Windows Deployment Services Deployment
Guide
Microsoft Corporation
Published: March 2009
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.
© 2009 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 Guide ...................................................................... 13
In This Guide .............................................................................................................................. 13
In This Topic ............................................................................................................................... 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 ....................................................................................................... 19
Configuring AD DS Integration ...................................................................................................... 19
In This Topic ............................................................................................................................... 19
Supported Environments ............................................................................................................ 19
Configuring Static Domain Controllers and Global Catalog Servers ......................................... 20
Creating a Localized Setup Experience ........................................................................................ 20
In This Topic ............................................................................................................................... 21
Localizing the Boot Menu ........................................................................................................... 21
Localizing Setup ......................................................................................................................... 21
Installing Language Packs ......................................................................................................... 23
Methods .................................................................................................................................. 23
Storing Language Packs in the Image Store .......................................................................... 24
Configuring DHCP ......................................................................................................................... 25
In This Topic ............................................................................................................................... 25
Configuring DHCP Options ........................................................................................................ 25
Enabling DHCP Authorization .................................................................................................... 26
Authorizing a Server ................................................................................................................... 27
Managing Network Boot Programs................................................................................................ 27
In This Topic ............................................................................................................................... 28
Configuring the NBP .................................................................................................................. 28
List of NBPs ................................................................................................................................ 28
Directing a Client to the Appropriate NBP .................................................................................. 29
Updating the IP Helper Tables ................................................................................................ 30
Using DHCP Options 60, 66, and 67 ...................................................................................... 30
Implementing PXE Referrals ...................................................................................................... 31
When to Implement PXE Referrals ......................................................................................... 31
Requirements.......................................................................................................................... 32
Referral Examples .................................................................................................................. 32
Enabling Architecture Detection ................................................................................................. 33
Avoiding a Boot Loop ................................................................................................................. 34
Managing the Boot Menu .............................................................................................................. 34
In This Topic ............................................................................................................................... 34
Configuring the Boot Menu ........................................................................................................ 35
Specifying Boot Images for Prestaged Clients ........................................................................... 35
Considerations for x64-Based Clients ........................................................................................ 36
Prestaging Client Computers ......................................................................................................... 36
In This Topic ............................................................................................................................... 36
Creating Computer Account Objects in AD DS .......................................................................... 36
Benefits ...................................................................................................................................... 37
Enabling the Auto-Add Policy..................................................................................................... 37
Purging the Auto-Add Database ................................................................................................ 38
Optimizing Your Deployment ......................................................................................................... 39
Extending Your Solution ................................................................................................................ 39
In This Topic ............................................................................................................................... 39
Benefits ...................................................................................................................................... 39
Creating a Custom Solution ....................................................................................................... 40
Windows Deployment Services PXE Server ....................................................................... 40
Windows Deployment Services Client................................................................................. 41
Custom Solution Example .......................................................................................................... 41
Instructions for Using the Sample Code ................................................................................. 42
Sample Visual Basic Script ..................................................................................................... 43
Sample Image Unattend File .................................................................................................. 44
Sample WinPESHL.ini File ..................................................................................................... 45
Managing a Complex Environment ............................................................................................... 45
In This Topic ............................................................................................................................... 45
Managing a Server Remotely..................................................................................................... 45
Avoiding IP Address Conflicts .................................................................................................... 46
Testing by Using Virtual Computers........................................................................................... 47
Versions of the Management Tools to Use with RIS and Windows Deployment Services ....... 47
Optimizing Performance and Scalability ........................................................................................ 49
In This Topic ............................................................................................................................... 49
Best Practices for Avoiding Performance and Scalability Problems .......................................... 49
Configuring the Server for Performance and Scalability ............................................................ 50
Performance and Scalability Expectations ................................................................................. 50
Unicasting ............................................................................................................................ 51
Multicasting .......................................................................................................................... 52
Multicast Installation ......................................................................................................... 53
Unicast Installation ........................................................................................................... 53
Testing of Security Options with Multicast ....................................................................... 54
Using Transport Server ................................................................................................................. 54
In This Topic ............................................................................................................................... 54
Comparison of Deployment Server and Transport Server ......................................................... 55
Configuring Transport Server ..................................................................................................... 56
Using a Transport Server to Boot from the Network .................................................................. 57
Using a Transport Server for Multicasting .................................................................................. 57
How to create a namespace with Transport Server ............................................................... 57
Prerequisites for creating a namespace .............................................................................. 57
To create a namespace ....................................................................................................... 58
How to join a client computer to a namespace by using Wdsmcast.exe ................................ 58
How to perform common tasks ............................................................................................... 60
Options ............................................................................................................................. 61
Performing Unattended Installations ............................................................................................. 62
Automating the PXE Boot .............................................................................................................. 63
In This Topic ............................................................................................................................... 63
Automating the PXE Boot .......................................................................................................... 63
Avoiding a Boot Loop .............................................................................................................. 63
Example Scenario ................................................................................................................... 64
Automating the Selection of the Boot Image .............................................................................. 64
Automating Setup .......................................................................................................................... 65
In This Topic ............................................................................................................................... 65
Creating Unattend Files ............................................................................................................. 65
Automating the User Interface Screens of the Windows Deployment Services Client .............. 66
Unattend File Settings ............................................................................................................ 67
Automating the Remaining Setup Phases ................................................................................. 68
Automating the Domain Join ......................................................................................................... 69
In This Topic ............................................................................................................................... 69
Modifying Your Unattend Files ................................................................................................... 69
Choosing a Permissions Method ............................................................................................... 70
Automating the Image Capture Wizard ......................................................................................... 71
WDSCapture.inf Unattend File Settings ..................................................................................... 71
Advanced Unattended Installation Scenarios ................................................................................ 73
In This Topic ............................................................................................................................... 74
Passing Unattend Files to Setup by Using the Command Line ................................................. 74
Using Implicit Unattend Files ...................................................................................................... 75
Embedding an Unattend File in an Image .................................................................................. 75
Understanding Unattend File Precedence ................................................................................. 75
Setting Command-Line Precedence for Image Unattend Files ................................................. 76
Using Variables to Obtain Information from the Client ............................................................... 77
Sample Unattend Files .................................................................................................................. 77
In This Topic ............................................................................................................................... 77
Windows Deployment Services Client Unattend Files ............................................................... 78
Example 1: Standard installation ............................................................................................ 78
Example 2: Install a language pack ........................................................................................ 80
Image Unattend Files for Windows Vista and Windows Server 2008 ........................................ 82
Example 1: Unsecure domain join .......................................................................................... 82
Example 2: Secure domain join .............................................................................................. 83
Example 3: Using variables .................................................................................................... 84
Image Unattend Files for Older Operating Systems .................................................................. 85
Example 1: Domain join .......................................................................................................... 85
Example 2: Using variables .................................................................................................... 86
Example 3: Run a script .......................................................................................................... 86
Combined Image and Client Unattend File ................................................................................ 87
Image Capture Wizard Unattend File ......................................................................................... 91
Working with Images ..................................................................................................................... 92
Creating Images ............................................................................................................................ 92
In This Topic ............................................................................................................................... 92
Image Types ............................................................................................................................... 92
Boot Images ............................................................................................................................... 93
Creating Custom Boot Images ................................................................................................ 93
Versions of Windows PE ........................................................................................................ 93
Discover Images......................................................................................................................... 94
Creating Custom Discover Images ......................................................................................... 95
Capture Images .......................................................................................................................... 96
Comparison of ImageX and Image Capture Wizard ............................................................... 96
Creating Custom Capture Images .......................................................................................... 97
Converting RIPREP Images ....................................................................................................... 97
Default Conversion ................................................................................................................. 97
In-Place Conversion................................................................................................................ 97
Deploying Earlier Versions of Windows ........................................................................................ 98
Filtering Images ............................................................................................................................. 99
Automatic Filtering by Windows Deployment Services .............................................................. 99
Filtering Images Manually ........................................................................................................ 100
Servicing Images ......................................................................................................................... 100
In This Topic ............................................................................................................................. 100
Types of Servicing .................................................................................................................... 100
Servicing an Image Offline ....................................................................................................... 101
Reducing the Size of Images ................................................................................................... 102
Storing and Replicating Images Using DFS ................................................................................ 102
Storing Files on Another Server ............................................................................................... 102
Replicating Images ................................................................................................................... 103
How to Perform Common Tasks ................................................................................................. 104
How to Manage Your Server ....................................................................................................... 105
General Tasks .......................................................................................................................... 107
To configure Windows Deployment Services ....................................................................... 107
To start or stop the server ..................................................................................................... 108
To enable the server ............................................................................................................. 108
To enable logging for the Windows Deployment Services client .......................................... 108
To choose the port number for RPCs ................................................................................... 109
To specify the network interfaces for Windows Deployment Services to listen on .............. 109
To configure how often the server refreshes its settings ...................................................... 110
To force the server to update files in the RemoteInstall folder ............................................. 110
To configure the network profile for the server ..................................................................... 110
To back up the server data ................................................................................................... 111
DHCP ....................................................................................................................................... 111
To configure Windows Deployment Services to run on the same computer as Microsoft
DHCP ................................................................................................................................ 111
To configure Windows Deployment Services to run on the same computer as non-Microsoft
DHCP ................................................................................................................................ 112
To turn on the DHCP authorization requirement .................................................................. 112
To authorize the server in DHCP .......................................................................................... 112
Client Requests ........................................................................................................................ 113
To configure the server to answer clients ............................................................................. 113
To set a delay in the server’s answers to PXE requests ...................................................... 114
To configure unknown clients to perform PXE boots without requiring F12 ......................... 114
To configure clients who have booted without F12 to require a key press on subsequent
boots .................................................................................................................................. 114
To configure the server to determine the architecture of booting clients .............................. 115
Client Boot Settings .................................................................................................................. 115
To choose which boot images are displayed on x64-based computers ............................... 115
To choose the default network boot program for each architecture ..................................... 115
To choose the default network boot program that does not require F12 for each architecture
........................................................................................................................................... 116
To choose the default boot image for each architecture ...................................................... 116
Active Directory Domain Services ............................................................................................ 117
To specify a domain controller for Windows Deployment Services ...................................... 117
To specify a global catalog server for Windows Deployment Services ................................ 117
To choose whether to search for computer accounts in the domain controller before
searching the global catalog .............................................................................................. 117
To configure the server to prestage clients by using their MAC address instead of their GUID
........................................................................................................................................... 118
To maintain a list of GUIDs that belong to multiple computers ............................................ 118
To specify how to generate computer names ....................................................................... 119
To specify the domain and OU in which to create computer accounts ................................ 119
To choose whether to join client computers to the domain .................................................. 120
Unattend File ............................................................................................................................ 121
To choose a default unattend file for the Windows Deployment Services client .................. 121
To specify whether an unattend file on the client computer will override a default unattend file
........................................................................................................................................... 121
How to Manage Client Computers............................................................................................... 122
Prestage Computers ................................................................................................................ 123
To prestage a client computer .............................................................................................. 123
To prestage a client computer to boot from a different server .............................................. 124
To prestage a client computer to use a network boot program other than the default ......... 124
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 .......................... 125
To prestage a client computer to join a domain .................................................................... 125
To view the attributes of a prestaged client .......................................................................... 126
Configure the Auto-Add Policy ................................................................................................. 126
To enable the Auto-Add policy.............................................................................................. 126
To change the length of time approved computers are held in the Auto-Add database ...... 127
To change the length of time rejected and pending computers are held in the Auto-Add
database ............................................................................................................................ 127
To delete the approved or rejected computers table ............................................................ 127
Specify Settings for Pending Computers ................................................................................. 128
To change the rate at which pending computers will poll the server .................................... 128
To change the number of times pending computers will poll the server .............................. 128
To change the message displayed to pending computers ................................................... 128
To set a default network boot server for pending computers ............................................... 129
To set a default network boot program for pending computers ............................................ 129
To set a default unattend file for pending computers ........................................................... 129
To set a default boot image for pending computers ............................................................. 130
To set domain join options for pending computers ............................................................... 130
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 ......................................... 131
To approve a pending computer, but change a setting ........................................................ 132
To approve all pending computers, but change a setting ..................................................... 132
To reject a pending computer ............................................................................................... 133
How to Manage Images ............................................................................................................... 134
General Tasks .......................................................................................................................... 134
To export an image from the server to a stand-alone .wim file ............................................ 134
To replace an image on the server with an updated version ................................................ 135
To remove an image ............................................................................................................. 136
Boot Images ............................................................................................................................. 136
To add a boot image to the server ........................................................................................ 136
To set the attributes on a boot image ................................................................................... 137
To display the attributes of a boot image .............................................................................. 138
To create a capture image .................................................................................................... 138
To create a discover image .................................................................................................. 139
Install Images ........................................................................................................................... 139
To add an install image ......................................................................................................... 139
To set the attributes for an install image ............................................................................... 139
To display the attributes for an install image ........................................................................ 140
To convert a RIPREP image to a .wim install image ............................................................ 140
To make a copy of an install image ...................................................................................... 141
Image Groups........................................................................................................................... 141
To remove an image group ................................................................................................... 141
To add an image group to the image store ........................................................................... 142
To set the attributes on an image group ............................................................................... 142
To display information about all images in an image group ................................................. 143
How to Create Multicast Transmissions ...................................................................................... 143
In This Topic ............................................................................................................................. 143
When to Implement Multicasting .............................................................................................. 143
Prerequisites for Creating a Multicast Transmission ................................................................ 144
Known Issues in Creating a Multicast Transmission................................................................ 144
Transmission Types ................................................................................................................. 145
To create a multicast transmission with Deployment Server ................................................... 146
To manage transmissions ........................................................................................................ 146
To manage clients in a transmission ........................................................................................ 147
To configure the UDP port range for multicasting .................................................................... 148
To configure how the server will obtain IP addresses for multicasting .................................... 149
Example Multicast Scripts ........................................................................................................... 150
In This Topic ............................................................................................................................. 150
Stop Transmissions Slower than 1 MB per Second ................................................................. 150
Display Performance Information About Clients ...................................................................... 155
How to Modify the BCD Store Using Bcdedit .............................................................................. 158
In This Topic ............................................................................................................................. 158
To View the Contents of the BCD Store .................................................................................. 159
To Configure the Default Selection Time-out Value................................................................. 159
To Configure a Localized Boot Manager Experience .............................................................. 160
To Configure the TFTP Block Size........................................................................................... 161
To Configure the TFTP Window Size....................................................................................... 163
To Configure Windows Debugger Options .............................................................................. 163
To Turn On Emergency Management Services Settings ........................................................ 166
Troubleshooting ........................................................................................................................... 169
Troubleshooting Performance Problems ..................................................................................... 169
In This Topic ............................................................................................................................. 169
Analyzing Blockages in Each Phase of Installation ................................................................. 169
PXE Boot Phase ................................................................................................................... 169
TFTP Download Phase ......................................................................................................... 170
Diagnosing TFTP Download Performance Problems ....................................................... 170
Addressing TFTP Download Performance Problems ....................................................... 171
Image Apply Phase ............................................................................................................... 172
Diagnosing Performance Problems in the Image Apply Phase ........................................ 172
Addressing Performance Problems in the Image Apply Phase ........................................ 172
Using Performance Monitoring ................................................................................................. 173
Common Problems ...................................................................................................................... 176
Performing PXE Boots on Client Computers ........................................................................... 177
I am unable to perform PXE boots on client computers. ................................................... 177
When I perform a PXE boot and select a boot image, I see a command prompt. ............ 178
The client computer fails to get an IP address when I try to PXE boot. ............................ 178
The client computer obtains an IP address but then fails to download a NBP. ................ 178
I don't see the hard drive of the client computer on the disk configuration page of Setup.178
My computer loads the boot image, but it cannot access an install image. ...................... 178
I created an unattend file, but when installation completes, my client computer is not joined
to the domain. ................................................................................................................ 179
Install images do not appear on the image selection page. .............................................. 179
Troubleshooting x64-Based Client Computers ........................................................................ 179
My x64-based client computer does not have any x64-based images on the boot image
selection page. ............................................................................................................... 179
My x64-based client computer is detected as x64, but it fails to boot to the default image.
....................................................................................................................................... 179
Performing Management Operations ....................................................................................... 180
I can't approve a pending computer. ................................................................................. 180
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. .......... 180
I received the error: "0x2: File not found" when trying to manage a remote Windows
Deployment Services server. ......................................................................................... 180
Creating Custom Install Images ............................................................................................... 180
When using Image Capture Wizard to create a custom image, the volume that contains my
image is not selectable. ................................................................................................. 180
The finish button is not enabled on the final page of the image capture wizard. .............. 182
Multicasting .............................................................................................................................. 182
My multicast transmissions are running very slowly. ........................................................ 182
After enabling multicasting, there is excessive traffic on the network. .............................. 183
Logging and Tracing .................................................................................................................... 183
Network Ports Used ..................................................................................................................... 187
Protocols .................................................................................................................................. 187
Ports ......................................................................................................................................... 187
Required Permissions ................................................................................................................. 188
In This Topic ............................................................................................................................. 188
General Permissions ................................................................................................................ 189
Permissions for Common Management Tasks ........................................................................ 189
Permissions for Client Installations .......................................................................................... 193
Permissions for Server Properties ........................................................................................... 195
Windows Deployment Services Deployment
Guide
This guide contains detailed information about how to manage and deploy operating systems by
using Microsoft® Windows® Deployment Services. To download the Windows Deployment
Services documentation (including a getting started guide, deployment guide, and WDSUTIL
command-line syntax), see http://go.microsoft.com/fwlink/?LinkId=89381. For information about
what is new in each version of Windows Deployment Services, see Windows Deployment
Services: What's New (http://go.microsoft.com/fwlink/?LinkId=140114).
In This Guide

