• Article

The Desktop FilesRevisiting Windows Deployment Services

Wes Miller

I've spent several of my recent columns discussing deployment technologies related to Windows Vista and to the next version of Windows Server, code-named "Longhorn." The one constant in software is change, and so I have a bit of an update for you regarding Windows Deployment Services (WDS), which will ship in

Windows Server® "Longhorn." I've also accumulated quite a few questions from readers and from discussions I've participated in over the past few months, and I'll take a portion of this column to answer some of these questions related to ImageX, WDS, and Windows® PE.

New Features and Enhancements

When WDS was originally envisioned, the hope was that the functionality shipped as an add-on to Windows Server 2003 would be nearly identical to the functionality of the version that would ship later in Windows Server "Longhorn." However, the team developing WDS for Windows Server "Longhorn" has been working diligently on three key new features that are expected to be exclusive to WDS on the upcoming server platform.

These new features are multicast deployment, enhanced TFTP download performance, and Extensible Firmware Interface (EFI) network boot support for x64 systems. These features are significant and highly beneficial for WDS users and administrators, so let's take a look at each one to see what's new. An important note, however: these features are not scheduled to be included in any future version of WDS for Windows Server 2003.

Multicast

Long before I began working on the Windows team, multicast was one of the most discussed and requested features for Remote Installation Services (RIS), and even for Windows deployment in general. Customers who had used third-party deployment technologies knew what multicast deployment could do. A few scenario-specific deployment technologies within Microsoft—Automated Deployment Services (ADS) in particular—implemented multicast, but none delivered it for OEM and enterprise deployment, and it remained a frequently requested feature every time I discussed deployment with OEM or enterprise customers.

The key advantage of multicast is allowing multiple computers to receive a communication simultaneously. That is to say, the sender (the WDS server in this case) sends the information to be communicated only once. Each client must then listen to the entire communication from end to end to receive it. Since all clients are specifically listening to one network address simultaneously, the benefit is twofold: enhanced deployment speed since the network is less congested with multiple clients performing the same task; and decreased network saturation since every client is listening to the single stream.

The downside of multicast has historically been, well, the very infrastructure of multicast itself. Imagine the game of "telephone" that many of us played as children. You probably can recall the steps:

  1. You say a phrase to the person next to you.
  2. This second person hears the phrase.
  3. The second person then repeats the phrase to a third person.
  4. The cycle continues through all the people present.

Now, the inherent problem with multicast is that in order for you to tell four people the entire phrase they all have to be in the room and listen simultaneously. If a fifth person walks into the room, unless they know to listen immediately, you will have to repeat the entire phrase to them again.

Multicast works in generally the same way. You send a binary image (usually a sector-based disk image) over the wire. All clients who need to receive it generally must wait in a queue if they aren't ready immediately when the image is first being broadcast. Even more annoying, if clients lose too much data due to network problems or performance, they either need to drop out of the communication queue entirely (since they can't ensure they received the entire disk image), or the entire group has to slow down to suit the needs of the client experiencing problems. In a scenario where you are deploying hundreds of systems simultaneously, ensuring that all clients boot at the same time and that the speed deficiencies of one don't affect the others is a cause of much focus when designing a multicast system.

The WDS team has changed all that by delivering a new multicast engine that takes advantage of the file-based Windows Imaging Format (WIM) infrastructure to allow for some very unique capabilities. You can perform the same staged multicast scenarios possible with most third-party multicast software, but the multicast solution for WDS delivers much more.

First, client computers can join at any time in the transfer. The multicast broadcast is a "round robin" broadcast of file streams that will continue to broadcast until every client computer's needs have been met. Because of this, it doesn't matter when clients come online. They listen to the WDS server, and when the server has completed the image file broadcast, it starts over from the beginning. If a client misses a file, it just listens until the file comes around again (think of horses on a carousel).

Second, the protocol is completely new and features congestion control and flow control—meaning that it works well on production networks without interfering with existing network communication. A common fear of network admins—justified with some multicast solutions—is that by turning them on you flood the network with traffic when, ironically, you were actually trying to make communication more efficient.

Third, the solution was designed to be independent of WDS and Active Directory®. This means you do not need to have either Active Directory or an active WDS implementation in order to take advantage of it. ImageX multicast can be performed independently, lending itself to many more scenarios. The multicast client is a command-line application that can run within Windows Server "Longhorn" (and its associated release of Windows PE), Windows Vista™, Windows XP Service Pack 2 (SP2), or the recently released Windows Server 2003 SP2.

