The Desktop Files
Windows Deployment Services 101
Last month's column reviewed the history of Pre-Boot eXecution Environment (PXE)-based deployment tools from Microsoft. This month, I'll dig into Windows Deployment Services (WDS), specifically discussing the versions that shipped for Windows Server 2003 and the updated version that shipped with Windows Server
2008. After that, I'll get you up and running with WDS.
WDS can best be thought of as the rewritten Remote Installation Services (RIS). Even though they both share some key components, and in fact the version of WDS on Windows Server® 2003 has a legacy mode that is functionally identical to RIS, the actual infrastructure of WDS running in native mode and in 50 percent of mixed mode is brand new.
WDS in Windows Server 2003
When Windows Vista® was released, WDS was offered at the same time. This step was necessary because the Windows Vista setup was completely redesigned using the Windows® Imaging Format (WIM) architecture, making RIS incapable of deploying Windows Vista (and, eventually, Windows Server 2008). WDS was then made available as an out-of-band download for customers running Windows Server 2003 SP1. With SP2, RIS was completely supplanted by WDS.
You should remember that since WDS in Windows Server 2003 has complete backward compatibility, you don't need to move to native mode when installing WDS on your Windows Server 2003 SP2 system(s). You can continue to run in legacy mode—functionally running as an RIS server—or in mixed mode, allowing for either WDS or RIS to be initiated.
Besides being able to deploy Windows Vista and Windows Server 2008, WDS running in native mode or in the native half of mixed mode has several additional features. Rather than utilizing the Windows kernel-mode setup engine and the traditional setup core I discussed last month (technet.microsoft.com/magazine/cc645015
), WDS uses Windows PE as its bootstrap preinstallation environment, and it deploys WIM-based images instead of using RISetup or RIPrep-based installs. Doing this makes deployment faster, easier, and more reliable.
Moreover, many of the limitations I mentioned last month, such as the need to use American National Standards Institute (ANSI)-based characters, go away since Windows PE is capable of displaying the same character sets as a full installation of Windows.
In addition, WDS gained a few tools that RIS sorely lacked—a Microsoft® Management Console (MMC) snap-in to assist in management, and a hugely comprehensive command-line configuration tool that enables configuration capabilities far beyond that of RIS.
Since both legacy and mixed modes allow for deploying RISetup- and RIPrep-based images of Windows, you may want to bear one thing in mind. Historically, RIS used a component called Single Instance Storage (SIS) in order to optimize image storage on disk. SIS, which later shipped as a part of Windows Storage Server 2003, utilized a service called Groveler, which runs in the background on RIS (and WDS) servers, looking for identical files. If the size and hash of any files match, SIS saves a copy to its own SIS Common Store folder and then creates a hardlink to each of the original versions it found.
SIS is designed to minimally impact processor utilization while enabling significant storage savings. It was a great concept that was used first by RIS and then broadly on the Windows Server platform. But SIS is no longer used for WDS going forward.
Since WDS on Windows Server 2003 running in native mode—and always on Windows Server 2008—utilizes WIM images for setup, it has its own compression and—more importantly—its own single instance file storage model, and it doesn't utilize SIS at all. The Image Store replaces the storage model used by RIS with a new WIM-based design for WDS. Additional information about SIS is available at go.microsoft.com/fwlink/?LinkId=120302
WDS in Windows Server 2008
In Windows Server 2008, WDS has become both a superset and a subset of the functionality in Windows Server 2003. It can now deploy images via multicast in standalone mode using Transport Server, a new Trivial File Transfer Protocol (TFTP) server with better performance, support for Extensible Firmware Interface (EFI)-based x64 systems, and enhanced installation metrics reporting. I'll discuss these in next month's column.
You should note that there is one feature of WDS in Windows Server 2003 that has been discontinued in Windows Server 2008—legacy setup support. The ability to deploy RISetup/RIPrep images or use the legacy RIS OS Chooser to start setup is no longer available.
Making a Choice
One of the more frequent questions I've been asked since Windows Server 2008 shipped is, "What version of WDS should I be using?" The answer depends on whether you are deploying pre-Windows Vista versions of Windows and, if so, if you are ready to make the transition from RISetup and/or RIPrep-based images to explicitly using a WIM-based setup.
WDS, even in Windows Server 2008, is capable of deploying Windows all the way back to Windows 2000 if it's in a WIM image—and can do it using multicast. So if you are making the transition from RIS to WDS right now and thinking about Windows Server 2008 in your infrastructure—and you're willing to migrate from RIS-based to WDS-based images—then a migration to WDS in Windows Server 2008 may make sense for you.
You could also migrate from RIS to WDS on your Windows Server 2003 system itself, which essentially happens when you install SP2, and make your shift to WDS-based images. Then you could just upgrade to Windows Server 2008 WDS and go.
That's not the model I'd recommend, though. As with many versions of Windows Server before 2008, Microsoft recommends migrating (versus in-place upgrading) from one version of Windows Server to another.
And as I've mentioned before, considering x64 versions of Windows Server 2008 probably makes a lot more sense in your infrastructure than did x64 versions of Windows Server 2003. If you do make that transition, performing a server-to-server migration of WDS on Windows Server 2003 to Windows Server 2008 will be relatively easy and much more reliable when compared with an in-place upgrade.
Here are some points to bear in mind while you are working on your WDS deployment. Note that they are actually not new requirements for WDS—RIS had many of these same considerations—but you'll want to take them into account whether you are building a single WDS server or an entire infrastructure:
Privileges There are two principal items to remember when you are managing a WDS server. You must authorize a WDS server in Active Directory® just as you had to with RIS. To do this, you must be either a domain administrator in the root domain of the forest, an enterprise administrator, or you must have been delegated the appropriate privileges. You also need to be a domain administrator to administer your WDS server, and, of course, you must also be an administrator on the WDS server itself.
Virtualization When running on a Windows Server 2003 or Windows Server 2008 instance virtualized under Microsoft Virtual PC or Virtual Server and communicating with a client PC on the same installation of Virtual PC or Virtual Server, a race condition may occur beginning at PXE boot, leading to a very slow or potentially hung client. It is recommended that you virtualize either clients or servers, but not both—especially on the same host system. Personally, I wouldn't recommend virtualizing a WDS server for production use—this is primarily due to the next point.
Other Services WDS, like RIS, doesn't always play well with other production services. In particular, I've seen issues with RIS/WDS when running on a production system that is also running Microsoft Exchange Server, Systems Management Server (SMS), and System Center Configuration Manager (SCCM).
Generally, I recommend that WDS be the only role on your server if you are using it for production for more than a handful of clients. This isn't unique to WDS—you should carefully consider whether or not you should mix roles of Windows server products and test them before deployment.
Slow- or High-Latency Links As with RIS, WDS isn't meant to be used over a low-bandwidth connection or a high-latency connection such as a satellite link; the PXE handshake may be problematic, and downloading images will likely be painful, if it works at all.
Getting Started with WDS
To begin, you have to decide whether you are going to use WDS on Windows Server 2003 or Windows Server 2008. If you are using Windows Server 2003, I recommend starting with SP2, which has WDS included natively as an optional component (replacing RIS), instead of using SP1 and the previously available optional download of WDS included in the Windows Automated Installation Kit (WAIK).
For either version of Windows Server, you'll want to build out your server system. You should use a high-quality Network Interface Card (NIC), capable of at least 100Mbps or faster. Do not use NIC teaming, as the PXE infrastructure of WDS may prove problematic with it. Note that if you are using Windows Server 2008, you can install WDS on either Server Core or the full installation of Windows Server 2008.
WDS is installed on Windows Server 2003 as an optional component (as was RIS before it). You can install it during setup of the OS or afterward by running Add/Remove Programs | Add/Remove Windows Components (or running sysocmgr.exe from the command line). WDS is installed in Windows Server 2008 as a Role and can be installed via the initial configuration wizard (click Add roles | Next | and select Windows Deployment Services), via Server Manager (same steps as initial configuration wizard), or from the command line by running ServerManagerCmd –install WDS.
Once you've installed WDS, you need to configure it. Under your Windows Start menu, go to Administrative Tools and select Windows Deployment Services. When the MMC launches, right-click on your server and select "Configure Server" from the menu to launch the configuration wizard.
If you are installing on Windows Server 2003 and upgrading an existing RIS Server, you will want to specify the existing RemoteInstall directory so that the legacy installation can be upgraded to mixed mode. In this situation, you should ensure that the RemoteInstall directory is not located on the System partition, which can impact performance.
Figure 1 shows the WDS console on Windows Server 2008 before the configuration wizard has been completed. Figure 2 shows the Welcome Page for the WDS configuration wizard on Windows Server 2008. Figure 3 shows the PXE configuration step of the WDS configuration wizard. In this step you can specify whether the server should respond to any clients (useful for initial build-out), respond to only known client computers (those that have been pre-staged in Active Directory), or respond to all clients (and whether it should optionally hold all unknown clients so an administrator can choose a further course of action).
Figure 1 WDS installed but not yet configured
Figure 2 The WDS configuration wizard
Figure 3 Choosing a response policy for the PXE server
Figure 4 shows you a fully configured WDS server on Windows Server 2008 (with no images installed yet) with its Properties page opened. If you are using a server that is already a Dynamic Host Configuration Protocol (DHCP) server, be sure to set DHCP Option 60 to PXEClient and set WDS to Do not listen on port 67. Doing so will allow your WDS server to skip a step during the PXE discovery process (as I discussed in last month's column).
Figure 4 A fully configured WDS Server on Windows Server 2008
Once the wizard has completed, you can add new images. Two types of images may be added to a WDS server running in mixed or native mode:
- Boot Images: these are images containing Windows PE 2.x, generally copied off of the Windows Server 2008 or Windows Vista SP1 installation DVD. Note that you'll want to use the \Sources\Boot.wim file from Windows Server 2008 for your boot images (even if you are deploying Windows Vista or a legacy operating system) if you are using multicast. Boot images generally consist of Windows PE, Windows Setup.exe, and other dependencies.
- Install Images: these consist of Windows OS images, generally the \Sources\Install.wim file from Windows Vista or Windows Server 2008.
To add a default boot image or default install image, the steps are almost the same. You begin each process by right-clicking the image type and choosing to add an image of that type.
For an install image, you need to specify a name for the image group (given that a default WIM on the Windows DVD contains more than one OS type). Then browse to the appropriate boot.wim or install.wim that you want to add and click Open. For install images, you can then uncheck any volume images (OS images) you do not want to add to the WDS server. Finally, you can PXE-install clients using these default images.
In order to create custom OS images, you need to create a capture image—a Windows PE image that is designed to allow you to capture a Windows system as a WIM image. The easiest way to do this is to use a boot.wim image you installed earlier.
Right-click the desired image and click Create Capture Boot Image. Specify the name and description to use for your image, and the location to save a local copy of the .wim file in case of network connectivity issues when deploying the capture image. Then follow the wizard to completion and click Finish.
Next, right-click the Boot Image folder in the WDS MMC and click Add Boot Image. As before, follow the instructions in the wizard. When you're finished, you are ready to capture up a Windows install image.
Before you capture an operating system image, you must, of course, install Windows and make sure it includes all your desired applications, customizations, and updates. The next thing you need to do is run Sysprep on your system; you can only capture Windows install images from systems prepared with Sysprep. You must specify a valid local location to save the new image (to avoid potential corruption) and a *.wim file extension.
After you have configured your system and copied the correct version of sysprep.exe to the system, you must follow these steps:
- From the command prompt that is on the reference computer, change to the directory where sysprep.exe is located.
- Start Sysprep (you can also start by double-clicking sysprep.exe and manually specifying options). On computers running Windows Vista or Windows Server 2008, run the command sysprep /oobe /generalize /reboot. On computers running earlier versions of Windows, run sysprep -mini –reseal –reboot.
- When the computer restarts, PXE boot it (the process may vary depending on your client system).
- From the boot menu, select your WDS capture image and click Next.
- Choose the drive and the name and description for the image.
- As mentioned, only systems that have been Sysprepped will be visible. This is by design, and there is no way to bypass it.
- Click Browse and then browse to the local folder where you want to store the captured install image. The location you choose can be a mapped network drive.
- Select Upload image to WDS server.
- Type the name of the WDS server and then click Connect.
- From the Image Group list, select the image group you want to store the image in and then click Finish.
This image is now ready to be deployed from your WDS server. There is one thing you RIS veterans out there may have noticed—I didn't capture this Windows image live. WDS requires that the system being captured be offline.
RIPrep, in RIS, was able to capture (in fact, required capture of) an online system. That process was exceedingly fragile. I think you'll find the capture process for WDS relatively easy and certainly more robust.
If you've been using RIS for any time at all, you've got some images laying around. For those images that are RISetup-based (a scripted install), this is the end of the road. You can, however, migrate RIPrep images to WDS WIM-based images. In fact, WDS even allows you to migrate the images via WDSUtil (I'll explain this in more detail next month).
I generally recommend doing this only if you have invested a significant amount of time in an image that you don't want to lose. The process works pretty well, but I've heard of some errors during conversion—which generally means you need to rebuild the image from scratch anyway.
Creating an image as I did previously gives you an image that can be installed manually. For a more automated or fully automated install, you need to use two unattended setup files. WDS itself requires an answer file (unattend.xml, stored under the \RemoteInstall\WDSClientUnattend directory on your WDS Server) that automates the WDS setup process. The second file is an actual image unattend file. For Windows Vista or later, this is an unattend.xml file. For earlier Windows images, it is a sysprep.inf file that is stored in a $OEM$ directory structure or under \Unattend in each image's directory. This file is used to automate the actual installation of Windows once WDS has completed.
To create the WDS Unattend file, create an unattend.xml file for WDS using the WAIK. Copy this file to the RemoteInstall directory or a subdirectory. Right-click the install image for which you would like to use the unattend file and click Properties. Under the Client tab, select Enable unattended installation and provide the unattend.xml file specified earlier.
To create the Image unattend file for pre-Windows Vista images, copy the sysprep.inf file to the $OEM$ directory for the image—for example, D:\RemoteInstall\Images\Windows XP\SP2\$OEM$\$1\sysprep\sysprep.inf. For Windows Vista images, specify the image you want to associate, click Properties, and then under the General tab, click Allow the image to install in unattend mode. Then specify the unattend.xml file that is to be used for installation.
We're now halfway there. This column should get you up and running with WDS. Next month, I'll drill into more detail about WDSUtil, Image Store specifics, and multicast. Then I'll wrap up the series with an in-depth look at how and why you might consider building a custom deployment solution on top of WDS. Until then, take a look at the "More on WDS" sidebar that accompanies this column.
is a Senior Technical Product Manager at CoreTrace (www.CoreTrace.com
) in Austin, Texas. Previously, he worked at Winternals Software and as a Program Manager at Microsoft. Wes can be reached at firstname.lastname@example.org
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.