Configuring Your Deployment

Optimizing Your Deployment

Performing Unattended Installations

Working with Images

How to Perform Common Tasks

Troubleshooting
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 Windows Deployment Services
Getting Started Guide.

To provide feedback on this documentation, e-mail wdsdoc@microsoft.com.
In This Topic

Benefits of Windows Deployment Services

Management Tools

Common Usage Scenarios
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
14
computers out of action (effectively disabling the office workers), it is important that she makes
the switch as quickly as possible.
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
15
image to be applied to the first computer, Monica boots another computer and starts the same
process on that one.
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.
16
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
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.

Use multicast deployments to preserve bandwidth while deploying images to many
computers concurrently.

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
17
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.
Shu uses multicasting to deploy to the 150 computers in the U.S. office simultaneously. To do
this, he creates a multicast transmission for the Windows Vista image on his Windows
Deployment Services server.
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.
The computers in the U.S. office will automatically join the multicast transmission, while the
computers in the other offices will deploy using unicasting. When the installation is completed,
Shu runs a task with USMT to migrate the user data to each computer.
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 installs the Windows Deployment Services server role on
his server (choosing to install only the Transport Server role service). He then writes a PXE
provider (a plug-in that reads information from the database and passes it to Windows
Deployment Services) and registers it with the server. He creates a custom boot image that
18
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 AD DS Integration

Creating a Localized Setup Experience

Configuring DHCP

Managing Network Boot Programs

Managing the Boot Menu

Prestaging Client Computers
Configuring AD DS Integration
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. You can
prestage a device in AD DS, which means to link a physical computer to a computer account
object. By doing this, 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.You can also link physical booting computers to computer account objects in AD DS. For
more information, see Prestaging Client Computers.
In This Topic

Supported Environments

Configuring Static Domain Controllers and Global Catalog Servers
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.
19
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.

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 define the domain controller and global catalog server
Windows Deployment Services will use. You can do this on the Advanced tab of the server’s
properties (right-click the server in the MMC snap-in, and click Properties). 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. Thisconfiguration 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 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 default dynamic discovery method.
Creating a Localized Setup Experience
You can create a localized setup experience during any phase of an installation.
20
In This Topic

Localizing the Boot Menu

Localizing Setup

Installing Language Packs
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 Setup
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
21
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.
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\dede.
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
22
[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 snapin, and then click Replace Image.
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
more information, see Install a Language Pack to an Offline Image at
http://go.microsoft.com/fwlink/?LinkId=120685.

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.
23
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
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.
Within Windows Deployment Services, you store language packs on a per-image basis within the
RemoteInstall directory. You must manually create the folder hierarchy for the language packs as
24
follows: C:\RemoteInstall\Images\<image file name>\Langpacks and then copy the language
folder and language pack to this location. For example, the German language pack would be
stored at C:\RemoteInstall\Images\Image1\Langpacks\de-DE. Also note that you cannot remove
language packs during the installation by using Windows Deployment Services.
A language pack is applicable to all versions of Windows Vista (except for 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.
Configuring DHCP
In This Topic

Configuring DHCP Options

Enabling DHCP Authorization

Authorizing a Server
Configuring DHCP Options
The booting client and the server communicate using 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 nonMicrosoft) 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 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 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.
25
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.
Enabling DHCP Authorization
By default, the PXE server for Windows Deployment Services does not need to be authorized to
service client computers. However, you can enable DHCP authorization (which is also known as
rogue detection). 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 PXE
servers and DHCP listeners.
Authorization checks occur only if authorization checking is enabled and the PXE server is
configured to listen on port 67. This means that authorization checks 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. You can enable this
authorization using the following methods:

Using the Windows Deployment Services MMC snap-in. To do this, right click the server,
click Properties and on the Advanced tab, select Yes, Windows Deployment Server should
be authorized in DHCP before servicing clients.

Using WDSUTIL by running WDSUTIL /Set-Server /RogueDetection:Yes.

Using the DHCP MMC snap-in. To do this, on the DHCP server, click Start, point to
Administrative Tools, and then click DHCP.
26
Authorizing a Server
You can authorize a Windows Deployment Services server using the Advanced tab of the
server’s properties. However, you must be a domain administrator in the root domain of the forest
or be an enterprise administrator. Alternatively, you may delegate permissions by using the
following procedure.
To delegate permissions to authorize the server
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.
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 PreBoot 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). On BIOS computers (per the PXE specification), the NBP is a 16-bit, real-
27
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

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

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 (defined on the Boot tab in the properties of the
Windows Deployment Services server). However, you can override the NBP for each server on a
per-client basis (by running WDSUTIL /Set-Device /Device:<name> /BootProgram:<path>).
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, and 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.
List of NBPs
The following table lists the available NBPs in Windows Deployment Services.
NBP
Description
Architecture
Firmware
PXEboot.com
(Default) Requires the user to press the F12
key for a PXE boot to continue.
x86-based and
x64-based
BIOS
PXEboot.n12
Does not require pressing F12 and
x86-based and
BIOS
28
NBP
Description
Architecture
immediately begins a PXE boot.
x64-based
Boots the computer by using the next boot
item in the BIOS without waiting for a timeout.
x86-based and
x64-based
BIOS
Hdlscom1.com and Causes computers that do not support
x86-based and
Hdlscom2.com
firmware console redirection to display
x64-based
"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.
BIOS
Hdlscom1.n12 and
Hdlscom2.n12
Causes computers that support firmware
console redirection will not display the
prompt "Press space or F12 for network
boot" and the computer will not wait for user
input.
x86-based and
x64-based
BIOS
Bootmgfw.efi
The EFI equivalent for Bootmgr.exe. In EFI,
the choice of whether or not to perform a
PXE boot is handled within the EFI shell,
and not by the NBP.
x64-based and
Itanium-based
EFI
Wdsnbp.com
An NBP developed for Windows
Deployment Services that serves the
following general purposes:
x86-based and
x64-based
BIOS
AbortPXE.com
Firmware
1. Architecture detection
2. Pending computer scenarios. When the
Auto-Add policy is enabled, it is sent to
pending computers to pause the PXE boot
and report back the client computer's
architecture to the server.
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.
29

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
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
30
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.

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
31
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,
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
ComputerA sends a DHCP broadcast packet and receives an IP address
32
Example
Details
from PXE server
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:
First order referral
using DHCP options

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.
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:

Second order referral
using both DHCP
options and PXE
server
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.
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
33
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 (using the Boot tab of the
server’s properties).
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
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.
In This Topic

Configuring the Boot Menu

Specifying Boot Images for Prestaged Clients
34

Considerations for x64-Based Clients
Configuring the Boot Menu
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. Note that when
you modify the BCD store, you must force it to be recreated in order for your changes to take
effect. To do this, either restart the WDSServer service (run wdsutil /stop-server and then run
wdsutil /start-server) or run Sc control wdsserver 129. 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
reflect the new default. In addition, other booting clients that have been assigned the same boot
image can reuse this dynamically generated BCD store.
35
Considerations 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
In This Topic

Creating Computer Account Objects in AD DS

Benefits

Enabling the Auto-Add Policy

Purging the Auto-Add Database
Creating Computer Account Objects in AD DS
You can use Windows Deployment Services to link physical computers to computer account
objects in Active Directory Domain Servers (AD DS). This is called prestaging the client.
Prestaged clients are also called known computers. This allows you to then configure properties
on the computer account to control the installation for the client. 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 network boot program. You can create a
computer account object and associate it with a physical computer using the following methods:

Using WDSUTIL. You can prestage client computers before they have attempted a network
boot, by running WDSUTIL /Add-Device /Device:<name> /ID:<ID>. 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.

Using the Active Directory Users and Computers snap-in. You can prestage client
computers before they have attempted a network boot using AD DS. For instructions, see the
section "To prestage a client computer" in How to Manage Client Computers.
36

Enabling the Auto-Add policy. If you enable this policy, when you approve the installation
for an unknown client, the installation will proceed and a computer account will be created in
AD DS for the client. For more information, see Enabling the Auto-Add Policy