There are new management tasks in the WDS MMC and in the WDSUtil application to set up and configure multicast. There is also a change to the user interface of the WDS client indicating that multicast is being used.

The WDS management tools allow administrators to monitor real-time transmission progress to clients (including removing clients from a transmission). The management tools also offer full logging and reporting, meaning that administrators will now have a method to log installations—something that RIS was sorely lacking.

Multicast in WDS for Windows Server "Longhorn" is one of the more exciting announcements I've heard in a while. It's great to know that the team was able to meet this often-requested customer wish in a way that should work quite well for OEM and enterprise consumers.

Enhanced TFTP Download Performance

Trivial File Transfer Protocol (TFTP) is a key component of the Pre-boot eXecution Environment (PXE), itself the backbone of both RIS and now WDS. TFTP was chosen not because of its network efficiency or its robustness, but largely due to the fact that it is an extremely small protocol (being stateless, non-secure, and UDP-based), lending itself to encapsulation in a boot ROM, necessary for systems to PXE boot from the network.

For Windows Server "Longhorn," the TFTP Daemon (TFTPD) was completely rewritten in such a way that it made possible significant improvements in TFTP download times (a major enhancement now that all WDS deployment is based around a Windows PE boot from RAM image). This is good news for customers who have wished for better performance in downloading Windows PE from RIS or WDS on Windows Server 2003.

As the PC world begins moving away from the ubiquitous BIOS (the backbone of x86 PCs today) to the EFI, Microsoft has prepared WDS to work with newly available x64 server systems that boot using EFI, rather than BIOS. The included functionality will allow x64 client systems to PXE boot from a WDS server.

Questions

With the WDS update in hand, I would like to take the remainder of this column to answer some questions that I have either received in e-mail or seen discussed recently online, and that I think may be of general interest to my readers.

Q Is it possible to use WDS in a non-DHCP environment? My network doesn't allow DHCP or PXE traffic.

A Yes, you can conceivably use WDS in a non-DHCP environment, but the solution doesn't scale since you must create unique CD media for each installation you intend to support—each with its own unique IP address. It's probably more advisable to use DVD media for installation. If you must install via WDS without DHCP, perform the following steps:

  1. Create a WDS Discover image with a statically defined server (this is pointing to the specific WDS server you will be installing from).
  2. Allow DHCP traffic to port 4011 on this destination WDS server. Even though you will not be using DHCP, you must allow this as it is how WDS clients handshake with the server.
  3. Create unique Windows PE media with a static IP address instead of DHCP.

Note that this solution is painful because the client media must be unique to avoid IP address collisions and you must point to a specific WDS server on your network. Since PXE (itself based upon DHCP) is the backbone of WDS, you can see why WDS works much better if DHCP is allowed in your environment.

Q I want to PXE boot Windows PE 2.0 from a PXE server other than WDS. How can I do this?

A The Knowledge Base article at support.microsoft.com/kb/926172 may provide some guidance for getting Windows PE 2.0 working from a non-WDS PXE server, but note that Microsoft support for this is somewhat limited.

Q What is the BDD? Is the Windows Automated Installation Kit (WAIK) a part of it?

A The BDD (actually, the Business Desk­top Deployment Solution Ac­cel­er­ator) is a framework for guidance on how to use Windows deployment tools (such as the WAIK) in a manageable and reproducible way. The WAIK is not a part of the BDD directly, but the BDD will pull together all of the necessary tools, including the WAIK, for you to install if they have not already been installed. So while BDD doesn't technically include the WAIK, it does require the WAIK in order to work. Please visit microsoft.com/desktopdeployment for more information on the BDD.

Q Where can I get WDS for my Windows Server 2003 system?

A WDS is available as a part of the WAIK download in the WDS directory (see go.microsoft.com/fwlink/?LinkId=85377).

Q How can I configure Windows PE 2.0 to boot with a static IP address, and support DNS configuration?

A To configure a static IP, use the unattend.xml sample in Figure 1 and put it at the root of your CD, USB flash drive, or other bootable media for it to be picked up. If you want to have DNS support as well, you will also need to run the following command:

