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........................................................................1
Abstract....................................................................................................................................1

Copyright information......................................................................................................................2

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

Windows Deployment Services Deployment Guide......................................................................12

In This Guide.............................................................................................................................12
In This Topic...............................................................................................................................12
Benefits of Windows Deployment Services...............................................................................12
Management Tools....................................................................................................................13
Common Usage Scenarios........................................................................................................13
Scenario One: The Small Business........................................................................................13
Scenario Two: The Medium-Sized Business..........................................................................15
Scenario Three: The Large Enterprise...................................................................................16
Scenario Four: A Custom Deployment Using Transport Server..............................................17

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

Configuring AD DS Integration......................................................................................................18
In This Topic...............................................................................................................................18
Supported Environments...........................................................................................................18
Configuring Static Domain Controllers and Global Catalog Servers..........................................19

Creating a Localized Setup Experience........................................................................................19

In This Topic...............................................................................................................................19
Localizing the Boot Menu..........................................................................................................19
Localizing Setup........................................................................................................................20
Installing Language Packs.........................................................................................................21
Methods.................................................................................................................................22
Storing Language Packs in the Image Store..........................................................................23

Configuring DHCP........................................................................................................................24
In This Topic...............................................................................................................................24
Configuring DHCP Options........................................................................................................24
Enabling DHCP Authorization....................................................................................................24
Authorizing a Server..................................................................................................................25

Managing Network Boot Programs...............................................................................................26

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

Managing the Boot Menu..............................................................................................................33

In This Topic...............................................................................................................................33
Configuring the Boot Menu........................................................................................................33
Specifying Boot Images for Prestaged Clients...........................................................................34
Considerations for x64-Based Clients........................................................................................34

Prestaging Client Computers........................................................................................................34

In This Topic...............................................................................................................................34
Creating Computer Account Objects in AD DS..........................................................................34
Benefits......................................................................................................................................35
Enabling the Auto-Add Policy....................................................................................................36
Purging the Auto-Add Database................................................................................................36

Optimizing Your Deployment.........................................................................................................37

Extending Your Solution................................................................................................................37

In This Topic...............................................................................................................................37
Benefits......................................................................................................................................37
Creating a Custom Solution.......................................................................................................38
Windows Deployment Services PXE Server.......................................................................38
Windows Deployment Services Client................................................................................39
Custom Solution Example.........................................................................................................40
Instructions for Using the Sample Code.................................................................................40
Sample Visual Basic Script.....................................................................................................41
Sample Image Unattend File..................................................................................................42
Sample WinPESHL.ini File.....................................................................................................43

Managing a Complex Environment...............................................................................................43

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

Optimizing Performance and Scalability........................................................................................47

 In This Topic...............................................................................................................................47
Best Practices for Avoiding Performance and Scalability Problems...........................................47
Configuring the Server for Performance and Scalability............................................................48
Performance and Scalability Expectations.................................................................................49
Unicasting...........................................................................................................................49
Multicasting.........................................................................................................................50
Multicast Installation........................................................................................................51
Unicast Installation..........................................................................................................51
Testing of Security Options with Multicast........................................................................52

Using Transport Server.................................................................................................................52

In This Topic...............................................................................................................................53
Comparison of Deployment Server and Transport Server.........................................................53
Configuring Transport Server.....................................................................................................54
Using a Transport Server to Boot from the Network..................................................................55
Using a Transport Server for Multicasting..................................................................................55
How to create a namespace with Transport Server................................................................55
Prerequisites for creating a namespace..............................................................................55
To create a namespace.......................................................................................................56
How to join a client computer to a namespace by using Wdsmcast.exe................................56
How to perform common tasks...............................................................................................58
Options............................................................................................................................59

Performing Unattended Installations.............................................................................................60

Automating the PXE Boot.............................................................................................................61

In This Topic...............................................................................................................................61
Automating the PXE Boot..........................................................................................................61
Avoiding a Boot Loop.............................................................................................................61
Example Scenario..................................................................................................................62
Automating the Selection of the Boot Image..............................................................................62

Automating Setup.........................................................................................................................63
In This Topic...............................................................................................................................63
Creating Unattend Files.............................................................................................................63
Automating the User Interface Screens of the Windows Deployment Services Client...............64
Unattend File Settings............................................................................................................65
Automating the Remaining Setup Phases.................................................................................66

Automating the Domain Join.........................................................................................................67

In This Topic...............................................................................................................................67
Modifying Your Unattend Files...................................................................................................67
Choosing a Permissions Method...............................................................................................68

Automating the Image Capture Wizard.........................................................................................69

WDSCapture.inf Unattend File Settings.....................................................................................69
Advanced Unattended Installation Scenarios................................................................................71
In This Topic...............................................................................................................................71
Passing Unattend Files to Setup by Using the Command Line.................................................72
Using Implicit Unattend Files.....................................................................................................72
Embedding an Unattend File in an Image..................................................................................73
Understanding Unattend File Precedence.................................................................................73
Setting Command-Line Precedence for Image Unattend Files..................................................74
Using Variables to Obtain Information from the Client...............................................................75

Sample Unattend Files..................................................................................................................75

In This Topic...............................................................................................................................75
Windows Deployment Services Client Unattend Files...............................................................76
Example 1: Standard installation ...........................................................................................76
Example 2: Install a language pack........................................................................................78
Image Unattend Files for Windows Vista and Windows Server 2008........................................80
Example 1: Unsecure domain join..........................................................................................80
Example 2: Secure domain join..............................................................................................81
Example 3: Using variables....................................................................................................81
Image Unattend Files for Older Operating Systems..................................................................83
Example 1: Domain join.........................................................................................................83
Example 2: Using variables....................................................................................................83
Example 3: Run a script.........................................................................................................84
Combined Image and Client Unattend File................................................................................84
Image Capture Wizard Unattend File ........................................................................................88

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

Creating Images............................................................................................................................89
In This Topic...............................................................................................................................89
Image Types..............................................................................................................................90
Boot Images..............................................................................................................................90
Creating Custom Boot Images...............................................................................................90
Versions of Windows PE........................................................................................................91
Discover Images........................................................................................................................91
Creating Custom Discover Images.........................................................................................92
Capture Images.........................................................................................................................93
Comparison of ImageX and Image Capture Wizard...............................................................93
Creating Custom Capture Images..........................................................................................94
Converting RIPREP Images......................................................................................................94
Default Conversion.................................................................................................................95
In-Place Conversion...............................................................................................................95

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

Filtering Images............................................................................................................................97
Automatic Filtering by Windows Deployment Services..............................................................97
 Filtering Images Manually..........................................................................................................97

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

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

Storing Files on Another Server...............................................................................................100
Replicating Images..................................................................................................................101

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

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

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

How to Manage Client Computers..............................................................................................120

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

How to Manage Images..............................................................................................................132

General Tasks..........................................................................................................................132
To export an image from the server to a stand-alone .wim file.............................................132
To replace an image on the server with an updated version................................................133
To remove an image.............................................................................................................134
Boot Images............................................................................................................................134
To add a boot image to the server........................................................................................134
To set the attributes on a boot image...................................................................................135
To display the attributes of a boot image..............................................................................136
To create a capture image....................................................................................................136
To create a discover image..................................................................................................136
Install Images..........................................................................................................................137
To add an install image.........................................................................................................137
To set the attributes for an install image...............................................................................137
To display the attributes for an install image.........................................................................138
To convert a RIPREP image to a .wim install image.............................................................138
To make a copy of an install image......................................................................................139
Image Groups..........................................................................................................................139
To remove an image group...................................................................................................139
To add an image group to the image store...........................................................................140
To set the attributes on an image group...............................................................................140
To display information about all images in an image group..................................................141

How to Create Multicast Transmissions......................................................................................141

In This Topic.............................................................................................................................141
When to Implement Multicasting..............................................................................................141
Prerequisites for Creating a Multicast Transmission................................................................142
Known Issues in Creating a Multicast Transmission................................................................142
Transmission Types.................................................................................................................143
To create a multicast transmission with Deployment Server....................................................144
To manage transmissions........................................................................................................144
To manage clients in a transmission........................................................................................145
To configure the UDP port range for multicasting....................................................................146
To configure how the server will obtain IP addresses for multicasting.....................................147

Example Multicast Scripts...........................................................................................................148

In This Topic.............................................................................................................................148
Stop Transmissions Slower than 1 MB per Second.................................................................148
Display Performance Information About Clients......................................................................153
How to Modify the BCD Store Using Bcdedit..............................................................................156
In This Topic.............................................................................................................................156
To View the Contents of the BCD Store...................................................................................156
To Configure the Default Selection Time-out Value..................................................................157
To Configure a Localized Boot Manager Experience...............................................................158
To Configure the TFTP Block Size...........................................................................................159
To Configure the TFTP Window Size.......................................................................................161
To Configure Windows Debugger Options...............................................................................161
To Turn On Emergency Management Services Settings.........................................................163