Using Windows Deployment Services as part of the image installation. By default, all
operating system installations using Windows Deployment Services result in a client
computer that is joined to a domain. You can disable this functionality using the Client tab of
the server’s properties page.
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 answer 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).
Enabling the Auto-Add Policy
When the Auto-Add policy is enabled, administrative approval is required before unknown clients
(clients that are not prestaged) can install an image. To enable this policy, run WDSUTIL /SetServer /AutoAddPolicy /Policy:AdminApproval. You can also enable it using the PXE
Response settings tab of the server’s properties page.
If you enable this policy, when an unknown computer attempts to boot against the server, the
computer will appear in the Pending Devices node of the MMC snap-in. The computer will
remain in this pending queue until you approve or reject it, the time-out is reached, or the user
cancels the attempt. If you approve the computer, the computer will continue booting from the
network, and a computer account object will be created in AD DS to represent the physical
computer. If you reject the computer, the network boot will abort, the computer will boot from the
next item in the boot order, and a computer account will not be created. If you do not enable this
policy, 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.
37
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
account for a booting computer. In all other cases, this policy will not be in effect. Also note that
this policy does not pertain to computers that use Extensible Firmware Interface (EFI).
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 nonstandard 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.
Purging the Auto-Add Database
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.
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 /DeleteAutoAddDevices /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 (run WDSUTIL /stop-server).
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 (run WDSUTIL /start-server).
38
Optimizing Your Deployment

Extending Your Solution

Managing a Complex Environment

Optimizing Performance and Scalability

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.
In This Topic

Benefits

Creating a Custom Solution

Custom Solution Example
Benefits
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.
39

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
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.
40

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

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.
41

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.
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
42
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
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)
43
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">
<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>
44
</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.
In This Topic

Managing a Server Remotely

Avoiding IP Address Conflicts

Testing 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
45
Method
Explanation
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 Windows
Server 2008 (but
not Windows
Deployment
Services)
To do this, you can install Remote Server 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 clickRole
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.
46
Testing by Using 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 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. In
addition, we recommend that you use virtual computers for either client computers or servers, but
not both.
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
Windows Server 2003

RISETUP (I)

RIPREP (I)
Windows Deployment Services servers running
Windows Server 2003

RISETUP (II)

RIPREP (II)

WDSUTIL (I)

MMC snap-in (I)

WDSUTIL (II)

MMC snap-in (II)
Windows Deployment Services servers running
Windows Server 2008
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)
47
Note
You cannot manage a Windows Deployment Services server running Windows
Server 2008 from a Windows Deployment Services server running Windows
Server 2003.
Servers
Servers running
Servers running
running
Windows
Windows
RIS on
Deployment
Deployment
Windows
Services on
Services on
Server 2003 Windows
Server 2003
Windows
Server 2008
X
X
X
X
X
X
X
X
X
X
Tools that you should use
X
X

RISETUP (I)

RIPREP (I)

RISETUP (II) and RIPREP (II) to manage
any RIS functionality (Legacy/Mixed
mode)

WDSUTIL (I) and WDSMMC (I) to manage
any WDS functionality

WDSUTIL (II)

WDSMMC (II).

RISETUP (II)

RIPREP (II)

WDSUTIL (I)

WDSMMC (I)

RISETUP (I)

RIPREP (I)

WDSUTIL (II)

WDSMMC (II)

RISETUP (II)

RIPREP (II)

WDSUTIL (II)

WDSMMC (II)

RISETUP (II)

RIPREP (II)

WDSUTIL (II)

WDSMMC (II)
48
Optimizing Performance and Scalability
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 Troubleshooting
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.
49

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).

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-persecond 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 highend 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
50
Unicasting
The following table outlines the hardware configurations of the servers that were used during
these scalability tests.
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

Single-processor x86

2 GB of RAM

7,200-RPM disk interface

Dual-processor x64

4 GB of RAM

10,000-RPM disk interface
Middle
100-MB network adapter
High-end
1-GB network adapter
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
51
Number of clients
Low-end
Mid-range
High-end
10
210
145
75
25
450
360
120
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
adapter
clients
Default
4,000
8,000
16,000
32,000
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.
Server
Client
Network interface card
Hardware configuration
Operating system
1-Gbps network adapter

Dual Xenon
processor 5150


2.67 Ghz

8 GB of RAM

Varied but capable
of installing the x86based version of
Windows Vista
100 megabits network
adapter
64-bit version of
Windows
Server 2008

52
Multicast Installation
25 clients
100 clients
300 clients
Restart
computer and
start clock.
Restart computer
and start clock.
Restart
computer and
start clock.
Time when the first client started
download of boot image using TFTP
:23
:21
:23
Time when the last client finishes
download of boot image using TFTP
1:02
2:40
7:16
Time when the first client started the
multicast transfer
3:04
3:55
8:18
Time when the last client finished the
multicast transfer
6:06
7:54
12:30
Total amount of time until the last client
reached the desktop
19:47
22:40
27:40
Unicast Installation
SMB 25 clients
SMB 100 clients
SMB 300 clients
Restart computer Restart
and start clock.
computer and
start clock.
Restart computer
and start clock.
Time when the first client started
download of boot image using TFTP
:21
:22
:20
Time when the last client finished
download of boot image using TFTP
:58
2:40
7:13
Time when the first client started image
transfer using unicast/SMB
3:14
4:38
8:29
Time when the last client started image
transfer using unicast/SMB
13:36
38:15
1:47:58
Total amount of time until the last client
reached the desktop
20:59
45:37
1:55:15
53
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
transfer of the install
image to the client
Clock started
Clock started
Clock started
End of multicast transfer
of the install image to
the client
2:19
2:27
31:05
Percentage of CPU
used during the
multicast transfer
~5%
~11%
~25%
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 Dynamic Host
Configuration Protocol (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.
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
54

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 Host
Configuration Protocol (DHCP), and
Dynamic Name Services (DNS) in the
environment.
Does not require other servers
in the environment.
PXE
Supports PXE boot with the default
PXE provider.
A PXE provider is not installed
so you must create a custom
PXE provider.
Image server
Includes the Windows Deployment
Services image server.
Does not include the Windows
Deployment Services image
server.
Transmission
method
Allows both unicasting and
multicasting.
Allows only multicasting.
Management tools
Is managed using either the Windows
Deployment Services MMC snap-in or
the WDSUTIL command-line tool.
Is managed only by the
WDSUTIL command-line tool.
Application on the
client computer
Uses the Windows Deployment
Services client (which is basically
Setup.exe and supporting files),
Wdsmcast.exe (which is included in
the Windows AIK), or a custom
multicast application.
Uses only Wdsmcast.exe or
custom application.
The server architectures are illustrated in the following diagram. The blue parts are installed with
Transport Server and the Deployment Server. The grey parts are installed with the Deployment
Server only. The yellow parts are not installed with either, but can be written using guidelines in
the Windows SDK.
55
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.

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
56
/Set-TransportServer [/Server:<name>] /Profile:{10Mbps|100Mbps|1Gbps|Custom} at an
elevated command prompt.

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.
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

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.
57

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
WDSUTIL 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.
To create a namespace
Like with Deployment Server, 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
58
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. Download and install the Windows AIK.
2. Run Copype.cmd to create a Microsoft Windows Preinstallation Environment (Windows
PE) image.
3. Mount the image by using Imagex.exe, and then copy the Wdsmcast.exe into the
Windows PE image.
4. If the content that you are multicasting is a .wim image, copy Imagex.exe into the
Windows PE image that you just created. This is so the image can be applied after it is
transmitted.
5. Unmount the image and commit the changes.
6. Boot the client computer to the image (from a CD, DVD, or USB drive, or by using the
PXE capability in Transport Server).
7. Start Windows PE networking by running WPEINIT on the client computer.
8. 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>.
59
Option
Description
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
user name>
The domain name and user name to connect to the server. These
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>
Path to the name of the file to be transferred, relative to the directory
specified in the /ConfigString path of the namespace. For example, if
you specified WDSUTIL /New-Namespace
/ConfigString:C:\RemoteInstall\Images, specify
/SourceFile:ImageGroup\install.wim.
/DestinationFile:<file
path>
The complete file path and name for the destination file.
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 ScheduledCast 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:
60
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
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
Description
/Server:<server
name>
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.
/Namespace:<Nam
espace name>
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.
/FriendlyName:<frie
The friendly name of the namespace. Note that this name does not need to
61
Option
Description
ndly name>
be unique.
/Description:<descri
ption>
A short description of the namespace.
/ContentProvider:<n The name of the content provider that supplies data to the multicast server.
ame>
If you are using the Windows Deployment Services content provider,
specify WDS.
/ConfigString:<confi
g string>
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.
/NamespaceType:
{AutoCast|Schedule
dCast}
The type of namespace to be created.
/Time:<YYYY/MM/D The time on the server when the namespace will start (note that you can
D:hh:mm>
set this option only for Scheduled-Cast transmissions).
/Clients:<Num of
Clients>
The number of clients to wait for before the namespace will start (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

Automating the Image Capture Wizard

Advanced Unattended Installation Scenarios

Sample Unattend Files
62
Automating the PXE Boot
In This Topic

Automating the PXE Boot

Automating the Selection of the Boot Image
Automating the PXE Boot
First to configure the client computer to perform PXE boots automatically when the computer is
started, you can modify the boot order in the computer’s firmware (BIOS or Extensible Firmware
Interface (EFI)) or by disabling any active partitions before booting.

If there are active partitions, the option to boot from the network must be higher in the boot
sequence than the hard disk drive. It is important to note that 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 NBP for a particular client so that only that client receives the *.n12 boot
program.

Configuring unknown clients to perform PXE boots without requiring F12 (WDSUTIL /SetServer /AllowN12ForNewClients:Yes) and then booting a computer that is not prestaged.
For a list of the NBPs, see the "List of NBPs" section in Managing Network Boot Programs.
Note
Because there is only one NBP for EFI computers, you must configure this setting within
the EFI shell.
Avoiding a Boot Loop
When implementing a fully automated experience of booting from the network, it is often
necessary to set the network as the first item in the client’s BIOS boot order and 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
63
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 *.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 Scenario
Consider the following situation. Computer A has been configured with the following boot order:
CD-ROM, Network, then 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).
64
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:

Configure the default boot image at the server level by running WDSUTIL /Set-Server
/BootImage:<Relative path>] /Architecture:{x86 | ia64 | x64} where <path> is the relative
path to the RemoteInstall folder. This setting applies to all clients of a particular architecture
(both prestaged and unknown computers) that connect to the server.

Configure the default boot image for a client by running the command WDSUTIL /Set-Device
/Device:<name> /BootImagePath:<Relative path>, where <path> is the relative path to the
RemoteInstall folder. This option works only for prestaged computers.
Automating Setup
In This Topic

Creating Unattend Files

Automating the User Interface Screens of the Windows Deployment Services client

Automating the Remaining Phases of Setup
Creating Unattend Files
To automate the entire installation you use two different unattend files: one for the Windows
Deployment Services UI screens, and one for the latter phases of Setup. Two files are necessary
because Windows Deployment Services can deploy two image types: Windows Vista images that
support the Unattend.xml format, and Windows XP and Windows Server 2003 images, which do
not support the Unattend.xml format.

Windows Deployment Services client unattend file. To automate the Windows
Deployment Services client user interface screens (such as entering credentials, choosing an
install image, and configuring the disk), create a client unattend file. This file uses the
Unattend.xml format and is stored on the Windows Deployment Services server in the
RemoteInstall\WDSClientUnattend folder. For more information, see Automating the
Windows Deployment Services client later in this topic.