Figure 1 Figure 1 unattend.xml

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
 <settings pass="windowsPE">
  <component 
   name="Microsoft-Windows-TCPIP" 
   processorArchitecture="x86" 
   publicKeyToken="31bf3856ad364e35" 
   language="neutral" 
   versionScope="nonSxS" 
   xmlns:wcm="https://schemas.microsoft.com/WMIConfig/2002/State" 
   xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance">
   <Interfaces>
    <Interface wcm:action="add">
     <Ipv4Settings>
      <DhcpEnabled>false</DhcpEnabled>
     </Ipv4Settings>
     <UnicastIpAddresses>
      <IpAddress wcm:action="add" wcm:keyValue="1">
       192.168.0.1</IpAddress>
     </UnicastIpAddresses>
     <Identifier>Local Area Connection</Identifier>
    </Interface>
   </Interfaces>
  </component>
 </settings>
<cpi:offlineImage 
 cpi:source="wim:c:/simtest/winpe.wim#Microsoft Windows Vista PE (X86)" 
 xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>

net start "DNS Client"
netsh interface ipv4 add dnsserver "Local Area Connection" 192.168.2.10 index=1

Q Is it possible to boot Windows PE from a Fibre Channel controller?

A Yes, provided Fibre Channel HBA supports registering the boot volume via Int13 so that it appears in the BIOS as a bootable volume for Windows PE. You must also add the Fibre Channel controller's driver as you would any other out-of-the-box storage controller driver.

Q Windows PE 2.0 always boots from a RAMDisk. Some of my systems don't have enough RAM to boot that way. Can I boot Windows PE 2.0 without a RAMDisk?

A Yes, you can. Systems with less than 256MB of RAM in particular may require a non-RAMDisk implementation of Windows PE in order to boot. There is a Microsoft support article in the works that will describe how to do this. A couple of important caveats: you will not be able to swap media, as you can with a RAMDisk, and it will boot more slowly than a RAMDisk-based version of Windows PE 2.0.

Q I have tried to boot Windows PE 2004 and Windows PE 2005 (1.5 or 1.6) from media other than DVD, and copy an image (or other data) off of a DVD. I'm not booting from the DVD, just copying data from it, but it isn't working. The DVD is readable under a full installation of Windows, but under Windows PE I receive an error stating that the volume is corrupt or unreadable. Can I fix this?

A Yes, you can. By default, Windows PE 1.x doesn't have support for UDF-formatted media. DVDs are, by definition, formatted with either ISO bridge support (a dual format of ISO and UDF) or just UDF. You need to add the UDF driver to your Windows PE installation for this to work. The driver is already there; it's just not installed. To install it, do the following:

  1. In Notepad, open the txtsetup.sif file in your I386 (or MiniNT, if a hard-disk installation of Windows PE) directory.
  2. Find the section called [CdRom­Dri­vers.Load] and look for the line with the driver named cdfs.sys. Below that line, add the line udfs = udfs.sys. The entry should look similar to this:
[CdRomDrivers.Load]
cdfs = cdfs.sys
udfs = udfs.sys

3. Find the section called [Cd­Rom­Dri­vers] and look for the line with cdfs in it. Below that line, add the line udfs = "Universal Disk File System". The entry should look similar to this:

[CdRomDrivers]
cdfs = "CD-ROM File System"
udfs = "Universal Disk File System"

4. Save and close your txtsetup.sif and recreate your Windows PE image as necessary. You should now be able to read any UDF-formatted DVD media from within Windows PE.

Q I have a number of older systems, on which I am running Windows XP, that do not support ACPI. Would I be able to use Windows PE 2.0 on these systems in order to migrate them to Windows Vista or perhaps to reinstall Windows XP?

A No, you can't. Windows PE 2.0 only supports Advanced Configuration and Power Interface (ACPI)-compliant systems, and will not boot on those systems. If you need to use Windows PE on those systems, use Windows PE 1.6 or earlier.

Q I have written my own application in Visual Studio® 2005 that I would like to run on Windows PE (1.x or 2.0). Will it work?