Troubleshooting..........................................................................................................................166

Troubleshooting Performance Problems.....................................................................................166

In This Topic.............................................................................................................................167
Analyzing Blockages in Each Phase of Installation..................................................................167
PXE Boot Phase...................................................................................................................167
TFTP Download Phase........................................................................................................167
Diagnosing TFTP Download Performance Problems........................................................168
Addressing TFTP Download Performance Problems........................................................168
Image Apply Phase..............................................................................................................169
Diagnosing Performance Problems in the Image Apply Phase.........................................169
Addressing Performance Problems in the Image Apply Phase.........................................170
Using Performance Monitoring................................................................................................171

Common Problems.....................................................................................................................173
Performing PXE Boots on Client Computers...........................................................................174
I am unable to perform PXE boots on client computers....................................................174
When I perform a PXE boot and select a boot image, I see a command prompt..............175
The client computer fails to get an IP address when I try to PXE boot..............................175
The client computer obtains an IP address but then fails to download a NBP...................176
I don't see the hard drive of the client computer on the disk configuration page of Setup.176
My computer loads the boot image, but it cannot access an install image........................176
I created an unattend file, but when installation completes, my client computer is not joined
to the domain.................................................................................................................176
Install images do not appear on the image selection page...............................................176
Troubleshooting x64-Based Client Computers........................................................................177
My x64-based client computer does not have any x64-based images on the boot image
selection page...............................................................................................................177
My x64-based client computer is detected as x64, but it fails to boot to the default image.
......................................................................................................................................177
Performing Management Operations.......................................................................................177
I can't approve a pending computer..................................................................................177
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............177
 I received the error: "0x2: File not found" when trying to manage a remote Windows
Deployment Services server..........................................................................................178
Creating Custom Install Images...............................................................................................178
When using Image Capture Wizard to create a custom image, the volume that contains my
image is not selectable..................................................................................................178
The finish button is not enabled on the final page of the image capture wizard................179
Multicasting..............................................................................................................................180
My multicast transmissions are running very slowly..........................................................180
After enabling multicasting, there is excessive traffic on the network................................180

Logging and Tracing...................................................................................................................180

Network Ports Used....................................................................................................................184

Protocols..................................................................................................................................184
Ports........................................................................................................................................185

Required Permissions.................................................................................................................186
In This Topic.............................................................................................................................186
General Permissions...............................................................................................................186
Permissions for Common Management Tasks.........................................................................187
Permissions for Client Installations..........................................................................................190
Permissions for Server Properties...........................................................................................192
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

Benefits of Windows Deployment Services

Windows Deployment Services provides the following installation and deployment benefits:

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

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

Common Usage Scenarios

The following are common scenarios for Windows Deployment Services.

Scenario One: The Small Business

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

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

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

15
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
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.

16
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
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.

17
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.
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

18
 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.

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

19
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
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).

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

[Available UI Languages]

en-US = 3

de-DE = 3

[Fallback Languages]

en-US = en-us

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

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

21
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.
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.

22
 • 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
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.

23
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 non-
Microsoft) are located on different physical computers. In this scenario, no additional
configuration steps are required for interoperability between Windows Deployment Services and
the DHCP server.
However, if you are running Windows Deployment Services and DHCP on the same computer, in
addition to configuring the server to not listen on port 67, you will need to use your DHCP tools to
add Option 60 to their DHCP scopes. This allows booting clients to learn about the Windows
Deployment Services 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.

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:
24
 • 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.

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.

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

Managing Network Boot Programs

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

In This Topic
• Configuring the NBP
• 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

26
 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 x86-based and BIOS
key for a PXE boot to continue. x64-based

PXEboot.n12 Does not require pressing F12 and x86-based and BIOS
immediately begins a PXE boot. x64-based

AbortPXE.com Boots the computer by using the next boot x86-based and BIOS
item in the BIOS without waiting for a time- x64-based
out.

Hdlscom1.com and Causes computers that do not support x86-based and BIOS
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.

Hdlscom1.n12 and Causes computers that support firmware x86-based and BIOS
Hdlscom2.n12 console redirection will not display the x64-based
prompt "Press space or F12 for network
boot" and the computer will not wait for user
input.

Bootmgfw.efi The EFI equivalent for Bootmgr.exe. In EFI, x64-based and EFI
the choice of whether or not to perform a Itanium-based

27
NBP Description Architecture Firmware

PXE boot is handled within the EFI shell,

and not by the NBP.

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

Services that serves the following general x64-based
purposes:
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.
• 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:

28
 • All DHCP broadcasts by client computers on User Data Protocol (UDP) port 67 should be
forwarded directly to both the DHCP server and the Windows Deployment Services PXE
server.
• All traffic on UDP port 4011 from the client computers to the Windows Deployment
Services PXE server should be routed appropriately (these requests direct traffic, not
broadcasts, to the server).

Using DHCP Options 60, 66, and 67

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

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

When to Implement PXE Referrals

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

30
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
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:
• 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.

First order referral ComputerA sends a DHCP broadcast packet and receives an IP address
using DHCP options lease from a DHCP server. The lease also contains values for DHCP
options 66 and 67, referring the client to download the file \boot\
x86\wdsnbp.com from Server1. The client computer downloads
Wdsnbp.com from Server1.
Requirement:
• The NBP that the client computer is directed to download from the
TFTP server (Server1 in this example) must be Wdsnbp.com.

Second order referral ComputerA sends a DHCP broadcast packet and receives an IP address
using both DHCP lease from a DHCP server. The lease also contains values for DHCP
options and PXE options 66 and 67, referring the client to download the file \boot\

31
Example Details

server 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
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.
32
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
• 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.

33
 • 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.

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

34
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.
• 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).

35
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 /Set-
Server /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.
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 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.

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 /Delete-
AutoAddDevices /DeviceType:<ApprovedDevices|RejectedDevices>.
By default, computers with an approved status will be deleted every 30 days. In addition, to delete
a prestaged computer that was added to AD DS by using the approval process, you must perform

36
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).

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:

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

Creating a Custom Solution

