The Desktop Files Advanced Functionality in WDS
For the past two installments of this column, I've been exploring Windows Deployment Services (WDS). I began by looking at the history of Pre-boot eXecution Environment (PXE)-based deployment tools from Microsoft, followed by an overview of WDS. This month I'll delve into some advanced topics—
WDSUtil (the powerful command-line utility for WDS), the WDS Image Store, WDS logging, and working with multicast functionality in WDS for Windows Server® 2008.
When Remote Installation Services (RIS) shipped in Windows® 2000 and Windows Server 2003, it was never as feature-rich as many would have liked. Three areas in particular stand out:
- Performance (more scalable deployment)
- Command-line automation
You'll see as we proceed through this month's column that with the initial release of WDS, and more specifically with WDS in Windows Server 2008, significant advances were made on each of these fronts.
I noted last month that WDS delivered a greatly improved management console. But even more important for most enterprises, WDS supplied a new command-line utility for management, WDSUtil.exe (see Figure 1). WDSUtil is installed with the WDS Optional Component on Windows Server 2003 (SP1+WDS or SP2) and with the WDS Role on Windows Server 2008.
Figure 1 Setting the architecture discovery option to yes with WDSUtil (Click the image for a larger view)
WDSUtil is an amazingly powerful utility, but it is complex. Effectively, everything you can do via the Microsoft® Management Console (MMC), and more, can be done via WDSUtil. In fact, for a great example of this that's also one of the best ways to diagnose if you're having problems, try running:
wdsutil /get-server /show:config
The results almost completely mirror what you would see in the entire WDS MMC—though WDSUtil can output it in an easily perused format you could then output to a text file.
Not enough information? Try running the following command instead, which returns even more:
wdsutil /get-server /show:all /detailed
And you can stop and restart the WDS server by running:
wdsutil /stop-server wdsutil /start-server
You'll find a command reference for WDSUtil at go.microsoft.com/fwlink/?LinkId=112194. If you prefer, you can also download a .chm version of this (along with all the WDS 2008 docs) at go.microsoft.com/fwlink/?LinkId=89381.
With RIS, there wasn't an easy way—unless you were an Active Directory® Service Interfaces guru—to find out via the command line whether a specific MAC address or GUID was associated with a Machine Account Object (MAO) in Active Directory. With WDSUtil, you can query based on either.
GUIDs can be confusing, as you can enter them in as binary strings or as a GUID string, and the only difference is the byte ordering and the absence of hyphens. MAC addresses can be entered with or without hyphens using either of the following lines of code:
wdsutil /get-device /id:01-23-45-67-89-AB wdsutil /get-device /id:0123456789AB
You can get device information by binary string using this command:
wdsutil /get device /id:ACEFA3E81F20694E953EB2DAA1E8B1B6
Or you can get device information by GUID string using this command:
wdsutil /get device /id:E8A3EFAC-201F-4E69-953-B2DAA1E8B1B6
Many of your computers are probably capable of running the 64-bit version of Windows, but some, unfortunately, don't report their architecture correctly. You can let WDS attempt to determine whether a system is x64-capable by running a small net-boot program provided as a part of WDS. As Figure 1 shows, you can do this with the following:
wdsutil /set-server /architecturediscovery:yes
In fact, the WDSUtil set-server command lets you configure a huge number of server settings. To see the possibilities, run the command:
wdsutil /set-server /?
If you have upgraded a Windows Server 2003 WDS server to Windows Server 2008, you can convert any RIPrep images to Windows Imaging Format (WIM) images by running:
Though WDSUtil can convert RIPrep images, any remaining RISetup images (traditional RIS/legacy WDS scripted installations) can't be converted.
The power of WDSUtil lies in its ability to automate repetitive tasks. The commands in Figure 2 give you an idea of the capabilities of WDSUtil. Whether you're rolling out new WDS servers, adding or modifying images across multiple servers, administering your multicast infrastructure, or specifying what network boot program to use for a specific boot client, WDSUtil provides some serious power that wasn't previously available in RIS.
Figure 2 WDSUtil commands
|/add||Adds devices, images, or image groups.|
|/approve-AutoAddDevices||Approves pending Auto-Add devices and allows you to set configuration information for them.|
|/convert-RiprepImage||Converts a legacy RIPrep image to a WIM image.|
|/copy-Image||Duplicates an image within an image store.|
|/delete-AutoAddDevices||Deletes all or specific pending Auto-Add devices.|
|/disable||Disables a WDS Server or Transport Server.|
|/disconnect-Client||Disconnects a client from a multicast transmission or namespace.|
|/enable||Enables a WDS Server or Transport Server.|
|/export-Image||As with /export in ImageX, this exports an existing image from the image store to a WIM image.|
|/get||Gets properties and attributes for a device, image, image group, WDS server, or transport server.|
|/initialize-Server||Configures a WDS Server for use after first installation.|
|/new||Creates capture or discover images, multicast transmissions, and namespaces.|
|/progress||Displays progress while a given command is being executed.|
|/reject-AutoAddDevices||Rejects all or specific pending Auto-Add devices.|
|/remove||Removes images, images groups, multicast transmissions, and namespaces.|
|/replace-Image||Replaces (overwrites) an image with a new image.|
|/set||Sets properties and attributes for a device, image, image group, WDS server, or transport server.|
|/start||Starts a WDS Server or Transport Server.|
|/stop||Stops a WDS Server or Transport Server.|
|/uninitialize-Server||Reverts the changes made to the server during server initialization (reverts it to an unconfigured state).|
|/update-ServerFiles||Updates the files in the server's REMINST share with the latest versions from the server's System32\RemInst directory.|
|/verbose||Displays verbose output while a given command is being executed.|
Last month I mentioned how the Single Instance Storage (SIS) used by RIS to store files more efficiently on disk has been abandoned in WDS. Now, all native mode (WIM) images, regardless of OS, are kept in the WDS Image Store. As I've indicated in past columns, that single instance functionality saved you space in .wim files when the volume images had related files. The WDS Image Store functions the same way. In fact, it uses WIM functionality to store images.
To work with the Image Store, you need to have at least one Image Group; WDS initialization will generally prompt you to create one. You can also create a new Image Group as you add an Install Image, and the image will be added to it (see Figure 3).
Figure 3 Creating a new Image Group (Click the image for a larger view)
So what is the Image Store? Look under your RemoteInstall directory, in the Images directory, and you'll find directories for each Image Group you created. As Figure 4 shows, there's one .wim file for each Install Image you imported into the Image Group and a single .rwm file (Resource WIM).
Figure 4 The contents of an Image Group (Click the image for a larger view)
Look carefully at the files in Figure 4. This Image Group consists of:
- install.wim (Windows Server 2008, Standard Edition)
- install-(2).wim (Windows Server 2008, Enterprise Edition)
- install-(3).wim (Windows Server 2008, Datacenter Edition)
- install-(4).wim (Windows Server 2008, Standard Edition (Server Core)
- install-(5).wim (Windows Server 2008, Enterprise Edition (Server Core)
- install-(6).wim (Windows Server 2008, Datacenter Edition (Server Core)
Now compare the sizes of those files with those from the MMC (shown in Figure 5). The size of each .wim file in Figure 4 is a fraction of the size of the Res.rwm file. Why? Well—in order to save space, the .wim files shown are simply stubs of actual files. They contain the metadata to restore the .wim file but don't actually contain the file resources. All file resources in an Image Group are stored in the .rwm file for that Image Group.
Figure 5 Images shown in Server Manager (Click the image for a larger view)
To edit an Install Image in an Image Store, you can either export the image, make your edits, and then replace the image (or import it anew), or you can interact with it by disabling the appropriate Install Image from the MMC and making your edits by mounting and modifying the .wim file.
One issue that RIS always had was image replication. When you copy SIS'd files over the wire, the SIS is lost since it's an NTFS attribute. This meant you had 40GB of RISetup and RIPrep images and you were replicating them to another server, even if the SIS Groveler had reduced them down to as little as 5GB, you were still replicating 40GB over the wire. This is not the case with the WDS Image Store. In fact, because of the architecture of the Image Store, you can save it on a Distributed File System (DFS) server and use DFS-Replication (DFS-R) to replicate it from site to site.
The specifics for this vary, depending on the version of WDS. For Windows Server 2003, see Chapter 7, "Working with Images," in the documentation downloadable at go.microsoft.com/fwlink/?LinkId=81031. For Windows Server 2008, see "Storing and Replicating Images Using DFS" at go.microsoft.com/fwlink/?LinkId=121960. Since the resources are all stored in the .rwm file, even when you copy an Image Group from one server to another, the amount of data crossing the wire is a fraction of what it would be if each entire .wim file was being transmitted (or in the old RIS SIS architecture).
So when do you create a new Image Group, and when do you use the old one? The rules are generally the same as for a .wim file. Though you could put an image of Windows XP Professional SP3 into an Image Group predominantly made up of Windows Server 2008 images, this wouldn't make much sense, as you're not saving much space. As with .wims, you'll want to generally have an Image Group for at least:
- Each specific release of Windows—where a release is both an SKU (Windows XP Professional) and a Service Pack revision (SP3).
- Windows Server 2003 and earlier: each localized language release (not Multilanguage User Interface). Prior to Windows Vista®, localized builds were entirely different binaries, so they didn't store well in a .wim file in terms of single instancing.
- Each Service Pack of each release. While you may be able to store Windows Server 2008 and Windows Vista SP1 images together, consider whether that functionally makes sense in your organization.
The Image Store, even more than SIS before it, works well to conserve space—both on disk and over the wire, and generally requires little work to keep it functioning happily.
One of the greatest weaknesses of RIS was its lack of scalability. Multicast deployment is all about rectifying that. People often think of multicast as "faster" deployment, but it isn't really about faster—it's about "more." You could deploy multiple systems via RIS. In fact, RIS could handle simultaneous deployment of about 75 systems.
But long before you approached that point, performance was impacted and each installation took progressively longer. Worse, as the number of installations increased, so did the potential for failure. At the same time, multiple installations saturated your network with Server Message Block (SMB) network traffic (so that during deployment, employees might not be able to get to critical network resources such as Microsoft Exchange Server).
Multicast is about scaling up your deployment numbers. Whether you're deploying four servers or a conference center with 100 systems, multicasting lets you complete that deployment without taking forever and without saturating the network. While you can use multicast to deploy to a single system, it isn't until you've got multiple systems listening to the transmission that the benefit of scale is realized.
In order to use multicast, you need to have routers that support multicast. Generally, this means Internet Group Management Protocol (IGMP) snooping should be enabled. You also must have Windows PE 2.1 (Windows Server 2008 RTM or Windows Vista SP1), as the version (2.0) that shipped with Windows Vista RTM is not capable of receiving a multicast transmission.
You should also ensure that if you have multiple WDS (or other multicast) servers on the same network, you specify a custom IP address range. This can be easily changed via the WDS MMC by right-clicking the server, clicking Properties, and then clicking the Network Settings tab.
When performing a multicast broadcast, the multicast server can either adjust to the speed at which the slowest client can receive, or it can regulate the speed at a higher level and drop clients that can't keep up. For reliability, WDS will run at the speed of the slowest client receiving the transmission.
If you find that transmission performance is slower than you expect, run wdsutil /Get-MulticastTransmission/Show-clients. This will reveal the master client that is throttling the transmission. You can then disconnect that client, and it will revert to using SMB instead of multicast. For an example script that auto disconnects slow clients, go to go.microsoft.com/fwlink/?LinkId=121961.
To create a multicast transmission, you can either right-click an Install Image and select Create Multicast Transmission, or you can right-click Multicast Transmissions in the WDS console and select Create Multicast Transmission. As you create the multicast transmission, you can create either an Auto-Cast or Scheduled-Cast. Auto-Cast is useful when you have several clients coming online regularly, all needing the exact same image; new clients will be added automatically to the ongoing transmission that was initiated for the very first client requesting an install image. Scheduled-Cast lets you set a group size that, if reached, will cause a transmission to begin.
You can also set the transmission to start at a specified time. Once clients are utilizing the multicast transmission, you can view them by clicking on the image name. In the right-hand pane, you will see specifics about the clients connected to the transmission.
Generally, your end users will use multicast from the WDS Setup client. There is, however, a command-line utility, named WDSMCast, that is shipped in the Windows Server 2008 Windows Automated Installation Kit (WAIK) and lets you request a .wim file via a multicast transmission from WDS. The .wim file must be transferred in its entirety and applied to the client—so you will want to ensure adequate disk space for the image to be stored and applied. Next month, I'll discuss how you can integrate WDSMCast into your own custom deployment process.
WDS is capable of performing considerable logging and tracing, though much of this is disabled by default to save space. There are two types of event logging—when a client writes to the Windows event log and writing to trace logs for other aspects of WDS.
In Windows Server 2008, however, WDS does perform quite a bit of logging by default. These logs are available under Administrative Tools | Event Viewer. The WDS logs are visible in the Event Viewer under Applications and Services Logs | Microsoft | Windows | Deployment-Services-Diagnostics. Conveniently, these are the same logs that are visible when you view the WDS role in the MMC (see Figure 6).
Figure 6 Viewing WDS events in Server Manager (Click the image for a larger view)
WDS client logging (visible in the event logs in Figure 6) can be started by running WDSUtil with the following arguments:
wdsutil /wdsclientlogging /enabled:yes /logginglevel:info
You can enable trace logging on several different subcomponents of WDS as well. To configure tracing, set a DWORD registry value accordingly under the registry key(s), shown in Figure 7. All trace logs are stored under \Windows\tracing. You will then need to restart the appropriate component for logging to begin.
Figure 7 Setting up trace logging
|WDS Component||Registry Key||Registry Value||Log Name|
WDS also has performance counters (described at go.microsoft.com/fwlink/?LinkId=121962) you can monitor in the event of system performance problems (or to carry out system performance analyses ahead of time). As noted earlier, you can get more detailed information if you encounter issues by using the /detailed, /verbose, or /progress switches with WDSUtil.
If you are having problems with WDS clients connecting or interacting with a WDS server, Microsoft Network Monitor (Netmon) is an excellent tool for debugging the issues. Network Monitor is available for download at go.microsoft.com/fwlink/?LinkId=121491.
I have been seeing a couple of issues that are worth mentioning. The first is memory—remember that at its core, WDS is based on Windows PE 2.x. This means that WDS clients need at least 384MB of RAM—and realistically you should ensure 512MB for optimal performance. Remember also that Windows PE 2.x cannot boot on non-Advanced Configuration and Power Interface (ACPI) systems—and this doesn't always mean old hardware. There are reports of relatively recent systems that don't support ACPI.
Note that those systems also won't support Windows Vista or Windows Server 2008. For systems that don't support ACPI, you'll need to either keep a Windows Server 2003 or earlier WDS or RIS Server available with those clients prestaged to it, or install Windows via a non-PXE mechanism.
Finally, bear in mind that if you want to boot Windows PE 1.x from your server, you will need to also use a Windows Server 2003 or earlier WDS or RIS server, as WDS in Windows Server 2008 cannot boot a Windows PE 1.x image (RAMDisk or PXE).
So far I've delved into WDS history, fundamentals, and advanced topics. Next month I'll take a look at some custom WDS scenarios—specifically, how you can interact with WDS and tweak it to perform the tasks you need it to, often without utilizing the existing WDS/setup experience.
Wes Miller 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.