Jose Antonio Cermeño's IT Blog | Microsoft , tecnologia ...
[pic]
[pic]
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.
[pic]
Copyright information
Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
© 2009 Microsoft Corporation. All rights reserved.
Active Directory, Microsoft, Windows, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
All other trademarks are property of their respective owners.
Contents
Windows Deployment Services Deployment Guide 13
In This Guide 13
In This Topic 13
Benefits of Windows Deployment Services 14
Management Tools 14
Common Usage Scenarios 14
Scenario One: The Small Business 14
Scenario Two: The Medium-Sized Business 16
Scenario Three: The Large Enterprise 17
Scenario Four: A Custom Deployment Using Transport Server 18
Configuring Your Deployment 19
Configuring AD DS Integration 19
In This Topic 19
Supported Environments 19
Configuring Static Domain Controllers and Global Catalog Servers 20
Creating a Localized Setup Experience 20
In This Topic 21
Localizing the Boot Menu 21
Localizing Setup 21
Installing Language Packs 23
Methods 23
Storing Language Packs in the Image Store 24
Configuring DHCP 25
In This Topic 25
Configuring DHCP Options 25
Enabling DHCP Authorization 26
Authorizing a Server 27
Managing Network Boot Programs 27
In This Topic 28
Configuring the NBP 28
List of NBPs 28
Directing a Client to the Appropriate NBP 30
Updating the IP Helper Tables 30
Using DHCP Options 60, 66, and 67 31
Implementing PXE Referrals 32
When to Implement PXE Referrals 32
Requirements 33
Referral Examples 33
Enabling Architecture Detection 35
Avoiding a Boot Loop 35
Managing the Boot Menu 35
In This Topic 36
Configuring the Boot Menu 36
Specifying Boot Images for Prestaged Clients 36
Considerations for x64-Based Clients 37
Prestaging Client Computers 37
In This Topic 37
Creating Computer Account Objects in AD DS 37
Benefits 38
Enabling the Auto-Add Policy 38
Purging the Auto-Add Database 39
Optimizing Your Deployment 40
Extending Your Solution 40
In This Topic 40
Benefits 40
Creating a Custom Solution 41
Windows Deployment Services PXE Server 41
Windows Deployment Services Client 42
Custom Solution Example 43
Instructions for Using the Sample Code 43
Sample Visual Basic Script 44
Sample Image Unattend File 45
Sample WinPESHL.ini File 46
Managing a Complex Environment 46
In This Topic 46
Managing a Server Remotely 46
Avoiding IP Address Conflicts 48
Testing by Using Virtual Computers 48
Versions of the Management Tools to Use with RIS and Windows Deployment Services 48
Optimizing Performance and Scalability 50
In This Topic 50
Best Practices for Avoiding Performance and Scalability Problems 51
Configuring the Server for Performance and Scalability 51
Performance and Scalability Expectations 52
Unicasting 52
Multicasting 54
Multicast Installation 54
Unicast Installation 55
Testing of Security Options with Multicast 56
Using Transport Server 56
In This Topic 56
Comparison of Deployment Server and Transport Server 57
Configuring Transport Server 58
Using a Transport Server to Boot from the Network 59
Using a Transport Server for Multicasting 59
How to create a namespace with Transport Server 59
Prerequisites for creating a namespace 59
To create a namespace 60
How to join a client computer to a namespace by using Wdsmcast.exe 60
How to perform common tasks 62
Options 63
Performing Unattended Installations 64
Automating the PXE Boot 65
In This Topic 65
Automating the PXE Boot 65
Avoiding a Boot Loop 65
Example Scenario 66
Automating the Selection of the Boot Image 66
Automating Setup 67
In This Topic 67
Creating Unattend Files 67
Automating the User Interface Screens of the Windows Deployment Services Client 68
Unattend File Settings 69
Automating the Remaining Setup Phases 71
Automating the Domain Join 72
In This Topic 72
Modifying Your Unattend Files 72
Choosing a Permissions Method 73
Automating the Image Capture Wizard 74
WDSCapture.inf Unattend File Settings 74
Advanced Unattended Installation Scenarios 77
In This Topic 77
Passing Unattend Files to Setup by Using the Command Line 78
Using Implicit Unattend Files 78
Embedding an Unattend File in an Image 79
Understanding Unattend File Precedence 79
Setting Command-Line Precedence for Image Unattend Files 80
Using Variables to Obtain Information from the Client 81
Sample Unattend Files 81
In This Topic 81
Windows Deployment Services Client Unattend Files 82
Example 1: Standard installation 82
Example 2: Install a language pack 84
Image Unattend Files for Windows Vista and Windows Server 2008 86
Example 1: Unsecure domain join 86
Example 2: Secure domain join 87
Example 3: Using variables 88
Image Unattend Files for Older Operating Systems 89
Example 1: Domain join 89
Example 2: Using variables 89
Example 3: Run a script 90
Combined Image and Client Unattend File 91
Image Capture Wizard Unattend File 95
Working with Images 96
Creating Images 96
In This Topic 96
Image Types 96
Boot Images 97
Creating Custom Boot Images 97
Versions of Windows PE 97
Discover Images 98
Creating Custom Discover Images 99
Capture Images 100
Comparison of ImageX and Image Capture Wizard 100
Creating Custom Capture Images 101
Converting RIPREP Images 101
Default Conversion 102
In-Place Conversion 102
Deploying Earlier Versions of Windows 102
Filtering Images 104
Automatic Filtering by Windows Deployment Services 104
Filtering Images Manually 104
Servicing Images 105
In This Topic 105
Types of Servicing 105
Servicing an Image Offline 105
Reducing the Size of Images 106
Storing and Replicating Images Using DFS 107
Storing Files on Another Server 107
Replicating Images 108
How to Perform Common Tasks 109
How to Manage Your Server 110
General Tasks 112
To configure Windows Deployment Services 112
To start or stop the server 113
To enable the server 113
To enable logging for the Windows Deployment Services client 114
To choose the port number for RPCs 114
To specify the network interfaces for Windows Deployment Services to listen on 115
To configure how often the server refreshes its settings 115
To force the server to update files in the RemoteInstall folder 116
To configure the network profile for the server 116
To back up the server data 116
DHCP 117
To configure Windows Deployment Services to run on the same computer as Microsoft DHCP 117
To configure Windows Deployment Services to run on the same computer as non-Microsoft DHCP 117
To turn on the DHCP authorization requirement 118
To authorize the server in DHCP 118
Client Requests 119
To configure the server to answer clients 119
To set a delay in the server’s answers to PXE requests 120
To configure unknown clients to perform PXE boots without requiring F12 120
To configure clients who have booted without F12 to require a key press on subsequent boots 120
To configure the server to determine the architecture of booting clients 121
Client Boot Settings 121
To choose which boot images are displayed on x64-based computers 121
To choose the default network boot program for each architecture 121
To choose the default network boot program that does not require F12 for each architecture 122
To choose the default boot image for each architecture 122
Active Directory Domain Services 123
To specify a domain controller for Windows Deployment Services 123
To specify a global catalog server for Windows Deployment Services 123
To choose whether to search for computer accounts in the domain controller before searching the global catalog 124
To configure the server to prestage clients by using their MAC address instead of their GUID 124
To maintain a list of GUIDs that belong to multiple computers 125
To specify how to generate computer names 125
To specify the domain and OU in which to create computer accounts 126
To choose whether to join client computers to the domain 127
Unattend File 128
To choose a default unattend file for the Windows Deployment Services client 128
To specify whether an unattend file on the client computer will override a default unattend file 128
How to Manage Client Computers 129
Prestage Computers 131
To prestage a client computer 131
To prestage a client computer to boot from a different server 133
To prestage a client computer to use a network boot program other than the default 134
To prestage a client computer to use an unattend file other than the default for the Windows PE phase of unattended setup 134
To prestage a client computer to use a boot image other than the default 134
To prestage a client computer to join a domain 135
To view the attributes of a prestaged client 135
Configure the Auto-Add Policy 136
To enable the Auto-Add policy 136
To change the length of time approved computers are held in the Auto-Add database 137
To change the length of time rejected and pending computers are held in the Auto-Add database 137
To delete the approved or rejected computers table 137
Specify Settings for Pending Computers 138
To change the rate at which pending computers will poll the server 138
To change the number of times pending computers will poll the server 138
To change the message displayed to pending computers 138
To set a default network boot server for pending computers 139
To set a default network boot program for pending computers 139
To set a default unattend file for pending computers 139
To set a default boot image for pending computers 140
To set domain join options for pending computers 140
Approve and Reject Pending Computers 141
To view the list of computers that are pending approval 141
To approve a pending computer by using the default settings 141
To approve all pending computers by using the default settings 142
To approve a pending computer, but change a setting 142
To approve all pending computers, but change a setting 144
To reject a pending computer 144
How to Manage Images 145
General Tasks 146
To export an image from the server to a stand-alone .wim file 146
To replace an image on the server with an updated version 147
To remove an image 148
Boot Images 149
To add a boot image to the server 149
To set the attributes on a boot image 149
To display the attributes of a boot image 150
To create a capture image 150
To create a discover image 151
Install Images 152
To add an install image 152
To set the attributes for an install image 152
To display the attributes for an install image 153
To convert a RIPREP image to a .wim install image 153
To make a copy of an install image 154
Image Groups 155
To remove an image group 155
To add an image group to the image store 155
To set the attributes on an image group 155
To display information about all images in an image group 156
How to Create Multicast Transmissions 156
In This Topic 156
When to Implement Multicasting 157
Prerequisites for Creating a Multicast Transmission 157
Known Issues in Creating a Multicast Transmission 158
Transmission Types 158
To create a multicast transmission with Deployment Server 159
To manage transmissions 160
To manage clients in a transmission 161
To configure the UDP port range for multicasting 162
To configure how the server will obtain IP addresses for multicasting 163
Example Multicast Scripts 164
In This Topic 164
Stop Transmissions Slower than 1 MB per Second 164
Display Performance Information About Clients 169
How to Modify the BCD Store Using Bcdedit 172
In This Topic 172
To View the Contents of the BCD Store 173
To Configure the Default Selection Time-out Value 173
To Configure a Localized Boot Manager Experience 174
To Configure the TFTP Block Size 175
To Configure the TFTP Window Size 177
To Configure Windows Debugger Options 177
To Turn On Emergency Management Services Settings 180
Troubleshooting 183
Troubleshooting Performance Problems 183
In This Topic 183
Analyzing Blockages in Each Phase of Installation 183
PXE Boot Phase 183
TFTP Download Phase 184
Diagnosing TFTP Download Performance Problems 184
Addressing TFTP Download Performance Problems 185
Image Apply Phase 186
Diagnosing Performance Problems in the Image Apply Phase 186
Addressing Performance Problems in the Image Apply Phase 186
Using Performance Monitoring 187
Common Problems 190
Performing PXE Boots on Client Computers 191
I am unable to perform PXE boots on client computers. 191
When I perform a PXE boot and select a boot image, I see a command prompt. 192
The client computer fails to get an IP address when I try to PXE boot. 192
The client computer obtains an IP address but then fails to download a NBP. 193
I don't see the hard drive of the client computer on the disk configuration page of Setup. 193
My computer loads the boot image, but it cannot access an install image. 193
I created an unattend file, but when installation completes, my client computer is not joined to the domain. 193
Install images do not appear on the image selection page. 193
Troubleshooting x64-Based Client Computers 194
My x64-based client computer does not have any x64-based images on the boot image selection page. 194
My x64-based client computer is detected as x64, but it fails to boot to the default image. 194
Performing Management Operations 194
I can't approve a pending computer. 194
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. 194
I received the error: "0x2: File not found" when trying to manage a remote Windows Deployment Services server. 195
Creating Custom Install Images 195
When using Image Capture Wizard to create a custom image, the volume that contains my image is not selectable. 195
The finish button is not enabled on the final page of the image capture wizard. 196
Multicasting 197
My multicast transmissions are running very slowly. 197
After enabling multicasting, there is excessive traffic on the network. 197
Logging and Tracing 197
Network Ports Used 201
Protocols 201
Ports 202
Required Permissions 203
In This Topic 203
General Permissions 203
Permissions for Common Management Tasks 204
Permissions for Client Installations 208
Permissions for Server Properties 211
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 . For information about what is new in each version of Windows Deployment Services, see Windows Deployment Services: What's New ().
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 .
• 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@.
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:
• 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 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.
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 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.
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.
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 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 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 .
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.
[pic]To enable the language-neutral page and language selection
|1. In the Windows Deployment Services MMC snap-in, right-click the desired boot image and then click Disable. |
|2. Export the image. |
|3. Using ImageX, mount (read/write) the image marked as RAMDISK bootable (usually the second image in the Boot.wim file). |
|4. Copy the setup MUI resource files and their associated folder to the \Sources directory of the mounted boot image. For |
|example, to add the German setup resource files to your English boot image, copy the \Sources\de-de directory and all of |
|its contents to your mounted boot image at C:\Mount\Sources. At the end of this process, you should have two sets of setup|
|resource files: English at \Sources\en-us, and German at \Sources\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 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 ()
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 .
• 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.
• 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\\Langpacks and then copy the language folder and language pack to this location. For example, the German language pack would be stored at C:\RemoteInstall\Images\Image1\Langpacks\de-DE. Also note that you cannot remove language packs during the installation by using Windows Deployment Services.
A language pack is applicable to all versions of Windows Vista (except for Windows PE 2.0, which has its own language packs separate from Windows Vista). However, a language pack is applicable only to a specific version of the operating system — that is, language packs are not backward-compatible. If a language pack was created for Windows Vista, you can apply it only to Windows Vista. If you install a service pack on Windows Vista, you cannot apply the Windows Vista language pack. The applicability rule is enforced at install time by Component-Based Servicing (CBS). Thus, although it is possible to associate an incorrect language pack with a particular version of an image, the installation of the language pack will fail when the installation starts.
Configuring DHCP
In This Topic
• Configuring DHCP Options
• Enabling DHCP Authorization
• Authorizing a Server
Configuring DHCP Options
The booting client and the server communicate using Dynamic Host Control Protocol (DHCP) packets. The Windows Deployment Services solution for booting over the network works well in many configurations. It works well when Windows Deployment Services is located on the same physical computer or on a different physical computer from the DHCP server. However, the default installation is that Windows Deployment Services and a DCHP server (Microsoft or 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.
[pic]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 ().
If DHCP is installed on a server that is located in a different subnet, you will need to do one of the following: configure your IP Helper tables (recommended) or add DHCP options 66 and 67. For more information about these settings, see Managing Network Boot Programs.
Enabling DHCP Authorization
By default, the PXE server for Windows Deployment Services does not need to be authorized to service client computers. However, you can enable DHCP authorization (which is also known as rogue detection). You may want to enable this authorization for the following reasons:
• To help prevent an improperly configured PXE server on the network. You can do this by requiring that only those servers that you authorize can service clients. This is not a security protection mechanism, but it can help ensure that a PXE server that is not approved does not service clients. Furthermore, DHCP authorization applies only to computers that are joined to the Active Directory Domain Services (AD DS) structure of the corporate network. For example, if a corporation had a forest, a malicious user could plug a computer into the corporate network, install Windows Server® 2008, run Dcpromo, create a forest, install Windows Deployment Services, and then authorize it.
• Your IT department has a policy that only authorized servers should be both PXE servers and DHCP listeners.
Authorization checks occur only if authorization checking is enabled and the PXE server is configured to listen on port 67. This means that authorization checks take place only in scenarios where Windows Deployment Services is running on a computer without DHCP. If Windows Deployment Services and DHCP are running on the same physical computer, then the DHCP server is listening on port 67, and it is responsible for making sure that it is authorized properly. Note that the PXE server will not perform any additional checks. You can enable this authorization using the following methods:
• Using the Windows Deployment Services MMC snap-in. To do this, right click the server, click Properties and on the Advanced tab, select Yes, Windows Deployment Server should be authorized in DHCP before servicing clients.
• Using WDSUTIL by running WDSUTIL /Set-Server /RogueDetection:Yes.
• Using the DHCP MMC snap-in. To do this, on the DHCP server, click Start, point to Administrative Tools, and then click DHCP.
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.
[pic]To delegate permissions to authorize the server
|1. Open the Active Directory Sites and Services MMC snap-in. |
|2. On the View menu, click Show Services Node. |
|3. Click Services. |
|4. Right-click NetServices, and then click Properties. |
|5. On the Security tab, assign the following permissions to the users or groups for which you want to authorize these |
|servers: Read, Write, and Create all child objects. |
|6. Click Advanced. Click the user or group you just added, and then click Edit. |
|7. In the Apply to box, click This object and all descendant objects. |
The environment that the Windows Deployment Services server is in influences the authorization behavior:
• NT4 domain. If the PXE server is part of an NT4 domain, no authorization is performed and the PXE server will service requests. This mode is supported only if the PXE server is running with a custom non-Microsoft PXE provider. Windows Deployment Services requires AD DS; therefore, it cannot operate if joined only to an NT4 domain.
• Windows Server 2000 or later domain. If the PXE server is part of a Windows Server 2000 or later domain (meaning that AD DS is present), it queries AD DS to determine its authorization state.
• Workgroup. If the PXE server is part of a workgroup, it can service client requests as long as other DHCP servers on the same subnet are not part of a domain. If a DHCP server that is part of a domain comes online, the PXE server will stop servicing requests.
• Windows Small Business Server 2003.If the PXE server is part of a Small Business Server 2003 domain, it must be the only DHCP server on the network. If another DHCP server exists or comes online, the PXE server stops servicing requests.
Managing Network Boot Programs
A network boot program (NBP) is the first file that is downloaded and executed as part of the 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
[pic]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: /BootProgram:). 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 |
| |(Default) Requires the user to press the F12 key for a PXE |x86-based and |BIOS |
| |boot to continue. |x64-based | |
|PXEboot.n12 |Does not require pressing F12 and immediately begins a PXE |x86-based and |BIOS |
| |boot. |x64-based | |
| |Boots the computer by using the next boot item in the BIOS |x86-based and |BIOS |
| |without waiting for a time-out. |x64-based | |
| and |Causes computers that do not support firmware console |x86-based and |BIOS |
| |redirection to display "Press space or F12 for network boot,"|x64-based | |
| |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 console redirection |x86-based and |BIOS |
|Hdlscom2.n12 |will not display the prompt "Press space or F12 for network |x64-based | |
| |boot" and the computer will not wait for user input. | | |
|Bootmgfw.efi |The EFI equivalent for Bootmgr.exe. In EFI, the choice of |x64-based and |EFI |
| |whether or not to perform a PXE boot is handled within the |Itanium-based | |
| |EFI shell, and not by the NBP. | | |
| |An NBP developed for Windows Deployment Services that serves |x86-based and |BIOS |
| |the following general purposes: |x64-based | |
| |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:
• 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.
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. 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.
[pic]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 (which will not exist on the backend Windows Deployment Services server if the server is in Native mode on Windows Server 2003, or if you are running Windows Server 2008).
Referral Examples
Referrals are classified based on the number of jumps the client must make before it downloads and executes an NBP. The following table contains three examples of referrals. Each of these examples supports the referral of x86-based or x64 BIOS-based clients, but does not support the referral of Itanium-based and x64 EFI-based clients
|Example |Details |
|First order referral from PXE |ComputerA sends a DHCP broadcast packet and receives an IP address lease from a DHCP server and a |
|server |response from PXE Server1. ComputerA contacts PXE Server1 directly on port 4011. PXE Server1 refers |
| |the client to download \boot\ from Server2. The client computer downloads from |
| |Server2. |
| |Requirements: |
| |• The NBP that the client computer is directed to download from the TFTP server (Server2 in this |
| |example) must be . |
| |• The network boot server performing the referral (PXE Server1 in this example) must be running |
| |Windows Deployment Services. |
|First order referral using |ComputerA sends a DHCP broadcast packet and receives an IP address lease from a DHCP server. The |
|DHCP options |lease also contains values for DHCP options 66 and 67, referring the client to download the file |
| |\boot\ x86\ from Server1. The client computer downloads from Server1. |
| |Requirement: |
| |• The NBP that the client computer is directed to download from the TFTP server (Server1 in this |
| |example) must be . |
|Second order referral using |ComputerA sends a DHCP broadcast packet and receives an IP address lease from a DHCP server. The |
|both DHCP options and PXE |lease also contains values for DHCP options 66 and 67, referring the client to download the file |
|server |\boot\ x86\ from PXE Server1. The client computer downloads from PXE Server1. |
| | contacts PXE Server1 on port 4011. PXE Server1 refers the client to download the |
| |\boot\x86\ from Server2. The client computer downloads from Server2. |
| |Requirements: |
| |• The NBP that the client computer is directed to download from the PXE server (PXE Server1 in this |
| |example) must be . |
| |• The NBP that the client computer is directed to download from the TFTP server (Server2 in this |
| |example) must be . |
| |• 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 () before downloading the normal NBP for the client’s architecture. performs an architecture detection test on the client processor and then reports the value back to the server, using a DHCP packet. After the server receives the information, it sends the correct NBP to the client.
When enabled, architecture detection is performed on every x86-based computer in the environment. This feature is turned off by default because the detection process adds time to boot, increases network traffic, and increases the server's load. You can enable architecture detection by running the command WDSUTIL /Set-Server /ArchitectureDiscovery:Yes.
Avoiding a Boot Loop
When implementing an automated experience of booting from the network, it is often necessary both to set the network as the first device in the client’s BIOS boot order and to send a specific client the .n12 NBP. If you combine these two configurations, the client will automatically boot from the network without requiring user intervention, and the computer will end up in a circular loop (always booting from the network and never from the hard disk drive). To work around this scenario, you should perform the following steps:
1. Prestage the device (see Prestaging Client Computers).
2. Set the BIOS boot order on the computer such that the computer always boots from the network.
3. Set the appropriate .n12 NBP for the computer's architecture (using the Boot tab of the server’s properties).
4. Turn on the computer, and let it boot from the network.
When you configure the installation in this way, the path to the NBP will be reset after the image is applied, as one of the final actions performed by Windows Deployment Services. This ensures that on the next boot, the computer will receive the default server NBP (commonly the .com version). Therefore, the computer will try to boot from the network (because the network is first in the BIOS boot order), but the computer will be sent the .com NBP. After waiting for the user to press the F12 key, this option will time out and the device will boot from the hard disk drive.
Managing the Boot Menu
A boot menu is displayed on a client computer when the client performs a Pre-Boot Execution Environment (PXE) boots and more than one boot image is available to that client. If only one boot image is available, the computer will automatically boot into that image. The boot images are ordered alphabetically, based on the file name of the .wim file that contains the image.
In This Topic
• Configuring the Boot Menu
• Specifying Boot Images for Prestaged Clients
• 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 .
To customize the BCD store, see How to Modify the BCD Store Using Bcdedit. Note that when you modify the BCD store, you must force it to be recreated in order for your changes to take effect. To do this, either restart the WDSServer service (run wdsutil /stop-server and then run wdsutil /start-server) or run Sc control wdsserver 129. Because the menu exists outside of an operating system, there are certain limitations placed on the user interface (UI), including the following:
• The screen size is 80x25 pixels, which means that approximately 13 images can be displayed on the page simultaneously. If more than 13 images are available, the display will scroll to support the additional images. The number of images that can be shown is dependent on several factors, including the number of images that need to be displayed to the client and the number of characters in the image name.
• There is no mouse or Input Method Editor (IME) functionality.
• There is no support for alternate keyboards, other than what the BIOS supports.
• There is limited support for localization, other than what the BIOS supports.
• There is limited support for accessibility.
Specifying Boot Images for Prestaged Clients
You can assign a boot image to a prestaged computer in Active Directory Domain Services (AD DS). For instructions, see the "Prestage Computers" section in How to Manage Client Computers. In these instances, Windows Deployment Services must dynamically create a BCD store for the booting client that has the assigned boot image selected as the default. Rather than generating a unique BCD store that contains only that operating system entry for each booting client (which, due to the BCD architecture may take several seconds), the existing BCD store for the client’s architecture (in RemoteInstall\Tmp) is copied and the default selection is modified to reflect the new default. In addition, other booting clients that have been assigned the same boot image can reuse this dynamically generated BCD store.
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 boot program will detect the architecture of the booting client and report that value back to the Windows Deployment Services server. For more information, see the "List of NBPs" section in Managing Network Boot Programs.
Prestaging Client Computers
In This Topic
• Creating Computer Account Objects in AD DS
• Benefits
• Enabling the Auto-Add Policy
• Purging the Auto-Add Database
Creating Computer Account Objects in AD DS
You can use Windows Deployment Services to link physical computers to computer account objects in Active Directory Domain Servers (AD DS). This is called prestaging the client. Prestaged clients are also called known computers. This allows you to then configure properties on the computer account to control the installation for the client. For example, you can configure the network boot program and the unattend file that the client should receive, as well as the server from which the client should download the network boot program. You can create a computer account object and associate it with a physical computer using the following methods:
• Using WDSUTIL. You can prestage client computers before they have attempted a network boot, by running WDSUTIL /Add-Device /Device: /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).
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).
[pic]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:.
By default, computers with an approved status will be deleted every 30 days. In addition, to delete a prestaged computer that was added to AD DS by using the approval process, you must perform two steps. First, you must delete the computer from AD DS. Second, you must delete the computer's record in the Auto-Add database. Failing to purge the database will cause the client to be stuck in 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 until a prestaged computer appears in AD DS.
[pic]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:
• 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 .
Windows Deployment Services PXE Server
The PXE server implementation in Windows Deployment Services consists of a PXE server and a PXE provider. The PXE server contains the core networking capability: it binds to network interfaces, listens for incoming PXE requests, and formats the Dynamic Host Control Protocol (DHCP) response packets. The PXE server supports a plug-in interface. Plug-ins are also known as PXE providers, and they provide the business logic. The server and provider enable you to develop custom PXE solutions while taking advantage of the core PXE server networking code base. The PXE server logic in Windows Deployment Services has two main features:
• A default provider that you can change. The provider installed by default with Windows Deployment Services is BINLSVC, which is implemented in the DLL, Binlsvc.dll. You can remove this PXE provider from the server and replace it with a custom-written provider.
• Support for multiple providers on a single server. Rather than having two PXE listeners on the network (each with its own application logic), you can have multiple providers. This means that you can have only one PXE listener on a network that has two or more sets of application logic.
With this PXE server implementation, you can perform either of the following tasks:
• Create a PXE plug-in for a stand-alone PXE server (for example, a server that is not joined to or communicating with an Active Directory Domain Services (AD DS) domain). The plug-in might use a .txt file, an .xml file, or a SQL database as its data store.
• Enable a second, registered provider to offer functionality without disrupting or reconfiguring Windows Deployment Services. One of the most powerful implementations available is writing a filter provider, which is an additional PXE provider that resides above BINLSVC (or any other PXE provider) in the ordered provider list. This filter provider acts as a gate before the next provider in the list, enabling the next provider to service selected clients by passing some requests and filtering others.
Windows Deployment Services Client
The Windows Deployment Services client is a graphical user interface (UI) that is built on Setup.exe in Windows Vista (it contains additional logic that is specific to Windows Deployment Services). The Windows Deployment Services client has the ability to establish a communication channel with a Windows Deployment Services server. This channel provides a mechanism for authentication and for retrieving a list of install images stored on the server. In addition, the Windows Deployment Services client sends progress and status messages to the server while the image is being installed. The library within the Windows Deployment Services client includes the following functionality:
• The ability to authenticate and enumerate images that are stored on a Windows Deployment Services server
• The ability to send client installation events that can be used for reporting and monitoring purposes (for example, sending notifications that the client installation has started or has finished)
The following is a common scenario that uses this functionality.
1. A computer boots into a boot image that contains the Windows Vista Setup files. The client can boot in any of several ways (from a CD, DVD, or hard disk drive, or over the network).
2. A custom application (with a custom UI) is started.
3. The application detects the computer's MAC address and contacts a database to acquire the correct unattend file.
4. The application uses the Windows Deployment Services client library to retrieve a list of available images stored on a Windows Deployment Services server and displays the list of choices to the client (by using the custom UI).
5. The application deploys the image that the user selects, and it also copies the unattend file that was acquired previously.
6. The application sends progress and status messages to the server by using the functionality provided by the Windows Deployment Services client library.
Custom Solution Example
Remote Installation Services (RIS) offered three options for naming a computer:
• Automatic: The computer name is automatically generated, and the client computer account is created in a particular organizational unit (OU), based on the policy that is implemented.
• Custom: The person performing the installation specifies the computer name and OU. These values override the dictated server policy.
• Administrator. The person performing the installation specifies the computer name and OU after the installation is completed.
Installations using the Windows Deployment Services client offer the Automatic and Administrator options. There are methods for achieving the Custom option, but they generally involve prestaging the device, either manually or by using Auto-Add functionality. Microsoft recommends using Business Desktop Deployment (BDD) to implement the Custom scenario. However, you can also provide this functionality with a few changes to your boot image, as illustrated in the sample scripts later in this topic..
The Microsoft Visual Basic® script at the end of this document does the following:
1. Starts running from within Windows PE and gathers a computer name and OU (in distinguished name form) from the user.
2. Runs the command setup.exe /wds /noreboot. At this point, the Windows Deployment Services installation proceeds, and Setup does not restart as normal after finishing the Windows PE phase.
3. Edits the unattend file to add the computer name and OU that were entered by the user. Note that the image that is selected needs an image unattend file that specifies the computer name and OU. When the script is finished, the client will reboot if the script is the last (or only) executable file listed in the WinPEshl.ini file.
Instructions for Using the Sample Code
To use these scripts, perform the following procedure to use these sample files.
1. Export a copy of a boot image from your server.
2. Mount the boot image as read/write. (Remember, the second image in the Boot.wim file is marked as RAMDISK bootable, and it contains the Setup files).
a. Create a custom Winpeshl.ini file, and then copy it to the \Windows\System32 folder of the mounted image.
b. Create a custom script (for example, domainOU.vbs) by using the sample code in the section following this procedure. Copy this script to the mounted image's \Sources folder.
3. Unmount the image, and then commit the changes.
4. Add the image back to your Windows Deployment Services server.
5. Create an image unattend file similar to the sample file (Sample Image Unattend File).
6. Associate the unattend file with an install image.
7. Boot a client into the updated boot image.
8. Select the install image associated the unattend file.
The script starts running when Windows PE boots. It shows a basic UI which enables the user to enter the computer name and the computer OU. The script performs the install and then replaces all occurrences of %COMPUTERNAME% with the value specified in the message box, as well as replacing all occurrences of %OU% with the value specified in the message box. Remember that the OU must be entered in a distinguished name form — for example, OU=MyOU,DC=Domain,DC=com.
Sample Visual Basic Script
Option Explicit
Dim computerName, OU, unattendFile, WshShell, result, fso, unattendFileObject, strContents
'----------------------------------------------------------------------
unattendFile = "C:\Windows\Panther\unattend.xml"
' end user defined settings
'----------------------------------------------------------------------
Set WshShell = WScript.CreateObject("WScript.Shell")
dim answer
do while answer vbYes
computerName = InputBox("Enter the desired computer name", "Computer Name")
OU = InputBox("Enter the distinguished name of the desired OU", "Organization Unit")
answer = MsgBox("Is this correct?" & vbCrLf & vbCrLF & "Name: " & computerName & vbCrLF & "OU: " & OU, vbYesNo, "Computer Account Details")
loop
WshShell.Run "%SYSTEMDRIVE%\sources\setup.exe /wds /noreboot", 0, true
Set fso = CreateObject("Scripting.FileSystemObject")
if fso.FileExists(unattendFile) = false then
wscript.echo "Couldn't find unattend file"
else
'Read the unattend file in and replace apprpriate variables
Set unattendFileObject = fso.OpenTextFile(unattendFile, 1)
strContents = unattendFileObject.ReadAll
strContents = Replace(strContents, "%OU%", OU)
strContents = Replace(strContents, "%COMPUTERNAME%", computerName)
unattendFileObject.Close
'Write the updated contents back to the unattend file
Set unattendFileObject = fso.OpenTextFile(unattendFile, 2)
unattendFileObject.Write(strContents)
unattendFileObject.Close
End If
Sample Image Unattend File
The following is a sample image unattend file.
false
%OU%
MyDomain
MyUserName
MyPassword
%MACHINEDOMAIN%
%COMPUTERNAME%
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
[pic]Note
When performing Pre-Boot Execution Environment (PXE) referrals in an environment that includes Windows Deployment Services and RIS, the Windows Deployment Services server must answer PXE requests and perform referrals. If a RIS server attempts to refer a client computer to a Windows Deployment Services server that is running in Mixed mode or Native mode, the client computer will receive an incorrect network boot program, which may cause the client to fail to boot.
Managing a Server Remotely
In addition to running Windows Deployment Services locally, you can also manage Windows Deployment Services remotely using the following methods.
|Method |Explanation |
|Managing from another |To do this, you must specify which server you want to manage. You can do this in either of the |
|Windows Deployment Services |following ways: |
|server |• Using the Windows Deployment Services MMC snap-in. First you must add the server to the console. To|
| |do this, right-click the Servers node and then click Add Server. Next, type the name of the server |
| |you want to add, or select it in the list. The server will be added to the left pane in the console, |
| |and you can perform any task by selecting it just as you would select the local server. |
| |• Using WDSUTIL. To specify a remote server to run a WDSUTIL command, append /Server: to the |
| |command. For example: |
| |WDSUTIL /Add-Image /ImageFile:C:\images\capture.wim /Server:MY-WDS-02 /ImageType:Boot |
|Managing from a remote |To do this, you can install Remote Server Administration Tools, which will install WDSUTIL and the |
|server that is running |Windows Deployment Services MMC snap-in on the server. To install Remote Server Administration Tools,|
|Windows Server 2008 (but not|open Server Manager, right-click the Features node, click Add Features, and then click Remote Server |
|Windows Deployment Services)|Administration Tools. Next clickRole Administration Tools, and then click Windows Deployment Services|
| |Tools. |
|Using PsExec |You can also manage the server by using PsExec. For example: psexec \\ \wdsutil |
| |/get-device /id: |
| |For information about using PsExec, see . |
Avoiding IP Address Conflicts
When two servers select the same multicast IP address to send content to, content intended for clients of either server can be routed to all clients. This causes unnecessary network traffic. Note also that this is particularly harmful if the servers are connected by a low-bandwidth connection (such as a wide area network (WAN) link), because both sets of content will be sent over this connection. The following are preventive measures that you should take to avoid this situation:
• Use a Multicast Address Dynamic Client Allocation Protocol (MADCAP) server to allocate multicast IP addresses. This will prevent addresses from being assigned twice.
• Configure a static range for each server, making sure that this range does not overlap with the ranges defined for other servers.
• Lower the multicast Time-To-Live (TTL) setting to prevent the routers from forwarding multicast traffic outside the site network. You can also configure your border router not to forward multicast traffic.
To modify these options, right-click the server in the MMC snap-in, click Properties, and then click the Network Settings tab.
Testing by Using Virtual Computers
Windows Deployment Services should work on virtual computers, but note that the performance will often be degraded, particularly during the Trivial File Transfer Protocol (TFTP) download phase. This phase is very resource-intensive and may fail if insufficient resources are available on the host computer. Also, performing a PXE boot on a virtual computer or virtual server can take 20 minutes or longer when you are using Windows Deployment Services. To resolve this, we recommend that you use a discover image instead of PXE in the BIOS of the virtual computer. In addition, we recommend that you use virtual computers for either client computers or servers, but not both.
Versions of the Management Tools to Use with RIS and Windows Deployment Services
There are three server configurations that you may need to manage in a production environment, and each of them has a different set of management tools. The following table lists these server configurations and the versions of the management tools that are included for each of them. Note that I indicates version 1, and II indicates version 2.
|Tool and operating system |Management tools |
|Remote Installation Services servers running Windows Server 2003 |• RISETUP (I) |
| |• RIPREP (I) |
|Windows Deployment Services servers running Windows Server 2003 |• RISETUP (II) |
| |• RIPREP (II) |
| |• WDSUTIL (I) |
| |• MMC snap-in (I) |
|Windows Deployment Services servers running Windows Server 2008 |• WDSUTIL (II) |
| |• MMC snap-in (II) |
The Windows Deployment Services management tools enable you to manage a remote server. Note, however, that there are some restrictions regarding which versions of the tools will work on which server versions. The following table lists the seven possible configurations and the versions of the tools that you should use with each environment. Essentially, you should use the latest available version of each tool. For example, see the sixth row in the table: if you have servers running the 2003 and 2008 versions of Windows Deployment Services, you should use RISETUP (II), RIPREP (II), WDSUTIL (II), and WDSMMC (II)
[pic]Note
You cannot manage a Windows Deployment Services server running Windows Server 2008 from a Windows Deployment Services server running Windows Server 2003.
|Servers running |Servers running Windows |Servers running Windows|Tools that you should use |
|RIS on Windows |Deployment Services on |Deployment Services on | |
|Server 2003 |Windows Server 2003 |Windows 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) |
| | | |• 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.
• 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.
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 |
[pic]Note
Network configuration for the high-end server involved connecting the server’s GB network adapter to a GB switch, which was connected to 100-MB switches that supported a GB back-plane configuration.
Time elapsed during the image apply phase
This table shows the approximate time (in minutes) from start to finish that it took for all of the clients to apply an install image.
|Number of clients |Low-end |Mid-range |High-end |
|1 |25 |25 |25 |
|10 |61 |55 |25 |
|25 |125 |117 |25 |
|50 |235 |220 |35 |
|75 |355 |330 |45 |
Time elapsed during the TFTP download phase
The following table shows the time (in seconds) it took to download Boot.wim using TFTP.
|Number of clients |Low-end |Mid-range |High-end |
|1 |70 |55 |40 |
|10 |210 |145 |75 |
|25 |450 |360 |120 |
|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 adapter |Number of clients |Default |4,000 |8,000 |16,000 |32,000 |
|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 processor 5150 |• 64-bit version of Windows |
| | |• 2.67 Ghz |Server 2008 |
| | |• 8 GB of RAM | |
|Client |100 megabits network adapter |• Varied but capable of installing|• |
| | |the x86-based version of Windows | |
| | |Vista | |
Multicast Installation
| |25 clients |100 clients |300 clients |
| |Restart computer and |Restart computer and start|Restart computer and |
| |start clock. |clock. |start clock. |
|Time when the first client started download of boot |:23 |:21 |:23 |
|image using TFTP | | | |
|Time when the last client finishes download of boot |1:02 |2:40 |7:16 |
|image using TFTP | | | |
|Time when the first client started the multicast |3:04 |3:55 |8:18 |
|transfer | | | |
|Time when the last client finished the multicast |6:06 |7:54 |12:30 |
|transfer | | | |
|Total amount of time until the last client reached the |19:47 |22:40 |27:40 |
|desktop | | | |
Unicast Installation
| |SMB 25 clients |SMB 100 clients |SMB 300 clients |
| |Restart computer and |Restart computer and |Restart computer and |
| |start clock. |start clock. |start clock. |
|Time when the first client started download of boot |:21 |:22 |:20 |
|image using TFTP | | | |
|Time when the last client finished download of boot |:58 |2:40 |7:13 |
|image using TFTP | | | |
|Time when the first client started image transfer using|3:14 |4:38 |8:29 |
|unicast/SMB | | | |
|Time when the last client started image transfer using |13:36 |38:15 |1:47:58 |
|unicast/SMB | | | |
|Total amount of time until the last client reached the |20:59 |45:37 |1:55:15 |
|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 transfer of the|Clock started |Clock started |Clock started |
|install image to the client | | | |
|End of multicast transfer of the |2:19 |2:27 |31:05 |
|install image to the client | | | |
|Percentage of CPU used during the |~5% |~11% |~25% |
|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.
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 Configuration Protocol |Does not require other servers in the |
| |(DHCP), and Dynamic Name Services (DNS) in the |environment. |
| |environment. | |
|PXE |Supports PXE boot with the default PXE provider. |A PXE provider is not installed so you must|
| | |create a custom PXE provider. |
|Image server |Includes the Windows Deployment Services image |Does not include the Windows Deployment |
| |server. |Services image server. |
|Transmission method |Allows both unicasting and multicasting. |Allows only multicasting. |
|Management tools |Is managed using either the Windows Deployment |Is managed only by the WDSUTIL command-line|
| |Services MMC snap-in or the WDSUTIL command-line |tool. |
| |tool. | |
|Application on the client |Uses the Windows Deployment Services client (which is|Uses only Wdsmcast.exe or custom |
|computer |basically Setup.exe and supporting files), |application. |
| |Wdsmcast.exe (which is included in the Windows AIK), | |
| |or a custom multicast application. | |
The server architectures are illustrated in the following diagram. The blue parts are installed with Transport Server and the Deployment Server. The 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.
[pic]
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: /End: at an elevated command prompt.
• Set the network profile. The network profile specifies the network speed of the Transport Server. Each profile contains settings to optimize performance for the specified speed (such as the maximum transport window size, the transport cache size, and the block size). You can view the profiles at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\Multicast\Profiles. Specify Custom if you want to customize the settings yourself by editing the registry. You should not modify the other profiles that are provided. You should use the custom profile even if you only want to change one setting. To set the profile, run WDSUTIL /Set-TransportServer [/Server:] /Profile:{10Mbps|100Mbps|1Gbps|Custom} at an elevated command prompt.
• Set the UDP port range. To do this, run WDSUTIL /Set-TransportServer [/Server:] /StartPort:x /EndPort:y at an elevated command prompt.
Using a Transport Server to Boot from the Network
A PXE server consists of two parts: a PXE listener that accepts incoming traffic, and a PXE provider that determines how best to respond to it. Transport Server contains only the PXE listener. In order to use Transport Server to boot a computer from the network, you will need to write a custom PXE provider, and register the provider with Windows Deployment Services, as documented in the Windows Server 2008 Software Development Kit (SDK).
Using a Transport Server for Multicasting
The multicast server in Windows Deployment Services also has two parts – the multicast provider (which transmits data over the network) and the content provider (which understands the data and passes it to the multicast provider). The content provider (installed with both Transport Server and Deployment Server) can be used to transfer any file. It also has specific knowledge of the .wim format, which it uses to transfer images while other images are added to the image group. You can create a custom content provider for cases where the default provider is not sufficient (for example when using Transport Server to deploy an operating system from inside a .vhd image). See the Windows Server 2008 SDK for guidelines and samples for authoring and registering the provider.
How to create a namespace with Transport Server
Transport Server transmits data by using multicast functionality through an object called a namespace. A namespace is analogous to a multicast transmission used by Deployment Server. A namespace consists of content to transfer (determined by the content provider with a configuration string), configuration settings (for example, Scheduled-Cast or Auto-Cast), and the names of connected clients. In this section:
• Prerequisites for creating a namespace
• To create a namespace
Prerequisites for creating a namespace
To create a namespace with Transport Server, you need the following:
• A content provider. You can use the Windows Deployment Services content provider (named WDS) that is included when you install Transport Server. Or you can create your own content provider by using the tools in the Windows Server 2008 SDK.
• 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:] /Namespace: /FriendlyName: [/Description:] /ContentProvider: /ConfigString: /NamespaceType:ScheduledCast [/Time:] [/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:] /Namespace: /FriendlyName: [/Description:] /ContentProvider: /ConfigString: /NamespaceType:AutoCast
For example:
WDSUTIL /New-Namespace /FriendlyName:"Custom AutoCast Namespace" /Namespace:"Custom Auto 1" /ContentProvider:WDS /ConfigString:D:\Images /NamespaceType:AutoCast
How to join a client computer to a namespace by using Wdsmcast.exe
The Windows Deployment Services client user interface will not work with Transport Server. Therefore, to connect a client to a namespace, you have two options:
• Use Wdsmcast.exe, which is included in the Windows Automated Installation Kit (AIK). This is a command-line utility you can use to connect to any namespace or multicast transmission that uses the Windows Deployment Services content provider. For more information about this, see the following procedure. You can download the Windows AIK at .
• 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.
[pic]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: /Namespace: /Username: |
|[/Password:] /SourceFile: /DestinationFile: |
Syntax:
|Option |Description |
|/Server: |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: |The name of the namespace. This value should match the name given when creating the namespace|
| |on the server. This is not the "friendly" name, and it must be unique. |
| |[pic]Note |
| |When using this option with Deployment Server, the syntax is as follows: |
| |/Namespace:WDS://. For example: WDS:ImageGroup1/install.wim/1 |
| |[pic]Note |
| |To view all namespaces that currently exist on the server, run WDSUTIL /get-allnamespaces. |
|/Username: |The domain name and user name to connect to the server. These can be either in the format |
| |Domain\User or the format User@Domain. |
|[/Password:] |The password for the user. If this is not specified, you will be prompted to enter it. |
|/SourceFile: |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: |The complete file path and name for the destination file. |
How to perform common tasks
The following are the most commonly used commands with Transport Server. For more information about each parameter, see Options.
• To start the transmission. To start a transmission, the transmission must be a Scheduled-Cast namespace, and there must be at least one client that has requested the transmission of data.
Syntax: WDSUTIL /Start-Namespace /Namespace:
• 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: /Show:Clients
• To remove a namespace
Syntax: WDSUTIL /Remove-Namespace [/Server:] /Namespace: [/Force]
For example:
• To remove the namespace after current client downloads are complete, run:
WDSUTIL /Remove-Namespace /Namespace:"Custom Auto 1"
• To remove the namespace immediately and stop any current client downloads, run:
WDSUTIL /Remove-Namespace /Server:MyWDSServer /Namespace:"Custom Auto 1" /Force
• To stop a client installation completely
Syntax: WDSUTIL /Disconnect-Client /ClientID: /Force
[pic]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:
• To view the client for each namespace
Syntax: WDSUTIL /Get-Namespace /Namespace: /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: |The name of the Windows Deployment Services server. This can be either the NetBIOS name or the FQDN. |
| |If the server name is not specified, the name of the local server will be used. |
|/Namespace: |The name of the namespace. This value should match the name given when creating the namespace on the |
| |server. Note that this is not the "friendly" name, and it must be unique. |
| |[pic]Note |
| |When using this option with Deployment Server, the syntax is as follows: |
| |/Namespace:WDS://. For example: WDS:ImageGroup1/install.wim/1 |
| |[pic]Note |
| |To view all namespaces that currently exist on the server, run WDSUTIL /get-allnamespaces. |
|/FriendlyName: | |
|/Description: |A short description of the namespace. |
|/ContentProvider: |The name of the content provider that supplies data to the multicast server. If you are using the |
| |Windows Deployment Services content provider, specify WDS. |
|/ConfigString: |content provider (WDS), specify the path to the folder where content is stored (for example, |
| |D:\Photos\Landscapes). This path can be anywhere on the server. |
|/NamespaceType: |The type of namespace to be created. |
|{AutoCast|ScheduledCast} | |
|/Time: |The time on the server when the namespace will start (note that you can set this option only for |
| |Scheduled-Cast transmissions). |
|/Clients: |The number of clients to wait for before the namespace will start (note that you can set this option |
| |only for Scheduled-Cast transmissions). |
|/Force |An option that deletes the transmission, even if there are current client installations. If you do |
| |not specify /Force, the transmission will be in the Delete Pending state, meaning that the |
| |transmission will be removed after clients' downloads are completed. |
Performing Unattended Installations
You can configure the entire deployment process using Windows Deployment Services to be without user interaction. To do this, you will need to automate the PXE boot, the selection of a boot image, and Setup.
• Automating the PXE Boot
• Automating Setup
• Automating the Domain Join
• Automating the Image Capture Wizard
• Advanced Unattended Installation Scenarios
• Sample Unattend Files
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.
[pic]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 (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\ 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 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:] /Architecture:{x86 | ia64 | x64} where 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: /BootImagePath:, where 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: option, and you must configure the command-line unattend precedence appropriately. For precedence information, see Advanced Unattended Installation Scenarios. For an example file, see Sample Unattend Files. In addition, Windows Deployment Services supports implicit unattend searching and can be used in conjunction with AutoUnattend.xml. For more information about implicit search paths, see Methods for Running Windows Setup at .
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 ()). 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.
[pic]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 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. |
|[pic]Note |
|The commands for this task are: To associate a client unattend file by architecture run WDSUTIL /Set-Server /WDSUnattend |
|/Policy:enabled /File: /Architecture:. To associate a client unattend file per computer, run WDSUTIL |
|/Set-Device /Device: /ID: /WDSClientUnattend: |
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 . For examples, see Sample Unattend Files.
|UI page |Component |Unattend setting |Explanation |
|Language-neutral |Microsoft-Windows-Internation|SetupUILanguage |Specifies the language for the Windows Deployment |
|page |al-Core-Windows PE | |Services client UI. This setting is required only when|
| | | |the boot image has setup resources for multiple |
| | | |languages. |
|Welcome and |Microsoft-Windows-Internation|InputLocale |Specifies the computer's input locale and the keyboard|
|keyboard selection |al-Core-Windows PE | |layout for the selected image. If this setting is not |
|page | | |specified, a default will be chosen based on |
| | | |UILanguage. |
| | | |Even if is properly configured not to |
| | | |display UI, the welcome page will be displayed if the |
| | | |credentials page value is set to Always. |
|Credentials page |Microsoft-Windows-Setup -> |Credentials |Specifies the user name, domain, and password of an |
| |WindowsDeploymentServices -> | |account with proper permissions to install the |
| |Login | |specified image. |
|Image selection |Microsoft-Windows-Setup -> |InstallImage |Specifies the image to be installed. |
|page |WindowsDeploymentServices | | |
|Image selection |Microsoft-Windows-Internation|UILanguage |Specifies the language for the selected image. If this|
|page |al-Core-Windows PE | |setting is not specified or if the specified value |
| | | |does not match any of the available install languages,|
| | | |the image selection page will be displayed. |
| | | |Do not specify this value if InstallImage is a Windows|
| | | |Server 2003, Windows 2000, or Windows XP image. In |
| | | |those cases, this setting does not apply and will |
| | | |cause an error (which causes the image selection page |
| | | |to appear). |
|Image selection |Microsoft-Windows-Internation|UILanguageFallback |Specifies the language to be used if the computer's |
|page |al-Core-Windows PE | |default UI language is only partially localized for |
| | | |the selected image. |
|Disk configuration |Microsoft-Windows-Setup -> |Disk |Specifies the disk configuration settings. |
|page |DiskConfiguration | | |
|Disk configuration |Microsoft-Windows-Setup -> |InstallTo |Specifies the disk and partition to which the selected|
|page |WindowsDeploymentServices -> | |image is to be installed. |
| |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 following location: \RemoteInstall\Images\\\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 true in the Microsoft-Windows-UnattendedJoin component. Additionally, the Microsoft-Windows-Shell-Setup component for the unattended pass must exist, even if it is empty.
• For Windows XP and Windows Server 2003 images. The image unattend file in the $OEM$ structure (Sysprep.inf) must have the setting DoOldStyleDomainJoin=Yes, and it must have (at a minimum) the [Networking] and [UserData] sections, even if they are empty.
If the image unattend file does not contain the proper formatting, Windows Deployment Services will assume that you have chosen to override or avoid the domain join and computer name functionality and therefore will not edit the unattend file. If a selected image does not have an associated image unattend file, a template unattend file will be used to pass domain join (and computer naming) information throughout the installation process.
• For Windows Vista or Windows Server 2008 images, this file exists within the image itself as \System32\WDSUnattendTemplate.xml. Therefore, after the image is applied, the template file will be located offline on the disk.
• For Windows XP and Windows Server 2003 images, this file exists in the \RemoteInstall\Templates\Sysprep.inf folder on the server when the server is first initialized. After the image is applied, Windows Deployment Services will copy the template Sysprep.inf into the offline image and then edit it as appropriate. This file is copied from the server into the offline image as C:\Sysprep\Sysprep.inf.
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, |This method is secure in the sense that it requires credentials |
|shared computer password and enabling the computer to join a |(user name, domain, and password) before you can reset the |
|domain without credentials. For Windows Vista and Windows Server |account and perform the domain join. However, in practice this |
|2008 images, this shared computer password is a dynamically |method is actually less secure because the credentials reside in |
|generated, strong password that is set by Windows Deployment |the ImageUnattend.xml file in plain text. |
|Services. The password is inserted into the ImageUnattend.xml |• Advantages: This method uses a simplified permissions model |
|file as the setting. For images from an earlier|because a single account is used throughout the enterprise to |
|version of Windows, this shared computer password is the computer|perform all domain join operations. |
|name. |• Disadvantages: Credentials are stored in plain text in the |
|• Advantages: This method does not require placing unattend |image unattend file, which is located on a shared folder on the |
|credentials in plain text in the unattend file. |Windows Deployment Services server. |
|• Disadvantages: It is possible for a malicious user to join the |To implement a secure join, do the following to the unattend |
|domain between the time the computer account was reset (in |file: |
|Windows PE) and when the actual domain join occurs (on first boot|1. Set UnsecureJoin = FALSE. |
|of the applied image). This particular attack is effectively |2. Specify the credentials for performing the domain join, and |
|mitigated with Windows Vista and Windows Server 2008 images |the domain that you want to join the computer to. |
|because the password is dynamically generated. |3. Ensure that the Microsoft-Windows-Shell-Setup component exists|
|To implement an unsecure join, set UnsecureJoin = TRUE and ensure|for the specialize phase. |
|that the Microsoft-Windows-Shell-Setup component exists for the |4. Set the value to %MACHINENAME%. During |
|specialize phase. |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 metadata. This will be the image |
| |name as displayed in the Windows Deployment Services management tools and the user interface of the |
| |Windows Deployment Services client. (The Windows Deployment Services client is basically Setup.exe |
| |and supporting files.) |
|ImageDescription |Specifies the value to be set as the description within the image metadata. This will be the image |
| |name as displayed in the Windows Deployment Services management tools and the user interface of the |
| |Windows Deployment Services client. |
|DestinationFile |Specifies the full path and name of the .wim file to which the image is to be captured. |
|SystemRoot |The name of the system root folder. If this setting is not specified, \Windows, \Winnt, and \i386 |
| |will be tried. The Image Capture Wizard must locate the system root to extract the data needed to |
| |form the metadata (for example, the version of the operating system and installed languages) that is |
| |added to the .wim during the capture. |
|Overwrite=Yes|No|Append |(Default=No) |
| |Designates whether the file specified in DestinationFile should be overwritten if a file with that |
| |name already exists in the specified location. |
| |• Yes. Specifies to overwrite the existing file. |
| |• No. The process will cause an error if a file with the same name already exists in the specified |
| |location. |
| |• Append. If a .wim file with the same name already exists, the capture should be appended as a new |
| |image within the existing .wim file. This setting often produces a much faster capture because when |
| |files from the current capture operation already reside in the .wim file (for example, if file |
| |resources in another image already exist in the .wim file), the files are not copied into the .wim |
| |file again. The image name specified must be unique within the .wim file; otherwise, you will receive|
| |an error. |
[ExclusionList]
Defines the files and folders to be excluded from the capture. By default, this section is populated with the following items: $ntfs.log, hiberfil.sys, pagefile.sys, System Volume Information, RECYCLER, winpepge.sys, and %SYSTEMROOT%\CSC. Note that the %SYSTEMROOT% variable is replaced by the value specified in SystemRoot in the [Capture] section.
[WDS]
Contains all of the Windows Deployment Services-specific unattend settings.
|Setting |Description |
|UploadToWDSServer=Yes|No |(Default=No) Specifies whether the resulting image should be added to a Windows |
| |Deployment Services server's image store. If this value is set to No, all other settings |
| |under the [WDS] section will be ignored. |
|WDSServerName |Specifies the name of the Windows Deployment Services server. This can be either a |
| |NetBIOS name or a fully qualified domain name (FQDN). |
|WDSImageGroup |The name of the image group on the specified Windows Deployment Services server. |
|Username |The user name to use when connecting to the specified Windows Deployment Services server.|
| |This name can take either of the following forms: domain\username or username@.|
|Password |The password of the user account. |
| |[pic]Note |
| |We recommend that you enter credentials in the wizard user interface (UI). Credentials |
| |specified in WDSCapture.inf are stored in plain text within the capture image, and there |
| |is no way to secure these credentials. |
|DeleteLocalWIMOnSuccess=Yes|No |Specifies whether the local capture image (where the capture image was saved) will be |
| |deleted at the end of the process, assuming that the image is successfully uploaded to |
| |the Windows Deployment Services server. You should be careful when using this option with|
| |the Overwrite=append option because the entire image will be deleted (not just the new |
| |.wim that was appended to the existing image). |
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
• 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: 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 (). 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 .
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 file |Image unattend file |
|AWindows Deployment Services client unattend file that is defined|The order of precedence for this file is as follows: |
|always overrides an implicit unattend file. The order of |1. Explicitly assigned image unattend files (Windows Vista images|
|precedence for this file is as follows: |only) |
|1. Unattend files that are passed explicitly from the command |2. Image unattend files in the $OEM$ structure |
|line (for example, setup.exe /wds /unattend:) |3. Template unattend files (used as part of a domain join) |
|2. Unattend files that are defined on the server |4. Client unattend files that have been carried over into |
|3. An implicit unattend file (AutoUnattend.xml) |additional phases of unattend processing |
Setting Command-Line Precedence for Image Unattend Files
There are installation scenarios in which you may want to use the same Unattend.xml file for automating the Windows Deployment Services client and subsequent phases of Setup when performing a custom deployment solution. Note that command-line precedence does not apply to Windows Deployment Services client unattend files that are obtained from the Windows Deployment Services server. By setting the command-line precedence value, you can specify whether another unattend file (either an implicit unattend file such as AutoUnattend.xml, or an unattend file passed by using the /Unattend option) will be used instead of the image unattend file when installing a client computer. To override an existing image unattend file associated with an image, first enable unattend installations by running the command wdsutil /set-server /wdsunattend /Policy:{Enabled | Disabled}. Next, run one of the following:
• To allow an unattend file on the client computer to override the unattend file sent from the server, run WDSUTIL /Set-Server /WDSUnattend /CommandLinePrecedence:Yes.
• To force the unattend file from the server to be used, run WDSUTIL /Set-server /WDSUnattend /CommandLinePrecedence:No.
The following is an example scenario:
There are two types of computers in your organization — laptops and desktops. Your company policy states that all laptops should be configured with two partitions and should contain the proper Bluetooth drivers and software. It also states that desktops should have a single partition and do not need Bluetooth support. Because the majority of the computers in your organization are desktops, you create a Windows Deployment Services client unattend file that creates a single disk partition. Then you create a Windows Vista image with an image unattend file that does not install the Bluetooth drivers and software. Next, you create a single Unattend.xml file that performs all of the custom actions needed for laptop installations. Finally, you create a custom boot image that is configured to run a script. The first action in the script is to use WMI calls to determine whether a booted client computer is a laptop or a desktop.
• If the computer is a laptop, the script calls Setup.exe by using the /wds option and then explicitly passes the custom Unattend.xml file for laptop use. To ensure that this single unattend is used throughout the process, you set the command-line precedence value of the server appropriately. This action causes the unattend file that is passed to the Windows Deployment Services client through the command line to override the existing image unattend file that is associated with the image on the Windows Deployment Services server.
• If the computer is a desktop, the script invokes the client normally, enabling the typical installation to continue (the client will obtain both the Windows Deployment Services client unattend file and, later, the image unattend file from the Windows Deployment Services server).
Using Variables to Obtain Information from the Client
The Windows Deployment Services client can obtain several pieces of information during an installation that you can use as part of your custom deployment scenario. The client will insert the proper variable valuess into your unattend file automatically as long as your file is formatted correctly. The variables that the client can use for this purpose are:
• %USERDOMAIN%. The name of the user's domain, which was specified either by credentials or in the Windows Deployment Services client unattend file.
• %USERNAME%. The user's name, which was specified either by credentials or in the Windows Deployment Services client unattend file.
• %USERPASSWORD%. The user's password, which was specified either by credentials or in the Windows Deployment Services client unattend file. Using this variable may pose a security risk and is not recommended. The password value will be written to the unattend file in plain text.
• %MACHINEDOMAIN%. The domain containing the computer account that represents the physical client computer.
• %MACHINENAME%. The computer name of the computer account that represents the physical client computer.
• %TIMEZONE%. The time zone of the Windows Deployment Services server.
• %ORGNAME%. The organization name of the Windows Deployment Services server.
To see an example file that uses these variables, see Sample Unattend Files.
Sample Unattend Files
In This Topic
• Windows Deployment Services Client Unattend Files
• Example 1: Standard installation
• Example 2: Install a language pack
• Image Unattend Files for Windows Vista and Windows Server 2008
• Example 1: Unsecure domain join
• Example 2: Secure domain join
• Example 3: Using variables
• Image Unattend Files for Older Operating Systems
• Example 1: Domain join
• Example 2: Using variables
• Example 3: Run a script
• Combined Image and Client Unattend File
• Image Capture Wizard Unattend File
[pic]Note
To download the Windows Deployment Services documentation (including a getting started guide, deployment guide, and WDSUTIL command-line syntax), see .
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 (), the credentials for the client to access the Windows Deployment Services server (), and the image for installing on the client computer (). It also configures the disk layout – for example, the image will be installed on the first partition () and the first disk () on the client computer.
OnError
username
my_password
OnError
Windows Vista with Office
ImageGroup1
Install.wim
0
1
OnError
0
false
1
1
C
TestOS
NTFS
true
false
OnError
en-US
en-US
Example 2: Install a language pack
You can use the following example file to install a language pack. If the 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 de-de) Windows Deployment Services will look for a German language pack on the server at C:\RemoteInstall\Images\\Langpacks\de-de.
OnError
Administrator
Password1
OnError
Windows Vista Ultimate
ImageGroup1
0
1
OnError
0
false
1
1
C
Vista
NTFS
true
false
OnError
en-US
de-de
de-de
de-de
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 value in the section. The attributes that define this domain join method are true and the Microsoft-Windows-Shell-Setup component. For more information about this method, see the “Ensuring Security” section of Automating the Domain Join.
true
XXXX-XXXX-XXXX-XXXX-XXXX
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 false, , 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.
false
Password1
MyUserName
%MACHINENAME%
Example 3: Using variables
In the following example, Windows Deployment Services will automatically replace the %USERDOMAIN%, %USERPASSWORD%, %USERNAME%, and %MACHINEDOMAIN% variables using the proper values. For more information, see "Using Variables to Obtain Information From the Client" in Advanced Unattended Installation Scenarios.
%USERDOMAIN%
%USERPASSWORD%
%USERNAME%
%MACHINEDOMAIN%
%MACHINENAME%
%USERDOMAIN%
Administrators
%USERNAME%
%ORGNAME%
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%
[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: option.
OnError
Administrator
Password1
Install Image
defaultx86
install.wim
OnError
0
1
OnError
0
false
1
1
C
Vista
NTFS
true
false
OnError
en-US
en-US
true
computer1
2
2
false
true
Work
1
true
true
32
96
1024
60
768
Password1
true
My Local Account
John Smith
Administrators;Power Users
John
Administrator
Administrators;Power Users
Image Capture Wizard Unattend File
The following is an example file that automates the UI screens of the Image Capture Wizard. To use this file, first update each section with the information for your environment. For example, the [ExclusionList] specifies the files that the capture process will exclude from capturing. Then create a capture image and save this file within the image. To do this, mount the image using ImageX, save this file as Windows\system32\Wdscapture.inf (overwrite the existing Wdscapture.inf), and then unmount the image. Lastly, add the capture image to the Windows Deployment Services server. When you boot a computer into this image, the UI screens will be automated and the image will be uploaded to the server with the settings you have specified.
[Capture]
Unattended=Yes
VolumeToCapture=C:
SystemRoot=windows
ImageName="WindowsVista"
ImageDescription="Windows Vista ULTIMATE with Office"
DestinationFile=C:\Capture.wim
Overwrite=Yes
[ExclusionList]
$ntfs.log
hiberfil.sys
pagefile.sys
"System Volume Information"
RECYCLER
winpepge.sys
%SYSTEMROOT%\CSC
[WDS]
UploadToWDSServer=Yes
WDSServerName=WDSServer
WDSImageGroup="ImageGroup1"
Username=Username
Domain=Domain
Password=Password1
DeleteLocalWimOnSuccess=No
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
[pic]Note
To download the Windows Deployment Services documentation (including a getting started guide, deployment guide, and WDSUTIL command-line syntax), see .
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 (). When creating boot images, ensure that the image is stored in .wim format, and it is marked as bootable from RAMDISK using the /boot option with ImageX. To create custom boot image, you must manually copy the Windows Vista or Windows Server 2008 Setup.exe binary files into the custom image. The process for doing this is as follows:
1. Create a top-level folder named Sources in the custom boot image.
2. Mount the boot image that is RAMDISK-bootable in the Boot.wim file (Boot.wim contains two Windows PE images, and the bootable image is the second image).
3. Copy all of the Setup.exe files from the \Sources folder in the mounted image to the \Sources folder in the custom boot image.
In addition, you must ensure that the Windows Deployment Services client is started by Windows PE. To ensure that this occurs, create an entry in the WinPESHL.ini file to start Setup.exe in Windows Deployment Services mode. For more information, see “When Setup Is Started in Windows Deployment Services Mode” in How the Windows Deployment Services Client Works (). For more information about editing WinPESHL.ini, see Include a Custom Script in a Windows PE Image (). 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 ().
• If you are using Windows PE 2.0, you might run into the issue documented at . In this scenario, run the command Bootsect.exe /nt52 c: to set up the correct NTFS file system boot sector.
Discover Images
Discover images are generally used in scenarios where the client cannot perform a PXE boot. These images enable a computer to locate a Windows Deployment Services server and use it to install an image. To create a discover image, right-click a boot image in the MMC snap-in, and then click Create discover boot image. In most cases, you should use the Boot.wim file included on the Windows Server 2008 DVD to create your image. For instructions, see the Windows Deployment Services Getting Started Guide.When you create a discover images, you configure one of the following:
• Static discovery. Static discovery is when you specify the server that the computer should use. Static discovery works well in data center environments or branch offices where DHCP may not be available. One major disadvantage of static discovery is that it introduces a single point of failure. For example, if the server that is specified is unavailable, the Windows Deployment Services client will not work, and there is no way to have the client try a different server. Another flaw is that static discovery does not allow for load balancing, because all clients using a particular boot image would use the specified server. You can specify the server when you create the discover image.
• Dynamic discovery. If you do not specify the server to use when you create a discover image, the Windows Deployment Services client will emulate a PXE request from within Windows PE. Based on the responses to that PXE request, the client can locate a valid server and continue the installation process.
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 ().
[pic]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 |
|(). |
|[LaunchApps] |
|%SYSTEMROOT%\sources\setup.exe, "/wds /wdsdiscover" |
|or |
|[LaunchApps] |
|%SYSTEMROOT%\sources\setup.exe, "/wds /wdsdiscover /wdsserver:" |
|See the following table for more information about these options. |
|4. Capture the modified image into a new .wim file. |
|5. Update the image metadata to reflect any changes to the image name or description. |
There are two command-line options for Setup.exe that control the discovery behavior of the Windows Deployment Services client. These options are described in the following table.
|Option |Description |
|/WDSDiscover |(Default) Specifies that the Windows Deployment Services client should be in discover mode. If you |
| |do not specify /WDSServer with this option, Windows Deployment Services will search for a server. |
| |For example, to start the Windows Deployment Services client in this dynamic discover mode, run the |
| |command \sources\setup.exe /wds /WDSDiscover. |
|/WDSServer: |Specifies the name of the Windows Deployment Services server that the client should connect to. Note|
| |that can be an IP address, a NetBIOS name, or a fully qualified domain name (FQDN). You|
| |must also specify /WDSDiscover. For example, to start the Windows Deployment Services client in this|
| |static discover mode, run the command \sources\setup.exe /wds /WDSDiscover /WDSServer:MyWDSServer. |
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 (). The following table compares these two tools.
|Functionality |Image Capture Wizard|ImageX |
|Captures a partial volume? |No |Yes |
|Captures an image that has not been prepared by using Sysprep? |No |Yes |
|Uploads directly to the Windows Deployment Services server? |Yes |No |
|Can the process be automated? |Yes |Yes |
|Has a GUI? |Yes |No |
|Provides additional functionality beyond image capture? |No |Yes |
|Enables me to specify a capture exclusion list? |Yes |Yes |
|Captures directly to a network location without making a local image copy? |No |Yes |
Creating Custom Capture Images
In advanced scenarios, you can create a custom capture image.
[pic]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
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.
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: acpiapic
• 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.
[pic]To ensure that the Boot.ini file is included with the image
|1. Deploy the image of the earlier operating system to a reference computer. |
|2. Use Sysprep to prepare the image. |
|3. Capture the image of reference computer, including the Boot.ini file. |
|4. Deploy the image by using Windows Deployment Services. When the image is applied, the Boot.ini file included in |
|that image will be copied as well. |
Filtering Images
You can restrict which install images are shown to users. These restrictions can be policy-based or enforced by the computer.
Automatic Filtering by Windows Deployment Services
Windows Deployment Services filters the images in the image selection page to avoid situations where a user is allowed to install an image that is not compatible. Images are filtered by hardware abstraction layer (HAL) and architecture.
For Windows Vista or Windows Server 2008 images, HAL filtering is not necessary because the image contains all possible HALs (and the correct HAL is detected and put in place automatically upon first boot). If the image is of an older operating system, Windows Deployment Services will compare the HAL type (as specified in the metadata for the .wim file) to that of the destination computer. If the HAL types are identical, the image will be shown to the user. If the HAL types do not match, the image will not be displayed. The HAL information about the image is stored in the image metadata in the 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.
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 ().
Servicing an Image Offline
The following are the four high-level steps you will need to perform to service an image offline.
1. Disable the current image. To do this, right-click the image and click Disable. This allows currently connected clients to finish applying the image, but it prevents new clients from starting an installation.
2. Export the image to a location outside of the image store. To do this, right-click the image and click Export. For install images, this combines the metadata in the install.wim file with the resources in the Res.rwm file into a single .wim file and saves it to the destination location. To save space, you can also use the WDSUTIL /Export-Image command to append the images to an existing .wim file. This is also generally faster than exporting it to a new .wim file. For more information about this command, see /export-Image.
3. Service the image. In this step, you update the image using the tools in the Windows AIK. For example, you can mount the image to a folder by using ImageX, and then add the files and folders to the image. You can also load the registry hive to add, delete, or modify registry keys. If the image is a boot image, you can use PEimg.exe to add drivers to the image. After all your changes are complete, use ImageX to commit the changes to the .wim. For more information, see the following topics:
• Phase 5: Image Maintenance ()
• Package Manager Technical Reference ()
• Add Device Drivers to an Offline Windows Image ()
• Install a Language Pack to an Offline Image ()
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.
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 ()
• Distributed File System ()
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.
[pic]Note
You cannot redirect the boot directory (that is, \\\reminst\boot) using DFS. If you do, Windows Deployment Services will not start.
[pic]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 () |
|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.\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. |
|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 ().
[pic]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 () |
|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: |
|Option |Explanation |
|/BcdRefreshPolicy |Causes the server to regenerate BCD stores in the \Tmp folder for all boot images. |
|/RefreshPeriod |Determines how often the boot images are regenerated. This value is required so that any changes that |
| |you make to your boot images on the master server are reflected in the boot menus that clients receive |
| |from remote servers. If you do not make changes to boot images very often, it is okay to have a larger |
| |value. If you make changes to boot images often or if you want changes to propagate quickly, set this |
| |to a lower value. However, be careful when setting a low value. BCD generation causes CPU and disk |
| |overhead on the Windows Deployment Services server. Configuring a small value can cause performance |
| |problems on the server. A good default value is 30 minutes. |
How to Perform Common Tasks
This topic contains procedures for performing common tasks using Windows Deployment Services MMC snap-in. and the WDSUTIL command line tool. The management tasks that you can perform with these tools fall into the following categories:
|Category |Example tasks |
|How to Manage Your Server |• Initialize and uninitialize a server |
| |• View configuration information about the server |
| |• Start/stop or enable/disable a server |
| |• Update the RemoteInstall folder |
| |• Set advanced server settings |
|How to Manage Client Computers |• Create and delete prestaged accounts in Active Directory Domain Services (AD DS) |
| |• View information about prestaged computers |
| |• Configure settings for prestaged computers |
| |• Reject/approve pending computers |
|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 Transmissions |• Create multicast transmissions |
| |• Manage multicast transmissions |
|How to Modify the BCD Store Using Bcdedit |• To view the contents of the BCD store |
| |• To configure the default selection time-out value |
| |• To configure a localized boot manager experience |
| |• To configure the TFTP block size and window size |
| |• To configure Windows debugger options |
How to Manage 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.
[pic]Note
To download the Windows Deployment Services documentation (including a getting started guide, deployment guide, and WDSUTIL command-line syntax), see .
[pic]Note
Help for WDSUTIL is available by typing WDSUTIL /? at a command prompt or online at .
|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 |
| |• 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 Settings |• To choose which boot images are displayed on x64-based computers |
| |• To choose the default network boot program for each architecture |
| |• To choose the default network boot program that does not require F12 for each architecture |
| |• To choose the default boot image for each architecture |
|Active Directory Domain|• To specify a domain controller for Windows Deployment Services |
|Services |• To specify a global catalog server for Windows Deployment 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
|Using the MMC |Using WDSUTIL |
|1. Install Windows Deployment Services. For more information, see|1. Install Windows Deployment Services. For more information, see|
|the Windows Deployment Services Getting Started Guide. |the Windows Deployment Services Getting Started Guide. |
|2. Click Start, click Administrative Tools, and then click |2. Click Start, right-click Command Prompt, click Run as |
|Windows Deployment Services. |administrator, and then run WDSUTIL /Verbose /Progress |
|3. In the left pane of the Windows Deployment Services snap-in, |/Initialize-Server /RemInst:, where is the path |
|right-click the server and then click Configure Server. |where you would like the RemoteInstall folder to be located. |
|4. Follow the instructions in the wizard. | |
The preceding procedure does the following:
1. Creates the folder tree for RemoteInstall.
2. Creates the RemoteInstall folder with the following default permissions: Authenticated Users = Read and Execute, System = Full Control, Administrators = Full Control, and WDSServer service = Full Control
3. Installs the server files (boot files) from the \system32\reminst folder (as placed during component installation) to the new folder structure.
4. Updates the service parameters.
5. Sets the Trivial File Transfer Protocol (TFTP) root to point to the RemoteInstall folder root.
6. Sets the WDSServer service startup type to Auto.
7. Optionally authorizes the server in Dynamic Host Control Protocol (DHCP).
8. Starts the services.
To start or stop the server
|Using the MMC |Using WDSUTIL |
|1. Right-click the server, and then click All Tasks. |1. Click Start, right-click Command Prompt, and click Run as |
|2. Click Stop Server or Start Server. |administrator. |
| |2. Run WDSUTIL /Start-Server or WDSUTIL /Stop-Server. |
The preceding procedure starts or stops the WDSServer service.
To enable the server
|Using the MMC |Using WDSUTIL |
|N/A |1. Click Start, right-click Command Prompt, and click Run as administrator. |
| |2. Run WDSUTIL /Enable-Server. |
The preceding procedure starts or stops the WDSServer service.
To enable logging for the Windows Deployment Services client
|Using the MMC |Using WDSUTIL |
|N/A |1. Click Start, right-click Command Prompt, and click Run as administrator. |
| |2. To turn on client logging, run WDSUTIL /Set-Server /WDSClientLogging /Enabled:Yes. |
| |3. To change which events are logged, run WDSUTIL /Set-Server /WDSClientLogging |
| |/LoggingLevel:{None|Errors|Warnings|Info} (each category includes all events from the previous |
| |categories). |
The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WdsImgSrv\ClientLogging\Enabled to 1.
The level is stored at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WdsImgSrv\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\RpcPort to the specified value.
[pic]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: |
| |/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\WDSPXE\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\WDSPXE\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:. |
The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Parameters\UpdateTime to the specified value.
To force the server to update files in the RemoteInstall folder
|Using the MMC |Using WDSUTIL |
|N/A |1. Click Start, right-click Command Prompt, and click Run as administrator. |
| |2. Run WDSUTIL /Update-ServerFiles. |
To configure the network profile for the server
|Using the MMC |Using WDSUTIL |
|1. Right-click the server, and then click Properties. |1. Click Start, right-click Command Prompt, and click Run as |
|2. On the Network Settings tab under Network Profile, select the|administrator. |
|option that specifies the network speed of your organization. |2. Run WDSUTIL /Set-Server [/Server:] /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\Multicast\Profiles\Custom
[pic]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 ().
• 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 (). As an alternative, you can regularly archive the server's configuration settings by running the command WDSUTIL /get-server /show:config. However, if you must restore the settings, you must manually reconfigure the settings by using WDSUTIL.
DHCP
To configure Windows Deployment Services to run on the same computer as Microsoft DHCP
|Using the MMC |Using WDSUTIL |
|1. Right-click the server, and then click Properties. |1. Click Start, right-click Command Prompt, and click Run as |
|2. On the DHCP tab, select Do not listen on port 67 and Configure|administrator. |
|DHCP Option #60 Tag to PXEClient. |2. Run WDSUTIL /Set-Server /UseDHCPPorts:No /DHCPOption60:Yes. |
The preceding procedure does the following:
• Sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Parameters\UseDhcpPorts to 0.
• Adds the option 60 PXEClient tag to all of your DHCP scopes.
To configure Windows Deployment Services to run on the same computer as non-Microsoft DHCP
|Using the MMC |Using WDSUTIL |
|1. Right-click the server, and then click Properties. |1. Click Start, right-click Command Prompt, and click Run as |
|2. On the DHCP tab, select Do not listen on port 67. |administrator. |
|3. Use your DHCP server tools to set the option 60 tag to |2. Run WDSUTIL /Set-Server /UseDHCPPorts:No. |
|PXEClient. |3. Use your DHCP server tools to set the option 60 tag to |
| |PXEClient. |
The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Parameters\UseDhcpPorts to 0.
To turn on the DHCP authorization requirement
|Using the MMC |Using WDSUTIL |
|N/A |1. Click Start, right-click Command Prompt, and click Run as administrator. |
| |2. Run WDSUTIL /Set-Server /RogueDetection:Yes. |
The preceding procedure sets HKEY_LOCAL_MACHINE\System\CurrentControlSet\WDSServer\Providers\WDSPXE\DisableRogueDetection 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 |1. Ensure that you are a domain administrator in the root domain |
|the forest or an enterprise administrator. For information about |of the forest or an enterprise administrator. For information |
|delegating permissions, see “Authorizing a Server” in the Configuring |about delegating permissions, see “Authorizing a Server” in the |
|DHCP topic. |Configuring DHCP topic. |
|2. Right-click the server, and then click Properties. |2. Click Start, right-click Command Prompt, and click Run as |
|3. On the Advanced tab, select Authorize the Windows Deployment Server|administrator. |
|in DHCP. |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
|Using the MMC |Using WDSUTIL |
|1. Right-click the server, and then click Properties. |1. Click Start, right-click Command Prompt, and click Run |
|2. On the PXE Response Settings tab, do one of the following: |as administrator. |
|• To respond to all client PXE requests, select Respond to all (known |2. Do one of the following: |
|and unknown) client computers. |• To respond to all clients’ PXE requests, run WDSUTIL |
|• To respond only to prestaged client PXE requests, select Respond |/Set-Server /AnswerClients:All. |
|only to the known client computers. |• To respond only to prestaged clients’ PXE requests, run |
|• To not answer any client PXE requests, select Do not respond to any |WDSUTIL /Set-Server /AnswerClients:Known. |
|client computer. Note that this option will only work if Windows |• To not answer any clients’ PXE requests, run WDSUTIL |
|Deployment Services and DHCP are running on different servers. This is|/Set-Server /AnswerClients:None. |
|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
|Using the MMC |Using WDSUTIL |
|1. Right-click the server, and then click Properties. |1. Click Start, right-click Command Prompt, and click Run as |
|2. On the PXE Response Settings tab, set the PXE Response delay |administrator. |
|in the control. |2. Run WDSUTIL /Set-Server /ResponseDelay:X, where X is the |
| |amount of time (in seconds) you want the server to wait before |
| |responding to clients. |
The preceding procedure sets the value of HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\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\WDSPXE\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\WDSPXE\Providers\BINLSVC\ResetBootProgram to 1.
To configure the server to determine the architecture of booting clients
|Using the MMC |Using WDSUTIL |
|N/A |1. Click Start, right-click Command Prompt, and click Run as administrator. |
| |2. Run WDSUTIL /Set-Server /ArchitectureDiscovery:Yes. |
The preceding procedure sets the value of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\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:. |
The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINLSVC\x86x64DefaultImageType to 1 for x86-based computers only, 2 for x64-based computers only, and 0 for both types of computers.
To choose the default network boot program for each architecture
|Using the MMC |Using WDSUTIL |
|1. Right-click the server, and then click Properties. |1. Click Start, right-click Command Prompt, and click Run as |
|2. On the Boot tab, insert the path to the boot file you want to |administrator. |
|use for each architecture. For a list of network boot programs, |2. Run WDSUTIL /Set-Server /BootProgram: |
|see Managing Network Boot Programs. |/Architecture:{x86|x64|ia64}, where is relative to the |
| |RemoteInstall folder. |
The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINLSVC\BootPrograms\\Default to the specified path.
To choose the default network boot program that does not require F12 for each architecture
|Using the MMC |Using WDSUTIL |
|N/A |1. Click Start, right-click Command Prompt, and click Run as administrator. |
| |2. Run WDSUTIL /Set-Server /N12BootProgram: /Architecture:{x86|x64|ia64}, where is |
| |relative to the RemoteInstall folder. |
The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINLSVC\BootPrograms\\N12 to the specified path.
To choose the default boot image for each architecture
|Using the MMC |Using WDSUTIL |
|1. Right-click the server, and then click Properties. |1. Click Start, right-click Command |
|2. On the Boot tab, insert the path to the boot image you want to use for each |Prompt, and click Run as administrator. |
|architecture. In most cases, you should use the standard boot image that is included on|2. Run WDSUTIL /Set-Server |
|the Windows Server 2008 media (located at \Sources\boot.wim) without modification. Do |/BootImage: |
|not use the Boot.wim from the Windows Vista media unless your version of Windows Vista |/Architecture:{x86|x64|ia64}, where |
|has SP1 integrated into the DVD. |is relative to the RemoteInstall folder. |
The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINLSVC\BootImages\\BootImagePath to the specified path.
Active Directory Domain Services
To specify a domain controller for Windows Deployment Services
|Using the MMC |Using WDSUTIL |
|1. Right-click the server, and then click Properties. |1. Click Start, right-click Command Prompt, and click Run as |
|2. On the Advanced tab, click Let Windows Deployment Services use|administrator. |
|only the specified servers, and then enter the domain controller |2. Run WDSUTIL /Set-Server /PreferredDC:, where is a|
|name. |NetBIOS name or fully qualified domain name (FQDN). |
The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINLSVC\DefaultServer to the specified name.
To specify a global catalog server for Windows Deployment Services
|Using the MMC |Using WDSUTIL |
|1. Right-click the server, and then click Properties. |1. Click Start, right-click Command Prompt, and click Run as |
|2. On the Advanced tab, click Let Windows Deployment Services use|administrator. |
|only the specified servers and then enter the Domain controller |2. Run WDSUTIL /Set-Server /PreferredGC:, where is a|
|name. |NetBIOS name or FQDN. |
The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\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 |
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\WDSPXE\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:. |
| |• To remove a GUID from the list, run WDSUTIL /Set-Server /BannedGUIDPolicy /Remove /GUID:. |
| |[pic]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\WDSPXE.
To specify how to generate computer names
|Using the MMC |Using WDSUTIL |
|1. Right-click the server, and then click Properties. |1. Click Start, right-click Command Prompt, and click Run as |
|2. On the Directory Services tab, enter the naming policy string |administrator. |
|in the indicated field (see below for details). |2. Run WDSUTIL /Set-Server /NewMachineNamingPolicy: where|
| | 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
|Using the MMC |Using WDSUTIL |
|1. Right-click the server, and then |1. Click Start, right-click Command Prompt, and click Run as administrator. |
|click Properties. |2. Do one of the following: |
|2. On the Directory Services tab, click|• To create new accounts in the default computer OU in the domain the Windows Deployment |
|Default Directory Service location or |Services server is in, run WDSUTIL /Set-Server /NewMachineOU /Type:ServerDomain. |
|specify the domain and organizational |• To create new accounts in the default computer OU in the domain the specified user |
|unit (OU) |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:. |
The preceding procedure does the following:
• Sets the netbootNewMachineOU attribute on the Service Control Point (SCP) for the Windows Deployment Services server to the distinguished name of the server
• Sets the NewMachineOUType registry key to 1
• Sets the NewMachineOUType registry key to 0
• Sets the netbootNewMachineOU attribute on the SCP for the Windows Deployment Services server to the specified distinguished name
To choose whether to join client computers to the domain
|Using the MMC |Using WDSUTIL |
|1. Right-click the server, and then click Properties. |1. Click Start, right-click Command Prompt, and click Run as |
|2. On the Client tab, clear the Do not create account in Active |administrator. |
|Directory after running the WDS Client check box to join |2. To join new computers to the domain, run WDSUTIL /Set-Server |
|computers to the domain. |/NewMachineDomainJoin:Yes. |
The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINLSVC\NewMachineDomainJoin to 1.
Unattend File
To choose a default unattend file for the Windows Deployment Services client
|Using the MMC |Using WDSUTIL |
|1. Right-click the server, and then click Properties. |1. Click Start, right-click Command Prompt, and click Run as |
|2. On the Client tab, select the Enable client unattend check box|administrator. |
|and then choose an unattend file for the relevant architecture. |2. To turn on unattended installation and specify the unattend |
| |file, run WDSUTIL /Set-Server /WDSUnattend /Policy:Enabled |
| |/File: /Architecture:{x86|x64|ia64}. |
The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WdsImgSrv\Unattend\Enabled to 1 and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WdsImgSrv\Unattend\\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\WdsImgSrv\Unattend\CommandLineUnattendPrecedence to 1 or 0.
How to Manage Client Computers
This topic contains procedures for the tasks that are listed and described in the following table. Help for WDSUTIL is available by typing WDSUTIL /? at a command prompt or online at .
|Type |Procedure |
|Prestage Computers |• To prestage a client computer |
| |• To prestage a client computer to boot from a different server |
| |• To prestage a client computer to use a network boot program other than the default |
| |• To prestage a client computer to use an unattend file other than the default for the Windows PE phase of |
| |unattended setup |
| |• To prestage a client computer to use a boot image other than the default |
| |• To prestage a client computer to join a domain |
| |• To view the attributes of a prestaged client |
|Configure the Auto-Add|• To enable the Auto-Add policy |
|Policy |• To change the length of time approved computers are held in the Auto-Add database |
| |• To change the length of time rejected and pending computers are held in the Auto-Add database |
| |• To delete the rejected or approved computers table |
|Specify Settings for |• To change the rate at which pending computers will poll the server |
|Pending Computers |• To change the number of times pending computers will poll the server |
| |• To change the message displayed to pending computers |
| |• To set a default network boot server for pending computers |
| |• To set a default network boot program for pending computers |
| |• To set a default unattend file for pending computers |
| |• To set a default boot image for pending computers |
| |• To set domain join options for pending computers |
|Approve and Reject |• To view the table of computers that are pending approval |
|Pending Computers |• To approve a pending computer by using the default settings |
| |• To approve all pending computers by using the default settings |
| |• To approve a pending computer, but change a setting |
| |• To approve all pending computers, but change a setting |
| |• To reject a pending computer |
Prestage Computers
To prestage a client computer
|Using the Active Directory Users and Computers snap-in |Using WDSUTIL |
|1. On the server running Active Directory Users and Computers, open the |1. Click Start, right-click Command Prompt, and click Run as |
|Active Directory Users and Computers MMC snap-in (click Start, click Run, |administrator. |
|type dsa.msc, and then click OK). |2. Run WDSUTIL /Add-Device /Device: |
|[pic]Note |/ID: where is the |
|To manage the server remotely, you can install “AD DS Snap-Ins and |identifier of the new computer. If you use a MAC address, you|
|Command-Line Tools” in the Remote Server Administration Tools. To do this,|must precede it with twenty zeros (0). |
|click Add Features in Server Manager, and install the feature from the |For example: WDSUTIL /Add-Device /Device:Computer1 |
|following location: Remote Server Administration Tools>Remote |/ID:{E8A3EFAC-201F-4E69-953F-B2DAA1E8B1B6} |
|Administration Tools>AD DS and AD LDS Tools>AD DS Tools>AD DS Snap-Ins and|/ReferralServer:WDSServer1 /BootProgram:boot\x86\ |
|Command-line Tools. |/WDSClientUnattend:WDSClientUnattend\unattend.xml |
|2. In the console tree, right-click the organizational unit that will |/User:Domain\MyUser /JoinRights:Full |
|contain the new client computer. |/BootImagePath:boot\x86\images\boot.wim |
|3. Click New, and then click Computer. |/OU:"OU=MyOU,CN=Test,DC=Domain,DC=com" |
|4. Type the client computer name, click Next, and then click This is a | |
|managed computer. | |
|5. In the text box, type the client computer's MAC address preceded with | |
|twenty zeros or the globally unique identifier (GUID) in the format: | |
|{XXXXXXXX-XXXX-XXXX-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. | |
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: |
| |/ReferralServer:. |
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: /BootProgram:, |
| |where 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: /WDSClientUnattend:, where the path is relative to the |
| |unattend file 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: /BootImagePath:, where 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: /User: /JoinRights:JoinOnly /JoinDomain:Yes /Domain: |
| |/ResetAccount, where: |
| | is domain\user or user@domain |
| | is the name of the computer |
| | 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: /User: /JoinRights:Full /JoinDomain:Yes /Domain:. |
| |• To join the client computer to the specified domain without granting any user rights, run WDSUTIL |
| |/Set-Device /Device: /JoinDomain:Yes /Domain:. |
The preceding procedure sets the JoinDomain variable in the netbootMirrorDataFile AD DS attribute on the client’s computer account object to 1. It also grants the specified user rights on the computer object.
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:. |
| |• To view a prestaged client by ID (GUID or MAC) in the local domain, run WDSUTIL /Get-Device /ID:. |
| |[pic]Note |
| |To specify that the client is in a domain other than the local one, specify /Domain: with either of |
| |these commands. |
| |[pic]Note |
| |To search the entire AD DS forest, specify /Forest:Yes with either of these commands. |
The preceding procedure displays the requested information from the folder.
Configure the Auto-Add Policy
For more information about the Auto-Add policy, see Enabling the Auto-Add Policy at Prestaging Client Computers
To enable the Auto-Add policy
|Using the MMC |Using WDSUTIL |
|1. Right-click the server, and then click Properties. |1. Click Start, right-click Command Prompt, and |
|2. On the PXE Response settings tab, click Respond to all (known and unknown) |click Run as administrator. |
|client computers. |2. Run WDSUTIL /Set-Server /AutoAddPolicy |
|3. Select the check box For unknown clients, notify administrator and respond |/Policy:AdminApproval. |
|after approval. | |
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:. |
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:. |
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:. |
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:. |
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:. |
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:. |
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:. |
The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINLSVC\AutoApprove\\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:, where |
| |the is relative to the RemoteInstall folder. |
The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINLSVC\AutoApprove\\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:, 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\\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:, where |
| |is relative to the RemoteInstall folder. |
The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINLSVC\AutoApprove\\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: /JoinRights:JoinOnly /JoinDomain:Yes /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: /JoinRights:Full |
| |/JoinDomain:Yes /Domain:. |
The preceding procedure sets:
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINLSVC\AutoApprove\\JoinRights to 0 if Join Only and 1 if Full
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINLSVC\AutoApprove\\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 Prompt, and click Run as |
|2. Select the Pending Devices node. |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 Prompt, and click Run as |
|2. Right-click the computer you want to approve, and then click |administrator. |
|Approve. |2. Run WDSUTIL /Approve-AutoAddDevices /RequestID: with the |
| |ID obtained from the Auto-Add database. |
The preceding procedure approves the computer. For more information, see Prestaging Client Computers.
To approve all pending computers by using the default settings
|Using the MMC |Using WDSUTIL |
|1. Right-click the Pending Devices node. |1. Click Start, right-click Command Prompt, and click Run as |
|2. Click Approve All. |administrator. |
| |2. Run WDSUTIL /Approve-AutoAddDevices /RequestID:All. |
The preceding procedure approves the computers. For more information, see Prestaging Client Computers.
To approve a pending computer, but change a setting
|Using the MMC (name change only)|Using WDSUTIL |
|1. Select the Pending Devices |1. Click Start, right-click Command Prompt, and click Run as administrator. |
|node. |2. Run WDSUTIL /Approve-AutoAddDevices /RequestID: with the ID obtained from the Auto-Add |
|2. Select the computer you want |database |
|to approve. |In addition, you can append this command with the following options: |
|3. On the Action menu, click |• To change the name, specify /MachineName: |
|Name and Approve. |• To change the organizational unit (OU) where the account will be created, specify /OU:. |
|name you want to give the |• To change the user account for the domain join, specify /User: where the name is |
|computer. |domain\user or user@domain. |
| |• To enable the user to join this computer to the domain only once, specify /JoinRights:JoinOnly.|
| |• To enable the user to join this computer to the domain at any time, specify /JoinRights:Full. |
| |• To join this computer to the domain, specify /JoinDomain:Yes. |
| |• To direct the computer to install from a different Windows Deployment Services server, specify |
| |/ReferralServer:. |
| |• To change the network boot program used, specify /BootProgram:. |
| |• To change the unattend file used for the Microsoft Windows Preinstallation Environment |
| |(Windows PE) phase of unattended setup, specify /WDSClientUnattend:. |
| |• To change the boot image used, specify /BootImagePath:. |
The preceding procedure approves the computer, with the configured settings. For more information, see Prestaging Client Computers.
To approve all pending computers, but change a setting
|Using the MMC |Using WDSUTIL |
|N/A |1. Click Start, right-click Command Prompt, and click Run as administrator. |
| |2. Run WDSUTIL /Approve-AutoAddDevices /RequestID:All |
| |In addition, you can append this command with the following options: |
| |• To change the OU where the accounts will be created, specify /OU:. |
| |• To change the user account used for domain join, specify /User: 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:. |
| |• To change the network boot program used, specify /BootProgram:. |
| |• To change the unattend file used for the Windows PE phase of unattended setup, specify |
| |/WDSClientUnattend:. |
| |• To change the boot image used, specify /BootImagePath:. |
The preceding procedure approves the computers with the configured settings. For more information, see Prestaging Client Computers.
To reject a pending computer
|Using the MMC |Using WDSUTIL |
|1. Select the Pending Devices node.|1. Click Start, right-click Command Prompt, and click Run as administrator. |
|2. Right-click the computer, and |2. Do one of the following: |
|then click Reject or Reject All. |• To reject a single computer, run WDSUTIL /Reject-AutoAddDevices /RequestID: with the ID |
| |obtained from the Auto-Add database. |
| |• To reject all computers, run WDSUTIL /Reject-AutoAddDevices /RequestID:All. |
The preceding procedure sets the Status field for the computer to 2 (rejected) in the table of pending computers, and it sends the file to the computer.
How to Manage Images
This topic contains procedures for the tasks that are listed and described in the following table.
[pic]Note
Help for WDSUTIL is available by typing WDSUTIL /? at a command prompt or online at .
|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
|Using the MMC |Using WDSUTIL |
|1. Right-click a boot or install |1. Click Start, right-click Command Prompt, and click Run as administrator. |
|image, and then click Export Image. |2. Do one of the following: |
|2. In the dialog box, choose a file |• For a boot image, run WDSUTIL /Verbose /Progress /Export-Image /Image: |
|name to export the image to. |/ImageType:Boot /Architecture:{x86|x64|ia64} /DestinationImage /Filepath:. |
| |• For an install image, run WDSUTIL /Verbose /Progress /Export-Image /Image: |
| |/ImageType:Install /ImageGroup: /DestinationImage /Filepath:. |
| |3. You can also set the following: |
| |• To set these metadata fields on the image, append /Name: or |
| |/Description: |
| |• To determine behavior when the image specified in /DestinationImage already exists, append|
| |/Overwrite:{Yes|No|Append}. Yes will overwrite the image, No will cause an error, and Append|
| |will append the new image to the existing .wim file. Note that Append is available only for |
| |install images. |
The preceding procedure does the following:
• For a boot image, it copies the file to the specified destination.
• For an install image, it combines the metadata in the Install.wim file with the resources in the Res.rwm file into a single .wim file at the specified destination.
To replace an image on the server with an updated version
|Using the MMC |Using WDSUTIL |
|1. Right-click a boot or install |1. Click Start, right-click Command Prompt, and click Run as administrator. |
|image, and then click Replace |2. Do one of the following: |
|Image. |• To replace a boot image, run WDSUTIL /Verbose /Progress /Replace-Image /Image: |
|2. Browse to the updated version. |/ImageType:Boot /Architecture:{x86|x64|ia64} /ReplacementImage /ImageFile:. |
|3. Click through the rest of the |• To replace an install image, run WDSUTIL /Verbose /Progress /Replace-Image /Image: |
|wizard. |/ImageType:Install /ImageGroup: /ReplacementImage /ImageFile:. |
The preceding procedure adds the new image to the image store and removes the old one.
To remove an image
|Using the MMC |Using WDSUTIL |
|1. Right-click a boot or install |1. Click Start, right-click Command Prompt, and click Run as administrator. |
|image. |2. Do one of the following: |
|2. Click Delete. |• For boot images, run WDSUTIL /Remove-Image /Image: /ImageType:Boot |
| |/Architecture:{x86|x64|ia64} |
| |• For install images, run WDSUTIL /Remove-Image /Image: /ImageType:Install |
| |/ImageGroup:. If the source image file contains more than one install image, |
| |append /SourceImage: to specify the image to use as a replacement. |
The preceding procedure deletes the .wim image file from the image store.
[pic]Note
If you specify /SourceImage, data folders associated with the original image (for example, folders that contains unattend files or language packs) will be kept intact and will be associated with the replacement image.
Boot Images
To add a boot image to the server
|Using the MMC |Using WDSUTIL |
|1. Right-click the Boot Images node, and then click Add Boot Image. |1. Click Start, right-click Command |
|2. Enter the path to the boot image or browse to the image file, and then click Next. In |Prompt, and click Run as administrator. |
|most cases, you should use the standard boot image that is included on the Windows |2. Run WDSUTIL /Verbose /Progress |
|Server 2008 media (located at \Sources\boot.wim) without modification. Do not use the |/Add-Image /ImageFile: |
|Boot.wim from the Windows Vista media unless your version of Windows Vista has SP1 |/ImageType:Boot, where the path is a full|
|integrated into the DVD. |path to the image file. |
|3. Enter an image name and description, and then click Next. | |
|4. Review the choices, and then click Next. | |
The preceding procedure does the following:
• Copies the boot image file to the folder \RemoteInstall\Boot\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 image, and |1. Click Start, right-click Command Prompt, and click Run as administrator. |
|then click Disable to take the |2. Do one of the following: |
|image offline. |• To take the image offline, run WDSUTIL /Set-Image /Image: /ImageType:Boot |
|2. Right-click the image, and then |/Architecture: /Enabled:No. |
|click Properties. |• To change the name and description, run WDSUTIL /Set-Image /Image: /ImageType:Boot |
|3. Enter the name and description. |/Architecture: /Name: /Description:. |
In the preceding procedure, note the following:
• Taking an image offline sets the hidden file attribute on the relevant .wim file.
• Changing the name and description changes these attributes in the metadata header of the .wim file.
To display the attributes of a boot image
|Using the MMC |Using WDSUTIL |
|1. Right-click a boot image. |1. Click Start, right-click Command Prompt, and click Run as |
|2. Click Properties. |administrator. |
| |2. Run WDSUTIL /Get-Image /Image: /ImageType:Boot |
| |/Architecture:. |
The preceding procedure displays the file name, image name, description, architecture, image type, size, creation and modify dates, default languages, operating system version, service pack level, and online and offline status of the image.
To create a capture image
|Using the MMC |Using WDSUTIL |
|1. In the Windows Deployment Services MMC snap-in, expand the Boot Images node. |1. Click Start, right-click Command |
|2. Right-click the image to use it as a capture image (most commonly, the |Prompt, and click Run as administrator. |
|\Sources\boot.wim file from the installation media). |2. Run WDSUTIL /New-CaptureImage |
|3. Click Create Capture Boot Image. |/Image: |
|4. Type a name, description, and the location where you want to save a local copy of |/Architecture:{x86|ia64|x64} |
|the file. You must specify a location so that if there is a network issue when you |/DestinationImage /FilePath:, |
|deploy the capture image, you have a local copy. |where the file path is the path and name |
|5. Continue to follow the instructions in the wizard, and when it is completed, click |for the capture image. |
|Finish. | |
|6. Right-click the boot image folder. | |
|7. Click Add Boot Image. | |
|8. Browse and select the new capture image, and then click Next. | |
|9. Follow the instructions in the Image Capture Wizard. | |
To create a discover image
|Using the MMC |Using WDSUTIL |
|1. In the Windows Deployment Services MMC snap-in, expand the |1. Click Start, right-click Command Prompt, and click Run as |
|Boot images node. |administrator. |
|2. Right-click the image you want to use as a discover image. In |2. Run WDSUTIL /New-DiscoverImage /Image: |
|most cases, this should be the Boot.wim file from the \Sources |/Architecture:{x86|x64|ia64} /DestinationImage /FilePath:. To specify which server the discover image|
|3. Click Create Discover Boot Image. |connects to, append /WDSServer:. |
|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 |1. Click Start, right-click Command Prompt, and click Run as administrator. |
|then click Add Install Image. |2. To create an image group, run WDSUTIL /Add-ImageGroup /ImageGroup:. |
|2. Select an image group. |3. Run WDSUTIL /Verbose /Progress /Add-Image /ImageFile: |
|3. Select the file to add. |/ImageType:Install. |
|4. Proceed through the rest of the |If more than one image group exists on the server, append /ImageGroup: to |
|wizard. |specify which group the image should be added to. |
| |To skip the integrity check before adding the image, append /SkipVerify. |
The preceding procedure runs an integrity check on the specified image file, creates a metadata-only .wim file in the image group folder, and adds the resources in the image file to the Resource .wim (res.rwm) file for the image group.
To set the attributes for an install image
The following procedure sets the name, description, online and offline status, access controls, and associated unattend file for an image.
|Using the MMC |Using WDSUTIL |
|1. Right-click an install image, and then either click Disable to|1. Click Start, right-click Command Prompt, and click Run as |
|take the image offline or click Enable to bring it back online. |administrator. |
|2. On the Action menu, click Properties. |2. Run WDSUTIL /Set-Image Image: /ImageType:Install |
|3. Enter the name and description in the appropriate text boxes. |/ImageGroup: /Name: |
|4. Check Allow image to install in unattended mode, and then |/Description: /UserFilter: /Enabled:{Yes|No} |
|select a file to associate an unattend file with the install |/UnattendFile:. |
|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 image. |1. Click Start, right-click Command Prompt, and click Run as administrator. |
|2. Click Properties. |2. Run WDSUTIL /Get-Image /Image: /ImageType:Install /ImageGroup:. |
The preceding procedure displays the file name, image name, description, architecture, image type, image group, size, HAL type, creation and modification time, languages, operating system version, ACLs, unattend file (if assigned), and the online or offline status of the image.
To convert a RIPREP image to a .wim install image
For more information, see Creating Images.
|Using the MMC |Using WDSUTIL |
|1. Click the Legacy Images node.|1. Click Start, right-click Command Prompt, and click Run as administrator. |
|2. Right-click the RIPREP image |2. Run WDSUTIL /Verbose /Progress /Convert-RiPrepImage /FilePath: |
|you want to convert, and then |/DestinationImage /FilePath:. In addition, you can specify the |
|click Convert to WIM. |following: |
|3. Enter the name, description, |• To give the new .wim image a name in the metadata, append /Name:. |
|path, and file name, and then |• To give the new .wim image a description in the metadata, append /Description:. |
|click Next. |• To convert the original RIPREP image, rather than a copy, append /InPlace. |
| |• To determine behavior when the image file specified in /DestinationImage already exists, append|
| |/Overwrite:{Yes|No|Append}. Yes will overwrite the .wim file, No will cause an error, and Append |
| |will append the new image to the existing .wim file. |
To make a copy of an install image
|Using the MMC |Using WDSUTIL |
|N/A |1. Click Start, right-click Command Prompt, and click Run as administrator. |
| |2. Run WDSUTIL /Copy-Image /Image: /ImageType:Install /ImageGroup: |
| |/DestinationImage /Name: /Filename:. To give the new image a description, append |
| |/Description:. |
The preceding procedure creates a copy of the metadata .wim file that corresponds to the selected image, and it sets the image name and file name (and description, if specified) to the values you specify.
Image Groups
To remove an image group
|Using the MMC |Using WDSUTIL |
|1. Right-click image group. |1. Click Start, right-click Command Prompt, and click Run as administrator. |
|2. Click Delete. |2. Run WDSUTIL /Remove-ImageGroup /ImageGroup:. |
This procedure deletes the image group folder and all of its contents from the image store. For install images, if an associated data folder exists (the folder that contains unattend files or language packs), it will be removed as well.
To add an image group to the image store
|Using the MMC |Using WDSUTIL |
|1. Right-click the Install Images node, and then click Add Image |1. Click Start, right-click Command Prompt, and click Run as |
|Group. |administrator. |
|2. Enter the name for the image group. |2. Run WDSUTIL /Add-ImageGroup /ImageGroup:. |
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.
[pic]Note
Changing the name renames the image group folder in the image store, and changing the security sets ACLs on the folder and its contents.
|Using the MMC |Using WDSUTIL |
|1. Right-click image group, and|1. Click Start, right-click Command Prompt, and click Run as administrator. |
|then click Rename. |2. To change the name, run WDSUTIL /Set-ImageGroup /ImageGroup: |
|2. Right-click image group, and|/Name:. |
|then click Security. |3. To set the security, run WDSUTIL /Set-ImageGroup /ImageGroup: |
| |/Security:, where SDDL is the security descriptor you want to use for the image group, in |
| |Security Descriptor Definition Language (SDDL) format. |
To display information about all images in an image group
|Using the MMC |Using WDSUTIL |
|1. Select an image group. |1. Click Start, right-click Command Prompt, and click Run as administrator. |
|2. View the images in the right pane. |2. Run WDSUTIL /Get-ImageGroup /ImageGroup:. 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
[pic]Note
Help for WDSUTIL is available by typing WDSUTIL /? at a command prompt or online at .
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.
|Consider implementing multicasting if your organization: |Multicasting might not optimize your installations if your |
| |organization: |
|• Has network routers that support multicasting. |• Has network routers that do not support multicasting. |
|• Is a large company that requires many concurrent client |• Does not have bandwidth overload problems. |
|installations. |• Deploys images to only a small number of client computers |
|• Wants to use network bandwidth efficiently. This is because |simultaneously. |
|with this feature, images are sent over the network only once, |• Has disk space limitations on the client computers. (This is |
|and you can specify limitations (for example, to only use 10 |because the image is downloaded to client computers instead of |
|percent of your bandwidth). |being installed from a server.) |
|• Has enough disk space on client computers for the image to be | |
|downloaded. | |
|• Meets the requirements listed in the following section. | |
Prerequisites for Creating a Multicast Transmission
To implement this feature in your organization, you must have all of the following:
• Routers that support multicasting. In particular, your network infrastructure needs to support the Internet Group Management Protocol (IGMP) to properly forward multicast traffic. Without the IGMP, multicast packets are treated as broadcast packets, which can lead to network flooding.
• At least one install image that you want to transmit on the server
• The Boot.wim file from the Windows Server 2008 media (located in the \Sources folder). Do not use the Boot.wim from the Windows Vista media unless your version of Windows Vista has SP1 integrated into the DVD.
• Internet Group Membership Protocol (IGMP) snooping should be enabled on all devices. This will cause your network hardware to forward multicast packets only to those devices that are requesting data. If IGMP snooping is turned off, multicast packets are treated as broadcast packets, and will be sent to every device in the subnet.
Known Issues in Creating a Multicast Transmission
You may encounter the following issues when implementing multicasting:
• If you use the Windows Vista Boot.wim file for multicast transmissions, you will be able to create the transmission, but people who boot into it will not be able to join it.
• 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.
|Consider using Auto-Cast if: |Consider using Scheduled-Cast if: |
|• You work for a large corporation or an |• You work for a smaller organization or an organization where network traffic is an |
|organization with high bandwidth that can |issue during the day. This way, you can set installations to occur during nonpeak |
|handle installations at any time. |hours or at night. |
|• You do not want customers to have to wait |• To reduce the total time of the transmission. Because you can set multiple clients |
|for the installation to begin. |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 following: |1. Click Start, right-click Command Prompt, and click Run as administrator. |
|• Right-click the Multicast |2. Do one of the following: |
|Transmission node, and then |a. To create an Auto-Cast transmission |
|click Create Multicast |Syntax: WDSUTIL /New-MulticastTransmission /Image: /FriendlyName: |
|Transmission. |/ImageType:Install /ImageGroup: /TransmissionType:AutoCast |
|• Right-click an image, and then|b. To create a Scheduled-Cast transmission |
|click Create Multicast |Syntax: WDSUTIL /New-MulticastTransmission /Image: /FriendlyName: |
|Transmission. |/ImageType:Install /ImageGroup: /TransmissionType:ScheduledCast |
| |[/Time:][/Clients:] |
To manage transmissions
|Using the MMC |Using WDSUTIL |
|• Start the transmission. If the transmission is the |• To start the transmission |
|Scheduled-Cast type, there is at least one client, and the |Syntax: WDSUTIL /Start-MulticastTransmission /Image: |
|transmission has not started yet, you can right-click the |/ImageType:Install /ImageGroup: |
|transmission and then click Start. |[pic]Note |
|• Delete the transmission. If you right-click the transmission |You can start the transmission only if it is the Scheduled-Cast |
|and click Delete, the multicast transmission stops and each |type, there is at least one client, and the transmission is not |
|client installation will fall back to using unicast transmission.|already started. |
|That is, the client installations will not be deleted or stopped,|• To delete the transmission |
|but they will not use the multicast transmission to complete the |Syntax: WDSUTIL /Remove-MulticastTransmission /Image:|
|installation. |/ImageType:Install /ImageGroup: /Force |
|• Deactivate the transmission. If you right-click the |• To deactivate the transmission |
|transmission and then click Deactivate, each client that is |Syntax: WDSUTIL /Remove-MulticastTransmission /Image:|
|currently installing will continue, but no new clients will be |/ImageType:Install /ImageGroup: |
|joined to the transmission. After each current client |• To view the transmission's properties |
|installation is completed, the transmission will be deleted. If |Syntax: WDSUTIL /Get-MulticastTransmission /Image: |
|there are no clients when you click this option, the transmission|/ImageType:Install /ImageGroup: |
|will be deleted instantly. | |
|• View the transmission's properties. To view the properties, | |
|right-click the transmission and then click Properties. Note that| |
|you cannot edit the properties of a transmission after it is | |
|created. To make a change after you have created a transmission, | |
|you need to delete it and then recreate it. | |
|• Refresh the transmissions and data. To do this, right-click a | |
|transmission and then click Refresh. You can also refresh the | |
|data by pressing F5. | |
To manage clients in a transmission
|Using the MMC |Using WDSUTIL |
|• Viewclients and see progress. To view any connected clients, |• To view clients and see progress |
|expand the Multicast Transmissions node and then click the image.|Syntax: WDSUTIL /Get-MulticastTransmission /Image: |
|The connected clients (including the current installation time |/ImageType:Install /ImageGroup: /show:clients |
|and the percentage complete) are shown in the right pane. |• To stop a client installation completely |
|• Stop a client installation. To stop the installation |Syntax: WDSUTIL /Disconnect-Client /ClientID: /Force. |
|completely, right-click a client and then click Disconnect. You |[pic]Note |
|should use this option with caution because the installation will|You should use this option with caution because the installation |
|fail and the computer could be left in an unusable state. |will fail and the computer could be left in an unusable state. |
|• Disconnect a client from a multicast transmission. To |• To disconnect a client from a multicast transmission but |
|discontinue the transmission for a particular client but continue|continue to transfer the image by using unicasting |
|to transfer the image through unicasting, right-click the client,|Syntax: WDSUTIL /Disconnect-Client /ClientID: |
|and then click Bypass multicast. |• To view the client for each transmission |
| |Syntax: WDSUTIL /Get-MulticastTransmission /Image: |
| |/ImageType:Install /ImageGroup: /show:clients |
To configure the UDP port range for multicasting
This setting specifies the range of UDP ports to use for multicasting and other components, such as the Trivial File Transfer Protocol (TFTP) provider. Before you change this range, you need to have at least as many ports as you have sessions and concurrent clients accessing the server. In terms of multicasting, a session is a network interface on your server. To calculate the number of sessions, multiply the number of network adapters on your server by the number of images that could be concurrently transferred using multicasting. For example, if you have two network adapters, and clients are connected on both interfaces, the content will be sent on the network twice (once from each interface). So in this case, you would need at least two ports. Because this range is also used by the TFTP provider, you will need as many available ports as you have concurrent clients accessing the server.
|Using the MMC |Using WDSUTIL |
|1. Right-click the server, and then click Properties. |1. Click Start, right-click Command Prompt, and click Run as |
|2. On the Network Settings tab, specify the UDP port range. |administrator. |
|3. You must restart the service before the changes will take |2. Run WDSUTIL /Set-Server [/Server:] /Transport |
|effect. To do this, right-click the server in the MMC snap-in, |/StartPort:x /EndPort:y. |
|click All Tasks, and then click Restart. |3. You must restart the service before the changes will take |
| |effect. To do this, run wdsutil /stop-server and then run wdsutil|
| |/start-server. |
To configure how the server will obtain IP addresses for multicasting
The server allocates a multicast IP address to each multicast session, and all connected clients listen in on that address. It's important that all IP addresses be unique on the network to ensure that each client receives the correct data. If you have a complex network, you should consider using DHCP to select the addresses. In more basic environments, you can configure a range and have the Windows Deployment Services server select the address.
|Using the MMC |Using WDSUTIL |
|1. Right-click the server, and then click Properties. |1. Click Start, right-click Command Prompt, and click Run as |
|2. On the Network Settings tab under Multicast IP Address, select|administrator. |
|one of the following: |2. Do one of the following: |
|• Obtain IP address from DHCP. You can select this option only if|• To use MADCAP to obtain the IP address for each namespace, run |
|your DHCP server supports it. The IP address for each namespace |WDSUTIL /Set-Server [/Server:] /Transport |
|will be obtained by using MADCAP (RFC 2730, Multicast). |/ObtainIPFrom:DHCP. |
|• Use IP address from the following range. You will need to enter|• To configure a preset range of IP addresses, run WDSUTIL |
|a range. |/Set-Server [/Server:] /Transport /ObtainIPv4From:Range |
|3. You must restart the service before the changes will take |/Start:x.x.x.x /End:y.y.y.y. |
|effect. To do this, right-click the server in the MMC snap-in, |3. You must restart the service before the changes will take |
|click All Tasks, and then click Restart. |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 .vbs . For example: cscript mcinfo.vbs localhost.
In This Topic
• Stop Transmissions Slower than 1 MB per Second
• Display Performance Information About Clients
Stop Transmissions Slower than 1 MB per Second
The following Microsoft Visual Basic script will stop the transmission of the master client for any multicast session that has been transmitting data at a rate slower then 1 MB per second for longer than 60 seconds. You can configure these values by using the parameters at the top of the script. The master client is the slowest client in a transmission — that is, the client that is not capable of installing any faster while the other clients may be able to install at a faster rate. To determine the master client, view the output of the following command: WDSUTIL /Get-MulticastTransmission /Show-clients. Note that there may be as many master clients as the server has network adapters.
' -------------Times are in milliseconds
sleepTime = 5000 ' Minimum time to wait between each query to the server
timeThreshold = 60000 ' Minimum time to wait before kicking the master client out of a slow session
' ------------- Speeds are in KB/sec
speedThreshold = 1024 ' Minimum transfer rate for a session
' ------------- Display variables
displayAllSessions = true ' Display all sessions on the server, not just the slow sessions
printStatusDots = true ' Print a dot every time we contact the server. Useful to show that the script is doing something
' ------------------------------- End user defined settings -------------------------------
Dim sessionDictionary, Manager, Server, hostname
' WDS Transport type definitions
WdsTptDisconnectUnknown = 0
WdsTptDisconnectFallback = 1
WdsTptDisconnectAbort = 2
' Run main
main()
' ---------------------------------- main
sub main
if WScript.Arguments.Count < 1 then
wscript.echo "[WARN]: Hostname not specified on command line, trying to connect to localhost"
hostname = "localhost"
else
hostname = WScript.Arguments.Item(0)
end if
' We use a dictionary to keep track of sessions on the server
Set sessionDictionary = CreateObject("Scripting.Dictionary")
' Create the Transport Manager
Set Manager = CreateObject("WdsTptMgmt.WdsTransportManager")
' Connect to the server
Set Server = Manager.GetWdsTransportServer(hostname)
' Echo out current settings
if displayAllSessions = false then
wscript.echo "[INFO]: Not displaying information for all sessions"
end if
if printStatusDots then
wscript.echo "[INFO]: Printing status dots"
end if
wscript.echo "[INFO]: Speed Threshold: " + Cstr(speedThreshold) + " KB/sec, Time Threshold: " + Cstr(Int(timeThreshold/1000)) + "s, Sleep time: " + Cstr(Int(sleepTime/1000)) + "s"
wscript.echo "[INFO]: Examining sessions on " + Server.name + "..." + vbCrLf
' Loop forever. User must control C out of the script to stop execution.
Do while true
if printStatusDots then
Wscript.StdOut.Write(".")
end if
loopAndKick()
wscript.sleep(sleepTime)
loop
end sub
' ---------------------------------- loopAndKick
sub loopAndKick
' Get a list of the namespaces on the server
Set NamespaceCollection = Server.NamespaceManager.RetrieveNamespaces("", "", False)
' Get all namespaces present on the server
for i = 1 to CLng(NamespaceCollection.count)
Set ns = NamespaceCollection.Item(i)
' Get all contents for this namespace
Set ContentCollection = NamespaceCollection.Item(i).RetrieveContents()
for j = 1 to CLng(ContentCollection.count)
Set content = ContentCollection.item(j)
' Get all sessions for this content
Set SessionCollection = content.RetrieveSessions()
for k = 1 to CLng(SessionCollection.count)
Set session = SessionCollection.item(k)
Set ClientCollection = session.RetrieveClients()
'Calculate the transfer rate, in KB/sec, for this session
tRate = CLng(session.TransferRate)
tRate = Int(tRate / 1024)
' Echo this session out to the screen
if displayAllSessions then
wscript.echo ns.name + content.name + ", Num clients: " + CStr(ClientCollection.count) + ", " + CStr(tRate) + " kB/sec"
end if
' If the session ID already exists in the dictionary, but no clients are connected, remove the entry from the dictionary
if ( (CLng(ClientCollection.count) = 0) AND sessionDictionary.Exists( CLng(session.ID)) ) then
wscript.echo vbTab + "Remove: " + Cstr(session.ID)
sessionDictionary.Remove(CLng(session.ID))
' If the session ID exists in the dictionary, update the session details, and kick the master client if needed
elseif sessionDictionary.Exists( CLng(session.ID) ) then
' Retrieve and update timeSlow
timeSlow = sessionDictionary.Item( CLng(session.ID) )
timeSlow = timeSlow + sleepTime
' If we've gone too slow for too long, kick the current master client
if ( (tRate < speedThreshold) AND (timeSlow > timeThreshold) ) then
' Make sure we have a valid master client ID before we attempt to kick
if Clng(session.MasterClientId) 0 then
wscript.echo vbTab + "Kicking client: " + Cstr(session.MasterClientId)
Server.DisconnectClient session.MasterClientId, WdsTptDisconnectFallback
' Reset time slow for this session
timeSlow = 0
end if
end if
' Remove the old entry from the dictionary
sessionDictionary.Remove(CLng(session.ID))
' If the session is still too slow, add it back to the dictionary with the new time value
if( tRate < speedThreshold) then
wscript.echo vbTab + "Update: " + Cstr(session.ID) + ", Time slow: " + Cstr(Int(timeSlow/1000)) + "s"
sessionDictionary.Add CLng(session.ID), timeSlow
Otherwise, we've removed the session from the dictionary above
else
wscript.echo vbTab + "Remove: " + Cstr(session.ID)
end if
' The session isn't in the dictionary. If the session is going too slow and has clients connected, add it to the dictionary
else
if( (tRate < speedThreshold) AND (CLng(ClientCollection.count) 0) ) then
wscript.echo vbTab + "Add: " + Cstr(session.ID)
sessionDictionary.Add CLng(session.ID), 0
end if
end if
next
next
next
end sub
Display Performance Information About Clients
The following Visual Basic script displays performance information for all clients in all transmissions that are connected to the same server.
' Create the Tranport Manager
Set Manager = CreateObject("WdsTptMgmt.WdsTransportManager")
if WScript.Arguments.Count = 0 then
wscript.echo "INFO: Specify a host name on the command line to connect to a remote host" & vbCrLf
Set Server = Manager.GetWdsTransportServer("localhost")
else
Set Server = Manager.GetWdsTransportServer(WScript.Arguments.Item(0))
end if
' Print Server name
wscript.echo "Server: " + Server.name
' Get a list of the namespaces on the server
Set NamespaceCollection = Server.NamespaceManager.RetrieveNamespaces("", "", False)
' Get all namespaces present on the server
for i = 1 to CLng(NamespaceCollection.count)
Set ns = NamespaceCollection.Item(i)
wscript.echo " Namespace ID: " + CStr(ns.id) + ", Name: " + ns.name
' Get all contents for this namespace
Set ContentCollection = NamespaceCollection.Item(i).RetrieveContents()
for j = 1 to CLng(ContentCollection.count)
Set content = ContentCollection.item(j)
wscript.echo " Content ID : " + CStr(content.id) + ", Name: " + content.name
' Get all sessions for this content
Set SessionCollection = content.RetrieveSessions()
for k = 1 to CLng(SessionCollection.count)
Set session = SessionCollection.item(k)
tRate = CLng(session.TransferRate)
tRate = Int(tRate / 1024)
' Get all clients for this session
Set ClientCollection = session.RetrieveClients()
wscript.echo " Session ID: " + CStr(session.id) + ", NIC Name: " + workInterfaceName &_
+ ", 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.
Namespace ID: 2471217798, Name: WDS:Server08/install-(2).wim/1
Namespace ID: 2471217799, Name: WDS:Server08/install.wim/1
Namespace ID: 2471217807, Name: WDS:Server03/amd64.wim/1
Namespace ID: 2471217808, Name: WDS:Server03/x86.wim/1
Namespace ID: 2471217810, Name: WDS:Vista/amd64.wim/1
Namespace ID: 2471217811, Name: WDS:Vista/x86.wim/1
Namespace ID: 2471217812, Name: WDS:XP_SP2/install-(2).wim/1
Content ID : 3263057331, Name: Res.rwm
Session ID: 3353296855, NIC Name: Broadcom NetXtreme Gigabit Ethernet #2, tRate: 0 kB/sec, clients: 0
Namespace ID: 2471217813, Name: WDS:XP_SP2/Install.wim/1
Content ID : 3263057330, Name: Res.rwm
Session ID: 3353296854, NIC Name: Broadcom NetXtreme Gigabit Ethernet #2, tRate: 883 kB/sec, clients: 1
* Client ID: 3267943420, Name: MININT-1U7QOTT, IP: 172.30.170.162, MAC: 000E7F28D375, Time connected: 1111
How to Modify the BCD Store Using Bcdedit
You can use the Boot Configuration Data Editor (Bcdedit.exe) to view and modify the contents of the Boot Configuration Data (BCD) store. Bcdedit.exe is available on computers running Windows Vista and Windows Server 2008. For more information, see "Boot Configuration Data Editor Frequently Asked Questions" ().
[pic]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
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
Example:
C:\>bcdedit /enum all /store c:\RemoteInstall\Boot\x86\default.bcd
Windows Boot Manager
--------------------
identifier {bootmgr}
inherit {dbgsettings}
timeout 30
Real-mode Application (10400009)
--------------------------------
identifier {40fe5c41-285e-412b-b4cd-0ce498e470a2}
device boot
path OSChooser\i386\startrom.n12
description Remote Installation Services
pxesoftreboot Yes
Debugger Settings
-----------------
identifier {dbgsettings}
debugtype Serial
debugport 1
baudrate 115200
Device options
--------------
identifier {68d9e51c-a129-4ee1-9725-2ab00a957daf}
ramdisksdidevice boot
ramdisksdipath \Boot\Boot.SDI
2. Set the appropriate time-out value by running the following command:
Syntax: bcdedit /store /set {bootmgr} timeout
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
Example:
C:\>bcdedit /enum all /store c:\RemoteInstall\Boot\x86\default.bcd
Windows Boot Manager
--------------------
identifier {bootmgr}
inherit {dbgsettings}
timeout 30
Real-mode Application (10400009)
--------------------------------
identifier {40fe5c41-285e-412b-b4cd-0ce498e470a2}
device boot
path OSChooser\i386\startrom.n12
description Remote Installation Services
pxesoftreboot Yes
Debugger Settings
-----------------
identifier {dbgsettings}
debugtype Serial
debugport 1
baudrate 115200
Device options
--------------
identifier {68d9e51c-a129-4ee1-9725-2ab00a957daf}
ramdisksdidevice boot
ramdisksdipath \Boot\Boot.SDI
2. Set the appropriate locale value by running the following command:
Syntax: bcdedit /store /set {bootmgr} locale
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 /set {bootmgr} path
Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set {bootmgr} path \boot\\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
Example:
C:\>bcdedit /enum all /store c:\RemoteInstall\Boot\x86\default.bcd
Windows Boot Manager
--------------------
identifier {bootmgr}
inherit {dbgsettings}
timeout 30
Real-mode Application (10400009)
--------------------------------
identifier {40fe5c41-285e-412b-b4cd-0ce498e470a2}
device boot
path OSChooser\i386\startrom.n12
description Remote Installation Services
pxesoftreboot Yes
Debugger Settings
-----------------
identifier {dbgsettings}
debugtype Serial
debugport 1
baudrate 115200
Device options
--------------
identifier {68d9e51c-a129-4ee1-9725-2ab00a957daf}
ramdisksdidevice boot
ramdisksdipath \Boot\Boot.SDI
2. Set the appropriate TFTP block size value by running the following command:
Syntax: bcdedit /store /set {} ramdisktftpblocksize
Example: C:\>bcdedit /store c:\RemoteInstall\boot\x86\default.bcd /set {68d9e51c-a129-4ee1-9725-2ab00a957daf} ramdisktftpblocksize 4096
[pic]Note
We recommend that you go up in multiples (4096, 8192, 16384, and so on) and that you not set a value higher than 16384.
3. Force regeneration of the BCD store in the \Tmp folder by sending a control signal to the WDSServer service, using the following command:
C:\>sc control wdsserver 129
To Configure the TFTP Window Size
The default TFTP window size is 8. You can configure this value by setting the appropriate value in the default BCD store for the client architecture, using the following steps:
1. At the command prompt, determine the GUID identifier of the boot manager application by running the following command:
Syntax: bcdedit /enum all /store
2. Set the appropriate TFTP window size by running the following command:
Syntax: bcdedit /store {} ramdisktftpwindowsize
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. |
[pic]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 |
|Example: |
|C:\>bcdedit /enum all /store c:\RemoteInstall\Boot\x86\default.bcd |
| |
|Windows Boot Manager |
|-------------------- |
|identifier {bootmgr} |
|inherit {dbgsettings} |
|timeout 30 |
| |
|Real-mode Application (10400009) |
|-------------------------------- |
|identifier {40fe5c41-285e-412b-b4cd-0ce498e470a2} |
|device boot |
|path OSChooser\i386\startrom.n12 |
|description Remote Installation Services |
|pxesoftreboot Yes |
| |
|Debugger Settings |
|----------------- |
|identifier {dbgsettings} |
|debugtype Serial |
|debugport 1 |
|baudrate 115200 |
| |
|Device options |
|-------------- |
|identifier {68d9e51c-a129-4ee1-9725-2ab00a957daf} |
|ramdisksdidevice boot |
|ramdisksdipath \Boot\Boot.SDI |
|2. Set the appropriate debugging values by running the following command: |
|Syntax: bcdedit /store /set {bootmgr} bootdebug |
|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 |
[pic]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 /enum all |
|Example: |
|C:\>bcdedit /store c:\RemoteInstall\Boot\x86\Images\boot.wim.bcd /enum all |
| |
|Windows Boot Loader |
|------------------- |
|identifier {06689f95-f69c-4937-8ded-09a966a6a319} |
|device ramdisk=[boot]\Boot\x86\Images\boot.wim,{68d9e51c-a129-4ee1-9725-2ab00a957da |
|f} |
|description WinPE 5600 RC1 |
|osdevice ramdisk=[boot]\Boot\x86\Images\boot.wim,{68d9e51c-a129-4ee1-9725-2ab00a957da |
|f} |
|systemroot \WINDOWS |
|detecthal Yes |
|winpe Yes |
|2. Enable debugging options by running the following command: |
|Syntax: bcdedit /store /set debug |
|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 /set inherit {dbgsettings} |
|Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set {06689f95-f69c-4937-8ded-09a966a6a319} inherit |
|{dbgsettings} |
|4. Force regeneration of the BCD store in the \Tmp folder by sending a control signal to the server service, using the |
|following command: |
|C:\>sc control wdsserver 129 |
To Turn On Emergency Management Services Settings
For servers equipped with the proper firmware, Emergency Management Services (EMS) provides functionality that you can use to administer a server remotely. This is useful for computers that do not support direct video output or do not have a keyboard and mouse attached. Except for hardware maintenance and replacement, all administrative functions that you can accomplish locally should be available remotely. This includes starting your system and performing system-recovery tasks. This method is typically used for high-end servers in a data center.
There are generally two types of devices that support remote administration: those whose BIOS and Extensible Firmware Interface (EFI) support UI redirection, and those whose BIOS does not 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.n12, , 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.
[pic]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 /enum all |
|Example: |
|C:\>bcdedit /store c:\RemoteInstall\Boot\x86\Images\boot.wim.bcd /enum all |
| |
|Windows Boot Loader |
|------------------- |
|identifier {06689f95-f69c-4937-8ded-09a966a6a319} |
|device ramdisk=[boot]\Boot\x86\Images\boot.wim,{68d9e51c-a129-4ee1-9725-2ab00a957da |
|f} |
|description WinPE 5600 RC1 |
|osdevice ramdisk=[boot]\Boot\x86\Images\boot.wim,{68d9e51c-a129-4ee1-9725-2ab00a957da |
|f} |
|systemroot \WINDOWS |
|detecthal Yes |
|winpe Yes |
|2. Create the EMS settings option in the Default.bcd store by running the following command: |
|Syntax: bcdedit /store /create {emssettings} /d |
|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 /set {emssettings} baudrate |
|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 /set {emssettings} debugtype |
|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 /set {emssettings} debugport |
|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 /enum all |
|Example: |
|C:\>bcdedit /store c:\RemoteInstall\Boot\x86\Images\boot.wim.bcd /enum all |
| |
|Windows Boot Loader |
|------------------- |
|identifier {06689f95-f69c-4937-8ded-09a966a6a319} |
|device ramdisk=[boot]\Boot\x86\Images\boot.wim,{68d9e51c-a129-4ee1-9725-2ab00a957da |
|f} |
|description WinPE 5600 RC1 |
|osdevice ramdisk=[boot]\Boot\x86\Images\boot.wim,{68d9e51c-a129-4ee1-9725-2ab00a957da |
|f} |
|systemroot \WINDOWS |
|detecthal Yes |
|winpe Yes |
|7. Enable EMS settings in the per-image BCD by running the following command: |
|Syntax: bcdedit /store /set ems |
|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 /set 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.
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.
[pic]Note
• TFTP block size
• Other network conditions (such as workload, the quality of the hardware that is installed, and electromagnetic noise considerations)
Diagnosing TFTP Download Performance Problems
The simplest way to diagnose long download times (observed from the client computer as a progress bar below an IP address) is to look at the average response time between the client and the server it is downloading from. To do this, in Windows PE, open the Command Prompt window, type ping , 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 ................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.