You can use the Windows Deployment Services PXE server and the Windows Deployment
Services client (which is essentially Setup.exe and supporting files for Windows Deployment
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

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

Windows Deployment Services Client

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

39
 4. The application uses the Windows Deployment Services client library to retrieve a list of
available images stored on a Windows Deployment Services server and displays the list of
choices to the client (by using the custom UI).
5. The application deploys the image that the user selects, and it also copies the unattend
file that was acquired previously.
6. The application sends progress and status messages to the server by using the
functionality provided by the Windows Deployment Services client library.

Custom Solution Example

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

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

Sample Visual Basic Script

Option Explicit

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

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

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

' end user defined settings

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

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

dim answer

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

41
Set fso = CreateObject("Scripting.FileSystemObject")

if fso.FileExists(unattendFile) = false then

wscript.echo "Couldn't find unattend file"

else

'Read the unattend file in and replace apprpriate variables

Set unattendFileObject = fso.OpenTextFile(unattendFile, 1)

strContents = unattendFileObject.ReadAll

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

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

unattendFileObject.Close

'Write the updated contents back to the unattend file

Set unattendFileObject = fso.OpenTextFile(unattendFile, 2)

unattendFileObject.Write(strContents)

unattendFileObject.Close

End If

Sample Image Unattend File

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

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

<settings pass="specialize">

<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>

42
 <Password>MyPassword</Password>

</Credentials>

<JoinDomain>%MACHINEDOMAIN%</JoinDomain>

</Identification>

</component>

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

publicKeyToken="31bf3856ad364e35" language="neutral"

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

<ComputerName>%COMPUTERNAME%</ComputerName>

</component>

</settings>

</unattend>

Sample WinPESHL.ini File

[LaunchApps]

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

Managing a Complex Environment

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

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.

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

Managing from a To do this, you can install Remote Server Administration Tools, which will
remote server that install WDSUTIL and the Windows Deployment Services MMC snap-in on
is running Windows the server. To install Remote Server Administration Tools, open Server
Server 2008 (but Manager, right-click the Features node, click Add Features, and then click
not Windows Remote Server Administration Tools. Next clickRole Administration
Deployment Tools, and then click Windows Deployment Services Tools.
Services)

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.
44
 • Lower the multicast Time-To-Live (TTL) setting to prevent the routers from forwarding
multicast traffic outside the site network. You can also configure your border router not to
forward multicast traffic.
To modify these options, right-click the server in the MMC snap-in, click Properties, and then
click the Network Settings tab.

Testing 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 • RISETUP (I)

Windows Server 2003 • RIPREP (I)

Windows Deployment Services servers running • RISETUP (II)

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

Windows Deployment Services servers running • WDSUTIL (II)

Windows Server 2008 • MMC snap-in (II)

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

45
running the 2003 and 2008 versions of Windows Deployment Services, you should use RISETUP
(II), RIPREP (II), WDSUTIL (II), and WDSMMC (II)

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

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

X • RISETUP (I)
• RIPREP (I)

X • RISETUP (II) and RIPREP (II) to

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

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

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

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

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

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

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

• WDSMMC (II)

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.

47
 • Ensure that the disk that contains the RemoteInstall folder has enough throughput
to meet the client demand. On small-scale solutions, this may mean getting a Serial
Advanced Technology Attachment (SATA) drive that spins at 7,200 RPM or faster. On mid-
scale solutions, this may mean getting multiple drives and configuring them using Redundant
Array of Independent Drives (RAID) configuration. On large-scale solutions, this may mean
investing in a hardware RAID array. The disk volume that contains RemoteInstall should be
separate from the system volume.
• Ensure that there is sufficient memory on the server to handle the demands. This
may mean upgrading a server from 32-bit (x86) to 64-bit (x64). (for details about how to
evaluate whether this solution is worthwhile for you, see Performance and Scalability
Expectations).
• Ensure that there is enough processor bandwidth on the server to handle the
demands. If the server has a lot of processes or services that are running, you may need to
distribute the processes and services or upgrade the server’s processor.

Configuring the Server for Performance and

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

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

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

Server type Network interface card Hardware configuration

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

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

Middle 100-MB network adapter • Single-processor x86

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

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

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

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

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

1 25 25 25

10 61 55 25

25 125 117 25

50 235 220 35
49
Number of clients Low-end Mid-range High-end

75 355 330 45

Time elapsed during the TFTP download phase

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

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

1 70 55 40

10 210 145 75

25 450 360 120

50 910 805 270

75 1515 1400 420

Time elapsed when the TFTP block was increased

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

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

adapter clients

GB 50 270 180 118 92 85

GB 75 422 267 171 126 125

100 MB 75 1,410 1,140

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

Network interface card Hardware configuration Operating system

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

processor 5150 Windows

50
 Network interface card Hardware configuration Operating system

• 2.67 Ghz Server 2008

• 8 GB of RAM

Client 100 megabits network • Varied but •

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

Multicast Installation

25 clients 100 clients 300 clients

Restart Restart computer Restart

computer and and start clock. computer and
start clock. start clock.

Time when the first client started :23 :21 :23

download of boot image using TFTP

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

download of boot image using TFTP

Time when the first client started the 3:04 3:55 8:18
multicast transfer

Time when the last client finished the 6:06 7:54 12:30
multicast transfer

Total amount of time until the last client 19:47 22:40 27:40
reached the desktop

Unicast Installation

SMB 25 clients SMB 100 clients SMB 300 clients

Restart computer Restart Restart computer

and start clock. computer and and start clock.
start clock.

Time when the first client started :21 :22 :20

download of boot image using TFTP

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

download of boot image using TFTP

51
 SMB 25 clients SMB 100 clients SMB 300 clients

Time when the first client started image 3:14 4:38 8:29
transfer using unicast/SMB

Time when the last client started image 13:36 38:15 1:47:58
transfer using unicast/SMB

Total amount of time until the last client 20:59 45:37 1:55:15
reached the desktop

Testing of Security Options with Multicast

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

No Security Hashing (default) Signing

Start of multicast Clock started Clock started Clock started

transfer of the install
image to the client

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

of the install image to
the client

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

used during the
multicast transfer

Using Transport Server

You have two options when installing the Windows Deployment Services role in Windows
Server 2008. You can install:
• Both the Deployment Server and Transport Server role services (default)
• Only the Transport Server role service
The second configuration is for advanced scenarios, such as environments without Active
Directory Domain Services (AD DS), Domain Name System (DNS), or 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.

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

Comparison of Deployment Server and Transport

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

Deployment Server Transport Server

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

PXE Supports PXE boot with the default A PXE provider is not installed
PXE provider. so you must create a custom
PXE provider.

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

Transmission method Allows both unicasting and Allows only multicasting.

multicasting.

Management tools Is managed using either the Windows Is managed only by the
Deployment Services MMC snap-in or WDSUTIL command-line tool.
the WDSUTIL command-line tool.

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

client computer Services client (which is basically custom application.
Setup.exe and supporting files),
Wdsmcast.exe (which is included in
the Windows AIK), or a custom
multicast application.

53
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.

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\

54
 Multicast\Profiles. Specify Custom if you want to customize the settings yourself by editing
the registry. You should not modify the other profiles that are provided. You should use the
custom profile even if you only want to change one setting. To set the profile, run
WDSUTIL /Set-TransportServer [/Server:<name>] /Profile:{10Mbps|100Mbps|1Gbps|
Custom} at an elevated command prompt.
• 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:

55
 • A content provider. You can use the Windows Deployment Services content provider
(named WDS) that is included when you install Transport Server. Or you can create your own
content provider by using the tools in the Windows Server 2008 SDK.
• Data to transmit. You can transmit any data that your content provider knows how to find
(for example operating system images, data files, or an MP3 archive). The Windows
Deployment Services content provider knows how to find any file within a folder.
• Familiarity with WDSUTIL. The only way to manage Transport Server is through the
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:

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

To join a namespace by using Wdsmcast.exe

1. 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
57
Option Description

as follows:
/Namespace:WDS:<ImageGroup>/<ImageName>/<Index>.
For example: WDS:ImageGroup1/install.wim/1

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

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

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

/SourceFile:<file path> 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 The complete file path and name for the destination file.
path>

How to perform common tasks

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

58
 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 The name of the Windows Deployment Services server. This can be either
name> the NetBIOS name or the FQDN. If the server name is not specified, the
name of the local server will be used.

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

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

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

/ The friendly name of the namespace. Note that this name does not need to
FriendlyName:<frie be unique.

59
Option Description

ndly name>

/ A short description of the namespace.

Description:<descri
ption>

/ The name of the content provider that supplies data to the multicast server.
ContentProvider:<n If you are using the Windows Deployment Services content provider,
ame> specify WDS.

/ The configuration string for the content provider. If you are using the
ConfigString:<confi Windows Deployment Services content provider (WDS), specify the path to
g string> the folder where content is stored (for example, D:\Photos\Landscapes).
This path can be anywhere on the server.

/NamespaceType: The type of namespace to be created.

{AutoCast|
ScheduledCast}

/ The time on the server when the namespace will start (note that you can
Time:<YYYY/MM/D set this option only for Scheduled-Cast transmissions).
D:hh:mm>

/Clients:<Num of The number of clients to wait for before the namespace will start (note that
Clients> 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

60
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 /Set-
Server /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 loop

61
(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).
However, if there is only one boot image available to the client computer, it will be selected
62
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.
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

63
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:
RemoteInstall\WDSClientUnattend.
3. Open the Windows Deployment Services MMC snap-in, right-click the server that

64
 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

Language- Microsoft-Windows- SetupUILanguage Specifies the language for the Windows

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

Welcome Microsoft-Windows- InputLocale Specifies the computer's input locale

and International-Core- and the keyboard layout for the
keyboard Windows PE selected image. If this setting is not
selection specified, a default will be chosen
page 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 Microsoft-Windows- Credentials Specifies the user name, domain, and

page Setup -> password of an account with proper
WindowsDeployme permissions to install the specified
ntServices -> Login image.

Image Microsoft-Windows- InstallImage Specifies the image to be installed.

selection Setup ->
65
UI page Component Unattend setting Explanation

page WindowsDeployme
ntServices

Image Microsoft-Windows- UILanguage Specifies the language for the selected

selection International-Core- image. If this setting is not specified or
page Windows PE 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 Microsoft-Windows- UILanguageFallb Specifies the language to be used if the

selection International-Core- ack computer's default UI language is only
page Windows PE partially localized for the selected
image.

Disk Microsoft-Windows- Disk Specifies the disk configuration

configuration Setup -> settings.
page DiskConfiguration

Disk Microsoft-Windows- InstallTo Specifies the disk and partition to which

configuration Setup -> the selected image is to be installed.
page WindowsDeployme
ntServices ->
ImageSelection

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 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

66
 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-Windows-
Shell-Setup component for the <specialize> unattended pass must exist, even if it is empty.
• For Windows XP and Windows Server 2003 images. The image unattend file in the
$OEM$ structure (Sysprep.inf) must have the setting DoOldStyleDomainJoin=Yes, and it
must have (at a minimum) the [Networking] and [UserData] sections, even if they are
empty.
If the image unattend file does not contain the proper formatting, Windows Deployment Services
will assume that you have chosen to override or avoid the domain join and computer name
functionality and therefore will not edit the unattend file. If a selected image does not have an
associated image unattend file, a template unattend file will be used to pass domain join (and
computer naming) information throughout the installation process.

67
 • 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.
• Advantages: This method does not
require placing unattend credentials in plain
text in the unattend file.
• Disadvantages: It is possible for a
malicious user to join the domain between To implement a secure join, do the following to
the time the computer account was reset
(in Windows PE) and when the actual
domain join occurs (on first boot of the
applied image). This particular attack is
effectively mitigated with Windows Vista
and Windows Server 2008 images because
the password is dynamically generated.
To implement an unsecure join, set
UnsecureJoin = TRUE and ensure that the
Microsoft-Windows-Shell-Setup component
This method is secure in the sense that it
requires credentials (user name, domain, and
password) before you can reset the account
and perform the domain join. However, in
practice this method is actually less secure
because the credentials reside in the
ImageUnattend.xml file in plain text.
• Advantages: This method uses a
simplified permissions model because a
single account is used throughout the
enterprise to perform all domain join
operations.
• Disadvantages: Credentials are stored
in plain text in the image unattend file,
which is located on a shared folder on the
Windows Deployment Services server.
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-
Shell-Setup component exists for the
specialize phase.
4. Set the <ComputerName> value to

68
Unsecure join Secure join

exists for the specialize phase. %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 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
69
Setting Description

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

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

70
Setting Description

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

No 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.

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
71
 • 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.

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.

72
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 The order of precedence for this file is as
file that is defined always overrides an implicit follows:
unattend file. The order of precedence for this 1. Explicitly assigned image unattend files
file is as follows: (Windows Vista images only)
1. Unattend files that are passed explicitly 2. Image unattend files in the $OEM$
from the command line (for example, structure
setup.exe /wds /unattend:<unattend
3. Template unattend files (used as part of
file>)
a domain join)
2. Unattend files that are defined on the
4. Client unattend files that have been
server
carried over into additional phases of
3. An implicit unattend file unattend processing
(AutoUnattend.xml)

73
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
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).

74
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
• 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

75
 • 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>

</Credentials>

</Login>

<ImageSelection>

<WillShowUI>OnError</WillShowUI>

<InstallImage>

<ImageName>Windows Vista with Office</ImageName>

<ImageGroup>ImageGroup1</ImageGroup>

76
 <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>

<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>

77
 </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>

<InstallImage>

<ImageName>Windows Vista Ultimate</ImageName>

<ImageGroup>ImageGroup1</ImageGroup>

</InstallImage>

<InstallTo>

<DiskID>0</DiskID>

<PartitionID>1</PartitionID>

</InstallTo>

</ImageSelection>

78
 </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>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>

79
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 Microsoft-
Windows-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>

<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>

80
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>

<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%

81
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"

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>

82
 <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]

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%

