Using Windows Deployment Services

A powerful tool for deploying Windows Vista and Windows Server 2008 in mid- and large-sized organizations is Windows Deployment Services, an updated and redesigned version of the Remote Installation Services (RIS) feature found in Windows Server 2003 and Windows 2000 Server. Windows Deployment Services enables enterprises to rapidly deploy Windows operating systems using network-based installation that doesn’t require you to be present at each target computer or to install directly from DVD media. Windows Deployment Services has three types of components:

• Server components These include a Preboot Execution Environment (PXE) server and Trivial File Transfer Protocol (TFTP) server to enable network booting of clients so that they can load and install an operating system on a machine. Other server components include a shared folder and image repository containing boot images, your installation images, and various files you need to support network boots.

• Client components These include a GUI that runs within the Windows Pre-Installation Environment (Windows PE) and communicates with the server components to select and install an operating system image on a machine.

• Management components These include various tools you use to manage your Windows Deployment Services server, operating system images, and client computer accounts.

The first release of Windows Deployment Services was the Windows Deployment Services update for Windows Server 2003. This version of Windows Deployment Services is included in both the Windows AIK and in Service Pack 2 for Windows Server 2003. It has a number of enhancements to the original RIS feature set, including the following:

• A new Windows Deployment Services MMC snap-in and the wdsutil.exe command-line tool

• Native support for Windows PE as a boot operating system and for the new Windows Imaging (WIM) file format used by Windows Vista and Windows Server 2008

• An extensible PXE server component, plus a new client menu for selecting boot operating systems

The upcoming Windows Server 2008 release of Windows Deployment Services will include several additional enhancements, including multicast deployment, TFTP windowing, and EFI x64 network boot support. Let’s look briefly at each of these improvements in turn.

Multicast Deployment

Today organizations can use the Windows Deployment Services update for Windows Server 2003 to deploy Windows Vista to client machines on your network. On a Gigabit Ethernet network, this scenario scales well up to about 75 client machines, but not much further because of the large size of the images and because unicast transmission is used to transfer these images over the network. You can get around this limit by batching your client machines into bunches of 75. But what if you have a lab environment where you have a lot of clients that need to receive images concurrently and only a limited amount of time available for imaging all of them? Or what if your corporate environment requires that images be installed on demand while not slowing down other network functions on your production network because of excessive bandwidth usage by image transfers?

Multicasting would be a big plus in these scenarios, and some third-party deployment products have supported multicast deployment where you configure your image for multicast, stage a bunch of clients, click a button, and your deployment kicks off. Well, the enhanced Windows Deployment Services in Windows Server 2008 can do this and more. Imagine an always-on deployment solution where a client can request an image at any time to trigger a new multicast deployment. Or imagine an always-on solution where a client can join an existing multicast deployment in midstream and still receive the entire image instead of just the last part of it. Well, you’ve just imagined Windows Deployment Services in Windows Server 2008! In fact, here are some things you can do using the Windows Deployment Server role in Windows Server 2008 (and most of these features are supported now in Beta 3):

• Support for multicast deployment of both Windows Server 2008 and Windows Vista (with Service Pack 1, actually-plus, don’t forget your routers have to be multicast-enabled as well).

• Support for both automatic (AutoCast) multicast deployment and manually initiated (ScheduledCast) multicast deployment.

• Support for both Windows PE–based multicast deployment and ImageX multicast deployment, and without the need of even having Active Directory deployed on your network.

• Real-time progress monitoring of multicast transmission using either the Windows Deployment Services snap-in or the wdsutil.exe command-line tool.

• Logging of every installation stage to the application logs on your Windows Deployment Server using the Windows infrastructure. This means you can now track the progress of your installations and gather metrics for later analysis.

• A new client UI page that indicates multicast transmission and new management features in the Windows Deployment Services snap-in and the wdsutil.exe command-line tool.

This is really good news for organizations planning to use Windows Deployment Services to undertake large deployments of Windows Vista clients and Windows Server 2008 servers. Let’s hear more about multicast deployment from one of our experts at Microsoft:

From the Experts: Using Custom Network Profiles with WDS Multicast

The multicast feature set of Windows Deployment Services (WDS) supports the notion of network profiles, which are groups of parameters that dictate the low-level performance and functionality of the underlying transport protocol. WDS ships with three standard profiles, optimized for particular network bandwidth configurations: 10 Mb, 100 Mb, and 1 Gb. Although any of the aforementioned profiles work on any network configuration with links above 10 Mb, the transport protocol might not necessarily perform optimally on your particular networking topology. The custom multicast network profile provides a mechanism to tweak multicast protocol parameters so that you can achieve the best transfer performance with the least impact to your network.

To enable the custom network profile, run the command WDSUTIL /set-server / transport /profile:custom.

You can adjust the network profile parameter values by editing the registry keys at the following location:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSServer\Providers\WDSMC\  Profiles\Custom

Common Parameters to Adjust

Following is a list of the parameters that most often need to be adjusted:

• Bandwidth Utilization Name = TpMaxBandwidth

  The value equals the percentage of bandwidth multicast traffic that should be used on each NIC. For example, suppose you have a server with two network interfaces: one connected to a 1-Gb network, and the other connected to a 100-Mb network. Setting this value to 80 specifies that the maximum bandwidth used by multicast is 80 percent of the available bandwidth on the first interface (1 Gb) and 80 percent of the available bandwidth on the second interface (100 Mb).

• Block Size Name = ApBlockSize

  The value equals the block size in bytes. A larger block size generally results in faster transfers, but it can cause issues if packet loss is high on the network (because there will be more data to retransmit as acknowledgment occurs at the block level). It is recommended to set this value in 4-KB increments-for example, 1 KB (1024 bytes), 4 KB (4096), 8 KB (8192), 16 KB (16384).

• Packet Time To Live (TTL) Name = TpMulticastTTL

  The TTL value determines the maximum number of network hops a multicast packet can traverse before being dropped by the devices on the network. You can use this value to restrict which clients can receive multicast content. For example, if your multicast server is in a hub office and you want to restrict clients from a branch office that is five network hops away from receiving multicast content, set the TTL to a very low value (for example, 3).

  Best Practices

  Following is a list of best practices to follow when working with WDS multicast:

• Adjust parameter values only in the custom profile. Never adjust parameter values in the default profiles. The custom profile is prepopulated with parameter values identical to that of the 100-Mb profile. If you need to return to the default values, set all parameters to mirror the 100-Mb values.

• Before switching to the custom network profile, perform sample deployments using each of the default profiles to determine which of the three (10 Mb, 100 Mb, or 1 Gb) performs best in your network topology. Take the parameter values of the identified default profile, and use those as starting points in the custom profile.

• Change only one parameter value at a time. Perform controlled tests after each change to assess the impact.

  –Scott Dickens

  Lead Program Manager, Windows Deployment Team

TFTP Windowing

TFTP windowing is another enhancement to Windows Deployment Services in Windows Server 2008. TFTP is a simplified form of FTP that’s been around since about 1980. Its use on Microsoft Windows platforms today is restricted to downloading Windows PE from your Windows Deployment Server so that a network boot can be performed on your client machine to download an image and kick off the installation process. TFTP was used in a similar way in RIS on Windows Server 2003 and Windows 2000 Server.

The main problem with TFTP for use in deployment is that it uses the connectionless UDP as its network transport, and each time the client receives a packet it has to send an ACK to the server to indicate success. This has two disadvantages: First, it slows down the transmission process because of all the ACKs that need to be sent and received, and this eats up network bandwidth also. And second, if your network link is slow, this ACKing can slow down your deployment even more.

Rather than try and rewrite the TFTP daemon from scratch, the product team instead decided to modify TFTP by adding a new feature called TFTP windowing, which is similar in some respects to the TCP windowing used by the TCP/IP network stack on Windows computers. What TFTP windowing involves is this: You define a window size that indicates how many UDP packets it takes to fill up the window. As packets arrive, the window starts filling up, but no ACK is transmitted until the entire window has been filled. The result is a lot fewer ACKs, and therefore, faster downloading of Windows PE from your Windows Deployment Server to your client computers, which can be server boxes on which you want to install Windows Server 2008 or client boxes on which you want to install Windows Vista.

