The Desktop Files Customizing Windows Deployment Services

Wes Miller

Contents

Replacing What You've Got
Looking at the Stack
Network Boot Program
WDS PXE Provider
TFTP Daemon
Boot Configuration Data Store
Windows PE
Transport Server
Custom Multicast
Wrapping Up

For three months I've been delving into Windows Deployment Services (WDS)—its origins, followed by an overview, followed by a closer look at some advanced topics such as WDSUtil and multicasting. In this final installment of the series, we're going to take a look at where and how you can customize and configure WDS to meet the needs of your organization. Most Microsoft tools are designed with some amount of configurability. But it's when the rubber hits the road that you actually find out whether the tools will meet your needs or, more often, that they require some tweaking to work in your scenarios.

Replacing What You've Got

A question I've often been asked by readers lately is, "I've got x (an existing deployment technology)—will WDS work for me, and does it have parity feature-wise with x?" With the deprecation of Automated Deployment Services (ADS), one area of particular interest is, "How can I perform high-volume rapid deployment or reprovisioning of servers—can WDS do that for me?"

While WDS wasn't designed as a 1:1 replacement for ADS, and in fact is missing a few key components to be considered a real substitute, with a bit of work you can make WDS stand in for ADS. Similarly, if some aspect of WDS isn't working for you as is, you'll find that many of its components can be replaced—with varying degrees of complexity and engineering. Let's take a look at deployment via WDS and examine the pieces you might want to customize and how you could do so.

Looking at the Stack

Figure 1 shows the components in the WDS deployment process. Each of these steps can be customized to a degree. I've color coded each step to reflect what I believe to be the complexity (generally the development skills) involved in replacing or customizing it. The darker the blue, the harder it will likely be to customize that step.

Figure 1 Complexity of customizing WDS

How difficult it is to customize each step really, of course, depends on both the skills of your team (development or scripting) and your understanding of WDS, Windows Imaging Format (WIM), Active Directory, or any other technologies you want to integrate, such as SQL or ADSI. Let's examine each of these steps; think about the ways in which you might want to customize them and the methods you would use.

Network Boot Program

It's doubtful you would need to create a custom Network Boot Program (NBP) to replace those provided with WDS, but it is possible. WDS includes NBPs for use with headless systems (generally servers) or systems that you may or may not prompt for F12, and so on. These NBPs can either be prestaged into Active Directory using WDSUtil, or you can replace Startrom.com with the NBP you want to use for all systems that aren't pre-staged (for example, if all of your systems are headless, or you never want to prompt F12).

Unfortunately, there isn't much documentation available on creating your own NBP (see msdn.microsoft.com/library/bb870970.aspx for some information). An NBP is a very small 16-bit executable with severe limitations and requires specific programming skills. I generally recommend using the existing NBPs provided with WDS unless you are trying to meet a very specific requirement and you have a development team with the appropriate skills.

WDS PXE Provider

With Remote Installation Services (RIS), common feedback we received from customers was the desire to use a data store other than Active Directory for client system information—most often, SQL Server. With WDS, the design includes a pluggable infrastructure for Pre-Boot eXecution Environment (PXE) providers. This means that with development work, you could use another backing store besides Active Directory for PXE information.

WDS comes with its own provider that uses Active Directory; System Center Configuration Manager (SCCM) now hooks in to WDS as well and implements a provider of its own. Documentation on writing your own provider is very scarce and there isn't much sample code available (though the Windows SDK provides some documentation and a couple of samples), so the task isn't for the meek. Unless you've got very specific requirements for this aspect of the boot process, I'd again recommend not attempting a custom PXE provider.

TFTP Daemon

Sometimes customers have invested in their own Trivial File Transfer Protocol Daemon (TFTPD) before WDS comes along. Since PXE servers don't play well together, this often means settling on only one.

In my experience, this usually means taking an existing, typically Linux-based TFTPD and coaxing it into booting other OSs. With the original infrastructure RIS used you couldn't do this. But when RAMDisk booting became the norm, you could, and it is still possible to do this using WDS-based boot images.

One thing to bear in mind is that you are wandering into a technically unsupported area as far as Microsoft is concerned, and one that can most certainly cause problems that are hard to diagnose. Moreover, with the enhanced TFTPD in WDS, you may well be walking away from better performance. Ideally, I recommend using the existing WDS TFTPD and trying to use PXE timeouts, prestaging, and/or network edges to define which clients boot from which PXE server instead of trying to bend an existing server to fit.

Boot Configuration Data Store

With RIS, it was never possible at the boot level to specify what should be booted—you always had to go through the OS Chooser and select an option (whether setup, Windows PE (Windows Preinstallation Environment), or something else entirely). WDS, since it uses a full loader for network booting, also supports customizization of the Boot Configuration Data (BCD) store served up to clients. The default BCD for each architecture lives under RemoteInstall\Boot\<arch>\Default.bcd, where <arch> is the specific architecture of the system being booted.

You can customize this BCD for each client, and the client will use it for booting. You could, for example, set up one BCD entry to start setup, another for running Windows Recovery Environment (WinRE), and yet another for running a memory test—or you could have a fully automated setup entry be the default and a manual (or custom setup experience) be a user-selectable option. (For more information, go to "How to Modify the BCD Store Using Bcdedit" at go.microsoft.com/fwlink/?LinkId=115267.)

Of course, the majority of WDS's heavy lifting occurs in Windows PE—so tweaking Windows PE to meet your needs can be a critical area of focus for a custom experience. WDS, by default, provides a very standard template for setup, which includes the full setup experience. Sometimes your deployment needs may mean this won't work for you. In that case, you can create your own Windows PE boot image. Let's start at the beginning.

