Windows Deployment Services Deployment

and Management Guide

Microsoft Corporation
Published: April 2008
Author: Trina Gorman

Abstract
This document contains detailed information that explains how to configure
Windows Server® 2008 to deploy operating system images to computers.
Copyright Information
Information in this document, including URL and other Internet Web site references, is subject to
change without notice. Unless otherwise noted, the companies, organizations, products, domain
names, e-mail addresses, logos, people, places, and events depicted in examples herein are
fictitious. No association with any real company, organization, product, domain name, e-mail
address, logo, person, place, or event is intended or should be inferred. Complying with all
applicable copyright laws is the responsibility of the user. Without limiting the rights under
copyright, no part of this document may be reproduced, stored in or introduced into a retrieval
system, or transmitted in any form or by any means (electronic, mechanical, photocopying,
recording, or otherwise), or for any purpose, without the express written permission of Microsoft
Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.

© 2008 Microsoft Corporation. All rights reserved.

Active Directory, Microsoft, Windows, Windows Server, and Windows Vista are either registered
trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

All other trademarks are property of their respective owners.

Contents
Windows Deployment Services Deployment and Management Guide...........................................1
Abstract....................................................................................................................................1

Copyright Information......................................................................................................................2

Contents..........................................................................................................................................3

Introduction to Windows Deployment Services.............................................................................12

About This Guide.......................................................................................................................12
In This Topic...............................................................................................................................12
What Is Windows Deployment Services?..................................................................................12
What’s New in Windows Deployment Services?........................................................................13
Benefits of Windows Deployment Services...............................................................................14
Management Tools....................................................................................................................14
Common Usage Scenarios........................................................................................................14
Scenario One: The Small Business........................................................................................14
Scenario Two: The Medium-Sized Business..........................................................................16
Scenario Three: The Large Enterprise...................................................................................17
Scenario Four: A Custom Deployment Using Transport Server..............................................18

Configuring Your Deployment.......................................................................................................18

Configuring Active Directory Settings............................................................................................19

In This Topic...............................................................................................................................19
Integration with Active Directory Domain Services....................................................................19
Supported Environments...........................................................................................................19
Configuring Static Domain Controllers and Global Catalog Servers..........................................20

Creating a Localized Setup Experience........................................................................................20

In This Topic...............................................................................................................................20
Localizing the Boot Menu..........................................................................................................21
Localizing the Installation...........................................................................................................21
Installing Language Packs.........................................................................................................23
Methods.................................................................................................................................23
Storing Language Packs in the Image Store..........................................................................24

Managing DHCP...........................................................................................................................25
In This Topic...............................................................................................................................25
Configuring DHCP Options........................................................................................................25
Enabling DHCP Authorization....................................................................................................26
Granting Permissions to Authorize the Server........................................................................26
Managing Network Boot Programs...............................................................................................27
In This Topic...............................................................................................................................27
Configuring the NBP..................................................................................................................28
List of NBPs...............................................................................................................................29
Directing a Client to the Appropriate NBP..................................................................................30
Updating the IP Helper Tables................................................................................................30
Using DHCP Options 60, 66, and 67......................................................................................31
Implementing PXE Referrals.....................................................................................................32
When to Implement PXE Referrals.........................................................................................32
Requirements.........................................................................................................................33
Referral Examples..................................................................................................................33
Enabling Architecture Detection.................................................................................................35
Avoiding a Boot Loop.................................................................................................................35

Managing the Boot Menu..............................................................................................................35

In This Topic...............................................................................................................................35
Overview....................................................................................................................................36
Boot Menu Limitations...............................................................................................................36
Specifying Boot Images for Prestaged Clients...........................................................................36
Configuring the Boot Menu for x64-Based Clients.....................................................................37

Prestaging Client Computers........................................................................................................37

In This Topic...............................................................................................................................37
Benefits......................................................................................................................................38
Creating an Auto-Add Policy......................................................................................................38
When the Policy Applies.........................................................................................................38
Auto-Add Policy Types...........................................................................................................39
Purging the Auto-Add Database................................................................................................40

Optimizing Your Deployment.........................................................................................................40

Extending Your Solution................................................................................................................40

In This Topic...............................................................................................................................41
Benefits of Building a Solution...................................................................................................41
Creating a Custom Solution.......................................................................................................41
Windows Deployment Services PXE Server.......................................................................42
Windows Deployment Services Client................................................................................42
Custom Solution Example.........................................................................................................43
Instructions for Using the Sample Code.................................................................................44
Sample Visual Basic Script.....................................................................................................44
Sample Image Unattend File..................................................................................................45
Sample WinPESHL.ini File.....................................................................................................46

Managing a Complex Environment...............................................................................................46

In This Topic...............................................................................................................................47
Managing a Server Remotely....................................................................................................47
 Avoiding IP Address Conflicts....................................................................................................48
Testing Technologies by Using Virtual Computers.....................................................................48
Versions of the Management Tools to Use with RIS and Windows Deployment Services.........49

Optimizing Performance................................................................................................................51
In This Topic...............................................................................................................................51
Best Practices for Avoiding Performance and Scalability Problems...........................................51
Configuring the Server for Performance and Scalability............................................................52
Performance and Scalability Expectations.................................................................................52
Unicasting...........................................................................................................................52
Multicasting.........................................................................................................................54
Multicast Installation........................................................................................................54
Unicast Installation..........................................................................................................55
Testing of Security Options with Multicast........................................................................56

Using Transport Server.................................................................................................................56

In This Topic...............................................................................................................................57
Comparison of Deployment Server and Transport Server.........................................................57
Configuring Transport Server.....................................................................................................58
Using a Transport Server to Boot from the Network..................................................................59
Using a Transport Server for Multicasting..................................................................................59
How to create a namespace with Transport Server................................................................60
Prerequisites for creating a namespace..............................................................................60
Namespace types...............................................................................................................60
To create a namespace.......................................................................................................61
How to join a client computer to a namespace by using Wdsmcast.exe................................61
How to perform common tasks...............................................................................................63
Options............................................................................................................................64

Performing Unattended Installations.............................................................................................65

Automating the PXE Boot.............................................................................................................65

In This Topic...............................................................................................................................65
Overview....................................................................................................................................65
Avoiding a Boot Loop.................................................................................................................66
Example Boot Loop.............................................................................................................67
Automating the Selection of the Boot Image..............................................................................67

Automating Setup.........................................................................................................................68
In This Topic...............................................................................................................................68
Overview....................................................................................................................................68
Automating the User Interface Screens of the Windows Deployment Services client................69
Unattend File Settings............................................................................................................70
Automating the Remaining Setup Phases.................................................................................72

Automating the Domain Join and Computer Naming....................................................................72

 In This Topic...............................................................................................................................73
Creating Unattend Files.............................................................................................................73
Ensuring Proper Rights..............................................................................................................73
Ensuring Security.......................................................................................................................74

Automating the Image Capture Wizard.........................................................................................75

Creating a WDSCapture.inf Unattend File.................................................................................75
Sample WDSCapture.inf Unattend File.....................................................................................79

Advanced Unattended Installation Scenarios................................................................................79

In This Topic...............................................................................................................................80
Passing Unattend Files to Setup by Using the Command Line.................................................80
Using Implicit Unattend Files.....................................................................................................81
Embedding an Unattend File in an Image..................................................................................81
Precedence...............................................................................................................................81
Unattend File Precedence...................................................................................................81
Command-Line Precedence...............................................................................................82
Example Scenario...............................................................................................................82
Using Variables to Obtain Information from the Client...............................................................83

Sample Unattend Files..................................................................................................................83

In This Topic...............................................................................................................................83
Windows Deployment Services Client Unattend File..............................................................84
Image Unattend Files (unsecure domain join)........................................................................85
Image Unattend Files (secure domain join)............................................................................86
Image Unattend Files (using variables)..................................................................................87
Sysprep.inf file........................................................................................................................88

Working with Images.....................................................................................................................89

Creating Images............................................................................................................................89
In This Topic...............................................................................................................................89
Overview....................................................................................................................................89
Boot Images..............................................................................................................................90
Versions of Windows PE........................................................................................................90
Creating Custom Boot Images...............................................................................................91
Discover Images........................................................................................................................91
Creating a Discover Images...................................................................................................92
Capture Image...........................................................................................................................93
Creating Custom Install Images.................................................................................................93
Converting RIPREP Images......................................................................................................94
Default Conversion.................................................................................................................94
In-Place Conversion...............................................................................................................95

Deploying Earlier Versions of Windows.........................................................................................95

Filtering Images............................................................................................................................96
Automatic Filtering by Windows Deployment Services..............................................................96
Filtering by Using HALs..........................................................................................................96
Filtering by Architecture..........................................................................................................97
Filtering Images Manually..........................................................................................................97

Servicing Images..........................................................................................................................97
In This Topic...............................................................................................................................98
Servicing an Image Offline.........................................................................................................98
Reducing the Size of Images.....................................................................................................99

Storing and Replicating Images Using DFS................................................................................100

Storing Files on Another Server...............................................................................................100
Replicating Images Using Distributed File System..................................................................101

How to Perform Common Tasks.................................................................................................102

In This Topic.............................................................................................................................102

How to Manage Your Server.......................................................................................................103

General Tasks..........................................................................................................................106
To configure Windows Deployment Services.......................................................................106
To start or stop the server.....................................................................................................106
To enable the server.............................................................................................................107
To enable logging of Windows Deployment Services client actions.....................................107
To choose the port number for RPCs...................................................................................107
To specify the network interfaces for the PXE provider to listen on......................................108
To configure how often the server refreshes its settings.......................................................109
To force the server to update files in the RemoteInstall folder..............................................109
To configure the network profile for the server......................................................................109
To back up the server data...................................................................................................109
DHCP.......................................................................................................................................110
To configure Windows Deployment Services to run on the same computer as Microsoft
DHCP................................................................................................................................110
To configure Windows Deployment Services to run on the same computer as non-Microsoft
DHCP................................................................................................................................110
To turn on the DHCP authorization requirement...................................................................111
To authorize the server in DHCP..........................................................................................111
Client Requests........................................................................................................................112
To configure the server to answer clients..............................................................................112
To set a delay in the server’s answers to PXE requests.......................................................112
To configure unknown clients to perform PXE boots without requiring F12..........................113
To configure clients who have booted without F12 to require a key press on subsequent
boots.................................................................................................................................113
To configure the server to determine the architecture of booting clients...............................113
Boot Program and Boot Image.................................................................................................114
 To choose which boot images are displayed on x64-based computers................................114
To choose the default network boot program for each architecture......................................114
To choose the default network boot program that does not require F12 for each architecture
..........................................................................................................................................115
To choose the default boot image for each architecture.......................................................115
Prestaging Clients....................................................................................................................116
To specify a domain controller for the PXE provider.............................................................116
To specify a global catalog server for the PXE provider.......................................................116
To choose whether to search for computer accounts in the domain controller before
searching the global catalog..............................................................................................116
To configure the server to prestage clients by using their MAC address instead of their GUID
..........................................................................................................................................117
To maintain a list of GUIDs that belong to multiple computers..............................................117
To specify how to generate computer names.......................................................................118
To specify the domain and OU in which to create computer accounts..................................119
To choose whether to join client computers to the domain...................................................119
Unattend File...........................................................................................................................120
To choose a default unattend file for the Windows Deployment Services client...................120
To specify whether an unattend file on the client computer will override a default unattend file
..........................................................................................................................................120

How to Manage Client Computers..............................................................................................121

Prestage Computers................................................................................................................123
To create a prestaged account for a client computer............................................................123
To prestage a client computer to boot from a different server...............................................123
To prestage a client computer to use a boot program other than the default........................123
To prestage a client computer to use an unattend file other than the default for the
Windows PE phase of unattended setup..........................................................................124
To prestage a client computer to use a boot image other than the default...........................124
To prestage a client computer to join a domain....................................................................125
Specify Settings for Prestaged Computers..............................................................................125
To view the attributes of a prestaged client..........................................................................125
To change the rate at which pending computers will poll the server.....................................126
To change the number of times pending computers will poll the server...............................127
To change the message displayed to pending computers....................................................127
To set a default network boot server for pending computers................................................127
To set a default boot program for pending computers..........................................................127
To set a default unattend file for pending computers............................................................128
To set a default boot image for pending computers..............................................................128
To set domain join options for pending computers...............................................................129
Configure Auto-Add Functionality............................................................................................130
To enable Auto-Add functionality..........................................................................................130
To change the length of time approved computers are held in the Auto-Add database........130
 To change the length of time rejected and pending computers are held in the Auto-Add
database...........................................................................................................................130
To delete the approved or rejected computers table.............................................................131
Approve and Reject Pending Computers.................................................................................131
To view the list of computers that are pending approval.......................................................131
To approve a pending computer by using the default settings..............................................131
To approve all pending computers by using the default settings..........................................132
To approve a pending computer, but change a setting.........................................................132
To approve all pending computers, but change a setting.....................................................134
To reject a pending computer...............................................................................................134

How to Manage Images..............................................................................................................135

General Tasks..........................................................................................................................136
To export an image from the server to a stand-alone .wim file.............................................136
To replace an image on the server with an updated version................................................137
To remove an image.............................................................................................................138
Boot Images............................................................................................................................138
To add a boot image to the server........................................................................................138
To set the name, description, and online/offline status attributes on a boot image...............139
To display the attributes of a boot image..............................................................................140
To create a capture image....................................................................................................140
To create a capture image manually.....................................................................................141
To create a discover image..................................................................................................142
To create a discover image manually...................................................................................143
Install Images..........................................................................................................................143
To add an install image.........................................................................................................143
To set the attributes for an install image...............................................................................144
To display the attributes for an install image.........................................................................144
To convert a RIPREP image to a .wim install image.............................................................145
To make a copy of an install image......................................................................................146
Image Groups..........................................................................................................................146
To remove an image group...................................................................................................146
To add an image group to the image store...........................................................................146
To set the attributes on an image group...............................................................................147
To display information about all images in an image group..................................................147

How to Create Multicast Transmissions......................................................................................147

In This Topic.............................................................................................................................148
Overview..................................................................................................................................148
Prerequisites for Creating a Multicast Transmission................................................................149
Known Issues in Creating a Multicast Transmission................................................................149
Transmission Types.................................................................................................................150
To create a multicast transmission with Deployment Server....................................................150
To manage transmissions........................................................................................................151
 To manage clients in a transmission........................................................................................152
To configure the UDP port range for multicasting....................................................................153
To configure how the server will obtain IP addresses for multicasting.....................................153

Example Multicast Scripts...........................................................................................................154

In This Topic.............................................................................................................................154
Stop Transmissions Slower than 1 MB per Second.................................................................154
Display Performance Information About Clients......................................................................159

How to Modify the BCD Store Using Bcdedit..............................................................................162

In This Topic.............................................................................................................................162
To View the Contents of the BCD Store...................................................................................162
To Configure the Default Selection Time-out Value..................................................................163
To Configure a Localized Boot Manager Experience...............................................................164
To Configure the TFTP Block Size...........................................................................................165
To Configure the TFTP Window Size.......................................................................................166
To Configure Windows Debugger Options...............................................................................167
To Turn On Emergency Management Services Settings.........................................................169

Troubleshooting .........................................................................................................................172

Analyzing Performance Problems...............................................................................................172

In This Topic.............................................................................................................................172
Analyzing Blockages in Each Phase of Installation..................................................................173
PXE Boot Phase...................................................................................................................173
TFTP Download Phase........................................................................................................173
Diagnosing TFTP Download Performance Problems........................................................173
Addressing TFTP Download Performance Problems........................................................174
Image Apply Phase..............................................................................................................175
Diagnosing Performance Problems in the Image Apply Phase.........................................175
Addressing Performance Problems in the Image Apply Phase.........................................176
Using Performance Monitoring................................................................................................177

Common Problems.....................................................................................................................179
Performing PXE Boots on Client Computers...........................................................................181
I am unable to perform PXE boots on client computers....................................................181
When I perform a PXE boot and select a boot image, I see a command prompt..............182
The client computer fails to get an IP address when I try to boot into PXE.......................182
The client computer obtains an IP address but then fails to download a NBP...................182
I don't see the hard drive of the client computer on the disk configuration page of Setup.182
My computer loads the boot image, but it cannot access an install image........................182
I created an unattend file, but when installation completes, my client computer is not joined
to the domain.................................................................................................................183
Install images do not appear on the image selection page...............................................183
Troubleshooting x64-Based Client Computers........................................................................183
 My x64-based client computer does not have any x64-based images on the boot image
selection page...............................................................................................................183
My x64-based client computer is detected as x64, but it fails to boot to the default image.
......................................................................................................................................184
Performing Management Operations.......................................................................................184
I can't approve a pending computer..................................................................................184
I approved a pending computer and then deleted the computer account that was created in
AD DS during the process. Now the server will not answer my client computer............184
I received the error: "0x2: File not found" when trying to manage a remote Windows
Deployment Services server..........................................................................................184
Creating Custom Install Images...............................................................................................185
When using Image Capture Wizard to create a custom image, the volume that contains my
image is not selectable..................................................................................................185
The finish button is not enabled on the final page of the image capture wizard................186
The capture started successfully, but then I got a metadata error.....................................186
Multicasting..............................................................................................................................186
My multicast transmissions are running very slowly..........................................................186
After enabling multicasting, there is excessive traffic on the network................................187

Logging and Tracing...................................................................................................................187

Network Ports Used ...................................................................................................................190

Protocols..................................................................................................................................190
Ports........................................................................................................................................191

Required Permissions.................................................................................................................192
In This Topic.............................................................................................................................192
General Permissions...............................................................................................................192
Permissions for Common Management Tasks.........................................................................193
Permissions for Client Installations..........................................................................................197
Permissions for Server Properties...........................................................................................199
Introduction to Windows Deployment
Services
This document contains detailed information about how to manage and deploy operating systems
by using Microsoft® Windows® Deployment Services.

About This Guide

Note the following information about this documentation:
• This guide applies only to the Windows Deployment Services server role for Windows
Server 2008. It does not apply to the Windows Deployment Services update (which is
included in the Windows AIK and Windows Server 2003 SP2). For more information about the
Windows Deployment Services update, see http://go.microsoft.com/fwlink/?LinkId=81031.
• This guide focuses primarily on the functionality of the complete installation of Windows
Deployment Services (Deployment Server role service). For information about configuring
and using the Transport Server role service, see Using Transport Server.
• For information about installing and configuring this role, see Step-by-Step Guide for
Windows Deployment Services in Windows Server 2008.
• To provide feedback on this documentation, e-mail wdsdoc@microsoft.com.

In This Topic
• What Is Windows Deployment Services?
• What’s New in Windows Deployment Services?
• Benefits of Windows Deployment Services
• Management Tools
• Common Usage Scenarios

What Is Windows Deployment Services?

The Windows Deployment Services role in Windows Server 2008 is the updated and redesigned
version of Remote Installation Services (RIS). Windows Deployment Services enables you to
deploy Windows operating systems, particularly Windows Vista® and Windows Server 2008. You
can use it to set up new computers by using a network-based installation. This means that you do
not have to be physically present at each computer, and you do not have to install each operating
system directly from a CD or DVD. The components of Windows Deployment Services are
organized into the following three categories:
• Server components. These components include a Pre-Boot Execution Environment
(PXE) server and Trivial File Transfer Protocol (TFTP) server for network booting a client to

12
 load and install an operating system. Also included is a shared folder and image repository
that contains boot images, install images, and files that you need specifically for network
booting. There is also a networking layer, a multicast component, and a diagnostics
component.
• Client components. These components include a graphical user interface (GUI) that
runs within the Windows Pre-Installation Environment (Windows PE). When a user selects an
operating system image, the client components communicate with the server components to
install the image.
• Management components. These components are a set of tools that you use to
manage the server, operating system images, and client computer accounts.

What’s New in Windows Deployment Services?

Windows Deployment Services for Windows Server 2008 includes several modifications to RIS
features. There are also modifications from Windows Deployment Services that you can install on
computers that are running Windows Server 2003. Both of these types of changes are described
in the following table.

Changes from RIS Changes from Windows Deployment Services in

Windows Server 2003

• The ability to deploy Windows Vista
and Windows Server 2008
• Windows PE as the boot operating
system
• Image-based installation, using the
Windows image (.wim) file
• The ability to transmit data and images
by using multicast functionality
• The ability to transmit data and images
by using multicast functionality on a stand-
alone server (when you install Using
Transport Server)

• The ability to transmit data and images • No support for RISETUP images or
by using multicast functionality OSChooser screens

• The ability to transmit data and images • An enhanced TFTP server

by using multicast functionality on a stand- • Support for network boots of x64-based
alone server (when you install Transport computers with Extensible Firmware
Server) Interface (EFI)
• An extensible and higher-performing • Metric reporting for installations (see
PXE server component Logging and Tracing)
• A new boot menu format for selecting
boot operating systems
• A new graphical user interface that you
can use to select and deploy images and to
manage Windows Deployment Services
servers and clients

13
Benefits of Windows Deployment Services
Windows Deployment Services provides the following installation and deployment benefits:
• Reduces the complexity of deployments and the costs associated with inefficient manual
installation processes.
• Enables you to perform network-based installation of Windows operating systems,
including Windows Vista and Windows Server 2008.
• Deploys Windows images to computers without operating systems.
• Supports mixed environments that include Windows Vista, Windows Server 2008,
Microsoft Windows XP, and Microsoft Windows Server 2003.
• Provides an end-to-end solution for the deployment of Windows operating systems to
client computers and servers.
• Uses standard Windows Server 2008 setup technologies, including Windows PE, .wim
files, and image-based setup.

Management Tools
• Windows Deployment Services MMC snap-in. A console that provides an easy way to
manage images, computers, and common server settings. You can perform almost all tasks
from the MMC snap-in (you cannot prestage client computers, but you can use it to set the
Auto-Add policy and approve or reject pending computers). Note that the snap-in is not
available when you are using the Transport Server role service.
• WDSUTIL command-line tool. A tool that enables you to manage the full functionality of
the server. WDSUTIL also enables you to script common tasks; simple batch files can run the
required commands because no command requires an interactive user session.

Common Usage Scenarios

The following are common scenarios for Windows Deployment Services.

Scenario One: The Small Business

Fabrikam, Inc. is a manufacturer of towels with custom designs. It is a small business with a
single office. Monica Brink, Fabrikam's resident IT professional, is responsible for maintaining the
IT infrastructure for the company, which consists of 25 client computers running Windows XP SP2
Professional and a single server running Windows Server 2003 with SP2. The server functions as
a file print server, Web server, Exchange server, Domain Name System (DNS), Dynamic Host
Configuration Protocol (DHCP) server, and domain controller. The computers are linked by a 100-
MBps Ethernet connection.
Monica is given the task of moving all of the client computers to the Windows Vista operating
system and upgrading the single server to Windows Server 2008. Because this takes all of those
computers out of action (effectively disabling the office workers), it is important that she makes
the switch as quickly as possible.

14
In the past, she deployed a new operating system one computer at a time. This took her around
45 minutes per computer (almost 19 hours to set up the operating system on all the client
computers). For almost three days, Monica was unavailable to work on anything else. Then she
would spend almost as much time installing the applications on each computer.
Monica is the only IT professional at Fabrikam, which means that she also must help teach users
about the new operating system. Therefore, it is important that she minimizes the amount of time
she spends on deployment. To accomplish this, Monica chooses to use Windows Deployment
Services because she can:
• Save time by running several installations simultaneously.
• Use a custom install image with preinstalled applications.
• Create an image by using the Windows Deployment Services Image Capture Wizard.
To begin, Monica does the following:
1. Upgrades her server to Windows Server 2008.
2. Installs the Windows Deployment Services server role.
3. Adds the Boot.wim from the Windows Server 2008 media (which contains a Windows PE
image, Setup.exe, and supporting files).
4. Adds the Install.wim from the Windows Vista media to the Windows Deployment Services
server by using the MMC snap-in.
5. Uses the MMC snap-in to create a capture image from the boot image she added in step
3. This image contains Windows PE and a wizard that will capture her custom image into a
.wim file.
All users at Fabrikam have the same desktop hardware, which was purchased from a single
vendor. To deploy on each of these computers a standardized image that contains the operating
system and preinstalled applications, Monica does the following:
1. Boots a reference computer from the network and installs the Install.wim onto it, which
contains the standard version of Windows Vista.
2. Installs Microsoft Office, the company's towel-design application, and the latest drivers
from the manufacturer’s site.
3. Uses Sysprep to generalize the operating system.
4. Reboots the computer into the capture image.
5. Uses the Image Capture Wizard to recapture the operating system and upload it directly
to the Windows Deployment Service server.
Now, Monica is ready to install the new operating systems. She does not need to migrate any
user data, because all of the employees store their user data on a server (rather than on their
hard disks). She reboots a client computer and then presses F12 to perform a network boot. This
boots her into the Boot.wim file, which guides her through the installation process. She selects
the disk partition and image she wants, and then the installation begins. While waiting for the
image to be applied to the first computer, Monica boots another computer and starts the same
process on that one.

15
Scenario Two: The Medium-Sized Business
Northwind Traders is a shipping firm with three offices: a central office in Tooth City, and branch
offices in the towns of Brushville and Flosston. Ron Gable is one of six IT staff members at
Northwind Traders. His responsibility is maintaining the 250 client computers used by the
company's employees. These are mostly desktop computers, but the sales force uses laptops for
customer presentations. There are 200 computers in the central office in Tooth City, and 25 each
in the Brushville and Flosston offices. Each site has an internal network running at 100 MB per
second (MBps), and the branch sites are connected to the Tooth City office by a T1 line. Ron has
three servers at the Tooth City office and one in each of the branch offices, which are
administered remotely.
Ron’s supervisor has tasked him with deploying Windows Vista to the whole company. Previously,
this would have involved many expensive trips to Brushville and Flosston, and it would have
taken Ron several weeks to complete. He wants to use Windows Deployment Services to deploy
Windows Vista remotely; however, company policy dictates that there can be only one DHCP
server on the corporate network, and this server is located at the Tooth City office. Remotely
deploying images to the 50 computers at the branch offices would cause immense congestion on
the connection.
Ron chooses to use Windows Deployment Services because with unattended setup, he can:
• Deploy Windows Vista to computers at the branch sites without being physically present
there.
• Use his existing replication solution to deliver images to the branch site servers.
• Use the PXE boot referral system to minimize network traffic between the branch sites
and the central office.
Ron configures the Windows Deployment Services server in the central office to pass on any
network boot requests from the branch offices to the local servers, which will supply the boot
programs and subsequent images. This minimizes the traffic on the line between the offices.
Ron has two standard operating system configurations — one for the desktop computers and one
for laptops that contains the sales presentations and drivers for projectors. Therefore, he builds
two images: one with the desktop configuration, and one with the laptop configuration (with no
applications). He stores all the user data on one of the servers, so he can deploy Windows Vista
without preserving any existing data on the client computers.
Ron uses Windows System Image Manager (Windows SIM) to author two image unattend files —
one for the desktop computers and one for the laptops. These files automate the installation, so
Ron does not need to be present at each computer during the installation. They also
automatically install Microsoft Office and the line-of-business application that the company uses
for package tracking. He uses the Windows Deployment Services management tools to associate
them with the images.
Next, Ron uses Active Directory® Domain Services (AD DS) to offer all computers a boot
program. The computer boots without requiring the users to press F12, and it assigns the correct
images to all of the desktops and laptops. He has configured each computer so when it is
restarted, it will boot from the network automatically and deploy the appropriate image. After the
image is applied to each computer, the computer is automatically joined to the corporate domain

16
and restarted. This time, it is served a different boot program that requires pressing F12 (so that it
boots to the hard disk drive and finishes the installation process). This prevents a boot loop, in
which the computer would continue booting into Setup. When the installation is completed, the
computer is ready for the user to log on.

Scenario Three: The Large Enterprise

Shu Ito is the network architect for Wide World Importers, a large enterprise with 5,000
employees in offices all over the world. The major employee centers are in the United States and
Germany, and there are 13 branch offices in other countries. Shu has five servers available to him
in the U.S. hub, two in the German hub, and one in each of the branch offices. The servers at the
hubs are connected to the corporate Ethernet on 1-GB-per-second (GBps) network interface
cards (NICs); the other computers are on 100-MBps NICs. The hubs are connected by T3 lines,
and the other sites are connected by T1 lines. All of the servers are hired on two-year leases.
Wide World Importers is replacing the accounting department’s 200 computers with computers
running Windows Vista. Shu would also like to deploy a Windows Server 2008 image to any
newly leased servers in the U.S. office. The servers in the German office and the branch sites are
the responsibility of the local administrators. Currently, deployments at Wide World Importers are
done by using RIS, and Shu wants to ensure that the existing computer building processes are
preserved with the move to Windows Deployment Services. In addition, it is important that each
computer is deployed with an operating system in a language that is appropriate for the users in
that country or region.
Shu chooses to use Windows Deployment Services because it enables him to do the following:
• Use appropriate language packs to reduce the required number of images.
• Manage all of his Windows Deployment Services servers from a single computer.
• Write scripts to automate common management tasks.
Shu upgrades his servers to Windows Server 2008, which gives him the ability to initialize and
configure the Windows Deployment Services servers remotely, using the management tools.
Then he starts creating his images. The vast majority of his deployments will be in English or
German, so he creates a Windows Vista image in each language. Other languages will be
installed by using external language packs, and applications will be downloaded by using
Systems Management Server (SMS). Shu first uploads the images and language packs to the
Windows Deployment Services server. Next, he creates the Windows Server 2008 image.
Shu authors unattend files with Windows SIM. He then uses File Replication Service (FRS) to
copy the images, language packs, and unattend files to the Windows Deployment Services
servers around the world. Of the accounting computers used by Wide World Importers, 150 are in
the U.S. office, 30 are in the German office, and the remaining 20 are scattered around the world.
To preserve the state and data on the previous computers, Shu uses the User State Migration
Tool (USMT) to save all of the data and user configurations to a shared folder on the primary
Windows Deployment Services server. Then he sets up each computer to boot from its local
Windows Deployment Services server and to start automated setup by using the unattend files.
When the installation is completed, Shu runs a task with USMT to migrate the user data to each
computer.

17
When the lease on a server expires and the server is replaced, Shu can use Windows
Deployment Services to deploy his Windows Server 2008 image in the same way that he
performed the RIS deployment.

Scenario Four: A Custom Deployment Using Transport Server

John Woods is the server maintenance engineer at the A. Datum Corporation data center. He is
responsible for maintaining the 300 servers used by A. Datum Corporation's major customers.
One of these customers is Adventure Works.
Adventure Works uses 40 servers to run a career Web site (which is backed by a database) for
circus performers. After the release of a popular film about circus life, Adventure Works expects
an increase in the use of their Web site. They order 10 additional servers to handle the
anticipated traffic.
John wants to deploy operating systems to these servers by using Windows Deployment
Services. However, he does not have AD DS running in this environment, so he cannot use the
standard Windows Deployment Services solution. Instead, he stores the configuration information
for his computers in a SQL Server database. In addition, he wants to partition the disks in a
standard configuration and also copy data (some for database servers, some for Web servers)
before the unattended setup begins. John chooses to use Windows Deployment Services
because he can:
• Write a plug-in that reads configuration data for the computers from a data store other
than AD DS (the data store is typically a database or a flat file).
• Write scripts (to run in Windows PE) that perform preinstallation tasks and then call Setup
to install the operating system.
John creates 10 computer accounts in his database for his 10 new servers, and he populates
them with the required information. He then writes a PXE provider (a plug-in that reads
information from the database and passes it to Windows Deployment Services). He creates a
custom boot image that contains Windows PE along with startup scripts to partition the disks and
copy the data. Then he uses ImageX to capture one of his existing servers as an install image.
After performing these initial tasks, John connects his servers to the network and boots them.
They boot into Windows PE by using the configuration stored in the database. His scripts run to
prepare each computer for deployment, and the scripts end by running ImageX to apply the
operating system image on each computer.

Configuring Your Deployment

• Configuring Active Directory Settings
• Creating a Localized Setup Experience
• Managing DHCP
• Managing Network Boot Programs
• Managing the Boot Menu

18
 • Prestaging Client Computers

Configuring Active Directory Settings

In This Topic
• Integration with Active Directory Domain Services
• Supported Environments
•

Integration with Active Directory Domain Services

Windows Deployment Services uses Active Directory Domain Services (AD DS) for a variety of
reasons. AD DS is its data store, and it contains all of the necessary helper routines. Windows
Deployment Services also links physical booting computers to computer account objects in
AD DS. The data used by Windows Deployment Services is stored in computer account objects
and Service Control Points (SCPs) within AD DS:
• Computer account objects. A physical computer is linked to to a computer account
object in AD DS. You can configure properties on the computer account object to control the
installation. For example, you can configure the network boot program and the unattend file
that the client should receive, as well as the server from which the client should download the
boot files.
• Service Control Point objects. The computer account object for the Windows
Deployment Services server contains a child object called an SCP object. This object is
created the first time Windows Deployment Services is started, and it indicates that the
computer account object is acting as a Windows Deployment Services server. The SCP
object also stores some configuration settings for Windows Deployment Services (for
example, whether the server should answer PXE boot requests).

Supported Environments
Windows Deployment Services supports AD DS environments that contain
Windows Server 2000, Windows Server 2003, Windows Server 2008, or environments with any
combination of these three operating systems. You will not gain any more functionality or features
in Windows Deployment Services features by switching to a higher forest functional level.
Windows Deployment Services works well in both single-domain and multidomain environments.
Windows Deployment Services also works in multiforest environments, but in such cases the
following caveats apply:
• A trust relationship must be established between the forest that contains the Windows
Deployment Services server and other forests in that environment.

19
 • The server must be configured to answer all client requests. The server cannot answer
only known clients in this configuration. This is because the AD DS search algorithm that is
used by Windows Deployment Services will only be able to locate prestaged computer
objects in the same AD DS forest as the Windows Deployment Services server. This also
means that all computer account objects that are created by Windows Deployment Services
will be created in the forest that contains the Windows Deployment Services server.

Configuring Static Domain Controllers and Global

Catalog Servers
In some circumstances, you may want to configure (statically) which domain controller and global
catalog server Windows Deployment Services will use. For example:
• You want to control replication latency. You may want to make changes to a particular
computer object and have Windows Deployment Services immediately pick up the change
(for example, if you modify netbootMachineFilePath to specify a different network boot
program).
• You do not have a domain controller and global catalog in the same AD DS site as
Windows Deployment Services. This configuration is not recommended. However, in this
case you may want to control which domain controller and global catalog Windows
Deployment Services will use rather than relying on the discovery algorithms.
• You need to troubleshoot an issue. For example, if Windows Deployment Services is
having problems accessing AD DS, you can use this setting to try to isolate the problem to a
specific domain controller or global catalog.
The one notable downside to mapping these servers statically occurs when a domain controller or
global catalog fails. For example, if you statically map Windows Deployment Services to use a
domain controller, and that domain controller is subsequently taken offline, Windows Deployment
Services will lose access to the domain controller’s services and stop servicing incoming client
requests. This problem will persist (even if you restart Windows Deployment Services) until the
domain controller is back online. This problem does not occur if you use the normal domain
controller and global catalog detection method.
To change these settings, see the "Prestaging Clients" section in How to Manage Your Server.

Creating a Localized Setup Experience

You can create a localized setup experience during any phase of an installation.

In This Topic
• Localizing the Boot Menu
• Localizing the Installation
• Installing Language Packs

20
Localizing the Boot Menu
Microsoft has completely reengineered the boot environment for Windows Vista to address the
increasing complexity and diversity of modern hardware and firmware. One aspect of this
reengineering is a new firmware-independent data store that contains boot configuration data
(BCD), which influences the boot process. For more information about BCD, see
http://go.microsoft.com/fwlink/?LinkId=110353.
You can configure the BCD store to display localized text in the boot menu by using a
combination of BCD store settings and true-type fonts. However, note the following two
limitations:
• The language that is configured in the BCD store will apply to all clients of a
particular architectural type. There is no way to configure language settings at a more
detailed level or to enable users to select the correct language.
• Image names are displayed exactly as they appear in the metadata of the Windows
image (.wim) file. Therefore, if you want the image names to be localized, you must change
the names manually.
To customize the BCD store, see How to Modify the BCD Store Using Bcdedit.

Localizing the Installation