A side effect of this change is that you can now use Windows Deployment Services to easily deploy Windows Vista or Windows Server 2008 to dual-homed machines, a scenario that was difficult to support using the initial release of Windows Deployment Services. Let’s hear from another of our experts, this time concerning TFTP windowing:

From the Experts: Using TFTP Windowing with WDS TFTP Server for Improved Performance

Windows Deployment Services uses TFTP to download all files in the pre-OS environment. TFTP is a UDP-based protocol that was designed to be simple; it does not have any security or authentication built in. The client requests a specific file from the TFTP server; the server divides the file into equal data blocks and sends it to the client. The client needs to acknowledge each data packet before the next data packet is sent by the server. This process works great if the server is not overloaded, but it starts to fall apart as network load increases and roundtrip time increases.

TFTP in Windows Server 2003

In Windows Server 2003, the WDS team added support for configurable data block sizes. The goal was to get as much data to the client before requiring an acknowledgment from the client. To configure the block size, administrators have to edit the BCD file generated for each architecture. The following steps demonstrate how this is done:

1. Go to the appropriate architecture directory, REMINST\Boot\<architecture>.

2. Use the BcdEdit.exe tool to add or edit the block size:

   BcdEdit -store default.bcd -set {}   ramdisktftpblocksize <block size>

3. Inform the WDS server that configuration has changed so that it can apply the changes:

   sc control wdsserver 129

   Limitations of This Approach

   This feature enables the transferring of more data per packet, but it has its own limitations:

   • The TFTP transfer is done using services provided by the BIOS, so the BIOS implementation on the client must be capable of picking up fragments of the UDP packet and assembling them into a full packet. In our testing, it was discovered that some BIOS implementations do not support this and thus TFTP download fails.

   • On a lossy or congested network, if a single UDP fragment is lost, the whole UDP becomes useless.

   • The maximum data that can be transferred in is restricted by the maximum size of the UDP packet, which is 65,535 bytes.

   • Some network switches apply ACLs on the UDP fragments as well and might discard UDP fragments if the fragments match their ACL.

     TFTP in Windows Server 2008

     Although the changes mentioned earlier in this sidebar do help to improve the download times, it was evident that we needed more for Windows Server 2008. So the WDS team added support for windowing in Windows Server 2008. The idea is that instead of the server sending one data packet and then waiting for acknowledgment from the client, the server now has a window of multiple data packets that are sent back-to-back without any acknowledgment from client. The client receives all data packets and then sends an acknowledgment. This mechanism also improves performance in high-latency networks.

     The number of packets the server should send without acknowledgment is configurable:

4. Go to the appropriate architecture directory, REMINST\Boot\<architecture>.

5. Use the BcdEdit.exe tool to add or edit the window size:

   BcdEdit -store default.bcd -set {}   ramdisktftpwindowsize <window size>

6. Inform the WDS server that the configuration has changed so that it can apply the changes:

   sc control wdsserver 129

   Best Practices

   Following is a list of best practices to follow when working with TFTP windowing:

   • Change one parameter at a time, and perform testing in a controlled environment to assess the impact.

   • If network switches in your environment enforce ACLs, set the block size to 1024 bytes and tweak the window size.

     –Asad Yaqoob

     Software Design Engineer, Windows Deployment Team

EFI x64 Network Boot Support

Finally, a third enhancement to Windows Deployment Services in Windows Server 2008 is the support for x64 EFI network boot. Extended Firmware Interface (EFI) is the next-generation firmware model and is likely to replace the legacy BIOS in the next few years. Overall, the enterprise hardware landscape is quickly moving toward EFI, particularly on x64 server hardware. Unfortunately, no network boot support for x64 EFI exists on Windows Server 2003-only IA64 hardware supports EFI for Windows Server 2003. And although the initial release of Windows Vista didn’t include x64 EFI support, future releases of this platform will likely do so. But Windows Server 2008 does include x64 EFI support, though it’s limited in scope to supporting basic network boots and has no support for architecture discovery, pending devices, or PXE referral. Still, it’s a good start, and it makes deploying Windows Server 2008 to x64 EFI hardware a reality today using Windows Deployment Services.

