Deploying Vista – Part 14: Understanding Windows Deployment Services

If you missed the previous articles in this series, please read:

In the previous thirteen articles of this series we have learned about the various components of the Windows Automated Installation Kit (Windows AIK) and how they can be used together to create customized solutions for unattended deployment of Windows Vista SP1 Enterprise edition in small, mid-sized, and large enterprise environments. The tools we have examined in these articles have included the System Preparation Tool (Sysprep), Windows System Image Manager (Windows SIM), the Windows Preinstallation Environment (Windows PE), ImageX, and a few other tools that are included in the Windows AIK. The reasons we’ve examined these different tools in depth are twofold:

  1. To understand the deployment process by looking at how these tools interact with the three phases and seven configuration passes of the Windows Setup process.
  2. To learn how organizations can create their own customized deployment solution using these tools in a way that can best suit their business needs.

But while the Windows AIK and its tools can be used to a wide variety of create custom automated deployment solutions for deploying Windows Vista, these solutions have no central management capability, which makes them hard to scale for large deployments. Imagine if you had dozens of images and dozens of different answer files to work with – how would you keep track of everything?

What you need for larger deployments is a centralized, server-based deployment solution, and that’s exactly what Windows Deployment Services (Windows DS) provides. Windows DS is a server-based solution for deploying Windows images onto bare-metal systems over a network, and it has the kind of power, flexibility, and scalability that make it particularly useful for large-scale deployments. Windows DS is in fact the successor to Remote Installation Services (RIS), a server-based deployment solution that was first included in Windows 2000 Server. In this article and the next several articles of this series, we’re going to look at how Windows DS works, its features and capabilities, how to install and configure it, and how to use Windows DS to perform unattended deployments of Windows Vista.

Note:
Although Windows DS is available for the Windows Server 2003 platform as part of Service Pack 2, this series of articles focuses on using the Windows Server 2008 version of Windows DS.

Overview of Windows DS

Windows DS is a Windows Server 2008 role that can be used for creating custom, sever-based solutions for deploying Windows Vista, Windows Server 2008, and (if configured appropriately) earlier versions of Microsoft Windows including Windows XP and Windows Server 2003. Windows DS can be used create and manage Windows images (.wim files) that can be used for booting and installing Windows onto bare-metal systems. If destination computers support the Pre-Boot Execution (PXE) environment, then you can simply turn on a destination computer and it will then automatically find a Windows DS server, download the necessary files, and perform an unattended install. And if you have older computers that don’t support PXE booting, you can use Windows DS to create remote client boot disks that can kick start the installation process on the destination computers.

New Features of Windows DS in Windows Server 2008

We mentioned that Windows DS is simply the newest evolutionary version of RIS and that an earlier version of Windows DS is available for Window Server 2003. What the new version of Windows DS in Windows Server 2008 brings to the table are as follows:

  • Support for the Windows imaging (WIM) format.

  • An improved management interface.

  • WDSUTIL.EXE, a new scriptable command-line tool.

  • Networking improvements to make large-scale deployments more bandwidth-efficient.

Windows DS Requirements

Before you implement Windows DS on your network as a deployment solution, you need to be aware of its requirements. Windows DS can be implemented in two different ways:

  • The default implementation, which requires an Active Directory environment that includes at least one domain controller, DNS server, and DHCP server. In a default implementation of Windows DS, you can either install Windows DS on a separate member server that belongs to your domain or you can install it on a domain controller. The preferred method is to install Windows DS on a member server that is not running the DHCP Server role, and the walkthroughs in future articles of this series will use this scenario.

  • A custom implementation, which can be implemented in either domain or workgroup environments. This scenario is beyond the scope of this present series of articles here on WindowsNetworking.com

Windows DS Components

Windows DS is implemented as a server role on Windows Server 2008 and consists of three types of components:

  • Server components

  • Client components

  • Management components

  • The server components of Windows DS are located on the member server running the Windows DS role and consist of the following:
  • Image repository – This is used for storing boot images, install images, and other types of files that may be needed when deploying Vista onto destination computers.

  • PXE Server – A service that works together with a DHCP server and enables destination computers that have no operating system installed to boot remotely and begin the installation process.

  • TFTP Server – A service that works together with the PXE Server to allow destination computers that have no operating system installed to download the Windows DS Client software so that an operating system can be downloaded and installed.

  • Networking layer – Additional components that support multicasting of Windows image files and other features.

Figure 1 shows the server components of a Windows DS server and how they work together to make remote installation of Windows onto bare-metal systems possible.


Figure 1: Server components of Windows DS

The client components of Windows DS include the Windows DS client, which can be deployed either automatically over the network using the PXE and TFTP Server components or can be distributed manually on removable media for destination computers that do not support remote PXE booting. The Windows DS client displays a menu that can the remote user can use to select which Windows operating system image he wants to install on his computer, and once the user makes his selection the Windows DS client then requests the appropriate Windows image from the image repository on the Windows DS server, downloads this image to the destination computer, and launches Windows Setup in order to install the image on the destination computer.

The management components of Windows DS include the following:

  • The Windows Deployment Services MMC console, which can be started from Administrative Tools on the Start menu.

  • A command-line tool named WDSUTIL that can be used to perform all the tasks that the MMC console can be used for and more, and which can also be used to script Windows DS configuration and management tasks.

  • The underlying Windows DS application programming interfaces (APIs) which can be used to build customized deployment solutions using Windows DS. These APIs are described in detail in the MSDN Library at Windows Deployment Services.

Figure 1 shows the management components of a Windows DS server and how they integrated with the Active Directory environment you need to use Windows DS in its default implementation scenario.


Figure 2: Management components of Windows DS

Conclusion

This article has looked at the rationale behind why Windows DS is needed and examined the different features and components of Windows DS. In the next article, we’ll look at how to implement Windows DS within an Active Directory environment.

If you missed the previous articles in this series, please read:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top