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.