Geek of All Trades

A Case for a Layered Approach to Deploying Windows Desktops

Greg Shields

Go delete every one of your Windows desktop images. Right now.

You know the ones I’m talking about: The dozens of specialized system images you’ve collected over the years. The “standard” ones, the “golden” ones, the “ones with special drivers,” even those one-off images that go with the specific application only the Sales team needs. Remove them from your network and empty the Recycle Bin. Come back when you’re done.

Why such a drastic suggestion? Simply put, the old monolithic approach to desktop deployment just isn’t practical these days. Creating dozens of individual images for each type of desktop hardware or software set creates a nightmare of customized images that are time-consuming to update, difficult to manage and clog up space on your file servers.

What’s needed to replace those images is a layered approach to deploying your Windows desktops, one with a single Windows image as its core. By taking advantage of multiple services you already have in place today, even the smallest IT environment can use this approach to create a powerful and highly-extensible infrastructure for quickly deploying new operating systems to users. If you’re considering making the jump from Windows XP or Windows Vista to Windows 7, now is the time to start rethinking the very basics of desktop deployment. With a little effort, you’ll be surprised at how automated your final solution can be.

Deploying Windows and Peeling Onions

But before we get into the details, think for a minute about how you administer your desktops today. Imagining for just a minute that your average Windows desktop is a lot like the layers of an onion. At its core is an operating system with default and out-of-the-box settings. Installed atop that core are the necessary drivers as well as required OS updates and patches. Next up are the user’s needed applications, along with individual configuration settings that define your custom desktop environment and modify application settings. Finally, the top layer includes the user’s specific personality data such as bookmarks, desktop shortcuts and printers.

All of these individual layers combine to create what ultimately becomes the user’s working environment. If you peel back each layer, you eventually make your way back to the core operating system itself.

This makes a lot of sense—right up to the point that you start to work with it. Traditionally, admins have attempted to shortcut the deployment process by creating monolithic desktop images that have many configurations already baked in. Perhaps one image has Microsoft Office installed. Another has been preconfigured with drivers for a particular type of desktop. A third may have desktop environment customizations set right on the image.

This shortcutting process at first blush seems useful because it reduces the count of layers in that desktop onion. But it fails at the very moment when image A can’t be installed to desktop B.

You know the situation: Your small environment has been using desktops from a particular vendor for years, and the hardware configuration has remained blissfully unchanged for an extended period of time. Then one day a new shipment arrives and you find a small change to one piece of hardware. Perhaps it’s a different NIC or a different sound card driver.

While this small change might be insignificant, the new driver means you must now support a completely separate monolithic image for just this batch of desktops. Further, having to deal with two images instead of just one requires adding new steps to the process to figure out which image works with which hardware. Suddenly, your “shortcut” process got a lot less simple.

Giving Each Layer its Due

It’s just such a situation that eventually forces many IT organizations into ever-increasing numbers of desktop images. And it’s this situation—and others like it—that drive us geeks of all trades to rethink how we do desktop deployment.

Figure 1 shows a representation of how the layers of that desktop deployment onion might look. Every deployment starts with planning. This administrative activity ensures that the right people get the right desktop. In the case of OS upgrades with their often-expanded requirements for hardware, planning is even more important, as you’ll have to consider the drivers, updates, applications, configuration changes and, ultimately, user personality information that combine to create a deployable desktop.

Figure 1 Layers of "Desktop Deployment Onion"

Microsoft recognizes that each of these layers exists as a separate function in the overall desktop deployment activity, and thus created services that let you manage each layer separately but as part of the greater whole. Each service costs you nothing; your challenge is in assembling them correctly. To that end, let’s take a quick look at each of the layers from a high-level perspective.

Planning and Analysis

Two words describe the Microsoft Assessment and Planning (MAP) Toolkit—“extremely cool.” Imagine a solution you can download and point toward every desktop in your domain or workgroup to gather information about hardware, software and drivers. Such a tool could quickly generate an inventory of everything about your computing environment: Which computers have the right hardware for a Windows 7 upgrade? Which ones may have software incompatibilities? Which devices need drivers that aren’t natively available on the Windows 7 DVD and must be located elsewhere? The same solution could whip up its results into a preconfigured spreadsheet for analysis (see Figure 2), or even build an entire project plan with its data for a hand-off to project managers. That solution is the MAP Toolkit.

Figure 2 Spreadsheet for Analysis

Core Operating System and Drivers

These two layers are functionally separate but can be managed through a set of tools that I’ll talk more about below. Two in particular are useful in the actual deployment of core desktops. The first is Microsoft’s Windows Automated Installation Toolkit (WAIK) that, among other things, installs the Windows System Image Manager (WSIM), a product that allows customization of the default Windows installation at the point of installation. It ensures that very basic items like partition configurations and product keys are correctly set as a new Windows instance is installed. The second tool is Windows Deployment Services (WDS). This Windows Server 2008 role is a primary solution for actually deploying images to desktops. Among a suite of new features in Windows Server 2008 R2, WDS now provides a convenient GUI for automatically injecting the correct drivers into a core OS image as it’s installed. I’ll talk more about WDS shortly.

OS Updates

Updating desktop images with patches can be a regular nightmare if your process involves downloading the image to a sample machine, completing the updates and then uploading the new image back to your file server. Repeat this process too many times and you’ll see just how time-consuming multiple-image management can be. However, it’s likely that you already have an update management solution in place with Windows Server Update Services (WSUS). With the right kinds of automation, you can instruct your freshly installed desktops to update themselves from WSUS immediately after installation. The result is a much-reduced need to manage patch levels on core OS images.