In addition to using the BCD to indicate which image to use, you can also specify the image by customizing the machine account object (MAO) for a computer in Active Directory. In RIS, a specific MAO attribute stored each item (which Startrom and Unattend—SIF—file to use). With WDS, these are stored as name-value pairs under the entry netBootMirrorDataFile. For example, the boot image and the Unattend file to be used by a given computer are stored in this entry. The form of the entries is as a semicolon-delimited list of name-value pairs. The entries to modify the boot image and the Unattend file are BootImage and UnattendFilePath, respectively.

Of course, you may find that you want to drop the existing setup experience completely and just build your own. Perhaps you need more configurability, more automation, or a build automated by SQL Server. You might want do as some customers did with RIS and Windows PE early on and build your own front end for setup. The key tasks you need to accomplish regardless of the setup experience you write are:

• Finding out any per-machine or per-user information. This information may be obtained from user input or from SQL Server or from a text file, for example.
• Copying and applying a setup image to the client system. This task can be accomplished using setup directly, using ImageX to apply an image from a network share, or via multicast (simply copy the image and apply it via ImageX).
• Provide an Unattend file (such as Unattend.xml or sysprep.inf, depending on the version of Windows being deployed) for setup to complete.
• Automate any post-setup migration steps that you want to perform (or any steps to apply roles in the case of Windows Server 2008).

ADS initiated the concept of task sequences that allows repeatable steps to be assigned to one or more computers. Since ADS was not designed or supported for use with Windows XP, you couldn't use it to deploy the OS. But ADS task sequences are really just structured scripts, and you can perform the same steps using a custom setup process.

I've been a fan of Microsoft SQL Server for quite some time (since the SQL Server 6.5 release), so my instinct is to build such a structure using SQL. Of course, you need to add in the SQL functionality to your build of Windows PE to do so. On top of that, you could either write your own GUI—an HTML application (HTA) or compiled executable—or use Windows Script Host (WSH) to perform a minimalist command-line-only setup experience. HTA or WSH would also need to be added to Windows PE in order to utilize them.

The complexity in designing your own setup experience completely depends on your skills and your imagination. I've seen quite elegant systems defined using only SQL and WSH or HTA—which are relatively easy skills for someone to pick up. It's very important, however, to keep in mind the constraints I have mentioned in previous columns:

• Windows PE features no Windows on Windows (WOW) subsystem, so you need to compile once for each architecture you intend to support.
• You cannot use Visual Basic 6.0 if you need to deploy via x64 or IA64 Windows PE.
• You can use Visual Studio 2005 or 2008 to build applications, but you must build an unmanaged Visual C++ application, as there is no Microsoft .NET Framework—any version—supported on Windows PE.
• Without a .NET Framework, you also are unable to use Windows PowerShell for automation.

You can, of course, use a third-party imaging utility via WDS as well, if you're willing to write your own setup experience. While I think that the WIM format and ImageX can meet most deployment scenarios, there may be certain requirements your existing imaging tool meets for you.

Similarly, certain scenarios may require custom partitioning—you may be deploying Windows Vista with BitLocker, or you're building Windows XP systems and storing profile data on a second volume, or perhaps you're deploying a Windows Server system and want to create a separate volume on the same disk for logging. Any of these requires automation of DiskPart, which, as in previous versions, can be done by feeding a script (any file format) to DiskPart that contains the commands you want to execute and ends with exit—to end DiskPart.

Creating your own setup experience isn't for the faint of heart, as you are basically rebuilding the setup executable (or at least mirroring its functionality), and there can be quite a bit to design and build. But it comes down to how much functionality you want to build into it by default and what you are building it in (HTA or WSH or a compiled programming language).

Transport Server

If you aren't using most of WDS's in-box functionality (such as Active Directory) or are engineering your own complete custom solution, Transport server may meet your needs and not bring requirements you don't want. The table in Figure 2 (reproduced from "Using Transport Server" at go.microsoft.com/fwlink/?LinkID=115298) describes what is included as a part of the WDS Transport server role.

Figure 2 Deployment Server vs. Transport Server

When I say that Transport server is a complicated item to implement, it isn't the role itself that's difficult; that, of course, is easily deployed (see Figure 3). It is the custom setup implementation around Transport server that requires work. Using the Transport server role effectively removes most of the ease of use built into WDS as a role.

Figure 3 Transport Server may be useful for custom deployment scenarios (Click the image for a larger view)

Custom Multicast

Whether or not you are using the Transport server role—but especially if you are—there is a good case to be made for using multicast if you are doing multi-system deployment. ADS featured a very powerful multicast feature, which you can duplicate using WDS with multicast. WDS features multicast on its own, but if you are building your own custom solution, you can leverage multicast using WDSMCast, as I mentioned last month (see Figure 4). Remember that you need to transfer the image file(s) to be deployed, and then they must be applied. Generally this means you need enough local disk space for the image to be stored and then applied.

Figure 4 Running WDSMCast (Click the image for a larger view)

Wrapping Up

WDS delivers quite a bit of power on its own—most likely enough for many organizations to meet their needs. But if you're looking to build your own solution that pushes beyond the boundaries of WDS, you can certainly do so—you're limited only by your imagination, your schedule, and your skills.

Wes Miller is a Senior Technical Product Manager at CoreTrace (CoreTrace.com) in Austin, Texas. Previously, he worked at Winternals Software and as a Program Manager at Microsoft. Wes can be reached at technet@getwired.com.