Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.
Windows Deployment Service in Server 2008 R2
No more installing client OSs by hand
Rhonda Layfield
November 19, 2010
25 Min Read
See this article's sidebar for information about pre-staging a client.
Solutions Plus
Problem: You need to deploy many clients.
Solution: Use Windows Deployment Services
What you need: Windows Deployment Services, OS images, an Active Directory domain, DNS, DHCP, and an NTFS partition.
Steps:
Install WDS
Configure WDS
Add boot images
Add install images
Add drivers to your images
Deploy to Clients
Windows Deployment Service (WDS) is Microsoft's replacement for Remote Installation Service. WDS has been around for a while—you could have installed WDS on Windows Server 2003 SP1, and it ships in the box with Server 2008 and later Windows Server OSs. In this article, I'll begin with installing WDS and walk you through configuring WDS, adding images (both .wim and .vhd formats), and I'll cover a topic that makes the top10 "most difficult things to do with Microsoft deployment tools" list every time—driver management. I'll finish up by showing you how to deploy an image to a client both a known and unknown client and what the difference is.
There are two types of WDS servers: transport and domain-based. A WDS transport server was designed for smaller environments that don't have an Active Directory (AD) domain. While transport servers require less infrastructure than domain-based server, they're more difficult to set up and configure. I'm only going to address domain-based WDS. Domain-based WDS requires infrastructure, including an AD domain, DNS, DHCP, and an NTFS partition.
Step 1: Installing WDS
How you install WDS depends on your server's OS. In Windows Server 2003 SP2, you open Control Panel, then Add/Remove Programs, Windows Components, WDS. On a Windows Server 2008 or 2008 R2 server, you add it as a role through Server Manager by following these steps:
Open Server Manager from the task bar (or the Start menu under Administrative Tools) and click Roles.
Click Add Roles to launch the Add Roles Wizard.
On the Before You Begin page, click Next.
The roles are listed on the Server Roles page. Select the Windows Deployment Services check box and click Next.
The Overview of Windows Deployment Services page explains a little about WDS and provides links for configuring and managing WDS. Review the links or just click Next.
The Select Role Services page lists two services that need to be installed for a domain-based WDS server. The Deployment Server and Transport Server check boxes should already be selected, so accept the default selections and click Next.
On the Confirm Installation Selections page, click Install. You'll see the Installation Progress page, then, when it's finished, the Installation Results page. Once it's successfully installed, click Close and you're done—no reboot required. The newly installed WDS snap-in is found in the Start menu under Administrative Tools, Windows Deployment Services.
Before you can deploy images from your WDS server, you'll need to configure WDS. Open the WDS snap-in then expand the Servers node and you should see your WDS server's name. If your server's name doesn't appear, right-click the Servers node and choose Add Server. The local computer is selected by default, so clicking OK adds the local server to the WDS snap-in. This is also how you can add multiple WDS servers to a single WDS snap-in so they can be remotely managed from a central location. To add a different WDS server instead of the local computer, right-click the Servers node and choose Another computer, then click Browse and navigate to the WDS server you'd like added.
Step 2: Configuring WDS
Now that your server is listed under Servers, notice the yellow yield sign next to your server's Fully Qualified Domain Name (FQDN). Configure WDS by following these steps:
Right-click your server name and choose Configure Server to launch the Windows Deployment Services Configuration Wizard.
The Before You Begin page lists the requirements of a domain-based WDS server. Click Next.
On the Remote Installation Folder Location page, type a path where you'd like to store your images (this must be an NTFS partition). I recommend putting your images on a drive other than your system or boot drives, and you should have at least 20 GB of storage space. I always accept the default name of the folder (RemoteInstall) and change the drive letter. Click Next.
The page displayed next depends on whether the DHCP service is installed on the same server you're installing WDS. Clients find both DHCP and WDS services by broadcast traffic destined for port UDP 67, which introduces two problems: Broadcast traffic is usually prevented from traversing one subnet to another, and DHCP and WDS installed on the same server can't both listen on port UDP 67. This leads you to three scenarios—WDS and DHCP installed on the same server, WDS and DHCP on different servers but the same subnet, and WDS and DHCP on different servers and different subnets.
WDS and DHCP installed on the same server: WDS and DHCP can't both listen on port UDP 67. Configuring WDS to not listen on UDP 67 leaves the port available for DHCP traffic and setting DHCP option 60 (scope or server option) to PXEClient resolves this problem. If you're installing WDS on a DHCP server, the DHCP Option 60 page appears during configuration. Select both Do not listen on port 67 and Configure DHCP option 60 to PXEClient check boxes. When a client receives an offer from that DHCP server, the offer will contain an IP address, subnet mask, and option 60, telling the client that the DHCP server is also a WDS server. If you add DHCP to a WDS server later you can configure this option by right-clicking your server name in the WDS snap-in and choosing Properties—the DHCP tab has similar check boxes.
WDS and DHCP on different servers, same subnet as clients: No additional configuration is required because WDS and DHCP are on different servers. They can both listen on port UDP 67, and the clients are on the same subnet as the DHCP and WDS servers, so broadcast traffic can be heard by all.
WDS and DHCP on different servers, different subnets: When WDS and DHCP are installed on different servers there is no issue with them both listening on port UDP 67. The problem is that broadcast traffic isn't normally allowed to pass from one subnet to another. There are a couple of ways to resolve this. You can configure IP helpers on your routers and switches to forward the traffic to the appropriate server, or you can configure DHCP options 66 and 67. Configuring DHCP options on an IPv4 network is performed in the DHCP snap-in, found in the Start menu under Administrative Tools, DHCP. From within the DHCP snap-in expand IPv4 then right-click Server Options (or scope options) and choose Configure Options. Scroll down to 066 Boot Server Host Name, select the check box, and type your WDS server's host name in the String value box (to find your server's hostname open a command prompt and type hostname). Then select the 067 Bootfile Name check box. In the String value box, type the path and name of the Preboot Execution Environment (PXE) file the client will boot. For example, on my WDS server, I accepted the default name of the WDS folder (RemoteInstall), so the string value for option 67 is E:RemoteInstallBootx86pxeboot.com.
The PXE Server Initial Settings page controls which client computers the server responds to. There are four options. The Do not respond to any client computers option is useful if you're not ready for the clients to deploy an image yet (maybe you haven't finished adding your images to the WDS server). The Respond only to known client computers option requires that you pre-stage your computer objects in Active Directory Users and Computers (ADUC). (For detailed steps, see the sidebar "Pre-staging a Client.") The Respond to all client computers (known and unknown) option is the least secure and, by default, allows any client that can connect to your network and authenticate to your domain the ability to deploy an image from your WDS server if the permissions on your images are left at the defaults. The last option, Respond to all client computers (known and unknown) BUT - Require administrator approval for unknown computers… is my favorite. This option allows known clients (prestaged clients) access to your WDS images and makes you aware of any unknown clients that attempt to access images on your WDS server. I'll explain the difference between known and unknown clients in the WDS and The Client section later. I recommend choosing the last option (you also have to select the Require administrator approval for unknown computers… check box) and clicking Next.
You'll see the Task Progress page and then the Operation Complete page. By default, the Add images to the server now option is selected. I like to clear this setting and add my images when I'm ready, so remove the check and click Finish. You should now see a green right arrow next to your server name.
Your WDS server is now configured. The next step is to add your images, there are two types: Boot (Windows Preinstallation Environment or WinPE) and Install images (these are the OS images you'd like to deploy).
Step 3: Adding Boot Images
A boot image is the WinPE that you will boot your clients with to get them on the network and ready to deploy an install image. I recommend using the latest boot image from Microsoft named boot.wim found on the Windows 7 DVD (or .iso) from the /Sources folder. When you boot using a x86 (32 bit) version of boot.wim you'll have both x86 and x64 install images listed to choose from. If you boot using the x64 (64 bit) version of boot.wim you will have only x64 install images to choose from. Follow these steps to add a boot image:
Within the WDS snap-in, right-click Boot Images and choose Add Boot Image to launch the Add Image Wizard.
On the Image File page, click Browse and navigate to your Windows 7 boot.wim file, then click Next.
On the Image Metadata page, accept the default Image name and Image description (or type your own) and click Next.
The Summary page shows your selections. If everything looks good, click Next, if you need to make changes click the Back button, make your changes and click Next again to get back to the summary page and click Next.
The Task Progress page appears. When it's done, click Finish and your new boot image will be listed in the details pane.
Step 4: Adding Install Images
The Install image contains the OS you want to deploy. The supported OSs to deploy are Windows 7, Windows Vista, Windows XP, Server 2008 R2, Server 2008, Server 2003 R2, and Server 2003.
WDS supports both .wim and .vhd OS image formats. You can add a Microsoft OS image file (.wim) or one you've created. If you create your own .wim image using ImageX be sure to use the /flags switch so WDS knows which edition of the OS is in the image. The imageX command syntax looks like this:
ImageX /Capture "Description" /Flags "Edition"To create an image of the C: partition, name it NewImage.wim with a description of New Windows 7 Image and identify the OS as Ultimate edition the command is:
ImageX /Capture C: C:NewImage.wim "New Windows 7 Image" /Flags "Ultimate"Adding a .wim install image to WDS
In this example, I'm deploying a Windows 7 OS image file from the Windows 7 DVD's /Sources folder. It's named install.wim. Follow these steps to add your Windows 7 install.wim to WDS:
From within the WDS snap-in, right-click Install Images and choose Add Install Image to launch the Add Image Wizard.
On the Image Group page, accept the default, Create an image group named ImageGroup1, or type a new image group name. I'm deploying an x86 Windows 7 image, so I'll create an image group named Windows 7 x86, then click Next.
Image groups reduce the storage space needed for your images. I'm adding a Windows 7 32-bit OS image to the image group named Windows 7 x86. When a second 32-bit Windows 7 image is added to the same image group, a special feature called single instancing wakes up and looks at every single file within the second image that's being added to the image group. If the file already exists (because it was in the first image I added), a pointer is created to use the existing file and not store the same file multiple times. There are a lot of core OS files that only need to be stored once within an image group, so you can save substantial space, and the more images you add the greater the savings.
Notice I mentioned putting only 32 bit images into this group—that's because adding 64-bit images store the entire .wim file, because the 64 bit core OS files are completely from the 32 bit architecture. I recommend creating one image group for 32-bit images and another for 64-bit images so single instancing can really do its thing. One other point to mention is that single instancing only works with .wim image files, not Virtual Hard Disk (.vhd) files.
On the Image File page, click Browse and navigate to your Windows 7 DVD's Sources folder (or .iso) and double-click install.wim, then click Next.
The Summary page shows the images that are contained in the install.wim. I'm using the retail DVD's install.wim, which contains Windows 7 Starter, Home Basic, Home Premium, Professional, and Ultimate editions. Click Next
The Task Progress page appears. Because install images are normally much larger than boot images, this will take longer to add. When the install image has been added, click Finish. The new install image appears in the details pane.
Adding a .vhd image to WDS
Adding a .vhd image is different than adding a .wim file in that it can't be done within the WDS snap-in. You must use the WDSUtil command line utility to add a .vhd. For example, if I have a .vhd file named Win7.vhd stored in the C:Images folder and want to add it to WDS's image group named MyVHDs, I'll follow these steps:
From within the WDS snap-in, create the image group MyVHDs by right-clicking the Install Images node and choosing Add Image Group.
In the Add Image Group box, type MyVHDs (or any name you want) and click OK. The new image group appears under the Install Images node. Close the WDS snap-in.
Open an elevated command prompt on the WDS server by right-clicking the Command Prompt and choosing Run as administrator.
Using WDS's command line utility WDSUtil to add a .vhd install image the syntax is:
WDSUTIL /Add-Image /ImageFile:"PathAndNameOfVHD" /ImageType:Install /ImageGroup: ImageGroupNameThe command for adding C:ImagesWin7.vhd is:
WDSUTIL /Add-Image /ImageFile:"C:ImagesWin7.vhd" /ImageType:Install /ImageGroup:MyVHDsStep 5: Add drivers to your images
Drivers in WDS are by far the most complicated component. They're not well documented and are incredibly frustrating to figure out. I hope these step-by-step instructions ease the WDS driver pain for you.
WDS uses dynamic driver provisioning (DDP) to control which drivers are deployed to your clients. You could rely on your clients to perform Plug and Play (PNP) during deployment to determine which drivers are needed. Or you can control driver deployment by organizing your drivers into driver groups.
A driver group is a collection of driver packages (drivers packaged in .exe, .msi or .cab formats). You can then add filters to the driver group identifying which drivers from the group are available to specific client computers based on hardware (such as Manufacturer or BIOS Vendor or Version to name a couple) or attributes of the OS install image like version (Windows 7 vs Windows Server 2008) or edition (Ultimate or Enterprise).
Normally the only drivers that will be deployed are drivers associated with hardware that is currently attached and powered on to your client machines. With DDP you can install drivers for hardware that is not yet conntected to your clients. It's a common practice to combine driver group filtering and PnP.
The supported driver packages are only available for Windows Server 2008 R2, Windows 7, Windows Server 2008, and Windows Vista SP1. WDS cannot read driver packages themselves (.exe, .msi or .cab file formats), they must be extracted first. Drivers packaged as .msi or .exe can sometimes be extracted using Winzip or WinRAR and some .exes you can change the extension from .exe to .zip, unzip the file and use Windows Explorer to copy the files from the compressed folder. Drivers packaged as .cab can be extracted using the Expand utility. For example a driver package named videodrv.cab stored in the c:drivers folder can be extracted to the c:expanddrv folder (that you created) by opening an elevated command prompt and typing the following:
expand -F:* c:driversvideodrv.cab c:expanddrvNote that the -F in the expand command is case sensitive.
Adding drivers to WDS is performed in two major steps: first you must add the driver packages to the WDS snap-in which also associates the driver package to an install image group (all install images within the image group have access to the driver group), then you can add the drivers to a boot image. To add driver packages to the WDS snap-in right-click the Drivers node, click Add Driver Package to launch the Add Driver Package Wizard and follow these steps:
Adding driver packages to WDS
On the Driver Package Location page choose to either add a driver package from an .inf file or a folder containing your expanded driver packages. Then click the Browse button and navigate to the .inf file or folder and click Next.
The drivers you added in step one are listed on the Available Driver Packages page. All drivers are selected by default. If you would like to de-select a driver, remove the checkmark next to the driver. After selecting your drivers click Next.
The Summary page lists the drivers to be added, review and if all looks good click Next.
The Task Progress page displays each driver as it is added. When completed click Next.
There are three choices for adding drivers to driver groups on the Driver Groups page: add drivers to an existing group (select your driver group from the drop down list), create a new driver group or do not put the driver in a driver group now. I created a driver group named VMWare, as Figure 1 shows, and clicked Next.
On the Task Complete page accept the default setting to modify the filters for this group. Click Finish to open the properties of the new VMWare driver group.
To add a filter click the Add button. Select the type of filter (I chose Manufacturer, as Figure 2 shows), select an Operator, (I chose Equal to), and type the name of the manufacturer (such as VMware, Inc.) and click OK. The new filter is displayed on the VMWare driver group properties / Filters tab. Click OK.
The new driver group appears under the Drivers node and the drivers are displayed in the details pane. The information displayed includes: Package Name, File Name and Class GUID to name a few. You may need this information when adding your drivers to a boot image later.
Adding Drivers to a Boot Image
Now that your images have been added to the WDS snap-in you can add drivers to your boot images for your client machines hardware. What type of drivers do you need to add? Possibly mass storage or network drivers. Follow these steps within the WDS snap-in:
Expand the Servers node, then expand your server and click on the Boot Images node. In the details pane, right-click the image and choose Add Driver Packages to Image to launch the Add Driver Packages to Image Wizard.
The Before You Begin page warns you to first back up your boot image by right-clicking the image and choosing Export Image. Exporting the image won't remove it from the WDS snap-in, it just creates a copy. If you don't have a backup copy of the boot image, click Cancel and export the image first, then launch the wizard again. If you have a backup copy of your boot image, click Next.
On the Select Driver Packages page two default filters will be displayed. The filters will depend on which boot image you launched the Add Driver Packages to Image Wizard from and it's architecture. I right-clicked a x86 boot.wim so my filters were: Package Architecture equal to x86 and Package Class equal to "Net", "System", "DiskDrive", "hdc", "SCSIAdapter". You can add more filters or if these are the only filters you need click the Search for Packages button. All drivers that meet the filter criteria will be listed in the Search results box, which Figure 3 shows. By default all drivers that meet the criteria will be selected, accept the default drivers or deselect the ones you don't want and click Next.
The drivers you chose will be listed on the Selected Driver Packages page, click Next.
The Task Progress page shows that the boot.wim is mounted, the drivers are added (each driver is listed as it is added), changes to the boot.wim are saved and it is unmounted. When the Operation Complete page appears click Finish.
View the drivers in a boot image
I wish there were an easy to way to view the drivers that have been added to the boot image. What if you don't know which drivers have been added to a boot image? Maybe you're not the person who added the boot image, but it's your job now to manage the images. To view the drivers in a boot image follow these steps:
Export the boot image by right clicking the image and choosing Export Image, give the exported image a name and path to where you would like to save it and click Save. I named mine WDSBoot.wim and saved it in the F:wims folder.
Open an elevated command prompt and mount the image to an existing empty folder. The tool you use to mount an image is the Deployment Image Servicing and Management tool (DISM). The syntax looks like this:
Dism /Mount-Wim /WimFile: /index: /MountDir:
For example to mount my WDSBoot.wim file to the c:mount folder I would type:
Dism /Mount-Wim /WimFile:f:wimswdsboot.wim /index:2 /MountDir:c:mountMounting boot images doesn't take long—they're small compared to install images. While waiting for your boot image to mount I'll take a moment to explain the /index:2 switch in the previous command. Microsoft .wim image files can contain multiple images and by default the boot.wim we added from the Windows 7 DVD (/Sources folder) contains two images. Drivers are added to the second image of the boot.wim, so that is the image you need to mount.
To get a list of currently installed drivers from the mounted boot image type this DISM command:
Dism /image:c:mount /Get-DriversIf you have a lot of drivers and don't want the screen scrolling all over the place you can also get the driver listing in a table format by typing:
Dism /image:c:mount /Get-Drivers /format:tableAnd a great way to quickly document which drivers are currently installed is to pipe this output to a text file and print the file, put it in a notebook and voila documentation is created. To pipe the information to a text file named drivers.txt and stored in the c: drive, type
Dism /image:c:mount /Get-Drivers /format:table >c:drivers.txtNext you need to unmount the image and if all you did was view the currently injected drivers there is no need to save your changes. But if you used DISM at this point to inject other drivers or modify any other part of the boot.wim you will need to save your changes when you unmount.
To unmount the image with no new changes, useDISM /Unmount-Wim /MountDir:C:mount /discardTo unmount the image if you made changes:
DISM /Unmount-Wim /MountDir:C:mount /commitIf you made changes to the boot.wim using DISM, you'll need to add the boot image back to the WDS snap-in in one of two ways. From within the WDS snap-in, either right-click the boot image you exported and choose Replace Image then select the image you previously exported, or add the boot image as a new image as I did earlier in the Adding Boot Images section.
Step 6: Deploy to Clients
Deploying your first WDS client is performed by PXE booting, also known as a network boot. When the client boots, it gets an IP address (and any options) from a DHCP server. Next, the client finds a WDS server (also called a Network Boot Server) to boot a Network Boot Program from. If there's more than one boot image on the WDS server, a list of boot images is presented to choose from. Lastly, a list of OS images are presented to choose from. In this section I'll show you each step in more detail and explain the difference between a known and unknown client deployment scenario.
Known Clients
To perform a network (PXE) boot from the client, boot a client then, when prompted, press F12, for network service boot.
If only one boot image has been added to your WDS server (as in this example), that boot image is automatically booted. If you have more than one boot image, a menu will allow you to choose which boot image you'd like to boot.
The client boots to the Windows Deployment Services Wizard and prompts you for the installation language. Accept the defaults for U.S. English or choose another and click Next.
You need to authenticate to the WDS server in the authentication dialog box (the user account you authenticate with needs to have read and execute permissions on the image you want to deploy). Be sure to use the DomainNameUserAccount format and click OK.
When the list of install images are displayed select the install image you want deployed and click Next.
On the Where do you want to install Windows page, click Drive options (advanced), then New.
Accept the default size or change it to what you want and click Apply. A message letting you know that Windows might create additional partitions for system files appears. Click OK. By default, deploying Windows 7 creates two partitions. One 100MB partition is created in case you want to use BitLocker (this partition will be hidden and receives no drive letter). The other partition uses the rest of the hard drive and will become the C: partition. Click Next.
The Waiting for server page appears, followed by the Installing Windows page. When it's done, the client reboots and displays the Set Up Windows page. Choose your Country or region, Time and currency, and Keyboard layout and click Next.
Type the name you want to use for the username that will be created locally on the client and click Next.
On the Set a password for your account page, type a password (twice) and a password hint and click Next.
On the Type your Windows product key page you can enter your product key. If you leave this field blank, you'll have 30 days to provide the product key. (I leave the product key blank on test machines). The Automatically activate Windows when I'm online check box is selected by default. If you choose not to enter your product key, clear this check box and click Next.
The Please read the license terms page requires you to select the I accept the license terms check box then click Next.
On the Help protect your computer and improve Windows automatically page, there are three selections: Use recommended settings (downloads and installs all OS patches, drivers from Windows Update and Windows Defender updates, IE phishing filters, and other updates when they're available), Install important updates only (downloads and installs critical updates only), and Ask me later (turns automatic updates off). Choose the setting that's right for you and click Next.
Set your time zone, date, and time on the Review your time and date settings page and click Next.
Setting your computer's current location determines how secure your new client will be. If you're on a trusted home network (that has a firewall between the client and the internet), choose Home network. If the client is on a trusted network at work (again, where there's a firewall present) choose Work network. If you're at a coffee shop or other public location with no known firewall between the client and the Internet, choose Public network.
You'll see Preparing your computer, then the Windows 7 desktop.
Unknown Clients
The difference between known and unknown clients is only one step and that's step one. At the beginning of this article in the "Configure WDS" section (step 5) I recommended that you set the PXE Server Initial Settings to Respond to all client computers (known and unknown) and also selected Require administrator approval for unknown computers etc….
When unknown computers (not pre-staged in ADUC) attempt to perform a network boot (PXE) they receive the screen that Figure 4 shows. Notice at the bottom of this screen there is a message, pending request id of 4, a space to provide a Message from Administrator: and a Contacting Server: IP address (this is the IP address of the WDS server the client is attempting to connect). The client will continue to contact the WDS server every few seconds to see if the request has been approved or rejected. Every time the client checks with the WDS server another dot appears after the WDS server's IP address.
To find pending devices, follow these steps on the WDS server
Open the WDS snap-in, expand Servers and your server name. Then click on the Pending Devices node, in the details pane you will see a pending device with a number associated to it. In our case it would be number 4.
Right-click the pending device Request ID 4 and from the menu there are three options: Approve (approves the client and they will continue with the deployment just as a known client would), Name and Approve also approves the request but it allows the administrator to name the computer object that is created in ADUC for the new client, and Reject reboots the client.
From this point forward, all steps for an unknown client are the same for known client computers. Follow steps 2-16 to complete your client deployment.
I know there's a lot of information in this article, with installation, configuration, adding basic boot, and install images (along with their drivers) to the client deployment process for both known and unknown clients. I haven't even told you about multicasting transmissions and the advanced configuration options. Look for future articles that cover these and many more WDS topics.
About the Author
You May Also Like
.jpg?width=700&auto=webp&quality=80&disable=upscale)
