Windows Deployment Services: A Real Ghostbuster Part 1

Reading Time: 5 minutes

I'm currently working on a relatively large project and it's one of the most complex migrations I have ever been part in. That is one of the reasons this blog has been a bit neglected. At the moment, most of my work on Active Directory and such only has to be fine tuned and that means less stress for me and more time to share my new found knowledge and experiences :). And with this post I will share my new found love for Windows Deployment Services on Windows Server 2008.

The Situation Report

There were two separate buildings, but I will concentrate primarily on the main building.

Next to a cross-forest migration (Forests A and B to C), a new deployment system for Windows XP Professional had to be designed. They already had Ghost and did use RIS and an upgraded RIS to WDS on Windows Server 2003.

Application deployment would be realized with SoftGrid 4.5 (now Microsoft App-V) in order to minimize application maintenance (They have about 200 applications), this would drastically reduce the amount of images and maintenance of those images.

With these other techniques the only requirements were that the new client OS deployment method could distribute one or two Windows XP installations to about 1000 computers in a relatively short time. Yes, multicasting is heavily implied here.

The physical network was already replaced with a Gb network with a ring redundancy. Our network guy guarantees it can handle it. To complicate things and to be able to secure the network, three VLAN's were implemented. Two for clients and one for servers and this means inter-VLAN multicasting….

The new forest is built upon Windows Server 2008 where it could, only a few servers are Windows Server 2003 R2. All servers were implemented in a VMWare ESX cluster with two servers.

The Objective

I already had some experience with Ghost (v11, i think) in combination with PXE and Ghostwalker. This meant that an (sysprepped) image would be deployed to a computer that was booted via the network. After deployment, Ghostwalker would change the computername and SID to prevent duplicates in your domain. The computername could defined so that Ghostwalker would change it every time automatically to the same one.

A similar strategy was my goal: the least amount of user input from booting to the login screen of Windows XP. After booting the computers start deploying the correct image automatically via multicast, then the sysprep would install the correct drivers, name the computer according to my whishes and automatically joins the computer to the domain. The only necessary user action needed until an usable logon screen appears: starting the PXE boot.

My instincts told me that WDS could be one of the solutions, my pride said it would be the most elegant one and my ratio said: Testing, testing and testing.

The How-To


Installing WDS is absolutely easy and no issue at all on Windows Server 2008.  When using Server Manager, you just have to add the Windows Deployment Services role (both Deployment and Transport Server). I will not go into the difference between those two sub roles, but in this case (and most cases) you will need both.

Installing WDS on Windows Server 2008 Installing WDS with Transport and Deployment server

Alternatively you can install them via command line using:

ServerManagerCmd -install WDS
ServerManagerCmd -install WDS-Transport

In our case the WDS servers is a member server and DNS and DHCP are installed on another server. Temporarily this is a DHCP server from one of the old forests and in another subnet (when this server is decommissioned, we would use DHCP relay and this is possibly not needed).

Having your WDS server in another subnet than your clients is no problem, but you will have to the DHCP server or scope options to enable DHCP options 66 and 67. Option 66 will need to contain the ip address of the WDS server and options 67 needs the boot file name (more on that later). If they are in the same subnet, this is not needed (actually Microsoft recommends not doing it).

Now your clients are able to boot via PXE and find your WDS server, but there are still some things to do obviously.

Boot Image: "need input!"

There are several different boot stages. One is the network boot, which enables the computer to find the Boot and Deploy or Boot and Capture Image. With WDS on Windows Server 2008 x64 clients with EFI BIOS are supported. I haven't seen anything of that yet, so I'll concentrate on the x86 versions.

The Boot image is a WIM file acquired from a Windows Server 2008 or Windows Vista SP1 DVD. The version is not important, although I want x86-32bit versions. And if you have only Vista DVD's (unlikely because you're using Windows 2008 as WDS server!), make sure you take the slipstreamed SP1 version. Otherwise multicasting will not work.

The WIM file has to be imported into WDS as a boot image, go to the Boot Image folder in WDS, just right mouse click, import and browse to boot.wim. As we will add at least one more boot image, name the image properly like "Boot and Deploy Image".

As default this will be a boot and deploy image, but you can convert an existing image to capture image. It's the same WIM file, but when booting from this it has been configured to look for sysprepped images and is able to capture it (to a local disc or directly to the WDS server). I tend to name this image "Boot and Capture Image".

With the boot image you can deploy sysprepped Windows installations after booting via PXE. As we don't have anything to deploy, the important thing now is to make a sysprepped installation of Windows XP or Vista. If not sysprepped, the WDS Boot and Capture image will not find a suitable prepared image to capture.

Prepping sysprep systems

In our case I will focus on XP. In the sysprep.inf the product license key, automatic domain join and other configurations are added in such a way no user input is necessary. There are some things to take in mind:

  1. Make a separate domain join account and do not take the (or a)domain administrator account. You could encrypt the sysprep.inf, but I feel a dedicated account for domain joining computers only is the safer and more elegant way.
  2. Make sure you have all you important drivers added, especially mass storage drivers and network drivers. In some cases you will have to seal the image multiple times on different hardware, in order to use the image on different hardware configurations.
  3. Add the line "COMPUTERNAME = %COMPUTERNAME%", otherwise Windows will wait for user input (most of the time with an suggested random name). We will configure more via the WDS command line tool WDSUTIL, but (much) more on that later.

There is much more to it with sysprepping, but that is beyond the scope of this article.

Next time…

The next part will elaborate on capturing and deploying your sysprepped image.


Further reading and Sources:

Windows Deployment Services

How to use the Sysprep tool to automate successful deployment of Windows XP