A That depends on how your application is written. If you are using unmanaged C++, then yes, your application should work. If you are using any of the managed code languages (C# or J#, for example) or writing any managed C++ code, then it won't work. Since the Microsoft® .NET Framework (any version) is not available on Windows PE, managed code will not run.

Q I'm trying to write my own application for use on Windows PE 2.0 and I need some help. Where is the best place to look?

A I suggest that you start with the Windows PE Developer's Guide whitepaper.

Q I have booted Windows PE 2.0 from a CD several times, but the drive letter (the RAMDisk) is always X. How can I actually tell what drive letter it really booted from?

A If you look in the registry, the following key should reflect the actual drive letter that Windows PE initially booted from:

HKEY_LOCAL_MACHINE\SYSTEM\Setup\SystemPartition

If you find that this key has not been populated because a third-party shell was used within Windows PE, running the following command will update it to the correct value:

start /w wpeinit UpdateBootInfo

Q Is it possible to use ImageX and WIM files to back up my systems?

A It is theoretically possible, but I wouldn't recommend it. ImageX can't back up any locked or open files like a true backup tool can. I recommend continuing the use of a true backup utility that allows you to protect open and locked files.

Q If I capture a WIM file uncompressed, will it deploy any faster than the same volume image compressed?

A Not significantly, no. Capturing takes longer, due to compression. However the application of the image to a target system does not take significantly longer regardless of the compression type used (none, XPress, or LZX). I recommend making your compression choice based upon your actual image size needs and the amount of time you can dedicate to capturing.

Q Do I need to repartition and format the disk if I am planning to apply a WIM image to it?

A Yes, you do. In order to do a clean image of a system, you will first need to clean the volume with the diskpart tool (or delete and recreate the destination partition). Alternatively, you can format the volume completely, before applying.

Furthermore, you must remember that versions of Windows prior to Windows Vista used a different boot sector—so if you're using Windows PE 2.0 to deploy Windows Server 2003 or earlier, you need to run the following command from within Windows PE to set the boot sector to one that Windows Server 2003 and earlier can boot from before beginning Windows setup or applying a WIM of it:

bootsect /nt52 sys C: /force

Conclusion

I hope you have found the WDS update and the answers to these questions useful and of interest. I appreciate all your questions and will do my best to answer them whenever I have space in this column. Please keep them coming by sending mail to the e-mail address listed in my bio.

Windows Vista Harware Assessment

Baldwin Ng

Good news—your manager finally responds to your proposal from a month ago. Apparently, he has been seriously considering your idea of an organization-wide rollout of Windows Vista and has begun to see the benefits and cost savings of managing a single operating system. However, he is not totally convinced that it makes financial sense to replace all of the PCs for the Windows Vista installation. He wants concrete, detailed information on which PCs can migrate to Windows Vista right now and which ones could be migrated given some minor upgrades such as additional system memory and hard-disk space. And he wants an answer by end of the week. So, where do you begin? How do you get the answer in a few days when your organization does not have any sophisticated asset or network management tools? To make things worse, your predecessor did not leave you enough information about the network assets that already exist.

Microsoft has just released Windows Vista Hardware Assessment, a solution accelerator that helps you determine your organization's readiness for Windows Vista (see mi­cro­soft.com/technet/wvha). This tool quickly assesses the PCs on a network and generates detailed readiness reports of their hardware and device compatibility in a matter of hours in most midsize organizations, all without installation of any software agents on the PCs across your network.

Building upon the powerful inventory collection and reporting technologies previously developed for the Microsoft Assessment and Deployment Solution (ADS), Windows Vista Hardware Assessment creates a set of readiness reports through a three-step process:

1. Hardware Inventory

Through the use of Windows Management Instrumentation (WMI), Active Directory®, and other Windows networking protocols such as NetServerEnum, this tool discovers computers on a domain as well as workgroup computers. Once inventory is completed, all system resources and device information is stored in a SQL Server™ 2005 Express database. The current release of this tool supports network discovery of up to 5,000 machines. Future releases will likely scale to larger networks.

2. Compatibility Analysis

Using the most up-to-date device and BIOS databases from the Windows team, the tool analyzes each PC's readiness around hardware and device compatibility for Windows Vista. In addition, driver information is pulled through a regularly updated Web service so that you can get the latest information each time you run the tool.

3. Readiness Reporting

The last step is the autogeneration of a set of readiness reports in the form of Microsoft Word documents and Excel® spreadsheets. These reports provide the readiness status together with upgrade recommendations for each PC.

Windows Vista Hardware Assessment complements other Windows Vista solution accelerators including Business Desktop Deployment 2007 and Windows Vista Security Guide. For more information, take a look at Solution Accelerators Home Page.

Baldwin Ng is the Product Manager in the Microsoft Solution Accelerators Team focusing on the creation of automated software tools to help customers and consultants adopt Microsoft software in a quicker and more effective way. He can be reached at Baldwin.Ng@microsoft.com.

Wes Miller is a Development Manager at Pluck (www.pluck.com) in Austin, TX. He has worked at Winternals Software in Austin and at Microsoft as a Program Manager and Product Manager for Windows. Reach Wes at technet@getwired.com. Wes thanks Scott Dickens, the Program Manager for Windows Deployment Services at Microsoft, for assisting him with the new WDS features section.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.