Posts made by Bjorn Jentoft

I would like to get someone to look into this idea again. Using bittorrent instead of multicast has many advantages. First and formost, it is easy to move the traffic away from the server connection.

If you have some of the same challenges as I have, multicast traffic from the server to a set of clients will affect networking in a bad way, on all swicthes between the server and the clients. Using bittorrent, you can easily limit traffic from the server to a single tcp connection, and let the traffic between the clients go crazy instead. The clients I am working with are usually limited to a few switches at a time, with no other traffic while I am imaging, but the connection to the server in a different building might go through a number of switches that facilitate normal traffic as well.

The challenge will be to get sequentual downloading of the image files, which is not the standard bittorrent way. We have seen this done in quite a few applications related to videos, applications that play videos while downloading. En example to look into might be btcat from p2ptube, script [URL=‘http://p2ptube.sourceforge.net/btcat.py’]here[/URL]. I have not looked into how btcat can seed from it’s download, since the download is not going to a file, but perhaps some kind of buffer in memory?

I suggest using bittorrent only for deployment, not for uploading. It could just be an addition to current deployment methods, having the fog server running a tracker and a seeder. The seeder should have the option to limit the number of connections. An optional seeding delay on the clients after finishing download could also improve the result.

I have actually done bittorrent downloading for imaging for a few years. However, I have been downloading the image file the normal bittorrent way. to a temporary partition, without piping it, and then running the actual imaging process and cleaning up the partitions afterwards. This is a delay in the process I would like to get rid of.

I believe you should be able to use single partition with Windows 7, if you choose OS type Vista. Both when uploading your image and deploying. This way, FOG does not expect to find the system partition, and you can still choose resizable, as you want.

gwhitfield, just to avoid your confusion. Fogprep is not necessary with Win7 when you use sysprep. I checked the source for fogprep, and it does not do anything that sysprep does not.
Boot errors are as you mention the clue, both fogprep and sysprep makes it possible to boot your image on different disk controller.

When booting from a non-disk media like pxe boot, the Linux kernel sometimes will choose drives for sda and sdb differently than you expect, depending on BIOS settings and actual ports used. Perhaps this is the case here. You could do a debug boot and check that your primary disk is actually determined to be sda by the fog kernel.

I use the same method, reserving IP addresses in DHCP for my printers. I only got one HP 4000-series printer (4250), but it works perfectly. No problem picking up default gateway, even with options 066/067 set on the DHCP server.

I see, after you have deployed your images, the licensing is not your problem, your users provide their own license and you cannot use it to build your image?

Sounds like you either have to bite some sour apple, or join the MS OEM program…

I don’t see any problem with working with an activated Windows installation while preparing your image, are there any special reasons you don’t do this? After rearming, it needs to be reactivated, but this is usually not a problem.

Indefinitely is a very long time… Why not use your favourite virtualization software for building your image. Take a snapshot before you sysprep and upload your image. Then restore your snapshot to keep editiing your image.

If you are unable to use virtualization, then upload a special image to your fog server before you sysprep, and redeploy to your lab computer after uploading your sysprepped image.

Messing with the SkipRearm setting will not give you more than 3 rearms. Oh, and do not follow the advice to skip rearming in your image for deployment. It will only give you problems.

This is an easy one. Fully explained at [url]http://technet.microsoft.com/en-us/library/ff716063.aspx[/url].

Keep your SkipRearm off in your image, so that any normal deployment is successful. Whenever you need to change your image, be prepared to change the setting in the sysprep file after deployment to your lab computer. In other words, deploy it, but don’t let it boot. Boot to WinPE from your preferred boot device and change the setting in your unattend xml file, now found in [SIZE=12px][FONT=Segoe UI][COLOR=#2a2a2a]%WINDIR%\Panther[/COLOR][/FONT][/SIZE][I][SIZE=12px][FONT=Segoe UI][COLOR=#2a2a2a].[/COLOR][/FONT][/SIZE][/I]

More info at [url]http://technet.microsoft.com/en-us/library/cc766514(v=ws.10).aspx[/url]

That is nice, I like the unattend.xml approach better than modifying the registry.

(Taking notes for next FOG hacking session.)

I actually had a lot of unsigned drivers from Dell, using their [URL=‘http://en.community.dell.com/techcenter/enterprise-client/w/wiki/2065.dell-driver-cab-files-for-enterprise-client-os-deployment.aspx’]system cabs[/URL], but that might be because we have a lot of older models.

[quote=“dvlsg, post: 4971, member: 1186”]Oh that reg bit is interesting too. I like that.
[/quote]

I feel that I should tell you I am not really using the same exact approach for driver installation anymore. I do copy the drivers as described in my posts in this thread, and modify the registry to make Windows able to find the new drivers when my generalized sysprepped image start installing devices.

However, since Windows skips unsigned drivers in this process, it didn’t completely fill my needs. So in addition, I also modify or create a [URL=‘http://technet.microsoft.com/en-us/library/cc766314(v=ws.10).aspx’]SetupComplete.cmd[/URL] script, that amongst other things run dism.exe with the /Add-Driver and /ForceUnsigned switch, for the drivers that are unsigned.

I think you have a valid argument for your boss to change his opinion about volume licenses. 125 images per computer must be hard to manage no matter where you store them.

Basically, your license and activation challenges are the same whether you use FOG or Ghost. There is nothing stopping you from replicating what you do with Ghost on FOG, you could have all those images that are now located on local disks, stored on your FOG server instead. If you have 5 images stored on 50 computers, that would give you 250 images stored on a FOG server. Totally doable. You could get rid of your second partition on your computers, and secure your images on proper storage.

Going from there to using one image for several computers is a challenge that are the same no matter what imaging system you choose.

This is good info, Michael. I appreciate it when some people do the extra research that is needed to identify the cause of problems.

Let’s hope this will lead to better partition table handling in FOG, so that FOG can handle GPT as well as MBR. I believe this is one of the major shortcomings of FOG these days.

Bjorn

buckITall,

Let me see if I understand you correct. You have ghost images stored locally on every machine that are machine specific? Or are they the same image for all machines? If the latter is the case, you could just use FOG with the same disk images (well, image the disk with ghost, go straight to upload in FOG, to convert from ghost to FOG images). There are no difference in how disk images behave after imaging, when you compare FOG and ghost, except the fact that FOG will change the computer name for you.

Assuming worst case, you have machine specific, locally made ghost images with computer names and all. Are your machines in a domain? If not, you could use the same preactivated image for all machines without sysprep, as FOG changes the computer name after imaging. I do think the activation will survive the name change, although I haven’t tried it.

One image for all machines in such a case would mean one image for every computer make and model.

Perhaps I confused you more than helped you now?

Windows XP: [url]http://technet.microsoft.com/en-us/library/bb457078.aspx[/url]
Windows Vista/7: [url]http://www.microsoft.com/en-us/download/details.aspx?id=5114[/url]

Both documents describe how to preserve OEM Activation in Windows during imaging. No Volume license needed.

However, there are some manufacturers that ship their computers without preactivation. They only supply the activation key on a sticker. For these machines, a volume license is needed to prevent activation.

I would like to see the option of being able to define multiple OUs instead of just the single one in FOG_AD_DEFAULT_OU. Then, using the full registration and imaging boot, I would like to be able to choose from the OUs I have registered, the same way I choose image and OS.

Bjorn

If you are lazy, like me, you can let FOG change the registry setting in your images, so you don’t have to create new ones. Then the function should look like this:

[CODE]copyDrivers()
{
machine=dmidecode -s system-product-name;
machine=“${machine%”${machine##[![:space:]]}“}” #Remove trailing spaces
echo " “;
echo " * FOG Driver copy for $machine”;
echo " “;
mkdir /ntfs &>/dev/null
if [ “$osid” = “5” ]
then
ntfs-3g -o force,rw $win7sys /ntfs
elif [ “$osid” = “1” ]
then
ntfs-3g -o force,rw $part /ntfs
fi
ln -s “/images/drivers/${machine}/” /root/mydrivers
mkdir /ntfs/Drivers >/dev/null
echo -n " * Copying Common Drivers…”;
cp -r /images/drivers/Common/ /ntfs/Drivers
echo “Done.”;
echo -n " * Copying $machine Drivers…";
cp -r /root/mydrivers/* /ntfs/Drivers

regfile="/ntfs/Windows/System32/config/SOFTWARE"
key1="\Microsoft\Windows\CurrentVersion\DevicePath"
devicepath="%SystemRoot%\inf;C:\Drivers"
reged -e "$regfile" &>/dev/null  <<EOFREG

ed $key1
$devicepath
q
y
EOFREG

umount /ntfs
echo "Done.";
echo " ";
echo " * Driver copy completed.";
sleep 2;

}[/CODE]

In order to make use of Andrew’s modification, you start by [URL=‘http://www.fogproject.org/wiki/index.php/Modifying_the_Init_Image’]modifying the init image[/URL]. The modifications you want to do is as follows:

Edit the file initmountdir/bin/fog (path as in wiki link above), and add a call to the new function. I added it just before the call to changeHostname() around line 606, like this:
[CODE]…
if [ “$capone” != “1” ]; then

                copyDrivers    #Copy machine specific drivers
                changeHostname

…[/CODE]

Then, you add the function to the file initmountdir/usr/share/fog/lib/funcs.sh, somewhere in the file, i put it at the very end:
[CODE]copyDrivers()
{
machine=dmidecode -s system-product-name;
machine=“${machine%”${machine##[![:space:]]}“}” #Remove trailing spaces
echo " “;
echo " * FOG Driver copy for $machine”;
echo " “;
mkdir /ntfs &>/dev/null
if [ “$osid” = “5” ]
then
ntfs-3g -o force,rw $win7sys /ntfs
elif [ “$osid” = “1” ]
then
ntfs-3g -o force,rw $part /ntfs
fi
ln -s “/images/drivers/${machine}/” /root/mydrivers
mkdir /ntfs/Drivers >/dev/null
echo -n " * Copying Common Drivers…”;
cp -r /images/drivers/Common/ /ntfs/Drivers
echo “Done.”;
echo -n " * Copying $machine Drivers…";
cp -r /root/mydrivers/* /ntfs/Drivers
umount /ntfs
echo “Done.”;
echo " “;
echo " * Driver copy completed.”;
sleep 2;
}[/CODE]

Follow the wiki link on how to save the modified init back into place.

Then you add your drivers to your fog server, placing them under /images/drivers/<product name>, and modify your Windows 7 image, so that it [URL=‘http://support.microsoft.com/kb/254078’]looks for new drivers[/URL] under C:\Drivers (use the registry mod, adding the path to
[LEFT][FONT=Segoe UI][COLOR=#333333]HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\DevicePath.)[/COLOR][/FONT][/LEFT]