83
[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%

[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">

84
 <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>

</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>

85
 <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">

<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>

86
 <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>

<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>

87
 </LocalAccounts>

<DomainAccounts>

<DomainAccountList>

<DomainAccount>

<Name>Administrator</Name>

<Group>Administrators;Power Users</Group>

</DomainAccount>

<Domain>Fabrikam.com</Domain>

</DomainAccountList>

</DomainAccounts>

</UserAccounts>

</component>

</settings>

</unattend>

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]

88
$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

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

89
 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.
• 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.

90
 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
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

91
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.

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.

92
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.

/ Specifies the name of the Windows Deployment Services server that the
WDSServer:<Server client should connect to. Note that <ServerName> can be an IP address,
Name> 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.

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.

93
Functionality Image Capture ImageX
Wizard

Captures a partial volume? No Yes

Captures an image that has not been prepared by using No Yes

Sysprep?

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 No Yes

image copy?

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

94
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
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.

95
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 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.

96
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
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.

97
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.
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.

98
 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.
• 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.

99
Storing and Replicating Images Using DFS
This section outlines the tools and topology configurations associated with the Distributed File
System (DFS) role service in the File Services server role of Windows Server 2008. You may
have to update your 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.
• 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 domain-based 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.

100
 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).

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,

101
Option Explanation

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
• Update the RemoteInstall folder
• Set advanced server settings

How to Manage Client • Create and delete prestaged accounts in Active

Computers Directory Domain Services (AD DS)
• View information about prestaged computers
• Configure settings for prestaged computers
• Reject/approve pending computers

How to Manage Images
• 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 • Create multicast transmissions

Transmissions • Manage multicast transmissions

How to Modify the BCD Store • To view the contents of the BCD store

102
Category Example tasks

Using Bcdedit • To configure the default selection time-out value

• To configure a localized boot manager experience
• To configure the TFTP block size and window size
• To configure Windows debugger options

How to Manage Your Server

This section contains procedures for the tasks that are listed and described in the following table.
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.

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

DHCP • To configure Windows Deployment Services to run on the same

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

103
Type Procedure

• To turn on the DHCP authorization requirement

• To authorize the server in DHCP

Client Requests • To configure the server to answer clients

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

Client Boot • To choose which boot images are displayed on x64-based computers
Settings • 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

Active Directory • To specify a domain controller for Windows Deployment Services

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

Unattend File • To choose a default unattend file for the Windows Deployment Services
client
• To specify whether an unattend file on the client computer overrides the
default unattend file

General Tasks
To configure Windows Deployment Services

104
Using the MMC Using WDSUTIL

1. Install Windows Deployment Services. 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.
3. In the left pane of the Windows
For more information, see the Windows
Deployment Services Getting Started
Guide.
2. Click Start, right-click Command
Prompt, click Run as administrator, and
then run WDSUTIL /Verbose /Progress
/Initialize-Server /RemInst:<path>,

Deployment Services snap-in, right-click where <path> is the path where you would
the server and then click Configure like the RemoteInstall folder to be located.
Server.
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.
4. Updates the service parameters.
5. Sets the Trivial File Transfer Protocol (TFTP) root to point to the RemoteInstall folder root.
6. Sets the WDSServer service startup type to Auto.
7. Optionally authorizes the server in Dynamic Host Control Protocol (DHCP).
8. Starts the services.

To start or stop the server

Using the MMC Using WDSUTIL

1. Right-click the server, and then click All 1. Click Start, right-click Command
Tasks. 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

105
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).

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.

106
 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
/Set-Server /BindPolicy /Policy:Exclude.

The preceding procedure sets

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

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

107
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.
2. On the Network Settings tab under
Network Profile, select the option that
specifies the network speed of your
organization.
1. Click Start, right-click Command
Prompt, and click Run as administrator.
2. Run WDSUTIL /Set-Server
[/Server:<name>] /Transport /Profile:
{10Mbps|100Mbps|1Gbps|Custom}.

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

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

To back up the server data

To completely back up your server, you must back up the following two sets of data:
• 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.

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

Using the MMC Using WDSUTIL

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

The preceding procedure does the following:

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

To configure Windows Deployment Services to run on the same

computer as non-Microsoft DHCP

Using the MMC Using WDSUTIL

1. Right-click the server, and then click 1. Click Start, right-click Command
Properties. Prompt, and click Run as administrator.
2. On the DHCP tab, select Do not listen 2. Run WDSUTIL /Set-Server
on port 67. /UseDHCPPorts:No.

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

The preceding procedure sets

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

To turn on the DHCP authorization requirement

Using the MMC Using WDSUTIL

N/A 1. Click Start, right-click Command Prompt, and click Run as

administrator.

109
Using the MMC Using WDSUTIL

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.
2. Right-click the server, and then click
Properties.
3. On the Advanced tab, select Authorize
the Windows Deployment Server in DHCP.
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. Click Start, right-click Command
Prompt, and click Run as administrator.
3. Run WDSUTIL /Set-Server
/Authorize:Yes.

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

110
Using the MMC Using WDSUTIL

1. Right-click the server, and then click
Properties.
2. On the PXE Response Settings tab, do
one of the following:
• To respond to all client PXE requests,
select Respond to all (known and
unknown) client computers.
1. Click Start, right-click Command
Prompt, and click Run as
administrator.
2. Do one of the following:
• To respond to all clients’ PXE
requests, run WDSUTIL /Set-
Server /AnswerClients:All.

• To respond only to prestaged client • To respond only to prestaged