Before we leave the topic of Windows Deployment Services, let’s hear once again from one of our experts, this time talking about how to upgrade your old RIS server to a Windows Deployment Server running Windows Server 2008:

From the Experts: Upgrading Your Old RIS Server to a Windows Server 2008 WDS Server

Windows Deployment Services is a replacement of the Remote Installation Services optional component in Windows Server 2003. However, the two services use different operating system image formats: RIS uses RIPREP and RISETUP images, while WDS uses WIM images, as found on the Windows Vista and Windows Server 2008 DVDs. Because of this, a Windows Server 2003 server running RIS cannot be directly upgraded to a Windows Server 2008 server-the data in these images would be lost. The upgrade path, therefore, requires the following process to be completed:

1. Update RIS to WDS. There are two ways to do this: either apply Service Pack 2 to the server, or install the hotfix update included in the Windows AIK. Speaking of which…

2. Install the Windows AIK. It contains necessary support files for image conversion.

3. Update the path environment variable to include the Windows AIK install directory.

4. Initialize the WDS server. This can be done either through the WDS MMC Wizard or by running WDSUTIL /Initialize-Server /RemInst:D:\RemoteInstall, where D:\RemoteInstall is the path to the REMINST shared directory used by RIS. This places the server into Mixed Mode.

5. Convert the RIS images to WIM. There are two ways to do this:

   • Deploy them to a reference PC, run sysprep to generalize them, and then use the WDS Capture tool to capture them as a WIM and upload them to the WDS server.

   • Convert them offline on the WDS server. To do this from the WDS MMC, open the Legacy Images node on the server, right-click on an image, and select Convert To WIM. Alternatively, at a command prompt, run WDSUTIL /Convert-RIPREPImage /FilePath:<path1> /DestinationImage /FilePath:<path2>, where <path1> is the full path to the riprep.sif file and <path2> is the full path and file name of the new WIM file. Note that offline conversion works only on RIPREP images, not on RISETUP images.

6. Force the server into Native mode by running WDSUTIL /Set-Server /ForceNative.

7. Upgrade the server to Windows Server 2008.

   –Jez Sadler

   Program Manager, Windows Deployment Team

Solution Accelerator for Windows Server Deployment

If you’ve begun deploying Windows Vista within your organization, you’ve probably been using the Microsoft Solution Accelerator for Business Desktop Deployment (BDD) 2007, a set of comprehensive guidance and tools from Microsoft that you can use to optimally deploy Windows Vista and the 2007 Office system. BDD 2007 is the deployment story Microsoft has for Windows Vista, so it make sense that Microsoft is also developing a similar story for the Windows Server 2008 platform. The Microsoft Solution Accelerator for Windows Server Deployment will provide role-based deployment and purposing of Windows Server 2008 servers through automation tools and guidance. The Solution Accelerator for Windows Server Deployment will leverage the Microsoft System Center Configuration Manager 2007 Operating System Deployment (OSD) Package and the Microsoft Systems Management Server V4 Task Sequencer for its infrastructure. Core deployment scenarios for using the Solution Accelerator for Windows Server Deployment include performing clean installs of Windows Server 2008 using Lite Touch Installation (LTI) and Zero Touch Installation (ZTI), upgrading Windows Server 2003 to Windows Server 2008 using LTI and ZTI, and performing clean installs of Windows Server 2003 using LTI and ZTI. In addition, current plans are for you to be able to deploy Windows Server 2008 with a subset of available roles, including the AD, DNS, DCHP, File and Print, and IIS roles.

All I can say is this: if BDD is terrific, then the Solution Accelerator for Windows Server Deployment will likely be absolutely outstanding and will end up being the best-practice solution for deploying Windows Server 2008 for mid- and large-sized organizations. So stay tuned!