Overview of Windows Deployment Services

Windows Deployment Service comes as a new server role in Windows Server 2008 operating systems, but can be installed optionally on Windows Server 2003 as well. It handles certain aspects of remote deployment, either aided by unattended scripts or by disk imagining. It also brings a set of new enhancements to its successor (Remote Installation Service abbreviated as RIS). IP multicasting is the most important addition.

The way WDS approaches remote deployment is by giving system administrators the ability to capture and store entire packages of installations for later deployment. WIM is the Windows Imaging Format. Its predecessor supported only unattended scripts.

Using the new WDS technology, we're therefore able to prepare images of various operating systems (Windows XP, Vista, 7, etc.) with a set of additional applications such as Microsoft Office suite, Visual Studio or any other development IDEs, web-authoring software packages, and so forth. And then when the situation requires it, you have ultimate flexibility to customize which OS to deploy with the different kinds of apps.

On the next page we'll briefly overview the set of features WDS brings to the table.

In order to fully understand how WDS comes into the picture of remote deployment, we first we need to present the renowned Windows Automated Installation Toolkit, also known as WAIK. Basically, WDS is built on top of this, and upon installation you will see that it asks you to download WAIK as well. That is a set of nifty tools, most of which are individual utilities that aid you in automated installations later on.

WAIK contains utilities such as the ImageX that helps create images (Windows Imaging Format, .WIM extension) and the Sysprep (System Preparation) utility that basically prepares an already-installed operating system to be cloned/imaged and deployed in the future on different machines. It basically removes all the computer-specific "clutter" and packs together an OS that can be put on another machine.

Other tools include the Windows PE (Preinstallation Environment) that is nothing but a stripped-down version of Windows (any version, from XP up to Win2008 and 7). This is the sort of new technology that helps deployment of Windows operating systems and replaced the old-fashioned MS-DOS. WAIK also contains other tools which are beyond this article's scope. Look into the official documentation for more information.

Windows Deployment Service is installed on a management server that is going to act as a centralized point that is able to keep together the deployment information for multiple operating systems along with driver packages, various applications, and things like unattended answer files. These are all created with the help of the tools contained within the WAIK, and then placed into the WDS, which gives you an easy-to-use front-end.

Now let's check out the requirements of WDS. First, as expected, you need to have a fully configured DHCP server (with at least one active scope) since PXE-booting heavily relies on this. Your target client machines need to contact your PXE server, and then once their IPs are assigned, they can further communicate and download via the TFTP server the necessary files to launch the deployment process. Other roles, such as having an Active Directory and a DNS server as well, should be met without doubts.

There are two kinds of WDS-possible installations: first, the Deployment Server, which is the entire Windows Deployment Service that contains all of its features and capabilities; and then the Transport Server, which is the option you want to choose if you need multicasting transfer without the other WDS functions.

Moving on, we will present how to set up Windows Deployment Service, and also see a real-world example of deploying Vista on client computers. We are going to also tackle the topic of how and when to use Multicasting transmissions.

Windows Deployment Service can be installed in a service role in the case of Windows Server 2008 operating systems, but also on Windows Server 2003 SP2. Right as you install Service Pack 2 on Windows 2003, the upgrade process replaces its RIS successor. For further information on how to install WDS and its possible modes (such as legacy, mixed, native mode) please check out the official Microsoft documentation.

Right now we're going to assume that you are about to set up WDS on a Windows Server 2008 operating system, and that all of the prerequisites are met. You add WDS as a new server role. Follow the instructions and once the process is done, you can fire up WDS from its MMC snap-in (located within Start -> Administrative Tools). You can now configure your WDS server.

Once again, like when working with any major roles in Windows Server operating systems, please don't forget that you need to be logged in as Enterprise Administrator. You can now configure your server. Select a remote installation folder path. This is not the place where your entire images are stored, but just the Windows PE image. Keep this is mind: you don't really need dozens of gigabytes of space on that partition.

Here comes a tricky part: if you are installing Windows Deployment Service on the same server that acts as a DHCP server within your domain, then as the setup screen suggests, you need to tick the following two check boxes during the installation steps: "Do not listen on port 67" and "Configure DHCP option to 'PXEClient'." Without these, PXE booting is not possible because the appropriate services won't respond accordingly.

Furthermore, you need to select the kind of answer policy you prefer. You should be done with the setup procedure by now. It's time to add some images and make this thing work. There are two kinds of images that are required: boot images and install images. The first ones are the so-called Windows PE images that basically prepare the client machine for the remote deployment process, while the install images are the actual images of the operating system that is going to be deployed on the machine(s).

There are various kinds of Windows PE images, but one of the most popular is the Windows Vista SP1 PE that is located on the Vista/Win2008 installation DVD. You can find both .WIM type images inside the sources folder and they are called, appropriately, boot.wim and install.wim.

Once you've added these, your Windows Deployment Service is ready to deploy Vista on client machines. You can also pick a boot program, for example the PXEboot.n12 that bypasses the "press F12" screen during deployment on clients.

There are a few key points to consider. Windows Deployment Service does not support IPv6. Multicasting is supported only if WDS is installed on a Windows Server 2008 operating system. Also, you need to use the "boot.wim" from the Server 2008 installation DVD (same location within the sources folder). Or if you have Windows Vista SP1 install media, then its version is the same as well. But the pre-SP1 Vista's Windows PE won't support multicasting appropriately. And it can lead to lots of trouble.

What exactly is multicasting and how does it affect the deployment in the case of WDS? In short, when you are working with a huge number of client computers, multicasting transmission alleviates network bottlenecks. It is basically because data is sent through the network only once, regardless of the number of clients; moreover, it also makes it possible for other clients to pause/resume transmissions or, in the case of lower-performance machines, to keep up with the pace of the remote deployment process.

The fact that multicasting is based on IGMP snooping makes it a requirement that your organization/company have multicasting-capable routers. This is technically what makes it possible to only send data to those clients that "need" (hence, request) the specific packets-from the networking point of view. Without this capability, your network is going to be overflowed with data, since the packets are assumed to be broadcast ones and sent to every machine (within the subnet, of course).

There are two things to consider in the case of multicasting transmissions. The first option is "Auto-cast" in the case of WDS remote deployment; this requires plenty of bandwidth, since it makes deployment instantaneous (it happens right away when clients need it). The second option is "Scheduled-cast;" this is more lightweight on bandwidth needs and reduces the total time of transmissions, but involves a client-wait time (manual scheduling).

There you have it; by now you should have finished setting up WDS on your server. Should you be working in a business environment where working with that many PCs isn't a necessary everyday task, you will still realize that by getting the most out of WDS, your overall job will be easier. You can maximize efficiency and productivity. Consider opting for those functions that really fit your scenario and deployment needs.

On the other hand, Windows Deployment Service is a centralized solution to the Sysprep-ing then manual cloning and deployment. Both have situations in which using one of them is more advantageous than the other. WDS also relies on certain aspects of that solution, since you need to know how to create answer files for unattended installs and how to slipstream installations, if need be.

It is our pleasure to remind you that we have already featured articles on those topics-please check out the following direct links: "Slipstreamed and Unattended Windows Installations", "Preparing Windows Images for Mass Deployment", and an article on our favorite free, third party disk imaging tool: Clonezilla.

In closing, I'd like to invite you to join our experienced community of technology professionals on all areas of IT&C starting from software and hardware up to consumer electronics at Dev Hardware Forums. Also, be sure to check out the community of our sister site at Dev Shed Forums. We are friendly and we'll do our best to help you.