PXE requests, select Respond only to the clients’ PXE requests, run
known client computers. WDSUTIL /Set-Server

• To not answer any client PXE requests, /AnswerClients:Known.

select Do not respond to any client • To not answer any clients’ PXE
computer. Note that this option will only requests, run WDSUTIL /Set-
work if Windows Deployment Services and Server /AnswerClients:None.
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.

The preceding procedure does the following:

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

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

111
Using the MMC Using WDSUTIL

1. Right-click the server, and then click
Properties.
2. On the PXE Response Settings tab,
set the PXE Response delay in the control.
1. Click Start, right-click Command
Prompt, and click Run as administrator.
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.

To configure the server to determine the architecture of booting

clients
112
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.
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.
1. Click Start, right-click Command
Prompt, and click Run as administrator.
2. Run WDSUTIL /Set-Server
/BootProgram:<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>\Default to the specified path.

113
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
2. On the Boot tab, insert the path to the boot image you Command Prompt, and
want to use for each architecture. In most cases, you should click Run as
use the standard boot image that is included on the administrator.
Windows Server 2008 media (located at \Sources\boot.wim) 2. Run WDSUTIL /Set-
without modification. Do not use the Boot.wim from the Server
Windows Vista media unless your version of Windows Vista /BootImage:<path>
has SP1 integrated into the DVD. /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\BootImages\<arch>\BootImagePath to the specified path.

Active Directory Domain Services

To specify a domain controller for Windows Deployment
Services

114
Using the MMC Using WDSUTIL

1. Right-click the server, and then click
Properties.
2. On the Advanced tab, click Let
Windows Deployment Services use only
the specified servers, and then enter the
domain controller name.
1. Click Start, right-click Command
Prompt, and click Run as administrator.
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 1. Click Start, right-click Command
Properties. Prompt, and click Run as administrator.
2. On the Advanced tab, click Let 2. Run WDSUTIL /Set-Server
Windows Deployment Services use only /PreferredGC:<name>,
where <name> is a
the specified servers and then enter the NetBIOS name or FQDN.
Domain controller name.

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.
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

115
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).

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

116
Using the MMC Using WDSUTIL

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

The policy string works as follows:

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

To specify the domain and OU in which to create computer

accounts

117
Using the MMC Using WDSUTIL

1. Right-click the
server, and then click
Properties.
2. On the Directory
Services tab, click
Default Directory
Service location or
specify the domain and
organizational unit (OU)
1. Click Start, right-click Command Prompt, and click Run
as administrator.
2. Do one of the following:
• To create new accounts in the default computer OU in
the domain the Windows Deployment Services server is in,
run WDSUTIL /Set-Server /NewMachineOU
/Type:ServerDomain.
• To create new accounts in the default computer OU in
the domain the specified user account is in, run WDSUTIL
/Set-Server /NewMachineOU /Type:UserDomain.

• To create new accounts in the same OU as the

specified user account, run WDSUTIL /Set-Server
/NewMachineOU /Type:UserOU.

• To create new accounts in a different OU, run

WDSUTIL /Set-Server /NewMachineOU /Type:Custom
/OU:<name of OU>.

The preceding procedure does the following:

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

To choose whether to join client computers to the domain

Using the MMC Using WDSUTIL

1. Right-click the server, and then click
Properties.
2. On the Client tab, clear the Do not
create account in Active Directory after
running the WDS Client check box to join
computers to the domain.
1. Click Start, right-click Command
Prompt, and click Run as administrator.
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.

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

Using the MMC Using WDSUTIL

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

The preceding procedure sets

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

To specify whether an unattend file on the client computer will

override a default unattend file

Using the MMC Using WDSUTIL

N/A 1. 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.

119
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 • To prestage a client computer

Computers • 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

Configure the • To enable the Auto-Add policy

Auto-Add • To change the length of time approved computers are held in the Auto-
Policy 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

Specify • To change the rate at which pending computers will poll the server
Settings for • To change the number of times pending computers will poll the server
Pending
• To change the message displayed to pending computers
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

Approve and • To view the table of computers that are pending approval
Reject • To approve a pending computer by using the default settings
Pending
• To approve all pending computers by using the default settings
Computers
• To approve a pending computer, but change a setting
• To approve all pending computers, but change a setting
• To reject a pending computer

120
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 1. Click Start, right-click Command
and Computers, open the Active Directory Users Prompt, and click Run as
and Computers MMC snap-in (click Start, click administrator.
Run, type dsa.msc, and then click OK). 2. Run WDSUTIL /Add-Device

Note /Device:<name> /ID:<GUIDorMACAddress>

where <GUIDorMACAddress> is the
To manage the server remotely, you can
identifier of the new computer. If you use
install “AD DS Snap-Ins and Command-
a MAC address, you must precede it
Line Tools” in the Remote Server
with twenty zeros (0).
Administration Tools. To do this, click Add
Features in Server Manager, and install For example: WDSUTIL /Add-Device
the feature from the following location: /Device:Computer1
Remote Server Administration /ID:{E8A3EFAC-201F-4E69-953F-
Tools>Remote Administration Tools>AD DS B2DAA1E8B1B6}
and AD LDS Tools>AD DS Tools>AD DS /ReferralServer:WDSServer1
Snap-Ins and Command-line Tools. /BootProgram:boot\x86\pxeboot.com /
2. In the console tree, right-click the WDSClientUnattend:WDSClientUnatte
organizational unit that will contain the new client nd\unattend.xml
computer. /User:Domain\MyUser
3. Click New, and then click Computer. /JoinRights:Full
4. Type the client computer name, click Next, /BootImagePath:boot\x86\images\boo
and then click This is a managed computer. t.wim
/OU:"OU=MyOU,CN=Test,DC=Domain,
5. In the text box, type the client computer's MAC
DC=com"
address preceded with twenty zeros or the globally
unique identifier (GUID) in the format:
{XXXXXXXX-XXXX-XXXX-XXX-
XXXXXXXXXXXX}.
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.

121
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

122
Using the MMC Using WDSUTIL

you want from the RemoteInstall folder.

The preceding procedure sets the WdsUnattendFilePath variable in the netbootMirrorDataFile

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

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

default

Using the MMC Using WDSUTIL

N/A 1. 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>.

123
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.

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
2. On the PXE Response settings tab, click Command Prompt, and click
Respond to all (known and unknown) client Run as administrator.
computers. 2. Run WDSUTIL /Set-Server

3. Select the check box For unknown clients, notify /AutoAddPolicy

administrator and respond after approval. /Policy:AdminApproval.

124
The preceding procedure sets
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers
\BINLSVC\AutoApprove\Policy to 1.

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

Auto-Add database

Using the MMC Using WDSUTIL

N/A 1. 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>.

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

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>.

126
This procedure sets
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers
\BINLSVC\AutoApprove\PollMessage to the specified message.

To set a default network boot server for pending computers

Using the MMC Using WDSUTIL

N/A 1. 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.

127
The preceding procedure sets
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers
\BINLSVC\AutoApprove\<architecture>\WdsUnattendFilePath to the specified path.

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\Provid
ers\BINLSVC\AutoApprove\<architecture>\JoinRights to 0 if Join Only and 1 if Full
•

128
 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Provid
ers\BINLSVC\AutoApprove\<architecture>\JoinDomain to 1.

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

2. Select the Pending Devices node. Prompt, and click Run as administrator.
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

2. Right-click the computer you want to Prompt, and click Run as administrator.
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

2. Click Approve All. Prompt, and click Run as administrator.
2. Run WDSUTIL /Approve-
AutoAddDevices /RequestID:All.

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

129
To approve a pending computer, but change a setting

Using the MMC (name Using WDSUTIL

change only)

1. Select the 1. Click Start, right-click Command Prompt, and click Run as
Pending Devices administrator.
node. 2. Run WDSUTIL /Approve-AutoAddDevices /RequestID:<ID> with
2. Select the the ID obtained from the Auto-Add database
computer you want In addition, you can append this command with the following options:
to approve.
• To change the name, specify /MachineName:<name>
3. On the Action
• To change the organizational unit (OU) where the account will
menu, click Name
be created, specify /OU:<name of OU>.
and Approve.
• To change the user account for the domain join, specify
4. In the dialog
/User:<name> where the name is domain\user or user@domain.
box, type the name
• To enable the user to join this computer to the domain only
you want to give
once, specify /JoinRights:JoinOnly.
the computer.
• 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.

130
Using the MMC Using WDSUTIL

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

In addition, you can append this command with the following options:
• To change the OU where the accounts will be created, specify
/OU:<name of OU>.

• To change the user account used for domain join, specify