Application deployment solutions like System Center Configuration Manager (ConfigMgr) and System Center Essentials (SCE) provide a service-oriented location for the deployment of applications to desktops. But these solutions arrive at added cost, which isn’t always an option with many small environments. Microsoft has long supported application installations through Group Policy Software Installation (GPSI). Though lacking in rich reporting capabilities, GPSI is perfect for small-scale build environments. Employing the same techniques used in packaging software for ConfigMgr or SCE, GPSI can deploy applications to freshly built desktops with little work required outside a few desktop reboots.

Configuration Changes

Even today, nearly 10 years after the introduction of Group Policy, I frequently find myself amazed at how few environments use it. Augmented in Windows Server 2008 with Group Policy Preferences, the combination of these two services enables virtually every facet of your desktop environment to be centrally controlled. Traditional Group Policy is perfect for managing all types of Windows-specific settings, locking down your desktops to a configuration that you control. Group Policy Preferences fill in the gaps by enabling customizable control over application settings, the user’s workspace and most everything else in between.


The last part of the process is the transfer of personality information from one computer to another. The roaming profiles feature has historically provided one mechanism for the transfer of this information; however, that feature’s use has been limited by its complexity. Microsoft also provides the User State Migration Toolkit (USMT), as well as other technologies in the Microsoft Deployment Toolkit (MDT) for the one-time transfer of personality information from old computer to new.

Core = Default, Core = Basic

While my limited column space prevents exploration of every facet of integrating the seven layers, two in particular warrant extra discussion: those involved with the installation of the core OS and its drivers. These are important because this entire discussion on layering is irrelevant without its key selling point: the single desktop image that’s installable to every piece of hardware.

Critical to recognize in the layering approach is that the OS at its core can be as close to the out-of-the-box defaults as you’re willing to make it. With a core OS that remains relatively unchanged from the default installation, layering other configurations over the top allows you fine-grained control of each step in the process. Getting started requires a service that actually converts the default image into a working installation. That service is WDS.

Installing WDS is a simple task within Server Manager. There, choose to install the Windows Deployment Services role with both its Deployment Server and Transport Server role services. Once installed, WDS must be initially configured by right-clicking the server name in Server Manager and choosing Configure Server. The resulting wizard provides an opportunity to configure the path where images will be stored, the initial settings for Preboot eXecution Environment (PXE) response, and a checkbox for adding your first set of images to the server.

Start by creating a new Image Group and adding images from a copy of the Windows 7 Ultimate DVD media. Four images are available by default on that media for the Home Premium, Professional, Ultimate and Home Basic Editions of Windows 7. Once uploaded, these images can be immediately used to install the default implementation of any of those four editions onto a desktop.

You’ll find all of the details associated with the deployment and management of images in Microsoft’s Windows Deployment Services for Windows Server 2008 R2 ( Two features deserve special attention, because they enable some very key customizations that you’ll want for your desktops.

The first relates to the limited set of special settings that are configured at the time of installation. These can be disk and volume settings, the acceptance of the EULA, configuration of product keys and system locale information, among others. One tool to pre-configure these and other settings right into your deployed image is the WAIK’s WSIM tool, shown in Figure 3. These settings must be configured at the time of installation, generally because they either can’t be changed later or are very difficult to configure through other means.

Figure 3 Windows System Image Manager

Saving these initial parameters into WSIM results in an .XML file that’s used to modify the default installation within WDS. Back in WDS, right-click and view the properties of the image you wish to modify. Under the General tab, check the “Allow image to install in unattended mode” box and click the button marked Select File. Enter your .XML file’s name and path into the resulting window to attach WSIM’s modifications to your default image.

This only brushes the surface of the at-installation customizations that are possible using WSIM. While WSIM can be a bit challenging for new users, an excellent explanation of its most basic uses is found on the WAIK for Windows 7 Readme at StepByStep_ITPro.

A new capability available in the Windows Server 2008 R2 version of WDS is the automatic injection of non-default drivers into an installation when requested by Plug and Play. This feature makes the WDS’s default images even more useful by enabling the creation of a catalog of non-default drivers that independently layer over the top of the default image.

Figure 4 shows an example of how a set of ATI Catalyst drivers for Windows 7 can be added as a Driver Group. In this case, that group includes the nine individual drivers that were collected as part of a package downloaded from the vendor’s Web site. Drivers for both the x64 and x86 platforms are represented, along with drivers for display and other functions required by the hardware.

Figure 4 Driver Group Example

The power of WDS’s driver deployment capabilities results from its integration with Microsoft’s Plug and Play service, which is designed to identify the hardware on a system and automatically request the appropriate driver when necessary. This occurs automatically during an installation, where many drivers are already available on the Windows DVD media. Others, however, must be downloaded from third-party Web sites and made available. WDS’s deployment engine provides the location where needed drivers can be found and automatically injected into the installation as needed.

Updates, Apps, Config Changes and Personality

While the information here is far from comprehensive, it helps to validate my case for a layered approach to desktop deployment. Getting through this process completes the installation of your core OS and prepares you for update and application installation, configuration changes through Group Policy, and eventually the migration of user personality data from the old computer to the new. Leveraging Microsoft’s other solutions for automating the completion of these tasks—WSUS, GPSI, GPs and GPPs, and USMT—gives you even more flexibility in customizing your desktop images on the fly.


Greg Shields, MVP, is a partner at Concentrated Technology. Get more of Shields’ Jack-of-all-Trades tips and tricks at


Geek of All Trades: Microsoft's New Certifications: What They Are, Why They Matter

Geek of All Trades: Setting Permissions from the Command Line

Geek of All Trades: The Benefits of Big, Cheap Disks