You can configure Windows Deployment Services to support a localized installation experience to
the same extent that you can configure Windows Vista Setup. For example, you can change the
display language, the input settings, and the keyboard layout. To enable this functionality, you
must edit the boot image to include the necessary localized setup files. The keyboard layouts and
input device drivers are included in Microsoft Windows Preinstallation Environment (Windows PE)
by default (with the exception of Input Method Editor devices).
The language of the user interface of the Windows Deployment Services client is controlled by
the language settings that are specified on the language-neutral page of Setup (an optional page
that is not shown by default). The data that is displayed on this page is provided by the
multilingual user interface (MUI) application programming interface (API). The data is populated
based in the UI languages section of the Lang.ini file (in the boot image's \Sources folder).
Selecting a language on this page loads the proper resources so that all text will be displayed in
the selected language.
The keyboard layout selection menu is also derived from the chosen language. You can configure
both the language and keyboard layout options in the Windows Deployment Services client
unattend file. For more information, see Automating Setup. Some information shown on the
image selection page, such as image name and description, will not be shown in localized strings.
This is because the data displayed on this page is taken directly from the .wim metadata, which
can hold only a single string in a single language.

To enable the language-neutral page and language selection

1. In the Windows Deployment Services MMC snap-in, right-click the desired boot
image and then click Disable.

21
 2. Export the image.
3. Using ImageX, mount (read/write) the image marked as RAMDISK bootable (usually
the second image in the Boot.wim file).
4. Copy the setup MUI resource files and their associated folder to the \Sources
directory of the mounted boot image. For example, to add the German setup resource
files to your English boot image, copy the \Sources\de-de directory and all of its contents
to your mounted boot image at C:\Mount\Sources. At the end of this process, you should
have two sets of setup resource files: English at \Sources\en-us, and German at
\Sources\de-de.
5. If you are enabling a language that requires Asian fonts, perform the following
additional steps. In all other scenarios, go to Step 6:
a. Install the Windows Automated Installation Kit (AIK) on either a reference
computer or the Windows Deployment Services server.
b. Use the Copype.cmd script to create a Windows PE distribution share.
c. At the root of the C:\ drive, create a folder named Temp.
d. In C:\Temp, create two subfolders: WindowsPE1 and WindowsPE2.
e. Mount (read/write) the boot image to C:\Temp\WindowsPE1.
f. Copy the Boot.wim image from the Windows Vista DVD to C:\Temp.
g. Mount (read only) the second image in Boot.wim into C:\Temp\WindowsPE2.
h. Copy the entire \Sources folder from the mounted image at
C:\Temp\WindowsPE2 into C:\Temp\WindowsPE1.
i. Unmount the image mounted to C:\Temp\WindowsPE1, and then commit the
changes.
j. Add the modified image to your Windows Deployment Services server.
6. To enable the language-neutral page, adjust the Lang.ini file in the mounted boot
image to specify that additional setup resource files are available. The following is a
sample Lang.ini file after editing:
Contents of C:\mount\Sources\lang.ini

[Available UI Languages]

en-US = 3

de-DE = 3

[Fallback Languages]

en-US = en-us

7. Using ImageX, unmount the image and then commit the changes.
8. Import the image. To do this, right-click the disabled boot image by using the MMC
snap-in, and then click Replace Image.

22
Installing Language Packs
In contrast to Windows Vista Setup, Windows Deployment Services has independent localization
controls for the client installation experience and the install image. This functionality allows you to
view the client installation screens in one language and keyboard combination. It also allows you
to install an image that will have a completely different language and keyboard combination.
Windows Vista is language neutral, meaning that core system binaries and UI elements that
contain strings (content that would need to be localized) are stored separately. The localized
elements are known as multilingual user interface (MUI) files. All of the language-specific binaries
for a given language are bundled together in a single package known as a language pack. For
more information, see Installing Language Interface Packs (http://go.microsoft.com/fwlink/?
LinkId=111017)
Note also that Windows Vista enables you to add or remove language packs to change
languages in a current image (although licensing restrictions may apply, depending on the version
of the operating system that you are using). You can do this either online or offline. With this
functionality, you can maintain a single image with associated language packs — something that
was not possible with previous Windows operating systems, in which you needed to maintain a
separate image for each language.

Methods
There are three language pack deployment models that work well in enterprise environments.
Method 1: Install the necessary language packs into the offline image.
In this method, you use Package Manager to inject language packs into your base image. For
information about Package Manager, see the Windows AIK documentation at
http://go.microsoft.com/fwlink/?LinkId=96016).
• Pros: Install times are faster than with the other two methods because the language pack
is already in the image.
• Cons: The image size increases. Also, many applications are locked into a single
language. Therefore, you may not be able to take full advantage of this scenario, because
even though you could change the underlying operating system language, the languages in
the applications would not change to match the operating system language.
Method 2: Store language packs outside the image, and during installation, have Setup
install both the image and the language pack.
You can implement this method by using Windows Deployment Services. A control on the image
selection page enables you to select the language packs that are installed in the image and those
that reside outside the image (but are still associated with the image). Expect the following
behaviors:
• If the selected image is from an earlier version of Windows, the language selection
control on the image selection page will be disabled. This is because these images do not
support installing language packs.
• If the selected image is Windows Vista but there are no language packs available on the
server, the drop-down list will display those languages that are currently installed in the image
23
 as defined in the image’s metadata. The selection will default to the default language that is
defined in the image’s metadata.
• If the selected image is Windows Vista and there are language packs available on the
server, the drop-down list will display all externally available language packs as well as those
that are already installed in the image. The selection will default to the default language that
is defined in the image’s metadata.
The language pack that is selected will be the default language for the first boot of the install
image, and it controls the boot environment language, UI language, and default settings for
system locale and keyboard layout (if these are not defined in the unattend settings).
• Pros: There are fewer images to maintain
• Cons: Install times are longer because external language packs must be copied and
installed.
Method 3: Deploy language packs online (to a running operating system) after the
installation.
Though this method of deployment falls out of the scope of the Windows Deployment Services
solution, it is included here to cover all scenarios. To use this method, you could run scripts at first
logon or deploy the language packs to the client by using management software such as Group
Policy or Systems Management Server (SMS).
• Pros: This method does not require a change to the setup method that you are currently
using.
• Cons: The user’s first experience with Windows Vista is not necessarily in the expected
language. For example, the boot and the initial logon might be shown in the language of the
operating system because the language pack has not been applied yet. Also, only certain
versions of Windows support language pack installation and removal.

Storing Language Packs in the Image Store

Each language pack is a .cab file called Lp.cab, and each file is differentiated by the folder in
which it resides (for example, \en-US for U.S. English and \de-DE for German). You cannot
distinguish one language pack from another just by examining the metadata of the Lp.cab file.
A language pack is applicable to all versions of Windows Vista (the exception to this is
Windows PE 2.0, which has its own language packs separate from Windows Vista). However, a
language pack is applicable only to a specific version of the operating system — that is, language
packs are not backward-compatible. If a language pack was created for Windows Vista, you can
apply it only to Windows Vista. If you install a service pack on Windows Vista, you cannot apply
the Windows Vista language pack. The applicability rule is enforced at install time by Component-
Based Servicing (CBS). Thus, although it is possible to associate an incorrect language pack with
a particular version of an image, the installation of the language pack will fail when the installation
starts.
Within the Windows Deployment Services image store, language packs are stored on a per-
image basis, and each language pack is associated with a particular image. You must manually
create the \LangPacks folder (and the per-image subfolder if it does not already exist) and copy

24
the language folder and pack. Also note that you cannot remove language packs during the
installation by using Windows Deployment Services.

Managing DHCP

In This Topic
• Configuring DHCP Options
• Enabling DHCP Authorization
• Granting Permissions to Authorize the Server

Configuring DHCP Options

The method of communication between the booting client and the server uses data fields (known
as options) in Dynamic Host Control Protocol (DHCP) packets. The Windows Deployment
Services solution for booting over the network works well in many configurations. It works well
when Windows Deployment Services is located on the same physical computer or on a different
physical computer from the DHCP server. However, the default installation is that Windows
Deployment Services and a DCHP server (Microsoft or non-Microsoft) are located on different
physical computers. In this scenario, no additional configuration steps are required for
interoperability between Windows Deployment Services and the DHCP server.
However, if you are running Windows Deployment Services and DHCP on the same computer, in
addition to configuring the server to not listen on port 67, you will need to use your DHCP tools to
add Option 60 to their DHCP scopes. This allows booting clients to learn about the Windows
Deployment Services Pre-Boot Execution Environment (PXE) server from the DHCP response
that is generated by the DHCP server. Setting DHCP option tag 60 has one side-effect: clients
booting from the network are always notified that the Windows Deployment Services PXE server
is available, even if the server is not operational or has stopped. For instructions on configuring
these options, see the "DHCP section" in How to Manage Your Server.

Note
There are some scenarios (particularly those that require running a DHCP server) that do
not support adding custom DHCP option 60 on the same physical computer as the
Windows Deployment Services server. In these circumstances, it is possible to configure
the server to bind to UDP Port 67 in nonexclusive mode by passing the
SO_REUSEADDR option. For more information, see Using SO_REUSEADDR and
SO_EXCLUSIVEADDRUSE (http://go.microsoft.com/fwlink/?LinkId=82387).
If DHCP is installed on a server that is located in a different subnet, you will need to do one of the
following: configure your IP Helper tables (recommended) or add DHCP options 66 and 67. For
more information about these settings, see Managing Network Boot Programs.

25
Enabling DHCP Authorization
By default, the Windows Deployment Services PXE server does not need to be authorized to
service client computers. However, you can enable DHCP authorization (which is also known as
rogue detection) by using either of the following methods:
• Using the management tools. For instructions, see How to Manage Your Server.
• Using the DHCP MMC snap-in. To do this, on the DHCP server, click Start, point to
Administrative Tools, and then click DHCP.
You may want to enable this authorization for the following reasons:
• To help prevent an improperly configured PXE server on the network. You can do
this by requiring that only those servers that you authorize can service clients. This is not a
security protection mechanism, but it can help ensure that a PXE server that is not approved
does not service clients. Furthermore, DHCP authorization applies only to computers that are
joined to the Active Directory Domain Services (AD DS) structure of the corporate network.
For example, if a corporation had a forest, a malicious user could plug a computer into the
corporate network, install Windows Server® 2008, run Dcpromo, create a forest, install
Windows Deployment Services, and then authorize it.
• Your IT department has a policy that only authorized servers should be both
Windows Deployment Services PXE servers and DHCP listeners.
Authorization checks for the Windows Deployment Services PXE server occur only if
authorization checking is enabled and the PXE server is configured to listen on port 67. This
means that authorization checks for a Windows Deployment Services PXE server take place only
in scenarios where Windows Deployment Services is running on a computer without DHCP. If
Windows Deployment Services and DHCP are running on the same physical computer, then the
DHCP server is listening on port 67, and it is responsible for making sure that it is authorized
properly. Note that the PXE server will not perform any additional checks.

Granting Permissions to Authorize the Server

You must be a domain administrator in the root domain of the forest or be an enterprise
administrator to authorize the server. Alternatively, you may delegate permissions by using the
following procedure.

To delegate permissions
1. Open the Active Directory Sites and Services MMC snap-in.
2. On the View menu, click Show Services Node.
3. Click Services.
4. Right-click NetServices, and then click Properties.
5. On the Security tab, assign the following permissions to the users or groups for
which you want to authorize these servers: Read, Write, and Create all child objects.
6. Click Advanced. Click the user or group you just added, and then click Edit.
7. In the Apply to box, click This object and all descendant objects.

26
The environment that the Windows Deployment Services server is in influences the authorization
behavior:
• NT4 domain. If the PXE server is part of an NT4 domain, no authorization is performed
and the PXE server will service requests. This mode is supported only if the PXE server is
running with a custom non-Microsoft PXE provider. Windows Deployment Services requires
AD DS; therefore, it cannot operate if joined only to an NT4 domain.
• Windows Server 2000 or later domain. If the PXE server is part of a
Windows Server 2000 or later domain (meaning that AD DS is present), it queries AD DS to
determine its authorization state.
• Workgroup. If the PXE server is part of a workgroup, it can service client requests as
long as other DHCP servers on the same subnet are not part of a domain. If a DHCP server
that is part of a domain comes online, the PXE server will stop servicing requests.
• Windows Small Business Server 2003. If the PXE server is part of a Small Business
Server 2003 domain, it must be the only DHCP server on the network. If another DHCP
server exists or comes online, the PXE server stops servicing requests.

Managing Network Boot Programs

A network boot program (NBP) is the first file that is downloaded and executed as part of the Pre-
Boot Execution Environment (PXE) boot process. Note that NBPs are specific to both architecture
and firmware (BIOS or EFI), and they control the first boot experience (EFI stands for Extensible
Firmware Interface). To see a list of the NBPs and how they modify the boot process, see List of
NBPs. On BIOS computers (per the PXE specification), the NBP is a 16-bit, real-mode
application. As such, you can use the same NBP for both x86-based and x64-based operating
systems that have BIOS, because both are capable of running this program.

In This Topic
• Configuring the NBP
• Specifying a NBP For the Server
• Specifying a NBP For a Specific Client
• List of NBPs
• List of NBPs
• Directing a Client to the Appropriate NBP
• Updating the IP Helper Tables
• Using DHCP Options 60, 66, and 67
• Implementing PXE Referrals
• When to Implement PXE Referrals
• Requirements
• Referral Examples
27
 • Enabling Architecture Detection
• Avoiding a Boot Loop

Note
For information about avoiding a boot loop, see Automating the PXE Boot.

Configuring the NBP

There is an NBP specified for each architecture. However, you can override the NBP for each
server on a per-client basis. For example, you may want to configure an NBP so that:
• Known clients receive the per-server default (presumably an NBP that requires pressing
the F12 key).
• Unknown clients receive an NBP that will cause them to perform a PXE boot
automatically.
This configuration is particularly useful in a lab environment where you want to immediately
image new computers, but you want to ensure that existing computers are not sent through the
imaging process by accidentally booting from the network.
To do this, you can override the per-server default by specifying the NBP that a client should
receive, using the netbootMachineFilePath attribute of a prestaged computer (that is, the
computer account that represents the client computer in Active Directory Domain Services
(AD DS). In the following netbootMachineFilePath attribute syntax, <PathToNBP> and
<NameOfNBP> are optional, and you can specify <Server> to indicate the PXE server referral.
<Server>\<PathToNBP>\<NameOfNBP>
For example:
netbootMachineFilePath: machine\OSChooser\i386\startrom.com

netbootMachineFilePath: machine.domain.com\boot\x86\pxeboot.n12

netbootMachineFilePath: machine

netbootMachineFilePath: machine.domain.com

The following is example output of the netbootMachineFilePath attribute, obtained by using the
Ldp graphical user interface (GUI) tool, which you can use to view objects stored in AD DS.
***Searching...

ldap_search_s(ld, "DC=domain,DC=com", 2, "(&(objectClass=*)(netbootMachineFilePath=*))",

attrList, 0, &msg)

Result <0>: (null)

Matched DNs:

Getting 1 entries:

>> Dn: CN=Prestage1,CN=Computers,DC=domain,DC=com

5> objectClass: top; person; organizationalPerson; user; computer;

1> cn: Prestage1;

28
 1> distinguishedName: CN=Prestage1,CN=Computers,DC=domain,DC=com;

1> name: Prestage1;

1> netbootMachineFilePath: machine.domain.com\boot\x86\pxeboot.n12;

1> canonicalName: domain.com/Computers/Prestage1;

List of NBPs
The following table lists the available NBPs in Windows Deployment Services.

NBP Description Architecture Firmware

PXEboot.com (Default) Requires the x86-based and x64- BIOS

user to press the F12 based
key for a PXE boot to
continue.

PXEboot.n12 Does not require x86-based and x64- BIOS

pressing F12 and based
immediately begins a
PXE boot.

AbortPXE.com Boots the computer by x86-based and x64- BIOS

using the next boot based
item in the BIOS
without waiting for a
time-out.

Hdlscom1.com and Causes computers that x86-based and x64- BIOS

Hdlscom2.com do not support based
firmware console
redirection to display
"Press space or F12 for
network boot," using
console redirection to
serial port 1 or 2. Users
can proceed with the
boot process by
pressing either key, or
they can exit the boot
process by not
pressing either key.

Hdlscom1.n12 and Causes computers that x86-based and x64- BIOS

Hdlscom2.n12 support firmware based
console redirection will
not display the prompt

29
NBP Description Architecture Firmware

"Press space or F12 for

network boot" and the
computer will not wait
for user input.

Bootmgfw.efi The EFI equivalent for x64-based and EFI

Bootmgr.exe. In EFI, Itanium-based
the choice of whether
or not to perform a
PXE boot is handled
within the EFI shell,
and not by the NBP.

Wdsnbp.com An NBP developed for x86-based and x64- BIOS

Windows Deployment based
Services that serves
the following general
purposes:
1. Architecture
detection
2. Pending computer
scenarios
3. PXE referral cases
(including use of
Dynamic Host Control
Protocol (DHCP)
options 66 and 67)

Directing a Client to the Appropriate NBP

There are two methods for directing a client computer to the correct NBP:
• Updating the IP Helper Tables (recommended). The client contacts the server directly for
this information.
• Using DHCP Options 60, 66, and 67. A DHCP server relays this information to the client.

Updating the IP Helper Tables

Updating the IP Helper tables means updating the routing tables for your networking equipment
to make sure that DHCP traffic is directed correctly. When configured correctly, all DHCP
broadcasts from the client computer will be directed to both a valid DHCP server and a valid
network boot server. (Note that the requirement is not to rebroadcast the packet onto other

30
network segments, but rather to perform a forward of the packet to only those recipients that are
listed in the IP Helper table.)
If the booting client, the DHCP server, and the network boot server are all located on the same
network segment, you should not have to configure these tables. The client’s DHCP broadcasts
will reach both the DHCP server and the network boot server. However, if either the DHCP server
or the network boot server is on a different network segment than the client, or if they are on the
same network segment but the network is controlled by a switch or router, we recommend that
you update these tables. After the client computer has obtained its IP address, it contacts the
network boot server directly (again using DHCP packets) to obtain the name and path of the NBP
to be downloaded. The following are the specific changes that you need to make:
• All DHCP broadcasts by client computers on User Data Protocol (UDP) port 67 should be
forwarded directly to both the DHCP server and the Windows Deployment Services PXE
server.
• All traffic on UDP port 4011 from the client computers to the Windows Deployment
Services PXE server should be routed appropriately (these requests direct traffic, not
broadcasts, to the server).

Using DHCP Options 60, 66, and 67

Although Microsoft does not recommend this method, you can use the following DHCP options to
direct PXE clients to an appropriate NBP to download:
• Option 60 = client identifier (set to the string PXEClient)
• Option 66 = boot server host name
• Option 67 = boot file name
For instructions on configuring these options, see the "DHCP" section in How to Manage Your
Server. When using these DHCP options, client computers receive an IP address lease,
information about the boot server, and information about the NBP directly from the DHCP server.
Clients will not contact the network boot server by using DHCP, but they download the NBP
through Trivial File Transfer Protocol (TFTP). Microsoft does not recommend this method for the
following reasons:
• Using DHCP options is not as reliable as updating the IP Helper tables. In testing,
Microsoft has observed some issues (mainly with older PXE ROM) related to clients
incorrectly parsing the DHCP options returned from the DHCP server. The result is that
booting clients see a “TFTP Failed” error message. Generally, this problem occurs when the
PXE ROM ignores the boot server host name value and instead attempts to download the
NBP directly from the DHCP server (which likely does not have the NBP).
• If there are multiple network boot servers available to service client requests,
specifying a specific network boot server may prevent load-balancing.
• Clients may be directed to a network boot server that is not available. Because the
client does not have to contact a network boot server directly to determine the NBP to
download, the DHCP server may direct clients to download a NBP that does not exist or to a
server that is not currently available.

31
 • Clients may bypass the network boot server’s answer settings. Many network boot
servers have a mechanism that enables you to control which clients (if any) should be
answered. Per the PXE standard, client computers should contact the network boot server
directly to obtain the path and file name of the NBP. Using DHCP options 66 and 67 can
cause the client to bypass this communication with the network boot server and therefore
ignore the settings of the network boot server for answering clients.
Note that using DHCP options 66 and 67 is considered a PXE boot referral. Therefore, if you
choose this method, ensure that your implementation meets the guidelines defined in
Implementing PXE Referrals.

Implementing PXE Referrals

A PXE referral (also known as a network boot referral) occurs when a client is directed to
download an NBP from a different server than the one it was in communication with through
DHCP (as part of the process to discover the network boot server name and NBP). This referral
may be initiated by either a network boot server or a DHCP server.
The following areas are covered in this section:
• When to Implement PXE Referrals
• Requirements
• Referral Scope

When to Implement PXE Referrals

You might want to consider using PXE referrals in the following scenarios:
• To direct a client to download a NBP that is located on a different computer or
network location. This may be especially helpful when using DHCP options 66 and 67,
because the client is typically answered directly by the DHCP server and is redirected to the
network location that contains the NBP.
• To enable load balancing. It may be advantageous to direct a class of clients to a
particular Windows Deployment Services server to limit network traffic to a server.
• To support complex network and AD DS topologies. Sometimes the networking and
AD DS topology do not line up. This could be because incoming PXE requests are answered
by a computer over a wide area network (WAN), but you would like a local server to provide
the boot image.
• To remove the need for image replication and duplicate image maintenance. Using
referrals can enable you to keep only one copy of an image, therefore maintaining a single
release point to update and service. Additionally, using referrals will reduce the amount of
overhead it takes to keep multiple images in sync.
Configuring PXE boot referrals involves two steps. First, you must configure the front-end and
back-end servers. A front-end server is the server that will answer the client’s PXE boot request
and direct the client to the proper server and NBP. A back-end server is the server that the client
will download the NBP from. Second, prestage clients and direct them to a back-end server and,

32
optionally, the NBP to download. This second step is required only if you are not using DHCP
options 66 and 67 to redirect clients. To configure these settings, see How to Manage Your
Server.

Requirements
PXE boot referrals that don't involve using DHCP options 66 and 67 require that the referred
client to be prestaged. Additionally, the netbootMachineFilePath attribute of that computer
account must be populated with (at a minimum) the server name that the client should use. In
environments that contain both Remote Installation Services (RIS) and Windows Deployment
Services servers, only the Windows Deployment Services servers should act as referral servers.
This enables the Windows Deployment Services server to control the referral process, correctly
referring clients to new Windows Deployment Services servers and maintaining backward
compatibility for RIS servers.

Note
Having a RIS server act as a referral server for a back-end Windows Deployment
Services server will work only if prestaged computers have both the referral server name
and the NBP name defined in the netbootMachineFilePath attribute. Failing to populate
the NBP name will cause the RIS server to populate the value automatically with
Startrom.com (which will not exist on the backend Windows Deployment Services server
if the server is in Native mode on Windows Server 2003, or if you are running Windows
Server 2008).

Referral Examples
Referrals are classified based on the number of jumps the client must make before it downloads
and executes an NBP. The following table contains three examples of referrals. Each of these
examples supports the referral of x86-based or x64 BIOS-based clients, but does not support the
referral of Itanium-based and x64 EFI-based clients

Example Details

First order referral from PXE server
ComputerA sends a DHCP broadcast packet
and receives an IP address lease from a DHCP
server and a response from PXE Server1.
ComputerA contacts PXE Server1 directly on
port 4011. PXE Server1 refers the client to
download \boot\wdsnbp.com from Server2. The
client computer downloads Wdsnbp.com from
Server2.
Requirements:
• The NBP that the client computer is
directed to download from the TFTP server
(Server2 in this example) must be

33
Example
First order referral using DHCP options
Second order referral using both DHCP options
and PXE server
Details
Wdsnbp.com.
• The network boot server performing the
referral (PXE Server1 in this example) must
be running Windows Deployment Services.
ComputerA sends a DHCP broadcast packet
and receives an IP address lease from a DHCP
server. The lease also contains values for
DHCP options 66 and 67, referring the client to
download the file \boot\ x86\wdsnbp.com from
Server1. The client computer downloads
Wdsnbp.com from Server1.
Requirement:
• The NBP that the client computer is
directed to download from the TFTP server
(Server1 in this example) must be
Wdsnbp.com.
ComputerA sends a DHCP broadcast packet
and receives an IP address lease from a DHCP
server. The lease also contains values for
DHCP options 66 and 67, referring the client to
download the file \boot\ x86\wdsnbp.com from
PXE Server1. The client computer downloads
Wdsnbp.com from PXE Server1. Wdsnbp.com
contacts PXE Server1 on port 4011. PXE
Server1 refers the client to download the
\boot\x86\wdsnbp.com from Server2. The client
computer downloads Wdsnbp.com from
Server2.
Requirements:
• The NBP that the client computer is
directed to download from the PXE server
(PXE Server1 in this example) must be
Wdsnbp.com.
• The NBP that the client computer is
directed to download from the TFTP server
(Server2 in this example) must be
Wdsnbp.com.
• The network boot server performing the
referral (PXE Server1 in this example) must
be running Windows Deployment Services.
34
Enabling Architecture Detection
To work around client architecture reporting problems, you can enable an architecture detection
feature on your Windows Deployment Services server. When enabled, the client is sent a NBP
(wdsnbp.com) before downloading the normal NBP for the client’s architecture. Wdsnbp.com
performs an architecture detection test on the client processor and then reports the value back to
the server, using a DHCP packet. After the server receives the information, it sends the correct
NBP to the client.
When enabled, architecture detection is performed on every x86-based computer in the
environment. This feature is turned off by default because the detection process adds time to
boot, increases network traffic, and increases the server's load. You can enable architecture
detection by running the command WDSUTIL /Set-Server /ArchitectureDiscovery:Yes.

Avoiding a Boot Loop

When implementing an automated experience of booting from the network, it is often necessary
both to set the network as the first device in the client’s BIOS boot order and to send a specific
client the .n12 NBP. If you combine these two configurations, the client will automatically boot
from the network without requiring user intervention, and the computer will end up in a circular
loop (always booting from the network and never from the hard disk drive). To work around this
scenario, you should perform the following steps:
1. Prestage the device (see Prestaging Client Computers).
2. Set the BIOS boot order on the computer such that the computer always boots from the
network.
3. Set the appropriate .n12 NBP for the computer's architecture. For instructions, see How
to Manage Your Server.
4. Turn on the computer, and let it boot from the network.
When you configure the installation in this way, the path to the NBP will be reset after the image is
applied, as one of the final actions performed by Windows Deployment Services. This ensures
that on the next boot, the computer will receive the default server NBP (commonly the .com
version). Therefore, the computer will try to boot from the network (because the network is first in
the BIOS boot order), but the computer will be sent the .com NBP. After waiting for the user to
press the F12 key, this option will time out and the device will boot from the hard disk drive.

Managing the Boot Menu

In This Topic
• Overview
• Boot Menu Limitations
35
 • Specifying Boot Images for Prestaged Clients
• Configuring the Boot Menu for x64-Based Clients

Overview
A boot menu is displayed on a client computer when the client performs a Pre-Boot Execution
Environment (PXE) boots and more than one boot image is available to that client. If only one
boot image is available, the computer will automatically boot into that image. The boot images are
ordered alphabetically, based on the file name of the .wim file that contains the image.
Microsoft has completely reengineered the boot environment for Windows Vista and
Windows Server® 2008 to address the increasing complexity and diversity of modern hardware
and firmware. One aspect of this reengineering is a new firmware-independent data store that
contains boot configuration data (BCD). The BCD store defines how the boot menu is configured.
The store is a namespace container for BCD objects and elements that holds the information that
is required to load Windows or run other boot applications. Physically, a BCD store is a binary file
in the registry hive format. For more information about BCDs, see http://go.microsoft.com/fwlink/?
LinkID=110353.
To customize the BCD store, see How to Modify the BCD Store Using Bcdedit.

Boot Menu Limitations

Because the menu exists outside of an operating system, there are certain limitations placed on
the user interface (UI), including the following:
• The screen size is 80x25 pixels, which means that approximately 13 images can be
displayed on the page simultaneously. If more than 13 images are available, the display will
scroll to support the additional images. The number of images that can be shown is
dependent on several factors, including the number of images that need to be displayed to
the client and the number of characters in the image name.
• There is no mouse or Input Method Editor (IME) functionality.
• There is no support for alternate keyboards, other than what the BIOS supports.
• There is limited support for localization, other than what the BIOS supports.
• There is limited support for accessibility.

Specifying Boot Images for Prestaged Clients

You can assign a boot image to a prestaged computer in Active Directory Domain Services
(AD DS). For instructions, see the "Prestage Computers" section in How to Manage Client
Computers. In these instances, Windows Deployment Services must dynamically create a BCD
store for the booting client that has the assigned boot image selected as the default. Rather than
generating a unique BCD store that contains only that operating system entry for each booting
client (which, due to the BCD architecture may take several seconds), the existing BCD store for
the client’s architecture (in RemoteInstall\Tmp) is copied and the default selection is modified to

36
reflect the new default. In addition, other booting clients that have been assigned the same boot
image can reuse this dynamically generated BCD store.

Configuring the Boot Menu for x64-Based Clients

Because x64-based computers are capable of booting both x86-based and x64-based images,
the default behavior is that x64-based users see a list of both x86-based and x64-based boot
images when both are available on the server. This means that x64-based clients receive the
x86x64.{GUID}.bcd store. For instructions on configuring the boot image policy that x64-based
clients should see, see the "Boot Program and Boot Image" section in How to Manage Client
Computers.
To work-around issues where the booting client may not be sending the correct architecture value
in the initial PXE discovery packet, the Wdsnbp.com boot program will detect the architecture of
the booting client and report that value back to the Windows Deployment Services server. For
more information, see the "List of NBPs" section in Managing Network Boot Programs.

Prestaging Client Computers

Prestaged client computers are computer account objects that are created within Active Directory
Domain Servers (AD DS) before the operating system is installed using Windows Deployment
Services. These objects are mapped to the physical computers that will perform a network boot to
install an image. You can prestage computers by using the following methods:
• Using WDSUTIL. For instructions see How to Manage Client Computers.
• Using Active Directory tools. These tools include the Active Directory Users and
Computers snap-in, Csvde.exe, the LDIFDE utility, Ldp.exe, and Adsiedit.msc.
• Enabling Auto-Add functionality. For instructions, see the section "To enable Auto-Add
functionality" in How to Manage Client Computers.
• Using Windows Deployment Services during image deployment. That is, when the
computer is set to join a domain.

Note
You cannot prestage computers by using the Windows Deployment Services MMC snap-
in, but you can set the Auto-Add policy and approve or reject pending computers.

In This Topic
• Benefits
• Creating an Auto-Add Policy
• When the Policy Applies
• Auto-Add Policy Types
• Purging the Auto-Add Database

37
Benefits
Prestaging clients provides three main benefits:
• An additional layer of security. You can configure Windows Deployment Services to
answer only prestaged clients, therefore ensuring that clients that are not prestaged will not
be able to boot from the network.
• Additional flexibility. Prestaging clients increases flexibility by enabling you to control
the following:
• The computer account name and location within AD DS.
• Which Pre-Boot Execution Environment (PXE) server should service the client.
• Which network boot program (NBP) the client should receive.
• Other advanced options — for example, what boot image a client will receive or what
Windows Deployment Services client unattend file the client should use.
• The ability for multiple PXE servers to service the same network segment. You can
do this by restricting the server to answering only a particular set of clients. Note that the
prestaged client must be in the same forest as the Windows Deployment Services server
(trusted forests do not work).

Creating an Auto-Add Policy

In Remote Installation Services (RIS), creating prestaged computers was largely a manual effort.
Windows Deployment Services, however, offers a more automated, simplified way to create
prestaged computer account objects by enabling the Auto-Add policy. For instructions on how to
enable Auto-Add, see How to Manage Client Computers.

Note
If you are creating computer accounts against a non-English domain controller and you
are using the default user property, you must set the Auto-Add settings to use a different
account that does not contain extended characters. If the account contains a non-
standard character (any character outside [A-Z, a-z, 0-9, \, -, and so on]), such as
German's "Domänen-Admins", then Auto-Add will fail. To change this value, see the help
at the command prompt for WDSUTIL /set-server /AutoAddSettings.

When the Policy Applies

The Auto-Add policy applies only when the Windows Deployment Services server is set to answer
all clients, and Windows Deployment Services does not find a prestaged computer for a booting
computer. In all other cases, the Auto-Add policy will not be in effect. In the following table, X
means that the policy will not be in effect, and O means that the policy will be in effect.

Note
The Auto-Add policy relies on NBPs that are available only for BIOS computers.
Computers that use Extensible Firmware Interface (EFI) will not use the Auto-Add policy.

38
Answer clients? Answer only known Computer account Is the Auto-Add policy
clients? found in AD DS? in effect?

No N/A N/A X

Yes No No O

Yes No Yes X

Yes Yes No X

Yes Yes Yes X

Auto-Add Policy Types

There are two options with Auto-Add:
• Disabled Auto-Add policy. (Default) If you do not turn on Auto-Add, Windows
Deployment Services will not create a computer account for unknown clients. It will, however,
still answer clients according to the settings on the server.
• Enabled Auto-Add policy. To enable Auto-Add, run the command WDSUTIL /Set-
Server /AutoAddPolicy /Policy:AdminApproval. With this option, when a client computer
that is not prestaged attempts a network boot, the computer will be put into a pending queue.
The computer will remain in this queue until you approve or reject it, the time-out is reached,
or the user cancels the attempt. While the computer is in the pending queue, a special NBP
(Wdsnbp.com) is sent to the client. The Wdsnbp.com program serves two main purposes:
• Pauses the PXE boot. This gives you time to review the computers in the pending
queue and accept or reject them, as appropriate. It also enables you to avoid situations
where the computer must be booted more than once. For example, suppose that a
computer boots once and is added to a pending queue. If the administrator does not
approve the computer immediately, it will move on and boot from the next item in the boot
order (which may be a blank hard disk, at which point the computer will be in a
nonbooted state).
• Reports back the client computer's architecture as part of architecture discovery.
All computers in the pending queue are represented as an entry in the Auto-Add database. This
temporary storage location serves three purposes:
• To provide the management utilities with a list of all pending computers on a server.
• To serve as an audit trail by recording what computers have been approved or rejected.
• To reduce the size of AD DS and keep old computer account objects out of the AD DS.
Approving a computer enables the client computer to continue booting from the network, and a
computer account object is created in AD DS to represent the physical computer. Rejecting a
computer causes the computer to abort and boot from the next item in the boot order. A computer
account is not created for a rejected computer.

39
Purging the Auto-Add Database
Records in the database are purged either manually or on a schedule. The default schedule
purges unapproved and rejected computers from the database every 24 hours. If a computer was
accidentally rejected, you can remove the computer by using one of the following methods:
• Wait for the default cleanup to occur, and then boot the computer again.
• Purge records from the pending table by running the command WDSUTIL /Delete-
AutoAddDevices /DeviceType:<ApprovedDevices|RejectedDevices>.
By default, computers with an approved status will be deleted every 30 days. In addition, to delete
a prestaged computer that was added to AD DS by using the approval process, you must perform
two steps. First, you must delete the computer from AD DS. Second, you must delete the
computer's record in the Auto-Add database. Failing to purge the database will cause the client to
be stuck in Wdsnbp.com and not proceed with booting from the network. This occurs because the
record in the Auto-Add database shows the computer as approved, but a prestaged computer in
AD DS will never be found (because the computer was deleted). In this situation, the server will
hold the client at Wdsnbp.com until a prestaged computer appears in AD DS.

To reset the Auto-Add database completely

1. Stop the WDSServer service.
2. Create a Temporary folder in the \RemoteInstall\Mgmt folder.
3. Move all existing files in the Mgmt folder to the Temporary folder.
4. Restart the WDSServer service.

Optimizing Your Deployment

• Extending Your Solution
• Managing a Complex Environment
• Optimizing Performance
• Using Transport Server

Extending Your Solution

Windows® Deployment Services enables you to create a variety of custom deployment solutions.
You can build an end-to-end deployment solution for Windows Vista and Windows Server® 2008.
Additionally, Microsoft Windows Preinstallation Environment (Windows PE) provides an
environment where you can use custom logic and processing. This chapter discusses ways to
extend your solution and provides useful examples.

40
In This Topic
• Benefits of Building a Solution
• Creating a Custom Solution
• Custom Solution Example

Benefits of Building a Solution

Using the Windows Deployment Services platform as part of a custom deployment solution
provides the following benefits:
• Increased interoperability. Common barriers for new deployment solutions include the
need for new hardware and the need for changes to network infrastructure to support
advanced networking configurations (for example, having two Pre-Boot Execution
Environment (PXE) servers on the same network segment). Windows Deployment Services
has built-in extensibility points that help you avoid these potential conflicts. You do not need
to have a separate physical server for each deployment solution because of the unified PXE
server architecture. Also, you do not need to store images in multiple locations or in multiple
formats because the management approach (which uses the Windows imaging format)
provides a central repository for images.
• A scalable PXE server infrastructure. The PXE server that is included in Windows
Deployment Services enables you to implement custom logic that dictates which clients are
answered. The PXE server handles advanced networking configurations by giving you control
over which interfaces the server binds to. This control extends to the IP address and MAC
address layers. The PXE server can handle the throughput generated by more than 5,000
client PXE requests per second.
• Image storage and management. Windows Deployment Services stores images in a
central location, and the management tools enable you to perform all common tasks, such as
adding and removing images and configuring server settings.
• Enumeration of images. Many network installation scenarios face a common problem:
getting a list of available install images from a central distribution point and returning that list
to the client. Windows Deployment Services does just this. It shows an authenticated client
computer a list of available images that are stored on a server or in a remote storage location,
which is referenced by using Distributed File System (DFS).
• Network boot support. Offering support for booting from the network becomes more
complex when different variations of Windows PE need to be supported (for example,
different languages, different hosted applications, and different architecture versions).
Windows Deployment Services accomplishes this by using the image storage structure and
management tools provided in Windows PE.

Creating a Custom Solution

You can use the Windows Deployment Services PXE server and the Windows Deployment
Services client (which is essentially Setup.exe and supporting files for Windows Deployment

41
Services) to create a custom solution. The Windows Deployment Services extensibility points are
documented in the Windows Vista software development kit (SDK) at
http://go.microsoft.com/fwlink/?LinkId=81029.

Windows Deployment Services PXE Server

The PXE server implementation in Windows Deployment Services consists of a PXE server and a
PXE provider. The PXE server contains the core networking capability: it binds to network
interfaces, listens for incoming PXE requests, and formats the Dynamic Host Control Protocol
(DHCP) response packets. The PXE server supports a plug-in interface. Plug-ins are also known
as PXE providers, and they provide the business logic. The server and provider enable you to
develop custom PXE solutions while taking advantage of the core PXE server networking code
base. The PXE server logic in Windows Deployment Services has two main features:
• A default provider that you can change. The provider installed by default with Windows
Deployment Services is BINLSVC, which is implemented in the DLL, Binlsvc.dll. You can
remove this PXE provider from the server and replace it with a custom-written provider.
• Support for multiple providers on a single server. Rather than having two PXE
listeners on the network (each with its own application logic), you can have multiple providers.
This means that you can have only one PXE listener on a network that has two or more sets
of application logic.
With this PXE server implementation, you can perform either of the following tasks:
• Create a PXE plug-in for a stand-alone PXE server (for example, a server that is not
joined to or communicating with an Active Directory Domain Services (AD DS) domain). The
plug-in might use a .txt file, an .xml file, or a SQL database as its data store.
• Enable a second, registered provider to offer functionality without disrupting or
reconfiguring Windows Deployment Services. One of the most powerful implementations
available is writing a filter provider, which is an additional PXE provider that resides above
BINLSVC (or any other PXE provider) in the ordered provider list. This filter provider acts as a
gate before the next provider in the list, enabling the next provider to service selected clients
by passing some requests and filtering others.

Windows Deployment Services Client

The Windows Deployment Services client is a graphical user interface (UI) that is built on
Setup.exe in Windows Vista (it contains additional logic that is specific to Windows Deployment
Services). The Windows Deployment Services client has the ability to establish a communication
channel with a Windows Deployment Services server. This channel provides a mechanism for
authentication and for retrieving a list of install images stored on the server. In addition, the
Windows Deployment Services client sends progress and status messages to the server while
the image is being installed. The library within the Windows Deployment Services client includes
the following functionality:
• The ability to authenticate and enumerate images that are stored on a Windows
Deployment Services server

42
 • The ability to send client installation events that can be used for reporting and monitoring
purposes (for example, sending notifications that the client installation has started or has
finished)
The following is a common scenario that uses this functionality.
1. A computer boots into a boot image that contains the Windows Vista Setup files. The
client can boot in any of several ways (from a CD, DVD, or hard disk drive, or over the
network).
2. A custom application (with a custom UI) is started.
3. The application detects the computer's MAC address and contacts a database to acquire
the correct unattend file.
4. The application uses the Windows Deployment Services client library to retrieve a list of
available images stored on a Windows Deployment Services server and displays the list of
choices to the client (by using the custom UI).
5. The application deploys the image that the user selects, and it also copies the unattend
file that was acquired previously.
6. The application sends progress and status messages to the server by using the
functionality provided by the Windows Deployment Services client library.

Custom Solution Example

Remote Installation Services (RIS) offered three options for naming a computer:
• Automatic: The computer name is automatically generated, and the client computer
account is created in a particular organizational unit (OU), based on the policy that is
implemented.
• Custom: The person performing the installation specifies the computer name and OU.
These values override the dictated server policy.
• Administrator. The person performing the installation specifies the computer name and
OU after the installation is completed.
Installations using the Windows Deployment Services client offer the Automatic and
Administrator options. There are methods for achieving the Custom option, but they generally
involve prestaging the device, either manually or by using Auto-Add functionality. Microsoft
recommends using Business Desktop Deployment (BDD) to implement the Custom scenario.
However, you can also provide this functionality with a few changes to your boot image, as
illustrated in the sample scripts later in this topic..
The Microsoft Visual Basic® script at the end of this document does the following:
1. Starts running from within Windows PE and gathers a computer name and OU (in
distinguished name form) from the user.
2. Runs the command setup.exe /wds /noreboot. At this point, the Windows Deployment
Services installation proceeds, and Setup does not restart as normal after finishing the
Windows PE phase.

43
 3. Edits the unattend file to add the computer name and OU that were entered by the user.
Note that the image that is selected needs an image unattend file that specifies the computer
name and OU. When the script is finished, the client will reboot if the script is the last (or only)
executable file listed in the WinPEshl.ini file.

Instructions for Using the Sample Code

To use these scripts, perform the following procedure to use these sample files.
1. Export a copy of a boot image from your server.
2. Mount the boot image as read/write. (Remember, the second image in the Boot.wim file is
marked as RAMDISK bootable, and it contains the Setup files).
a. Create a custom Winpeshl.ini file, and then copy it to the \Windows\System32 folder
of the mounted image.
b. Create a custom script (for example, domainOU.vbs) by using the sample code in the
section following this procedure. Copy this script to the mounted image's \Sources folder.
3. Unmount the image, and then commit the changes.
4. Add the image back to your Windows Deployment Services server.
5. Create an image unattend file similar to the sample file (Sample Image Unattend File).
6. Associate the unattend file with an install image.
7. Boot a client into the updated boot image.
8. Select the install image associated the unattend file.
The script starts running when Windows PE boots. It shows a basic UI which enables the user to
enter the computer name and the computer OU. The script performs the install and then replaces
all occurrences of %COMPUTERNAME% with the value specified in the message box, as well as
replacing all occurrences of %OU% with the value specified in the message box. Remember that
the OU must be entered in a distinguished name form — for example,
OU=MyOU,DC=Domain,DC=com.

Sample Visual Basic Script

Option Explicit

Dim computerName, OU, unattendFile, WshShell, result, fso, unattendFileObject, strContents

'----------------------------------------------------------------------

unattendFile = "C:\Windows\Panther\unattend.xml"

' end user defined settings

'----------------------------------------------------------------------

Set WshShell = WScript.CreateObject("WScript.Shell")

dim answer

44
do while answer <> vbYes

computerName = InputBox("Enter the desired computer name", "Computer Name")

OU = InputBox("Enter the distinguished name of the desired OU", "Organization Unit")

answer = MsgBox("Is this correct?" & vbCrLf & vbCrLF & "Name: " & computerName &
vbCrLF & "OU: " & OU, vbYesNo, "Computer Account Details")

loop

WshShell.Run "%SYSTEMDRIVE%\sources\setup.exe /wds /noreboot", 0, true

Set fso = CreateObject("Scripting.FileSystemObject")

if fso.FileExists(unattendFile) = false then

wscript.echo "Couldn't find unattend file"

else

'Read the unattend file in and replace apprpriate variables

Set unattendFileObject = fso.OpenTextFile(unattendFile, 1)

strContents = unattendFileObject.ReadAll

strContents = Replace(strContents, "%OU%", OU)

strContents = Replace(strContents, "%COMPUTERNAME%", computerName)

unattendFileObject.Close

'Write the updated contents back to the unattend file

Set unattendFileObject = fso.OpenTextFile(unattendFile, 2)

unattendFileObject.Write(strContents)

unattendFileObject.Close

End If

Sample Image Unattend File

The following is a sample image unattend file.
<?xml version="1.0" encoding="utf-8"?>

<unattend xmlns="urn:schemas-microsoft-com:unattend">

<settings pass="specialize">

45
 <component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="x86"
publicKeyToken="31bf3856ad364e35" language="neutral"

versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<Identification>

<UnsecureJoin>false</UnsecureJoin>

<MachineObjectOU>%OU%</MachineObjectOU>

<Credentials>

<Domain>MyDomain</Domain>

<Username>MyUserName</Username>

<Password>MyPassword</Password>

</Credentials>

<JoinDomain>%MACHINEDOMAIN%</JoinDomain>

</Identification>

</component>

<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86"

publicKeyToken="31bf3856ad364e35" language="neutral"

versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<ComputerName>%COMPUTERNAME%</ComputerName>

</component>

</settings>

</unattend>

Sample WinPESHL.ini File

[LaunchApps]

"%SYSTEMROOT%\system32\cscript.exe","%SYSTEMDRIVE%\sources\domainOU.vbs"

Managing a Complex Environment

This topic addresses difficulties that may be arise in complex environments — for example, where
Windows Deployment Services is used in an environment with many servers, Remote Installation
Services (RIS) servers, network hops, and so on.

46
In This Topic
• Managing a Server Remotely
• Avoiding IP Address Conflicts
• Testing Technologies by Using Virtual Computers
• Versions of the Management Tools to Use with RIS and Windows Deployment Services

Note
When performing Pre-Boot Execution Environment (PXE) referrals in an environment
that includes Windows Deployment Services and RIS, the Windows Deployment
Services server must answer PXE requests and perform referrals. If a RIS server
attempts to refer a client computer to a Windows Deployment Services server that is
running in Mixed mode or Native mode, the client computer will receive an incorrect
network boot program, which may cause the client to fail to boot.

Managing a Server Remotely

In addition to running Windows Deployment Services locally, you can also manage Windows
Deployment Services remotely using the following methods.

Method Explanation

Managing from another Windows Deployment
Services server
To do this, you must specify which server you
want to manage. You can do this in either of the
following ways:
• Using the Windows Deployment
Services MMC snap-in. First you must add
the server to the console. To do this, right-
click the Servers node and then click Add
Server. Next, type the name of the server
you want to add, or select it in the list. The
server will be added to the left pane in the
console, and you can perform any task by
selecting it just as you would select the local
server.
• Using WDSUTIL. To specify a remote
server to run a WDSUTIL command,
append /Server:<name> to the command.
For example:
WDSUTIL /Add-Image
/ImageFile:C:\images\capture.wim
/Server:MY-WDS-02 /ImageType:Boot

Managing from a remote server that is running To do this, you can install Remote Server

47
Method Explanation

Windows Server 2008 (but not Windows
Deployment Services)
Administration Tools, which will install WDSUTIL
and the Windows Deployment Services MMC
snap-in on the server. To install Remote Server
Administration Tools, open Server Manager,
right-click the Features node, click Add
Features, and then click Remote Server
Administration Tools. Next click Role
Administration Tools, and then click Windows
Deployment Services Tools.

Using PsExec You can also manage the server by using

PsExec. For example: psexec
\\<servername> \wdsutil /get-device
/id:<GUID>
For information about using PsExec, see
http://go.microsoft.com/fwlink/?LinkId=110605.

Avoiding IP Address Conflicts

When two servers select the same multicast IP address to send content to, content intended for
clients of either server can be routed to all clients. This causes unnecessary network traffic. Note
also that this is particularly harmful if the servers are connected by a low-bandwidth connection
(such as a wide area network (WAN) link), because both sets of content will be sent over this
connection. The following are preventive measures that you should take to avoid this situation:
• Use a Multicast Address Dynamic Client Allocation Protocol (MADCAP) server to allocate
multicast IP addresses. This will prevent addresses from being assigned twice.
• Configure a static range for each server, making sure that this range does not overlap
with the ranges defined for other servers.
• Lower the multicast Time-To-Live (TTL) setting to prevent the routers from forwarding
multicast traffic outside the site network. You can also configure your border router not to
forward multicast traffic.
To modify these options, right-click the server in the MMC snap-in, click Properties, and then
click the Network Settings tab.

Testing Technologies by Using Virtual Computers

Before introducing a new technology to a production environment, you may want to test the
technology on virtual computers. Windows Deployment Services should work on virtual
computers, but note that the performance will often be degraded, particularly during the Trivial
File Transfer Protocol (TFTP) download phase. This phase is very resource-intensive and may
fail if insufficient resources are available on the host computer. Also, performing a PXE boot on a

48
virtual computer or virtual server can take 20 minutes or longer when you are using Windows
Deployment Services. To resolve this, we recommend that you use a discover image instead of
PXE in the BIOS of the virtual computer.

Versions of the Management Tools to Use with RIS

and Windows Deployment Services
There are three server configurations that you may need to manage in a production environment,
and each of them has a different set of management tools. The following table lists these server
configurations and the versions of the management tools that are included for each of them. Note
that I indicates version 1, and II indicates version 2.

Tool and operating system Management tools

Remote Installation Services servers running • RISETUP (I)

Windows Server 2003 • RIPREP (I)

Windows Deployment Services servers running • RISETUP (II)

Windows Server 2003 • RIPREP (II)
• WDSUTIL (I)
• MMC snap-in (I)

Windows Deployment Services servers running • WDSUTIL (II)

Windows Server 2008 • MMC snap-in (II)

The Windows Deployment Services management tools enable you to manage a remote server.
Note, however, that there are some restrictions regarding which versions of the tools will work on
which server versions. The following table lists the seven possible configurations and the versions
of the tools that you should use with each environment. Essentially, you should use the latest
available version of each tool. For example, see the sixth row in the table: if you have servers
running the 2003 and 2008 versions of Windows Deployment Services, you should use RISETUP
(II), RIPREP (II), WDSUTIL (II), and WDSMMC (II)

Note
You cannot manage a Windows Deployment Services server running Windows
Server 2008 from a Windows Deployment Services server running Windows
Server 2003.

Servers running RIS Servers running Servers running Tools that you should
on Windows Windows Deployment Windows Deployment use
Server 2003 Services on Windows Services on Windows
Server 2003 Server 2008

X • RISETUP (I)

49
Servers running RIS Servers running Servers running Tools that you should
on Windows Windows Deployment Windows Deployment use
Server 2003 Services on Windows Services on Windows
Server 2003 Server 2008

• RIPREP (I)

X • RISETUP (II)
and RIPREP (II) to
manage any RIS
functionality
(Legacy/Mixed
mode)
• WDSUTIL (I)
and WDSMMC (I) to
manage any WDS
functionality

X • WDSUTIL (II)
• WDSMMC (II).

X X • RISETUP (II)
• RIPREP (II)
• WDSUTIL (I)
• WDSMMC (I)

X X • RISETUP (I)
• RIPREP (I)
• WDSUTIL (II)
• WDSMMC (II)

X X • RISETUP (II)
• RIPREP (II)
• WDSUTIL (II)
• WDSMMC (II)

X X X • RISETUP (II)
• RIPREP (II)
• WDSUTIL (II)
• WDSMMC (II)

50
Optimizing Performance
This chapter includes guidelines, techniques, and best practices to maximize performance,
scalability, and reliability. Among other useful information, you will find techniques to identify
blockages in your deployment, such as issues with network and server performance.

In This Topic
• Best Practices for Avoiding Performance and Scalability Problems
• Configuring the Server for Performance and Scalability
• Performance and Scalability Expectations
• Unicasting
• Multicasting
For information about analyzing blockages during an installation, see Analyzing Performance
Problems.

Best Practices for Avoiding Performance and

Scalability Problems
The following are best practices that you can use:
• Ensure that the network interface between the server and client has sufficient
bandwidth. Consider gigabit network adapters on the physical server with Category 5e (Cat
5e) cabling to a switch that can handle a GB back-plane connection, with 100-MB ports on
the front-plane (100 MB-clients, 1-GB back end to the server).
• Use high-quality Ethernet cabling. We recommend at least Cat 5 or Cat 5e is
recommended throughout the physical network.
• Use network switches. Do not use a hub.
• Partition network segments to distribute the load across multiple servers.
• Keep network latency to a minimum to optimize TFTP transfers.
• Ensure that the disk that contains the RemoteInstall folder has enough throughput
to meet the client demand. On small-scale solutions, this may mean getting a Serial
Advanced Technology Attachment (SATA) drive that spins at 7,200 RPM or faster. On mid-
scale solutions, this may mean getting multiple drives and configuring them using Redundant
Array of Independent Drives (RAID) configuration. On large-scale solutions, this may mean
investing in a hardware RAID array. The disk volume that contains RemoteInstall should be
separate from the system volume.
• Ensure that there is sufficient memory on the server to handle the demands. This
may mean upgrading a server from 32-bit (x86) to 64-bit (x64). (for details about how to
evaluate whether this solution is worthwhile for you, see Performance and Scalability
Expectations).

51
 • Ensure that there is enough processor bandwidth on the server to handle the
demands. If the server has a lot of processes or services that are running, you may need to
distribute the processes and services or upgrade the server’s processor.

Configuring the Server for Performance and

Scalability
Performance is the speed of a single client installation. In tests, Windows Deployment Services
performs on par with a network-based installation from a file share. As expected, factors such as
image size, network speed, and disk speed on the client affect the installation times. Typical
installations using the standard Windows Vista image took around 20 minutes from first client
boot to desktop.
A key benefit of using Windows Deployment Services is the ability to deploy to several clients
simultaneously. Again, many factors influence the solution's ability to scale, but the most
important ones are the following (in order from most to least influential):
1. Network bandwidth. Windows Deployment Services performs best using a 1-GB-per-
second network adapter. In tests, a server with a 100-MB-per-second network adapter could
perform a maximum of 10 simultaneous installations, while keeping the installation time under
an hour (regardless of the server RAM, disk speed, or processor speed). By contrast, a high-
end server with a 1-GB-per-second network adapter could install Windows images on 75
simultaneous clients in 45 minutes.
2. RAM on the server. If the computer has enough available memory, it is possible to
cache an entire image into memory. This reduces the number of disk read/write operations
and, in turn, speeds up the process. If several different images are being deployed
concurrently, you may need more RAM.
3. Disk speed on the server. Disk speed is another factor that can slow down deployments
(even when you have the maximum amount of RAM). The install image must be read from
the disk at least once, and a faster disk speed can accelerate this process.
4. Disk speed on the client. A blockage in the client computer's disk may keep it from
achieving the shortest possible installation times.

Performance and Scalability Expectations

This section outlines the approximate amounts of time that elapsed during the image apply and
TFTP download phases.
• Unicasting
• Multicasting

Unicasting
The following table outlines the hardware configurations of the servers that were used during
these scalability tests.

52
Server type Network interface card Hardware configuration

Low-end 100-MB network adapter • Single-processor x86

• 1 GB of RAM
• 5,400-RPM disk
interface

Middle 100-MB network adapter • Single-processor x86

• 2 GB of RAM
• 7,200-RPM disk
interface

High-end 1-GB network adapter • Dual-processor x64

• 4 GB of RAM
• 10,000-RPM disk
interface

Note
Network configuration for the high-end server involved connecting the server’s GB
network adapter to a GB switch, which was connected to 100-MB switches that
supported a GB back-plane configuration.
Time elapsed during the image apply phase
This table shows the approximate time (in minutes) from start to finish that it took for all of the
clients to apply an install image.

Number of clients Low-end Mid-range High-end

1 25 25 25

10 61 55 25

25 125 117 25

50 235 220 35

75 355 330 45

Time elapsed during the TFTP download phase

The following table shows the time (in seconds) it took to download Boot.wim using TFTP.

Number of clients Low-end Mid-range High-end

1 70 55 40

10 210 145 75

25 450 360 120

53
Number of clients Low-end Mid-range High-end

50 910 805 270

75 1515 1400 420

Time elapsed when the TFTP block was increased

The following table shows the effect on time (in seconds) of changing the default TFTP block size.
The times are cumulative for the total number of clients simultaneously downloading the same
boot image.

Network Number of Default 4,000 8,000 16,000 32,000

adapter clients

GB 50 270 180 118 92 85

GB 75 422 267 171 126 125

100 MB 75 1,410 1,140

Multicasting
Microsoft performed tests to compare the installation times of multicast and unicast transmissions
using the same hardware, software, and image set. The following table outlines the configurations
of the servers and clients that were used during these tests. The boot and install images were
taken from an x86-based version of Windows Server 2008. The size of the boot image was
approximately 128 MB, and the size of the install image was approximately 1.32 GB. Note that
the out-of-box experience (OOBE) and logon were automated by using an unattend file.

Network interface card Hardware configuration Operating system

Server 1-Gbps network • Dual Xenon • 64-bit version of

adapter processor 5150 Windows
• 2.67 Ghz Server 2008

• 8 GB of RAM

Client 100 megabits network • Varied but •

adapter capable of installing
the x86-based
version of Windows
Vista

Multicast Installation

54
 25 clients 100 clients 300 clients

Restart computer and Restart computer and Restart computer and

start clock. start clock. start clock.

Time when the first :23 :21 :23

client started
download of boot
image using TFTP

Time when the last 1:02 2:40 7:16

client finishes
download of boot
image using TFTP

Time when the first 3:04 3:55 8:18

client started the
multicast transfer

Time when the last 6:06 7:54 12:30

client finished the
multicast transfer

Total amount of time 19:47 22:40 27:40

until the last client
reached the desktop

Unicast Installation

SMB 25 clients SMB 100 clients SMB 300 clients

Restart computer and Restart computer and Restart computer and

start clock. start clock. start clock.

Time when the first :21 :22 :20

client started download
of boot image using
TFTP

Time when the last :58 2:40 7:13

client finished download
of boot image using
TFTP

Time when the first 3:14 4:38 8:29

client started image
transfer using
unicast/SMB

55
 SMB 25 clients SMB 100 clients SMB 300 clients

Time when the last 13:36 38:15 1:47:58

client started image
transfer using
unicast/SMB

Total amount of time 20:59 45:37 1:55:15

until the last client
reached the desktop

Testing of Security Options with Multicast

The following table lists the times for the start and end of the multicast transfer of the install
image, and the percentage of the CPU used for the multicast transfer, depending on the level of
security that was enabled during the test. This test involved 25 client computers.

No Security Hashing (default) Signing

Start of multicast Clock started Clock started Clock started

transfer of the install
image to the client

End of multicast transfer 2:19 2:27 31:05

of the install image to
the client

Percentage of CPU ~5% ~11% ~25%

used during the
multicast transfer

Using Transport Server

You have two options when installing the Windows Deployment Services role in Windows
Server 2008. You can install:
• Both the Deployment Server and Transport Server role services (default)
• Only the Transport Server role service
The second configuration is for advanced scenarios, such as environments without Active
Directory Domain Services (AD DS), Domain Name System (DNS), or Domain name system
(DHCP). You can configure Transport Server to enable you to boot from the network using Pre-
Boot Execution Environment (PXE) and Trivial File Transfer Protocol (TFTP), a multicast server,
or both. Note that Transport Server does not contain or support the Windows Deployment
Services image store.

56
In This Topic
• Comparison of Deployment Server and Transport Server
• Configuring Transport Server
• Using a Transport Server to Boot from the Network
• Using a Transport Server for Multicast
• How to create a namespace with Transport Server
• How to join a client computer to a namespace using Wdsmcast.exe
• How to perform common tasks

Comparison of Deployment Server and Transport

Server
The following table compares these two installation options. In general, Deployment Server
enables the end-to-end Windows Deployment Services deployment solution. Transport Server is
a platform that you can use to create a custom multicast deployment solution.

Deployment Server Transport Server

Server requirements
Requires AD DS, Dynamic Does not require other servers
Host Configuration Protocol in the environment.
(DHCP), and Dynamic Name
Services (DNS) in the
environment.

PXE Supports PXE boot with the Supports PXE boot using the
default PXE provider. default PXE provider, or if you
have a custom PXE provider.

Image server Includes the Windows Does not include the Windows
Deployment Services image Deployment Services image
server. server.

Transmission method Allows both unicasting and Allows only multicasting.

multicasting.

Management tools Is managed using either the Is managed only by the

Windows Deployment Services WDSUTIL command-line tool.
MMC snap-in or the WDSUTIL
command-line tool.

Application on the client Uses the Windows Uses only Wdsmcast.exe or

computer Deployment Services client custom application.
(which is basically Setup.exe
and supporting files),
Wdsmcast.exe (which is

57
 Deployment Server Transport Server

included in the Windows AIK),

or a custom multicast
application.

The server architectures are illustrated in the following diagram. The blue parts are installed with
Transport Server and the Deployment Server. The yellow parts are installed with the Deployment
Server only. The grey parts are not installed with either, but can be written using guidelines in the
Windows SDK.

Configuring Transport Server

Transport Server does not require any configuration. However, the following configurations are
optional. After configuring any of these settings, you must restart the WDSServer service to apply
the changes (at an elevated command prompt, run net stop wdsserver, and then run net start
wdsserver.)
• Configure how to obtain IP addresses. If multiple servers are using multicast
functionality on a network (Transport Server, Deployment Server, or another solution), it is
important that each server is configured so that the multicast IP addresses do not collide.
Otherwise, you may encounter excessive traffic when you enable multicasting. Note that each
Windows Deployment Services server will have the same default range. To work around this
issue, specify static ranges that do not overlap to ensure that each server is using a unique IP
address, or configure each of the servers to obtain multicast addresses from a Multicast
Address Dynamic Client Allocation Protocol (MADCAP) server.
• To use MADCAP for IP addresses, run WDSUTIL /Set-TransportServer
/ObtainIPv4From:DHCP at an elevated command prompt.

58
 • To defined range for IP addresses, run WDSUTIL /Set-TransportServer
/ObtainIPv4From:Range /Start:<start Ipv4 Address> /End:<end Ipv4 Address> at an
elevated command prompt.
• Set the network profile. The network profile specifies the network speed of the
Transport Server. Each profile contains settings to optimize performance for the specified
speed (such as the maximum transport window size, the transport cache size, and the block
size). You can view the profiles at
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\
Multicast\Profiles. Specify Custom if you want to customize the settings yourself by editing
the registry. You should not modify the other profiles that are provided. You should use the
custom profile even if you only want to change one setting. To set the profile, run
WDSUTIL /Set-TransportServer [/Server:<name>] /Profile:{10Mbps|100Mbps|1Gbps|
Custom} at an elevated command prompt.

Caution
To modify the registry settings that are described in this guide, use only the Windows
Deployment Services management tools—you should not directly edit these settings
and attributes.
• Set the UDP port range. To do this, run WDSUTIL /Set-TransportServer
[/Server:<name>] /StartPort:x /EndPort:y at an elevated command prompt.

Using a Transport Server to Boot from the

Network
A PXE server consists of two parts: a PXE listener that accepts incoming traffic, and a PXE
provider that determines how best to respond to it. Transport Server contains only the PXE
listener. In order to use Transport Server to boot a computer from the network, you will need to
write a custom PXE provider, and register the provider with Windows Deployment Services, as
documented in the Windows Server 2008 Software Development Kit (SDK).

Using a Transport Server for Multicasting

The multicast server in Windows Deployment Services also has two parts – the multicast provider
(which transmits data over the network) and the content provider (which understands the data
and passes it to the multicast provider). The content provider (installed with both Transport Server
and Deployment Server) can be used to transfer any file. It also has specific knowledge of the
.wim format, which it uses to transfer images while other images are added to the image group.
You can create a custom content provider for cases where the default provider is not sufficient
(for example when using Transport Server to deploy an operating system from inside a .vhd
image). See the Windows Server 2008 SDK for guidelines and samples for authoring and
registering the provider.

59
How to create a namespace with Transport Server
Transport Server transmits data by using multicast functionality through an object called a
namespace. A namespace is analogous to a multicast transmission used by Deployment Server.
A namespace consists of content to transfer (determined by the content provider with a
configuration string), configuration settings (for example, Scheduled-Cast or Auto-Cast), and the
names of connected clients. In this section:
• Prerequisites for creating a namespace
• Namespace types
• To create a namespace

Prerequisites for creating a namespace

To create a namespace with Transport Server, you need the following:
• A content provider. You can use the Windows Deployment Services content provider
(named WDS) that is included when you install Transport Server. Or you can create your own
content provider by using the tools in the Windows Server 2008 SDK.
• Data to transmit. You can transmit any data that your content provider knows how to find
(for example operating system images, data files, or an MP3 archive). The Windows
Deployment Services content provider knows how to find any file within a folder.
• Familiarity with WDSUTIL. The only way to manage Transport Server is through the
WDSUSTIL command-line tool.
• A way to boot clients. This is because Transport Server does not include a PXE
provider (such as BINLSVC).
• Routers. The routers in your environment must support multicasting. In particular, your
network infrastructure needs to support the Internet Group Management Protocol (IGMP) to
properly forward multicast traffic. Without the IGMP, multicast packets are treated as
broadcast packets, which can lead to network flooding.

Namespace types
There are two types of multicast namespace:
• Auto-Cast. This option indicates that as soon as a client requests the data, a multicast
namespace begins. Then, as other clients request the data, they too are joined to the
namespace that has already started.
• Scheduled-Cast. This option sets the start criteria for the namespace, based on the
number of clients that are requesting the data and/or a specific day and time. After a
Schedule-Cast namespace has been started, new clients will not be able to join the
namespace. If it is imperative that clients be able to join a namespace that is already in
progress, use an Auto-Cast namespace.

60
To create a namespace
You can create Scheduled-Cast and Auto-Cast namespaces. For more information about each
parameter, see Options.
• To create a Scheduled-Cast namespace
Syntax: WDSUTIL /New-Namespace [/Server:<server name>] /Namespace:<namespace
name> /FriendlyName:<friendly name> [/Description:<description>]
/ContentProvider:<name> /ConfigString:<config string> /NamespaceType:ScheduledCast
[/Time:<YYYY/MM/DD:hh:mm>] [/Clients:<number of clients>]
For example: WDSUTIL /New-Namespace /Server:MyWDSServer
/FriendlyName:"Custom Scheduled Namespace" /Namespace:"Custom Scheduled
1" /ContentProvider:WDS /ConfigString:D:\Images /NamespaceType:ScheduledCast
/Time:"2006/11/20:17:00" /Clients:20
• To create an Auto-Cast namespace
Syntax: WDSUTIL /New-Namespace [/Server:<server>] /Namespace:<namespace name>
/FriendlyName:<friendly name> [/Description:<description>] /ContentProvider:<name>
/ConfigString:<config string> /NamespaceType:AutoCast
For example:
WDSUTIL /New-Namespace /FriendlyName:"Custom AutoCast Namespace"
/Namespace:"Custom Auto 1" /ContentProvider:WDS /ConfigString:D:\Images
/NamespaceType:AutoCast

How to join a client computer to a namespace by using

Wdsmcast.exe
The Windows Deployment Services client user interface will not work with Transport Server.
Therefore, to connect a client to a namespace, you have two options:
• Use Wdsmcast.exe, which is included in the Windows Automated Installation Kit (AIK).
This is a command-line utility you can use to connect to any namespace or multicast
transmission that uses the Windows Deployment Services content provider. For more
information about this, see the following procedure. You can download the Windows AIK at
http://go.microsoft.com/fwlink/?LinkID=54863.
• Use a custom deployment client. You can do this by using the APIs of the Windows
Deployment Services transport client. You will need to create a custom client if you are using
a custom content provider. For instructions on how to do this, see the Windows Server 2008
SDK.

To join a namespace by using Wdsmcast.exe

1. Mount the image by using Imagex.exe, and then copy the Wdsmcast.exe into the
System32 folder in the image.
2. Boot the client computer to the image (from a CD, DVD, or USB drive, or by using the
PXE capability in Transport Server).

61
 3. Start Microsoft Windows Preinstallation Environment (Windows PE) networking by
running WPEINIT on the client computer.
4. From the client computer, run a command with the following syntax (the following
table explains these options):
WDSMCAST /Transfer-File /Server:<server name> /Namespace:<namespace name>
/Username:<domain and user name> [/Password:<password>] /SourceFile:<file path>
/DestinationFile:<file path>

Syntax:

Option Description

/Server:<server name> The name of the Windows Deployment Services server. This can be
either the NetBIOS name or the fully qualified domain name
(FQDN). If the server name is not specified, the name of the local
server will be used.

/Namespace:<namespace The name of the namespace. This value should match the name
name> given when creating the namespace on the server. This is not the
"friendly" name, and it must be unique.

Note
When using this option with Deployment Server, the syntax
is as follows:
/Namespace:WDS:<ImageGroup>/<ImageName>/<Index>.
For example: WDS:ImageGroup1/install.wim/1

Note
To view all namespaces that currently exist on the server,
run WDSUTIL /get-allnamespaces.

/Username:<domain and The domain name and user name to connect to the server. These
user name> can be either in the format Domain\User or the format
User@Domain.

[/Password:<password>] The password for the user. If this is not specified, you will be
prompted to enter it.

/SourceFile:<file path> The path to the file to be transferred, relative to the root folder of the
content provider (for example, if you are using the Windows
Deployment Services content provider (named WDS), the path is
relative to the ConfigString folder).

/DestinationFile:<file path> The complete file path and name for the destination file.

62
How to perform common tasks
The following are the most commonly used commands with Transport Server. For more
information about each parameter, see Options.
• To start the transmission. To start a transmission, the transmission must be a
Scheduled-Cast namespace, and there must be at least one client that has requested the
transmission of data.
Syntax: WDSUTIL /Start-Namespace /Namespace:<name>
• To display information for the clients that are connected to a namespace (for
example, computer name, MAC address, IP address, speed, and percent complete)
Syntax: WDSUTIL /Get-Namespace /Namespace:<name> /Show:Clients
• To remove a namespace
Syntax: WDSUTIL /Remove-Namespace [/Server:<server name>] /Namespace:<namespace
name> [/Force]
For example:
• To remove the namespace after current client downloads are complete, run:
WDSUTIL /Remove-Namespace /Namespace:"Custom Auto 1"
• To remove the namespace immediately and stop any current client downloads, run:
WDSUTIL /Remove-Namespace /Server:MyWDSServer /Namespace:"Custom Auto
1" /Force
• To stop a client installation completely
Syntax: WDSUTIL /Disconnect-Client /ClientID:<id> /Force

Important
You should use this option with caution because the installation will fail and the
computer could be left in an unusable state.
• To discontinue the download for a client but continue to transfer the image through
another method (such as SMB copy). The client will fall back to another method of transfer
only if the client implementation supports this behavior. Although the Windows Deployment
Services client will fall back to SMB transfer, note that Wdsmcast.exe does not support any
fallback mechanism.
Syntax: WDSUTIL /Disconnect-Client /ClientID:<id>
• To view the client <id> for each namespace
Syntax: WDSUTIL /Get-Namespace /Namespace:<name> /show:clients
• To view all clients connected to all namespaces on the server
Syntax: WDSUTIL /Get-AllNamespaces

63
Options
The options in the following table apply to the sections "Creating a namespace with Transport
Server" and "Using common commands" earlier in this chapter.
Option
/Server:<server name>
/Namespace:<Namespace
name>
/FriendlyName:<friendly
name>
/Description:<description>
/ContentProvider:<name>
/ConfigString:<config string>
/NamespaceType: {AutoCast|
ScheduledCast}
/ The time on the server when the namespace will start (note that
Time:<YYYY/MM/DD:hh:mm
>
/Clients:<Num of Clients>
Description
The name of the Windows Deployment Services server. This can
be either the NetBIOS name or the FQDN. If the server name is
not specified, the name of the local server will be used.
The name of the namespace. This value should match the name
given when creating the namespace on the server. Note that this
is not the "friendly" name, and it must be unique.
Note
When using this option with Deployment Server, the
syntax is as follows:
/Namespace:WDS:<ImageGroup>/<ImageName>/<Index
>. For example: WDS:ImageGroup1/install.wim/1
Note
To view all namespaces that currently exist on the server,
run WDSUTIL /get-allnamespaces.
The friendly name of the namespace. Note that this name does
not need to be unique.
A short description of the namespace.
The name of the content provider that supplies data to the
multicast server. If you are using the Windows Deployment
Services content provider, specify WDS.
The configuration string for the content provider. If you are using
the Windows Deployment Services content provider (WDS),
specify the path to the folder where content is stored (for
example, D:\Photos\Landscapes). This path can be anywhere on
the server.
The type of namespace to be created.
you can set this option only for Scheduled-Cast transmissions).
The number of clients to wait for before the namespace will start
64
Option Description

(note that you can set this option only for Scheduled-Cast
transmissions).

/Force An option that deletes the transmission, even if there are current
client installations. If you do not specify /Force, the transmission
will be in the Delete Pending state, meaning that the
transmission will be removed after clients' downloads are
completed.

Performing Unattended Installations

You can configure the entire deployment process using Windows Deployment Services to be
without user interaction. To do this, you will need to automate the PXE boot, the selection of a
boot image, and Setup.
• Automating the PXE Boot
• Automating Setup
• Automating the Domain Join and Computer Naming
• Automating the Image Capture Wizard
• Advanced Unattended Installation Scenarios
• Sample Unattend Files

Automating the PXE Boot

In This Topic
• Overview
• Avoiding a Boot Loop
• Automating the Selection of the Boot Image

Overview
Settings for automating Pre-Boot Execution Environment (PXE) boots are contained both within
and outside of Windows Deployment Services.
First, you must configure the client computer to perform PXE boots automatically. You can do this
by modifying the boot order in the computer’s firmware (BIOS or Extensible Firmware Interface
(EFI)) or by disabling any active partitions before booting.

65
 • If there are active partitions, the option to boot from the network must be higher in the
boot sequence than the hard disk drive.

Important
This configuration is susceptible to a boot loop, a condition that causes a computer to
always boot from the network, and never from the hard disk drive. For more details,
see Avoiding a Boot Loop.
• If there are no active partitions, the computer will be unable to boot from the hard disk
drive, and it will proceed to the next boot item in the boot order. As such, we recommend that
you include the option to boot from the hard disk drive before the option to boot from the
network (to avoid a boot loop).
Second, the network boot program (NBP) that is downloaded by the client computer must
automatically continue the boot process without user interaction (for example, by pressing F12).
You can configure this by doing one of the following:
• Specifying the default NBP of the server (per architecture) so that all clients receive the
*.N12 boot program.
• Specifying the boot program for a particular client so that only that client receives the
*.N12 boot program.
• Setting the AllowN12ForNewClients option and then booting a computer that is not
prestaged.

Note
There are not multiple NBPs for EFI computers; a single program handles all boot
cases. Therefore, you must configure this setting within the EFI shell.
For a list of the NBPs, see the "List of NBPs" section in Managing Network Boot Programs.

Avoiding a Boot Loop

When implementing a fully automated experience of booting from the network, it is often
necessary to do the following:
• Set the network as the first item in the client’s BIOS boot order.
• Send a specific client an .N12 NBP.
If you combine these two configurations, the client will automatically boot from the network
without requiring user intervention, and the computer will end up in a circular loop (always booting
from the network and never booting from the hard disk drive).
The following are best practices that you can use to avoid a boot loop:
• Always configure the hard disk drive as a higher priority than the network. To
enable a computer that already has an operating system installed to boot automatically from
the network (for example, when reprovisioning a computer), disable any active partitions
before rebooting the computer to initiate the PXE boot.
• For prestaged computers that are configured to boot from the network before
booting from the hard disk drive, toggle the BootProgram value between *.N12 and

66
 *.COM to control the automatic PXE boot behavior. For example, set it to
boot\x86\pxeboot.n12 when you want to boot the computer from the network, and set it to
boot\x86\abortpxe.com when you want to boot from the hard disk drive. For instructions on
how to do this, see How to Manage Client Computers.
• For nonprestaged computers that are configured to boot from the network before
booting from the hard disk drive, set the server default NBP to *.COM and configure
the AllowN12ForNewClients option. This will prevent a boot loop if both of the following are
true: the booting client will perform an operating system installation by using Windows
Deployment Services, and the client computer is configured to join a domain, which is the
default.

Example Boot Loop

Consider the following situation. Computer A has been configured with the following boot order:
1. CD-ROM
2. Network
3. Hard disk
On the Windows Deployment Services server, the default NBP setting for x86-based computers is
boot\x86\pxeboot.n12, which is an NBP that does not require pressing F12 to boot from the
network. The following sequence of events will result in a boot loop:
1. The computer is turned on.
2. Assuming there is not a bootable CD, the computer boots from the network, downloads
Windows PE from the Windows Deployment Services server, and proceeds through the user
interface of the Windows Deployment Services client.
3. The image installation to the hard disk drive begins.
4. After the image is applied, the computer reboots.
The boot order sequence still specifies the network as a higher priority than the hard disk drive.
And, the NBP received by the client is still *.N12, which causes the computer to continue the
process of booting from the network. As a result, the image that was just applied to the hard disk
drive will never be booted.

Automating the Selection of the Boot Image

Windows Deployment Services displays a menu that enables users to select a boot image. This
menu is always automated, and when there are multiple boot images, one will be selected by
default when the time-out value expires (which is configurable by using the Bcdedit tool).
However, if there is only one boot image available to the client computer, it will be selected
immediately. For more information about the boot menu, see Managing the Boot Menu.
Because the boot menu selection does not require any user action, the only configuration task
that you need to complete is to ensure that clients are directed to the correct default boot image.
There are two methods for doing this:

67
 • Configure the default boot image at the server level. This setting would apply to all clients
(of a particular architecture) that connect to the server. This option works for both prestaged
and unknown computers.
• Configure the default boot image for a client by running the command WDSUTIL /Set-
Device /Device:<name> /BootImagePath:<path>, where <path> is the relative path to the
desired boot image from the RemoteInstall folder. This option works only for prestaged
computers.

Automating Setup
For step-by-step instructions, see the Step-by-Step Guide for Windows Deployment Services in
Windows Server 2008.

In This Topic
• Overview
• Automating the User Interface Screens of the Windows Deployment Services client
• Automating the Remaining Phases of Setup

Overview
Unattended installations can be complicated. This chapter presents key points that you should
understand and remember when you are automating Setup for Windows Deployment Services.
Specifically, you should keep the following in mind:
• There are two unattend files used during Windows Deployment Services
installations. One of the unattend files automates the Windows Deployment Services client
user interface (UI) screens, and the other one automates the remaining phases of setup.
• Windows Deployment Services client unattend file. This file uses the
Unattend.xml format and is stored on the Windows Deployment Services server in the
C:\RemoteInstall\WDSClientUnattend folder. It is used to automate the Windows
Deployment Services client user interface screens (such as the screens for entering
credentials, choosing an install image, and configuring the disk). For more information,
see Automating the Windows Deployment Services client later in this topic.
• Image unattend file. This file uses either the Unattend.xml or Sysprep.inf format,
depending on the version of the operating system in the image. It is stored in a subfolder
(either $OEM$ structure or \Unattend) in the per-image folder. It is used to automate the
remaining phases of setup (for example, offline servicing, specialize pass with Sysprep,
and Mini-Setup). For more information, see Automating the Remaining Phases of Setup
later in this topic.
Two unattend files are necessary because the Windows Deployment Services client can
deploy two image types: Windows Vista and Windows Server 2008 images that support the

68
 Unattend.xml format, and Windows XP and Windows Server 2003 images, which do not
support the Unattend.xml format.
• The Windows Deployment Services client processes only settings in the
Windows PE section of the unattend file. It will not process settings in any other sections
of that file, nor will it pass on the client unattend file for further processing after the image is
applied, unless at least one of the following is true:
• You have configured command-line precedence and are using an unattend file that
was passed to Setup through the command line. For precedence information, see
Advanced Unattended Installation Scenarios.
• You do not have an image unattend file, and the client is not configured to join a
domain.
• It is possible to use a single unattend file throughout the entire installation
process. To do this, you must pass an unattend file to Setup.exe with the
/unattend:<unattend file> option, and you must configure the command-line unattend
precedence appropriately. For precedence information, see Advanced Unattended Installation
Scenarios.
• Windows Deployment Services supports implicit unattend searching and can be
used in conjunction with AutoUnattend.xml. For more information about implicit search
paths, see “Methods of Running Windows Setup” in the Windows AIK documentation
(http://go.microsoft.com/fwlink/?LinkId=96016).

Automating the User Interface Screens of the

Windows Deployment Services client
The Windows Deployment Services client (which is basically Windows Vista Setup.exe and
supporting files) uses the Unattend.xml format. To completely automate the UI screens, you must
specify settings that correspond to each screen. Unfortunately, this is not easy to figure out
because of the Unattend.xml design.
Unattend.xml is organized by the phases of unattend setting processing. As a result, there is not
always a 1:1 mapping relationship between a particular setting and a UI screen. In addition, not
all of the settings that are necessary to automate the UI screens for the Windows Deployment
Services client are grouped within the file. We recommend that you use Windows System Image
Manager (Windows SIM) to author the Windows Deployment Services client unattend file
because it abstracts the format of the unattend file and makes for a simplified authoring
experience.
Some of the settings in Unattend.xml that are processed by the Windows Deployment Services
client are identical in syntax and form to other sections supported by Windows Vista Setup. For
example, the DiskConfiguration setting used by the Windows Deployment Services client is
identical to the DiskConfiguration section used by Setup. Other settings are specific to Windows
Deployment Services (these reside in the WindowsDeploymentServices section) and are
processed only when Setup.exe is running in Windows Deployment Services mode.

69
After authoring the unattend file by using Windows SIM, copy the file to the \WDSClientUnattend
folder and then associate it with an image by using the management tools. You can give the file
any name you want, but it must be an .xml file. For step-by-step instructions, see the Step-by-
Step Guide for Windows Deployment Services in Windows Server 2008.

Unattend File Settings

The settings in the following table must be specified in the Windows Deployment Services client
unattend file to completely automate the client experience. You can find the complete details of
these settings in the Windows AIK documentation (http://go.microsoft.com/fwlink/?LinkId=96016).
For examples, see Sample Unattend Files.

UI page Component Unattend setting Explanation

Language- Microsoft-Windows- SetupUILanguage Specifies the

neutral page International-Core-Windows PE language for the
Windows
Deployment
Services client UI.
This setting is
required only when
the boot image has
setup resources for
multiple languages.

Welcome and Microsoft-Windows- InputLocale Specifies the

keyboard International-Core-Windows PE computer's input
selection page locale and the
keyboard layout for
the selected
image. If this
setting is not
specified, a default
will be chosen
based on
UILanguage.
Even if
<InputLocale> is
properly configured
not to display UI,
the welcome page
will be displayed if
the credentials
page
<WillShowUI>

70
UI page Component Unattend setting Explanation

value is set to
Always.

Credentials Microsoft-Windows-Setup -> Credentials Specifies the user

page WindowsDeploymentServices name, domain, and
-> Login password of an
account with
proper permissions
to install the
specified image.

Image selection Microsoft-Windows-Setup -> InstallImage Specifies the

page WindowsDeploymentServices image to be
installed.

Image selection Microsoft-Windows- UILanguage Specifies the

page International-Core-Windows PE language for the
selected image. If
this setting is not
specified or if the
specified value
does not match
any of the available
install languages,
the image selection
page will be
displayed.
Do not specify this
value if
InstallImage is a
Windows
Server 2003,
Windows 2000, or
Windows XP
image. In those
cases, this setting
does not apply and
will cause an error
(which causes the
image selection
page to appear).

Image selection Microsoft-Windows- UILanguageFallback Specifies the

page International-Core-Windows PE language to be

71
UI page Component Unattend setting Explanation

used if the
computer's default
UI language is only
partially localized
for the selected
image.

Disk Microsoft-Windows-Setup -> Disk Specifies the disk

configuration DiskConfiguration configuration
page settings.

Disk Microsoft-Windows-Setup -> InstallTo Specifies the disk

configuration WindowsDeploymentServices and partition to
page -> ImageSelection which the selected
image is to be
installed.

Automating the Remaining Setup Phases

The remaining phases of Setup are handled by Unattend.xml for Windows Vista or by Sysprep.inf
for earlier version of Windows.
• Unattend.xml. You should author Unattend.xml by using Windows SIM, save it to a
known location, and then associate the file with an image using the management tools. The
Unattend.xml file that you specify will be renamed ImageUnattend.xml and copied to the
<ImageName>\Unattend folder. For example, if the image was named x86install.wim, the
Unattend.xml file would be copied to
C:\RemoteInstall\Images\ImageGroup1\x86install\Unattend\ImageUnattend.xml.
• Sysprep.inf. You should author Sysprep.inf by using Setup Manager and then place it in
the correct per-image unattend location. Finally, associate the image unattend file by using
the management tools.
For examples of these setup tasks, see Sample Unattend Files.

Automating the Domain Join and Computer

Naming
By default, all operating system installations using Windows Deployment Services result in a
client computer that is joined to a domain. If a client computer is prestaged in Active Directly
Domain Services (AD DS), the client will be joined to the domain as the prestaged computer. For
more information about prestaged computers, see Prestaging Client Computers. For instructions

72
on setting this option, see the "Prestage Computers" section in How to Manage Client
Computers.

In This Topic
• Creating Unattend Files
• Ensuring Proper Rights
• Ensuring Security

Creating Unattend Files

The domain join and computer naming processes use the image unattend file to pass data that is
collected within Windows PE to the subsequent phases of Setup.exe. If an image is associated
with an image unattend file, the domain join and computer name settings will be made directly to
this file. However, for this to occur, you must properly the file correctly (see the Sample Unattend
Files). Specifically, this means as follows:
• For Windows Vista or Windows Server 2008 images. The image unattend file
(ImageUnattend.xml) must have the setting <UnsecureJoin>true</UnsecureJoin> in the
Microsoft-Windows-UnattendedJoin component. Additionally, the Microsoft-Windows-
Shell-Setup component for the <specialize> unattended pass must exist, even if it is empty.
• For Windows XP and Windows Server 2003 images. The image unattend file in the
$OEM$ structure (Sysprep.inf) must have the setting DoOldStyleDomainJoin=Yes, and it
must have (at a minimum) the [Networking] and [UserData] sections, even if they are
empty.
If the image unattend file does not contain the proper formatting, Windows Deployment Services
will assume that you have chosen to override or avoid the domain join and computer name
functionality and therefore will not edit the unattend file. If a selected image does not have an
associated image unattend file, a template unattend file will be used to pass domain join and
computer naming information throughout the installation process.
• For Windows Vista or Windows Server 2008 images, this file exists within the image itself
as \System32\WDSUnattendTemplate.xml. Therefore, after the image is applied, the template
file will be located offline on the disk.
• For Windows XP and Windows Server 2003 images, this file exists in the
\RemoteInstall\Templates\Sysprep.inf folder on the server when the server is first initialized.
After the image is applied, Windows Deployment Services will copy the template Sysprep.inf
into the offline image and then edit it as appropriate. This file is copied from the server into
the offline image as C:\Sysprep\Sysprep.inf.

Ensuring Proper Rights

Domain join and computer naming require two sets of rights:

73
 • Rights to create computer objects in AD DS (this is required if you are not using
prestaged computer objects).
• Rights to perform the actual domain join. These rights can be further subdivided into two
specific tasks: rights to reset the computer account, and rights to perform the domain join.
All of this is covered in greater detail in Required Permissions.

Ensuring Security
For providing credentials in an unattend file, there are two permissions methods, that enable a
computer to join a domain: unsecure join and secure join. Both of these methods are described in
the following table.

Unsecure join Secure join

This method involves resetting the computer
account to a known, shared computer
password and enabling the computer to join a
domain without credentials. For Windows Vista
and Windows Server 2008 images, this shared
computer password is a dynamically generated,
strong password that is set by Windows
Deployment Services. The password is inserted
into the ImageUnattend.xml file as the
<ComputerPassword> setting. For images
from an earlier version of Windows, this shared
computer password is the computer name.
• Advantages: This method does not
require placing unattend credentials in plain
text in the unattend file.
• Disadvantages: It is possible for a
malicious user to join the domain between To implement a secure join, do the following to
the time the computer account was reset the unattend file:
(in Windows PE) and when the actual
domain join occurs (on first boot of the
applied image). This particular attack is
effectively mitigated with Windows Vista
and Windows Server 2008 images because
the password is dynamically generated.
To implement an unsecure join, set
UnsecureJoin = TRUE and ensure that the
Microsoft-Windows-Shell-Setup component
exists for the specialize phase.
This method is secure in the sense that it
requires credentials (user name, domain, and
password) before you can reset the account
and perform the domain join. However, in
practice this method is actually less secure
because the credentials reside in the
ImageUnattend.xml file in plain text.
• Advantages: This method uses a
simplified permissions model because a
single account is used throughout the
enterprise to perform all domain join
operations.
• Disadvantages: Credentials are stored
in plain text in the image unattend file,
which is located on a shared folder on the
Windows Deployment Services server.
1. Set UnsecureJoin = FALSE.
2. Specify the credentials for performing
the domain join, and the domain that you
want to join the computer to.
3. Ensure that the Microsoft-Windows-
Shell-Setup component exists for the
specialize phase.
4. Set the <ComputerName> value to
%MACHINENAME%. During installation,
Windows Deployment Services will retrieve
the name of the prestaged account from
74
Unsecure join Secure join

AD DS and replace the %MACHINENAME

% string with the actual computer name.

Automating the Image Capture Wizard

The Image Capture Wizard will run in unattended mode when the WDSCapture.inf file exists in
the same folder as the WDSCapture.exe file (that is, X:\Windows\System32 within the image),
and Unattended=Yes is specified in the file. If unattended mode is set to No but WDSCapture.inf
exists and has settings defined, those settings will be used to create the wizard's dialog boxes.

Creating a WDSCapture.inf Unattend File

This section explains the format for WDSCapture.inf files.
• [Capture]. Contains all of the capture settings for the Image Capture Wizard, as
described in the following table.

75
Setting Description

Unattended=Yes|No Specifies whether the wizard should be in

unattend mode.
• Yes. Specifies that the wizard is in
unattend mode, and suppresses all pop-
ups and user interface elements. All
unattend settings are read out of this file.
• No. Specifies that the wizard is not in
unattend mode, and uses values in the
file to prepopulate the user interface.

VolumeToCapture Specifies the volume that is holding the

Windows installation to be captured. This
setting must be in the following format: drive
letter, colon, back slash. For example: c:\

ImageName Specifies the value to be set as the image

name within the image metadata. This will be
the image name as displayed in the Windows
Deployment Services management tools and
the user interface of the Windows
Deployment Services client. (The Windows
Deployment Services client is basically
Setup.exe and supporting files.)

ImageDescription Specifies the value to be set as the

description within the image metadata. This
will be the image name as displayed in the
Windows Deployment Services management
tools and the user interface of the Windows
Deployment Services client.

DestinationFile Specifies the full path and name of the .wim

file to which the image is to be captured.

SystemRoot The name of the system root folder. If this

setting is not specified, \Windows, \Winnt,
and \i386 will be tried. The Image Capture
Wizard must locate the system root to extract
the data needed to form the metadata (for
example, the version of the operating system
and installed languages) that is added to
the .wim during the capture.

76
Setting Description

Overwrite=Yes|No|Append (Default=No)
Designates whether the file specified in
DestinationFile should be overwritten if a file
with that name already exists in the specified
location.
• Yes. Specifies to overwrite the
existing file.
• No. The process will cause an error if
a file with the same name already exists
in the specified location.
• Append. If a .wim file with the same
name already exists, the capture should
be appended as a new image within the
existing .wim file. This setting often
produces a much faster capture because
when files from the current capture
operation already reside in the .wim file
(for example, if file resources in another
image already exist in the .wim file), the
files are not copied into the .wim file
again. The image name specified must
be unique within the .wim file; otherwise,
you will receive an error.

• [ExclusionList]. Defines the files and folders to be excluded from the capture. By
default, this section is populated with the following items: $ntfs.log, hiberfil.sys, pagefile.sys,
System Volume Information, RECYCLER, winpepge.sys, and %SYSTEMROOT%\CSC. Note
that the %SYSTEMROOT% variable is replaced by the value specified in SystemRoot in the
[Capture] section.
• [WDS]. Contains all of the Windows Deployment Services-specific unattend settings.

77
Setting Description

UploadToWDSServer=Yes|No (Default=No) Specifies whether the resulting

image should be added to a Windows
Deployment Services server's image store. If
this value is set to No, all other settings
under the [WDS] section will be ignored.

WDSServerName Specifies the name of the Windows

Deployment Services server. This can be
either a NetBIOS name or a fully qualified
domain name (FQDN).

WDSImageGroup The name of the image group on the

specified Windows Deployment Services
server.

Username The user name to use when connecting to

the specified Windows Deployment Services
server. This name can take either of the
following forms: domain\username or
username@domain.com.

Password The password of the user account.

Note
We recommend that you enter
credentials in the wizard user
interface (UI). Credentials specified
in WDSCapture.inf are stored in
plain text within the capture image,
and there is no way to secure these
credentials.

DeleteLocalWIMOnSuccess=Yes|No Specifies whether the local capture image

(where the capture image was saved) will be
deleted at the end of the process, assuming
that the image is successfully uploaded to
the Windows Deployment Services server.
You should be careful when using this option
with the Overwrite=append option because
the entire image will be deleted (not just the
new .wim that was appended to the existing
image).

78
Sample WDSCapture.inf Unattend File
The following code is a sample WDSCapture.inf file:
[Capture]

Unattended=Yes

VolumeToCapture=C:\

SystemRoot=Windows

ImageName=”Windows Vista with Microsoft Office”

ImageDescription=”Windows Vista image for the sales department. Also contains Office
2007.”

DestinationFile=C:\temp\VistaImageWIM

Overwrite=No

[ExclusionList]

$ntfs.log

hiberfil.sys

pagefile.sys

"System Volume Information"

RECYCLER

winpepge.sys

%SYSTEMROOT%\CSC

[WDS]

UploadToWDSServer=Yes

WDSServerName=MyWDSServer

WDSImageGroup=ImageGroup1

Username=Contoso\WDSAdmin

Password=Password1

DeleteLocalWimOnSuccess=No

Advanced Unattended Installation Scenarios

There are several advanced unattended installation scenarios that you can implement with
Windows Deployment Services.

79
In This Topic
• Passing Unattend Files to Setup by Using the Command Line
• Using Implicit Unattend Files
• Embedding an Unattend File in an Image
• Precedence
• Unattend File Precedence
• Command-Line Precedence
• Using Variables to Obtain Information from the Client

Passing Unattend Files to Setup by Using the

Command Line
It is possible to pass an unattend file directly instead of obtaining the unattend file from the server.
For example:
1. A client computer boots into a version of Windows PE that contains the Windows Vista
Setup files. The client boot can be performed over the network, from a CD or DVD, or from
the hard disk drive.
2. A custom application is invoked, which has a customized user interface (UI).
3. The application detects the computer’s MAC address and contacts a database to get the
correct unattend file.
4. The application uses the Windows Deployment Services client (which is essentially
Setup.exe and supporting files) to retrieve a list of available images that are stored on a
Windows Deployment Services server, and then it displays this list to the user.
5. The user selects an image.
6. The application takes the selected image and inserts the relative data into the unattend
file.
7. The application invokes Setup.exe in Windows Deployment Services mode, and then it
passes Setup.exe an unattend file.
8. The installation proceeds.
In scenarios such as the preceding one, you can use the /unattend:<unattend file> option with
the /wds option (for example, Setup.exe /WDS /Unattend:X:\WDSClientUnattend.xml). If you
are booting Windows PE by using a CD, DVD, or hard disk drive, you must also invoke the
Windows Deployment Services client in discover mode by using the /WDSDiscover option.
As is also the case when receiving the Windows Deployment Services client unattend file from
the server, the unattend file that you passed by using the command line will be used only for the
Windows PE phase. Settings corresponding to other unattended passes will be handled by the
image unattend file.

80
Using Implicit Unattend Files
You can use implicit unattend files, which means that if an unattend file is not specified (through
the command line or from the Windows Deployment Services server), the client searches for an
unattend file in several locations. The most common scenario involves using a file called
AutoUnattend.xml, which is at the root of removable media (such as a CD, DVD, or USB flash
drive). For more information about implicit search paths, see “Methods of Running Windows
Setup” in the Windows AIK documentation (http://go.microsoft.com/fwlink/?LinkID=90643).

Embedding an Unattend File in an Image

In general, it is a best practice to store unattend files outside of the images with which they are
associated. The main reason for this is flexibility; it is easier to modify an image that is sitting on a
file share on the Windows Deployment Services server than it is to mark an image offline, export
the image, mount it, modify the unattend file, and then reimport the image. However, there are
some cases where you may want to include the unattend file in a boot or install image. The
following is an example of a scenario in which you may want to do this.
There are two types of computers in your organization — laptops and desktops. Your company
policy states that all laptops should be configured with two partitions to support BitLocker Drive
Encryption, and desktops should have a single partition and do not need BitLocker support. You
create a custom boot image that is configured to run a simple script. The first action in the script
is to use Windows Management Instrumentation (WMI) calls to determine whether a particular
booted client computer is a laptop or a desktop.
• If the computer is a laptop, the script calls Setup.exe by using the /wds option and then
passes an Unattend.xml file for laptop use (one that creates two hard disk partitions).
• If the computer is a desktop, the script calls Setup.exe by using the /wds option and then
explicitly passes an Unattend.xml file for desktop use (one that creates only a single
partition).

Precedence
This section explains precedence for unattend files and the command line.

Unattend File Precedence

The following list outlines the precedence order of the available unattend files. Be aware that you
cannot change this precedence order.
The default order of precedence for Windows Deployment Services client unattend files is as
follows:
1. Unattend files that are passed explicitly from the command line (for example,
setup.exe /wds /unattend:<unattend file>)
2. Unattend files that are passed to the client by the Windows Deployment Services server
3. An implicit unattend file (AutoUnattend.xml)

81
 Note
This means that a Windows Deployment Services client unattend file that is defined
always overrides an implicit unattend file.
The default order of precedence for image unattend files is as follows:
1. Explicitly assigned image unattend files (Windows Vista images only)
2. Image unattend files in the $OEM$ structure
3. Template unattend files (used as part of a domain join)
4. Client unattend files that have been carried over into additional phases of unattend
processing

Command-Line Precedence
There are installation scenarios in which you may want to use the same Unattend.xml file for
automating the Windows Deployment Services client and subsequent phases of Setup when
performing a custom deployment solution. Note that command-line precedence does not apply to
Windows Deployment Services client unattend files that are obtained from the Windows
Deployment Services server.
By setting the command-line precedence value, you can specify whether another unattend file
(either an implicit unattend file such as AutoUnattend.xml, or an unattend file passed by using the
/Unattend option) will be used instead of the image unattend file when installing a client
computer. To override an existing image unattend file associated with an image, first enable
unattend installations by running the command wdsutil /set-server /wdsunattend /Policy:
{Enabled | Disabled} and then running wdsutil /set-server /wdsunattend
/CommandlinePrecedence:{Yes|No}. For details, see How to Manage Your Server.

Example Scenario
This section presents an example of a precedence scenario.
There are two types of computers in your organization — laptops and desktops. Your company
policy states that all laptops should be configured with two partitions and should contain the
proper Bluetooth drivers and software. It also states that desktops should have a single partition
and do not need Bluetooth support. Because the majority of the computers in your organization
are desktops, you do the following:
• Create a Windows Deployment Services client unattend file that creates a single disk
partition. and a single Windows Vista image with an associated image unattend file that does
not install the Bluetooth drivers and software.
• Create a single Unattend.xml file by using Windows System Image Manager (Windows
SIM), This file performs all of the custom actions needed for laptop installations.
• Create a custom boot image that is configured to run a script.
The first action in the script is to use WMI calls to determine whether a booted client computer is
a laptop or a desktop.

82
 • If the computer is a laptop, the script calls Setup.exe by using the /wds option and then
explicitly passes the custom Unattend.xml file for laptop use. To ensure that this single
unattend is used throughout the process, you set the command-line precedence value of the
server appropriately. This action causes the unattend file that is passed to the Windows
Deployment Services client through the command line to override the existing image unattend
file that is associated with the image on the Windows Deployment Services server.
• If the computer is a desktop, the script invokes the client normally, enabling the typical
installation to continue (the client will obtain both the Windows Deployment Services client
unattend file and, later, the image unattend file from the Windows Deployment Services
server).

Using Variables to Obtain Information from the

Client
The Windows Deployment Services client can obtain several pieces of information during an
installation that you can use as part of your custom deployment scenario. The client will insert the
proper variable valuess into your unattend file automatically as long as your file is formatted
correctly. The variables that the client can use for this purpose are:
• %USERDOMAIN%. The name of the user's domain, which was specified either by
credentials or in the Windows Deployment Services client unattend file.
• %USERNAME%. The user's name, which was specified either by credentials or in the
Windows Deployment Services client unattend file.
• %USERPASSWORD%. The user's password, which was specified either by credentials
or in the Windows Deployment Services client unattend file. Using this variable may pose a
security risk and is not recommended. The password value will be written to the unattend file
in plain text.
• %MACHINEDOMAIN%. The domain containing the computer account that represents the
physical client computer.
• %MACHINENAME%. The computer name of the computer account that represents the
physical client computer.
• %TIMEZONE%. The time zone of the Windows Deployment Services server.
• %ORGNAME%. The organization name of the Windows Deployment Services server.
To see an example file that uses these variables, see Sample Unattend Files.

Sample Unattend Files

In This Topic
• Windows Deployment Services Client Unattend File
• Image Unattend Files (unsecure domain join)

83
 • Image Unattend Files (secure domain join)
• Image Unattend Files (using variables)
• Sysprep.inf file

Windows Deployment Services Client Unattend File

<?xml version="1.0" ?>

<unattend xmlns="urn:schemas-microsoft-com:unattend">

<settings pass="windowsPE">

<component name="Microsoft-Windows-Setup" publicKeyToken="31bf3856ad364e35"

language="neutral" versionScope="nonSxS" processorArchitecture="x86">

<WindowsDeploymentServices>

<Login>

<WillShowUI>OnError</WillShowUI>

<Credentials>

<Username>username</Username>

<Domain>wds-dom</Domain>

<Password>my_password</Password>

</Credentials>

</Login>

<ImageSelection>

<WillShowUI>OnError</WillShowUI>

<InstallImage>

<ImageName>Windows Vista with Office</ImageName>

<ImageGroup>ImageGroup1</ImageGroup>

<Filename>Install.wim</Filename>

</InstallImage>

<InstallTo>

<DiskID>0</DiskID>

<PartitionID>1</PartitionID>

</InstallTo>

</ImageSelection>

</WindowsDeploymentServices>

<DiskConfiguration>

<WillShowUI>OnError</WillShowUI>

<Disk>

84
 <DiskID>0</DiskID>

<WillWipeDisk>false</WillWipeDisk>

<ModifyPartitions>

<ModifyPartition>

<Order>1</Order>

<PartitionID>1</PartitionID>

<Letter>C</Letter>

<Label>TestOS</Label>

<Format>NTFS</Format>

<Active>true</Active>

<Extend>false</Extend>

</ModifyPartition>

</ModifyPartitions>

</Disk>

</DiskConfiguration>

</component>

<component name="Microsoft-Windows-International-Core-WinPE"
publicKeyToken="31bf3856ad364e35"

language="neutral" versionScope="nonSxS" processorArchitecture="x86">

<SetupUILanguage>

<WillShowUI>OnError</WillShowUI>

<UILanguage>en-US</UILanguage>

</SetupUILanguage>

<UILanguage>en-US</UILanguage>

</component>

</settings>

</unattend>

Image Unattend Files (unsecure domain join)

<?xml version="1.0" encoding="utf-8"?>

<unattend xmlns="urn:schemas-microsoft-com:unattend">

<settings pass="specialize">

<component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="x86"

publicKeyToken="31bf3856ad364e35"

85
language="neutral" versionScope="nonSxS"
xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<Identification>

<UnsecureJoin>true</UnsecureJoin>

</Identification>

</component>

<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86"

publicKeyToken="31bf3856ad364e35"

language="neutral" versionScope="nonSxS"
xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<ProductKey>XXXX-XXXX-XXXX-XXXX-XXXX</ProductKey>

</component>

</settings>

</unattend>

Image Unattend Files (secure domain join)

<?xml version="1.0" encoding="utf-8"?>

<unattend xmlns="urn:schemas-microsoft-com:unattend">

<settings pass="specialize">

<component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="x86"

publicKeyToken="31bf3856ad364e35"

language="neutral" versionScope="nonSxS"
xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<Identification>

<UnsecureJoin>false</UnsecureJoin>

<Credentials>

<Domain>fabrikam</Domain>

<Password>MyPassword1</Password>

<Username>MyUserName</Username>

</Identification>

</component>

86
 <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86"
publicKeyToken="31bf3856ad364e35"

language="neutral" versionScope="nonSxS"
xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<ComputerName>%MACHINENAME%</ComputerName>

</component>

</settings>

</unattend>

Image Unattend Files (using variables)

In the following example file, Windows Deployment Services will replace the %USERDOMAIN%,
%USERPASSWORD%, %USERNAME%, and %MACHINEDOMAIN% variables using the proper
values. For more information, see "Using Variables to Obtain Information From the Client" in the
Advanced Unattended Installation Scenarios topic
<?xml version="1.0" encoding="utf-8"?>

<unattend xmlns="urn:schemas-microsoft-com:unattend">

<settings pass="specialize">

<component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="x86"

publicKeyToken="31bf3856ad364e35"

language="neutral" versionScope="nonSxS"
xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<Identification>

<Credentials>

<Domain>%USERDOMAIN%</Domain>

<Password>%USERPASSWORD%</Password>

<Username>%USERNAME%</Username>

</Credentials>

<JoinDomain>%MACHINEDOMAIN%</JoinDomain>

</Identification>

</component>

<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86"

publicKeyToken="31bf3856ad364e35"

language="neutral" versionScope="nonSxS"
xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"

87
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<ComputerName>%MACHINENAME%</ComputerName>

</component>

</settings>

<settings pass="oobeSystem">

<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86"

publicKeyToken="31bf3856ad364e35" language="neutral"

versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<UserAccounts>

<DomainAccounts>

<DomainAccountList wcm:action="add">

<Domain>%USERDOMAIN%</Domain>

<DomainAccount wcm:action="add">

<Group>Administrators</Group>

<Name>%USERNAME%</Name>

</DomainAccount>

</DomainAccountList>

</DomainAccounts>

</UserAccounts>

<TimeZone>%TIMEZONE%</TimeZone>

<RegisteredOrganization>%ORGNAME%</RegisteredOrganization>

</component>

</settings>

</unattend>

Sysprep.inf file
[Identification]

DoOldStyleDomainJoin=Yes

[Networking]

[UserData]

88
Working with Images
• Creating Images
• Filtering Images
• Deploying Earlier Versions of Windows
• Storing and Replicating Images Using DFS
• Servicing Images

Creating Images

In This Topic
• Overview
• Boot Images
• Versions of Windows PE
• Creating Custom Boot Images
• Discover Images
• Creating Discover Images
• Capture Images
• Creating Custom Install Images
• Converting RIPREP Images

Overview
Windows Deployment Services uses two basic image types, both of which use the Windows
Image (.wim) file format:
• Install image: The operating system image that you deploy to the client computer. After
you boot a computer into a boot image, you will be presented with a user interface (UI) where
you can select the install image you want to install.
• Boot image: Boot images are the images that you boot a client into before you install the
install image. For Windows Deployment Services, these images contain Windows PE and the
Windows Deployment Services client (which is essentially Windows Vista Setup.exe and
supporting files). To install an operating system, you first boot the computer into the boot
image, and then you select the install image to install. You can also create two additional
types of boot images:
• Capture image: A type of boot image that you boot a client computer into to capture
the operating system as a .wim file. You must first create a capture image when you are
creating custom install images.

89
 • Discover image: A type of boot image that you can use to install an operating
system on a computer that is not Pre-Boot Execution Environment (PXE) enabled. When
you boot a computer into a discover image, the Windows Deployment Services client will
locate a valid Windows Deployment Services server, and then you can choose the install
image you want to install.

Boot Images
Microsoft Windows Preinstallation Environment (Windows PE) is the boot image format for
Windows Deployment Services. Windows Deployment Services can boot both standard and
custom boot images, as long as the following two conditions are met:
• The image must be stored in .wim format.
• The image in the .wim file must be marked as bootable from RAMDISK using the /boot
option with ImageX.
In most cases, you should use the standard boot image that is included on the Windows
Server 2008 media (located at \Sources\boot.wim) without modification. Do not use the Boot.wim
from the Windows Vista media unless your version of Windows Vista has SP1 integrated into the
DVD. If you use the first version of Windows Vista that does not contain SP1, multicasting will not
work correctly. The Boot.wim file meets the two conditions just stated, and it also contains the
Windows Deployment Services client (which is basically Windows Vista Setup.exe and supporting
files).
You can also create custom boot images as long as they meet the two conditions previously
mentioned. In addition, you can add the Windows Vista or Windows Server 2008 Setup binary
files if you want the functionality of Windows Deployment Services client. For information about
managing and modifying the boot menu, see Managing the Boot Menu.

Versions of Windows PE
In general you should use the latest version of Windows PE in the boot image that you use to
deploy images. The version of Windows PE must match or be newer than the install image. For
example, you can use Windows PE 2.1 to deploy install images of all versions of Windows
(including Windows Vista with SP1, Windows Server 2008, and all earlier versions of Windows).
You cannot, however, use Windows PE 2.0 to deploy Windows Vista with SP1 or Windows
Server 2008.
If you are deploying Windows Server 2003 and your boot image does not contain the Windows
Deployment Services client (for example, if you are booting a Windows PE 2005 boot image into
the command prompt instead of into the user interface screens of the Windows Deployment
Services client), we recommend that you use the latest version of Windows PE. You can use
Windows PE 2004, Windows PE 2005, Windows PE 2.0, or Windows PE 2.1, although the
following caveats apply:
• If you are applying a .wim image of Windows Server 2003 using ImageX, you can use
either the x86 or x64 version of Windows PE.

90
 • In the past, if you were running Winnt32.exe for Setup, you could only use x64 versions
of Windows PE, but that has changed. For details, see Knowledge Base article 931761
(http://go.microsoft.com/fwlink/?LinkID=110354).
• If you are using Windows PE 2.0, you might run into the issue documented at
http://go.microsoft.com/fwlink/?LinkID=110354. In this scenario, run the command
Bootsect.exe /nt52 c: to set up the correct NTFS file system boot sector.

Creating Custom Boot Images

In most cases, you can just use the Boot.wim file on the DVD for Windows Server 2008 in the
\Sources folder. This is actually the same Windows PE image used by Setup.exe. Therefore, the
image already contains the Setup.exe files and is properly configured to start Setup automatically.
For instructions, see the Step-by-Step Guide for Windows Deployment Services in Windows
Server 2008.
You can also use the tools in the Windows Automated Installation Kit (AIK) to create a custom
boot image. As part of the image-building process, you must manually copy the required setup
files into the custom image. The process for doing this is as follows:
1. Create a top-level folder named Sources in the custom boot image.
2. Mount the boot image that is RAMDISK-bootable in the Boot.wim file (this file contains
two Windows PE images, and the bootable image is the second image).
3. Copy all of the setup files from the \Sources folder in the mounted image to the \Sources
folder in the custom boot image.

Note
As part of the custom image build process, you must ensure that the Windows
Deployment Services client is started by Windows PE. To ensure that this occurs,
create an entry in the WinPESHL.ini file to start Setup.exe in Windows Deployment
Services mode. For more information about editing WinPESHL.ini, see the Windows
AIK documentation (http://go.microsoft.com/fwlink/?LinkId=96016).

Discover Images
A discover image is a boot image that has been modified to start Windows Deployment Services
and discover a valid server (it is generally used in non-PXE boot scenarios). These images
enable a computer that cannot perform a PXE boot from a Windows Deployment Services server
to locate such a server and use it to install an image. These images must be started with the
/WDSDiscover option (see the table in the next section). The discovery functionality has two
configuration options:
• Static discovery. This means specifying the server that the computer should use. Static
discovery works well in data center environments or branch offices where DHCP may not be
available. One major disadvantage of static discovery is that it introduces a single point of
failure. For example, if the server that is specified is unavailable, the Windows Deployment
Services client will not work, and there is no way to have the client try a different server.
Another flaw is that static discovery does not allow for load balancing, because all clients
91
 using a particular boot image would use the specified server. You can specify the server when
you create the discover image.
• Dynamic discovery. With this option, the Windows Deployment Services client emulates
a PXE request from within Windows PE. Based on the responses to that PXE request, the
client can locate a valid server and continue the installation process. If you do not specify the
server when you create the discover image, the image will use this method to locate a server.

Creating a Discover Images

In most cases, you can use the Boot.wim file included on the Windows Server 2008 DVD to
create your image. To create a discover image, right-click the image in the MMC snap-in, and
then click Create discover boot image. For instructions, see the Step-by-Step Guide for
Windows Deployment Services in Windows Server 2008.
For advanced scenarios if you want to create a custom deployment, you can create a discover
image by using the tools provided in the Windows AIK. To do this, copy the appropriate setup files
from the \Sources folder in the boot image located on the Windows Server 2008 DVD (it is the
second image in the Boot.wim file). Then create a WinPESHL.ini file that invokes Setup.exe and
passes the appropriate discovery options.
There are two optional command-line options for Setup.exe that control the discovery behavior of
the Windows Deployment Services client. These options are described in the following table.

Option Description

/WDSDiscover (Default) Specifies that the Windows

Deployment Services client should be in
discover mode. If you do not specify
/WDSServer with this option, Windows
Deployment Services will search for a server.
For example, to start the Windows Deployment
Services client in this dynamic discover mode,
run the command \sources\setup.exe /wds
/WDSDiscover.

/WDSServer:<ServerName> Specifies the name of the Windows Deployment

Services server that the client should connect
to. Note that <ServerName> can be an IP
address, a NetBIOS name, or a fully qualified
domain name (FQDN). You must also specify
/WDSDiscover. For example, to start the
Windows Deployment Services client in this
static discover mode, run the command
\sources\setup.exe /wds /WDSDiscover
/WDSServer:MyWDSServer.

92
Capture Image
A capture image is a boot image (containing Windows PE) that has been modified to start the
Windows Deployment Services Image Capture Wizard instead of starting Setup. When you boot
a computer (that has been prepared with Sysprep) into a capture image, a wizard creates an
install image of the computer and saves it as a .wim file. Capture images provide an alternative to
ImageX. You create capture images from existing boot images — most commonly, the Boot.wim
file from the installation media. Then you can add the images back to the server for PXE boot
deployment or copy them to bootable media (CD, DVD, USB drive, and so on).
For instructions on creating a capture image and deploying an install image, see the Step-by-Step
Guide for Windows Deployment Services in Windows Server 2008.
For information about automating the wizard, see Automating the Image Capture Wizard.

Creating Custom Install Images

You can create custom install images by using either of the following:
• ImageX, which is included in the Windows AIK. For information about creating a custom
install image by using ImageX, see the Windows AIK documentation
(http://go.microsoft.com/fwlink/?LinkID=53552).
• Capture images, which contain the Windows Deployment Services Image Capture
Wizard. For instructions on creating a capture image and deploying an install image, see the
Step-by-Step Guide for Windows Deployment Services in Windows Server 2008.
The Image Capture Wizard enables you to capture an operating system that has been prepared
with Sysprep into a .wim file. Then you can upload the image to the Windows Deployment
Services server. The wizard provides a subset of the functionality included in the ImageX
/capture command. The following table compares these two tools.

Functionality Image Capture Wizard ImageX

Captures a partial volume? No Yes

Captures an image that has not been prepared by No Yes

using Sysprep?

Can I specify a Yes: only LZX or Yes: LZX, XPRESS, or no compression

compression type? XPRESS

Uploads directly to the Yes No

Windows Deployment
Services server?

Can the process be Yes Yes

automated?

Has a GUI? Yes No

Provides additional No Yes

93
Functionality Image Capture Wizard ImageX

functionality beyond
image capture?

Enables me to specify a Yes Yes

capture exclusion list?

Captures directly to a No Yes

network location without
making a local image
copy?

Regardless of which tool you use, the high-level process remains essentially the same:
1. Install Windows on a reference computer.
2. Perform customizations and install software.
3. Run the correct version of Sysprep for the reference computer's operating system.
4. Reboot into Windows PE.
5. Capture the offline Sysprep image into .wim format.
6. Upload the image to the Windows Deployment Services server’s image store.

Converting RIPREP Images

RIPREP images are essentially images that have been prepared with Sysprep that do not contain
a fully populated critical device database. To convert these images, you must first upgrade your
server to Windows Server 2008. For instructions on how to convert RIPREP images, see the
"Install Images" section in How to Manage Images.

Default Conversion
The default conversion process copies the updated version of a file to another location. There
were two main factors that influenced this design decision:
• The original image remains unmodified, in case the conversion process fails or you want
to continue to use the original RIPREP image after the conversion process is run.
• In RIS, you could associate multiple unattended setup installation files (.sif) with a
particular image. If an image is so configured, a conversion process that is run for one .sif file
would alter the backing files used by the other .sif file.
The conversion process requires at least twice as much free disk space as the size of the image.
This space is needed for a copy of the RIPREP image placed in the %TEMP% folder and the
.wim file that was created by using the contents of the converted image in the %TEMP% folder.

Note
The data in the %TEMP% folder can be removed only after the new image has been
captured.

94
In-Place Conversion
You can force an in-place conversion of a RIPREP image, which will save time and the amount of
disk space that you use during the conversion process. You can do this by using the /InPlace
option with the WDSUTIL /Convert-RiprepImage command. It is common for multiple variations
of a single RIPREP image (differing only by HAL type) to exist on a server. You can save time
during the conversion process by using the /Overwrite:Append option of the WDSUTIL
/Convert-RiprepImage command to take advantage of single-instancing technology within the
.wim format. For instructions on how to convert RIPREP images, see the "Install Images" section
in How to Manage Images.
The append operation is much faster than a traditional capture because it avoids the need to
compress and insert files that already exist in the .wim file. Files that are identical between
images and that already exist within the .wim file will simply have their reference count
incremented to indicate that the single file belongs to multiple images within the .wim file. The
general conversion process entails first converting the first RIPREP image in the set by creating a
new .wim file, and then converting the remaining RIPREP images (for the other HAL types) by
appending them to the .wim file you created previously.

Deploying Earlier Versions of Windows

You can use Windows Deployment Services to deploy Windows Vista as well as earlier Windows
operating systems such as Windows XP and Windows Server 2003. To do this, you use Sysprep
to prepare the operating system, and then store the image in the Windows image (.wim) file
format.

Note
Windows Deployment Services does not recognize that the image contains an earlier
operating system until the image is selected on the image selection page. When the
image is selected, the image's metadata specifies the exact version of the operating
system.
Although Windows Deployment Services provides full functionality for applying images for
Windows Vista, note the following limitations when deploying the images of earlier Windows
operating systems:
• Sysprep must be applied to the first primary partition: Earlier operating system
images that have been prepared with Sysprep must be applied to the first primary partition
(for example, C:\). Applying these images to other partitions is not supported.
• The HAL must match: Earlier operating system images are hardware abstraction layer
(HAL)-specific, meaning that they can be applied only to computers that have a matching
HAL type. Therefore, Windows Deployment Services detects the local computer's HAL type
and filters out images that are earlier than Windows Vista and that are not of that same HAL
type. For example, if there are two images on the Windows Deployment Services server that
the client has permissions to (one ACPI and the other APIC) and the client computer is ACPI,
only the ACPI image will be available. This is true in both attended and unattended

95
 installation scenarios. Note that the HAL type of an image is stored in the .wim image
metadata: <HAL>acpiapic</HAL>
• External language packs do not apply: When you are applying these images, the
concept of external language packs does not apply. The language selection drop-down list on
the image selection page will not let you select an additional language. Additionally, if you
specify a language, locale, and keyboard layout in the Windows Deployment Services client
user interface — or if you use unattend — the settings you specified will not be used in the
image that gets applied. Windows Deployment Services does not support modifications to
offline images predating Windows Vista that would be necessary for this functionality.
• You cannot apply a driver to an offline image (by using the F6 key or load driver
functionality) to images earlier than Windows Vista. The API set you use to perform
offline driver injection is supported only for Windows Vista images.
• The Boot.ini file must exist in the image: Rather than Setup generating a Boot.ini file
when deploying an operating system earlier than Windows Vista, Boot.ini must already exist
in the image. This is currently the default behavior of most image-based deployments,
including those involving ImageX.

To ensure that the Boot.ini file is included with the image

1. Deploy the image of the earlier operating system to a reference computer.
2. Use Sysprep to prepare the image.
3. Capture the image of reference computer, including the Boot.ini file.
4. Deploy the image by using Windows Deployment Services. When the image is
applied, the Boot.ini file included in that image will be copied as well.

Filtering Images
You can restrict which install images are shown to users. These restrictions can be policy-based
or enforced by the computer.
• Automatic Filtering by Windows Deployment Services
• Filtering Images Manually

Automatic Filtering by Windows Deployment

Services
Filtering by Using HALs
To avoid situations where a user is allowed to install an image that contains an incompatible
hardware abstraction layer (HAL) type, Windows Deployment Services performs HAL filtering.
During image selection, any nonmatching images are not shown to the user.
96
 • Windows Vista or Windows Server 2008. For newer images (as specified in the
metadata for the .wim file), HAL filtering will not take place. In these cases, HAL filtering is not
necessary because the image actually contains all of the possible HALs, and the correct HAL
is detected and put in place automatically upon first boot.
• Earlier operating systems. If the image is of an earlier operating system, Windows
Deployment Services will compare the HAL type (as specified in the metadata for the .wim
file) to that of the destination computer. If the HAL types are identical, the image will be
shown to the user. If the HAL types do not match, the image will not be displayed. The HAL
information about the image is stored in the image metadata in the <HAL> section of the .wim
file.

Filtering by Architecture
For x86-based computers, you can boot only into x86-based boot images and install only x86-
based install images. The images that are applicable to that architecture will be filtered
automatically. In Windows Server 2008, however, there is new functionality that controls how
images are filtered to users on x64-based computers. When you boot into the Boot.wim file that is
included on the x86 version of Windows Server 2008 media from an x64-based computer, you will
be able to choose from both x86-based and x64-based install images. However, if you boot into
an x64-based Boot.wim file from the same computer, only x64-based boot images will be
displayed.

Filtering Images Manually

You can specify permissions to allow only certain users rights to see a particular install image. To
set permissions, right-click the image (either in the MMC snap-in or in the RemoteInstall folder),
and then click Properties. It is not possible to specify permissions for different users for images
within the same image group. For example, if you have two images, ImageA and ImageB, and
you would like User1 to have access to ImageA and User2 to have access to ImageB, you must
have each image stored in a separate .wim file.
Note that setting these permissions sets the permissions on the .wim file (which contains only
metadata), but not the Res.rwm file (which contains the file resources for the image). In order to
secure the Res.rwm, you must create an ACL for the file. However we do not recommend this
because if the permission sets differ for the files, a user could have permissions to view the .wim,
but not the Res.rwm, and therefore the installation would fail.

Servicing Images
Servicing images means updating an image that is currently available to users — for example,
adding a Windows update to your existing image. There are two types of image servicing:
• Offline. In the context of updating images, the term "offline" refers to updating or applying
changes to an operating system image that is not currently running. For example, you might

97
 update a .wim file with security updates by using ImageX, while it sits in a folder structure or
another partition.
• Online. In the context of updating images, the term "online" refers to updating or applying
changes to an operating system that the computer is booted into. For example, installing an
update by using Windows Update is an online operation.
Your ability to service an offline image is limited by:
• The version of the operating system of the offline image. Windows Vista supports
offline servicing of images that have been prepared with Sysprep, whereas earlier versions of
Windows do not.
• The type of action you are performing. You can service a Windows Vista or Windows
Server 2008 image offline by using Package Manager or online by using OCSetup, Package
Manager, or the Windows Update Standalone installer.
There are various command-line tools that you can use to install and uninstall packages.
Package Manager works only with operating system packages (hotfixes, updates, drivers, service
packs, and language packs). OCSetup works only with Microsoft Windows Installer components
(and hands off packages to Package Manager to install or remove). The Windows Update
Standalone installer installs service packs and other updates delivered as .msu files. For details
on their use, see the "Package Manager" technical reference in the Windows AIK documentation
(http://go.microsoft.com/fwlink/?LinkID=53552). You must use the servicing tools and
technologies included in the Windows AIK to perform offline servicing on images that are located
on a Windows Deployment Services server.

In This Topic
• Servicing an Image Offline
• Reducing the Size of Images

Servicing an Image Offline

The following are the four high-level steps you will need to perform to service an image offline.
1. Disable the current image. This enables currently connected clients to finish applying
the image, but it prevents new clients from starting an installation.
2. Export the image to a .wim file that is outside of the Windows Deployment Services
server's image store. For install images, this combines the metadata in the install.wim file
with the resources in the Res.rwm file into a single .wim file and saves it to the destination
location. Combining the file resources and metadata into one file is a requirement of image
manipulation tools such as ImageX.
3. Service the image. In this step, you update the image as you like using the tools in the
Windows AIK. For example, you can mount the image to a folder by using ImageX, and then
add the files and folders to the image. Alternatively, you can load the registry hive, and then
add, delete, or modify registry keys. If the image that is being serviced is a boot image, you

98
 can use PEimg.exe to add drivers to the image. After all your changes are complete, use
ImageX to commit the changes to the .wim.
4. Replace the current image with the updated version. In this step, you add the
updated image back to the Windows Deployment Services server. If the previous image is still
in use, the replacement will fail. You can check to see whether the old image is still in use
before attempting a replacement by using the Shared Folders in the MMC snap-in to view all
currently open files. If the previous image is still in use, you have two options:
• Wait for existing installations to complete, delete the old copy, and then replace it with
the new. For instructions, see How to Manage Images. We recommend this method
because any associated external data such as language packs, unattend files, or $OEM$
folder contents will remain associated with the image.
• Add the updated image as a new, separate image. You must also copy or associate
any external data such as language packs, unattend files, or $OEM$ folder contents.
Sometimes it may be more efficient to redeploy and recapture an image to add applications,
rather than servicing the image offline. For instructions, see the Step-by-Step Guide for Windows
Deployment Services in Windows Server 2008.

Reducing the Size of Images

An image group is a collection of images that share common file resources and security. The
following are the two components of an image group:
• Res.rwm file: Contains the file resources for each image group.
• Image.wim files: Contains the metadata that describes the content of the install image.
Because the images are stored this way, removing an image from an image group does not
reduce the size of the files. This is because files in the Res.rwm file that no longer belong to an
image are not actually converted to free space; rather, they are just dereferenced. To reclaim free
space within the Res.rwm file, you must perform the following steps:
1. Export all images from the image group to an external .wim file.
2. Create a new image group.
3. Add all exported images to the new group.
When performing this procedure, you must manually copy and reassociate any external data
(such as language packs and unattend files) to the new image group.

Note
When exporting images to an external .wim file, you should use the command
WDSUTIL /Export-Image to append the images to an existing .wim file. Appending an
image to an existing .wim file is generally faster than exporting it to a new .wim file.

99
Storing and Replicating Images Using DFS
This section outlines the tools and topology configurations associated with the Distributed File
System (DFS) role service in the File Services server role of Windows Server 2008. You may
have to update your AD DS schema to use DFS to manage multiple Windows Deployment
Services servers. Any issues pertaining to AD DS, updates to an AD DS schema, and AD DS
maintenance and best practices are outside the scope of this document. For more information
about DFS, see:
• Step-By-Step Guide for Distributed File Systems in Windows Server 2008
(http://go.microsoft.com/fwlink/?LinkId=111021)
• Distributed File System (http://go.microsoft.com/fwlink/?LinkId=108012)

Storing Files on Another Server

You can store install images on another server (not Windows Deployment Services server) using
DFS and still install the images by using Windows Deployment Services. Using DFS for install
images provides two main benefits:
• Load balancing. Clients can be directed to computers other than the Windows
Deployment Services server to download the image.
• Simplified administration. When you use DFS replication technology, you can modify
images on a single server and propagate changes to other distribution points.

To configure DFS namespaces for install images:

1. Install and configure Windows Deployment Services.
2. Install the DFS role service from the File Services server role in Server Manager. For
more information about DFS, see Distributed File System
(http://go.microsoft.com/fwlink/?LinkId=108012)
3. Create a file share on a secondary server. Grant permissions to the Windows
Deployment Services server’s computer account. For example, if the server is called
MyWDSServer, grant read/write permissions to MyWDSServer$.
4. Create a new namespace in DFS Management. For example,
\\fileserver\MyNamespace for a stand-alone namespace or
\\corp.woodgrovebank.com\MyNamespace for a domain-based namespace.
5. Add a new folder to the namespace and create an image group on the Windows
Deployment Services server as a target folder for the new folder in the namespace. For
example, create \\MyServerOrDomain\MyNamespace\ImageGroup in DFS Namespaces,
and specify \\MyWDSServer\RemoteInstall\images\DFSImageGroupName as a target
folder for that folder.
6. Add images to the Windows Deployment Services server.
7. Verify that the content appears when you connect to
\\MyServerOrDomain\MyNamespace\ImageGroup.

100
 8. Repeat this procedure for additional image groups.

Replicating Images Using Distributed File System

DFS Replication is a server technology that you can use to replicate images between Windows
Deployment Services servers. DFS Replication can decrease the total cost of ownership by
making it possible for you to manage images from a single server in the environment. Changes
can then be propagated to other servers without requiring interaction. A best practice is to create
a single, master Windows Deployment Services server that clients do not connect to. Make all
modifications to images on this server by using the Windows Deployment Services management
tools and the image maintenance tools included in the Windows AIK. Next, replicate changes
from this server to other servers in the topology. To prevent replication conflicts, avoid modifying
or servicing the same image from multiple servers at the same time.
For more information, see Distributed File System Replication: Frequently Asked Questions
(http://go.microsoft.com/fwlink/?LinkId=111023).

To configure DFS Replication for install images:

1. Install and configure Windows Deployment Services.
2. Install the DFS role service from the File Services server role in Server Manager. For
more information, see Step-By-Step Guide for Distributed File Systems Windows
Server 2008 (http://go.microsoft.com/fwlink/?LinkID=111021)
3. Create and configure a replication group for the RemoteInstall folder or its subfolders.
If you are replicating RemoteInstall subfolders, you must exclude the \Mgmt and \Tmp
folders. These folders contain server-specific information that cannot be used by remote
Windows Deployment Services servers.
4. Configure the BCD refresh policy by running the following command (see below for
details about the options): WDSUTIL /set-server /BcdRefreshPolicy /Enabled:yes
/RefreshPeriod:<time in minutes>

Option Explanation

/BcdRefreshPolicy Causes the server to regenerate BCD stores in

the \Tmp folder for all boot images.

/RefreshPeriod Determines how often the boot images are

regenerated. This value is required so that any
changes that you make to your boot images on
the master server are reflected in the boot
menus that clients receive from remote servers.
If you do not make changes to boot images very
often, it is okay to have a larger value. If you
make changes to boot images often or if you
want changes to propagate quickly, set this to a

101
Option Explanation

lower value. However, be careful when setting a

low value. BCD generation causes CPU and
disk overhead on the Windows Deployment
Services server. Configuring a small value can
cause performance problems on the server. A
good default value is 30 minutes.

How to Perform Common Tasks

This topic contains procedures for performing common tasks using Windows Deployment
Services MMC snap-in. and the WDSUTIL command line tool.

Note
Other than displaying a message that indicates whether the operation succeeded or
failed, WDSUTIL shows minimal screen output (by default). However you can specify two
additional options to enable more output. You can specify/Verbose to show detailed
information about a task, and you can specify /Progress to use ellipses to indicate that a
long-running process (for example, adding an image) is running and is not stalled. Even
when you use these options, you can redirect the WDSUTIL output to a file. In the sample
WDSUTIL command-lines in this section, these options are used wherever they provide
useful information.

In This Topic
The management tasks that you can perform with these tools fall into the following categories:

Category Example tasks

How to Manage Your Server • Initialize and uninitialize a server

• View configuration information about
servers
• Start/stop or enable/disable a server
• Update the RemoteInstall folder
• Set advanced server settings

How to Manage Client Computers • Create and delete prestaged accounts

in AD DS
• View information about prestaged
computers
• Set configuration attributes

102
Category Example tasks

• Reject/approve pending computers

How to Manage Images • View information about images and

image groups
• Create capture and discover images
• Add, copy, export, remove, update
images from the image store
• Set attributes and associate unattend
files for install images.
• Convert RIPREP images
• Add and remove image groups
• Set attributes of an image group

How to Create Multicast Transmissions • Set multicast server settings

• Create and manage multicast
transmissions

How to Modify the BCD Store Using Bcdedit
• To view the contents of the BCD store
• To configure the default selection time-
out value
• To configure a localized boot manager
experience
• To configure the TFTP block size and
window size
• To configure Windows debugger
options

How to Manage Your Server

This section contains procedures for the tasks that are listed and described in the following table.

Type Procedure

General Tasks • To configure Windows Deployment

Services
• To start or stop the server
• To enable the server
• To enable logging of Windows
Deployment Services client actions

103
Type Procedure

• To choose the port number for RPC

• To specify the network interfaces for the
PXE provider to listen on
• To configure how often the server
refreshes its settings
• To force the server to update files in the
RemoteInstall folder
• To configure the network profile for the
server
• To back up the server data

DHCP • To configure Windows Deployment

Services to run on the same computer as
Microsoft DHCP
• To configure Windows Deployment
Services to run on the same computer as
non-Microsoft DHCP
• To turn on the DHCP authorization
requirement
• To authorize the server in DHCP

Client Requests • To configure the server to answer

clients
• To set a delay in the server’s answers
to PXE requests
• To configure unknown clients to perform
PXE boots without requiring F12
• To configure clients who have booted
without F12 to require a key press on
subsequent boots
• To configure the server to determine the
architecture of booting clients

Network Boot Program and Boot Image
• To choose which boot images are
displayed on x64-based computers
• To choose the default network boot
program for each architecture
• To choose the default network boot
program that does not require F12 for each
architecture
• To choose the default boot image for

104
Type Procedure

each architecture

Prestaging Clients • To specify a domain controller for the

PXE provider
• To specify a global catalog server for
the PXE provider
• To choose whether to search for
computer accounts in the domain controller
before searching the global catalog
• To configure the server to prestage
clients by using their MAC address instead
of their GUID
• To maintain a list of GUIDs that belong
to multiple computers
• To specify how to generate client
computer names
• To specify the domain and OU in which
to create client computer accounts
• To choose whether to join client
computers to the domain

Unattend File • To choose a default unattend file for the

Windows Deployment Services client
• To specify whether an unattend file on
the client computer overrides the default
unattend file

Caution
To modify the registry settings that are described in this guide, use only the Windows
Deployment Services management tools—you should not directly edit these settings and
attributes.

Note
You cannot manage a Windows Deployment Services server running Windows
Server 2008 from a Windows Deployment Services server running Windows
Server 2003.

Note
Help for WDSUTIL is available by typing WDSUTIL /? at a command prompt or online at
http://go.microsoft.com/fwlink/?LinkId=112194.

105
General Tasks
To configure Windows Deployment Services

Using the MMC Using WDSUTIL

1. Install Windows Deployment Services. 1. Install Windows Deployment Services.

For more information, see the Step-by-Step
Guide for Windows Deployment Services in
Windows Server 2008.
2. Click Start, click Administrative
Tools, and then click Windows
Deployment Services.
3. In the left pane of the Windows
Deployment Services snap-in, right-click
the server and then click Configure
Server.
4. Follow the instructions in the wizard.
For more information, see the Step-by-Step
Guide for Windows Deployment Services in
Windows Server 2008.
2. Open an elevated Command Prompt
window, and then run WDSUTIL
/Verbose /Progress /Initialize-Server
/RemInst:<path>, where <path> is the path
where you would like the RemoteInstall
folder to be located.

The preceding procedure does the following:

1. Creates the folder tree for RemoteInstall.
2. Creates the RemoteInstall folder with the following default permissions: Authenticated
Users = Read and Execute, System = Full Control, Administrators = Full Control, and
WDSServer service = Full Control
3. Installs the server files (boot files) from the \system32\reminst folder (as placed during
component installation) to the new folder structure.
4. Updates the service parameters.
5. Sets the Trivial File Transfer Protocol (TFTP) root to point to the RemoteInstall folder root.
6. Sets the WDSServer service startup type to Auto.
7. Optionally authorizes the server in Dynamic Host Control Protocol (DHCP).
8. Starts the services.

To start or stop the server

Using the MMC Using WDSUTIL

1. Right-click the server, and then click All 1. Open an elevated Command Prompt
Tasks. window.
2. Click Stop Server or Start Server. 2. Run WDSUTIL /Start-Server or
WDSUTIL /Stop-Server.

106
The preceding procedure starts or stops the WDSServer service.

To enable the server

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Enable-Server.

The preceding procedure starts or stops the WDSServer service.

To enable logging of Windows Deployment Services client

actions

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. To turn on client logging, run
WDSUTIL /Set-Server
/WDSClientLogging /Enabled:Yes.
3. To change which events are logged, run
WDSUTIL /Set-Server
/WDSClientLogging /LoggingLevel:
{None|Errors|Warnings|Info} (each
category includes all events from the
previous categories).

The preceding procedure sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WdsI
mgSrv\ClientLogging\Enabled to 1.
The level is stored at
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WdsI
mgSrv\ClientLogging\LogLevel, where 0 is None; 1 is Errors only; 2 is Errors and Warnings;
and 3 is Errors, Warnings, and Information.

To choose the port number for RPCs

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

107
Using the MMC Using WDSUTIL

window.
2. Run WDSUTIL /Set-Server
/RPCPort:X, where X is the RPC port
number you want to use.

The preceding procedure sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Parameters\Rp
cPort to the specified value.

Note
If this remote procedure call (RPC) port is changed from the default value, you must add
a firewall exception for the new RPC port.

To specify the network interfaces for the PXE provider to listen

on

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Do one of the following:
• To add an interface to the list, run
WDSUTIL /Set-Server /BindPolicy
/Add /Address:<IP or MAC
address> /AddressType:{IP|MAC}.
• To bind to only the interfaces on the
list, run WDSUTIL /Set-Server
/BindPolicy /Policy:Include.
• To bind to all interfaces other than
those on the list, run WDSUTIL /Set-
Server /BindPolicy /Policy:Exclude.

The preceding procedure sets

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSServer\Providers\WDSP
XE\BindPolicy to 0 to exclude the list, and sets it to 1 to include the list (and excludes all other
interfaces).
The list is stored in the following key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSServer\Providers\WDSP
XE\BindInterfaces (addresses are stored as MAC=XXXXXXXXXXXX or IP=10.10.2.2)

108
To configure how often the server refreshes its settings

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Set-Server
/RefreshPeriod:<time in seconds>.

The preceding procedure sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Parameters\Up
dateTime to the specified value.

To force the server to update files in the RemoteInstall folder

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Update-ServerFiles.

To configure the network profile for the server

Using the MMC Using WDSUTIL

1. Right-click the server, and then click
Properties.
2. On the Network Settings tab under
Network Profile, select the option that
specifies the network speed of your
organization.
1. Open an elevated Command Prompt
window.
2. Run WDSUTIL /Set-Server
[/Server:<name>] /Transport /Profile:
{10Mbps|100Mbps|1Gbps|Custom}.

Select Custom if you want to customize the settings yourself by editing the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\Multi
cast\Profiles\Custom

Important
You should not modify the other profiles that are provided. Instead, you should create a
custom profile even if you want to change only one setting.

To back up the server data

To completely back up your server, you must back up the following two sets of data:
109
 • Images stored in the \RemoteInstall folder. To back up images, you must perform
regular backups of the \RemoteInstall folder. You can restore the content from these backups
without any special qualifications. The exception to this is if your server contains Remote
Installation Services (RIS) images that have been groveled by Single Instance Storage (SIS).
For more information about how to restore a volume that is managed by SIS, see article
263027 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=81026).
• Settings generally stored in the server’s registry. To back up these settings, we
recommend that you perform regular backups by using the Microsoft Volume Shadow Copy
Service (http://go.microsoft.com/fwlink/?LinkId=105509). As an alternative, you can regularly
archive the server's configuration settings by running the command WDSUTIL /get-server
/show:config. However, if you must restore the settings, you must manually reconfigure the
settings by using WDSUTIL.

DHCP
To configure Windows Deployment Services to run on the same
computer as Microsoft DHCP

Using the MMC Using WDSUTIL

1. Right-click the server, and then click
Properties.
2. On the DHCP tab, select Do not listen
on port 67 and Configure DHCP Option
#60 Tag to PXEClient.
1. Open an elevated Command Prompt
window.
2. Run WDSUTIL /Set-Server
/UseDHCPPorts:No /DHCPOption60:Yes.

The preceding procedure does the following:

• Sets
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Parameters
\UseDhcpPorts to 0.
• Adds the option 60 PXEClient tag to all of your DHCP scopes.

To configure Windows Deployment Services to run on the same

computer as non-Microsoft DHCP

Using the MMC Using WDSUTIL

1. Right-click the server, and then click 1. Open an elevated Command Prompt
Properties. window.
2. On the DHCP tab, select Do not listen 2. Run WDSUTIL /Set-Server
on port 67. /UseDHCPPorts:No.

110
Using the MMC Using WDSUTIL

3. Use your DHCP server tools to set the 3. Use your DHCP server tools to set the
option 60 tag to PXEClient. option 60 tag to PXEClient.

The preceding procedure sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Parameters\Us
eDhcpPorts to 0.

To turn on the DHCP authorization requirement

Using the MMC Using WDSUTIL

1. Right-click the server, and then click 1. Open an elevated Command Prompt
Properties. window.
2. On the Advanced tab, select Yes, 2. Run WDSUTIL /Set-Server
Windows Deployment Server should be /RogueDetection:Yes.
authorized in DHCP before servicing
clients.

The preceding procedure sets

HKEY_LOCAL_MACHINE\System\CurrentControlSet\WDSServer\Providers\WDSPXE\Disab
leRogueDetection to 0.

To authorize the server in DHCP

Using the MMC Using WDSUTIL

1. Ensure that you have enterprise 1. Open an elevated Command Prompt

administrator permissions within the DHCP window.
MMC snap-in. 2. Run WDSUTIL /Set-Server
2. Right-click the server, and then click /Authorize:Yes.
Properties.
3. On the Advanced tab, select
Authorize the Windows Deployment
Server in DHCP.

The preceding procedure creates an entry for DHCP authorization under the CN-NetServices,
CN=Services, CN=Configuration, DC=Domain, DC=com object in AD DS.

111
Client Requests
To configure the server to answer clients

Using the MMC Using WDSUTIL

1. Right-click the server, and then click
Properties.
2. On the PXE Response Settings tab,
do one of the following:
• To respond to all client PXE
requests, select Respond to all
(known and unknown) client
computers.
• To respond only to prestaged client
PXE requests, select Respond only to
the known client computers.
• To not answer any client PXE
requests, select Do not respond to
any client computer.
1. Open an elevated Command Prompt
window.
2. Do one of the following:
• To respond to all clients’ PXE
requests, run WDSUTIL /Set-Server
/AnswerClients:All.
• To respond only to prestaged
clients’ PXE requests, run WDSUTIL
/Set-Server /AnswerClients:Known.
• To not answer any clients’ PXE
requests, run WDSUTIL /Set-Server
/AnswerClients:None.

The preceding procedure does the following:

• When the Respond to all (known and unknown) client computers check box is
selected, the netbootAnswerRequests DS attribute is set to TRUE and the
netbootAnswerOnlyValidClients DS attribute is set to FALSE.
• When the Respond only to the known client computers check box is selected, both
attributes are set to TRUE.
• When the Do not respond to any client computer check box is selected, both attributes
are set to FALSE.

To set a delay in the server’s answers to PXE requests

Using the MMC Using WDSUTIL

1. Right-click the server, and then click
Properties.
2. On the PXE Response Settings tab,
set the PXE Response delay in the control.
1. Open an elevated Command Prompt
window.
2. Run WDSUTIL /Set-Server
/ResponseDelay:X, where X is the amount
of time (in seconds) you want the server to
wait before responding to clients.

112
The preceding procedure sets the value of
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSServer\Providers\WDSP
XE\Providers\BINLSVC\ResponseDelay to the specified time.

To configure unknown clients to perform PXE boots without

requiring F12

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Set-Server
/AllowN12ForNewClients:Yes.

The preceding procedure sets the value of

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSServer\Providers\WDSP
XE\Providers\BINLSVC\AllowN12ForNewClients to 1.

To configure clients who have booted without F12 to require a

key press on subsequent boots

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Set-Server
/ResetBootProgram:Yes.

The preceding procedure sets the value of

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSServer\Providers\WDSP
XE\Providers\BINLSVC\ResetBootProgram to 1.

To configure the server to determine the architecture of booting

clients

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Set-Server
/ArchitectureDiscovery:Yes.

113
The preceding procedure sets the value of
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE\Providers\BINLSVC\DisableArchDisc to 0.

Boot Program and Boot Image

To choose which boot images are displayed on x64-based
computers

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Set-Server
/DefaultX86X64ImageType:<x86|x64|
both>.

The preceding procedure sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE\Providers\BINLSVC\x86x64DefaultImageType to 1 for x86-based computers only, 2 for
x64-based computers only, and 0 for both types of computers.

To choose the default network boot program for each

architecture

Using the MMC Using WDSUTIL

1. Right-click the server, and then 1. Open an elevated Command Prompt window.
click Properties. 2. Run WDSUTIL /Set-Server
2. On the Boot tab, insert the path /BootProgram:<path>/Architecture:{x86|x64|
to the boot file you want to use for ia64}, where <path> is relative to the
each architecture. In most cases, you RemoteInstall folder.
should use the standard boot image
that is included on the Windows
Server 2008 media (located at
\Sources\boot.wim) without
modification. Do not use the Boot.wim
from the Windows Vista media unless
your version of Windows Vista has
SP1 integrated into the DVD.

114
The preceding procedure sets
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE\Providers\BINLSVC\BootPrograms\<arch>\Default to the specified path.

To choose the default network boot program that does not

require F12 for each architecture

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Set-Server
/N12BootProgram:<path> /Architecture:
{x86|x64|ia64}, where <path> is relative to
the RemoteInstall folder.

The preceding procedure sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE\Providers\BINLSVC\BootPrograms\<arch>\N12 to the specified path.

To choose the default boot image for each architecture

Using the MMC Using WDSUTIL

1. Right-click the server, and then click 1. Open an elevated Command Prompt
Properties. window.
2. On the Boot tab, insert the path to the 2. Run WDSUTIL /Set-Server
boot image you want to use for each /BootImage:<path> /Architecture:{x86|
architecture. In most cases, you should use x64|ia64}, where <path> is relative to the
the standard boot image that is included on RemoteInstall folder.
the Windows Server 2008 media (located
at \Sources\boot.wim) without modification.
Do not use the Boot.wim from the
Windows Vista media unless your version
of Windows Vista has SP1 integrated into
the DVD.

The preceding procedure sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE\Providers\BINLSVC\BootImages\<arch>\BootImagePath to the specified path.

115
Prestaging Clients
To specify a domain controller for the PXE provider

Using the MMC Using WDSUTIL

1. Right-click the server, and then click
Properties.
2. On the Advanced tab, click Let
Windows Deployment Services use only
the specified servers, and then enter the
domain controller name.
1. Open an elevated Command Prompt
window.
2. Run WDSUTIL /Set-Server
/PreferredDC:<name>, where <name> is a
NetBIOS name or fully qualified domain
name (FQDN).

The preceding procedure sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE\Providers\BINLSVC\DefaultServer to the specified name.

To specify a global catalog server for the PXE provider

Using the MMC Using WDSUTIL

1. Right-click the server, and then click
Properties.
2. On the Advanced tab, click Let
Windows Deployment Services use only
the specified servers and then enter the
Domain controller name.
1. Open an elevated Command Prompt
window.
2. Run WDSUTIL /Set-Server
/PreferredGC:<name>, where <name> is a
NetBIOS name or FQDN.

The preceding procedure sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE\Providers\BINLSVC\DefaultGCServer to the specified name.

To choose whether to search for computer accounts in the

domain controller before searching the global catalog

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Do one of the following:
• To search in the domain controller
before searching the Global Catalog

116
Using the MMC Using WDSUTIL

server, run WDSUTIL /Set-Server

/DomainSearchOrder:DCFirst
• To search only in the Global
Catalog server, run WDSUTIL /Set-
Server /DomainSearchOrder:GCOnly

In the preceding procedure:

• DCFirst sets
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\
WDSPXE\Providers\BINLSVC\ADSearchOrder to 1
• GCOnly sets it to 0.

To configure the server to prestage clients by using their MAC

address instead of their GUID

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Set-Server
/PrestageUsingMAC:Yes.

The preceding procedure sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE\Providers\BINLSVC\ClientIdUse to 1.

To maintain a list of GUIDs that belong to multiple computers

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Do one of the following:
• To add a GUID to the list, run
WDSUTIL /Set-Server
/BannedGUIDPolicy /Add
/GUID:<GUID>.
• To remove a GUID from the list, run
WDSUTIL /Set-Server
/BannedGUIDPolicy /Remove

117
Using the MMC Using WDSUTIL

/GUID:<GUID>.

Note
The GUID string should be
specified without brackets or
dashes (as seen during a PXE
boot).

The list of banned GUIDs list will be stored at

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE.

To specify how to generate computer names

Using the MMC Using WDSUTIL

1. Right-click the server, and then click
Properties.
2. On the Directory Services tab, enter
the naming policy string in the indicated
field (see below for details).
1. Open an elevated Command Prompt
window.
2. Run WDSUTIL /Set-Server
/NewMachineNamingPolicy:<Policy>
where <policy> is the naming policy string
(see below for details).

The policy string works as follows:

• %First: the first name of the user.
• %Last: the last name of the user.
• %Username: the user name of the user.
• %MAC: the MAC address of the computer.
• %n#: an incremental n-digit number. For example, %2# will add a number to the
computer name in the following order: 1,2,3,…99.
• %0n#: an incremental n-digit number, with zeros added before the digit. For example,
%02# will add a number to the computer name in the following order: 01,02,03,…99.
These can be combined in any order. A number before a tag string (such as %3First or
%5Username) will crop the string to that length. For example:
• %61Username%# equals JohnSmi12
• %2first.%last equals Jo.Smith
The preceding procedure sets the netbootNewMachineNamingPolicy DS attribute to the
specified policy.

118
To specify the domain and OU in which to create computer
accounts

Using the MMC Using WDSUTIL

1. Right-click the server, and then click
Properties.
2. On the Directory Services tab, click
Default Directory Service location or
specify the domain and organizational unit
(OU)
1. Open an elevated Command Prompt
window.
2. Do one of the following:
• To create new accounts in the
default computer OU in the domain the
Windows Deployment Services server
is in, run WDSUTIL /Set-Server
/NewMachineOU
/Type:ServerDomain.
• To create new accounts in the
default computer OU in the domain the
specified user account is in, run
WDSUTIL /Set-Server
/NewMachineOU /Type:UserDomain.
• To create new accounts in the
same OU as the specified user account,
run WDSUTIL /Set-
Server /NewMachineOU
/Type:UserOU.
• To create new accounts in a
different OU, run WDSUTIL /Set-Server
/NewMachineOU /Type:Custom
/OU:<name of OU>.

The preceding procedure does the following:

• Sets the netbootNewMachineOU attribute on the Service Control Point (SCP) for the
Windows Deployment Services server to the distinguished name of the server
• Sets the NewMachineOUType registry key to 1
• Sets the NewMachineOUType registry key to 0
• Sets the netbootNewMachineOU attribute on the SCP for the Windows Deployment
Services server to the specified distinguished name

To choose whether to join client computers to the domain

Using the MMC Using WDSUTIL

1. Right-click the server, and then click 1. Open an elevated Command Prompt

119
Using the MMC Using WDSUTIL

Properties.
2. On the Client tab, clear the Do not
create account in Active Directory after
running the WDS Client check box to join
computers to the domain.
window.
2. To join new computers to the domain,
run WDSUTIL /Set-Server
/NewMachineDomainJoin:Yes.

The preceding procedure sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE\Providers\BINLSVC\NewMachineDomainJoin to 1.

Unattend File
To choose a default unattend file for the Windows Deployment
Services client

Using the MMC Using WDSUTIL

1. Right-click the server, and then click
Properties.
2. On the Client tab, select the Enable
client unattend check box and then
choose an unattend file for the relevant
architecture.
1. Open an elevated Command Prompt
window.
2. To turn on unattended installation and
specify the unattend file, run WDSUTIL
/Set-Server /WDSUnattend
/Policy:Enabled /File:<path>
/Architecture:{x86|x64|ia64}.

The preceding procedure sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WdsI
mgSrv\Unattend\Enabled to 1 and
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WdsI
mgSrv\Unattend\<arch>\FilePath to the specified path.

To specify whether an unattend file on the client computer will

override a default unattend file

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Do one of the following:
• To allow an unattend file on the

120
Using the MMC Using WDSUTIL

client computer to override the unattend

file sent from the server for the
Windows Deployment Services client,
run WDSUTIL /Set-Server
/WDSUnattend
/CommandLinePrecedence:Yes.
• To force the unattend file sent from
the server to be used for the Windows
Deployment Services client, run
WDSUTIL /Set-server
/WDSUnattend
/CommandLinePrecedence:No.

The preceding procedure sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WdsI
mgSrv\Unattend\CommandLineUnattendPrecedence to 1 or 0.

How to Manage Client Computers

This topic contains procedures for the tasks that are listed and described in the following table.

Type Procedure

Prestage Computers • To create a prestaged account for a

client computer
• To prestage a client computer to boot
from a different server
• To prestage a client computer to use a
boot program other than the default
• To prestage a client computer to use an
unattend file other than the default for the
Windows PE phase of unattended setup
• To prestage a client computer to use a
boot image other than the default
• To prestage a client computer to join a
domain

Specify Settings for Prestaged Computers • To view the attributes of a prestaged

client
• To change the rate at which pending

121
Type
Configure Auto-Add Functionality
Approve and Reject Pending Computers
Procedure
computers will poll the server
• To change the number of times pending
computers will poll the server
• To change the message displayed to
pending computers
• To set a default network boot server for
pending computers
• To set a default boot program for
pending computers
• To set a default unattend file for
pending computers
• To set a default boot image for pending
computers
• To set domain join options for pending
computers
• To enable Auto-Add functionality
• To change the length of time approved
computers are held in the Auto-Add
database
• To change the length of time rejected
and pending computers are held in the
Auto-Add database
• To delete the rejected or approved
computers table
• To view the table of computers that are
pending approval
• To approve a pending computer by
using the default settings
• To approve all pending computers by
using the default settings
• To approve a pending computer, but
change a setting
• To approve all pending computers, but
change a setting
• To reject a pending computer
122
 Caution
To modify the registry settings that are described in this guide, use only the Windows
Deployment Services management tools—you should not directly edit these settings and
attributes.

Note
Help for WDSUTIL is available by typing WDSUTIL /? at a command prompt or online at
http://go.microsoft.com/fwlink/?LinkId=112194.

Prestage Computers
To create a prestaged account for a client computer

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Add-Device
/Device:<name> /ID:<ID>, where the ID is
the GUID or MAC address of the computer
you want to prestage.

The command in the preceding procedure creates a computer account object in Active Directory
Domain Services (AD DS) for the specified computer, with the netbootGUID attribute set to the
specified ID.

To prestage a client computer to boot from a different server

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Set-Device
/Device:<name>
/ReferralServer:<ServerName>.

The preceding procedure sets the AD DS netbootMachineFilePath attribute to the specified

referral server.

To prestage a client computer to use a boot program other than

the default

123
Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Set-Device
/Device:<name> /BootProgram:<path>,
where <path> is the relative path to the boot
program you want from the RemoteInstall
folder.

The preceding procedure appends the specified path to the referral server as part of the
netbootMachineFilePath attribute on the computer.

To prestage a client computer to use an unattend file other than

the default for the Windows PE phase of unattended setup

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Set-Device
/Device:<name>
/WDSClientUnattend:<path>, where
<path> is the relative path to the unattend
file you want from the Remote Install shared
folder.

The preceding procedure sets the WdsUnattendFilePath variable in the netbootMirrorDataFile

AD DS attribute on the client’s computer account object to the specified path.

To prestage a client computer to use a boot image other than the

default

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Set-Device
/Device:<name> /BootImagePath:<path>,
where <path> is the relative path to the boot
image you want from the Remote Install
shared folder.

124
This command sets the BootImagePath variable in the netbootMirrorDataFile AD DS attribute
on the client’s computer account object to the specified path.

To prestage a client computer to join a domain

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Do one of the following:
• To enable the specified user to join
the client computer to the specified
domain once, run WDSUTIL /Set-
Device /Device:<name> /User:<user>
/JoinRights:JoinOnly
/JoinDomain:Yes
/Domain:<domain> /ResetAccount,
where:
<user> is domain\user or user@domain
<name> is the name of the computer
<domain> is the name of the domain
• To enable the specified user to join
the client computer to the specified
domain at any time, run WDSUTIL /Set-
Device /Device:<name> /User:<user>
/JoinRights:Full /JoinDomain:Yes
/Domain:<domain>.
• To join the client computer to the
specified domain without granting any
user rights, run WDSUTIL /Set-
Device /Device:<name>
/JoinDomain:Yes /Domain:<domain>.

The preceding procedure sets the JoinDomain variable in the netbootMirrorDataFile AD DS

attribute on the client’s computer account object to 1. It also grants the specified user rights on
the computer object.

Specify Settings for Prestaged Computers

To view the attributes of a prestaged client

125
Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Do one of the following:
• To view the prestaged client by
name in the local domain, run
WDSUTIL /Get-Device
/Device:<name>.
• To view a prestaged client by ID
(GUID or MAC) in the local domain, run
WDSUTIL /Get-Device /ID:<ID>.

Note
To specify that the client is in a
domain other than the local
one, specify
/Domain:<domain> with either
of these commands.

Note
To search the entire AD DS
forest, specify /Forest:Yes with
either of these commands.

The preceding procedure displays the requested information from the folder.

To change the rate at which pending computers will poll the

server

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. To set the time between polls, run
WDSUTIL /Set-Server /AutoAddPolicy
/PollInterval:<time in seconds>.

This command sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE\Providers\BINLSVC\AutoApprove\PollInterval to the specified time.

126
To change the number of times pending computers will poll the
server

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Set-Server
/AutoAddPolicy /MaxRetry:<retries>.

The preceding procedure sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE\Providers\BINLSVC\AutoApprove\PollMaxRetry to the specified value.

To change the message displayed to pending computers

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Set-Server
/AutoAddPolicy /Message:<message>.

This procedure sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE\Providers\BINLSVC\AutoApprove\PollMessage to the specified message.

To set a default network boot server for pending computers

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Set-Server
/AutoAddSettings /Architecture:{x86|x64|
ia64} /ReferralServer:<server name>.

The preceding procedure sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE\Providers\BINLSVC\AutoApprove\<arch>\ReferralServer to the specified server name.

To set a default boot program for pending computers

127
Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Set-Server
/AutoAddSettings /Architecture:{x86|x64|
ia64} /BootProgram:<path>, where the
path is relative to the Remote Install shared
folder.

The preceding procedure sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE\Providers\BINLSVC\AutoApprove\<arch>\BootProgramPath to the specified path.

To set a default unattend file for pending computers

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Set-Server
/AutoAddSettings /Architecture:{x86|x64|
ia64} /WDSClientUnattend:<path>, where
the path is relative to the RemoteInstall
folder.

The preceding procedure sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE\Providers\BINLSVC\AutoApprove\<arch>\WdsUnattendFilePath to the specified path.

To set a default boot image for pending computers

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Set-Server
/AutoAddSettings /Architecture:{x86|x64|
ia64} /BootImage:<path>, where <path> is
relative to the Remote Install shared folder.

128
The preceding procedure sets
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE\Providers\BINLSVC\AutoApprove\<arch>\BootImagePath to the specified path.

To set domain join options for pending computers

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Do one of the following:
• To enable the specified user
(specified as domain\user or
user@domain) to join the client
computer to the specified domain once,
run WDSUTIL /Set-Server
/AutoAddSettings Architecture:{x86|
x64|ia64} /User:<user>
/JoinRights:JoinOnly
/JoinDomain:Yes /Domain:<domain>.
• To enable the specified user to join
the client computer to the specified
domain at any time, run WDSUTIL /Set-
Server /AutoAddSettings
Architecture:{x86|x64|ia64}
/User:<user> /JoinRights:Full
/JoinDomain:Yes /Domain:<domain>.

The preceding procedure sets:

•

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\
WDSPXE\Providers\BINLSVC\AutoApprove\<arch>\JoinRights to 0 if Join Only and 1 if
Full
•

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\
WDSPXE\Providers\BINLSVC\AutoApprove\<arch>\JoinDomain to 1.

129
Configure Auto-Add Functionality
To enable Auto-Add functionality

Using the MMC Using WDSUTIL

1. Right-click the server, and then click 1. Open an elevated Command Prompt
Properties. window.
2. On the PXE Response settings tab, 2. Run WDSUTIL /Set-Server
click Respond to all (known and /AutoAddPolicy /Policy:AdminApproval.
unknown) client computers.
3. Select the check box For unknown
clients, notify administrator and
respond after approval.

The preceding procedure sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE\Providers\BINLSVC\AutoApprove\Policy to 1.

To change the length of time approved computers are held in the

Auto-Add database

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Set-Server
/AutoAddPolicy /RetentionPeriod
/Approved:<time in days>.

The preceding procedure sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE\Providers\BINLSVC\AutoApprove\ApprovedRetention to the specified number.

To change the length of time rejected and pending computers

are held in the Auto-Add database

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Set-Server

130
Using the MMC Using WDSUTIL

/AutoAddPolicy /RetentionPeriod
/Others:<time in days>.

The preceding procedure sets

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE\Providers\BINLSVC\AutoApprove\OtherRetention to the specified number.

To delete the approved or rejected computers table

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt window.

2. Run WDSUTIL /Delete-AutoAddDevices
/DeviceType:<ApprovedDevices|
RejectedDevices>.

The preceding procedure deletes the contents of the approved or rejected table in the Auto-Add
database.

Approve and Reject Pending Computers

To view the list of computers that are pending approval

Using the MMC Using WDSUTIL

1. Expand the server node. 1. Open an elevated Command Prompt

2. Select the Pending Devices node. window.
2. Run WDSUTIL /Get-
AutoAddDevices
/DeviceType:PendingDevices.

The preceding procedure displays the Auto-Add devices table from the Binlsvcdb.mdb file.

To approve a pending computer by using the default settings

Using the MMC Using WDSUTIL

1. Select the Pending Devices node. 1. Open an elevated Command Prompt

2. Right-click the computer you want to window.
approve, and then click Approve. 2. Run WDSUTIL /Approve-

131
Using the MMC Using WDSUTIL

AutoAddDevices /RequestID:<ID> with

the ID obtained from the Auto-Add
database.

The preceding procedure approves the computer. For more information, see Prestaging Client
Computers.

To approve all pending computers by using the default settings

Using the MMC Using WDSUTIL

1. Right-click the Pending Devices node. 1. Open an elevated Command Prompt

2. Click Approve All. window.
2. Run WDSUTIL /Approve-
AutoAddDevices /RequestID:All.

The preceding procedure approves the computers. For more information, see Prestaging Client
Computers.

To approve a pending computer, but change a setting

132
Using the MMC (name change only)
1. Select the Pending Devices node.
2. Select the computer you want to
approve.
3. On the Action menu, click Name and
Approve.
4. In the dialog box, type the name you
want to give the computer.
The preceding procedure approves the computer, with the configured settings. For more
information, see Prestaging Client Computers.
Using WDSUTIL
1. Open an elevated Command Prompt
window.
2. Run WDSUTIL /Approve-
AutoAddDevices /RequestID:<ID> with
the ID obtained from the Auto-Add database
In addition, you can append this command with
the following options:
• To change the name, specify
/MachineName:<name>
• To change the organizational unit (OU)
where the account will be created, specify
/OU:<name of OU>.
• To change the user account for the
domain join, specify /User:<name> where
the <name> is domain\user or
user@domain.
• To enable the user to join this computer
to the domain only once, specify
/JoinRights:JoinOnly.
• To enable the user to join this computer
to the domain at any time, specify
/JoinRights:Full.
• To join this computer to the domain,
specify /JoinDomain:Yes.
• To direct the computer to install from a
different Windows Deployment Services
server, specify /ReferralServer:<server
name>.
• To change the boot program used,
specify /BootProgram:<path>.
• To change the unattend file used for the
Microsoft Windows Preinstallation
Environment (Windows PE) phase of
unattended setup, specify
/WDSClientUnattend:<path>
• To change the boot image used, specify
/BootImagePath:<path>.
133
To approve all pending computers, but change a setting

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Approve-
AutoAddDevices /RequestID:All
In addition, you can append this command with
the following options:
• To change the OU where the accounts
will be created, specify /OU:<name of OU>.
• To change the user account used for
domain join, specify /User:<name> where
<name> is domain\user or user@domain.
• To allow the user to join these
computers to the domain once only, specify
/JoinRights:JoinOnly.
• To allow the user to join these
computers to the domain at any time,
specify /JoinRights:Full.
• To join these computers to the domain,
specify /JoinDomain:Yes.
• To direct the computers to install from a
different Windows Deployment Services
server, specify /ReferralServer:<server
name>.
• To change the boot program used,
specify /BootProgram:<path>.
• To change the unattend file used for the
Windows PE phase of unattended setup,
specify /WDSClientUnattend:<path>.
• To change the boot image used, specify
/BootImagePath:<path>.

The preceding procedure approves the computers with the configured settings. For more
information, see Prestaging Client Computers.

To reject a pending computer

134
Using the MMC Using WDSUTIL

1. Select the Pending Devices node. 1. Open an elevated Command Prompt

2. Right-click the computer, and then click
Reject or Reject All.
window.
2. Do one of the following:
• To reject a single computer, run
WDSUTIL /Reject-AutoAddDevices
/RequestID:<ID> with the ID obtained
from the Auto-Add database.
• To reject all computers, run
WDSUTIL /Reject-AutoAddDevices
/RequestID:All.

The preceding procedure sets the Status field for the computer to 2 (rejected) in the table of
pending computers, and it sends the Abortpxe.com file to the computer.

How to Manage Images

This topic contains procedures for the tasks that are listed and described in the following table.

Type Procedure

General Tasks • To export an image from the server to a

stand-alone .wim file
• To replace an image on the server with
an updated version
• To remove an image

Boot Images • To add a boot image to the server

• To set the name, description, and
online/offline status attributes on a boot
image
• To display the attributes of a boot image
• To create a capture image
• To create a capture image manually
• To create a discover image
• To create a discover image manually

Install Images • To add an install image

• To set the attributes on an install image
• To display the attributes on an install

135
Type Procedure

image
• To convert an RIPREP image to a .wim
install image
• To make a copy of an install image
within an image group

Image Groups • To remove an image group

• To add an image group to the image
store
• To set the attributes on an image group
• To display information about all images
in an image group

Note
Help for WDSUTIL is available by typing WDSUTIL /? at a command prompt or online at
http://go.microsoft.com/fwlink/?LinkId=112194.

General Tasks
To export an image from the server to a stand-alone .wim file

Using the MMC Using WDSUTIL

1. Right-click a boot or install image, and 1. Open an elevated Command Prompt

then click Export Image. window.
2. In the dialog box, choose a file name to 2. Do one of the following:
export the image to. • For a boot image, run WDSUTIL
/Verbose /Progress /Export-Image
/Image:<name> /ImageType:Boot
/Architecture:{x86|x64|ia64}
/DestinationImage /Filepath:<path
and file name>.
• For an install image, run
WDSUTIL /Verbose /Progress
/Export-Image /Image:<name>
/ImageType:Install
/ImageGroup:<image group
name> /DestinationImage
/Filepath:<path and file name>.

136
Using the MMC Using WDSUTIL

3. You can also set the following:

• To set these metadata fields on the
image, append /Name:<name> or
/Description:<description>
• To determine behavior when the
image specified in /DestinationImage
already exists, append /Overwrite:{Yes|
No|Append}. Yes will overwrite the
image, No will cause an error, and
Append will append the new image to
the existing .wim file. Note that Append
is available only for install images.

The preceding procedure does the following:

• For a boot image, it copies the file to the specified destination.
• For an install image, it combines the metadata in the Install.wim file with the resources in
the Res.rwm file into a single .wim file at the specified destination.

To replace an image on the server with an updated version

Using the MMC Using WDSUTIL

1. Right-click a boot or install image, and 1. Open an elevated Command Prompt

then click Replace Image.
2. Browse to the updated version.
3. Click through the rest of the wizard.
window.
2. Do one of the following:
• To replace a boot image, run
WDSUTIL /Verbose /Progress
/Replace-Image /Image:<name>
/ImageType:Boot /Architecture:{x86|
x64|ia64} /ReplacementImage
/ImageFile:<path>.
• To replace an install image, run
WDSUTIL /Verbose /Progress
/Replace-Image /Image:<name>
/ImageType:Install
/ImageGroup:<image group
name> /ReplacementImage
/ImageFile:<path>.

The preceding procedure adds the new image to the image store and removes the old one.

137
To remove an image
Using the MMC
1. Right-click a boot or install image.
2. Click Delete.
The preceding procedure deletes the .wim image file from the image store.
Note
If you specify /SourceImage, data folders associated with the original image (for example,
folders that contains unattend files or language packs) will be kept intact and will be
associated with the replacement image.
Boot Images
To add a boot image to the server
Using the MMC
1. Right-click the Boot Images node, and
then click Add Boot Image.
2. Enter the path to the boot image or
browse to the image file, and then click
Next. In most cases, you should use the
standard boot image that is included on the
Windows Server 2008 media (located at
\Sources\boot.wim) without modification.
Do not use the Boot.wim from the
Using WDSUTIL
1. Open an elevated Command Prompt
window.
2. Do one of the following:
• For boot images, run WDSUTIL
/Remove-Image /Image:<name>
/ImageType:Boot /Architecture:{x86|
x64|ia64}
• For install images, run WDSUTIL
/Remove-Image /Image:<name>
/ImageType:Install
/ImageGroup:<image group name>. If
the source image file contains more
than one install image, append
/SourceImage:<Source image name> to
specify the image to use as a
replacement.
Using WDSUTIL
1. Open an elevated Command Prompt
window.
2. Run WDSUTIL /Verbose /Progress
/Add-Image /ImageFile:<path>
/ImageType:Boot, where the path is a full
path to the image file.
138
Using the MMC Using WDSUTIL

Windows Vista media unless your version

of Windows Vista has SP1 integrated into
the DVD.
3. Enter an image name and description,
and then click Next.
4. Review the choices, and then click
Next.

The preceding procedure does the following:

• Copies the boot image file to the folder \RemoteInstall\Boot\<arch>\Images.
• Generates a Boot Configuration Data (BCD) store for the boot image in the folder
\RemoteInstall\Boot\<arch>\Images.
• Generates a combined BCD store for the architecture in folder
\RemoteInstall\Boot\<arch>.
• Extracts the required files for Pre-Execution Environment (PXE) booting from
\Windows\Boot\PXE in the image to the folder \RemoteInstall\Boot. If the files already exist on
the server, a version check is performed so that the newest files are used.

To set the name, description, and online/offline status attributes

on a boot image

Using the MMC Using WDSUTIL

1. Right-click a boot image, and then click 1. Open an elevated Command Prompt
Disable to take the image offline. window.
2. Right-click the image, and then click 2. Do one of the following:
Properties. • To take the image offline, run
3. Enter the name and description. WDSUTIL /Set-Image
/Image:<name> /ImageType:Boot
/Architecture:<arch> /Enabled:No.
• To change the name and
description, run WDSUTIL /Set-
Image /Image:<name>
/ImageType:Boot
/Architecture:<arch>
/Name:<name>
/Description:<description>.

In the preceding procedure, note the following:

• Taking an image offline sets the hidden file attribute on the relevant .wim file.
139
 • Changing the name and description changes these attributes in the metadata header of
the .wim file.

To display the attributes of a boot image

Using the MMC Using WDSUTIL

1. Right-click a boot image. 1. Open an elevated Command Prompt

2. Click Properties. window.
2. Run WDSUTIL /Get-Image
/Image:<name> /ImageType:Boot
/Architecture:<arch>.

The preceding procedure displays the file name, image name, description, architecture, image
type, size, creation and modify dates, default languages, operating system version, service pack
level, and online and offline status of the image.

To create a capture image

140
Using the MMC Using WDSUTIL

1. In the Windows Deployment Services 1. Open an elevated Command Prompt

MMC snap-in, expand the Boot Images
node.
2. Right-click the image to use it as a
capture image (most commonly, the
\Sources\boot.wim file from the installation
media).
3. Click Create Capture Boot Image.
window.
2. Run WDSUTIL /New-CaptureImage
/Image:<source boot image name>
/Architecture:{x86|ia64|x64}
/DestinationImage /FilePath:<file path>,
where <filepath> is the path and name for
the capture image.

4. Type a name, description, and the

location where you want to save a local
copy of the file. You must specify a location
so that if there is a network issue when you
deploy the capture image, you have a local
copy.
5. Continue to follow the instructions in
the wizard, and when it is completed, click
Finish.
6. Right-click the boot image folder.
7. Click Add Boot Image.
8. Browse and select the new capture
image, and then click Next.
9. Follow the instructions in the Image
Capture Wizard.

To create a capture image manually

141
Using the MMC Using WDSUTIL

1. Create a temporary folder in the path N/A

that is pointed to by the environment
variable, %TEMP%.
2. Apply the contents of the source boot
image from the Windows Deployment
Services server’s image store to the \Temp
folder.
3. Create a Winpeshl.ini file in the
Windows\System32 folder of the applied
image with the following section:
[LaunchApps]

%SYSTEMROOT%\system32\wdscapture.exe

4. Capture the modified image into a

new .wim file.
5. Update the image metadata to reflect
any changes to the image name or
description.

To create a discover image

Using the MMC Using WDSUTIL

1. In the Windows Deployment Services 1. Open an elevated Command Prompt

MMC snap-in, expand the Boot images
node.
2. Right-click the image you want to use
as a discover image. This must be the
Boot.wim file from Windows Server 2008
media.
3. Click Create Discover Boot Image.
window.
2. Run WDSUTIL /New-DiscoverImage
/Image:<name> /Architecture:{x86|x64|
ia64} /DestinationImage /FilePath:<path
and name to new file>. To specify which
server the discover image connects to,
append /WDSServer:<server name or IP>.

4. Follow the instructions in the wizard,

and when it is completed, click Finish.
5. Right-click the boot image folder.
6. Click Add Boot Image.
7. Browse and select the new discover
image, and then click Next.
8. Follow the instructions in the wizard.

142
To create a discover image manually

Using the MMC Using WDSUTIL

1. Create a temporary folder in the path N/A

pointed to by the environment variable,
%TEMP%.
2. Apply the contents of the source boot
image from the Windows Deployment
Services server’s image store to the
temporary folder.
3. Create a Winpeshl.ini file in the
Windows\System32 folder of the applied
image with the following section:
[LaunchApps]

%SYSTEMROOT%\sources\setup.exe, "/wds
/wdsdiscover"

Or

[LaunchApps]

%SYSTEMROOT%\sources\setup.exe, "/wds
/wdsdiscover /wdsserver:<server>"

4. Capture the modified image into a

new .wim file.
5. Update the image metadata to reflect
any changes to the image name or
description.

Install Images
To add an install image

Using the MMC Using WDSUTIL

1. Right-click the image group, and then
click Add Install Image.
2. Select an image group.
3. Select the file to add.
4. Proceed through the rest of the wizard.
1. Open an elevated Command Prompt
window.
2. To create an image group, run
WDSUTIL /Add-ImageGroup
/ImageGroup:<image group name>.
3. Run WDSUTIL /Verbose /Progress
/Add-Image /ImageFile:<path to .wim

143
Using the MMC Using WDSUTIL

file> /ImageType:Install.
If more than one image group exists on the
server, append /ImageGroup:<image
group name> to specify which group the
image should be added to.
To skip the integrity check before adding the
image, append /SkipVerify.

The preceding procedure runs an integrity check on the specified image file, creates a metadata-
only .wim file in the image group folder, and adds the resources in the image file to the
Resource .wim (res.rwm) file for the image group.

To set the attributes for an install image

The following procedure sets the name, description, online and offline status, access controls,
and associated unattend file for an image.

Using the MMC Using WDSUTIL

1. Right-click an install image, and then 1. Open an elevated Command Prompt

either click Disable to take the image window.
offline or click Enable to bring it back 2. Run WDSUTIL /Set-Image
online. Image:<name> /ImageType:Install
2. On the Action menu, click Properties. /ImageGroup:<image group name>
3. Enter the name and description in the /Name:<name>
appropriate text boxes. /Description:<description>
/UserFilter:<SDDL> /Enabled:{Yes|No}
4. Check Allow image to install in
/UnattendFile:<path>.
unattended mode, and then select a file to
associate an unattend file with the install
image.
5. Use the Security tab to set access
controls.

The preceding procedure changes image metadata or file access control lists (ACLs) on the
image file to store the attributes. If you specify an unattend file, this procedure also copies it into
the image store. Note that taking an image offline makes the file hidden.

To display the attributes for an install image

144
Using the MMC Using WDSUTIL

1. Right-click the image. 1. Open an elevated Command Prompt

2. Click Properties. window.
2. Run WDSUTIL /Get-Image
/Image:<name> /ImageType:Install
/ImageGroup:<image group name>.

The preceding procedure displays the file name, image name, description, architecture, image
type, image group, size, HAL type, creation and modification time, languages, operating system
version, ACLs, unattend file (if assigned), and the online or offline status of the image.

To convert a RIPREP image to a .wim install image

For more information, see Creating Images.

Using the MMC Using WDSUTIL

1. Click the Legacy Images node. 1. Open an elevated Command Prompt

2. Right-click the RIPREP image you
want to convert, and then click Convert to
WIM.
3. Enter the name, description, path, and
file name, and then click Next.
window.
2. Run WDSUTIL /Verbose /Progress
/Convert-RiPrepImage /FilePath:<path to
RIPREP image .sif file>
/DestinationImage /FilePath:<path and
name of .wim image>. In addition, you can
specify the following:
• To give the new .wim image a name
in the metadata, append
/Name:<name>.
• To give the new .wim image a
description in the metadata, append
/Description:<description>.
• To convert the original RIPREP
image, rather than a copy, append
/InPlace.
• To determine behavior when the
image file specified in
/DestinationImage already exists,
append /Overwrite:{Yes|No|Append}.
Yes will overwrite the .wim file, No will
cause an error, and Append will
append the new image to the
existing .wim file.

145
To make a copy of an install image

Using the MMC Using WDSUTIL

N/A 1. Open an elevated Command Prompt

window.
2. Run WDSUTIL /Copy-Image
/Image:<name> /ImageType:Install
/ImageGroup:<image group name>
/DestinationImage /Name:<name>
/Filename:<file name>. To give the new
image a description, append
/Description:<description>.

The preceding procedure creates a copy of the metadata .wim file that corresponds to the
selected image, and it sets the image name and file name (and description, if specified) to the
values you specify.

Image Groups
To remove an image group

Using the MMC Using WDSUTIL

1. Right-click image group. 1. Open an elevated Command Prompt

2. Click Delete. window.
2. Run WDSUTIL /Remove-
ImageGroup /ImageGroup:<image group
name>.

This procedure deletes the image group folder and all of its contents from the image store. For
install images, if an associated data folder exists (the folder that contains unattend files or
language packs), it will be removed as well.

To add an image group to the image store

Using the MMC Using WDSUTIL

1. Right-click the Install Images node, 1. Open an elevated Command Prompt

and then click Add Image Group. window.
2. Enter the name for the image group. 2. Run WDSUTIL /Add-ImageGroup
/ImageGroup:<image group name>.

146
The preceding procedure creates a folder in the image store with the specified name.

To set the attributes on an image group

Use the following procedure to set the name and access controls for an image group.

Note
Changing the name renames the image group folder in the image store, and changing
the security sets ACLs on the folder and its contents.

Using the MMC Using WDSUTIL

1. Right-click image group, and then click
Rename.
2. Right-click image group, and then click
Security.
1. Open an elevated Command Prompt
window.
2. To change the name, run WDSUTIL
/Set-ImageGroup /ImageGroup:<existing
image group name> /Name:<new image
group name>.
3. To set the security, run WDSUTIL /Set-
ImageGroup /ImageGroup:<image group
name> /Security:<SDDL>, where <SDDL>
is the security descriptor you want to use for
the image group, in Security Descriptor
Definition Language (SDDL) format.

To display information about all images in an image group

Using the MMC Using WDSUTIL

1. Select an image group. 1. Open an elevated Command Prompt

2. View the images in the right pane.
window.
2. Run WDSUTIL /Get-ImageGroup
/ImageGroup:<image group name>. To
display the full image metadata on each
image in the group, append /Detailed.

How to Create Multicast Transmissions

This topic explains how to use Windows Deployment Services to create multicast transmissions.

147
In This Topic
• Overview
• Prerequisites for Creating a Multicast Transmission
• Known Issues in Creating a Multicast Transmission
• Transmission Types
• To create a multicast transmission with Deployment Server
• To manage transmissions
• To manage clients in a transmission
• To configure the UDP port range for multicast
• To configure how the server will obtain IP addresses for multicast transmissions

Note
Help for WDSUTIL is available by typing WDSUTIL /? at a command prompt or
online at http://go.microsoft.com/fwlink/?LinkId=112194.
For information about using Transport Server to create a namespace, see Using Transport
Server.

Overview
Multicasting enables you to deploy an image to a large number of client computers without
overburdening the network. When you create a multicast transmission for an image, the data is
sent over the network only once, which can drastically reduce the amount of network bandwidth
that is used.

Consider implementing multicasting if your Multicasting might not optimize your installations
organization: if your organization:

• Has network routers that support
multicasting.
• Is a large company that requires many
concurrent client installations.
• Wants to use network bandwidth
efficiently. This is because with this feature,
images are sent over the network only
once, and you can specify limitations (for
example, to only use 10 percent of your
bandwidth).
• Has enough disk space on client
computers for the image to be downloaded.
• Meets the requirements listed in the
following section.
• Has network routers that do not support
multicasting.
• Does not have bandwidth overload
problems.
• Deploys images to only a small number
of client computers simultaneously.
• Has disk space limitations on the client
computers. (This is because the image is
downloaded to client computers instead of
being installed from a server.)

148
Prerequisites for Creating a Multicast
Transmission
To implement this feature in your organization, you must have all of the following:
• Routers that support multicasting. In particular, your network infrastructure needs to
support the Internet Group Management Protocol (IGMP) to properly forward multicast traffic.
Without the IGMP, multicast packets are treated as broadcast packets, which can lead to
network flooding.
• At least one install image that you want to transmit on the server
• The Boot.wim file from the Windows Server 2008 media (located in the \Sources folder).
Do not use the Boot.wim from the Windows Vista media unless your version of
Windows Vista has SP1 integrated into the DVD.
• Internet Group Membership Protocol (IGMP) snooping should be enabled on all devices.
This will cause your network hardware to forward multicast packets only to those devices that
are requesting data. If IGMP snooping is turned off, multicast packets are treated as
broadcast packets, and will be sent to every device in the subnet.

Known Issues in Creating a Multicast

Transmission
You may encounter the following issues when implementing multicasting:
• If you use the Windows Vista Boot.wim file for multicast transmissions, you will be able to
create the transmission, but people who boot into it will not be able to join it.
• If multiple servers are using multicast functionality on a network (Transport Server,
Deployment Server, or another solution), it is important that each server is configured so that
the multicast IP addresses do not collide. Otherwise, you may encounter excessive traffic
when you enable multicasting. Note that each Windows Deployment Services server will have
the same default range. To work around this issue, specify static ranges that do not overlap to
ensure that each server is using a unique IP address or Multicast Address Dynamic Client
Allocation Protocol (MADCAP). To specify this option, right-click the server in the MMC snap-
in, click Properties, and then click the Network Settings tab.
• After you configure Windows Deployment Services server, if you modify the Multicast IP
Address, the User Data Protocol (UDP) port range, or the remote procedure call (RPC) port
number (by running wdsutil /set-server /rpcport:<portnum>), you must restart the service
before the changes will take effect. If you do not restart the service, the server will use the old
values and may not answer clients. To restart the service, you can do either of the following:
right-click Windows Deployment Services in the MMC snap-in, and then click Restart; or run
wdsutil /stop-server and then run wdsutil /start-server in an elevated Command Prompt
window.

149
 • Each transmission can be run only as fast as the slowest client. That is, the entire
transmission will be slow if there is one slow client. To resolve this issue, first determine the
client that is holding back the transmission (this is called the master client). To do this, view
the output of the following command: WDSUTIL /Get-MulticastTransmission /Show-
clients. Next, disconnect the master client. This will force the master client to run the
transmission by using the Server Message Block (SMB) protocol, and the other clients'
multicast performance should speed up. If they do not speed up, there is a problem with the
client's hardware (for example, a slow hard disk) or a network problem.

Transmission Types
There are two types of multicast transmissions:
• Auto-Cast. This option indicates that as soon as an applicable client requests an install
image, a multicast transmission of the selected image begins. Then, as other clients request
the same image, they too are joined to the transmission that is already started.
• Scheduled-Cast. This option sets the start criteria for the transmission based on the
number of clients that are requesting an image and/or a specific day and time. If you do not
select either of these check boxes, the transmission will not start until you manually start it.
Note that in addition to these criteria, you can start a transmission manually at any time by
right-clicking it and then clicking Start.

Note
Content is transferred over the network only if clients request data. If no clients are
connected (that is, the transmission is idle), data will not be sent over the network.

Note
After you configure Windows Deployment Services server, if you modify the Multicast
IP Address, the UDP port range, or the RPC port number (by running wdsutil /set-
server /rpcport:<portnum>), you must restart the service before the changes will
take effect. If you do not restart the service, the server will use the old values and
may not answer clients. To restart the service, you can do either of the following:
right-click Windows Deployment Services in the MMC snap-in, and then click
Restart; or run wdsutil /stop-server and then run wdsutil /start-server in an
elevated Command Prompt window.

To create a multicast transmission with

Deployment Server
Using the MMC Using WDSUTIL

Do one of the following: 1. Open an elevated Command Prompt

• Right-click the Multicast window.
Transmission node, and then click 2. Do one of the following:

150
Using the MMC
Create Multicast Transmission.
• Right-click an image, and then click
Create Multicast Transmission.
To manage transmissions
Using the MMC
• Start the transmission. If the
transmission is the Scheduled-Cast type,
there is at least one client, and the
transmission has not started yet, you can
right-click the transmission and then click
Start.
• Delete the transmission. If you right-
click the transmission and click Delete, the
multicast transmission stops and each
client installation will fall back to using
unicast transmission. That is, the client
installations will not be deleted or stopped,
but they will not use the multicast
transmission to complete the installation.
• Deactivate the transmission. If you
right-click the transmission and then click
Deactivate, each client that is currently
installing will continue, but no new clients
Using WDSUTIL
a. To create an Auto-Cast transmission
Syntax: WDSUTIL /New-
MulticastTransmission /Image:<image
name> /FriendlyName:<friendly name>
/ImageType:Install /ImageGroup:<Image
group name>
/TransmissionType:AutoCast
b. To create a Scheduled-Cast
transmission
Syntax: WDSUTIL /New-
MulticastTransmission /Image:<image
name> /FriendlyName:<friendly name>
/ImageType:Install /ImageGroup:<Image
group name>
/TransmissionType:ScheduledCast
[/Time:<yyyy/mm/dd:hh:mm>][/Clients:<no
of clients>]
Using WDSUTIL
• To start the transmission
Syntax: WDSUTIL /Start-
MulticastTransmission /Image:<image
name> /ImageType:Install
/ImageGroup:<image group name>
Note
You can start the transmission only
if it is the Scheduled-Cast type,
there is at least one client, and the
transmission is not already started.
• To delete the transmission
Syntax: WDSUTIL /Remove-
MulticastTransmission /Image:<image
name> /ImageType:Install
/ImageGroup:<image group name> /Force
• To deactivate the transmission
Syntax: WDSUTIL /Remove-
151
Using the MMC
will be joined to the transmission. After
each current client installation is completed,
the transmission will be deleted. If there are
no clients when you click this option, the
transmission will be deleted instantly.
• View the transmission's properties.
To view the properties, right-click the
transmission and then click Properties.
Note that you cannot edit the properties of
a transmission after it is created. To make a
change after you have created a
transmission, you need to delete it and then
recreate it.
• Refresh the transmissions and data.
To do this, right-click a transmission and
then click Refresh. You can also refresh
the data by pressing F5.
To manage clients in a transmission
Using the MMC
• Viewclients and see progress. To
view any connected clients, expand the
Multicast Transmissions node and then
click the image. The connected clients
(including the current installation time and
the percentage complete) are shown in the
right pane.
• Stop a client installation. To stop the
installation completely, right-click a client
and then click Disconnect. You should use
this option with caution because the
installation will fail and the computer could
be left in an unusable state.
• Disconnect a client from a multicast
transmission. To discontinue the
transmission for a particular client but
continue to transfer the image through
unicasting, right-click the client, and then
Using WDSUTIL
MulticastTransmission /Image:<image
name> /ImageType:Install
/ImageGroup:<image group name>
• To view the transmission's
properties
Syntax: WDSUTIL /Get-
MulticastTransmission /Image:<image
name> /ImageType:Install
/ImageGroup:<image group name>
Using WDSUTIL
• To view clients and see progress
Syntax: WDSUTIL /Get-
MulticastTransmission /Image:<image
name> /ImageType:Install
/ImageGroup:<image group name>
/show:clients
• To stop a client installation
completely
Syntax: WDSUTIL /Disconnect-Client
/ClientID:<id> /Force.
Note
You should use this option with
caution because the installation will
fail and the computer could be left
in an unusable state.
• To disconnect a client from a
multicast transmission but continue to
152
Using the MMC Using WDSUTIL

click Bypass multicast. transfer the image by using unicasting

Syntax: WDSUTIL /Disconnect-Client
/ClientID:<id>
• To view the client <id> for each
transmission
Syntax: WDSUTIL /Get-
MulticastTransmission /Image:<image
name> /ImageType:Install
/ImageGroup:<image group name>
/show:clients

To configure the UDP port range for multicasting

This setting specifies the range of UDP ports to use for multicasting and other components, such
as the Trivial File Transfer Protocol (TFTP) provider. Before you change this range, you need to
have at least as many ports as you have sessions and concurrent clients accessing the server. In
terms of multicasting, a session is a network interface on your server. To calculate the number of
sessions, multiply the number of network adapters on your server by the number of images that
could be concurrently transferred using multicasting. For example, if you have two network
adapters, and clients are connected on both interfaces, the content will be sent on the network
twice (once from each interface). So in this case, you would need at least two ports. Because this
range is also used by the TFTP provider, you will need as many available ports as you have
concurrent clients accessing the server.

Using the MMC Using WDSUTIL

1. Right-click the server, and then click
Properties.
2. On the Network Settings tab, specify
the UDP port range.
1. Open an elevated Command Prompt
window.
2. Run WDSUTIL /Set-Server
[/Server:<name>] /Transport
/StartPort:x /EndPort:y.

To configure how the server will obtain IP

addresses for multicasting
The server allocates a multicast IP address to each multicast session, and all connected clients
listen in on that address. It's important that all IP addresses be unique on the network to ensure
that each client receives the correct data. If you have a complex network, you should consider
using DHCP to select the addresses. In more basic environments, you can configure a range and
have the Windows Deployment Services server select the address.
153
Using the MMC Using WDSUTIL

3. 1. Right-click the server, and then 1. Open an elevated Command Prompt

click Properties.
2. On the Network Settings tab under
Multicast IP Address, select one of the
following:
• Obtain IP address from DHCP.
You can select this option only if your
DHCP server supports it. The IP
address for each namespace will be
obtained by using MADCAP (RFC
2730, Multicast).
• Use IP address from the
following range. You will need to enter
a range.
window.
2. Do one of the following:
• To use MADCAP to obtain the IP
address for each namespace, run
WDSUTIL /Set-Server
[/Server:<name>] /Transport
/ObtainIPFrom:DHCP.
• To configure a preset range of IP
addresses, run WDSUTIL /Set-Server
[/Server:<name>] /Transport
/ObtainIPv4From:Range
/Start:x.x.x.x /End:y.y.y.y.

Example Multicast Scripts

The following examples are sample scripts that you can use with your multicast transmissions.
To use each script, copy the code to a file and then save, it using the .vbs file name extension.
Then open an elevated Command Prompt window and run a command that uses the following
syntax: cscript <nameoffile>.vbs <WDSServer>. For example: cscript mcinfo.vbs localhost.

In This Topic
• Stop Transmissions Slower than 1 MB per Second
• Display Performance Information About Clients

Stop Transmissions Slower than 1 MB per Second

The following Microsoft Visual Basic script will stop the transmission of the master client for any
multicast session that has been transmitting data at a rate slower then 1 MB per second for
longer than 60 seconds. You can configure these values by using the parameters at the top of the
script. The master client is the slowest client in a transmission — that is, the client that is not
capable of installing any faster while the other clients may be able to install at a faster rate. To
determine the master client, view the output of the following command: WDSUTIL /Get-
MulticastTransmission /Show-clients. Note that there may be as many master clients as the
server has network adapters.
' -------------Times are in milliseconds

154
sleepTime = 5000 ' Minimum time to wait between each query to the server

timeThreshold = 60000 ' Minimum time to wait before kicking the master client out of a
slow session

' ------------- Speeds are in KB/sec

speedThreshold = 1024 ' Minimum transfer rate for a session

' ------------- Display variables

displayAllSessions = true ' Display all sessions on the server, not just the slow sessions

printStatusDots = true ' Print a dot every time we contact the server. Useful to show
that the script is doing something

' ------------------------------- End user defined settings

-------------------------------

Dim sessionDictionary, Manager, Server, hostname

' WDS Transport type definitions

WdsTptDisconnectUnknown = 0

WdsTptDisconnectFallback = 1

WdsTptDisconnectAbort = 2

' Run main

main()

' ---------------------------------- main

sub main

if WScript.Arguments.Count < 1 then

wscript.echo "[WARN]: Hostname not specified on command line, trying to

connect to localhost"

hostname = "localhost"

else

hostname = WScript.Arguments.Item(0)

end if

155
 ' We use a dictionary to keep track of sessions on the server

Set sessionDictionary = CreateObject("Scripting.Dictionary")

' Create the Transport Manager

Set Manager = CreateObject("WdsTptMgmt.WdsTransportManager")

' Connect to the server

Set Server = Manager.GetWdsTransportServer(hostname)

' Echo out current settings

if displayAllSessions = false then

wscript.echo "[INFO]: Not displaying information for all sessions"

end if

if printStatusDots then

wscript.echo "[INFO]: Printing status dots"

end if

wscript.echo "[INFO]: Speed Threshold: " + Cstr(speedThreshold) + " KB/sec, Time

Threshold: " + Cstr(Int(timeThreshold/1000)) + "s, Sleep time: " +
Cstr(Int(sleepTime/1000)) + "s"

wscript.echo "[INFO]: Examining sessions on " + Server.name + "..." + vbCrLf

' Loop forever. User must control C out of the script to stop execution.

Do while true

if printStatusDots then

Wscript.StdOut.Write(".")

end if

loopAndKick()

wscript.sleep(sleepTime)

loop

end sub

156
' ---------------------------------- loopAndKick

sub loopAndKick

' Get a list of the namespaces on the server

Set NamespaceCollection = Server.NamespaceManager.RetrieveNamespaces("", "", False)

' Get all namespaces present on the server

for i = 1 to CLng(NamespaceCollection.count)

Set ns = NamespaceCollection.Item(i)

' Get all contents for this namespace

Set ContentCollection = NamespaceCollection.Item(i).RetrieveContents()

for j = 1 to CLng(ContentCollection.count)

Set content = ContentCollection.item(j)

' Get all sessions for this content

Set SessionCollection = content.RetrieveSessions()

for k = 1 to CLng(SessionCollection.count)

Set session = SessionCollection.item(k)

Set ClientCollection = session.RetrieveClients()

'Calculate the transfer rate, in KB/sec, for this session

tRate = CLng(session.TransferRate)

tRate = Int(tRate / 1024)

' Echo this session out to the screen

if displayAllSessions then

wscript.echo ns.name + content.name + ", Num clients: " +

CStr(ClientCollection.count) + ", " + CStr(tRate) + " kB/sec"

end if

' If the session ID already exists in the dictionary, but no

clients are connected, remove the entry from the dictionary

if ( (CLng(ClientCollection.count) = 0) AND
sessionDictionary.Exists( CLng(session.ID)) ) then

157
 wscript.echo vbTab + "Remove: " + Cstr(session.ID)

sessionDictionary.Remove(CLng(session.ID))

' If the session ID exists in the dictionary, update the session

details, and kick the master client if needed

elseif sessionDictionary.Exists( CLng(session.ID) ) then

' Retrieve and update timeSlow

timeSlow = sessionDictionary.Item( CLng(session.ID) )

timeSlow = timeSlow + sleepTime

' If we've gone too slow for too long, kick the current
master client

if ( (tRate < speedThreshold) AND (timeSlow >

timeThreshold) ) then

' Make sure we have a valid master client ID before

we attempt to kick

if Clng(session.MasterClientId) <> 0 then

wscript.echo vbTab + "Kicking client: " +

Cstr(session.MasterClientId)

Server.DisconnectClient session.MasterClientId,
WdsTptDisconnectFallback

' Reset time slow for this session

timeSlow = 0

end if

end if

' Remove the old entry from the dictionary

sessionDictionary.Remove(CLng(session.ID))

' If the session is still too slow, add it back to the

dictionary with the new time value

if( tRate < speedThreshold) then

158
 wscript.echo vbTab + "Update: " + Cstr(session.ID) +
", Time slow: " + Cstr(Int(timeSlow/1000)) + "s"

sessionDictionary.Add CLng(session.ID), timeSlow

Otherwise, we've removed the session from the

dictionary above

else

wscript.echo vbTab + "Remove: " + Cstr(session.ID)

end if

' The session isn't in the dictionary. If the session is going

too slow and has clients connected, add it to the dictionary

else

if( (tRate < speedThreshold) AND

(CLng(ClientCollection.count) <> 0) ) then

wscript.echo vbTab + "Add: " + Cstr(session.ID)

sessionDictionary.Add CLng(session.ID), 0

end if

end if

next

next

next

end sub

Display Performance Information About Clients

The following Visual Basic script displays performance information for all clients in all
transmissions that are connected to the same server.
' Create the Tranport Manager

Set Manager = CreateObject("WdsTptMgmt.WdsTransportManager")

if WScript.Arguments.Count = 0 then

wscript.echo "INFO: Specify a host name on the command line to connect to a

remote host" & vbCrLf

Set Server = Manager.GetWdsTransportServer("localhost")

else

159
 Set Server = Manager.GetWdsTransportServer(WScript.Arguments.Item(0))

end if

' Print Server name

wscript.echo "Server: " + Server.name

' Get a list of the namespaces on the server

Set NamespaceCollection = Server.NamespaceManager.RetrieveNamespaces("", "", False)

' Get all namespaces present on the server

for i = 1 to CLng(NamespaceCollection.count)

Set ns = NamespaceCollection.Item(i)

wscript.echo " Namespace ID: " + CStr(ns.id) + ", Name: " + ns.name

' Get all contents for this namespace

Set ContentCollection = NamespaceCollection.Item(i).RetrieveContents()

for j = 1 to CLng(ContentCollection.count)

Set content = ContentCollection.item(j)

wscript.echo " Content ID : " + CStr(content.id) + ", Name: " +

content.name

' Get all sessions for this content

Set SessionCollection = content.RetrieveSessions()

for k = 1 to CLng(SessionCollection.count)

Set session = SessionCollection.item(k)

tRate = CLng(session.TransferRate)

tRate = Int(tRate / 1024)

' Get all clients for this session

Set ClientCollection = session.RetrieveClients()

wscript.echo " Session ID: " + CStr(session.id) + ",

NIC Name: " + session.NetworkInterfaceName &_

160
 + ", tRate: " + CStr(tRate) + " kB/sec, clients: " +
Cstr(ClientCollection.count)

for l = 1 to Cint(ClientCollection.count)

set client = ClientCollection.item(l)

' Determine if this client is the master client

if Clng(session.MasterClientId) = Clng(client.id)
then

wscript.echo " * Client ID: " +

CStr(client.id) + ", Name: " + client.name &_

+ ", IP: " + client.IpAddress + ", MAC:

" + client.MacAddress + ", Time connected: " + Cstr(client.JoinDuration)

else

wscript.echo " Client ID: " +

CStr(client.id) + ", Name: " + client.name &_

+ ", IP: " + client.IpAddress + ", MAC:

" + client.MacAddress + ", Time connected: " + Cstr(client.JoinDuration)

end if

next

next

next

next

The following code is example output from the preceding script:

C:\Users\administrator>cscript MCInfo.vbs localhost

Microsoft (R) Windows Script Host Version 5.7

Copyright (C) Microsoft Corporation. All rights reserved.

Server: wds-server.fabrikam.com

Namespace ID: 2471217798, Name: WDS:Server08/install-(2).wim/1

Namespace ID: 2471217799, Name: WDS:Server08/install.wim/1

Namespace ID: 2471217807, Name: WDS:Server03/amd64.wim/1

Namespace ID: 2471217808, Name: WDS:Server03/x86.wim/1

Namespace ID: 2471217810, Name: WDS:Vista/amd64.wim/1

Namespace ID: 2471217811, Name: WDS:Vista/x86.wim/1

161
 Namespace ID: 2471217812, Name: WDS:XP_SP2/install-(2).wim/1

Content ID : 3263057331, Name: Res.rwm

Session ID: 3353296855, NIC Name: Broadcom NetXtreme Gigabit Ethernet #2, tRate: 0
kB/sec, clients: 0

Namespace ID: 2471217813, Name: WDS:XP_SP2/Install.wim/1

Content ID : 3263057330, Name: Res.rwm

Session ID: 3353296854, NIC Name: Broadcom NetXtreme Gigabit Ethernet #2, tRate:
883 kB/sec, clients: 1

* Client ID: 3267943420, Name: MININT-1U7QOTT, IP: 172.30.170.162, MAC:

000E7F28D375, Time connected: 1111

How to Modify the BCD Store Using Bcdedit

You can use the Boot Configuration Data Editor (Bcdedit.exe) to view and modify the contents of
the Boot Configuration Data (BCD) store. Bcdedit.exe is available on computers running Windows
Vista and Windows Server 2008. For more information, see "Boot Configuration Data Editor
Frequently Asked Questions" (http://go.microsoft.com/fwlink/?LinkId=112156).

In This Topic
• To View the Contents of the BCD Store
• To Configure the Default Selection Time-out Value
• To Configure a Localized Boot Manager Experience
• To Configure the TFTP Block Size
• To Configure the TFTP Window Size
• To Configure Windows Debugger Options
• To Turn On Emergency Management Services Settings

To View the Contents of the BCD Store

To view the contents of this store, run the following command at the command prompt:
Syntax: bcdedit /enum all /store <path to BCD store>
Example: C:\boot>bcdedit.exe /enum all /store c:\remoteinstall\tmp\X86.{05FF3388-7D71-
46A1-AE8A704480979281}.bcd

162
To Configure the Default Selection Time-out Value
The default selection time-out value is set to 30 seconds. You can configure this value by setting
the appropriate option in the Default.bcd store for your client’s architecture, using the following
steps:
1. View the existing configuration settings in the Default.bcd store by running the following
command:
Syntax: bcdedit /enum all /store <full path and file name of store>
Example:
C:\>bcdedit /enum all /store c:\RemoteInstall\Boot\x86\default.bcd

Windows Boot Manager

--------------------

identifier {bootmgr}

inherit {dbgsettings}

timeout 30

Real-mode Application (10400009)

--------------------------------

identifier {40fe5c41-285e-412b-b4cd-0ce498e470a2}

device boot

path OSChooser\i386\startrom.n12

description Remote Installation Services

pxesoftreboot Yes

Debugger Settings

-----------------

identifier {dbgsettings}

debugtype Serial

debugport 1

baudrate 115200

Device options

--------------

identifier {68d9e51c-a129-4ee1-9725-2ab00a957daf}

ramdisksdidevice boot

ramdisksdipath \Boot\Boot.SDI

163
 2. Set the appropriate time-out value by running the following command:
Syntax: bcdedit /store <full path and file name of store> /set {bootmgr} timeout <value in
seconds>
Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set {bootmgr}
timeout 10
3. Force regeneration of the BCD store in the \Tmp folder by sending a control signal to the
WDSServer service, using the following command:
C:\>sc control wdsserver 129

To Configure a Localized Boot Manager

Experience
To configure the Boot Manager application to allow for a localized setup experience, perform the
following steps:
1. View the existing settings in the default BCD store by running the following command:
Syntax: bcdedit /enum all /store <full path and file name of store>
Example:
C:\>bcdedit /enum all /store c:\RemoteInstall\Boot\x86\default.bcd

Windows Boot Manager

--------------------

identifier {bootmgr}

inherit {dbgsettings}

timeout 30

Real-mode Application (10400009)

--------------------------------

identifier {40fe5c41-285e-412b-b4cd-0ce498e470a2}

device boot

path OSChooser\i386\startrom.n12

description Remote Installation Services

pxesoftreboot Yes

Debugger Settings

-----------------

identifier {dbgsettings}

164
debugtype Serial

debugport 1

baudrate 115200

Device options

--------------

identifier {68d9e51c-a129-4ee1-9725-2ab00a957daf}

ramdisksdidevice boot

ramdisksdipath \Boot\Boot.SDI

2. Set the appropriate locale value by running the following command:

Syntax: bcdedit /store <full path and file name of store> /set {bootmgr} locale <lang>
Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set {bootmgr} locale
en-US
3. Set the application path by running the following command:
Syntax: bcdedit /store <full path and file name of store> /set {bootmgr} path <relative path to
bootmgr.exe>
Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set {bootmgr}
path \boot\<arch>\bootmgr.exe
4. Force regeneration of the BCD store in the \Tmp folder by sending a control signal to the
server service by specifying, using the following command:
C:\>sc control wdsserver 129

To Configure the TFTP Block Size

The default TFTP block size value is 1432 bytes. You can configure this value by setting the
appropriate value in the default BCD store for the client architecture, using the following steps:
1. Determine the GUID identifier of the boot manager application by running the following
command:
Syntax: bcdedit /enum all /store <full path and file name of store>
Example:
C:\>bcdedit /enum all /store c:\RemoteInstall\Boot\x86\default.bcd

Windows Boot Manager

--------------------

identifier {bootmgr}

inherit {dbgsettings}

timeout 30

165
Real-mode Application (10400009)

--------------------------------

identifier {40fe5c41-285e-412b-b4cd-0ce498e470a2}

device boot

path OSChooser\i386\startrom.n12

description Remote Installation Services

pxesoftreboot Yes

Debugger Settings

-----------------

identifier {dbgsettings}

debugtype Serial

debugport 1

baudrate 115200

Device options

--------------

identifier {68d9e51c-a129-4ee1-9725-2ab00a957daf}

ramdisksdidevice boot

ramdisksdipath \Boot\Boot.SDI

2. Set the appropriate TFTP block size value by running the following command:
Syntax: bcdedit /store <full path and file name of store> /set {<GUID identifier>}
ramdisktftpblocksize <block size>
Example: C:\>bcdedit /store c:\RemoteInstall\boot\x86\default.bcd /set {68d9e51c-a129-
4ee1-9725-2ab00a957daf} ramdisktftpblocksize 4096

Note
We recommend that you go up in multiples (4096, 8192, 16384, and so on) and that
you not set a value higher than 16384.
3. Force regeneration of the BCD store in the \Tmp folder by sending a control signal to the
WDSServer service, using the following command:
C:\>sc control wdsserver 129

To Configure the TFTP Window Size

The default TFTP window size is 8. You can configure this value by setting the appropriate value
in the default BCD store for the client architecture, using the following steps:
166
 1. At the command prompt, determine the GUID identifier of the boot manager application
by running the following command:
Syntax: bcdedit /enum all /store <full path and file name of store>
2. Set the appropriate TFTP window size by running the following command:
Syntax: bcdedit /store <full path and file name of store> {<GUID>} ramdisktftpwindowsize
<windowsize>
Example: C:\>bcdedit /store c:\RemoteInstall\boot\x86\default.bcd {68d9e51c-a129-
4ee1-9725-2ab00a957daf} ramdisktftpwindowsize 9
3. Force regeneration of the BCD store in the \Tmp folder by sending a control signal to the
WDSServer service by running the following command:
C:\>sc control wdsserver 129

To Configure Windows Debugger Options

There are three debugging options that you can add by using BCDedit.exe. These options are
described in the following table.

Option Description

/bootdebug Enables or disables boot debugging for a boot

application.

/dbgsettings Sets the global debugger parameters.

/debug Enables or disables kernel debugging for an

operating system entry.

To turn on debugging for boot manager

1. View the existing settings in the Default.bcd store by running the following command:
Syntax: bcdedit /enum all /store <full path and file name of store>
Example:
C:\>bcdedit /enum all /store c:\RemoteInstall\Boot\x86\default.bcd

Windows Boot Manager

--------------------

identifier {bootmgr}

inherit {dbgsettings}

timeout 30

Real-mode Application (10400009)

167
 --------------------------------

identifier {40fe5c41-285e-412b-b4cd-0ce498e470a2}

device boot

path OSChooser\i386\startrom.n12

description Remote Installation Services

pxesoftreboot Yes

Debugger Settings

-----------------

identifier {dbgsettings}

debugtype Serial

debugport 1

baudrate 115200

Device options

--------------

identifier {68d9e51c-a129-4ee1-9725-2ab00a957daf}

ramdisksdidevice boot

ramdisksdipath \Boot\Boot.SDI

2. Set the appropriate debugging values by running the following command:

Syntax: bcdedit /store <full path and file name of store> /set {bootmgr} bootdebug
<value>
Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set {bootmgr}
bootdebug on
3. Force the regeneration of the BCD store in the \Tmp folder by sending a control
signal to the server service, using the following command:
C:\>sc control wdsserver 129

To turn on debugging for a particular operating system entry (for OSLoader)

1. Determine the GUID of the operating system entry by running the following
command:
Syntax: bcdedit /store <full path and file name of per-image BCD store> /enum all
Example:
C:\>bcdedit /store c:\RemoteInstall\Boot\x86\Images\boot.wim.bcd /enum all

Windows Boot Loader

168
 -------------------

identifier {06689f95-f69c-4937-8ded-09a966a6a319}

device ramdisk=[boot]\Boot\x86\Images\boot.wim,{68d9e51c-a129-4ee1-
9725-2ab00a957da

f}

description WinPE 5600 RC1

osdevice ramdisk=[boot]\Boot\x86\Images\boot.wim,{68d9e51c-a129-4ee1-
9725-2ab00a957da

f}

systemroot \WINDOWS

detecthal Yes

winpe Yes

2. Enable debugging options by running the following command:

Syntax: bcdedit /store <full path and file name of per-image BCD store> /set <GUID
identifier> debug <value>
Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set {06689f95-
f69c-4937-8ded-09a966a6a319} debug on
3. Enable the inheritance of the debug options that are in Default.bcd so that they apply
to the operating system entry, using the following command:
Syntax: bcdedit /store <full path and file name of per-image BCD store> /set <GUID
identifier> inherit {dbgsettings}
Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set {06689f95-
f69c-4937-8ded-09a966a6a319} inherit {dbgsettings}
4. Force regeneration of the BCD store in the \Tmp folder by sending a control signal to
the server service, using the following command:
C:\>sc control wdsserver 129

To Turn On Emergency Management Services

Settings
For servers equipped with the proper firmware, Emergency Management Services (EMS)
provides functionality that you can use to administer a server remotely. This is useful for
computers that do not support direct video output or do not have a keyboard and mouse
attached. Except for hardware maintenance and replacement, all administrative functions that you
can accomplish locally should be available remotely. This includes starting your system and
performing system-recovery tasks. This method is typically used for high-end servers in a data
center.
There are generally two types of devices that support remote administration: those whose BIOS
and Extensible Firmware Interface (EFI) support UI redirection, and those whose BIOS does not

169
support UI redirection. The first class of computers is generally EFI-based, typically Itanium-
based servers. The second class of computers have had the video card removed (or the
computer did not come with one), and the goal is to redirect output by using a COM port.
Support for remote administration is enabled by default for Itanium-based computers that are
using configuration settings specified in the default BCD store that was created for Itanium-based
clients. These EMS settings are enabled and set to use the BIOS default settings (as opposed to
COM port redirection). Each per-image BCD store that is generated for Itanium-based clients is
set to inherit these settings from the default BCD configuration.
Support for remote administration is not enabled by default for x86-based or x64-based
computers that do not support BIOS redirection. To enable this support, you must do the
following:
• Adjust the default NBP to one that supports remote administration (for example,
hdlscom1.com, hdlscom1.n12, hdlscom2.com, or hdlscom2.n12). For more information about
boot programs and their use, see the "Network Boot Program" section in Managing Network
Boot Programs.
• Signal the loader to support remote administration. You can do this by using
BCDedit.exe to set the appropriate EMS options in the default BCD store used for that
architecture. You must enable EMS settings and, optionally, you can specify the default port
and baud rate.

To turn on EMS settings for a particular operating system entry (for OSLoader)
1. Determine the GUID of the operating system entry by running the following
command:
Syntax: BCDEDIT /store <full path and file name of per-image BCD store> /enum all
Example:
C:\>bcdedit /store c:\RemoteInstall\Boot\x86\Images\boot.wim.bcd /enum all

Windows Boot Loader

-------------------

identifier {06689f95-f69c-4937-8ded-09a966a6a319}

device ramdisk=[boot]\Boot\x86\Images\boot.wim,{68d9e51c-a129-4ee1-
9725-2ab00a957da

f}

description WinPE 5600 RC1

osdevice ramdisk=[boot]\Boot\x86\Images\boot.wim,{68d9e51c-a129-4ee1-
9725-2ab00a957da

f}

systemroot \WINDOWS

detecthal Yes

170
winpe Yes

2. Create the EMS settings option in the Default.bcd store by running the following
command:
Syntax: bcdedit /store <full path and file name of per-image BCD store> /create
{emssettings} /d <description>
Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /create
{emssettings} /d "EMS Settings”
3. Set the baud rate by running the following command:
Syntax: bcdedit /store <full path and file name of per-image BCD store> /set
{emssettings} baudrate <value>
Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set
{emssettings} baudrate 115200
4. Set the output port type by running the following command:
Syntax: bcdedit /store <full path and file name of per-image BCD store> /set
{emssettings} debugtype <value>
Example:C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set
{emssettings} debugtype Serial
5. Set the output port number (this should match the output port of the configured
network boot program (NBP)) by running the following command:
Syntax: bcdedit /store <full path and file name of per-image BCD store> /set
{emssettings} debugport <value>
Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set
{emssettings} debugport 1
6. Determine the GUID of the operating system entry by running the following
command:
Syntax: bcdedit /store <full path and file name of per-image BCD store> /enum all
Example:
C:\>bcdedit /store c:\RemoteInstall\Boot\x86\Images\boot.wim.bcd /enum all

Windows Boot Loader

-------------------

identifier {06689f95-f69c-4937-8ded-09a966a6a319}

device ramdisk=[boot]\Boot\x86\Images\boot.wim,{68d9e51c-a129-4ee1-
9725-2ab00a957da

f}

description WinPE 5600 RC1

osdevice ramdisk=[boot]\Boot\x86\Images\boot.wim,{68d9e51c-a129-4ee1-
9725-2ab00a957da

171
 f}

systemroot \WINDOWS

detecthal Yes

winpe Yes

7. Enable EMS settings in the per-image BCD by running the following command:
Syntax: bcdedit /store <full path and file name of the per-image BCD store> /set <GUID
identifier> ems <value>
Example:C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set {06689f95-
f69c-4937-8ded-09a966a6a319} ems on
8. Enable inheritance of EMS settings from Default.bcd values as configured above, by
running the following command:
Syntax: bcdedit /store <full path and file name of per-image BCD store> /set <GUID
identifier> inherit {emssettings}
Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set {06689f95-
f69c-4937-8ded-09a966a6a319} inherit {emssettings}
9. Force regeneration of the BCD store in the \Tmp folder by sending a control signal to
the server service, using the following command:
C:\>sc control wdsserver 129

Troubleshooting
• Analyzing Performance Problems
• Common Problems
• Logging and Tracing
• Network Ports Used
• Required Permissions

Analyzing Performance Problems

This topic contains information about analyzing blockages during each phase of an image
installation. For more information, see Optimizing Performance.

In This Topic
• Analyzing Blockages in Each Phase of Installation
• PXE Boot Phase

172
 • TFTP Download Phase
• Image Apply Phase
• Using Performance Monitoring

Analyzing Blockages in Each Phase of Installation

PXE Boot Phase
The Pre-Boot Execution Environment (PXE) boot phase encompasses the initial boot performed
by the client computer. This includes obtaining an IP address lease, locating a valid Windows
Deployment Services server, and downloading a network boot program (NBP) by using Trivial File
Transfer Protocol (TFTP). The amount of data transferred over the network during this phase is
minimal, and the end-to-end operation typically succeeds in a matter of seconds.
Given the speed at which operations in this phase are completed, you have a few options when it
comes to performance tuning. The Windows Deployment Services PXE server can handle
several hundred requests per second in sustained throughput. Slight performance decreases can
occur if the domain controller is located across a latent network link or is overloaded. In larger
environments, consider locating Dynamic Host Configuration Protocol (DHCP) and Windows
Deployment Services roles on separate physical computers.

TFTP Download Phase

The TFTP download phase of the installation process is when the boot image is downloaded to
the client computer. Performance in this phase is tied directly to the following factors (in order of
importance):
• Latency between the client computer and the server (measured by the average response
time between the server and the client)
• Size of the boot image

Note
Increasing boot image size will cause the TFTP download times to increase and will
reduce reliability. Typically, the longer it takes to download the boot image, the more
likely it is that something could go wrong.
• TFTP block size
• Other network conditions (such as workload, the quality of the physical equipment that is
installed, and electromagnetic noise considerations)

Diagnosing TFTP Download Performance Problems

The simplest way to diagnose long download times (observed from the client computer as a
progress bar below an IP address) is to look at the average response time between the client and
the server it is downloading from. To do this, in Windows PE, open the Command Prompt window,

173
type ping [server’s IP address], and then note the average latency measured. The output will
look similar to the following, where the average latency is less than 1 millisecond (which is good):
C:\Windows\system32>ping 10.197.160.93

Pinging 10.197.160.93 with 32 bytes of data:

Reply from 10.197.160.93: bytes=32 time=2ms TTL=60

Reply from 10.197.160.93: bytes=32 time<1ms TTL=60

Reply from 10.197.160.93: bytes=32 time<1ms TTL=60

Reply from 10.197.160.93: bytes=32 time<1ms TTL=60

Ping statistics for 10.197.160.93:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 2ms, Average = 0ms

High round-trip time values indicate latency on the network, which is an indicator that TFTP
download performance will be poor. To improve this performance, consider doing one or more of
the following:
• Use a Windows Deployment Services server that is closer to each client.
• Remove stress and load from the network segment.
• If the client connects to the server after multiple network hops, use the output from the
tracert command to identify the latent segment, and consider rerouting TFTP traffic to avoid
that hop.
You can also diagnose TFTP download performance problems by examining a network trace of
the download activity. Generally, the best practice is to obtain this trace from the client and server
simultaneously to assess exactly where the blockage is occurring (server, client, or network). To
do this, add a client and a third computer to a hub, start network traces from the server and the
third computer, and then boot the client computer from the network.

Addressing TFTP Download Performance Problems

In the preceding example, the average latency is less than 1 millisecond, which is good. If the
average latency between the client and the server is longer than 5 milliseconds, TFTP
performance will be seriously degraded. For example, if it takes X seconds to download the boot
image when the average latency is 1 millisecond, it will take approximately two seconds to
download the image when the average latency is 2 milliseconds, and approximately eight
seconds to download it when the average latency is 4 milliseconds.
You may be able to decrease the impact of latency on TFTP download times by increasing the
TFTP block size. This means that more data will be sent each time, which cuts down on the
number of round-trips. For instructions, see How to Modify the BCD Store Using Bcdedit.
Reducing the size of the boot image can also speed up TFTP downloads. To accomplish this, do
the following:

174
 • Use the tools in the Windows Automated Installation Kit (AIK) to create a custom boot
image that contains the Windows Setup binary files and Microsoft Windows Preinstallation
Environment (Windows PE), which has been prepared by using PEIMG.exe /prep.
• Ensure that the Windows image (.wim) file that contains the boot image does not contain
extra space. A best practice is to use the ImageX /export command to export your boot
image to a "clean" .wim file before adding the image to the Windows Deployment Services
server.
• Ensure that the .wim file that contains the boot image is using the maximum compression
format, LZX. To do this, run Imagex /info ImageFile [ImageNumber|ImageName].
In situations where a server is overburdened, consider using PXE boot referrals to direct booting
clients to different PXE servers for TFTP downloads. For more information, see Managing
Network Boot Programs and the Windows AIK documentation (http://go.microsoft.com/fwlink/?
LinkId=96016). Lastly, consider altering your physical network topology by using one or more of
the following steps:
• Add a PXE server closer to the client computer.
• Move the client computer closer to the PXE server.
• Repair the existing network infrastructure (in the case of high-packet loss).
• Upgrade to better cabling (Cat 5e is recommended).
• Check the condition of the switches between the client computer and the PXE server to
ensure that packets are not being dropped.

Image Apply Phase

The image apply phase of the installation process involves transferring an install image from the
Windows Deployment Services server to the client. This transfer occurs through either Server
Message Block (SMB) or multicasting and is the most time-consuming part of the installation
process.

Diagnosing Performance Problems in the Image Apply Phase

To begin, test several client computers on your network, and compare the performance with the
test results outlined in the "Performance and Scalability Expectations" section in Optimizing
Performance. You can also enable logging to gather information. For more information, see the
"Windows Deployment Services Client Logs" section in Logging and Tracing. If there are
substantial variances between the expected results and your results, you probably have a
performance blockage. To troubleshoot common blockages, ask yourself the following questions:
• Do performance problems occur only at certain times of the day? This may indicate
a scalability problem that is probably caused by an overused network or an overburdened
server.
• Do performance problems occur only for clients on a particular subnet or network
location? If so, determine whether there is a network issue on that segment.

175
 • Do performance problems occur only for clients that access a particular server? If
so, check the server’s performance statistics as well as the network segment that connects
the clients to the server to see whether the server is overused.
Performance problems that occur across a larger group of computers generally indicate either a
concurrency problem (scalability) or a blockage in the network or server. To investigate, measure
the amount of time it takes to download a file (of approximately the same size as the install
image) from the server to the client, in Windows PE. Or try to download the install image after it
has been placed in a shared folder on the server. If the time it takes to download a large file
exceeds the expectations, you should analyze the switch utilization and observe other network
metrics to identify the network conditions that are impacting download times.
If you suspect that the server is the blockage, use the steps in the Using Performance Monitoring
section later in this chapter to identify the root cause of the blockage.

Addressing Performance Problems in the Image Apply Phase

Performance problems in this phase are generally caused by network congestion, or inadequate
resources on the server or client. If network congestion is the issue, consider doing the following:
• Creating more bandwidth on the network. This may mean upgrading your network
infrastructure to support greater bandwidth and higher throughput. For example, it might
mean moving from 100 MB to 1 GB, upgrading cabling, replacing hubs with routers or
switches, or reducing the number of clients that can access a particular network segment
simultaneously.
• Adding additional Windows Deployment Services servers to the network to handle
the network demand. This means segmenting network infrastructure so that smaller groups
of clients are answered by each server.
• Balancing the server load by adding dedicated image servers. For more information,
see Storing and Replicating Images Using DFS.
• Reducing image size. Because larger images mean longer installation times and greater
network strain, you should consider creating images that contain minimum customization,
drivers, and applications; or consider creating specialized images for each department,
hardware type, or function. For more information, see the "Reducing the Size of Images"
section in the Servicing Images topic.
Most Windows Deployment Services server blockages occur because of inadequate bandwidth
(at the network adapter), slow disk subsystems, or insufficient available physical memory. To
identify the source of the blockage, use the information in the next section, Using Performance
Monitoring. Typical causes of performance problems on individual client computers include the
following:
• Problems with the physical network connection between the client computer and the
network topology
• Problems with the switching equipment
• A bad disk controller interface on the client computer
• A bad network adapter on the client computer

176
 • Insufficient RAM on the client computer (512 MB of RAM is the minimum requirement for
Windows Vista)
• Poorly performing system drivers

Using Performance Monitoring

You can use Windows Reliability and Performance Monitor to diagnose performance problems
with Windows Deployment Services. Note, however, that this is not a complete solution. Because
most performance and scalability issues in Windows Deployment Services are network related,
network analysis tools may be of greater use. Nevertheless, Windows Reliability and
Performance Monitor can be a powerful and quick tool for identifying resource issues on services
associated with Windows Deployment Services.
The following are the most useful counters for diagnosing Windows Deployment Services
performance. To open Reliability and Performance Monitor, click Start, type Performance in the
Start Search box, and then press ENTER. To add these counters, expand Monitoring Tools ,
click Performance Monitor, and then click the green plus sign (+) in the right pane. In Available
Counters, scroll to the counter you want to add, and then click Add. Review the following
information to maximize your server's performance.
• Network Interface (Bytes Sent/sec)
• PhysicalDisk (Avg. Disk sec/Read, Avg. Disk sec/Write, and Current Disk Queue
Length ). These disk counters highlight the current disk activity. The Avg. Disk sec/Read and
the Avg. Disk sec/Write counter should generally take less than 10 milliseconds, and the
maximum should not exceed 50 milliseconds. Anything outside these thresholds indicates
that there is too little available disk space to respond to the demands that are being placed on
the server. The Current Disk Queue Length counter indicates the backlog of pending
input/output (I/O) requests. As you might expect, you do not want to see much here, if
anything.
• Process (Page Faults/sec). Page faults occur when there is not enough physical memory
on the server to meet the server's demands. When this occurs, the server has to copy
memory from the physical RAM to a swap file on the hard disk drive, and then make room to
enable the requested memory allocation to complete. This is a very expensive operation
because this swap requires a series of reads and writes on the hard disk drive, and this
process must be completed before the operation that caused the fault can resume. On
servers where there is not enough memory, page faults can occur frequently, which
significantly reduces the amount of processor time that is available to complete any other
operations. If there are significant time periods with a lot of page fault activity, you should
consider adding memory to the server.
• Processor (% Processor Time). You can tell from the % Processor Time counter whether
there is enough processing power on the server to meet the demands being placed on it. If
you see that processor utilization is high, use this counter for each individual process to
determine the cause of the degraded performance. If the Windows Deployment Services
server is configured to work with File Replication Service (FRS), and the Distributed File
System Replication (DFSR) service is consuming a significant portion of processor time, you

177
should consider increasing the boot configuration data (BCD) refresh interval to reduce the
number of changes that FRS has to propagate between servers. If the server has multiple
server roles, you may want to configure the roles so that they are better distributed across
multiple servers.
A strong correlation between network utilization and disk reads (and disk throughput)
indicates that the network card may be the cause of a reduction in image deployment times.
In this case, if you are not concerned with disk throughput, consider upgrading the network
infrastructure to support GB Ethernet, or refactoring the Windows Deployment Services
server infrastructure so that it is spread across multiple servers.
• WDS Multicast Server (all counters). The following list describes all of counters for
multicasting.
• Active Clients. This counter shows the clients that are currently connected to a
multicast session.
• Active Contents. Contents refers to the data that is being transmitted. When a client
connects to a namespace, a “content” is created. The content is then removed if clients
are not active in the content for 5 minutes or longer. You can have multiple contents for a
single namespace if there are multiple network cards on the server.
• Active Namespaces. This counter is essentially equivalent to a multicast
transmission. A namespace is the underlying object that gets created when you create a
multicast transmission.
• Incoming Packets/Second (in Bytes). This counter shows the sum of all incoming
data packets (per second) from all multicast sessions.
• Outgoing Packets/Second (in Bytes): This counter shows the sum of all outgoing data
packets (per second) from all multicast sessions.
• Total Data Packets. This counter shows the total number of data packets sent by the
multicast server.
• Total Master Client Switches. This counter shows the total number of times that the
master client has been changed in a transmission. Note that the master client is the
slowest client in a transmission — that is, the client that is not capable of installing any
faster, whereas the other clients may be able to install at a faster rate.
• Total NACK Packets. A NACK packet is a negative acknowledgement. This counter
shows the total number of NACK packets received from client computers.
• Total Repair Packets. This counter shows the total number of repair packets sent by
the server. Note that the server sends repair packets in response to NACK packets. If the
number in this counter is high, relative to the Total Data Packets counter, this indicates
that packet loss is occurring between the clients and the server. Ideally, the ratio of total
data packets to total repair packets should be greater than 100:1.
• Total Slowdown Request. Clients send slowdown requests when the server is
sending data faster than the client can handle it. This is usually caused by slow disk
performance on the clients, or by other resource pressure (such as insufficient memory,
high CPU utilization, and so on).

178
 • WDS TFTP Server (all counters). The following list describes the two counters for TFTP.
• Active Requests. This counter shows the number of active TFTP transfers on the
server.
• Transfer Rate/Second (in Bytes). This counter shows the total amount of data that the
TFTP server is sending out per second.
• WDS Server (all counters). The following list describes the counters for the Windows
Deployment Services server.
• Active Requests. This counter shows the number of currently active requests on the
Windows Deployment Services server, including remote procedure calls (RPCs) to the
server and multicast requests.
• Processed/Second. This counter shows the number of requests processed in the last
second.
• Requests/Second. This counter shows the number of requests received in the last
second.
For more information about Reliability and Performance Monitor, see
http://go.microsoft.com/fwlink/?LinkID=110854.
For information about how to view these counters, see the following Microsoft TechNet articles:
• Add Counters Dialog Box (http://go.microsoft.com/fwlink/?LinkId=105531)
• Creating Data Collector Sets (http://go.microsoft.com/fwlink/?LinkID=55157)

Common Problems
This chapter highlights some common issues that you may encounter when using Windows
Deployment Services including the following:

Type Issues

Performing PXE Boots on Client Computers • I am unable to perform PXE boots on

client computers.
• When I perform a PXE boot and select
a boot image, I see a command prompt.
• The client computer fails to get an IP
address when I try to boot into PXE.
• The client computer obtains an IP
address but then fails to download a boot
program.
• I don't see the hard drive of the client
computer on the disk configuration page of
Setup.
• My computer loads the boot image, but

179
Type Issues

it cannot access an install image.

• I created an unattend file, but when
installation completes, my client computer is
not joined to the domain.
• Install images do not appear on the
image selection page.

Troubleshooting x64-Based Client Computers • My x64-based client computer does not

have any x64-based images on the boot
image selection page.
• My x64-based client computer is
detected as x64, but it fails to boot to the
default image.

Performing Management Operations • I can't approve a pending computer.

• I approved a pending computer and
then deleted the computer account that was
created in AD DS during the process. Now
the server will not answer my client
computer.
• I received the error: "0x2: File not
found" when trying to use the management
tools to manage a remote Windows
Deployment Services server.

Creating Custom Images • When using the Image Capture Wizard

to create a custom image, the volume that
contains my image is not selectable.
• The finish button is not enabled on the
final page of the image capture wizard.
• The capture started successfully, but
then I got a metadata error.

Multicasting • My multicast transmissions are running

very slowly.
• After enabling multicasting, there is
excessive traffic on the network.

180
Performing PXE Boots on Client Computers
I am unable to perform PXE boots on client computers.
The most common causes for this issue are:
• The Windows Deployment Services server services have not been started. To fix this, run
WDSUTIL /start-server to start all services. Examine the output of the command and the
Windows Application event log for error messages indicating service start-up failures.
• The necessary firewall ports are not open on the server. Ensure that the proper ports are
open to enable the client to connect to the Windows Deployment Services server. For more
information, see Network Ports Used .
• The answer policy is not configured correctly. For example, the server is not configured to
answer clients, or it is configured to answer only known clients and the client is not prestaged.
To fix this, reconfigure the policy. For example, run WDSUTIL /set-server
/answerRequests:all. For instructions, How to Manage Client Computers.
• The computer is marked as approved in the Auto-Add database, but a computer account
representing the computer does not exist in Active Directory Domain Services (AD DS). To fix
this, see the very end of Prestaging Client Computers.
• The computer is marked as rejected in the Auto-Add database. After a computer has
been marked as rejected, the computer will not be able to PXE boot. You can clear the entry
in the Auto-Add database by deleting all pending computer records (by running WDSUTIL
/delete-AutoAddDevices /DeviceType:RejectedDevices) or enabling the record to be
purged automatically (according to the default cleanup interval). For instructions, see the
Auto-Add Database section of How to Manage Client Computers.
• Client boot requests are not getting routed correctly to the Windows Deployment Services
server. To ensure that the IP Helper router is updated and that the Dynamic Host Control
Protocol (DHCP) option configuration has been completed correctly, see "Methods of
Directing a Client to the Appropriate NBP" in Managing Network Boot Programs.
• A boot image has not been added to the server. Use the management tools to add the
Boot.wim from the Windows Server 2008 media to the server. For instructions, see the Step-
by-Step Guide for Windows Deployment Services in Windows Server 2008.
• The client has been prestaged and a network boot program (NBP) has been defined;
however, the NBP does not exist on the server. Examine the output from WDSUTIL /get-
device /Device:<device name> to determine the name and path of the NBP. Then check
that location on the Windows Deployment Services server to ensure that the file exists. If it
does not exist, run WDSUTIL /Set-device to direct the client to a different NBP.
• DHCP and Windows Deployment Services are running on the same physical computer,
but the settings associated with this configuration have not been defined. To configure this,
see the DHCP section of How to Manage Your Server. For more information, see Managing
DHCP.

181
When I perform a PXE boot and select a boot image, I see a command
prompt.
If you do not see the wizard when you boot into a boot image, the boot image probably does not
contain the Windows Deployment Services client (which is basically Setup.exe and supporting
files for Windows Deployment Services). One common cause of this is if you created an image of
Windows PE by using the Windows AIK instead of using the Boot.wim file from the Windows Vista
or Windows Server 2008 DVDs. To fix this, upload the Boot.wim file located in the Sources
directory of Windows Server 2008 DVD. This image contains the Windows Deployment Services
client and Windows PE.

The client computer fails to get an IP address when I try to boot into PXE.
The most common causes of this problem are:
• There is a problem with the network.
• There is a problem with DHCP.
To resolve these issues, check Event Viewer for events and errors, and then refer to the DHCP
Infrastructure troubleshooting documentation (http://go.microsoft.com/fwlink/?LinkId=108014) for
steps you can use to resolve the problem. If you are using a non-Microsoft DHCP server, contact
the manufacturer for troubleshooting information.

The client computer obtains an IP address but then fails to download a

NBP.
You may have a problem with the network or the configuration of the Windows Deployment
Services server. A common cause is if a client is on a different subnet from the Windows
Deployment Services server and you have not configured the server to get the PXE signal
through the router. To fix this, see the "Updating the IP Helper Tables" section in Managing
Network Boot Programs.

I don't see the hard drive of the client computer on the disk configuration
page of Setup.
The most common cause of this problem is that the client computer does not have the correct
storage driver from the hardware manufacturer. To fix this, do one of the following:
• Add the driver to the image by using the tools in the Windows AIK. For general
instructions, see "Modify a Boot or Install Image" (http://go.microsoft.com/fwlink/?
LinkId=108013).To download the Windows AIK, see (http://go.microsoft.com/fwlink/?
LinkID=54863).
• Click Add Driver on the disk configuration page, and then specify the driver.

My computer loads the boot image, but it cannot access an install image.
The boot image may not contain the correct network driver for the client computer. To resolve this,
on the client computer, press SHIFT+F10 to open a command prompt and run IPConfig. If an IP
address and subnet mask are not reported in the output, this indicates that networking has not

182
been started and it is likely that a network driver is not present. To fix this, add the driver from the
hardware manufacturer to the image by using the tools in the Windows AIK. For general
instructions, see "Modify a Boot or Install Image" (http://go.microsoft.com/fwlink/?
LinkId=108013).To download the Windows AIK, see http://go.microsoft.com/fwlink/?
LinkID=54863.

I created an unattend file, but when installation completes, my client

computer is not joined to the domain.
There are two common causes for this issue:
• The image unattend file is not formatted properly. To verify that your file is correctly
formatted, see Automating the Domain Join and Computer Naming and Sample Unattend
Files.
• The client computer does not have permissions to join a domain. To resolve this, check
for an error in \Windows\panther\setupact.log under domainjoininformation, and grant the
appropriate permissions. For more information, see Required Permissions.

Install images do not appear on the image selection page.

The most common causes of this problem are:
• The account whose credentials were entered on the credential screen of Windows
Deployment Services client does not have permissions to read the install .wim file. These
images are located at \\<WDSServer>\RemoteInstall\Images\<Image Group>. For more
information, see Required Permissions.
• The architecture of the client computer (x86, Itanium, x64) does not match the
architecture type of the install image. For example, a client booting into an x86-based boot
image will only be able to view x86-based install images on the image selection page.
• You may have an incompatible hardware abstraction layer (HAL) type. To deploy an
image to this computer, you will need an image that has the correct HAL type — that is, an
image that was captured from a computer that has the same HAL type as this computer.

Troubleshooting x64-Based Client Computers

My x64-based client computer does not have any x64-based images on the
boot image selection page.
Many x64-based system BIOS do not accurately identify the computer as x64 during the boot
process. If Windows Deployment Services does not recognize the computer as x64, only x86
images will be shown. Run WDSUTIL /set-server /architecturediscovery:yes to force the
Windows Deployment Services server to recognize x64 computers.

183
My x64-based client computer is detected as x64, but it fails to boot to the
default image.
If an x64-based computer performs a PXE boot but does not find an x64-based image, it will be
unable to complete the boot process. Ensure that your Windows Deployment Services server has
the x64-based version of Boot.wim. Alternatively, you can force all x64 clients to only receive x86
boot files by configuring the default boot program—for example, configure Pxeboot.com from
\RemoteInstall\boot\x86. For more information, see Managing Network Boot Programs.

Performing Management Operations

I can't approve a pending computer.
The two most common causes of this issue are the following:
• You do not have the correct permissions in AD DS for the computer. Each computer
requires a computer certificate. For more information, see Required Permissions.
• The computer name is not valid. For example, the name might be too long, or it might
contain characters that are not valid.

I approved a pending computer and then deleted the computer account that
was created in AD DS during the process. Now the server will not
answer my client computer.
Deleting a prestaged computer that was added to AD DS by using the approval process for
pending computer involves two steps:
• Remove the computer account from AD DS.
• Remove the record in the Auto-Add database.
Failing to remove the record in the database will cause the client to remain in wdsnbp.com, and it
will not proceed with booting from the network. This occurs because the record in the Auto-Add
database shows the computer as approved, but a prestaged computer in AD DS will not be found
(because the computer was deleted).
This scenario is identical to a case where there is AD DS replication latency. For example, the
server will not permit the client to proceed past Wdsnbp.com until a prestaged computer appears
in AD DS.
For more information, see Prestaging Client Computers.

I received the error: "0x2: File not found" when trying to manage a remote
Windows Deployment Services server.
You may have received this error if you are trying to manage a Windows Deployment Services
server running Windows Server 2008 from a Windows Deployment Services server running
Windows Server 2003.This scenario is not supported. You can only manage Windows
Deployment Services servers running Windows Server 2008 from a Windows Deployment

184
Services server running Windows Server 2008. For more information, see Managing a Complex
Environment.

Creating Custom Install Images

When using Image Capture Wizard to create a custom image, the volume
that contains my image is not selectable.
There are two common reasons for this problem:
• Cause 1: The boot image does not contain the proper drivers for the computer’s
hard disk drive controller. To troubleshoot this, when the Image Capture Wizard first starts,
press SHIFT+F10 to open a command prompt. Run Diskpart, and then run lis disk. Select
each disk (for example, sel dis 0 and sel dis 1), and then type lis vol to list each volume.
Ensure that the volume that contains the offline Sysprep image is viewable. If it is not, you
need to add the driver for your mass-storage controller to Windows PE so that it can detect
the local disk that contains the offline Sysprep image. To do this, use one of the following
procedures:

To inject drivers into a boot image, and use the boot image to create a capture image:
1. Add a boot image to your server.
2. Mark the image as offline (disabled).
3. Mount the image by using ImageX and Mountrw (included in the Windows AIK).
4. Insert all of the drivers that use PEIMG.exe into the boot image.
5. Mark the image as online (enabled).
6. Create the capture image using this boot image.

To load the driver yourself in Windows PE:

1. Boot into the capture image.
2. Press SHIFT+F10 to access a command prompt.
3. Use Drvload.exe to load the driver.
4. Confirm that you have access to the local disk that contains the offline image.
5. Press ALT+TAB to return to the capture wizard and continue the process.

• Cause 2: The volume does not contain an image that was prepared using Sysprep.

To determine whether the offline image has been prepared using Sysprep:
1. Run regedit to load the offline system hive.
2. In HKEY_LOCAL_MACHINE\System, create a new key called Test.
3. Import the offline system hive from C:\windows\system32\config\system
(assuming the offline operating system is located on C:\) into the empty Test key.
4. Examine the two registry keys in the imported system hive that are checked by
185
 the wizard:
• Ensure that HKEY_LOCAL_MACHINE\System\Setup\CloneTag exists
• Ensure that
HKEY_LOCAL_MACHINE\System\Setup\SystemSetupInProgress is set to 1.

If either of the registry keys are not set correctly, there are two likely causes:
• The Generalize check box was not selected when Sysprep was run.
• After Sysprep completed, the computer was specialized before the Image Capture
Wizard was started. This can happen if you installed Windows Vista, ran Sysprep,
rebooted the computer, and then failed to signal the PXE boot in time so that the
computer starts to boot and the specialization process runs. You realized your mistake,
restarted the computer, and signaled the PXE boot. Then you booted into Windows PE
and start the image capture wizard. In this scenario, the wizard will not show the volume
because the offline image is no longer generalized.
To resolve either of these, boot into the image, run Sysprep again, and then perform the
capture process again.

The finish button is not enabled on the final page of the image capture
wizard.
This occurs when a name and location for the .wim file is not specified. You must specify this
information even if you are uploading the resulting image to a Windows Deployment Services
server. The Image Capture Wizard creates a local copy of the image first, to ensure that transient
networking conditions will not interfere with the image capture process.
You can specify a location for the .wim file that is on the same volume that is being captured (this
will not interfere with the capture process). By default, this local image is not deleted at the
conclusion of the image capture process. To delete the file, specify the appropriate unattended
installation setting. For more information, see Automating the Image Capture Wizard.

The capture started successfully, but then I got a metadata error.

The most common cause of this is if you do not use the .wim file extension when specifying
where to save the file locally in the image capture wizard. To resolve this, retry the capture and
specify <path>\<imagename>.wim.

Multicasting
My multicast transmissions are running very slowly.
One typical cause of this issue occurs in environments that contain computers with different
hardware configurations and architectures. In this case, some clients can run multicast
transmissions faster than others. Because each transmission can be run only as fast as the
slowest client, the entire transmission will be slow if there is one slow client. To resolve this issue,
first determine the client that is holding back the transmission (this is called the master client). To

186
do this, view the output of the following command: WDSUTIL /Get-
AllMulticastTransmissions /Show:Clients. Next, disconnect the master client using
WDSUTIL /disconnect-client /ID:<ID>, where ID is the client ID (which you can get using the
/get-transmission option).
Disconnecting the master client will force it to run the transmission by using the Server Message
Block (SMB) protocol, and the other clients' multicast performance should speed up. If they do not
speed up, there is a problem with the client's hardware (for example, a slow hard drive) or a
network problem. Also, see Example Multicast Scripts for an example script that will automatically
disconnect slow master clients.

After enabling multicasting, there is excessive traffic on the network.

One common cause of this is if Internet Group Membership Protocol (IGMP) snooping is not
enabled on all devices. IGMP snooping enables your network hardware to forward multicast
packets only to those devices that are requesting data. If IGMP snooping is turned off, multicast
packets are treated as broadcast packets, and will be sent to every device in the subnet. In cases
where you cannot enable IGMP snooping, you can adjust the multicast packet time-to-live (TTL),
which is 32 by default. You can change this by modifying the registry key of the network profile at:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\Multi
cast\Profiles\
32 is sufficient for most network topologies, but if your environment does not support snooping,
you can use this setting to somewhat mitigate that.

Logging and Tracing

You can enable tracing and logging for all Windows Deployment Services components for
troubleshooting purposes. The installation logs are stored at %windir%\logs\cbs\cbs.log. This
chapter outlines the various logs and output that you can generate.

Caution
Incorrectly editing the registry might severely damage your system. Before making
changes to the registry, you should back up any valued data.

Component Obtain and review this output:

General status of • WDSUTIL /get-server /show:all /detailed

the Windows • Windows Application log in Event Viewer
Deployment
• Windows System log in Event Viewer
Services server

Server • WDSUTIL /get-server /show:all /detailed

187
Component Obtain and review this output:

components • Windows Application log in Event Viewer

• Windows System log in Event Viewer
• Trace logs. To obtain these logs, you must first enable tracing in the
server and management components by setting the following:
HKEY_LOCAL_MACHINE\Software\Microsoft\Tracing\WDSServer
Name: EnableFileTracing
Value:1
Then you can obtain the trace log at %windir%\tracing\wdsserver.log

Management • Enable tracing in the management and MMC snap-in components by

components setting the following:
a. Set the following registry key to enable tracing in the
management components:
HKEY_LOCAL_MACHINE\Software\Microsoft\Tracing\WDSMGMT
Name: EnableFileTracing
Value:1
b. Set the following registry key to enable tracing in the
management console:
HKEY_LOCAL_MACHINE\Software\Microsoft\Tracing\WDSMMC
Name: EnableFileTracing
Value:1
Then you can obtain the trace logs at %windir%\tracing\wdsmgmt.log and
%windir%\tracing\wdsmmc.log.
• WDSUTIL /get-server /show:all /detailed
• Windows Application log in Event Viewer
• Windows System log in Event Viewer

Note
Although the Windows Deployment Services MMC snap-in and
WDSUTIL share the same API layer, in some cases the MMC
adds additional processing and functionality. In instances where
an error occurs, it is often worthwhile to attempt to reproduce the
failure using WDSUTIL to determine if the error is localized to the
MMC or if it is a general management API failure. Often,
WDSUTIL will provide more detailed error output without enabling
tracing. Where applicable, use the /detailed, /verbose, and
/progress options for extra information.

Client component Logging in the Windows Deployment Services client serves two purposes.
First, it allows you to determine if a particular client failed during installation,

188
Component Obtain and review this output:

and it provides details regarding the failure. Second, it allows you to collect
information regarding client installations including how many clients installed a
particular image, and the success rate for client installs. You can view the logs
in the Application event log in Event Viewer. Because a time stamp is logged
with each event, you can use this information to determine how long particular
phases of the client installation process took to complete. This information is
especially useful when diagnosing performance problems or doing
performance benchmarking. There are four logging levels:
• NONE: No logging (default)
• ERRORS: Errors only
• WARNINGS: Warnings and errors
• INFO: The highest level of logging, which includes errors, warnings,
and informational events
To turn on client logging, run WDSUTIL /Set-Server /WDSClientLogging
/Enabled:Yes. To change which events are logged, run WDSUTIL /Set-
Server /WDSClientLogging /LoggingLevel:{None|Errors|Warnings|Info}
(each category includes all events from the previous categories). Regardless
of the logging level, the following information is always logged: Architecture
type, Client IP address, MAC address, and computer GUID, Time, and
Transaction ID. Based on the configured logging level, some or all of these
events are logged: Client started, Image selected, Image apply started, Image
apply finished, Client finished, and Client error.
To view the logs, obtain the following:
Setup logs from the client computer. The setup logs appear in different
places depending on when the failure occurred:
• If the failure occurred in Windows PE before the disk configuration
page of the Windows Deployment Services client has been completed,
you can find the logs at X:\Windows\Panther. Use Shift+F10 to open a
command prompt, and then navigate to the location.
• If the failure occurred in Windows PE after the disk configuration page
of the Windows Deployment Services client has been completed, you can
find the logs on the local disk volume (usually C:\) at
$Windows.~BT\Sources\Panther. Use Shift+F10 to open a command
prompt, and then navigate to the location.
• If the failure occurred on first boot after the image was applied, you
can find the logs in the \Windows\Panther folder of the local disk volume
(usually C:\).
Trace log from the Image Capture Wizard. To obtain these logs, do the
following:
1. Boot into the capture image.

189
Component Obtain and review this output:

2. When the wizard starts, press Shift+F10 to access the command

prompt.
3. Enable tracing for the wizard. To do this, first run Regedit.exe. Then
set the following registry key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Tracing\WDSCapture
Name: EnableFileTracing
Value:1
4. Open a second instance of the Image Capture Wizard.
5. Reproduce the failure using the wizard that you just opened. Do not
close the original wizard or the computer will restart.

Note
Note: you can use Alt+Tab to move between windows.
6. Obtain the trace log from X:\Windows\Tracing\WDSCapture.log.

PXE boot • Enable tracing in the server and management components and obtain
components the trace logs (as outlined previously).
• Obtain a network trace that shows the failed boot attempt. It is a best
practice to obtain this trace from the client and server simultaneously to
accurately assess whether the failure is occurring at the sending server or
the receiving client. The process is:
a. Place a client and a third computer (laptop or desktop) on a hub.
b. Start network traces from the server and third computer.
c. Boot the client from the network.

Note
If you are using Network Monitor to obtain the traces, ensure
that the buffer size is at least 20 MB. If you configure a bufferf
size too small for the capture, then packets will be lost (not
appear) in the capture output.

Network Ports Used

Protocols
Windows Deployment Services uses the following protocols for installing images:
• Dynamic Host Configuration Protocol (DHCP)
• Pre-Boot Execution Environment (PXE)

190
 • Trivial File Transfer Protocol (TFTP)
• Remote procedure call (RPC)
• Server Message Block (SMB)
• Multicasting

Ports
The following table outlines the User Data Protocol (UDP) and Transmission Control Protocol
(TCP) network ports that are used during image deployment. You can modify the values that have
an asterisk (*) by using the instructions in How to Manage Your Server.

UDP TCP

• 67 • 135 for RPC

• 68 if DHCP authorization is required on • 5040* for RPC
the server • 137–139*
• 69
• 4011
• Random ports from 64001 through
65000*, to establish a session with the
server for TFTP and multicasting (in
accordance with RFC 1783 at
http://go.microsoft.com/fwlink/?
LinkId=81027).

The following steps explain the UDP and TCP ports that are used during image
deployment:
1. The client performs a PXE boot.
2. PXE uses DHCP ports and TFTP to download the binary files. For UDP and DHCP,
you need to enable ports 67, 69, and 4011. In addition, TFTP endpoints are used; by
default, these endpoints range from 64001 through 65000. For instructions on modifying
these ranges, see How to Manage Your Server.You can also use the Network Address
Translation (NAT) with the Routing and Remote Access network service to control these
ports.
3. In accordance with RFC 1783 (http://go.microsoft.com/fwlink/?LinkId=81027), the
client chooses random UDP ports to establish the session with the server. You should
use an application exception for TFTP if you have the Windows firewall enabled on the
Windows Deployment Services server.
4. The client downloads Windows PE and boots to the Windows Deployment Services
client. This download also uses the same TFTP ports as mentioned previously.
5. The Windows Deployment Services client communicates with the Windows

191
 Deployment Services server to authenticate and obtain the list of available images. This
conversation occurs over RPC because RPC has built-in authentication (it is one of the
few completely available protocols in Windows PE). You need to allow the port for the
Endpoint Mapper (TCP 135) and the port for the RPC listener for the Windows
Deployment Services server (which is TCP 5040 by default).
6. The Windows Deployment Services client installs the selected image. Image transfer
occurs through SMB. You need all the file-sharing and printer-sharing ports — for
example, TCP 137 through 139 — for installing the image.

Note
In addition, if DHCP authorization is required on the server, you need DHCP
client port 68 to be open on the server. Note that DHCP authorization is not
required by default; but you can turn it on manually.

Required Permissions
This chapter outlines the following permissions and, where appropriate, how to grant them.

In This Topic
• General Permissions
• Permissions for Common Management Tasks
• Permissions for Client Installations
• Permissions for Server Properties

Caution
To modify the registry settings that are described in this guide, use only the Windows
Deployment Services management tools—you should not directly edit these settings
and attributes.

General Permissions
To fully administer a Windows Deployment Services server, you need the following permissions:
• Local administrator of the Windows Deployment Services server. This gives you the
following rights:
• File permissions and permissions to the RemoteInstall folder (the management tools
interact with the image store using UNC paths).
• Registry hive permissions. Many settings for the Windows Deployment Services
server are stored in HKEY_LOCAL_MACHINE\System, and you need appropriate
permissions to these locations to change them.

192
 • Domain administrator of the domain that contains the Windows Deployment
Services server. This gives you permissions on the Service Control Point (SCP) in Active
Directory Domain Services (AD DS) for the Windows Deployment Services server. Some
configuration settings for the server are stored here.
• Enterprise administrator (optional). This gives you Dynamic Host Configuration
Protocol (DHCP) authorization permissions. If DHCP authorization is enabled, the Windows
Deployment Services server must be authorized in AD DS before it will be allowed to answer
incoming client PXE requests. DHCP authorization is stored in the Configuration container
in AD DS.
It is often useful to delegate the management of a Windows Deployment Services server to an
account other than the domain administrator or enterprise administrator (and grant these general
permissions to the delegated account). The delegated administrator account should be a local
and domain administrator as specified above.

Permissions for Common Management Tasks

The following table contains common tasks and the permissions that are required for each.

Task Permissions Needed

Add or Full control over C:RemoteInstall\Images\ImageGroup.

remove
an
image
group

Add or Full control over C:RemoteInstall\Images\ImageGroup.

remove
an
image

Disable Permission to read and write attributes for the associated image file. Disabling an image
an means hiding the Windows image (.wim) file associated with the image.
image

Add a Read and write access to the following:

boot • C:RemoteInstall\Boot
image
• C:RemoteInstall\Admin (This folder is only present if you upgrade from Windows
Server 2003).
• %TEMP%

Remov Read and write access to C:RemoteInstall\Boot.

ea
boot
image

193
Task Permissions Needed

Set Read and write permissions to the .wim metadata file that represents the image. This file
propert is located within the image group at: C:RemoteInstall\Images\ImageGroup.
ies on
an
image

Presta Permissions to create accounts in the domain, as well as write to the properties of a
ge a computer object.
comput To grant permissions to prestage a computer
er
1. Open Active DirectoryUsers and Computers.
2. Right-click the organizational unit (OU) where you are creating prestaged
computer accounts, and then select Delegate Control.
3. On the first screen of the wizard, click Next.
4. Add the user or group you wish to delegate control to, and then click Next.
5. Select Create a Custom task to delegate.
6. Select Only the following objects in the folder. Then select the Computer
Objects check box, select Create selected objects in this folder, and click Next.
7. In the Permissions box, select the Write all Properties check box, and click
Finish.

Approv Read and write permissions for the folder that contains the database file Binlsvcdb.mdb
ea in the RemoteInstall share (for example, C:RemoteInstall\MGMT). The actual account of
pendin an approved pending computer is created by using the server’s authentication token, not
g the token of the administrator who is performing the approval. Therefore, in AD DS, you
comput must grant rights to the Windows Deployment Services server’s account
er (WDSSERVER$) to create computer account objects for the containers and OUs where
the approved pending computers will be created.
To grant permissions to approve a pending computer
1. Open Active Directory Users and Computers.
2. Right-click the OU where you are creating prestaged computer accounts, and
then select Delegate Control.
3. On the first screen of the wizard, click Next.
4. Change the object type to include computers.
5. Add the computer object of the Windows Deployment Services server, and then
click Next.
6. Select Create a Custom task to delegate.
7. Select Only the following objects in the folder. Then select the Computer
Objects check box, select Create selected objects in this folder, and click Next.
8. In the Permissions box, select the Write all Properties check box, and click
Finish.

194
Task Permissions Needed

Presta The user account must have permissions to join the domain. The JoinRights registry
ge a setting determines the set of security privileges, and the User registry setting
comput determines which users have the right to join the domain. To change the per server (per
er to architecture) defaults, you need read and write permissions to these registry keys.
join a • The JoinRights setting is located at
domain HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Pr
oviders\WDSPXE\Providers\BINLSVC\AutoApprove\<arch>
Name: JoinRights
Type: DWORD
Value: 0 = JoinOnly.; 1 = Full.
A user that has Join only rights cannot join the domain without administrator
assistance (an administrator with proper permissions on the computer account
object must reset the computer account before the client installation and domain
join).A user that has Full rights can reset the account and join the domain without
administrator assistance.
• The User setting is stored at
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Pr
oviders\WDSPXE\Providers\BINLSVC\AutoApprove\<arch>
Name: User
Type: REG_SZ
Value: Name of group or user. For this setting, there are two administration models
that you can use.
• (recommended) You can associate a primary user to the account at the time
the computer is approved. When the computer is approved, the computer
account will grant the primary user 1) read and write permissions on all
properties on the computer object (JoinRights = JoinOnly or JoinRights =
Full), and 2) reset and change password rights on the computer object
(JoinRights = Full).
• You can specify server defaults for the user and JoinRights that apply to all
approved clients of a given architecture. The default values grant domain
administrators the Full join right. If you do not assign a primary user to the
computer account at the time of approval, these default values will take effect.

Note
If you are creating computer accounts against a non-English domain
controller and you are using the default user property, you must set the
Auto-Add settings to use a different account that does not contain
extended characters. If the account contains a non-standard character
(any character outside [A-Z, a-z, 0-9, \, -, and so on]), such as German's
"Domänen-Admins", then Auto-Add will fail. To change this value, see

195
Task Permissions Needed

the help at the command prompt for WDSUTIL /set-server

/AutoAddSettings.

Conver • Read and write permissions to the %TEMP% directory and destination location
ta • Read permissions on the original RIPREP image
RIPRE
P
image

Create • Read and write permission to the %TEMP% directory and destination location
a • Read permissions on the original boot image
discov
er or
capture
image

Create • Full control over the following registry key:

a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Pr
multica oviders\Multicast
st • Read permissions to RemoteInstall\Images\ImageGroup.
transmi
ssion

Modify Full control over the following registry key:

a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Provid
multica ers\Multicast
st
transmi
ssion
(for
exampl
e,
delete,
deactiv
ate,
start,
stop,
discon
nect,
and so
on)

196
Permissions for Client Installations
In general, performing a client installation requires domain user rights. However, additional
permissions may be required depending on the scenario. This section outlines the minimal set of
permissions that are required to perform common installation tasks.

Task Permissions Needed

PXE boot a client computer No permissions are required to PXE boot a

client, and no mechanism exists to secure the
process of booting from the network. If security is
the primary concern for you, we recommend that
you use physical media (for example, that
contains a discover image) to boot each
computer.

Select a boot image No permissions are required to select a boot

image and no mechanism exists to secure
entries that are displayed in the list. The first
authentication mechanism occurs using the
Windows Deployment Services client running
within Windows PE.

Select an install image The credentials provided in the user interface of

the Windows Deployment Services client must
be those of a domain account. After a client has
been authenticated to the Windows Deployment
Services server, the authenticated user must be
able to read the install .wim file and Res.rwm file
from the RemoteInstall folder. By default,
authenticated users have permissions to do so.

Join a domain The JoinRights registry setting determines the

set of security privileges, and the User registry
setting control which users have the right to join
the domain. For more information about these
settings, see the Prestaged a computer to join
a domain section in the previous table.
If the computer is prestaged, then the user
performing the installation (or the credentials in
the Unattend file for the domain join) needs the
appropriate JoinDomain rights. If the computer
is not prestaged (meaning Windows Deployment
Services will create a computer account in AD
DS), the user performing the installation (or the
credentials as specified in the Unattend file for

197
Task
Using /ResetBootProgram
Disabling access to the command prompt
during installations
Permissions Needed
the domain join) need rights to add a prestaged
computer and the appropriate JoinRights.
If the ResetBootProgram functionality is enabled,
the user needs read and write permissions to the
netbootMachineFilePath property on the
prestaged computer object. If this permission is
not granted and the user's boot program is set to
pxeboot.n12, Windows Deployment Services will
not be able to reset the NBP to pxeboot.com,
forcing the computer into an infinite reboot loop.
For more information, see Managing Network
Boot Programs.
By default, users can gain access to a command
prompt during Windows Deployment Services
installations by:
• Pressing Shift+F10 when Setup is
running in Windows PE.
• Pressing Shift+F10 when the Image
Capture Wizard is running in Windows PE.
• Holding down the CTRL key when
Microsoft Windows Preinstallation
Environment (Windows PE) is booting.
• Pressing Shift+F10 when the Out of Box
Experience (OOBE) is running (OOBE is the
wizard that usually runs after Setup).
Important
A Command Prompt window that is
opened during OOBE will be running
in the system context. If this window
is not closed at the conclusion of
Setup, the user may have access to
it and therefore, system rights, even
though the user is not a local
administrator on the client computer.
You can disable this functionality by adding a
DisableCmdRequest.tag to the image.
To disable access for boot images
1. In the Windows Deployment Services
MMC snap-in, right-click the desired boot
198
Task Permissions Needed

image and select Disable.

2. Mount the image for read and write
access using the tools provided in the
Windows Automated Installation Kit (AIK).
3. Create the file %windir
%\Setup\Scripts\DisableCmdRequest.tag in
the mounted image.
4. Commit the changes and unmount the
image.
5. In the Windows Deployment Services
MMC snap-in, right-click the desired boot
image and select Enable. .
To disable access for install images
1. In the Windows Deployment Services
MMC snap-in, right-click the desired boot
image and choose Disable.
2. Export the image to an external .wim file.
3. Mount the image for read and write
access using the tools provided in the
Windows AIK.
4. Create the file %windir
%\Setup\Scripts\DisableCmdRequest.tag in
the mounted image.
5. Commit the changes and unmount the
image. .
6. In the Windows Deployment Services
MMC snap-in, right-click the disabled install
image and choose Replace Image.
7. Follow the instructions in the wizard to
re-import the modified install image.

Permissions for Server Properties

The following section outlines the minimal set of permissions that are necessary to perform
common management tasks using the server properties pages. To access these settings, open
the Windows Deployment Services MMC snap-in, right click the server, and click Properties.

199
Tab Settings that Require Permissions

PXE • PXE response policy. The PXE response policy (for example, responding only to
Resp known clients, or responding to all clients) is stored on the server’s SCP. Configuring
onse these settings requires read and write permissions to the SCP object.
Settin To grant permissions to the SCP object
gs
a. Open Active Directory Users and Computers.
b. Click View, and then click Advanced Features (if it is not already enabled).
c. Right click the computer account for you Windows Deployment Services
server, and click Properties.
d. On the Remote Install tab, select Advanced Settings…
e. Select the Security tab, and click Add…
f. Select the user, and then select Full Control on this object.
• PXE response delay. Configuring this setting requires read and write
permissions to the following registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSSERVER\Pro
viders\WDSPXE\Providers\BINLSVC
Name: ResponseDelay
Type: REG_DWORD
Value: Number of seconds to wait before answering PXE client requests

Direct • New client naming policy. This setting is stored in the SCP object on the server.
ory The property is called: netbootNewMachineNamingPolicy
Servi • Client account location. This setting is stored in the SCP object on the server.
ces The property is called: netbootNewMachineOU

Boot Default boot program

• Server-wide: This option is controlled by the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Prov
iders\WDSPXE\Providers\BINLSVC\BootPrograms\<arch>
Name: Default
Type: REG_SZ
Value: Path to server-wide client default boot program for this architecture. For
example: boot\x86\pxeboot.com
• Per computer: The computer account attribute is: netbootMachineFilePath
Default boot image
• Server-wide: This option is controlled by the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Prov
iders\WDSPXE\Providers\BINLSVC\BootImages\<arch>
Name: BootImagePath

200
Tab Settings that Require Permissions

Type: REG_SZ
Value: Path to server-wide client default boot image for this architecture. For example:
boot\x86\images\boot.wim
• Per computer: The computer account attribute is: netbootMirrorDataFile

Client Unattend file

• Server-wide: This option is controlled by the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Prov
iders\WdsImgSrv\Unattend\x86
Name: FilePath
Type: REG_SZ
Value: Path to server-wide client Unattend file relative to the RemoteInstall folder. For
example: WdsClientUnattend\WdsUnattend.xml
• Per computer: The computer account attribute is netbootMirrorDataFile
Client account creation
• This option is controlled by the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Prov
iders\WDSPXE\Providers\BINLSVC
Name: NewMachineDomainJoin
Type: DWORD
Value: 0 to prevent domain joining by clients; 1 to enable it.

DHC • Do not listen on Port 67. This option is controlled by the following registry key:
P HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSSERVER\Pro
viders\WDSPXE
Name: UseDhcpPorts
Type: DWORD
Value: 0 disabled; 1 enabled
• Configure DHCP option 60 to "PXEClient".This requires that the user is able to
configure the Microsoft DHCP server running on the local computer.

Adva • DC/GC used by the Windows Deployment Services server (this server).
nced These settings are stored at the following registry location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Prov
iders\WDSPXE\Providers\BINLSVC
The keys for these settings are as follows:
• Default domain controller: Name: DefaultServer, Type: REG_SZ, Value:
FQDN for default domain controller.
• Default global catalog server: Name: DefaultGCServer, Type: REG_SZ,

201
Tab Settings that Require Permissions

Value: FQDN for default global catalog server.

• DHCP authorization. Performed using DHCP APIs—you need permissions to
authorize the Microsoft DHCP server.

202