Posts made by Bjorn Jentoft

I really liked Andrew’s idea of copying machine specific drivers.

I changed his script slightly and incorporated it with some other changes I have done to funcs.sh

[quote=“Andrew Single, post: 3130, member: 1006”]

machine=dmidecode -s system-product-name;
machine2=${machine// /};
…
echo -n " * Copying $machine Drivers…";
cp -r /images/drivers/${machine// /} /ntfs/Drivers

[/quote]

Became

[CODE]machine=dmidecode -s system-product-name;
machine=“${machine%”${machine##[![:space:]]}“}” # Remove trailing whitespace
ln -s “/images/drivers/${machine}/” /root/mydrivers
…
echo -n " * Copying $machine Drivers…";
cp -r /root/mydrivers/ /ntfs/Drivers
[/CODE]

The symbolic link is just a simple way to overcome the space-in-path-names problem, so I can have folder names just as they appear under “System Product” in the FOG hardware inventory.

Bjorn

[quote=“eric0626, post: 3807, member: 357”]KMS does not use SID, but it uses CMID instead. Thus, you don’t have to sysprep the image if you want to KMS, you can just simply rearm the OS before uploading the image.[/quote]

Eric, you are right about the fact that KMS does not use the SID, but CMID instead. This does not change the fact that sysprep is necessary, as CMID is also changed by sysprep. Having the same CMID on all computers results in KMS not counting.

Rearming the computer will create a new CMID, but this is not supported by MS. The recommended way is to rebuild your image with sysprep /generalize and no <SkipRearm>. The last note on the [URL=‘http://support.microsoft.com/kb/929829’]KB929829 [/URL]might be confusing though.

Regards, Bjorn

Considering my [URL=‘http://fogproject.org/forum/threads/why-sysprep-should-be-mandatory.708/’]post about sysprep[/URL], I would like to see better support for sysprepped machines in FOG.

There are several things that could easily be implemented by altering %WINDIR%\Panther\unattend.xml after imaging, like:
[LIST=1]
[]Renaming machine before first boot
[]Changing display properties (which on Win7 is only possible though registry, if implemented in client)
[*]Join domain
[/LIST]
I am sure there are more settings that would be nice to implement the same way, that are not part of FOG settings today, I only listed some that are currently configurable in FOG.
Regards, Bjorn

Sysprep has for many been an option they decided to skip when cloning Windows computers. This is bad practice.

The arguments for skipping sysprep is usually that the scenario includes a Windows domain, where the machine domain account gives a unique SID that will be used instead of the machine SID in every important case. The [URL=‘http://blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.aspx’]2009 article from Mark Russinovich[/URL] has often been used (also by myself) as an argument for this. However, it’s a long article, please read the last sentence as well. “Note that Sysprep resets other machine-specific state that, if duplicated, can cause problems for certain applications…”

Microsoft has never supported Windows cloning without sysprep. Sysprep is by Microsoft [URL=‘http://support.microsoft.com/kb/314828’]considered mandatory[/URL], and skipping it could lead to undocumented problems.

There are several Microsoft systems that we know use the machine SID instead of the domain account SID, including WSUS and KMS. If you use any of these, you are bound to get in trouble without sysprep.

Tools like NewSID are not an option. Russinovich states: “these tools don’t necessarily know about all the places where Windows stashes away references to the machine SID. The reliability and security of a system that has a mix of the old and new machine SID can’t be guaranteed.” Considering NewSID has not been updated since 2006, it should be obvious not to use it.

Other articles about this is
[url]http://support.microsoft.com/kb/929829[/url]
[url]http://technet.microsoft.com/en-us/library/ee939272.aspx[/url]
[url]http://blogs.technet.com/b/askcore/archive/2009/10/16/kms-host-client-count-not-increasing-due-to-duplicate-cmid-s.aspx[/url]
[url]http://www.brianmadden.com/blogs/guestbloggers/archive/2011/04/13/do-sids-matter-anymore.aspx[/url]

Regards, Bjorn

My conclusion that it works with CentOS 5.8 was a bit too soon. The problem persist when multicasting from a storage node, even though it works from the main server.

After doing some troubleshooting, I decided to test with a new installation.

First, I created a virtual network and set up a new FOG server on Ubuntu 11.10, and imported my image. Same result.

Second, I reinstalled the FOG server with CentOS 5.8. Problem solved, multicasting works as expected.

FOG 0.32 on Ubuntu 11.10. Weird problem. Multicasting stops when first partition is done, and does not continue to the next.

[IMG]http://jentofts.net/images/fogmulti01.png[/IMG]

This happens both when multicasting from my main FOG server and from my storage nodes. The only related logging is in /opt/fog/log/multicast.log:

[CODE][04-13-12 8:33:33 pm] CMD: gunzip -c “/images/xxxx/rec.img.000” | /usr/local/sbin/udp-sender --min-receivers 2 --portbase 63112 --interface eth0 --half-duplex --ttl 32 --nokbd;gunzip -c “/images/xxxx/sys.img.000” | /usr/local/sbin/udp-sender --min-receivers 2 --portbase 63112 --interface eth0 --half-duplex --ttl 32 --nokbd;[/CODE]

Anyone seen this?

Regards, Bjorn

I just solved a problem like this for myself. It turned out my Ubuntu mysql installation sets mysql to listen to 127.0.0.1 only. When I changed the IP to the actual IP and opened the firewall (main FOG server), it worked as intended.

On Ubuntu, the config file in question is /etc/mysql/my.cnf, the setting is "bind-address = ".

It’s a known fact that tftp is not the fastest protocol out there. Bigger files transfer much better on http. If you exchange [B]pxelinux.0[/B] with [B]gpxelinux.0[/B], http is supported. This will decrease loading time of ISO files substantially.

Your pxelinux.cfg/default would then contain something like this

LABEL winstall32
MENU LABEL Install Windows (all 32-bit)
LINUX memdisk
INITRD [url]http://myfogserver/iso/LiteTouchPE_x86.iso[/url]
APPEND iso raw

or

LABEL winpe
MENU LABEL WinPE
LINUX memdisk
INITRD [url]http://myfogserver/iso/mywinpe.iso[/url]
APPEND iso raw

Good luck, Bjorn

I am not sure if this has been addressed in a different thread, please excuse me if that is the case.

After uploading a Win7 sysprepped image from some computers, I get the following fail on first boot.

[IMG]http://jentofts.net/images/failedtostart.png[/IMG]

I found out that I could prevent this by using an image sysprepped on a [B]different machine[/B], in my case a VMware virtual machine, where I used standard IDE for the disk, not SATA. I added machine specific drivers to the image by using [URL=‘http://technet.microsoft.com/en-us/library/dd744355(v=ws.10).aspx’]dism.exe[/URL] from WinPE before uploading the image from VMware, to make it proper for the machine in question.

I hope this can be helpful to anyone with the same problem.

Bjorn