/User:<name> where 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 1. Click Start, right-click Command Prompt, and click Run as
Pending Devices administrator.
node. 2. Do one of the following:
2. Right-click the • To reject a single computer, run WDSUTIL /Reject-
computer, and then AutoAddDevices /RequestID:<ID> with the ID obtained from the
click Reject or Auto-Add database.
Reject All.
• 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.

131
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

Boot Images • 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

Install Images • 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

Image Groups • To remove an image group

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

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

132
Using the MMC Using WDSUTIL

1. Right-click a boot
or install image, and
then click Export
Image.
2. In the dialog box,
choose a file name to
export the image to.
1. Click Start, right-click Command Prompt, and click Run as
administrator.
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

133
Using the MMC Using WDSUTIL

1. Right-click a boot 1. Click Start, right-click Command Prompt, and click Run as
or install image, and administrator.
then click Replace 2. Do one of the following:
Image.
• To replace a boot image, run WDSUTIL /Verbose /Progress
2. Browse to the /Replace-Image /Image:<name> /ImageType:Boot
updated version. /Architecture:{x86|x64|ia64} /ReplacementImage
3. Click through the /ImageFile:<path>.
rest of the wizard. • 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 1. Click Start, right-click Command Prompt, and click Run as

boot or install administrator.
image. 2. Do one of the following:
2. Click Delete. • 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

134
Using the MMC Using WDSUTIL

1. Right-click the Boot Images node, and then click Add 1. Click Start, right-click
Boot Image. Command Prompt, and
2. Enter the path to the boot image or browse to the image click Run as
file, and then click Next. In most cases, you should use the administrator.
standard boot image that is included on the Windows 2. Run WDSUTIL
Server 2008 media (located at \Sources\boot.wim) without /Verbose /Progress
modification. Do not use the Boot.wim from the /Add-Image
Windows Vista media unless your version of Windows Vista /ImageFile:<path>
has SP1 integrated into the DVD. /ImageType:Boot, where
3. Enter an image name and description, and then click the path is a full path to
Next. 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-
3. Enter the name Image /Image:<name> /ImageType:Boot
and description. /Architecture:<arch> /Name:<name>
/Description:<description>.

In the preceding procedure, note the following:

• Taking an image offline sets the hidden file attribute on the relevant .wim file.
135
 • 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

2. Click Properties. Prompt, and click Run as administrator.
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, 1. Click Start, right-click

expand the Boot Images node. Command Prompt, and
2. Right-click the image to use it as a capture image (most click Run as
commonly, the \Sources\boot.wim file from the installation administrator.
media). 2. Run WDSUTIL /New-

3. Click Create Capture Boot Image. CaptureImage

/Image:<source boot
4. Type a name, description, and the location where you
image name>
want to save a local copy of the file. You must specify a
/Architecture:{x86|ia64|
location so that if there is a network issue when you deploy
x64}
the capture image, you have a local copy.
/DestinationImage
5. Continue to follow the instructions in the wizard, and /FilePath:<file path>,
when it is completed, click Finish. where the file path is the
6. Right-click the boot image folder. path and name for the
7. Click Add Boot Image. capture image.
8. Browse and select the new capture image, and then
click Next.
9. Follow the instructions in the Image Capture Wizard.

To create a discover image

136
Using the MMC Using WDSUTIL

1. In the Windows Deployment Services 1. Click Start, right-click Command

MMC snap-in, expand the Boot images
node.
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.
3. Click Create Discover Boot Image.
Prompt, and click Run as administrator.
2. Run WDSUTIL /New-DiscoverImage
/Image:<name> /Architecture:{x86|x64|
ia64} /DestinationImage /FilePath:<path
and name to new file>. To specify which
server the discover image connects to,
append /WDSServer:<server name or IP>.

4. Follow the instructions in the wizard,

and when it is completed, click Finish.

Install Images
To add an install image

Using the MMC Using WDSUTIL

1. Right-click the
image group, and then
click Add Install
Image.
2. Select an image
group.
3. Select the file to
add.
4. Proceed through
the rest of the wizard.
1. Click Start, right-click Command Prompt, and click Run as
administrator.
2. To create an image group, run WDSUTIL /Add-ImageGroup
/ImageGroup:<image group name>.
3. Run WDSUTIL /Verbose /Progress /Add-Image
/ImageFile:<path to .wim file> /ImageType:Install.
If more than one image group exists on the server, append
/ImageGroup:<image group name> to specify which group the
image should be added to.
To skip the integrity check before adding the image, append
/SkipVerify.

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

To set the attributes for an install image

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

137
Using the MMC Using WDSUTIL

1. Right-click an install image, and then 1. Click Start, right-click Command

either click Disable to take the image Prompt, and click Run as administrator.
offline or click Enable to bring it back 2. Run WDSUTIL /Set-Image
online. Image:<name> /ImageType:Install
2. On the Action menu, click Properties. /ImageGroup:<image group name>

3. Enter the name and description in the /Name:<name>

appropriate text boxes. /Description:<description>

/UserFilter:<SDDL> /Enabled:{Yes|No}
4. Check Allow image to install in
/UnattendFile:<path>.
unattended mode, and then select a file to
associate an unattend file with the install
image.
5. Use the Security tab to set access
controls.

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

To display the attributes for an install image

Using the MMC Using WDSUTIL

1. Right-click the 1. Click Start, right-click Command Prompt, and click Run as
image. 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.

138
Using the MMC Using WDSUTIL

1. Click the 1. Click Start, right-click Command Prompt, and click Run as
Legacy Images administrator.
node. 2. Run WDSUTIL /Verbose /Progress /Convert-RiPrepImage
2. Right-click the /FilePath:<path to RIPREP image sif file> /DestinationImage
RIPREP image /FilePath:<path and name of .wim image>. In addition, you can
you want to specify the following:
convert, and then • To give the new .wim image a name in the metadata,
click Convert to append /Name:<name>.
WIM.
• To give the new .wim image a description in the metadata,
3. Enter the append /Description:<description>.
name, description,
• To convert the original RIPREP image, rather than a copy,
path, and file
append /InPlace.
name, and then
• To determine behavior when the image file specified in
click Next.
/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

139
Using the MMC Using WDSUTIL

1. Right-click image 1. Click Start, right-click Command Prompt, and click Run
group. 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, 1. Click Start, right-click Command

and then click Add Image Group. 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 1. Click Start, right-click Command Prompt, and click Run as

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

140
To display information about all images in an image group

Using the MMC Using WDSUTIL

1. Select an image group.
2. View the images in the
right pane.
1. Click Start, right-click Command Prompt, and click
Run as administrator.
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.

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

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

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.
142
 • 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
right-clicking it and then clicking Start.

143
Consider using Auto-Cast if: Consider using Scheduled-Cast if:

• 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.
• 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).

To create a multicast transmission with

Deployment Server
Using the MMC Using WDSUTIL

Do one of the 1. Click Start, right-click Command Prompt, and click Run as
following: administrator.
• Right-click the 2. Do one of the following:
Multicast a. To create an Auto-Cast transmission
Transmission
Syntax: WDSUTIL /New-MulticastTransmission /Image:<image
node, and then
name> /FriendlyName:<friendly name> /ImageType:Install
click Create
/ImageGroup:<Image group name> /TransmissionType:AutoCast
Multicast
b. To create a Scheduled-Cast transmission
Transmission.
Syntax: WDSUTIL /New-MulticastTransmission /Image:<image
• Right-click an
name> /FriendlyName:<friendly name> /ImageType:Install
image, and then
/ImageGroup:<Image group name>
click Create
/TransmissionType:ScheduledCast [/Time:<yyyy/mm/dd:hh:mm>]
Multicast
[/Clients:<no of clients>]
Transmission.

To manage transmissions