Image unattend file. Image unattend files automate the remaining phases of setup (for
example, offline servicing, Sysprep specialize, and mini-setup). This file uses the
Unattend.xml or Sysprep.inf format, depending on the version of the operating system of the
image. It is stored in a subfolder (either $OEM$ structure or \Unattend) in the per-image
folder. For more information, see Automating the Remaining Phases of Setup later in this
topic.
65
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. For an example file, see Sample
Unattend Files. In addition, 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 for Running Windows Setup at
http://go.microsoft.com/fwlink/?LinkId=120686.
Automating the User Interface Screens of the
Windows Deployment Services Client
You automate the UI screens using the Windows Deployment Services client unattend file
(Unattend.xml). 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 (see “When
Setup Is Started in Windows Deployment Services Mode” in How the Windows Deployment
Services Client Works (http://go.microsoft.com/fwlink/?LinkId=147067)). The Windows
Deployment Services client processes only settings in the Windows PE section of the client
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.

You do not have an image unattend file, and the client is not configured to join a domain.
To associate a client unattend file by architecture
1. Create an Unattend.xml file with settings applicable to Windows Deployment Services
client screens. For examples of these setup tasks, see Sample Unattend Files.
2. Copy the client unattend file to a folder in the RemoteInstall folder. For example:
66
RemoteInstall\WDSClientUnattend.
3. Open the Windows Deployment Services MMC snap-in, right-click the server that
contains the Windows Vista or Windows Server 2008 image that you want to associate
the unattend file with, and then click Properties.
4. On the Client tab, select Enable unattended installation, browse to the appropriate
unattend file, and then click Open.
5. Click OK to close the Properties page.
Note
The commands for this task are: To associate a client unattend file by
architecture run WDSUTIL /Set-Server /WDSUnattend /Policy:enabled
/File:<filepath> /Architecture:<arch>. To associate a client unattend file per
computer, run WDSUTIL /Set-Device /Device:<computername> /ID:<GUID or
MAC address> /WDSClientUnattend:<relative path>
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 at Windows Unattended Setup Reference
http://go.microsoft.com/fwlink/?LinkId=120687. For examples, see Sample Unattend Files.
UI page
Component
Unattend setting
Explanation
Languageneutral page
Microsoft-WindowsInternational-CoreWindows PE
SetupUILanguage Specifies the 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
keyboard
selection
page
Microsoft-WindowsInternational-CoreWindows PE
InputLocale
Specifies the computer's input 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> value
is set to Always.
Credentials
page
Microsoft-WindowsSetup ->
WindowsDeployme
Credentials
Specifies the user name, domain, and
password of an account with proper
permissions to install the specified
67
UI page
Component
Unattend setting
ntServices -> Login
Explanation
image.
Image
selection
page
Microsoft-WindowsSetup ->
WindowsDeployme
ntServices
InstallImage
Specifies the image to be installed.
Image
selection
page
Microsoft-WindowsInternational-CoreWindows PE
UILanguage
Specifies the 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
page
Microsoft-WindowsInternational-CoreWindows PE
UILanguageFallb
ack
Specifies the language to be used if the
computer's default UI language is only
partially localized for the selected
image.
Disk
configuration
page
Microsoft-WindowsSetup ->
DiskConfiguration
Disk
Specifies the disk configuration
settings.
Disk
configuration
page
Microsoft-WindowsSetup ->
WindowsDeployme
ntServices ->
ImageSelection
InstallTo
Specifies the disk and partition to which
the selected image is to be installed.
Automating the Remaining Setup Phases
You automate the remaining phases of Setup with an image unattend file (Unattend.xml or
Sysprep.inf). For examples, see Sample Unattend Files.

Unattend.xml. For Windows Vista and Windows Server 2008 images, 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. To do this, right-click the image in the MMC snap-in that you
68
want to associate with the unattend file, and then click Properties. On the General tab, click
Allow image to install in unattend mode, click Select File, browse to select the unattend
file, and then click OK twice. The Unattend.xml file will be saved to the following location:
\RemoteInstall\Images\<imagegroup>\<imagename>\Unattend\ImageUnattend.xml.

Sysprep.inf. For images prior to Windows Vista, author Sysprep.inf by using Setup Manager
and then save these files to the $OEM$ structure of the image (for example,
D:\RemoteInstall\Images\Windows XP\winxpsp2\$OEM$\$1\sysprep\sysprep.inf). Now when
you deploy the image, Setup will automatically locate and use the Sysprep.inf file.
Automating the Domain Join
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. In
order for the join to be successful, the user account must have permissions to join the domain
and rights to create computer objects in AD DS (this is required if you are not using prestaged
computer objects).For more information, see Required Permissions.
In This Topic

Modifying Your Unattend Files

Choosing a Permissions Method
Modifying Your Unattend Files
The domain join process uses 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-WindowsShell-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
69
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.
Choosing a Permissions Method
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
<MachinePassword> setting. For images from
an earlier version of Windows, this shared
computer password is the computer name.
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.

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
the time the computer account was reset
(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
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.
To implement a secure join, do the following to
the unattend file:
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-Shell70
Unsecure join
Secure join
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.
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
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.
To automate this wizard, create a WDSCapture.inf file. Then create a capture image and save
this file within the image. To do this, mount the image using ImageX, save this file as
Windows\system32\Wdscapture.inf (overwrite the existing Wdscapture.inf), and then unmount the
image. Lastly, add the capture image to the Windows Deployment Services server. When you
boot a computer into this image, the UI screens will be automated and the image will be uploaded
to the server with the settings you have specified.
WDSCapture.inf Unattend File Settings
This section explains the format for WDSCapture.inf files. To view a sample WDSCapture.inf, see
Sample Unattend Files.
[Capture]
Contains all of the capture settings for the Image Capture Wizard, as described in the following
table.
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
71
Setting
Description
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.
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,
72
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.
Setting
Description
UploadToWDSServer=Yes|N
o
(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= Specifies whether the local capture image (where the capture
Yes|No
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).
Advanced Unattended Installation Scenarios
This topic contains information about advanced tasks that you can implement with Windows
Deployment Services.
73
In This Topic

Passing Unattend Files to Setup by Using the Command Line

Using Implicit Unattend Files

Embedding an Unattend File in an Image

Understanding Unattend File Precedence

Setting Command-Line Precedence for Unattend Files

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.
You can do this by passing /unattend:<unattend file> and /wds with Setup.exe (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. For more information about Windows
Deployment Services mode, see the “When Setup Is Started in Windows Deployment Services
Mode” section in How the Windows Deployment Services Client Works
(http://go.microsoft.com/fwlink/?LinkID=147067). 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. The following is an example
scenario:
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 appropriate 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.
74
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
at http://go.microsoft.com/fwlink/?LinkId=120686.
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 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).
Understanding Unattend File Precedence
The following table outlines the precedence for unattend files. Note that you cannot change this
precedence order.
Windows Deployment Services client unattend
Image unattend file
file
AWindows Deployment Services client
unattend file that is defined always overrides an
implicit unattend file. The order of precedence
for this file is as follows:
The order of precedence for this file is as
follows:
1. Unattend files that are passed explicitly
from the command line (for example,
2. Image unattend files in the $OEM$
structure
1. Explicitly assigned image unattend files
(Windows Vista images only)
75
Windows Deployment Services client unattend
Image unattend file
file
setup.exe /wds /unattend:<unattend
file>)
2. Unattend files that are defined on the
server
3. An implicit unattend file (AutoUnattend.xml)
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
Setting Command-Line Precedence for Image
Unattend Files
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}. Next, run one of the following:

To allow an unattend file on the client computer to override the unattend file sent from the
server, run WDSUTIL /Set-Server /WDSUnattend /CommandLinePrecedence:Yes.

To force the unattend file from the server to be used, run WDSUTIL /Set-server
/WDSUnattend /CommandLinePrecedence:No.
The following is an example 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 create a Windows Deployment Services client unattend file that creates a
single disk partition. Then you create a Windows Vista image with an image unattend file that
does not install the Bluetooth drivers and software. Next, you create a single Unattend.xml file
that performs all of the custom actions needed for laptop installations. Finally, you 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.

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
76
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 Files

Example 1: Standard installation

Example 2: Install a language pack
Image Unattend Files for Windows Vista and Windows Server 2008
77


Example 1: Unsecure domain join

Example 2: Secure domain join

Example 3: Using variables
Image Unattend Files for Older Operating Systems

Example 1: Domain join

Example 2: Using variables

Example 3: Run a script

Combined Image and Client Unattend File

Image Capture Wizard Unattend File
Note
To download the Windows Deployment Services documentation (including a getting
started guide, deployment guide, and WDSUTIL command-line syntax), see
http://go.microsoft.com/fwlink/?LinkId=89381.
Windows Deployment Services Client Unattend
Files
Example 1: Standard installation
The following file contains all of the standard attributes that are needed to automate the UI
screens. It specifies the language for the installation (<SetupUILanguage>), the credentials for
the client to access the Windows Deployment Services server (<Credentials>), and the image for
installing on the client computer (<ImageName>). It also configures the disk layout – for example,
the image will be installed on the first partition (<PartitionID>) and the first disk (<DiskID>) on the
client computer.
<?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>Fabrikam.com</Domain>
<Password>my_password</Password>
78
</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>
<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>
79
<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>
Example 2: Install a language pack
You can use the following example file to install a language pack. If the <UILanguage> is the
same as the language on the image, then Windows Deployment Services will not install a
language pack. However, if you use the following example with an English image, then (because
of <UILanguage>de-de</UILanguage>) Windows Deployment Services will look for a German
language pack on the server at C:\RemoteInstall\Images\<imagefilename>\Langpacks\de-de.
<?xml version="1.0" encoding="utf-8"?>
<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>Administrator</Username>
<Domain>Fabrikam.com</Domain>
<Password>Password1</Password>
</Credentials>
</Login>
<ImageSelection>
<WillShowUI>OnError</WillShowUI>
80
<InstallImage>
<ImageName>Windows Vista Ultimate</ImageName>
<ImageGroup>ImageGroup1</ImageGroup>
</InstallImage>
<InstallTo>
<DiskID>0</DiskID>
<PartitionID>1</PartitionID>
</InstallTo>
</ImageSelection>
</WindowsDeploymentServices>
<DiskConfiguration>
<WillShowUI>OnError</WillShowUI>
<Disk>
<DiskID>0</DiskID>
<WillWipeDisk>false</WillWipeDisk>
<ModifyPartitions>
<ModifyPartition>
<Order>1</Order>
<PartitionID>1</PartitionID>
<Letter>C</Letter>
<Label>Vista</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>
81
<UILanguage>en-US</UILanguage>
</SetupUILanguage>
<UILanguage>de-de</UILanguage>
<SystemLocale>de-de</SystemLocale>
<UserLocale>de-de</UserLocale>
</component>
</settings>
<cpi:offlineImage cpi:source="" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>
Image Unattend Files for Windows Vista and
Windows Server 2008
Example 1: Unsecure domain join
This file sets the password for the computer to a dynamically generated and shared password,
and joins the computer to a domain without credentials. The password will be inserted into this
unattend file as the <MachinePassword> value in the <Identification> section. The attributes that
define this domain join method are <UnsecureJoin>true</UnsecureJoin> and the MicrosoftWindows-Shell-Setup component. For more information about this method, see the “Ensuring
Security” section of Automating the 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>true</UnsecureJoin>
</Identification>
</component>
82
<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>
Example 2: Secure domain join
This example uses the credentials specified in this file (user name, domain, and password) to
perform the domain join. The attributes that define this domain join method are
<UnsecureJoin>false</UnsecureJoin>, <Credentials>, and the Microsoft-Windows-Shell-Setup
component. During installation, Windows Deployment Services will retrieve the name of the
prestaged account from Active Directory Domain Services (AD DS) and replace the
%MACHINENAME% string with the actual computer name. For more information about this
method, see the “Ensuring Security” section of Automating the 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.com</Domain>
<Password>Password1</Password>
<Username>MyUserName</Username>
</Identification>
</component>
83
<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>
Example 3: Using variables
In the following example, Windows Deployment Services will automatically 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 Advanced Unattended Installation Scenarios.
<?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"
84
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>
<RegisteredOrganization>%ORGNAME%</RegisteredOrganization>
</component>
</settings>
</unattend>
Image Unattend Files for Older Operating Systems
Example 1: Domain join
The following is an example Sysprep.inf file that sets the password of the computer account to
the computer name, and joins the computer to a domain without credentials.
[Identification]
DoOldStyleDomainJoin=Yes
[Networking]
[UserData]
85
Example 2: Using variables
In the following Sysprep.inf example, Windows Deployment Services will automatically replace
the %ORGNAME%, %MACHINENAME%, %TIMEZONE%, and %MACHINEDOMAIN% variables
using the proper values. For more information, see "Using Variables to Obtain Information From
the Client" in Advanced Unattended Installation Scenarios.
[UserData]
OrgName = "%ORGNAME%"
ComputerName = %MACHINENAME%
ProductKey= "XXXXX-XXXXX-XXXXX-XXXXX-XXXXX"
[GuiUnattended]
TimeZone = %TIMEZONE%
[Networking]
[Identification]
JoinDomain = %MACHINEDOMAIN%
DoOldStyleDomainJoin = Yes
Example 3: Run a script
The following is an example Sysprep.inf file that runs a script on first logon (Command0), sets the
administrator password (AdminPassword), and bypasses the Welcome screen (AutoLogon).
[GuiRunOnce]
Command0 = "set path=c:\scripts;%PATH%"
[GuiUnattended]
AutoLogon = Yes
AdminPassword = Password1!
OEMSkipRegional = 1
OemSkipWelcome = 1
TimeZone = %TIMEZONE%
86
[Identification]
JoinDomain = %MACHINEDOMAIN%
DoOldStyleDomainJoin = Yes
Combined Image and Client Unattend File
The following is a single .xml unattend file that automates the entire installation process (the
Windows Deployment Services client UI screens and the remaining phases of Setup). To use this
file, update the file with information for your environment and then configure the command-line
unattend precedence appropriately (for precedence information, see Advanced Unattended
Installation Scenarios). Then pass this file to Setup.exe with the /unattend:<unattend file> option.
<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>Administrator</Username>
<Domain>Fabrikam.com</Domain>
<Password>Password1</Password>
</Credentials>
</Login>
<ImageSelection>
<InstallImage>
<ImageName>Install Image</ImageName>
<ImageGroup>defaultx86</ImageGroup>
<Filename>install.wim</Filename>
</InstallImage>
<WillShowUI>OnError</WillShowUI>
<InstallTo>
<DiskID>0</DiskID>
<PartitionID>1</PartitionID>
</InstallTo>
87
</ImageSelection>
</WindowsDeploymentServices>
<DiskConfiguration>
<WillShowUI>OnError</WillShowUI>
<Disk>
<DiskID>0</DiskID>
<WillWipeDisk>false</WillWipeDisk>
<ModifyPartitions>
<ModifyPartition>
<Order>1</Order>
<PartitionID>1</PartitionID>
<Letter>C</Letter>
<Label>Vista</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>
<settings pass="specialize">
88
<component name="Microsoft-Windows-UnattendedJoin"
publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
processorArchitecture="x86">
<Identification>
<UnsecureJoin>true</UnsecureJoin>
</Identification>
</component>
<component name="Microsoft-Windows-Shell-Setup" publicKeyToken="31bf3856ad364e35"
language="neutral" versionScope="nonSxS" processorArchitecture="x86">
<ComputerName>computer1</ComputerName>
</component>
<component name="Microsoft-Windows-TerminalServices-RDP-WinStationExtensions"
publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
processorArchitecture="x86">
<SecurityLayer>2</SecurityLayer>
<UserAuthentication>2</UserAuthentication>
</component>
<component name="Microsoft-Windows-TerminalServices-LocalSessionManager"
publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
processorArchitecture="x86">
<fDenyTSConnections>false</fDenyTSConnections>
</component>
</settings>
<settings pass="oobeSystem">
<component name="Microsoft-Windows-Shell-Setup" publicKeyToken="31bf3856ad364e35"
language="neutral" versionScope="nonSxS" processorArchitecture="x86">
<OOBE>
<HideEULAPage>true</HideEULAPage>
<NetworkLocation>Work</NetworkLocation>
<ProtectYourPC>1</ProtectYourPC>
<SkipMachineOOBE>true</SkipMachineOOBE>
<SkipUserOOBE>true</SkipUserOOBE>
</OOBE>
<Display>
<ColorDepth>32</ColorDepth>
89
<DPI>96</DPI>
<HorizontalResolution>1024</HorizontalResolution>
<RefreshRate>60</RefreshRate>
<VerticalResolution>768</VerticalResolution>
</Display>
<UserAccounts>
<LocalAccounts>
<LocalAccount>
<Password>
<Value>Password1</Value>
<PlainText>true</PlainText>
</Password>
<Description>My Local Account</Description>
<DisplayName>John Smith</DisplayName>
<Group>Administrators;Power Users</Group>
<Name>John</Name>
</LocalAccount>
</LocalAccounts>
<DomainAccounts>
<DomainAccountList>
<DomainAccount>
<Name>Administrator</Name>
<Group>Administrators;Power Users</Group>
</DomainAccount>
<Domain>Fabrikam.com</Domain>
</DomainAccountList>
</DomainAccounts>
</UserAccounts>
</component>
</settings>
</unattend>
90
Image Capture Wizard Unattend File
The following is an example file that automates the UI screens of the Image Capture Wizard. To
use this file, first update each section with the information for your environment. For example, the
[ExclusionList] specifies the files that the capture process will exclude from capturing. Then
create a capture image and save this file within the image. To do this, mount the image using
ImageX, save this file as Windows\system32\Wdscapture.inf (overwrite the existing
Wdscapture.inf), and then unmount the image. Lastly, add the capture image to the Windows
Deployment Services server. When you boot a computer into this image, the UI screens will be
automated and the image will be uploaded to the server with the settings you have specified.
[Capture]
Unattended=Yes
VolumeToCapture=C:
SystemRoot=windows
ImageName="WindowsVista"
ImageDescription="Windows Vista ULTIMATE with Office"
DestinationFile=C:\Capture.wim
Overwrite=Yes
[ExclusionList]
$ntfs.log
hiberfil.sys
pagefile.sys
"System Volume Information"
RECYCLER
winpepge.sys
%SYSTEMROOT%\CSC
[WDS]
UploadToWDSServer=Yes
WDSServerName=WDSServer
WDSImageGroup="ImageGroup1"
Username=Username
Domain=Domain
Password=Password1
DeleteLocalWimOnSuccess=No
91
Working with Images

Creating Images

Filtering Images

Deploying Earlier Versions of Windows

Storing and Replicating Images Using DFS

Servicing Images
Creating Images
This topic contains information about the images that you use with Windows Deployment
Services.
In This Topic

Image Types

Boot Images

Discover Images

Capture Images

Converting RIPREP Images
Note
To download the Windows Deployment Services documentation (including a getting
started guide, deployment guide, and WDSUTIL command-line syntax), see
http://go.microsoft.com/fwlink/?LinkId=89381.
Image Types
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.

Boot image: The Microsoft Windows Preinstallation Environment (Windows PE) image that
you boot a client into before you install the install image. 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.
92

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
These images contain Windows PE and the Windows Deployment Services client, which is
Windows Vista Setup.exe with some additional functionality needed for network deployments. 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 Boot.wim from the version of Windows Vista that does not contain SP1,
multicasting will not work correctly.
Creating Custom Boot Images
You can also use the tools in the Windows Automated Installation Kit (AIK) to create a custom
boot image. For more information, see Windows PE Walkthroughs
(http://go.microsoft.com/fwlink/?LinkId=120691). When creating boot images, ensure that the
image is stored in .wim format, and it is marked as bootable from RAMDISK using the /boot
option with ImageX. To create custom boot image, you must manually copy the Windows Vista or
Windows Server 2008 Setup.exe binary 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 (Boot.wim contains two
Windows PE images, and the bootable image is the second image).
3. Copy all of the Setup.exe files from the \Sources folder in the mounted image to the \Sources
folder in the custom boot image.
In addition, 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, see “When Setup Is
Started in Windows Deployment Services Mode” in How the Windows Deployment Services
Client Works (http://go.microsoft.com/fwlink/?LinkID=147067). For more information about editing
WinPESHL.ini, see Include a Custom Script in a Windows PE Image
(http://go.microsoft.com/fwlink/?LinkId=120692). For information about managing and modifying
the boot menu, see Managing the Boot Menu.
Versions of Windows PE
When creating custom boot images, the version of Windows PE that you use must match or be
newer than the install image. For example, you can use Windows PE 2.1 to deploy install images
93
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.

In the past, if you were running Winnt32.exe for Setup.exe, 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.
Discover Images
Discover images are generally used in scenarios where the client cannot perform a PXE boot.
These images enable a computer to locate a Windows Deployment Services server and use it to
install an image. To create a discover image, right-click a boot image in the MMC snap-in, and
then click Create discover boot image. In most cases, you should use the Boot.wim file included
on the Windows Server 2008 DVD to create your image. For instructions, see the Windows
Deployment Services Getting Started Guide.When you create a discover images, you configure
one of the following:

Static discovery. Static discovery is when you specify 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 using a particular boot image would use the specified server. You can specify the
server when you create the discover image.

Dynamic discovery. If you do not specify the server to use when you create a discover
image, the Windows Deployment Services client will emulate 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.
94
Creating Custom Discover Images
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. For more information, see Windows PE
Walkthroughs (http://go.microsoft.com/fwlink/?LinkId=120691).
To create a discover image manually
1. In the boot image, create a temporary folder in the path pointed to by the environment
variable, %TEMP%.
2. Copy the appropriate Setup.exe 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) to the
temporary folder.
3. Create a Winpeshl.ini file in the Windows\System32 folder of the applied image with the
following section. For more information about editing WinPESHL.ini, see Include a
Custom Script in a Windows PE Image (http://go.microsoft.com/fwlink/?LinkId=120692).
[LaunchApps]
%SYSTEMROOT%\sources\setup.exe, "/wds /wdsdiscover"
or
[LaunchApps]
%SYSTEMROOT%\sources\setup.exe, "/wds /wdsdiscover /wdsserver:<server>"
See the following table for more information about these options.
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.
There are two 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:<Server Specifies the name of the Windows Deployment Services server that the
Name>
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.
95
Capture Images
Capture images are boot images that contain Windows PE and the Windows Deployment
Services Image Capture Wizard. When you boot a computer (that has been prepared with
Sysprep) into a capture image, the wizard creates an install image of the computer and saves it
as a .wim file. Then you can upload the image to the Windows Deployment Services server or
copy them to bootable media (CD, DVD, USB drive, and so on). You create capture images from
existing boot images — most commonly, the Boot.wim file from the installation media. For
instructions on creating these images, see the Windows Deployment Services Getting Started
Guide. For information about automating the wizard, see Automating the Image Capture Wizard.
Regardless of which tool you use (capture images or ImageX), the high-level process for
capturing images 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.
Comparison of ImageX and Image Capture Wizard
Capture images provide a subset of the functionality included in the ImageX /capture command.
For information, see ImageX Technical Reference
(http://go.microsoft.com/fwlink/?LinkId=120693). The following table compares these two tools.
Functionality
Image Capture
ImageX
Wizard
Captures a partial volume?
No
Yes
Captures an image that has not been prepared by using
Sysprep?
No
Yes
Uploads directly to the Windows Deployment Services server?
Yes
No
Can the process be automated?
Yes
Yes
Has a GUI?
Yes
No
Provides additional functionality beyond image capture?
No
Yes
Enables me to specify a capture exclusion list?
Yes
Yes
Captures directly to a network location without making a local
image copy?
No
Yes
96
Creating Custom Capture Images
In advanced scenarios, you can create a custom capture image.
To create a capture image manually
1. Create a temporary folder in the path 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.
Converting RIPREP Images
To convert RIPREP images, you must first upgrade your server to Windows Server 2008. For
instructions, see http://go.microsoft.com/fwlink/?LinkId=84628
Default Conversion
To convert your files, right-click the RIPREP image you want to convert in the Legacy Images
node, and then click Convert to WIM. 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 that the data in the %TEMP% folder can be removed only after the new image has been
captured.
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
97
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, see the "Install Images" section in How to Manage Images.
The append operation is much faster than a traditional capture because it does not 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 use a capture image to save the image in the Windows
image (.wim) file format. Note that 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
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 using an unattend file) the settings you specified will not be used in the
98
image that gets applied. This is because Windows Deployment Services does not support
modifications to offline images older than 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) . 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
Windows Deployment Services filters the images in the image selection page to avoid situations
where a user is allowed to install an image that is not compatible. Images are filtered by hardware
abstraction layer (HAL) and architecture.
For Windows Vista or Windows Server 2008 images, HAL filtering is not necessary because the
image contains all possible HALs (and the correct HAL is detected and put in place automatically
upon first boot). If the image is of an older 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.
Architecture filtering works as follows. For x86-based computers, you use only x86-based boot
images and x86-based install images. The images that are applicable to that architecture will be
99
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
In This Topic

Types of Servicing

Servicing an Image Offline

Reducing the Size of Images
Types of Servicing
Servicing images means updating an image that is currently available to users — for example,
adding an 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
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.
100
Windows Vista supports offline servicing of images that have been prepared with Sysprep,
whereas earlier versions of Windows do not. You can service an image offline with Package
Manager or on a running Windows operating system with OCSetup, Package Manager, or the
Windows Update Standalone Installer. Package Manager works only with operating system
packages (hotfixes, updates, drivers, service packs, and language packs). All of these are
command-line tools can install and uninstall packages. Service packs and other updates that are
delivered as .msu files must be installed online on a running Windows installation with the
Windows Update Standalone Installer. For more information, see Servicing an Image
(http://go.microsoft.com/fwlink/?LinkId=122507).
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. To do this, right-click the image and click Disable. This allows
currently connected clients to finish applying the image, but it prevents new clients from
starting an installation.
2. Export the image to a location outside of the image store. To do this, right-click the image
and click Export. 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. To save space, you can also use the WDSUTIL /Export-Image command to
append the images to an existing .wim file. This is also generally faster than exporting it to a
new .wim file. For more information about this command, see /export-Image.
3. Service the image. In this step, you update the image 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. You can also load the registry hive to add, delete, or modify registry
keys. If the image is a boot image, you 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. For more
information, see the following topics:

Phase 5: Image Maintenance (http://go.microsoft.com/fwlink/?LinkId=120703)

Package Manager Technical Reference (http://go.microsoft.com/fwlink/?LinkId=120704)

Add Device Drivers to an Offline Windows Image
(http://go.microsoft.com/fwlink/?LinkId=120705)

Install a Language Pack to an Offline Image
(http://go.microsoft.com/fwlink/?LinkID=120685)
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,
you have two options:

Wait for existing installations to complete, delete the old copy, and then replace it with the
new. To do this, right-click the image and click Replace. 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.
101

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.
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.
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 Active Directory Domain Services (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:

Distributed File Systems Step-By-Step Guide (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 a 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.
102

Simplified administration. When you use DFS replication technology, you can modify
images on a single server and propagate changes to other distribution points.
Note
You cannot redirect the boot directory (that is, \\<server>\reminst\boot) using DFS. If you
do, Windows Deployment Services will not start.
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 domainbased namespace.
5. Add a new folder to the namespace and create an image group on the Windows
Deployment Services server as the target folder. 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.
8. Repeat this procedure for additional image groups.
Replicating Images
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).
103
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 Distributed File Systems Step-By-Step Guide
(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 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. 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 the server

Start/stop or enable/disable a server
104
Category
Example tasks

Update the RemoteInstall folder

Set advanced server settings

Create and delete prestaged accounts in Active Directory
Domain Services (AD DS)

View information about prestaged computers

Configure settings for prestaged computers

Reject/approve pending computers

View information about images and image groups

Create 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

Create multicast transmissions

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 Client
Computers
How to Manage Images
How to Manage Your Server
This section contains procedures for the tasks that are listed and described in the following table.
Note that you cannot manage a Windows Deployment Services server running Windows
Server 2008 from a Windows Deployment Services server running Windows Server 2003.
Note
To download the Windows Deployment Services documentation (including a getting
started guide, deployment guide, and WDSUTIL command-line syntax), see
http://go.microsoft.com/fwlink/?LinkId=89381.
105
Note
Help for WDSUTIL is available by typing WDSUTIL /? at a command prompt or online at
http://go.microsoft.com/fwlink/?LinkId=112194.
Type
Procedure
General Tasks

To configure Windows Deployment Services

To start or stop the server

To enable the server

To enable logging for the Windows Deployment Services client

To choose the port number for RPC

To specify the network interfaces for Windows Deployment Services 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

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

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

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 each architecture

To specify a domain controller for Windows Deployment Services

To specify a global catalog server for Windows Deployment Services

To choose whether to search for computer accounts in the domain
DHCP
Client Requests
Client Boot
Settings
Active Directory
Domain
Services
106
Type
Procedure
controller before searching the global catalog
Unattend File

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

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
General Tasks
To configure Windows Deployment Services
Using the MMC
Using WDSUTIL
1. Install Windows Deployment Services. For
more information, see the Windows
Deployment Services Getting Started
Guide.
1. Install Windows Deployment Services. For
more information, see the Windows
Deployment Services Getting Started
Guide.
2. Click Start, click Administrative Tools,
and then click Windows Deployment
Services.
2. Click Start, right-click Command Prompt,
click Run as administrator, and then run
3. In the left pane of the Windows Deployment
Services snap-in, right-click the server and
then click Configure Server.
WDSUTIL /Verbose /Progress /InitializeServer /RemInst:<path>,
where <path> is
the path where you would like the
RemoteInstall folder to be located.
4. Follow the instructions in the wizard.
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.
107
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
Tasks.
1. Click Start, right-click Command Prompt,
and click Run as administrator.
2. Click Stop Server or Start Server.
2. Run WDSUTIL /Start-Server or WDSUTIL
/Stop-Server.
The preceding procedure starts or stops the WDSServer service.
To enable the server
Using the MMC
Using WDSUTIL
N/A
1. Click Start, right-click Command Prompt, and click Run as
administrator.
2. Run WDSUTIL /Enable-Server.
The preceding procedure starts or stops the WDSServer service.
To enable logging for the Windows Deployment Services client
Using the MMC
Using WDSUTIL
N/A
1. Click Start, right-click Command Prompt, and click Run as
administrator.
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).
108
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. Click Start, right-click Command Prompt, and click Run as
administrator.
2. Run WDSUTIL /Set-Server /RPCPort:X, where X is the RPC port number
you want to use.
3. You must restart the service before the changes will take effect. To do
this, run wdsutil /stop-server and then run wdsutil /start-server.
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 Windows Deployment
Services to listen on
Using the MMC
Using WDSUTIL
N/A
1. Click Start, right-click Command Prompt, and click Run as
administrator.
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 /SetServer /BindPolicy /Policy:Exclude.
109
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)
To configure how often the server refreshes its settings
Using the MMC
Using WDSUTIL
N/A
1. Click Start, right-click Command Prompt, and click Run as
administrator.
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. Click Start, right-click Command Prompt, and click Run as
administrator.
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.
1. Click Start, right-click Command Prompt,
and click Run as administrator.
2. On the Network Settings tab under
Network Profile, select the option that
specifies the network speed of your
organization.
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:
110
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:

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.
1. Click Start, right-click Command Prompt,
and click Run as administrator.
2. On the DHCP tab, select Do not listen on
port 67 and Configure DHCP Option #60
Tag to PXEClient.
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.
111
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
Properties.
1. Click Start, right-click Command Prompt,
and click Run as administrator.
2. On the DHCP tab, select Do not listen on
port 67.
2. Run WDSUTIL /Set-Server
/UseDHCPPorts:No.
3. Use your DHCP server tools to set the
option 60 tag to PXEClient.
3. Use your DHCP server tools to set the
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
N/A
1. Click Start, right-click Command Prompt, and click Run as
administrator.
2. Run WDSUTIL /Set-Server /RogueDetection:Yes.
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 are a domain administrator in
the root domain of the forest or an enterprise
administrator. For information about delegating
permissions, see “Authorizing a Server” in the
Configuring DHCP topic.
1. Ensure that you are a domain administrator
in the root domain of the forest or an
enterprise administrator. For information
about delegating permissions, see
“Authorizing a Server” in the Configuring
DHCP topic.
2. Right-click the server, and then click
Properties.
3. On the Advanced tab, select Authorize the
Windows Deployment Server in DHCP.
2. Click Start, right-click Command Prompt,
and click Run as administrator.
3. Run WDSUTIL /Set-Server /Authorize:Yes.
112
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.
Client Requests
To configure the server to answer clients
Using the MMC
Using WDSUTIL
1. Right-click the server, and then click
Properties.
1. Click Start, right-click Command
Prompt, and click Run as
administrator.
2. On the PXE Response Settings tab, do one of
the following:
2. Do one of the following:

To respond to all client PXE requests,
select Respond to all (known and
unknown) client computers.

To respond to all clients’ PXE
requests, run WDSUTIL /Set-Server
/AnswerClients:All.

To respond only to prestaged client PXE
requests, select Respond only to the
known client computers.

To respond only to prestaged
clients’ PXE requests, run WDSUTIL
To not answer any client PXE requests,
select Do not respond to any client
computer. Note that this option will only
work if Windows Deployment Services and
DHCP are running on different servers.
This is because although Windows
Deployment Services will not respond,
DHCP will. You can try to work around this
issue by disabling DHCP Option 60 on the
DHCP tab.


/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.
113
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.
1. Click Start, right-click Command Prompt,
and click Run as administrator.
2. On the PXE Response Settings tab, set
the PXE Response delay in the control.
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.
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. Click Start, right-click Command Prompt, and click Run as
administrator.
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. Click Start, right-click Command Prompt,
and click Run as administrator.
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.
114
To configure the server to determine the architecture of booting
clients
Using the MMC
Using WDSUTIL
N/A
1. Click Start, right-click Command Prompt, and click Run as
administrator.
2. Run WDSUTIL /Set-Server /ArchitectureDiscovery:Yes.
The preceding procedure sets the value of
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE\Providers\BINLSVC\DisableArchDisc to 0.
Client Boot Settings
To choose which boot images are displayed on x64-based
computers
Using the MMC
Using WDSUTIL
N/A
1. Click Start, right-click Command Prompt, and click Run as
administrator.
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 click
Properties.
1. Click Start, right-click Command Prompt,
and click Run as administrator.
2. On the Boot tab, insert the path to the boot
file you want to use for each architecture.
For a list of network boot programs, see
Managing Network Boot Programs.
2. Run WDSUTIL /Set-Server
/BootProgram:<path>
/Architecture:{x86|x64|ia64},
where <path>
is relative to the RemoteInstall folder.
115
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. Click Start, right-click Command Prompt, and click Run as
administrator.
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 Properties.
1. Click Start, right-click
Command Prompt, and
click Run as
administrator.
2. On the Boot tab, insert the path to the boot image you want
to use for each architecture. 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.
2. Run WDSUTIL /Set-Server
/BootImage:<path>
/Architecture:{x86|x64|i
a64},
where <path> is
relative to the
RemoteInstall folder.
The preceding procedure sets
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS
PXE\Providers\BINLSVC\BootImages\<arch>\BootImagePath to the specified path.
116
Active Directory Domain Services
To specify a domain controller for Windows Deployment
Services
Using the MMC
Using WDSUTIL
1. Right-click the server, and then click
Properties.
1. Click Start, right-click Command Prompt,
and click Run as administrator.
2. On the Advanced tab, click Let Windows
Deployment Services use only the
specified servers, and then enter the
domain controller name.
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 Windows Deployment
Services
Using the MMC
Using WDSUTIL
1. Right-click the server, and then click
Properties.
1. Click Start, right-click Command Prompt,
and click Run as administrator.
2. On the Advanced tab, click Let Windows
Deployment Services use only the
specified servers and then enter the
Domain controller name.
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. Click Start, right-click Command Prompt, and click Run as
administrator.
117
Using the MMC
Using WDSUTIL
2. Do one of the following:

To search in the domain controller before searching the Global Catalog
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
3. 1.
Click Start, right-click Command Prompt, and click Run as
administrator.
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. Click Start, right-click Command Prompt, and click Run as administrator.
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 /GUID:<GUID>.
Note
The GUID string should be specified without brackets or dashes
(as seen during a PXE boot).
118
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.
1. Click Start, right-click Command Prompt,
and click Run as administrator.
2. On the Directory Services tab, enter the
naming policy string in the indicated field
(see below for details).
2. Run WDSUTIL /Set-Server
where
<policy> is the naming policy string (see
below for details).
/NewMachineNamingPolicy:<Policy>
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.
To specify the domain and OU in which to create computer
accounts
119
Using the MMC
Using WDSUTIL
1. Right-click the server,
and then click
Properties.
1. Click Start, right-click Command Prompt, and click Run as
administrator.
2. On the Directory
Services tab, click
Default Directory
Service location or
specify the domain and
organizational unit (OU)
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 /SetServer /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
Properties.
1. Click Start, right-click Command Prompt,
and click Run as administrator.
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.
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.
120
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.
1. Click Start, right-click Command Prompt,
and click Run as administrator.
2. On the Client tab, select the Enable client
unattend check box and then choose an
unattend file for the relevant architecture.
2. To turn on unattended installation and
specify the unattend file, run WDSUTIL /SetServer /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. Click Start, right-click Command Prompt, and click Run as
administrator.
2. Do one of the following:

To allow an unattend file on the 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.
121
How to Manage Client Computers
This topic contains procedures for the tasks that are listed and described in the following table.
Help for WDSUTIL is available by typing WDSUTIL /? at a command prompt or online at
http://go.microsoft.com/fwlink/?LinkId=112194.
Type
Procedure
Prestage
Computers

To prestage a client computer

To prestage a client computer to boot from a different server

To prestage a client computer to use a network 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

To view the attributes of a prestaged client

To enable the Auto-Add policy

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 change the rate at which pending 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 network 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 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
Configure the
Auto-Add
Policy
Specify
Settings for
Pending
Computers
Approve and
Reject
Pending
Computers
122
Prestage Computers
To prestage a client computer
Using the Active Directory Users and Computers snap-in Using WDSUTIL
1. On the server running Active Directory Users and
Computers, open the Active Directory Users and
Computers MMC snap-in (click Start, click Run,
type dsa.msc, and then click OK).
Note
To manage the server remotely, you can
install “AD DS Snap-Ins and CommandLine Tools” in the Remote Server
Administration Tools. To do this, click Add
Features in Server Manager, and install
the feature from the following location:
Remote Server Administration
Tools>Remote Administration Tools>AD DS
and AD LDS Tools>AD DS Tools>AD DS
Snap-Ins and Command-line Tools.
2. In the console tree, right-click the organizational
unit that will contain the new client computer.
3. Click New, and then click Computer.
4. Type the client computer name, click Next, and
then click This is a managed computer.
5. In the text box, type the client computer's MAC
address preceded with twenty zeros or the globally
unique identifier (GUID) in the format:
{XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXXXXX}.
1. Click Start, right-click Command
Prompt, and click Run as
administrator.
2. Run WDSUTIL /Add-Device
/Device:<name> /ID:<GUIDorMACAddress>
where <GUIDorMACAddress> is the
identifier of the new computer. If you use
a MAC address, you must precede it
with twenty zeros (0).
For example: WDSUTIL /Add-Device
/Device:Computer1
/ID:{E8A3EFAC-201F-4E69-953FB2DAA1E8B1B6}
/ReferralServer:WDSServer1
/BootProgram:boot\x86\pxeboot.com
/WDSClientUnattend:WDSClientUnatt
end\unattend.xml
/User:Domain\MyUser
/JoinRights:Full
/BootImagePath:boot\x86\images\boo
t.wim
/OU:"OU=MyOU,CN=Test,DC=Domain
,DC=com"
6. Click Next, and click one of the following options
to specify which server or servers will support this
client computer:

Any available remote installation server

The following remote installation server
7. Click Next, and then click Finish.
123
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. Click Start, right-click Command Prompt,
and click Run as administrator.
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 network boot program
other than the default
Using the MMC
Using WDSUTIL
N/A
1. Click Start, right-click Command Prompt,
and click Run as administrator.
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. Click Start, right-click Command Prompt, and click Run as
administrator.
2. Run WDSUTIL /Set-Device /Device:<name> /WDSClientUnattend:<path>,
where the path is relative to the unattend file you want from the
RemoteInstall folder.
124
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. Click Start, right-click Command Prompt, and click Run as
administrator.
2. Run WDSUTIL /Set-Device /Device:<name> /BootImagePath:<path>, where
<path> is the relative path to the boot image you want from the
RemoteInstall folder.
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. Click Start, right-click Command Prompt, and click Run as
administrator.
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.
125
To view the attributes of a prestaged client
Using the MMC
Using WDSUTIL
N/A
1. Click Start, right-click Command Prompt, and click Run as administrator.
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.
Configure the Auto-Add Policy
For more information about the Auto-Add policy, see Enabling the Auto-Add Policy at Prestaging
Client Computers
To enable the Auto-Add policy
Using the MMC
Using WDSUTIL
1. Right-click the server, and then click Properties.
1. Click Start, right-click
Command Prompt, and click
Run as administrator.
2. On the PXE Response settings tab, click Respond
to all (known and unknown) client computers.
3. Select the check box For unknown clients, notify
administrator and respond after approval.
2. Run WDSUTIL /Set-Server
/AutoAddPolicy
/Policy:AdminApproval.
The preceding procedure sets
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers
\BINLSVC\AutoApprove\Policy
to 1.
126
To change the length of time approved computers are held in the
Auto-Add database
Using the MMC
Using WDSUTIL
N/A
1. Click Start, right-click Command Prompt, and click Run as
administrator.
2. Run WDSUTIL /Set-Server /AutoAddPolicy /RetentionPeriod
/Approved:<time in days>.
The preceding procedure sets
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\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. Click Start, right-click Command Prompt, and click Run as
administrator.
2. Run WDSUTIL /Set-Server /AutoAddPolicy /RetentionPeriod
/Others:<time in days>.
The preceding procedure sets
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers
\BINLSVC\AutoApprove\OtherRetention
to the specified number.
To delete the approved or rejected computers table
Using the MMC
Using WDSUTIL
N/A
1. Click Start, right-click Command Prompt, and click Run as
administrator.
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.
127
Specify Settings for Pending Computers
To change the rate at which pending computers will poll the
server
Using the MMC
Using WDSUTIL
N/A
1. Click Start, right-click Command Prompt, and click Run as
administrator.
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\WDSPXE\Providers
\BINLSVC\AutoApprove\PollInterval
to the specified time.
To change the number of times pending computers will poll the
server
Using the MMC
Using WDSUTIL
N/A
1. Click Start, right-click Command Prompt, and click Run as
administrator.
2. Run WDSUTIL /Set-Server /AutoAddPolicy /MaxRetry:<retries>.
The preceding procedure sets
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers
\BINLSVC\AutoApprove\PollMaxRetry
to the specified value.
To change the message displayed to pending computers
Using the MMC
Using WDSUTIL
N/A
3. 1.
Click Start, right-click Command Prompt, and click Run as
administrator.
2. Run WDSUTIL /Set-Server /AutoAddPolicy /Message:<message>.
This procedure sets
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers
\BINLSVC\AutoApprove\PollMessage
to the specified message.
128
To set a default network boot server for pending computers
Using the MMC
Using WDSUTIL
N/A
1. Click Start, right-click Command Prompt, and click Run as
administrator.
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\WDSPXE\Providers
\BINLSVC\AutoApprove\<architecture>\ReferralServer
to the specified server name.
To set a default network boot program for pending computers
Using the MMC
Using WDSUTIL
N/A
1. Click Start, right-click Command Prompt, and click Run as
administrator.
2. Run WDSUTIL /Set-Server /AutoAddSettings
/Architecture:{x86|x64|ia64} /BootProgram:<path>,
where the <path>
is relative to the RemoteInstall folder.
The preceding procedure sets
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers
\BINLSVC\AutoApprove\<architecture>\BootProgramPath
to the specified path.
To set a default unattend file for pending computers
Using the MMC
Using WDSUTIL
N/A
1. Click Start, right-click Command Prompt, and click Run as
administrator.
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\WDSPXE\Providers
\BINLSVC\AutoApprove\<architecture>\WdsUnattendFilePath
to the specified path.
129
To set a default boot image for pending computers
Using the MMC
Using WDSUTIL
N/A
1. Click Start, right-click Command Prompt, and click Run as
administrator.
2. Run WDSUTIL /Set-Server /AutoAddSettings
/Architecture:{x86|x64|ia64} /BootImage:<path>,
where <path> is
relative to the RemoteInstall folder.
The preceding procedure sets
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers
\BINLSVC\AutoApprove\<architecture>\BootImagePath
to the specified path.
To set domain join options for pending computers
Using the MMC
Using WDSUTIL
N/A
1. Click Start, right-click Command Prompt, and click Run as
administrator.
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\Pr
oviders\BINLSVC\AutoApprove\<architecture>\JoinRights
to 0 if Join Only and 1 if Full


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Pr
oviders\BINLSVC\AutoApprove\<architecture>\JoinDomain
to 1.
130
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. Click Start, right-click Command Prompt,
and click Run as administrator.
2. Select the Pending Devices node.
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. Click Start, right-click Command Prompt,
and click Run as administrator.
2. Right-click the computer you want to
approve, and then click Approve.
2. Run WDSUTIL /Approve-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. Click Start, right-click Command Prompt,
and click Run as administrator.
2. Click Approve All.
2. Run WDSUTIL /Approve-AutoAddDevices
/RequestID:All.
The preceding procedure approves the computers. For more information, see Prestaging Client
Computers.
131
To approve a pending computer, but change a setting
Using the MMC (name
Using WDSUTIL
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.
1. Click Start, right-click Command Prompt, and click Run as
administrator.
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 network 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>.
The preceding procedure approves the computer, with the configured settings. For more
information, see Prestaging Client Computers.
To approve all pending computers, but change a setting
Using the MMC
Using WDSUTIL
N/A
1. Click Start, right-click Command Prompt, and click Run as
administrator.
2. Run WDSUTIL /Approve-AutoAddDevices /RequestID:All
132
Using the MMC
Using WDSUTIL
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 the 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 network 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
Using the MMC
Using WDSUTIL
1. Select the Pending
Devices node.
1. Click Start, right-click Command Prompt, and click Run as
administrator.
2. Right-click the
computer, and then
click Reject or
Reject All.
2. Do one of the following:

To reject a single computer, run WDSUTIL /RejectAutoAddDevices /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.
133
How to Manage Images
This topic contains procedures for the tasks that are listed and described in the following table.
Note
Help for WDSUTIL is available by typing WDSUTIL /? at a command prompt or online at
http://go.microsoft.com/fwlink/?LinkId=112194.
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

To add a boot image to the server

To set attributes on a boot image

To display the attributes of a boot image

To create a capture image

To create a discover image

To add an install image

To set the attributes on an install image

To display the attributes on an install image

To convert an RIPREP image to a .wim install image

To make a copy of an install image within an image group

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
Boot Images
Install Images
Image Groups
General Tasks
To export an image from the server to a stand-alone .wim file
134
Using the MMC
Using WDSUTIL
1. Right-click a boot or
install image, and then
click Export Image.
1. Click Start, right-click Command Prompt, and click Run as
administrator.
2. In the dialog box,
choose a file name to
export the image to.
2. Do one of the following:

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>.
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
135
Using the MMC
Using WDSUTIL
1. Right-click a boot or
install image, and
then click Replace
Image.
1. Click Start, right-click Command Prompt, and click Run as
administrator.
2. Do one of the following:

To replace a boot image, run WDSUTIL /Verbose /Progress
2. Browse to the
updated version.
/Replace-Image /Image:<name> /ImageType:Boot
3. Click through the rest
of the wizard.
/ImageFile:<path>.
/Architecture:{x86|x64|ia64} /ReplacementImage

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.
To remove an image
Using the MMC
Using WDSUTIL
1. Right-click a boot or
install image.
1. Click Start, right-click Command Prompt, and click Run as
administrator.
2. Click Delete.
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.
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
136
Using the MMC
Using WDSUTIL
1. Right-click the Boot Images node, and then click Add Boot
Image.
1. Click Start, right-click
Command Prompt, and
click Run as
administrator.
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
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.
2. Run WDSUTIL /Verbose
/Progress /Add-Image
/ImageFile:<path>
/ImageType:Boot,
where
the path is a full path to
the image file.
4. Review the choices, and then click Next.
The preceding procedure does the following:

Copies the boot image file to the folder \RemoteInstall\Boot\architecture\Images.

Generates a Boot Configuration Data (BCD) store for the boot image in the folder
\RemoteInstall\Boot\ architecture \Images.

Generates a combined BCD store for the architecture in folder \RemoteInstall\Boot\
architecture.

Extracts the required files for Pre-Boot 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 attributes on a boot image
Using the MMC
Using WDSUTIL
1. Right-click a boot
1. Click Start, right-click Command Prompt, and click Run as
image, and then click
administrator.
Disable to take the
2. Do one of the following:
image offline.
 To take the image offline, run WDSUTIL /Set-Image
2. Right-click the
/Image:<name> /ImageType:Boot /Architecture:<arch>
image, and then click
/Enabled:No.
Properties.
 To change the name and description, run WDSUTIL /Set-Image
3. Enter the name and
/Image:<name> /ImageType:Boot /Architecture:<arch>
description.
/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.
137

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. Click Start, right-click Command Prompt,
and click Run as administrator.
2. Click Properties.
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
Using the MMC
Using WDSUTIL
1. In the Windows Deployment Services MMC snap-in, expand
the Boot Images node.
1. Click Start, right-click
Command Prompt, and
click Run as
administrator.
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.
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.
2. Run WDSUTIL /NewCaptureImage
/Image:<source boot
image name>
/Architecture:{x86|ia64|
x64} /DestinationImage
/FilePath:<file path>,
where the file path is the
path and name for the
capture image.
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.
138
To create a discover image
Using the MMC
Using WDSUTIL
1. In the Windows Deployment Services MMC
snap-in, expand the Boot images node.
1. Click Start, right-click Command Prompt,
and click Run as administrator.
2. Right-click the image you want to use as a
discover image. In most cases, this should
be the Boot.wim file from the \Sources
directory of the installation DVD.
2. Run WDSUTIL /New-DiscoverImage
3. Click Create Discover Boot Image.
4. Follow the instructions in the wizard, and
when it is completed, click Finish.
/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>.
Install Images
To add an install image
Using the MMC
Using WDSUTIL
1. Right-click the image
group, and then click
Add Install Image.
1. Click Start, right-click Command Prompt, and click Run as
administrator.
3. Select the file to add.
3. Run WDSUTIL /Verbose /Progress /Add-Image /ImageFile:<path
to .wim file> /ImageType:Install.
2. To create an image group, run WDSUTIL /Add-ImageGroup
2. Select an image group.
/ImageGroup:<image group name>.
4. Proceed through the
rest of the wizard.
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 metadataonly .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.
139
Using the MMC
Using WDSUTIL
1. Right-click an install image, and then either
click Disable to take the image offline or
click Enable to bring it back online.
1. Click Start, right-click Command Prompt,
and click Run as administrator.
2. Run WDSUTIL /Set-Image Image:<name>
2. On the Action menu, click Properties.
/ImageType:Install /ImageGroup:<image
3. Enter the name and description in the
appropriate text boxes.
group name> /Name:<name>
4. Check Allow image to install in
unattended mode, and then select a file to
associate an unattend file with the install
image.
/Description:<description>
/UserFilter:<SDDL> /Enabled:{Yes|No}
/UnattendFile:<path>.
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
Using the MMC
Using WDSUTIL
1. Right-click the image.
1. Click Start, right-click Command Prompt, and click Run as
administrator.
2. Click Properties.
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.
140
Using the MMC
Using WDSUTIL
1. Click the Legacy
Images node.
1. Click Start, right-click Command Prompt, and click Run as
administrator.
2. Right-click the
RIPREP image
you want to
convert, and then
click Convert to
WIM.
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:
3. Enter the name,
description, path,
and file name, and
then click Next.

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.
To make a copy of an install image
Using the MMC
Using WDSUTIL
N/A
1. Click Start, right-click Command Prompt, and click Run as
administrator.
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
141
Using the MMC
Using WDSUTIL
1. Right-click image group.
1. Click Start, right-click Command Prompt, and click Run as
administrator.
2. Click Delete.
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, and
then click Add Image Group.
1. Click Start, right-click Command Prompt,
and click Run as administrator.
2. Enter the name for the image group.
2. Run WDSUTIL /Add-ImageGroup
/ImageGroup:<image group name>.
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.
1. Click Start, right-click Command Prompt, and click Run as
administrator.
2. Right-click image
group, and then
click Security.
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.
142
To display information about all images in an image group
Using the MMC
Using WDSUTIL
1. Select an image group.
1. Click Start, right-click Command Prompt, and click Run
as administrator.
2. View the images in the right
pane.
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.
In This Topic

When to Implement Multicasting

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.
When to Implement Multicasting
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.
143
Consider implementing multicasting if your
Multicasting might not optimize your
organization:
installations if your organization:

Has network routers that support
multicasting.

Has network routers that do not support
multicasting.

Is a large company that requires many
concurrent client installations.

Does not have bandwidth overload
problems.

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).

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.)

Has enough disk space on client computers
for the image to be downloaded.

Meets the requirements listed in the
following section.
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.
144

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.

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. Note that 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.

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 rightclicking it and then clicking Start.
145
Consider using Auto-Cast if:
Consider using Scheduled-Cast if:


You work for a smaller organization or an organization
where network traffic is an issue during the day. This way,
you can set installations to occur during nonpeak hours or
at night.

To reduce the total time of the transmission. Because you
can set multiple clients to start at the same time, the time
will be reduced because Windows Deployment Services
will not have to resend a part of the image to clients that
started after the first client.

You do not want the transmission to start until you
manually start it (to do this, clear both check boxes when
you create the transmission).

You work for a large
corporation or an
organization with high
bandwidth that can handle
installations at any time.
You do not want customers
to have to wait for the
installation to begin.
To create a multicast transmission with
Deployment Server
Using the MMC
Using WDSUTIL
Do one of the
following:
1. Click Start, right-click Command Prompt, and click Run as
administrator.

2. Do one of the following:

Right-click the
Multicast
Transmission
node, and then
click Create
Multicast
Transmission.
Right-click an
image, and then
click Create
Multicast
Transmission.
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>]
To manage transmissions
146
Using the MMC





Using WDSUTIL
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.
To start the transmission
Syntax: WDSUTIL /StartMulticastTransmission /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.

Deactivate the transmission. If you rightclick the transmission and then click
Deactivate, each client that is currently
installing will continue, but no new clients

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.
To delete the transmission
Syntax: WDSUTIL /RemoveMulticastTransmission /Image:<image
name> /ImageType:Install
/ImageGroup:<image group name> /Force
To deactivate the transmission
Syntax: WDSUTIL /RemoveMulticastTransmission /Image:<image
name> /ImageType:Install
/ImageGroup:<image group name>
To view the transmission's properties
Syntax: WDSUTIL /GetMulticastTransmission /Image:<image
name> /ImageType:Install
/ImageGroup:<image group name>
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
147
Using the MMC
Using WDSUTIL




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.
Syntax: WDSUTIL /GetMulticastTransmission /Image:<image
name> /ImageType:Install
/ImageGroup:<image group name>
/show:clients

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
click Bypass multicast.
To view clients and see progress
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 transfer
the image by using unicasting
Syntax: WDSUTIL /Disconnect-Client
/ClientID:<id>

To view the client <id> for each
transmission
Syntax: WDSUTIL /GetMulticastTransmission /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
148
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.
1. Click Start, right-click Command Prompt,
and click Run as administrator.
2. On the Network Settings tab, specify the
UDP port range.
2. Run WDSUTIL /Set-Server
3. You must restart the service before the
changes will take effect. To do this, rightclick the server in the MMC snap-in, click
All Tasks, and then click Restart.
[/Server:<name>] /Transport /StartPort:x
/EndPort:y.
3. You must restart the service before the
changes will take effect. To do this, run
wdsutil /stop-server and then run wdsutil
/start-server.
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.
149
Using the MMC
Using WDSUTIL
1. Right-click the server, and then click
Properties.
1. Click Start, right-click Command Prompt,
and click Run as administrator.
2. On the Network Settings tab under
Multicast IP Address, select one of the
following:
2. Do 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.
3. You must restart the service before the
changes will take effect. To do this, rightclick the server in the MMC snap-in, click
All Tasks, and then click Restart.
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.
3. You must restart the service before the
changes will take effect. To do this, run
WDSUTIL /stop-server and then run WDSUTIL
/start-server.
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 /Get150
MulticastTransmission /Show-clients. Note that there may be as many master clients as the
server has network adapters.
' -------------Times are in milliseconds
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"
151
hostname = "localhost"
else
hostname = WScript.Arguments.Item(0)
end if
' 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
152
loopAndKick()
wscript.sleep(sleepTime)
loop
end sub
' ---------------------------------- 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
153
' 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
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
154
' 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
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")
155
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
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)
156
' Get all clients for this session
Set ClientCollection = session.RetrieveClients()
wscript.echo "
Session ID: " + CStr(session.id) + ",
NIC Name: " + session.NetworkInterfaceName &_
+ ", 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
157
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
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).
Note
Note that when you modify the BCD store, you must force it to be recreated in order for
your changes to take effect. To do this, either restart the WDSServer service (run wdsutil
/stop-server and then run wdsutil /start-server) or run Sc control wdsserver 129.
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
158

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-7D7146A1-AE8A704480979281}.bcd
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}
159
debugtype
Serial
debugport
1
baudrate
115200
Device options
-------------identifier
{68d9e51c-a129-4ee1-9725-2ab00a957daf}
ramdisksdidevice
boot
ramdisksdipath
\Boot\Boot.SDI
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)
-------------------------------160
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 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:
161
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
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:
162
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-a1294ee1-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:
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-a1294ee1-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.
163
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)
-------------------------------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
164
<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
------------------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 {06689f95f69c-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 {06689f95165
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
support UI redirection. The first class of computers is generally EFI-based, typically Itaniumbased 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
166
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
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
167
{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
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 {06689f95f69c-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 {06689f95f69c-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
168
Troubleshooting

Troubleshooting Performance Problems

Common Problems

Logging and Tracing

Network Ports Used

Required Permissions
Troubleshooting Performance Problems
This topic contains information about analyzing blockages during each phase of an image
installation. For more information, see Optimizing Performance and Scalability.
In This Topic


Analyzing Blockages in Each Phase of Installation

PXE Boot Phase

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.
169
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. For this reason, 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.
Note

TFTP block size

Other network conditions (such as workload, the quality of the hardware 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, 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.
170

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
the 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.
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:

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). For instructions, see Creating Images. Ensure this image has
been prepared by using PEIMG.exe /prep. For more information, see PEImg Command-Line
Options (http://go.microsoft.com/fwlink/?LinkId=120707).

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. For more information, see ImageX Command-Line Options
(http://go.microsoft.com/fwlink/?LinkId=120708).

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>. For
more information, see ImageX Command-Line Options
(http://go.microsoft.com/fwlink/?LinkId=120708).

In situations where a server is overburdened, use PXE boot referrals to direct booting clients
to different PXE servers for TFTP downloads. For more information, see Managing Network
Boot Programs.

Alter your physical network topology by doing one or more of the following:

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).
171

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 and Scalability. 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.

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
172
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

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.
173

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
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.
174



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).
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:
175

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 PXE boot.
The client computer obtains an IP address but then fails to download a network
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 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.
Troubleshooti
ng 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.
Multicasting

My multicast transmissions are running very slowly.

After enabling multicasting, there is excessive traffic on the network.
176
Performing PXE Boots on Client Computers
I am unable to perform PXE boots on client computers.
The most common causes for this issue are:

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
Windows Deployment Services Getting Started Guide.

The services for Windows Deployment 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, purge the database using the steps in Prestaging Client Computers topic.

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 /deleteAutoAddDevices /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.

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 /getdevice /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 Configuring
DHCP.
177
When I perform a PXE boot and select a boot image, I see a command
prompt.
If you do not see the UI from Setup.exe 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 PXE boot.
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.

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 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.
178
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 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. 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.
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.
179
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
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:
180

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 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 Sysprepwas run.
181

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.
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
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.
182
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.
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.
Note
You should close the Windows Deployment Services MMC snap-in when you run a
WDSUTIL command. If the snap-in is open, the trace logs may not contain messages for
some actions.
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 the Windows
Deployment
Services server

WDSUTIL /get-server /show:all /detailed

Windows Application log in Event Viewer

Windows System log in Event Viewer
Server

WDSUTIL /get-server /show:all /detailed
183
Component
Obtain and review this output:
components

Windows Application log in Event Viewer

Windows System log in Event Viewer

Deployment Services Diagnostics logs in Event Viewer. To locate these
logs, expand Applications and Services Logs, expand Microsoft,
expand Windows, and then expand Deployment-Services-Diagnostics.
The Admin node contains all errors, and the Operational node contains
information messages.

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
components

Enable tracing in the management and MMC snap-in components by
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
184
Component
Obtain and review this output:
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.
Windows
Deployment
Services client
Logging in the Windows Deployment Services client serves two purposes.
First, it allows you to determine if a particular client failed during installation,
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:


Deployment Services Diagnostics logs in Event Viewer. To locate
these logs, click Applications and Services Logs, click Microsoft, click
Windows, and then click Deployment-Services-Diagnostics. The Admin
node contains all errors, and the Operational node contains information
messages. Note that in both of these logs, the architectures listed for some
errors mean the following:

Architecture 0 means x86

Architecture 6 means ia64

Architecture 9 means x64
Setup logs from the client computer. The setup logs appear in different
185
Component
Obtain and review this output:
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:
a. Boot into the capture image.
b. When the wizard starts, press Shift+F10 to access the command
prompt.
c.
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
d. Open a second instance of the Image Capture Wizard.
e. 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.
f.
PXE boot
components
Obtain the trace log from X:\Windows\Tracing\WDSCapture.log.

Enable tracing in the server and management components and obtain 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.
186
Component
Obtain and review this output:
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)

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 the server

5040* for RPC

69

137–139*

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).
187
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 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
188

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.

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 remove an
image group
Full control over C:RemoteInstall\Images\ImageGroup.
Add or remove an
image
Full control over C:RemoteInstall\Images\ImageGroup.
189
Task
Permissions Needed
Disable an image
Permission to read and write attributes for the associated image file.
Disabling an image means hiding the Windows image (.wim) file associated
with the image.
Add a boot image
Read and write access to the following:

C:RemoteInstall\Boot

C:RemoteInstall\Admin (This folder is only present if you upgrade from
Windows Server 2003).

%TEMP%
Remove a boot
image
Read and write access to C:RemoteInstall\Boot.
Set properties on
an image
Read and write permissions to the .wim metadata file that represents the
image. This file is located within the image group at:
C:RemoteInstall\Images\ImageGroup.
Prestage a
computer
Permissions to create accounts in the domain, as well as write to the
properties of a computer object.
To grant permissions to prestage a computer
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.
Approve a
Read and write permissions for the folder that contains the database file
pending computer Binlsvcdb.mdb in the RemoteInstall share (for example,
C:RemoteInstall\MGMT). The actual account of an approved pending
computer is created by using the server’s authentication token, not the token
of the administrator who is performing the approval. Therefore, in AD DS,
you must grant rights to the Windows Deployment Services server’s account
(WDSSERVER$) to create computer account objects for the containers and
OUs where the approved pending computers will be created.
190
Task
Permissions Needed
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.
Prestage a
computer to join a
domain
The user account must have permissions to join the domain. The JoinRights
registry setting determines the set of security privileges, and the User
registry setting determines which users have the right to join the domain. To
change the per server (per architecture) defaults, you need read and write
permissions to these registry keys.

The JoinRights setting is located at
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDS
Server\Providers\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\WDS
Server\Providers\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.
191
Task
Permissions Needed

(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 the help at the command prompt for
WDSUTIL /set-server /AutoAddSettings.
Convert a
RIPREP image
Create a discover
or capture image

Read and write permissions to the %TEMP% directory and destination
location

Read permissions on the original RIPREP image

Read and write permission to the %TEMP% directory and destination
location

Read permissions on the original boot image
Create a multicast 
transmission

Full control over the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDS
Server\Providers\Multicast
Read permissions to RemoteInstall\Images\ImageGroup.
Modify a multicast Full control over the following registry key:
transmission (for
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSSer
example, delete,
ver\Providers\Multicast
deactivate, start,
stop, disconnect,
and so on)
192
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 the domain join) need
rights to add a prestaged computer and the appropriate JoinRights.
Using
/ResetBootProgram
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
193
Task
Permissions Needed
Managing Network Boot Programs.
Disabling access to the
command prompt during
installations
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 image and select Disable.
2. Mount the image for read and write access using ImageX which is
provided in the Windows Automated Installation Kit (AIK). For
more information about ImageX, see the ImageX Technical
Reference (http://go.microsoft.com/fwlink/?LinkID=120693).
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
194
Task
Permissions Needed
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.
Tab
Settings that Require Permissions
PXE
Response
Settings

PXE response policy. The PXE response policy (for example, responding
only to known clients, or responding to all clients) is stored on the server’s
SCP. Configuring these settings requires read and write permissions to the
SCP object.
To grant permissions to the SCP object
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\WDSSERV
ER\Providers\WDSPXE\Providers\BINLSVC
Name: ResponseDelay
Type: REG_DWORD
Value: Number of seconds to wait before answering PXE client requests
Directory
Services

New client naming policy. This setting is stored in the SCP object on the
server. The property is called: netbootNewMachineNamingPolicy
195
Tab
Settings that Require Permissions

Boot
Client account location. This setting is stored in the SCP object on the
server. The property is called: netbootNewMachineOU
Default boot program

Server-wide: This option is controlled by the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServe
r\Providers\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\WDSServe
r\Providers\WDSPXE\Providers\BINLSVC\BootImages\<arch>
Name: BootImagePath
Type: REG_SZ
Value: Path to server-wide client default boot image for this architecture. For
example: boot\x86\images\boot.wim

Client
Per computer: The computer account attribute is: netbootMirrorDataFile
Unattend file

Server-wide: This option is controlled by the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServe
r\Providers\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\WDSServe
r\Providers\WDSPXE\Providers\BINLSVC
Name: NewMachineDomainJoin
Type: DWORD
196
Tab
Settings that Require Permissions
Value: 0 to prevent domain joining by clients; 1 to enable it.
DHCP

Do not listen on Port 67. This option is controlled by the following registry
key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSSERV
ER\Providers\WDSPXE
Name: UseDhcpPorts
Type: DWORD
Value: 0 disabled; 1 enabled
Advanced

Configure DHCP option 60 to "PXEClient".This requires that the user is able
to configure the Microsoft DHCP server running on the local computer.

DC/GC used by the Windows Deployment Services server (this server).
These settings are stored at the following registry location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServe
r\Providers\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,
Value: FQDN for default global catalog server.
DHCP authorization. Performed using DHCP APIs—you need permissions to
authorize the Microsoft DHCP server.
197