144
Using the MMC
• Start the transmission. If the
transmission is the Scheduled-Cast type,
there is at least one client, and the
transmission has not started yet, you can
right-click the transmission and then click
Start.
• Delete the transmission. If you right-
click the transmission and click Delete, the
multicast transmission stops and each
client installation will fall back to using
unicast transmission. That is, the client
installations will not be deleted or stopped,
but they will not use the multicast
transmission to complete the installation.
• Deactivate the transmission. If you
right-click the transmission and then click
Deactivate, each client that is currently
installing will continue, but no new clients
will be joined to the transmission. After
each current client installation is completed,
the transmission will be deleted. If there are
no clients when you click this option, the
transmission will be deleted instantly.
• View the transmission's properties.
To view the properties, right-click the
transmission and then click Properties.
Note that you cannot edit the properties of
a transmission after it is created. To make a
change after you have created a
transmission, you need to delete it and then
recreate it.
• Refresh the transmissions and data.
To do this, right-click a transmission and
then click Refresh. You can also refresh
the data by pressing F5.
To manage clients in a transmission
Using WDSUTIL
• To start the transmission
Syntax: WDSUTIL /Start-
MulticastTransmission /Image:<image
name> /ImageType:Install
/ImageGroup:<image group name>
Note
You can start the transmission only
if it is the Scheduled-Cast type,
there is at least one client, and the
transmission is not already started.
• To delete the transmission
Syntax: WDSUTIL /Remove-
MulticastTransmission /Image:<image
name> /ImageType:Install
/ImageGroup:<image group name> /Force
• To deactivate the transmission
Syntax: WDSUTIL /Remove-
MulticastTransmission /Image:<image
name> /ImageType:Install
/ImageGroup:<image group name>
• To view the transmission's
properties
Syntax: WDSUTIL /Get-
MulticastTransmission /Image:<image
name> /ImageType:Install
/ImageGroup:<image group name>
145
Using the MMC Using WDSUTIL

• Viewclients and see progress. To • To view clients and see progress

view any connected clients, expand the Syntax: WDSUTIL /Get-
Multicast Transmissions node and then MulticastTransmission /Image:<image
click the image. The connected clients name> /ImageType:Install
(including the current installation time and /ImageGroup:<image group name>
the percentage complete) are shown in the /show:clients
right pane.
• To stop a client installation
• Stop a client installation. To stop the completely
installation completely, right-click a client
Syntax: WDSUTIL /Disconnect-Client
and then click Disconnect. You should use
/ClientID:<id> /Force.
this option with caution because the
installation will fail and the computer could Note
be left in an unusable state. You should use this option with
• Disconnect a client from a multicast caution because the installation will
transmission. To discontinue the fail and the computer could be left
transmission for a particular client but in an unusable state.
continue to transfer the image through • To disconnect a client from a
unicasting, right-click the client, and then multicast transmission but continue to
click Bypass multicast. transfer the image by using unicasting
Syntax: WDSUTIL /Disconnect-Client
/ClientID:<id>

• To view the client <id> for each

transmission
Syntax: WDSUTIL /Get-
MulticastTransmission /Image:<image
name> /ImageType:Install
/ImageGroup:<image group name>
/show:clients

To configure the UDP port range for multicasting

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

146
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 1. Click Start, right-click Command
Properties. Prompt, and click Run as administrator.
2. On the Network Settings tab, specify 2. Run WDSUTIL /Set-Server
the UDP port range. [/Server:<name>] /Transport /StartPort:x

3. You must restart the service before the /EndPort:y.

changes will take effect. To do this, right- 3. You must restart the service before the
click the server in the MMC snap-in, click changes will take effect. To do this, run
All Tasks, and then click Restart. 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.

147
Using the MMC Using WDSUTIL

1. Right-click the server, and then click
Properties.
2. On the Network Settings tab under
Multicast IP Address, select one of the
following:
• Obtain IP address from DHCP.
You can select this option only if your
DHCP server supports it. The IP
address for each namespace will be
obtained by using MADCAP (RFC
2730, Multicast).
• Use IP address from the
following range. You will need to enter
a range.
3. You must restart the service before the
changes will take effect. To do this, right-
click the server in the MMC snap-in, click
All Tasks, and then click Restart.
1. Click Start, right-click Command
Prompt, and click Run as administrator.
2. Do one of the following:
• To use MADCAP to obtain the IP
address for each namespace, run
WDSUTIL /Set-Server [/Server:<name>]
/Transport /ObtainIPFrom:DHCP.
• To configure a preset range of IP
addresses, run WDSUTIL /Set-Server
[/Server:<name>] /Transport
/ObtainIPv4From:Range /Start:x.x.x.x
/End:y.y.y.y.
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 /Get-

148
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"

hostname = "localhost"

149
 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

loopAndKick()

wscript.sleep(sleepTime)

150
 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

151
 ' 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

' Remove the old entry from the dictionary

sessionDictionary.Remove(CLng(session.ID))

152
 ' 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")

if WScript.Arguments.Count = 0 then

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

remote host" & vbCrLf

153
 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)

' Get all clients for this session

Set ClientCollection = session.RetrieveClients()

154
 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

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

155
 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
• 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>

156
Example: C:\boot>bcdedit.exe /enum all /store c:\remoteinstall\tmp\X86.{05FF3388-7D71-
46A1-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}

debugtype Serial

debugport 1

baudrate 115200

Device options

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

157
 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)

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

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

device boot

path OSChooser\i386\startrom.n12

description Remote Installation Services

pxesoftreboot Yes

158
 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:
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

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

159
 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:
Syntax: bcdedit /store <full path and file name of store> /set {<GUID identifier>}
ramdisktftpblocksize <block size>
Example: C:\>bcdedit /store c:\RemoteInstall\boot\x86\default.bcd /set {68d9e51c-a129-
4ee1-9725-2ab00a957daf} ramdisktftpblocksize 4096

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

160
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-a129-
4ee1-9725-2ab00a957daf} ramdisktftpwindowsize 9
3. Force regeneration of the BCD store in the \Tmp folder by sending a control signal to the
WDSServer service by running the following command:
C:\>sc control wdsserver 129

To Configure Windows Debugger Options

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

Option Description

/bootdebug Enables or disables boot debugging for a boot application.

/dbgsettings Sets the global debugger parameters.

/debug Enables or disables kernel debugging for an operating system entry.

To turn on debugging for boot manager

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

Windows Boot Manager

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

identifier {bootmgr}

inherit {dbgsettings}

timeout 30

161
 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
<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

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

To Turn On Emergency Management Services

Settings
For servers equipped with the proper firmware, Emergency Management Services (EMS)
provides functionality that you can use to administer a server remotely. This is useful for
computers that do not support direct video output or do not have a keyboard and mouse
attached. Except for hardware maintenance and replacement, all administrative functions that you
can accomplish locally should be available remotely. This includes starting your system and

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

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

Windows Boot Loader

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

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

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

f}

description WinPE 5600 RC1

osdevice ramdisk=[boot]\Boot\x86\Images\boot.wim,{68d9e51c-

164
 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
{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

165
 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 {06689f95-
f69c-4937-8ded-09a966a6a319} ems on
8. Enable inheritance of EMS settings from Default.bcd values as configured above, by
running the following command:
Syntax: bcdedit /store <full path and file name of per-image BCD store> /set <GUID
identifier> inherit {emssettings}
Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set {06689f95-
f69c-4937-8ded-09a966a6a319} inherit {emssettings}
9. Force regeneration of the BCD store in the \Tmp folder by sending a control signal to
the server service, using the following command:
C:\>sc control wdsserver 129

Troubleshooting
• 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.

166
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.

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)

167
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.
• 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:

168
 • 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).
• 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:

169
 • 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
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:

170
 • 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.
• 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.

171
• 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.
• 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

172
 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:
• 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 • I am unable to perform PXE boots on client computers.

PXE Boots on • When I perform a PXE boot and select a boot image, I see a command
Client prompt.
Computers
• 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

173
Type Issues

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 • My x64-based client computer does not have any x64-based images on the
ng x64-Based boot image selection page.
Client • My x64-based client computer is detected as x64, but it fails to boot to the
Computers default image.

Performing • I can't approve a pending computer.

Management • I approved a pending computer and then deleted the computer account that
Operations 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 • When using the Image Capture Wizard to create a custom image, the
Custom volume that contains my image is not selectable.
Images • 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.

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.

174
 • 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
/delete-AutoAddDevices /DeviceType:RejectedDevices) or enabling the record to be
purged automatically (according to the default cleanup interval). For instructions, see the
Auto-Add Database section of How to Manage Client Computers.
• Client boot requests are not getting routed correctly to the Windows Deployment Services
server. To ensure that the IP Helper router is updated and that the Dynamic Host Control
Protocol (DHCP) option configuration has been completed correctly, see "Methods of
Directing a Client to the Appropriate NBP" in Managing Network Boot Programs.
• The client has been prestaged and a network boot program (NBP) has been defined;
however, the NBP does not exist on the server. Examine the output from WDSUTIL /get-
device /Device:<device name> to determine the name and path of the NBP. Then check
that location on the Windows Deployment Services server to ensure that the file exists. If it
does not exist, run WDSUTIL /Set-device to direct the client to a different NBP.
• DHCP and Windows Deployment Services are running on the same physical computer,
but the settings associated with this configuration have not been defined. To configure this,
see the DHCP section of How to Manage Your Server. For more information, see Configuring
DHCP.

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.

175
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.

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

176
 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.

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:

177
 • 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:
• 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).

178
 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.
• 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.

179
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.

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.

180
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 • WDSUTIL /get-server /show:all /detailed

of the Windows • Windows Application log in Event Viewer
Deployment
• Windows System log in Event Viewer
Services server

Server • WDSUTIL /get-server /show:all /detailed

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 • Enable tracing in the management and MMC snap-in components by

components setting the following:
a. Set the following registry key to enable tracing in the management
components:
HKEY_LOCAL_MACHINE\Software\Microsoft\Tracing\WDSMGMT

181
Component Obtain and review this output:

Name: EnableFileTracing
Value:1
b. Set the following registry key to enable tracing in the management
console:
HKEY_LOCAL_MACHINE\Software\Microsoft\Tracing\WDSMMC
Name: EnableFileTracing
Value:1
Then you can obtain the trace logs at %windir%\tracing\wdsmgmt.log and
%windir%\tracing\wdsmmc.log.
• WDSUTIL /get-server /show:all /detailed
• Windows Application log in Event Viewer
• Windows System log in Event Viewer

Note
Although the Windows Deployment Services MMC snap-in and
WDSUTIL share the same API layer, in some cases the MMC adds
additional processing and functionality. In instances where an error
occurs, it is often worthwhile to attempt to reproduce the failure
using WDSUTIL to determine if the error is localized to the MMC or
if it is a general management API failure. Often, WDSUTIL will
provide more detailed error output without enabling tracing. Where
applicable, use the /detailed, /verbose, and /progress options for
extra information.

Windows Logging in the Windows Deployment Services client serves two purposes. First,
Deployment it allows you to determine if a particular client failed during installation, and it
Services client 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

182
Component Obtain and review this output:

/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 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:

183
Component Obtain and review this output:

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. Obtain the trace log from X:\Windows\Tracing\WDSCapture.log.

PXE boot • Enable tracing in the server and management components and obtain
components the trace logs (as outlined previously).
• Obtain a network trace that shows the failed boot attempt. It is a best
practice to obtain this trace from the client and server simultaneously to
accurately assess whether the failure is occurring at the sending server or
the receiving client. The process is:
a. Place a client and a third computer (laptop or desktop) on a hub.
b. Start network traces from the server and third computer.
c. Boot the client from the network.

Note
If you are using Network Monitor to obtain the traces, ensure
that the buffer size is at least 20 MB. If you configure a bufferf
size too small for the capture, then packets will be lost (not
appear) in the capture output.

Network Ports Used

Protocols
Windows Deployment Services uses the following protocols for installing images:
• Dynamic Host Configuration Protocol (DHCP)
• Pre-Boot Execution Environment (PXE)
• Trivial File Transfer Protocol (TFTP)
• Remote procedure call (RPC)
• Server Message Block (SMB)
• Multicasting
184
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
• 69 RPC

• 4011 • 137–139*

• Random ports from 64001 through 65000*, to establish a session

with the server for TFTP and multicasting (in accordance with RFC
1783 at http://go.microsoft.com/fwlink/?LinkId=81027).

The following steps explain the UDP and TCP ports that are used during image
deployment:
1. The client performs a PXE boot.
2. PXE uses DHCP ports and TFTP to download the binary files. For UDP and DHCP,
you need to enable ports 67, 69, and 4011. In addition, TFTP endpoints are used; by
default, these endpoints range from 64001 through 65000. For instructions on modifying
these ranges, see How to Manage Your Server.You can also use the Network Address
Translation (NAT) with the Routing and Remote Access network service to control these
ports.
3. In accordance with RFC 1783 (http://go.microsoft.com/fwlink/?LinkId=81027), the
client chooses random UDP ports to establish the session with the server. You should
use an application exception for TFTP if you have the Windows firewall enabled on the
Windows Deployment Services server.
4. The client downloads Windows PE and boots to the Windows Deployment Services
client. This download also uses the same TFTP ports as mentioned previously.
5. The Windows Deployment Services client communicates with the Windows
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

185
 In addition, if DHCP authorization is required on the server, you need DHCP
client port 68 to be open on the server. Note that DHCP authorization is not
required by default; but you can turn it on manually.

Required Permissions
This chapter outlines the following permissions and, where appropriate, how to grant them.

In This Topic
• General Permissions
• Permissions for Common Management Tasks
• Permissions for Client Installations
• Permissions for Server Properties

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

General Permissions
To fully administer a Windows Deployment Services server, you need the following permissions:
• Local administrator of the Windows Deployment Services server. This gives you the
following rights:
• File permissions and permissions to the RemoteInstall folder (the management tools
interact with the image store using UNC paths).
• Registry hive permissions. Many settings for the Windows Deployment Services
server are stored in HKEY_LOCAL_MACHINE\System, and you need appropriate
permissions to these locations to change them.
• 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.

186
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 Full control over C:RemoteInstall\Images\ImageGroup.

image group

Add or remove an Full control over C:RemoteInstall\Images\ImageGroup.

image

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 Read and write access to C:RemoteInstall\Boot.

image

Set properties on Read and write permissions to the .wim metadata file that represents the
an image image. This file is located within the image group at:
C:RemoteInstall\Images\ImageGroup.

Prestage a Permissions to create accounts in the domain, as well as write to the

computer 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
187
Task Permissions Needed

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.
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 The user account must have permissions to join the domain. The JoinRights
computer to join a registry setting determines the set of security privileges, and the User registry
domain 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

188
Task Permissions Needed

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.
• (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 • Read and write permissions to the %TEMP% directory and

RIPREP image destination location
• Read permissions on the original RIPREP image

Create a discover • Read and write permission to the %TEMP% directory and destination
or capture image location
• Read permissions on the original boot image

Create a multicast • Full control over the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDS
189
Task Permissions Needed

transmission 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)

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 No permissions are required to PXE boot a client, and no mechanism
computer 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
190
Task Permissions Needed

(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 If the ResetBootProgram functionality is enabled, the user needs read

/ResetBootProgram and write permissions to the netbootMachineFilePath property on
the prestaged computer object. If this permission is not granted and
the user's boot program is set to pxeboot.n12, Windows Deployment
Services will not be able to reset the NBP to pxeboot.com, forcing the
computer into an infinite reboot loop. For more information, see
Managing Network Boot Programs.

Disabling access to the By default, users can gain access to a command prompt during
command prompt during Windows Deployment Services installations by:
installations • 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.

191
Task Permissions Needed

5. In the Windows Deployment Services MMC snap-in, right-click

the desired boot image and select Enable. .
To disable access for install images
1. In the Windows Deployment Services MMC snap-in, right-click
the desired boot image and choose Disable.
2. Export the image to an external .wim file.
3. Mount the image for read and write access using the tools
provided in the Windows AIK.
4. Create the file %windir
%\Setup\Scripts\DisableCmdRequest.tag in the mounted image.
5. Commit the changes and unmount the image. .
6. In the Windows Deployment Services MMC snap-in, right-click
the disabled install image and choose Replace Image.
7. Follow the instructions in the wizard to re-import the modified
install image.

Permissions for Server Properties

The following section outlines the minimal set of permissions that are necessary to perform
common management tasks using the server properties pages. To access these settings, open
the Windows Deployment Services MMC snap-in, right click the server, and click Properties.

Tab Settings that Require Permissions

PXE • PXE response policy. The PXE response policy (for example, responding
Response only to known clients, or responding to all clients) is stored on the server’s SCP.
Settings 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

192
Tab Settings that Require Permissions

permissions to the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSSERVE
R\Providers\WDSPXE\Providers\BINLSVC
Name: ResponseDelay
Type: REG_DWORD
Value: Number of seconds to wait before answering PXE client requests

Directory • New client naming policy. This setting is stored in the SCP object on the
Services server. The property is called: netbootNewMachineNamingPolicy
• Client account location. This setting is stored in the SCP object on the
server. The property is called: netbootNewMachineOU

Boot Default boot program

• Server-wide: This option is controlled by the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\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
• Per computer: The computer account attribute is: netbootMirrorDataFile

Client Unattend file

• Server-wide: This option is controlled by the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServe
r\Providers\WdsImgSrv\Unattend\x86
Name: FilePath
Type: REG_SZ
Value: Path to server-wide client Unattend file relative to the RemoteInstall

193
Tab Settings that Require Permissions

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
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\WDSSERVE
R\Providers\WDSPXE
Name: UseDhcpPorts
Type: DWORD
Value: 0 disabled; 1 enabled
• Configure DHCP option 60 to "PXEClient".This requires that the user is
able to configure the Microsoft DHCP server running on the local computer.

Advanced • 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.

194