Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Prestaging Client Computers
Document related concepts
Transcript
Windows Deployment Services Deployment Guide Microsoft Corporation Published: March 2009 Author: Trina Gorman Abstract This document contains detailed information that explains how to configure Windows Server® 2008 to deploy operating system images to computers. Copyright information Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. © 2009 Microsoft Corporation. All rights reserved. Active Directory, Microsoft, Windows, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. All other trademarks are property of their respective owners. Contents Windows Deployment Services Deployment Guide ...................................................................... 13 In This Guide .............................................................................................................................. 13 In This Topic ............................................................................................................................... 13 Benefits of Windows Deployment Services ............................................................................... 14 Management Tools..................................................................................................................... 14 Common Usage Scenarios ........................................................................................................ 14 Scenario One: The Small Business ........................................................................................ 14 Scenario Two: The Medium-Sized Business .......................................................................... 16 Scenario Three: The Large Enterprise ................................................................................... 17 Scenario Four: A Custom Deployment Using Transport Server ............................................. 18 Configuring Your Deployment ....................................................................................................... 19 Configuring AD DS Integration ...................................................................................................... 19 In This Topic ............................................................................................................................... 19 Supported Environments ............................................................................................................ 19 Configuring Static Domain Controllers and Global Catalog Servers ......................................... 20 Creating a Localized Setup Experience ........................................................................................ 20 In This Topic ............................................................................................................................... 21 Localizing the Boot Menu ........................................................................................................... 21 Localizing Setup ......................................................................................................................... 21 Installing Language Packs ......................................................................................................... 23 Methods .................................................................................................................................. 23 Storing Language Packs in the Image Store .......................................................................... 24 Configuring DHCP ......................................................................................................................... 25 In This Topic ............................................................................................................................... 25 Configuring DHCP Options ........................................................................................................ 25 Enabling DHCP Authorization .................................................................................................... 26 Authorizing a Server ................................................................................................................... 27 Managing Network Boot Programs................................................................................................ 27 In This Topic ............................................................................................................................... 28 Configuring the NBP .................................................................................................................. 28 List of NBPs ................................................................................................................................ 28 Directing a Client to the Appropriate NBP .................................................................................. 29 Updating the IP Helper Tables ................................................................................................ 30 Using DHCP Options 60, 66, and 67 ...................................................................................... 30 Implementing PXE Referrals ...................................................................................................... 31 When to Implement PXE Referrals ......................................................................................... 31 Requirements.......................................................................................................................... 32 Referral Examples .................................................................................................................. 32 Enabling Architecture Detection ................................................................................................. 33 Avoiding a Boot Loop ................................................................................................................. 34 Managing the Boot Menu .............................................................................................................. 34 In This Topic ............................................................................................................................... 34 Configuring the Boot Menu ........................................................................................................ 35 Specifying Boot Images for Prestaged Clients ........................................................................... 35 Considerations for x64-Based Clients ........................................................................................ 36 Prestaging Client Computers ......................................................................................................... 36 In This Topic ............................................................................................................................... 36 Creating Computer Account Objects in AD DS .......................................................................... 36 Benefits ...................................................................................................................................... 37 Enabling the Auto-Add Policy..................................................................................................... 37 Purging the Auto-Add Database ................................................................................................ 38 Optimizing Your Deployment ......................................................................................................... 39 Extending Your Solution ................................................................................................................ 39 In This Topic ............................................................................................................................... 39 Benefits ...................................................................................................................................... 39 Creating a Custom Solution ....................................................................................................... 40 Windows Deployment Services PXE Server ....................................................................... 40 Windows Deployment Services Client................................................................................. 41 Custom Solution Example .......................................................................................................... 41 Instructions for Using the Sample Code ................................................................................. 42 Sample Visual Basic Script ..................................................................................................... 43 Sample Image Unattend File .................................................................................................. 44 Sample WinPESHL.ini File ..................................................................................................... 45 Managing a Complex Environment ............................................................................................... 45 In This Topic ............................................................................................................................... 45 Managing a Server Remotely..................................................................................................... 45 Avoiding IP Address Conflicts .................................................................................................... 46 Testing by Using Virtual Computers........................................................................................... 47 Versions of the Management Tools to Use with RIS and Windows Deployment Services ....... 47 Optimizing Performance and Scalability ........................................................................................ 49 In This Topic ............................................................................................................................... 49 Best Practices for Avoiding Performance and Scalability Problems .......................................... 49 Configuring the Server for Performance and Scalability ............................................................ 50 Performance and Scalability Expectations ................................................................................. 50 Unicasting ............................................................................................................................ 51 Multicasting .......................................................................................................................... 52 Multicast Installation ......................................................................................................... 53 Unicast Installation ........................................................................................................... 53 Testing of Security Options with Multicast ....................................................................... 54 Using Transport Server ................................................................................................................. 54 In This Topic ............................................................................................................................... 54 Comparison of Deployment Server and Transport Server ......................................................... 55 Configuring Transport Server ..................................................................................................... 56 Using a Transport Server to Boot from the Network .................................................................. 57 Using a Transport Server for Multicasting .................................................................................. 57 How to create a namespace with Transport Server ............................................................... 57 Prerequisites for creating a namespace .............................................................................. 57 To create a namespace ....................................................................................................... 58 How to join a client computer to a namespace by using Wdsmcast.exe ................................ 58 How to perform common tasks ............................................................................................... 60 Options ............................................................................................................................. 61 Performing Unattended Installations ............................................................................................. 62 Automating the PXE Boot .............................................................................................................. 63 In This Topic ............................................................................................................................... 63 Automating the PXE Boot .......................................................................................................... 63 Avoiding a Boot Loop .............................................................................................................. 63 Example Scenario ................................................................................................................... 64 Automating the Selection of the Boot Image .............................................................................. 64 Automating Setup .......................................................................................................................... 65 In This Topic ............................................................................................................................... 65 Creating Unattend Files ............................................................................................................. 65 Automating the User Interface Screens of the Windows Deployment Services Client .............. 66 Unattend File Settings ............................................................................................................ 67 Automating the Remaining Setup Phases ................................................................................. 68 Automating the Domain Join ......................................................................................................... 69 In This Topic ............................................................................................................................... 69 Modifying Your Unattend Files ................................................................................................... 69 Choosing a Permissions Method ............................................................................................... 70 Automating the Image Capture Wizard ......................................................................................... 71 WDSCapture.inf Unattend File Settings ..................................................................................... 71 Advanced Unattended Installation Scenarios ................................................................................ 73 In This Topic ............................................................................................................................... 74 Passing Unattend Files to Setup by Using the Command Line ................................................. 74 Using Implicit Unattend Files ...................................................................................................... 75 Embedding an Unattend File in an Image .................................................................................. 75 Understanding Unattend File Precedence ................................................................................. 75 Setting Command-Line Precedence for Image Unattend Files ................................................. 76 Using Variables to Obtain Information from the Client ............................................................... 77 Sample Unattend Files .................................................................................................................. 77 In This Topic ............................................................................................................................... 77 Windows Deployment Services Client Unattend Files ............................................................... 78 Example 1: Standard installation ............................................................................................ 78 Example 2: Install a language pack ........................................................................................ 80 Image Unattend Files for Windows Vista and Windows Server 2008 ........................................ 82 Example 1: Unsecure domain join .......................................................................................... 82 Example 2: Secure domain join .............................................................................................. 83 Example 3: Using variables .................................................................................................... 84 Image Unattend Files for Older Operating Systems .................................................................. 85 Example 1: Domain join .......................................................................................................... 85 Example 2: Using variables .................................................................................................... 86 Example 3: Run a script .......................................................................................................... 86 Combined Image and Client Unattend File ................................................................................ 87 Image Capture Wizard Unattend File ......................................................................................... 91 Working with Images ..................................................................................................................... 92 Creating Images ............................................................................................................................ 92 In This Topic ............................................................................................................................... 92 Image Types ............................................................................................................................... 92 Boot Images ............................................................................................................................... 93 Creating Custom Boot Images ................................................................................................ 93 Versions of Windows PE ........................................................................................................ 93 Discover Images......................................................................................................................... 94 Creating Custom Discover Images ......................................................................................... 95 Capture Images .......................................................................................................................... 96 Comparison of ImageX and Image Capture Wizard ............................................................... 96 Creating Custom Capture Images .......................................................................................... 97 Converting RIPREP Images ....................................................................................................... 97 Default Conversion ................................................................................................................. 97 In-Place Conversion................................................................................................................ 97 Deploying Earlier Versions of Windows ........................................................................................ 98 Filtering Images ............................................................................................................................. 99 Automatic Filtering by Windows Deployment Services .............................................................. 99 Filtering Images Manually ........................................................................................................ 100 Servicing Images ......................................................................................................................... 100 In This Topic ............................................................................................................................. 100 Types of Servicing .................................................................................................................... 100 Servicing an Image Offline ....................................................................................................... 101 Reducing the Size of Images ................................................................................................... 102 Storing and Replicating Images Using DFS ................................................................................ 102 Storing Files on Another Server ............................................................................................... 102 Replicating Images ................................................................................................................... 103 How to Perform Common Tasks ................................................................................................. 104 How to Manage Your Server ....................................................................................................... 105 General Tasks .......................................................................................................................... 107 To configure Windows Deployment Services ....................................................................... 107 To start or stop the server ..................................................................................................... 108 To enable the server ............................................................................................................. 108 To enable logging for the Windows Deployment Services client .......................................... 108 To choose the port number for RPCs ................................................................................... 109 To specify the network interfaces for Windows Deployment Services to listen on .............. 109 To configure how often the server refreshes its settings ...................................................... 110 To force the server to update files in the RemoteInstall folder ............................................. 110 To configure the network profile for the server ..................................................................... 110 To back up the server data ................................................................................................... 111 DHCP ....................................................................................................................................... 111 To configure Windows Deployment Services to run on the same computer as Microsoft DHCP ................................................................................................................................ 111 To configure Windows Deployment Services to run on the same computer as non-Microsoft DHCP ................................................................................................................................ 112 To turn on the DHCP authorization requirement .................................................................. 112 To authorize the server in DHCP .......................................................................................... 112 Client Requests ........................................................................................................................ 113 To configure the server to answer clients ............................................................................. 113 To set a delay in the server’s answers to PXE requests ...................................................... 114 To configure unknown clients to perform PXE boots without requiring F12 ......................... 114 To configure clients who have booted without F12 to require a key press on subsequent boots .................................................................................................................................. 114 To configure the server to determine the architecture of booting clients .............................. 115 Client Boot Settings .................................................................................................................. 115 To choose which boot images are displayed on x64-based computers ............................... 115 To choose the default network boot program for each architecture ..................................... 115 To choose the default network boot program that does not require F12 for each architecture ........................................................................................................................................... 116 To choose the default boot image for each architecture ...................................................... 116 Active Directory Domain Services ............................................................................................ 117 To specify a domain controller for Windows Deployment Services ...................................... 117 To specify a global catalog server for Windows Deployment Services ................................ 117 To choose whether to search for computer accounts in the domain controller before searching the global catalog .............................................................................................. 117 To configure the server to prestage clients by using their MAC address instead of their GUID ........................................................................................................................................... 118 To maintain a list of GUIDs that belong to multiple computers ............................................ 118 To specify how to generate computer names ....................................................................... 119 To specify the domain and OU in which to create computer accounts ................................ 119 To choose whether to join client computers to the domain .................................................. 120 Unattend File ............................................................................................................................ 121 To choose a default unattend file for the Windows Deployment Services client .................. 121 To specify whether an unattend file on the client computer will override a default unattend file ........................................................................................................................................... 121 How to Manage Client Computers............................................................................................... 122 Prestage Computers ................................................................................................................ 123 To prestage a client computer .............................................................................................. 123 To prestage a client computer to boot from a different server .............................................. 124 To prestage a client computer to use a network boot program other than the default ......... 124 To prestage a client computer to use an unattend file other than the default for the Windows PE phase of unattended setup .......................................................................... 124 To prestage a client computer to use a boot image other than the default .......................... 125 To prestage a client computer to join a domain .................................................................... 125 To view the attributes of a prestaged client .......................................................................... 126 Configure the Auto-Add Policy ................................................................................................. 126 To enable the Auto-Add policy.............................................................................................. 126 To change the length of time approved computers are held in the Auto-Add database ...... 127 To change the length of time rejected and pending computers are held in the Auto-Add database ............................................................................................................................ 127 To delete the approved or rejected computers table ............................................................ 127 Specify Settings for Pending Computers ................................................................................. 128 To change the rate at which pending computers will poll the server .................................... 128 To change the number of times pending computers will poll the server .............................. 128 To change the message displayed to pending computers ................................................... 128 To set a default network boot server for pending computers ............................................... 129 To set a default network boot program for pending computers ............................................ 129 To set a default unattend file for pending computers ........................................................... 129 To set a default boot image for pending computers ............................................................. 130 To set domain join options for pending computers ............................................................... 130 Approve and Reject Pending Computers ................................................................................. 131 To view the list of computers that are pending approval ...................................................... 131 To approve a pending computer by using the default settings ............................................. 131 To approve all pending computers by using the default settings ......................................... 131 To approve a pending computer, but change a setting ........................................................ 132 To approve all pending computers, but change a setting ..................................................... 132 To reject a pending computer ............................................................................................... 133 How to Manage Images ............................................................................................................... 134 General Tasks .......................................................................................................................... 134 To export an image from the server to a stand-alone .wim file ............................................ 134 To replace an image on the server with an updated version ................................................ 135 To remove an image ............................................................................................................. 136 Boot Images ............................................................................................................................. 136 To add a boot image to the server ........................................................................................ 136 To set the attributes on a boot image ................................................................................... 137 To display the attributes of a boot image .............................................................................. 138 To create a capture image .................................................................................................... 138 To create a discover image .................................................................................................. 139 Install Images ........................................................................................................................... 139 To add an install image ......................................................................................................... 139 To set the attributes for an install image ............................................................................... 139 To display the attributes for an install image ........................................................................ 140 To convert a RIPREP image to a .wim install image ............................................................ 140 To make a copy of an install image ...................................................................................... 141 Image Groups........................................................................................................................... 141 To remove an image group ................................................................................................... 141 To add an image group to the image store ........................................................................... 142 To set the attributes on an image group ............................................................................... 142 To display information about all images in an image group ................................................. 143 How to Create Multicast Transmissions ...................................................................................... 143 In This Topic ............................................................................................................................. 143 When to Implement Multicasting .............................................................................................. 143 Prerequisites for Creating a Multicast Transmission ................................................................ 144 Known Issues in Creating a Multicast Transmission................................................................ 144 Transmission Types ................................................................................................................. 145 To create a multicast transmission with Deployment Server ................................................... 146 To manage transmissions ........................................................................................................ 146 To manage clients in a transmission ........................................................................................ 147 To configure the UDP port range for multicasting .................................................................... 148 To configure how the server will obtain IP addresses for multicasting .................................... 149 Example Multicast Scripts ........................................................................................................... 150 In This Topic ............................................................................................................................. 150 Stop Transmissions Slower than 1 MB per Second ................................................................. 150 Display Performance Information About Clients ...................................................................... 155 How to Modify the BCD Store Using Bcdedit .............................................................................. 158 In This Topic ............................................................................................................................. 158 To View the Contents of the BCD Store .................................................................................. 159 To Configure the Default Selection Time-out Value................................................................. 159 To Configure a Localized Boot Manager Experience .............................................................. 160 To Configure the TFTP Block Size........................................................................................... 161 To Configure the TFTP Window Size....................................................................................... 163 To Configure Windows Debugger Options .............................................................................. 163 To Turn On Emergency Management Services Settings ........................................................ 166 Troubleshooting ........................................................................................................................... 169 Troubleshooting Performance Problems ..................................................................................... 169 In This Topic ............................................................................................................................. 169 Analyzing Blockages in Each Phase of Installation ................................................................. 169 PXE Boot Phase ................................................................................................................... 169 TFTP Download Phase ......................................................................................................... 170 Diagnosing TFTP Download Performance Problems ....................................................... 170 Addressing TFTP Download Performance Problems ....................................................... 171 Image Apply Phase ............................................................................................................... 172 Diagnosing Performance Problems in the Image Apply Phase ........................................ 172 Addressing Performance Problems in the Image Apply Phase ........................................ 172 Using Performance Monitoring ................................................................................................. 173 Common Problems ...................................................................................................................... 176 Performing PXE Boots on Client Computers ........................................................................... 177 I am unable to perform PXE boots on client computers. ................................................... 177 When I perform a PXE boot and select a boot image, I see a command prompt. ............ 178 The client computer fails to get an IP address when I try to PXE boot. ............................ 178 The client computer obtains an IP address but then fails to download a NBP. ................ 178 I don't see the hard drive of the client computer on the disk configuration page of Setup.178 My computer loads the boot image, but it cannot access an install image. ...................... 178 I created an unattend file, but when installation completes, my client computer is not joined to the domain. ................................................................................................................ 179 Install images do not appear on the image selection page. .............................................. 179 Troubleshooting x64-Based Client Computers ........................................................................ 179 My x64-based client computer does not have any x64-based images on the boot image selection page. ............................................................................................................... 179 My x64-based client computer is detected as x64, but it fails to boot to the default image. ....................................................................................................................................... 179 Performing Management Operations ....................................................................................... 180 I can't approve a pending computer. ................................................................................. 180 I approved a pending computer and then deleted the computer account that was created in AD DS during the process. Now the server will not answer my client computer. .......... 180 I received the error: "0x2: File not found" when trying to manage a remote Windows Deployment Services server. ......................................................................................... 180 Creating Custom Install Images ............................................................................................... 180 When using Image Capture Wizard to create a custom image, the volume that contains my image is not selectable. ................................................................................................. 180 The finish button is not enabled on the final page of the image capture wizard. .............. 182 Multicasting .............................................................................................................................. 182 My multicast transmissions are running very slowly. ........................................................ 182 After enabling multicasting, there is excessive traffic on the network. .............................. 183 Logging and Tracing .................................................................................................................... 183 Network Ports Used ..................................................................................................................... 187 Protocols .................................................................................................................................. 187 Ports ......................................................................................................................................... 187 Required Permissions ................................................................................................................. 188 In This Topic ............................................................................................................................. 188 General Permissions ................................................................................................................ 189 Permissions for Common Management Tasks ........................................................................ 189 Permissions for Client Installations .......................................................................................... 193 Permissions for Server Properties ........................................................................................... 195 Windows Deployment Services Deployment Guide This guide contains detailed information about how to manage and deploy operating systems by using Microsoft® Windows® Deployment Services. To download the Windows Deployment Services documentation (including a getting started guide, deployment guide, and WDSUTIL command-line syntax), see http://go.microsoft.com/fwlink/?LinkId=89381. For information about what is new in each version of Windows Deployment Services, see Windows Deployment Services: What's New (http://go.microsoft.com/fwlink/?LinkId=140114). In This Guide Configuring Your Deployment Optimizing Your Deployment Performing Unattended Installations Working with Images How to Perform Common Tasks Troubleshooting Note the following information about this documentation: This guide applies only to the Windows Deployment Services server role for Windows Server 2008. It does not apply to the Windows Deployment Services update (which is included in the Windows AIK and Windows Server 2003 SP2). For more information about the Windows Deployment Services update, see http://go.microsoft.com/fwlink/?LinkId=81031. This guide focuses primarily on the functionality of the complete installation of Windows Deployment Services (Deployment Server role service). For information about configuring and using the Transport Server role service, see Using Transport Server. For information about installing and configuring this role, see Windows Deployment Services Getting Started Guide. To provide feedback on this documentation, e-mail [email protected]. In This Topic Benefits of Windows Deployment Services Management Tools Common Usage Scenarios 13 Benefits of Windows Deployment Services Windows Deployment Services provides the following installation and deployment benefits: Reduces the complexity of deployments and the costs associated with inefficient manual installation processes. Enables you to perform network-based installation of Windows operating systems, including Windows Vista and Windows Server 2008. Deploys Windows images to computers without operating systems. Supports mixed environments that include Windows Vista, Windows Server 2008, Microsoft Windows XP, and Microsoft Windows Server 2003. Provides an end-to-end solution for the deployment of Windows operating systems to client computers and servers. Uses standard Windows Server 2008 setup technologies, including Windows PE, .wim files, and image-based setup. Management Tools Windows Deployment Services MMC snap-in. A console that provides an easy way to manage images, computers, and common server settings. You can perform almost all tasks from the MMC snap-in (you cannot prestage client computers, but you can use it to set the Auto-Add policy and approve or reject pending computers). Note that the snap-in is not available when you are using the Transport Server role service. WDSUTIL command-line tool. A tool that enables you to manage the full functionality of the server. WDSUTIL also enables you to script common tasks; simple batch files can run the required commands because no command requires an interactive user session. Common Usage Scenarios The following are common scenarios for Windows Deployment Services. Scenario One: The Small Business Fabrikam, Inc. is a manufacturer of towels with custom designs. It is a small business with a single office. Monica Brink, Fabrikam's resident IT professional, is responsible for maintaining the IT infrastructure for the company, which consists of 25 client computers running Windows XP SP2 Professional and a single server running Windows Server 2003 with SP2. The server functions as a file print server, Web server, Exchange server, Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP) server, and domain controller. The computers are linked by a 100-MBps Ethernet connection. Monica is given the task of moving all of the client computers to the Windows Vista operating system and upgrading the single server to Windows Server 2008. Because this takes all of those 14 computers out of action (effectively disabling the office workers), it is important that she makes the switch as quickly as possible. In the past, she deployed a new operating system one computer at a time. This took her around 45 minutes per computer (almost 19 hours to set up the operating system on all the client computers). For almost three days, Monica was unavailable to work on anything else. Then she would spend almost as much time installing the applications on each computer. Monica is the only IT professional at Fabrikam, which means that she also must help teach users about the new operating system. Therefore, it is important that she minimizes the amount of time she spends on deployment. To accomplish this, Monica chooses to use Windows Deployment Services because she can: Save time by running several installations simultaneously. Use a custom install image with preinstalled applications. Create an image by using the Windows Deployment Services Image Capture Wizard. To begin, Monica does the following: 1. Upgrades her server to Windows Server 2008. 2. Installs the Windows Deployment Services server role. 3. Adds the Boot.wim from the Windows Server 2008 media (which contains a Windows PE image, Setup.exe, and supporting files). 4. Adds the Install.wim from the Windows Vista media to the Windows Deployment Services server by using the MMC snap-in. 5. Uses the MMC snap-in to create a capture image from the boot image she added in step 3. This image contains Windows PE and a wizard that will capture her custom image into a .wim file. All users at Fabrikam have the same desktop hardware, which was purchased from a single vendor. To deploy on each of these computers a standardized image that contains the operating system and preinstalled applications, Monica does the following: 1. Boots a reference computer from the network and installs the Install.wim onto it, which contains the standard version of Windows Vista. 2. Installs Microsoft Office, the company's towel-design application, and the latest drivers from the manufacturer’s site. 3. Uses Sysprep to generalize the operating system. 4. Reboots the computer into the capture image. 5. Uses the Image Capture Wizard to recapture the operating system and upload it directly to the Windows Deployment Service server. Now, Monica is ready to install the new operating systems. She does not need to migrate any user data, because all of the employees store their user data on a server (rather than on their hard disks). She reboots a client computer and then presses F12 to perform a network boot. This boots her into the Boot.wim file, which guides her through the installation process. She selects the disk partition and image she wants, and then the installation begins. While waiting for the 15 image to be applied to the first computer, Monica boots another computer and starts the same process on that one. Scenario Two: The Medium-Sized Business Northwind Traders is a shipping firm with three offices: a central office in Tooth City, and branch offices in the towns of Brushville and Flosston. Ron Gable is one of six IT staff members at Northwind Traders. His responsibility is maintaining the 250 client computers used by the company's employees. These are mostly desktop computers, but the sales force uses laptops for customer presentations. There are 200 computers in the central office in Tooth City, and 25 each in the Brushville and Flosston offices. Each site has an internal network running at 100 MB per second (MBps), and the branch sites are connected to the Tooth City office by a T1 line. Ron has three servers at the Tooth City office and one in each of the branch offices, which are administered remotely. Ron’s supervisor has tasked him with deploying Windows Vista to the whole company. Previously, this would have involved many expensive trips to Brushville and Flosston, and it would have taken Ron several weeks to complete. He wants to use Windows Deployment Services to deploy Windows Vista remotely; however, company policy dictates that there can be only one DHCP server on the corporate network, and this server is located at the Tooth City office. Remotely deploying images to the 50 computers at the branch offices would cause immense congestion on the connection. Ron chooses to use Windows Deployment Services because with unattended setup, he can: Deploy Windows Vista to computers at the branch sites without being physically present there. Use his existing replication solution to deliver images to the branch site servers. Use the PXE boot referral system to minimize network traffic between the branch sites and the central office. Ron configures the Windows Deployment Services server in the central office to pass on any network boot requests from the branch offices to the local servers, which will supply the boot programs and subsequent images. This minimizes the traffic on the line between the offices. Ron has two standard operating system configurations — one for the desktop computers and one for laptops that contains the sales presentations and drivers for projectors. Therefore, he builds two images: one with the desktop configuration, and one with the laptop configuration (with no applications). He stores all the user data on one of the servers, so he can deploy Windows Vista without preserving any existing data on the client computers. Ron uses Windows System Image Manager (Windows SIM) to author two image unattend files — one for the desktop computers and one for the laptops. These files automate the installation, so Ron does not need to be present at each computer during the installation. They also automatically install Microsoft Office and the line-of-business application that the company uses for package tracking. He uses the Windows Deployment Services management tools to associate them with the images. 16 Next, Ron uses Active Directory® Domain Services (AD DS) to offer all computers a boot program. The computer boots without requiring the users to press F12, and it assigns the correct images to all of the desktops and laptops. He has configured each computer so when it is restarted, it will boot from the network automatically and deploy the appropriate image. After the image is applied to each computer, the computer is automatically joined to the corporate domain and restarted. This time, it is served a different boot program that requires pressing F12 (so that it boots to the hard disk drive and finishes the installation process). This prevents a boot loop, in which the computer would continue booting into Setup. When the installation is completed, the computer is ready for the user to log on. Scenario Three: The Large Enterprise Shu Ito is the network architect for Wide World Importers, a large enterprise with 5,000 employees in offices all over the world. The major employee centers are in the United States and Germany, and there are 13 branch offices in other countries. Shu has five servers available to him in the U.S. hub, two in the German hub, and one in each of the branch offices. The servers at the hubs are connected to the corporate Ethernet on 1-GB-per-second (GBps) network interface cards (NICs); the other computers are on 100-MBps NICs. The hubs are connected by T3 lines, and the other sites are connected by T1 lines. All of the servers are hired on two-year leases. Wide World Importers is replacing the accounting department’s 200 computers with computers running Windows Vista. Shu would also like to deploy a Windows Server 2008 image to any newly leased servers in the U.S. office. The servers in the German office and the branch sites are the responsibility of the local administrators. Currently, deployments at Wide World Importers are done by using RIS, and Shu wants to ensure that the existing computer building processes are preserved with the move to Windows Deployment Services. In addition, it is important that each computer is deployed with an operating system in a language that is appropriate for the users in that country or region. Shu chooses to use Windows Deployment Services because it enables him to do the following: Use appropriate language packs to reduce the required number of images. Manage all of his Windows Deployment Services servers from a single computer. Use multicast deployments to preserve bandwidth while deploying images to many computers concurrently. Write scripts to automate common management tasks. Shu upgrades his servers to Windows Server 2008, which gives him the ability to initialize and configure the Windows Deployment Services servers remotely, using the management tools. Then he starts creating his images. The vast majority of his deployments will be in English or German, so he creates a Windows Vista image in each language. Other languages will be installed by using external language packs, and applications will be downloaded by using Systems Management Server (SMS). Shu first uploads the images and language packs to the Windows Deployment Services server. Next, he creates the Windows Server 2008 image. Shu authors unattend files with Windows SIM. He then uses File Replication Service (FRS) to copy the images, language packs, and unattend files to the Windows Deployment Services 17 servers around the world. Of the accounting computers used by Wide World Importers, 150 are in the U.S. office, 30 are in the German office, and the remaining 20 are scattered around the world. Shu uses multicasting to deploy to the 150 computers in the U.S. office simultaneously. To do this, he creates a multicast transmission for the Windows Vista image on his Windows Deployment Services server. To preserve the state and data on the previous computers, Shu uses the User State Migration Tool (USMT) to save all of the data and user configurations to a shared folder on the primary Windows Deployment Services server. Then he sets up each computer to boot from its local Windows Deployment Services server and to start automated setup by using the unattend files. The computers in the U.S. office will automatically join the multicast transmission, while the computers in the other offices will deploy using unicasting. When the installation is completed, Shu runs a task with USMT to migrate the user data to each computer. When the lease on a server expires and the server is replaced, Shu can use Windows Deployment Services to deploy his Windows Server 2008 image in the same way that he performed the RIS deployment. Scenario Four: A Custom Deployment Using Transport Server John Woods is the server maintenance engineer at the A. Datum Corporation data center. He is responsible for maintaining the 300 servers used by A. Datum Corporation's major customers. One of these customers is Adventure Works. Adventure Works uses 40 servers to run a career Web site (which is backed by a database) for circus performers. After the release of a popular film about circus life, Adventure Works expects an increase in the use of their Web site. They order 10 additional servers to handle the anticipated traffic. John wants to deploy operating systems to these servers by using Windows Deployment Services. However, he does not have AD DS running in this environment, so he cannot use the standard Windows Deployment Services solution. Instead, he stores the configuration information for his computers in a SQL Server database. In addition, he wants to partition the disks in a standard configuration and also copy data (some for database servers, some for Web servers) before the unattended setup begins. John chooses to use Windows Deployment Services because he can: Write a plug-in that reads configuration data for the computers from a data store other than AD DS (the data store is typically a database or a flat file). Write scripts (to run in Windows PE) that perform preinstallation tasks and then call Setup to install the operating system. John creates 10 computer accounts in his database for his 10 new servers, and he populates them with the required information. He installs the Windows Deployment Services server role on his server (choosing to install only the Transport Server role service). He then writes a PXE provider (a plug-in that reads information from the database and passes it to Windows Deployment Services) and registers it with the server. He creates a custom boot image that 18 contains Windows PE along with startup scripts to partition the disks and copy the data. Then he uses ImageX to capture one of his existing servers as an install image. After performing these initial tasks, John connects his servers to the network and boots them. They boot into Windows PE by using the configuration stored in the database. His scripts run to prepare each computer for deployment, and the scripts end by running ImageX to apply the operating system image on each computer. Configuring Your Deployment Configuring AD DS Integration Creating a Localized Setup Experience Configuring DHCP Managing Network Boot Programs Managing the Boot Menu Prestaging Client Computers Configuring AD DS Integration Windows Deployment Services uses Active Directory Domain Services (AD DS) for a variety of reasons. AD DS is its data store, and it contains all of the necessary helper routines. You can prestage a device in AD DS, which means to link a physical computer to a computer account object. By doing this, you can configure properties on the computer account object to control the installation. For example, you can configure the network boot program and the unattend file that the client should receive, as well as the server from which the client should download the boot files.You can also link physical booting computers to computer account objects in AD DS. For more information, see Prestaging Client Computers. In This Topic Supported Environments Configuring Static Domain Controllers and Global Catalog Servers Supported Environments Windows Deployment Services supports AD DS environments that contain Windows Server 2000, Windows Server 2003, Windows Server 2008, or environments with any combination of these three operating systems. You will not gain any more functionality or features in Windows Deployment Services features by switching to a higher forest functional level. Windows Deployment Services works well in both single-domain and multidomain environments. 19 Windows Deployment Services also works in multiforest environments, but in such cases the following caveats apply: A trust relationship must be established between the forest that contains the Windows Deployment Services server and other forests in that environment. The server must be configured to answer all client requests. The server cannot answer only known clients in this configuration. This is because the AD DS search algorithm that is used by Windows Deployment Services will only be able to locate prestaged computer objects in the same AD DS forest as the Windows Deployment Services server. This also means that all computer account objects that are created by Windows Deployment Services will be created in the forest that contains the Windows Deployment Services server. Configuring Static Domain Controllers and Global Catalog Servers In some circumstances, you may want to define the domain controller and global catalog server Windows Deployment Services will use. You can do this on the Advanced tab of the server’s properties (right-click the server in the MMC snap-in, and click Properties). For example: You want to control replication latency. You may want to make changes to a particular computer object and have Windows Deployment Services immediately pick up the change (for example, if you modify netbootMachineFilePath to specify a different network boot program). You do not have a domain controller and global catalog in the same AD DS site as Windows Deployment Services. Thisconfiguration is not recommended. However, in this case you may want to control which domain controller and global catalog Windows Deployment Services will use rather than relying on the discovery algorithms. You need to troubleshoot an issue. For example, if Windows Deployment Services is having problems accessing AD DS, you can use this setting to try to isolate the problem to a specific domain controller or global catalog. The one notable downside to mapping these servers statically occurs when a domain controller or global catalog fails. For example, if you statically map Windows Deployment Services to use a domain controller, and that domain controller is taken offline, Windows Deployment Services will lose access to the domain controller’s services and stop servicing incoming client requests. This problem will persist (even if you restart Windows Deployment Services) until the domain controller is back online. This problem does not occur if you use the default dynamic discovery method. Creating a Localized Setup Experience You can create a localized setup experience during any phase of an installation. 20 In This Topic Localizing the Boot Menu Localizing Setup Installing Language Packs Localizing the Boot Menu Microsoft has completely reengineered the boot environment for Windows Vista to address the increasing complexity and diversity of modern hardware and firmware. One aspect of this reengineering is a new firmware-independent data store that contains boot configuration data (BCD), which influences the boot process. For more information about BCD, see http://go.microsoft.com/fwlink/?LinkId=110353. You can configure the BCD store to display localized text in the boot menu by using a combination of BCD store settings and true-type fonts. However, note the following two limitations: The language that is configured in the BCD store will apply to all clients of a particular architectural type. There is no way to configure language settings at a more detailed level or to enable users to select the correct language. Image names are displayed exactly as they appear in the metadata of the Windows image (.wim) file. Therefore, if you want the image names to be localized, you must change the names manually. To customize the BCD store, see How to Modify the BCD Store Using Bcdedit. Localizing Setup You can configure Windows Deployment Services to support a localized installation experience to the same extent that you can configure Windows Vista Setup. For example, you can change the display language, the input settings, and the keyboard layout. To enable this functionality, you must edit the boot image to include the necessary localized setup files. The keyboard layouts and input device drivers are included in Microsoft Windows Preinstallation Environment (Windows PE) by default (with the exception of Input Method Editor devices). The language of the user interface of the Windows Deployment Services client is controlled by the language settings that are specified on the language-neutral page of Setup (an optional page that is not shown by default). The data that is displayed on this page is provided by the multilingual user interface (MUI) application programming interface (API). The data is populated based in the UI languages section of the Lang.ini file (in the boot image's \Sources folder). Selecting a language on this page loads the proper resources so that all text will be displayed in the selected language. The keyboard layout selection menu is also derived from the chosen language. You can configure both the language and keyboard layout options in the Windows Deployment Services client unattend file. For more information, see Automating Setup. Some information shown on the 21 image selection page, such as image name and description, will not be shown in localized strings. This is because the data displayed on this page is taken directly from the .wim metadata, which can hold only a single string in a single language. To enable the language-neutral page and language selection 1. In the Windows Deployment Services MMC snap-in, right-click the desired boot image and then click Disable. 2. Export the image. 3. Using ImageX, mount (read/write) the image marked as RAMDISK bootable (usually the second image in the Boot.wim file). 4. Copy the setup MUI resource files and their associated folder to the \Sources directory of the mounted boot image. For example, to add the German setup resource files to your English boot image, copy the \Sources\de-de directory and all of its contents to your mounted boot image at C:\Mount\Sources. At the end of this process, you should have two sets of setup resource files: English at \Sources\en-us, and German at \Sources\dede. 5. If you are enabling a language that requires Asian fonts, perform the following additional steps. In all other scenarios, go to Step 6: a. Install the Windows Automated Installation Kit (AIK) on either a reference computer or the Windows Deployment Services server. b. Use the Copype.cmd script to create a Windows PE distribution share. c. At the root of the C:\ drive, create a folder named Temp. d. In C:\Temp, create two subfolders: WindowsPE1 and WindowsPE2. e. Mount (read/write) the boot image to C:\Temp\WindowsPE1. f. Copy the Boot.wim image from the Windows Vista DVD to C:\Temp. g. Mount (read only) the second image in Boot.wim into C:\Temp\WindowsPE2. h. Copy the entire \Sources folder from the mounted image at C:\Temp\WindowsPE2 into C:\Temp\WindowsPE1. i. Unmount the image mounted to C:\Temp\WindowsPE1, and then commit the changes. j. Add the modified image to your Windows Deployment Services server. 6. To enable the language-neutral page, adjust the Lang.ini file in the mounted boot image to specify that additional setup resource files are available. The following is a sample Lang.ini file after editing: Contents of C:\mount\Sources\lang.ini [Available UI Languages] en-US = 3 de-DE = 3 22 [Fallback Languages] en-US = en-us 7. Using ImageX, unmount the image and then commit the changes. 8. Import the image. To do this, right-click the disabled boot image by using the MMC snapin, and then click Replace Image. Installing Language Packs In contrast to Windows Vista Setup, Windows Deployment Services has independent localization controls for the client installation experience and the install image. This functionality allows you to view the client installation screens in one language and keyboard combination. It also allows you to install an image that will have a completely different language and keyboard combination. Windows Vista is language neutral, meaning that core system binaries and UI elements that contain strings (content that would need to be localized) are stored separately. The localized elements are known as multilingual user interface (MUI) files. All of the language-specific binaries for a given language are bundled together in a single package known as a language pack. For more information, see Installing Language Interface Packs (http://go.microsoft.com/fwlink/?LinkId=111017) Note also that Windows Vista enables you to add or remove language packs to change languages in a current image (although licensing restrictions may apply, depending on the version of the operating system that you are using). You can do this either online or offline. With this functionality, you can maintain a single image with associated language packs — something that was not possible with previous Windows operating systems, in which you needed to maintain a separate image for each language. Methods There are three language pack deployment models that work well in enterprise environments. Method 1: Install the necessary language packs into the offline image. In this method, you use Package Manager to inject language packs into your base image. For more information, see Install a Language Pack to an Offline Image at http://go.microsoft.com/fwlink/?LinkId=120685. Pros: Install times are faster than with the other two methods because the language pack is already in the image. Cons: The image size increases. Also, many applications are locked into a single language. Therefore, you may not be able to take full advantage of this scenario, because even though you could change the underlying operating system language, the languages in the applications would not change to match the operating system language. Method 2: Store language packs outside the image, and during installation, have Setup install both the image and the language pack. 23 You can implement this method by using Windows Deployment Services. A control on the image selection page enables you to select the language packs that are installed in the image and those that reside outside the image (but are still associated with the image). Expect the following behaviors: If the selected image is from an earlier version of Windows, the language selection control on the image selection page will be disabled. This is because these images do not support installing language packs. If the selected image is Windows Vista but there are no language packs available on the server, the drop-down list will display those languages that are currently installed in the image as defined in the image’s metadata. The selection will default to the default language that is defined in the image’s metadata. If the selected image is Windows Vista and there are language packs available on the server, the drop-down list will display all externally available language packs as well as those that are already installed in the image. The selection will default to the default language that is defined in the image’s metadata. The language pack that is selected will be the default language for the first boot of the install image, and it controls the boot environment language, UI language, and default settings for system locale and keyboard layout (if these are not defined in the unattend settings). Pros: There are fewer images to maintain Cons: Install times are longer because external language packs must be copied and installed. Method 3: Deploy language packs online (to a running operating system) after the installation. Though this method of deployment falls out of the scope of the Windows Deployment Services solution, it is included here to cover all scenarios. To use this method, you could run scripts at first logon or deploy the language packs to the client by using management software such as Group Policy or Systems Management Server (SMS). Pros: This method does not require a change to the setup method that you are currently using. Cons: The user’s first experience with Windows Vista is not necessarily in the expected language. For example, the boot and the initial logon might be shown in the language of the operating system because the language pack has not been applied yet. Also, only certain versions of Windows support language pack installation and removal. Storing Language Packs in the Image Store Each language pack is a .cab file called Lp.cab, and each file is differentiated by the folder in which it resides (for example, \en-US for U.S. English and \de-DE for German). You cannot distinguish one language pack from another just by examining the metadata of the Lp.cab file. Within Windows Deployment Services, you store language packs on a per-image basis within the RemoteInstall directory. You must manually create the folder hierarchy for the language packs as 24 follows: C:\RemoteInstall\Images\<image file name>\Langpacks and then copy the language folder and language pack to this location. For example, the German language pack would be stored at C:\RemoteInstall\Images\Image1\Langpacks\de-DE. Also note that you cannot remove language packs during the installation by using Windows Deployment Services. A language pack is applicable to all versions of Windows Vista (except for Windows PE 2.0, which has its own language packs separate from Windows Vista). However, a language pack is applicable only to a specific version of the operating system — that is, language packs are not backward-compatible. If a language pack was created for Windows Vista, you can apply it only to Windows Vista. If you install a service pack on Windows Vista, you cannot apply the Windows Vista language pack. The applicability rule is enforced at install time by Component-Based Servicing (CBS). Thus, although it is possible to associate an incorrect language pack with a particular version of an image, the installation of the language pack will fail when the installation starts. Configuring DHCP In This Topic Configuring DHCP Options Enabling DHCP Authorization Authorizing a Server Configuring DHCP Options The booting client and the server communicate using Dynamic Host Control Protocol (DHCP) packets. The Windows Deployment Services solution for booting over the network works well in many configurations. It works well when Windows Deployment Services is located on the same physical computer or on a different physical computer from the DHCP server. However, the default installation is that Windows Deployment Services and a DCHP server (Microsoft or nonMicrosoft) are located on different physical computers. In this scenario, no additional configuration steps are required for interoperability between Windows Deployment Services and the DHCP server. However, if you are running Windows Deployment Services and DHCP on the same computer, in addition to configuring the server to not listen on port 67, you will need to use your DHCP tools to add Option 60 to their DHCP scopes. This allows booting clients to learn about the Windows Deployment Services PXE server from the DHCP response that is generated by the DHCP server. Setting DHCP option tag 60 has one side-effect: clients booting from the network are always notified that the PXE server is available, even if the server is not operational or has stopped. For instructions on configuring these options, see the "DHCP section" in How to Manage Your Server. 25 Note There are some scenarios (particularly those that require running a DHCP server) that do not support adding custom DHCP option 60 on the same physical computer as the Windows Deployment Services server. In these circumstances, it is possible to configure the server to bind to UDP Port 67 in nonexclusive mode by passing the SO_REUSEADDR option. For more information, see Using SO_REUSEADDR and SO_EXCLUSIVEADDRUSE (http://go.microsoft.com/fwlink/?LinkId=82387). If DHCP is installed on a server that is located in a different subnet, you will need to do one of the following: configure your IP Helper tables (recommended) or add DHCP options 66 and 67. For more information about these settings, see Managing Network Boot Programs. Enabling DHCP Authorization By default, the PXE server for Windows Deployment Services does not need to be authorized to service client computers. However, you can enable DHCP authorization (which is also known as rogue detection). You may want to enable this authorization for the following reasons: To help prevent an improperly configured PXE server on the network. You can do this by requiring that only those servers that you authorize can service clients. This is not a security protection mechanism, but it can help ensure that a PXE server that is not approved does not service clients. Furthermore, DHCP authorization applies only to computers that are joined to the Active Directory Domain Services (AD DS) structure of the corporate network. For example, if a corporation had a forest, a malicious user could plug a computer into the corporate network, install Windows Server® 2008, run Dcpromo, create a forest, install Windows Deployment Services, and then authorize it. Your IT department has a policy that only authorized servers should be both PXE servers and DHCP listeners. Authorization checks occur only if authorization checking is enabled and the PXE server is configured to listen on port 67. This means that authorization checks take place only in scenarios where Windows Deployment Services is running on a computer without DHCP. If Windows Deployment Services and DHCP are running on the same physical computer, then the DHCP server is listening on port 67, and it is responsible for making sure that it is authorized properly. Note that the PXE server will not perform any additional checks. You can enable this authorization using the following methods: Using the Windows Deployment Services MMC snap-in. To do this, right click the server, click Properties and on the Advanced tab, select Yes, Windows Deployment Server should be authorized in DHCP before servicing clients. Using WDSUTIL by running WDSUTIL /Set-Server /RogueDetection:Yes. Using the DHCP MMC snap-in. To do this, on the DHCP server, click Start, point to Administrative Tools, and then click DHCP. 26 Authorizing a Server You can authorize a Windows Deployment Services server using the Advanced tab of the server’s properties. However, you must be a domain administrator in the root domain of the forest or be an enterprise administrator. Alternatively, you may delegate permissions by using the following procedure. To delegate permissions to authorize the server 1. Open the Active Directory Sites and Services MMC snap-in. 2. On the View menu, click Show Services Node. 3. Click Services. 4. Right-click NetServices, and then click Properties. 5. On the Security tab, assign the following permissions to the users or groups for which you want to authorize these servers: Read, Write, and Create all child objects. 6. Click Advanced. Click the user or group you just added, and then click Edit. 7. In the Apply to box, click This object and all descendant objects. The environment that the Windows Deployment Services server is in influences the authorization behavior: NT4 domain. If the PXE server is part of an NT4 domain, no authorization is performed and the PXE server will service requests. This mode is supported only if the PXE server is running with a custom non-Microsoft PXE provider. Windows Deployment Services requires AD DS; therefore, it cannot operate if joined only to an NT4 domain. Windows Server 2000 or later domain. If the PXE server is part of a Windows Server 2000 or later domain (meaning that AD DS is present), it queries AD DS to determine its authorization state. Workgroup. If the PXE server is part of a workgroup, it can service client requests as long as other DHCP servers on the same subnet are not part of a domain. If a DHCP server that is part of a domain comes online, the PXE server will stop servicing requests. Windows Small Business Server 2003.If the PXE server is part of a Small Business Server 2003 domain, it must be the only DHCP server on the network. If another DHCP server exists or comes online, the PXE server stops servicing requests. Managing Network Boot Programs A network boot program (NBP) is the first file that is downloaded and executed as part of the PreBoot Execution Environment (PXE) boot process. Note that NBPs are specific to both architecture and firmware (BIOS or EFI), and they control the first boot experience (EFI stands for Extensible Firmware Interface). On BIOS computers (per the PXE specification), the NBP is a 16-bit, real- 27 mode application. As such, you can use the same NBP for both x86-based and x64-based operating systems that have BIOS, because both are capable of running this program. In This Topic Configuring the NBP List of NBPs Directing a Client to the Appropriate NBP Updating the IP Helper Tables Using DHCP Options 60, 66, and 67 Implementing PXE Referrals When to Implement PXE Referrals Requirements Referral Examples Enabling Architecture Detection Avoiding a Boot Loop Note For information about avoiding a boot loop, see Automating the PXE Boot. Configuring the NBP There is an NBP specified for each architecture (defined on the Boot tab in the properties of the Windows Deployment Services server). However, you can override the NBP for each server on a per-client basis (by running WDSUTIL /Set-Device /Device:<name> /BootProgram:<path>). For example, you may want to configure an NBP so that known clients receive the per-server default (presumably an NBP that requires pressing the F12 key, and unknown clients receive an NBP that will cause them to perform a PXE boot automatically. This configuration is particularly useful in a lab environment where you want to immediately image new computers, but you want to ensure that existing computers are not sent through the imaging process by accidentally booting from the network. List of NBPs The following table lists the available NBPs in Windows Deployment Services. NBP Description Architecture Firmware PXEboot.com (Default) Requires the user to press the F12 key for a PXE boot to continue. x86-based and x64-based BIOS PXEboot.n12 Does not require pressing F12 and x86-based and BIOS 28 NBP Description Architecture immediately begins a PXE boot. x64-based Boots the computer by using the next boot item in the BIOS without waiting for a timeout. x86-based and x64-based BIOS Hdlscom1.com and Causes computers that do not support x86-based and Hdlscom2.com firmware console redirection to display x64-based "Press space or F12 for network boot," using console redirection to serial port 1 or 2. Users can proceed with the boot process by pressing either key, or they can exit the boot process by not pressing either key. BIOS Hdlscom1.n12 and Hdlscom2.n12 Causes computers that support firmware console redirection will not display the prompt "Press space or F12 for network boot" and the computer will not wait for user input. x86-based and x64-based BIOS Bootmgfw.efi The EFI equivalent for Bootmgr.exe. In EFI, the choice of whether or not to perform a PXE boot is handled within the EFI shell, and not by the NBP. x64-based and Itanium-based EFI Wdsnbp.com An NBP developed for Windows Deployment Services that serves the following general purposes: x86-based and x64-based BIOS AbortPXE.com Firmware 1. Architecture detection 2. Pending computer scenarios. When the Auto-Add policy is enabled, it is sent to pending computers to pause the PXE boot and report back the client computer's architecture to the server. 3. PXE referral cases (including use of Dynamic Host Control Protocol (DHCP) options 66 and 67) Directing a Client to the Appropriate NBP There are two methods for directing a client computer to the correct NBP: Updating the IP Helper Tables (recommended). The client contacts the server directly for this information. 29 Using DHCP Options 60, 66, and 67. A DHCP server relays this information to the client. Updating the IP Helper Tables Updating the IP Helper tables means updating the routing tables for your networking equipment to make sure that DHCP traffic is directed correctly. When configured correctly, all DHCP broadcasts from the client computer will be directed to both a valid DHCP server and a valid network boot server. (Note that the requirement is not to rebroadcast the packet onto other network segments, but rather to perform a forward of the packet to only those recipients that are listed in the IP Helper table.) If the booting client, the DHCP server, and the network boot server are all located on the same network segment, you should not have to configure these tables. The client’s DHCP broadcasts will reach both the DHCP server and the network boot server. However, if either the DHCP server or the network boot server is on a different network segment than the client, or if they are on the same network segment but the network is controlled by a switch or router, we recommend that you update these tables. After the client computer has obtained its IP address, it contacts the network boot server directly (again using DHCP packets) to obtain the name and path of the NBP to be downloaded. The following are the specific changes that you need to make: All DHCP broadcasts by client computers on User Data Protocol (UDP) port 67 should be forwarded directly to both the DHCP server and the Windows Deployment Services PXE server. All traffic on UDP port 4011 from the client computers to the Windows Deployment Services PXE server should be routed appropriately (these requests direct traffic, not broadcasts, to the server). Using DHCP Options 60, 66, and 67 Although Microsoft does not recommend this method, you can use the following DHCP options to direct PXE clients to an appropriate NBP to download: Option 60 = client identifier (set to the string PXEClient) Option 66 = boot server host name Option 67 = boot file name For instructions on configuring these options, see the "DHCP" section in How to Manage Your Server. When using these DHCP options, client computers receive an IP address lease, information about the boot server, and information about the NBP directly from the DHCP server. Clients will not contact the network boot server by using DHCP, but they download the NBP through Trivial File Transfer Protocol (TFTP). Microsoft does not recommend this method for the following reasons: Using DHCP options is not as reliable as updating the IP Helper tables. In testing, Microsoft has observed some issues (mainly with older PXE ROM) related to clients incorrectly parsing the DHCP options returned from the DHCP server. The result is that booting clients see a “TFTP Failed” error message. Generally, this problem occurs when the 30 PXE ROM ignores the boot server host name value and instead attempts to download the NBP directly from the DHCP server (which likely does not have the NBP). If there are multiple network boot servers available to service client requests, specifying a specific network boot server may prevent load-balancing. Clients may be directed to a network boot server that is not available. Because the client does not have to contact a network boot server directly to determine the NBP to download, the DHCP server may direct clients to download a NBP that does not exist or to a server that is not currently available. Clients may bypass the network boot server’s answer settings. Many network boot servers have a mechanism that enables you to control which clients (if any) should be answered. Per the PXE standard, client computers should contact the network boot server directly to obtain the path and file name of the NBP. Using DHCP options 66 and 67 can cause the client to bypass this communication with the network boot server and therefore ignore the settings of the network boot server for answering clients. Note that using DHCP options 66 and 67 is considered a PXE boot referral. Therefore, if you choose this method, ensure that your implementation meets the guidelines defined in Implementing PXE Referrals. Implementing PXE Referrals A PXE referral (also known as a network boot referral) occurs when a client is directed to download an NBP from a different server than the one it was in communication with through DHCP (as part of the process to discover the network boot server name and NBP). This referral may be initiated by either a network boot server or a DHCP server. The following areas are covered in this section: When to Implement PXE Referrals Requirements Referral Scope When to Implement PXE Referrals You might want to consider using PXE referrals in the following scenarios: To direct a client to download a NBP that is located on a different computer or network location. This may be especially helpful when using DHCP options 66 and 67, because the client is typically answered directly by the DHCP server and is redirected to the network location that contains the NBP. To enable load balancing. It may be advantageous to direct a class of clients to a particular Windows Deployment Services server to limit network traffic to a server. To support complex network and AD DS topologies. Sometimes the networking and AD DS topology do not line up. This could be because incoming PXE requests are answered by 31 a computer over a wide area network (WAN), but you would like a local server to provide the boot image. To remove the need for image replication and duplicate image maintenance. Using referrals can enable you to keep only one copy of an image, therefore maintaining a single release point to update and service. Additionally, using referrals will reduce the amount of overhead it takes to keep multiple images in sync. Configuring PXE boot referrals involves two steps. First, you must configure the front-end and back-end servers. A front-end server is the server that will answer the client’s PXE boot request and direct the client to the proper server and NBP. A back-end server is the server that the client will download the NBP from. Second, prestage clients and direct them to a back-end server and, optionally, the NBP to download. This second step is required only if you are not using DHCP options 66 and 67 to redirect clients. To configure these settings, see How to Manage Your Server. Requirements PXE boot referrals that don't involve using DHCP options 66 and 67 require that the referred client to be prestaged. Additionally, the netbootMachineFilePath attribute of that computer account must be populated with (at a minimum) the server name that the client should use. In environments that contain both Remote Installation Services (RIS) and Windows Deployment Services servers, only the Windows Deployment Services servers should act as referral servers. This enables the Windows Deployment Services server to control the referral process, correctly referring clients to new Windows Deployment Services servers and maintaining backward compatibility for RIS servers. Note Having a RIS server act as a referral server for a back-end Windows Deployment Services server will work only if prestaged computers have both the referral server name and the NBP name defined in the netbootMachineFilePath attribute. Failing to populate the NBP name will cause the RIS server to populate the value automatically with Startrom.com (which will not exist on the backend Windows Deployment Services server if the server is in Native mode on Windows Server 2003, or if you are running Windows Server 2008). Referral Examples Referrals are classified based on the number of jumps the client must make before it downloads and executes an NBP. The following table contains three examples of referrals. Each of these examples supports the referral of x86-based or x64 BIOS-based clients, but does not support the referral of Itanium-based and x64 EFI-based clients Example Details First order referral ComputerA sends a DHCP broadcast packet and receives an IP address 32 Example Details from PXE server lease from a DHCP server and a response from PXE Server1. ComputerA contacts PXE Server1 directly on port 4011. PXE Server1 refers the client to download \boot\wdsnbp.com from Server2. The client computer downloads Wdsnbp.com from Server2. Requirements: First order referral using DHCP options The NBP that the client computer is directed to download from the TFTP server (Server2 in this example) must be Wdsnbp.com. The network boot server performing the referral (PXE Server1 in this example) must be running Windows Deployment Services. ComputerA sends a DHCP broadcast packet and receives an IP address lease from a DHCP server. The lease also contains values for DHCP options 66 and 67, referring the client to download the file \boot\ x86\wdsnbp.com from Server1. The client computer downloads Wdsnbp.com from Server1. Requirement: Second order referral using both DHCP options and PXE server The NBP that the client computer is directed to download from the TFTP server (Server1 in this example) must be Wdsnbp.com. ComputerA sends a DHCP broadcast packet and receives an IP address lease from a DHCP server. The lease also contains values for DHCP options 66 and 67, referring the client to download the file \boot\ x86\wdsnbp.com from PXE Server1. The client computer downloads Wdsnbp.com from PXE Server1. Wdsnbp.com contacts PXE Server1 on port 4011. PXE Server1 refers the client to download the \boot\x86\wdsnbp.com from Server2. The client computer downloads Wdsnbp.com from Server2. Requirements: The NBP that the client computer is directed to download from the PXE server (PXE Server1 in this example) must be Wdsnbp.com. The NBP that the client computer is directed to download from the TFTP server (Server2 in this example) must be Wdsnbp.com. The network boot server performing the referral (PXE Server1 in this example) must be running Windows Deployment Services. Enabling Architecture Detection To work around client architecture reporting problems, you can enable an architecture detection feature on your Windows Deployment Services server. When enabled, the client is sent a NBP (wdsnbp.com) before downloading the normal NBP for the client’s architecture. Wdsnbp.com 33 performs an architecture detection test on the client processor and then reports the value back to the server, using a DHCP packet. After the server receives the information, it sends the correct NBP to the client. When enabled, architecture detection is performed on every x86-based computer in the environment. This feature is turned off by default because the detection process adds time to boot, increases network traffic, and increases the server's load. You can enable architecture detection by running the command WDSUTIL /Set-Server /ArchitectureDiscovery:Yes. Avoiding a Boot Loop When implementing an automated experience of booting from the network, it is often necessary both to set the network as the first device in the client’s BIOS boot order and to send a specific client the .n12 NBP. If you combine these two configurations, the client will automatically boot from the network without requiring user intervention, and the computer will end up in a circular loop (always booting from the network and never from the hard disk drive). To work around this scenario, you should perform the following steps: 1. Prestage the device (see Prestaging Client Computers). 2. Set the BIOS boot order on the computer such that the computer always boots from the network. 3. Set the appropriate .n12 NBP for the computer's architecture (using the Boot tab of the server’s properties). 4. Turn on the computer, and let it boot from the network. When you configure the installation in this way, the path to the NBP will be reset after the image is applied, as one of the final actions performed by Windows Deployment Services. This ensures that on the next boot, the computer will receive the default server NBP (commonly the .com version). Therefore, the computer will try to boot from the network (because the network is first in the BIOS boot order), but the computer will be sent the .com NBP. After waiting for the user to press the F12 key, this option will time out and the device will boot from the hard disk drive. Managing the Boot Menu A boot menu is displayed on a client computer when the client performs a Pre-Boot Execution Environment (PXE) boots and more than one boot image is available to that client. If only one boot image is available, the computer will automatically boot into that image. The boot images are ordered alphabetically, based on the file name of the .wim file that contains the image. In This Topic Configuring the Boot Menu Specifying Boot Images for Prestaged Clients 34 Considerations for x64-Based Clients Configuring the Boot Menu Microsoft has completely reengineered the boot environment for Windows Vista and Windows Server® 2008 to address the increasing complexity and diversity of modern hardware and firmware. One aspect of this reengineering is a new firmware-independent data store that contains boot configuration data (BCD). The BCD store defines how the boot menu is configured. The store is a namespace container for BCD objects and elements that holds the information that is required to load Windows or run other boot applications. Physically, a BCD store is a binary file in the registry hive format. For more information about BCDs, see http://go.microsoft.com/fwlink/?LinkID=110353. To customize the BCD store, see How to Modify the BCD Store Using Bcdedit. Note that when you modify the BCD store, you must force it to be recreated in order for your changes to take effect. To do this, either restart the WDSServer service (run wdsutil /stop-server and then run wdsutil /start-server) or run Sc control wdsserver 129. Because the menu exists outside of an operating system, there are certain limitations placed on the user interface (UI), including the following: The screen size is 80x25 pixels, which means that approximately 13 images can be displayed on the page simultaneously. If more than 13 images are available, the display will scroll to support the additional images. The number of images that can be shown is dependent on several factors, including the number of images that need to be displayed to the client and the number of characters in the image name. There is no mouse or Input Method Editor (IME) functionality. There is no support for alternate keyboards, other than what the BIOS supports. There is limited support for localization, other than what the BIOS supports. There is limited support for accessibility. Specifying Boot Images for Prestaged Clients You can assign a boot image to a prestaged computer in Active Directory Domain Services (AD DS). For instructions, see the "Prestage Computers" section in How to Manage Client Computers. In these instances, Windows Deployment Services must dynamically create a BCD store for the booting client that has the assigned boot image selected as the default. Rather than generating a unique BCD store that contains only that operating system entry for each booting client (which, due to the BCD architecture may take several seconds), the existing BCD store for the client’s architecture (in RemoteInstall\Tmp) is copied and the default selection is modified to reflect the new default. In addition, other booting clients that have been assigned the same boot image can reuse this dynamically generated BCD store. 35 Considerations for x64-Based Clients Because x64-based computers are capable of booting both x86-based and x64-based images, the default behavior is that x64-based users see a list of both x86-based and x64-based boot images when both are available on the server. This means that x64-based clients receive the x86x64.{GUID}.bcd store. For instructions on configuring the boot image policy that x64-based clients should see, see the "Boot Program and Boot Image" section in How to Manage Client Computers. To work-around issues where the booting client may not be sending the correct architecture value in the initial PXE discovery packet, the Wdsnbp.com boot program will detect the architecture of the booting client and report that value back to the Windows Deployment Services server. For more information, see the "List of NBPs" section in Managing Network Boot Programs. Prestaging Client Computers In This Topic Creating Computer Account Objects in AD DS Benefits Enabling the Auto-Add Policy Purging the Auto-Add Database Creating Computer Account Objects in AD DS You can use Windows Deployment Services to link physical computers to computer account objects in Active Directory Domain Servers (AD DS). This is called prestaging the client. Prestaged clients are also called known computers. This allows you to then configure properties on the computer account to control the installation for the client. For example, you can configure the network boot program and the unattend file that the client should receive, as well as the server from which the client should download the network boot program. You can create a computer account object and associate it with a physical computer using the following methods: Using WDSUTIL. You can prestage client computers before they have attempted a network boot, by running WDSUTIL /Add-Device /Device:<name> /ID:<ID>. You cannot prestage computers by using the Windows Deployment Services MMC snap-in, but you can set the Auto-Add policy and approve or reject pending computers. Using the Active Directory Users and Computers snap-in. You can prestage client computers before they have attempted a network boot using AD DS. For instructions, see the section "To prestage a client computer" in How to Manage Client Computers. 36 Enabling the Auto-Add policy. If you enable this policy, when you approve the installation for an unknown client, the installation will proceed and a computer account will be created in AD DS for the client. For more information, see Enabling the Auto-Add Policy Using Windows Deployment Services as part of the image installation. By default, all operating system installations using Windows Deployment Services result in a client computer that is joined to a domain. You can disable this functionality using the Client tab of the server’s properties page. Benefits Prestaging clients provides three main benefits: An additional layer of security. You can configure Windows Deployment Services to answer only prestaged clients, therefore ensuring that clients that are not prestaged will not be able to boot from the network. Additional flexibility. Prestaging clients increases flexibility by enabling you to control the following: The computer account name and location within AD DS. Which Pre-Boot Execution Environment (PXE) server should service the client. Which network boot program (NBP) the client should receive. Other advanced options — for example, what boot image a client will receive or what Windows Deployment Services client unattend file the client should use. The ability for multiple PXE servers to service the same network segment. You can do this by restricting the server to answer only a particular set of clients. Note that the prestaged client must be in the same forest as the Windows Deployment Services server (trusted forests do not work). Enabling the Auto-Add Policy When the Auto-Add policy is enabled, administrative approval is required before unknown clients (clients that are not prestaged) can install an image. To enable this policy, run WDSUTIL /SetServer /AutoAddPolicy /Policy:AdminApproval. You can also enable it using the PXE Response settings tab of the server’s properties page. If you enable this policy, when an unknown computer attempts to boot against the server, the computer will appear in the Pending Devices node of the MMC snap-in. The computer will remain in this pending queue until you approve or reject it, the time-out is reached, or the user cancels the attempt. If you approve the computer, the computer will continue booting from the network, and a computer account object will be created in AD DS to represent the physical computer. If you reject the computer, the network boot will abort, the computer will boot from the next item in the boot order, and a computer account will not be created. If you do not enable this policy, Windows Deployment Services will not create a computer account for unknown clients. It will, however, still answer clients according to the settings on the server. 37 The Auto-Add policy applies only when the Windows Deployment Services server is set to answer all clients, and Windows Deployment Services does not find a prestaged computer account for a booting computer. In all other cases, this policy will not be in effect. Also note that this policy does not pertain to computers that use Extensible Firmware Interface (EFI). Note If you are creating computer accounts against a non-English domain controller and you are using the default user property, you must set the Auto-Add settings to use a different account that does not contain extended characters. If the account contains a nonstandard character (any character outside [A-Z, a-z, 0-9, \, -, and so on]), such as German's "Domänen-Admins", then Auto-Add will fail. To change this value, see the help at the command prompt for WDSUTIL /set-server /AutoAddSettings. Purging the Auto-Add Database All computers in the pending queue are represented as an entry in the Auto-Add database. This temporary storage location serves three purposes: To provide the management utilities with a list of all pending computers on a server. To serve as an audit trail by recording what computers have been approved or rejected. To reduce the size of AD DS and keep old computer account objects out of the AD DS. Records in the database are purged either manually or on a schedule. The default schedule purges unapproved and rejected computers from the database every 24 hours. If a computer was accidentally rejected, you can remove the computer by using one of the following methods: Wait for the default cleanup to occur, and then boot the computer again. Purge records from the pending table by running the command WDSUTIL /DeleteAutoAddDevices /DeviceType:<ApprovedDevices|RejectedDevices>. By default, computers with an approved status will be deleted every 30 days. In addition, to delete a prestaged computer that was added to AD DS by using the approval process, you must perform two steps. First, you must delete the computer from AD DS. Second, you must delete the computer's record in the Auto-Add database. Failing to purge the database will cause the client to be stuck in Wdsnbp.com and not proceed with booting from the network. This occurs because the record in the Auto-Add database shows the computer as approved, but a prestaged computer in AD DS will never be found (because the computer was deleted). In this situation, the server will hold the client at Wdsnbp.com until a prestaged computer appears in AD DS. To reset the Auto-Add database completely 1. Stop the WDSServer service (run WDSUTIL /stop-server). 2. Create a Temporary folder in the \RemoteInstall\Mgmt folder. 3. Move all existing files in the Mgmt folder to the Temporary folder. 4. Restart the WDSServer service (run WDSUTIL /start-server). 38 Optimizing Your Deployment Extending Your Solution Managing a Complex Environment Optimizing Performance and Scalability Using Transport Server Extending Your Solution Windows Deployment Services enables you to create a variety of custom deployment solutions. You can build an end-to-end deployment solution for Windows Vista and Windows Server® 2008. Additionally, Microsoft Windows Preinstallation Environment (Windows PE) provides an environment where you can use custom logic and processing. This chapter discusses ways to extend your solution and provides useful examples. In This Topic Benefits Creating a Custom Solution Custom Solution Example Benefits Using the Windows Deployment Services platform as part of a custom deployment solution provides the following benefits: Increased interoperability. Common barriers for new deployment solutions include the need for new hardware and the need for changes to network infrastructure to support advanced networking configurations (for example, having two Pre-Boot Execution Environment (PXE) servers on the same network segment). Windows Deployment Services has built-in extensibility points that help you avoid these potential conflicts. You do not need to have a separate physical server for each deployment solution because of the unified PXE server architecture. Also, you do not need to store images in multiple locations or in multiple formats because the management approach (which uses the Windows imaging format) provides a central repository for images. A scalable PXE server infrastructure. The PXE server that is included in Windows Deployment Services enables you to implement custom logic that dictates which clients are answered. The PXE server handles advanced networking configurations by giving you control over which interfaces the server binds to. This control extends to the IP address and MAC address layers. The PXE server can handle the throughput generated by more than 5,000 client PXE requests per second. 39 Image storage and management. Windows Deployment Services stores images in a central location, and the management tools enable you to perform all common tasks, such as adding and removing images and configuring server settings. Enumeration of images. Many network installation scenarios face a common problem: getting a list of available install images from a central distribution point and returning that list to the client. Windows Deployment Services does just this. It shows an authenticated client computer a list of available images that are stored on a server or in a remote storage location, which is referenced by using Distributed File System (DFS). Network boot support. Offering support for booting from the network becomes more complex when different variations of Windows PE need to be supported (for example, different languages, different hosted applications, and different architecture versions). Windows Deployment Services accomplishes this by using the image storage structure and management tools provided in Windows PE. Creating a Custom Solution You can use the Windows Deployment Services PXE server and the Windows Deployment Services client (which is essentially Setup.exe and supporting files for Windows Deployment Services) to create a custom solution. The Windows Deployment Services extensibility points are documented in the Windows Vista software development kit (SDK) at http://go.microsoft.com/fwlink/?LinkId=81029. Windows Deployment Services PXE Server The PXE server implementation in Windows Deployment Services consists of a PXE server and a PXE provider. The PXE server contains the core networking capability: it binds to network interfaces, listens for incoming PXE requests, and formats the Dynamic Host Control Protocol (DHCP) response packets. The PXE server supports a plug-in interface. Plug-ins are also known as PXE providers, and they provide the business logic. The server and provider enable you to develop custom PXE solutions while taking advantage of the core PXE server networking code base. The PXE server logic in Windows Deployment Services has two main features: A default provider that you can change. The provider installed by default with Windows Deployment Services is BINLSVC, which is implemented in the DLL, Binlsvc.dll. You can remove this PXE provider from the server and replace it with a custom-written provider. Support for multiple providers on a single server. Rather than having two PXE listeners on the network (each with its own application logic), you can have multiple providers. This means that you can have only one PXE listener on a network that has two or more sets of application logic. With this PXE server implementation, you can perform either of the following tasks: Create a PXE plug-in for a stand-alone PXE server (for example, a server that is not joined to or communicating with an Active Directory Domain Services (AD DS) domain). The plug-in might use a .txt file, an .xml file, or a SQL database as its data store. 40 Enable a second, registered provider to offer functionality without disrupting or reconfiguring Windows Deployment Services. One of the most powerful implementations available is writing a filter provider, which is an additional PXE provider that resides above BINLSVC (or any other PXE provider) in the ordered provider list. This filter provider acts as a gate before the next provider in the list, enabling the next provider to service selected clients by passing some requests and filtering others. Windows Deployment Services Client The Windows Deployment Services client is a graphical user interface (UI) that is built on Setup.exe in Windows Vista (it contains additional logic that is specific to Windows Deployment Services). The Windows Deployment Services client has the ability to establish a communication channel with a Windows Deployment Services server. This channel provides a mechanism for authentication and for retrieving a list of install images stored on the server. In addition, the Windows Deployment Services client sends progress and status messages to the server while the image is being installed. The library within the Windows Deployment Services client includes the following functionality: The ability to authenticate and enumerate images that are stored on a Windows Deployment Services server The ability to send client installation events that can be used for reporting and monitoring purposes (for example, sending notifications that the client installation has started or has finished) The following is a common scenario that uses this functionality. 1. A computer boots into a boot image that contains the Windows Vista Setup files. The client can boot in any of several ways (from a CD, DVD, or hard disk drive, or over the network). 2. A custom application (with a custom UI) is started. 3. The application detects the computer's MAC address and contacts a database to acquire the correct unattend file. 4. The application uses the Windows Deployment Services client library to retrieve a list of available images stored on a Windows Deployment Services server and displays the list of choices to the client (by using the custom UI). 5. The application deploys the image that the user selects, and it also copies the unattend file that was acquired previously. 6. The application sends progress and status messages to the server by using the functionality provided by the Windows Deployment Services client library. Custom Solution Example Remote Installation Services (RIS) offered three options for naming a computer: Automatic: The computer name is automatically generated, and the client computer account is created in a particular organizational unit (OU), based on the policy that is implemented. 41 Custom: The person performing the installation specifies the computer name and OU. These values override the dictated server policy. Administrator. The person performing the installation specifies the computer name and OU after the installation is completed. Installations using the Windows Deployment Services client offer the Automatic and Administrator options. There are methods for achieving the Custom option, but they generally involve prestaging the device, either manually or by using Auto-Add functionality. Microsoft recommends using Business Desktop Deployment (BDD) to implement the Custom scenario. However, you can also provide this functionality with a few changes to your boot image, as illustrated in the sample scripts later in this topic.. The Microsoft Visual Basic® script at the end of this document does the following: 1. Starts running from within Windows PE and gathers a computer name and OU (in distinguished name form) from the user. 2. Runs the command setup.exe /wds /noreboot. At this point, the Windows Deployment Services installation proceeds, and Setup does not restart as normal after finishing the Windows PE phase. 3. Edits the unattend file to add the computer name and OU that were entered by the user. Note that the image that is selected needs an image unattend file that specifies the computer name and OU. When the script is finished, the client will reboot if the script is the last (or only) executable file listed in the WinPEshl.ini file. Instructions for Using the Sample Code To use these scripts, perform the following procedure to use these sample files. 1. Export a copy of a boot image from your server. 2. Mount the boot image as read/write. (Remember, the second image in the Boot.wim file is marked as RAMDISK bootable, and it contains the Setup files). a. Create a custom Winpeshl.ini file, and then copy it to the \Windows\System32 folder of the mounted image. b. Create a custom script (for example, domainOU.vbs) by using the sample code in the section following this procedure. Copy this script to the mounted image's \Sources folder. 3. Unmount the image, and then commit the changes. 4. Add the image back to your Windows Deployment Services server. 5. Create an image unattend file similar to the sample file (Sample Image Unattend File). 6. Associate the unattend file with an install image. 7. Boot a client into the updated boot image. 8. Select the install image associated the unattend file. The script starts running when Windows PE boots. It shows a basic UI which enables the user to enter the computer name and the computer OU. The script performs the install and then replaces all occurrences of %COMPUTERNAME% with the value specified in the message box, as well as 42 replacing all occurrences of %OU% with the value specified in the message box. Remember that the OU must be entered in a distinguished name form — for example, OU=MyOU,DC=Domain,DC=com. Sample Visual Basic Script Option Explicit Dim computerName, OU, unattendFile, WshShell, result, fso, unattendFileObject, strContents '---------------------------------------------------------------------unattendFile = "C:\Windows\Panther\unattend.xml" ' end user defined settings '---------------------------------------------------------------------Set WshShell = WScript.CreateObject("WScript.Shell") dim answer do while answer <> vbYes computerName = InputBox("Enter the desired computer name", "Computer Name") OU = InputBox("Enter the distinguished name of the desired OU", "Organization Unit") answer = MsgBox("Is this correct?" & vbCrLf & vbCrLF & "Name: " & computerName & vbCrLF & "OU: " & OU, vbYesNo, "Computer Account Details") loop WshShell.Run "%SYSTEMDRIVE%\sources\setup.exe /wds /noreboot", 0, true Set fso = CreateObject("Scripting.FileSystemObject") if fso.FileExists(unattendFile) = false then wscript.echo "Couldn't find unattend file" else 'Read the unattend file in and replace apprpriate variables Set unattendFileObject = fso.OpenTextFile(unattendFile, 1) strContents = unattendFileObject.ReadAll strContents = Replace(strContents, "%OU%", OU) 43 strContents = Replace(strContents, "%COMPUTERNAME%", computerName) unattendFileObject.Close 'Write the updated contents back to the unattend file Set unattendFileObject = fso.OpenTextFile(unattendFile, 2) unattendFileObject.Write(strContents) unattendFileObject.Close End If Sample Image Unattend File The following is a sample image unattend file. <?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="specialize"> <component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Identification> <UnsecureJoin>false</UnsecureJoin> <MachineObjectOU>%OU%</MachineObjectOU> <Credentials> <Domain>MyDomain</Domain> <Username>MyUserName</Username> <Password>MyPassword</Password> </Credentials> <JoinDomain>%MACHINEDOMAIN%</JoinDomain> </Identification> </component> <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ComputerName>%COMPUTERNAME%</ComputerName> 44 </component> </settings> </unattend> Sample WinPESHL.ini File [LaunchApps] "%SYSTEMROOT%\system32\cscript.exe","%SYSTEMDRIVE%\sources\domainOU.vbs" Managing a Complex Environment This topic addresses difficulties that may be arise in complex environments — for example, where Windows Deployment Services is used in an environment with many servers, Remote Installation Services (RIS) servers, network hops, and so on. In This Topic Managing a Server Remotely Avoiding IP Address Conflicts Testing by Using Virtual Computers Versions of the Management Tools to Use with RIS and Windows Deployment Services Note When performing Pre-Boot Execution Environment (PXE) referrals in an environment that includes Windows Deployment Services and RIS, the Windows Deployment Services server must answer PXE requests and perform referrals. If a RIS server attempts to refer a client computer to a Windows Deployment Services server that is running in Mixed mode or Native mode, the client computer will receive an incorrect network boot program, which may cause the client to fail to boot. Managing a Server Remotely In addition to running Windows Deployment Services locally, you can also manage Windows Deployment Services remotely using the following methods. Method Explanation Managing from another Windows Deployment Services server To do this, you must specify which server you want to manage. You can do this in either of the following ways: Using the Windows Deployment Services MMC snap-in. First you must add the server to the console. To do this, right-click the Servers 45 Method Explanation node and then click Add Server. Next, type the name of the server you want to add, or select it in the list. The server will be added to the left pane in the console, and you can perform any task by selecting it just as you would select the local server. Using WDSUTIL. To specify a remote server to run a WDSUTIL command, append /Server:<name> to the command. For example: WDSUTIL /Add-Image /ImageFile:C:\images\capture.wim /Server:MY-WDS-02 /ImageType:Boot Managing from a remote server that is running Windows Server 2008 (but not Windows Deployment Services) To do this, you can install Remote Server Administration Tools, which will install WDSUTIL and the Windows Deployment Services MMC snap-in on the server. To install Remote Server Administration Tools, open Server Manager, right-click the Features node, click Add Features, and then click Remote Server Administration Tools. Next clickRole Administration Tools, and then click Windows Deployment Services Tools. Using PsExec You can also manage the server by using PsExec. For example: psexec \\<servername> \wdsutil /get-device /id:<GUID> For information about using PsExec, see http://go.microsoft.com/fwlink/?LinkId=110605. Avoiding IP Address Conflicts When two servers select the same multicast IP address to send content to, content intended for clients of either server can be routed to all clients. This causes unnecessary network traffic. Note also that this is particularly harmful if the servers are connected by a low-bandwidth connection (such as a wide area network (WAN) link), because both sets of content will be sent over this connection. The following are preventive measures that you should take to avoid this situation: Use a Multicast Address Dynamic Client Allocation Protocol (MADCAP) server to allocate multicast IP addresses. This will prevent addresses from being assigned twice. Configure a static range for each server, making sure that this range does not overlap with the ranges defined for other servers. Lower the multicast Time-To-Live (TTL) setting to prevent the routers from forwarding multicast traffic outside the site network. You can also configure your border router not to forward multicast traffic. To modify these options, right-click the server in the MMC snap-in, click Properties, and then click the Network Settings tab. 46 Testing by Using Virtual Computers Windows Deployment Services should work on virtual computers, but note that the performance will often be degraded, particularly during the Trivial File Transfer Protocol (TFTP) download phase. This phase is very resource-intensive and may fail if insufficient resources are available on the host computer. Also, performing a PXE boot on a virtual computer or virtual server can take 20 minutes or longer when you are using Windows Deployment Services. To resolve this, we recommend that you use a discover image instead of PXE in the BIOS of the virtual computer. In addition, we recommend that you use virtual computers for either client computers or servers, but not both. Versions of the Management Tools to Use with RIS and Windows Deployment Services There are three server configurations that you may need to manage in a production environment, and each of them has a different set of management tools. The following table lists these server configurations and the versions of the management tools that are included for each of them. Note that I indicates version 1, and II indicates version 2. Tool and operating system Management tools Remote Installation Services servers running Windows Server 2003 RISETUP (I) RIPREP (I) Windows Deployment Services servers running Windows Server 2003 RISETUP (II) RIPREP (II) WDSUTIL (I) MMC snap-in (I) WDSUTIL (II) MMC snap-in (II) Windows Deployment Services servers running Windows Server 2008 The Windows Deployment Services management tools enable you to manage a remote server. Note, however, that there are some restrictions regarding which versions of the tools will work on which server versions. The following table lists the seven possible configurations and the versions of the tools that you should use with each environment. Essentially, you should use the latest available version of each tool. For example, see the sixth row in the table: if you have servers running the 2003 and 2008 versions of Windows Deployment Services, you should use RISETUP (II), RIPREP (II), WDSUTIL (II), and WDSMMC (II) 47 Note You cannot manage a Windows Deployment Services server running Windows Server 2008 from a Windows Deployment Services server running Windows Server 2003. Servers Servers running Servers running running Windows Windows RIS on Deployment Deployment Windows Services on Services on Server 2003 Windows Server 2003 Windows Server 2008 X X X X X X X X X X Tools that you should use X X RISETUP (I) RIPREP (I) RISETUP (II) and RIPREP (II) to manage any RIS functionality (Legacy/Mixed mode) WDSUTIL (I) and WDSMMC (I) to manage any WDS functionality WDSUTIL (II) WDSMMC (II). RISETUP (II) RIPREP (II) WDSUTIL (I) WDSMMC (I) RISETUP (I) RIPREP (I) WDSUTIL (II) WDSMMC (II) RISETUP (II) RIPREP (II) WDSUTIL (II) WDSMMC (II) RISETUP (II) RIPREP (II) WDSUTIL (II) WDSMMC (II) 48 Optimizing Performance and Scalability This chapter includes guidelines, techniques, and best practices to maximize performance, scalability, and reliability. Among other useful information, you will find techniques to identify blockages in your deployment, such as issues with network and server performance. In This Topic Best Practices for Avoiding Performance and Scalability Problems Configuring the Server for Performance and Scalability Performance and Scalability Expectations Unicasting Multicasting For information about analyzing blockages during an installation, see Troubleshooting Performance Problems. Best Practices for Avoiding Performance and Scalability Problems The following are best practices that you can use: Ensure that the network interface between the server and client has sufficient bandwidth. Consider gigabit network adapters on the physical server with Category 5e (Cat 5e) cabling to a switch that can handle a GB back-plane connection, with 100-MB ports on the front-plane (100 MB-clients, 1-GB back end to the server). Use high-quality Ethernet cabling. We recommend at least Cat 5 or Cat 5e is recommended throughout the physical network. Use network switches. Do not use a hub. Partition network segments to distribute the load across multiple servers. Keep network latency to a minimum to optimize TFTP transfers. Ensure that the disk that contains the RemoteInstall folder has enough throughput to meet the client demand. On small-scale solutions, this may mean getting a Serial Advanced Technology Attachment (SATA) drive that spins at 7,200 RPM or faster. On mid-scale solutions, this may mean getting multiple drives and configuring them using Redundant Array of Independent Drives (RAID) configuration. On large-scale solutions, this may mean investing in a hardware RAID array. The disk volume that contains RemoteInstall should be separate from the system volume. 49 Ensure that there is sufficient memory on the server to handle the demands. This may mean upgrading a server from 32-bit (x86) to 64-bit (x64). (for details about how to evaluate whether this solution is worthwhile for you, see Performance and Scalability Expectations). Ensure that there is enough processor bandwidth on the server to handle the demands. If the server has a lot of processes or services that are running, you may need to distribute the processes and services or upgrade the server’s processor. Configuring the Server for Performance and Scalability Performance is the speed of a single client installation. In tests, Windows Deployment Services performs on par with a network-based installation from a file share. As expected, factors such as image size, network speed, and disk speed on the client affect the installation times. Typical installations using the standard Windows Vista image took around 20 minutes from first client boot to desktop. A key benefit of using Windows Deployment Services is the ability to deploy to several clients simultaneously. Again, many factors influence the solution's ability to scale, but the most important ones are the following (in order from most to least influential): 1. Network bandwidth. Windows Deployment Services performs best using a 1-GB-persecond network adapter. In tests, a server with a 100-MB-per-second network adapter could perform a maximum of 10 simultaneous installations, while keeping the installation time under an hour (regardless of the server RAM, disk speed, or processor speed). By contrast, a highend server with a 1-GB-per-second network adapter could install Windows images on 75 simultaneous clients in 45 minutes. 2. RAM on the server. If the computer has enough available memory, it is possible to cache an entire image into memory. This reduces the number of disk read/write operations and, in turn, speeds up the process. If several different images are being deployed concurrently, you may need more RAM. 3. Disk speed on the server. Disk speed is another factor that can slow down deployments (even when you have the maximum amount of RAM). The install image must be read from the disk at least once, and a faster disk speed can accelerate this process. 4. Disk speed on the client. A blockage in the client computer's disk may keep it from achieving the shortest possible installation times. Performance and Scalability Expectations This section outlines the approximate amounts of time that elapsed during the image apply and TFTP download phases. Unicasting Multicasting 50 Unicasting The following table outlines the hardware configurations of the servers that were used during these scalability tests. Server type Network interface card Hardware configuration Low-end 100-MB network adapter Single-processor x86 1 GB of RAM 5,400-RPM disk interface Single-processor x86 2 GB of RAM 7,200-RPM disk interface Dual-processor x64 4 GB of RAM 10,000-RPM disk interface Middle 100-MB network adapter High-end 1-GB network adapter Note Network configuration for the high-end server involved connecting the server’s GB network adapter to a GB switch, which was connected to 100-MB switches that supported a GB back-plane configuration. Time elapsed during the image apply phase This table shows the approximate time (in minutes) from start to finish that it took for all of the clients to apply an install image. Number of clients Low-end Mid-range High-end 1 25 25 25 10 61 55 25 25 125 117 25 50 235 220 35 75 355 330 45 Time elapsed during the TFTP download phase The following table shows the time (in seconds) it took to download Boot.wim using TFTP. Number of clients Low-end Mid-range High-end 1 70 55 40 51 Number of clients Low-end Mid-range High-end 10 210 145 75 25 450 360 120 50 910 805 270 75 1515 1400 420 Time elapsed when the TFTP block was increased The following table shows the effect on time (in seconds) of changing the default TFTP block size. The times are cumulative for the total number of clients simultaneously downloading the same boot image. Network Number of adapter clients Default 4,000 8,000 16,000 32,000 GB 50 270 180 118 92 85 GB 75 422 267 171 126 125 100 MB 75 1,410 1,140 Multicasting Microsoft performed tests to compare the installation times of multicast and unicast transmissions using the same hardware, software, and image set. The following table outlines the configurations of the servers and clients that were used during these tests. The boot and install images were taken from an x86-based version of Windows Server 2008. The size of the boot image was approximately 128 MB, and the size of the install image was approximately 1.32 GB. Note that the out-of-box experience (OOBE) and logon were automated by using an unattend file. Server Client Network interface card Hardware configuration Operating system 1-Gbps network adapter Dual Xenon processor 5150 2.67 Ghz 8 GB of RAM Varied but capable of installing the x86based version of Windows Vista 100 megabits network adapter 64-bit version of Windows Server 2008 52 Multicast Installation 25 clients 100 clients 300 clients Restart computer and start clock. Restart computer and start clock. Restart computer and start clock. Time when the first client started download of boot image using TFTP :23 :21 :23 Time when the last client finishes download of boot image using TFTP 1:02 2:40 7:16 Time when the first client started the multicast transfer 3:04 3:55 8:18 Time when the last client finished the multicast transfer 6:06 7:54 12:30 Total amount of time until the last client reached the desktop 19:47 22:40 27:40 Unicast Installation SMB 25 clients SMB 100 clients SMB 300 clients Restart computer Restart and start clock. computer and start clock. Restart computer and start clock. Time when the first client started download of boot image using TFTP :21 :22 :20 Time when the last client finished download of boot image using TFTP :58 2:40 7:13 Time when the first client started image transfer using unicast/SMB 3:14 4:38 8:29 Time when the last client started image transfer using unicast/SMB 13:36 38:15 1:47:58 Total amount of time until the last client reached the desktop 20:59 45:37 1:55:15 53 Testing of Security Options with Multicast The following table lists the times for the start and end of the multicast transfer of the install image, and the percentage of the CPU used for the multicast transfer, depending on the level of security that was enabled during the test. This test involved 25 client computers. No Security Hashing (default) Signing Start of multicast transfer of the install image to the client Clock started Clock started Clock started End of multicast transfer of the install image to the client 2:19 2:27 31:05 Percentage of CPU used during the multicast transfer ~5% ~11% ~25% Using Transport Server You have two options when installing the Windows Deployment Services role in Windows Server 2008. You can install: Both the Deployment Server and Transport Server role services (default) Only the Transport Server role service The second configuration is for advanced scenarios, such as environments without Active Directory Domain Services (AD DS), Domain Name System (DNS), or Dynamic Host Configuration Protocol (DHCP). You can configure Transport Server to enable you to boot from the network using Pre-Boot Execution Environment (PXE) and Trivial File Transfer Protocol (TFTP), a multicast server, or both. Note that Transport Server does not contain or support the Windows Deployment Services image store. In This Topic Comparison of Deployment Server and Transport Server Configuring Transport Server Using a Transport Server to Boot from the Network Using a Transport Server for Multicast How to create a namespace with Transport Server How to join a client computer to a namespace using Wdsmcast.exe 54 How to perform common tasks Comparison of Deployment Server and Transport Server The following table compares these two installation options. In general, Deployment Server enables the end-to-end Windows Deployment Services deployment solution. Transport Server is a platform that you can use to create a custom multicast deployment solution. Deployment Server Transport Server Server requirements Requires AD DS, Dynamic Host Configuration Protocol (DHCP), and Dynamic Name Services (DNS) in the environment. Does not require other servers in the environment. PXE Supports PXE boot with the default PXE provider. A PXE provider is not installed so you must create a custom PXE provider. Image server Includes the Windows Deployment Services image server. Does not include the Windows Deployment Services image server. Transmission method Allows both unicasting and multicasting. Allows only multicasting. Management tools Is managed using either the Windows Deployment Services MMC snap-in or the WDSUTIL command-line tool. Is managed only by the WDSUTIL command-line tool. Application on the client computer Uses the Windows Deployment Services client (which is basically Setup.exe and supporting files), Wdsmcast.exe (which is included in the Windows AIK), or a custom multicast application. Uses only Wdsmcast.exe or custom application. The server architectures are illustrated in the following diagram. The blue parts are installed with Transport Server and the Deployment Server. The grey parts are installed with the Deployment Server only. The yellow parts are not installed with either, but can be written using guidelines in the Windows SDK. 55 Configuring Transport Server Transport Server does not require any configuration. However, the following configurations are optional. After configuring any of these settings, you must restart the WDSServer service to apply the changes (at an elevated command prompt, run net stop wdsserver, and then run net start wdsserver.) Configure how to obtain IP addresses. If multiple servers are using multicast functionality on a network (Transport Server, Deployment Server, or another solution), it is important that each server is configured so that the multicast IP addresses do not collide. Otherwise, you may encounter excessive traffic when you enable multicasting. Note that each Windows Deployment Services server will have the same default range. To work around this issue, specify static ranges that do not overlap to ensure that each server is using a unique IP address, or configure each of the servers to obtain multicast addresses from a Multicast Address Dynamic Client Allocation Protocol (MADCAP) server. To use MADCAP for IP addresses, run WDSUTIL /Set-TransportServer /ObtainIPv4From:DHCP at an elevated command prompt. To defined range for IP addresses, run WDSUTIL /Set-TransportServer /ObtainIPv4From:Range /Start:<start Ipv4 Address> /End:<end Ipv4 Address> at an elevated command prompt. Set the network profile. The network profile specifies the network speed of the Transport Server. Each profile contains settings to optimize performance for the specified speed (such as the maximum transport window size, the transport cache size, and the block size). You can view the profiles at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\ Multicast\Profiles. Specify Custom if you want to customize the settings yourself by editing the registry. You should not modify the other profiles that are provided. You should use the custom profile even if you only want to change one setting. To set the profile, run WDSUTIL 56 /Set-TransportServer [/Server:<name>] /Profile:{10Mbps|100Mbps|1Gbps|Custom} at an elevated command prompt. Set the UDP port range. To do this, run WDSUTIL /Set-TransportServer [/Server:<name>] /StartPort:x /EndPort:y at an elevated command prompt. Using a Transport Server to Boot from the Network A PXE server consists of two parts: a PXE listener that accepts incoming traffic, and a PXE provider that determines how best to respond to it. Transport Server contains only the PXE listener. In order to use Transport Server to boot a computer from the network, you will need to write a custom PXE provider, and register the provider with Windows Deployment Services, as documented in the Windows Server 2008 Software Development Kit (SDK). Using a Transport Server for Multicasting The multicast server in Windows Deployment Services also has two parts – the multicast provider (which transmits data over the network) and the content provider (which understands the data and passes it to the multicast provider). The content provider (installed with both Transport Server and Deployment Server) can be used to transfer any file. It also has specific knowledge of the .wim format, which it uses to transfer images while other images are added to the image group. You can create a custom content provider for cases where the default provider is not sufficient (for example when using Transport Server to deploy an operating system from inside a .vhd image). See the Windows Server 2008 SDK for guidelines and samples for authoring and registering the provider. How to create a namespace with Transport Server Transport Server transmits data by using multicast functionality through an object called a namespace. A namespace is analogous to a multicast transmission used by Deployment Server. A namespace consists of content to transfer (determined by the content provider with a configuration string), configuration settings (for example, Scheduled-Cast or Auto-Cast), and the names of connected clients. In this section: Prerequisites for creating a namespace To create a namespace Prerequisites for creating a namespace To create a namespace with Transport Server, you need the following: A content provider. You can use the Windows Deployment Services content provider (named WDS) that is included when you install Transport Server. Or you can create your own content provider by using the tools in the Windows Server 2008 SDK. 57 Data to transmit. You can transmit any data that your content provider knows how to find (for example operating system images, data files, or an MP3 archive). The Windows Deployment Services content provider knows how to find any file within a folder. Familiarity with WDSUTIL. The only way to manage Transport Server is through the WDSUTIL command-line tool. A way to boot clients. This is because Transport Server does not include a PXE provider (such as BINLSVC). Routers. The routers in your environment must support multicasting. In particular, your network infrastructure needs to support the Internet Group Management Protocol (IGMP) to properly forward multicast traffic. Without the IGMP, multicast packets are treated as broadcast packets, which can lead to network flooding. To create a namespace Like with Deployment Server, you can create Scheduled-Cast and Auto-Cast namespaces. For more information about each parameter, see Options. To create a Scheduled-Cast namespace Syntax: WDSUTIL /New-Namespace [/Server:<server name>] /Namespace:<namespace name> /FriendlyName:<friendly name> [/Description:<description>] /ContentProvider:<name> /ConfigString:<config string> /NamespaceType:ScheduledCast [/Time:<YYYY/MM/DD:hh:mm>] [/Clients:<number of clients>] For example: WDSUTIL /New-Namespace /Server:MyWDSServer /FriendlyName:"Custom Scheduled Namespace" /Namespace:"Custom Scheduled 1" /ContentProvider:WDS /ConfigString:D:\Images /NamespaceType:ScheduledCast /Time:"2006/11/20:17:00" /Clients:20 To create an Auto-Cast namespace Syntax: WDSUTIL /New-Namespace [/Server:<server>] /Namespace:<namespace name> /FriendlyName:<friendly name> [/Description:<description>] /ContentProvider:<name> /ConfigString:<config string> /NamespaceType:AutoCast For example: WDSUTIL /New-Namespace /FriendlyName:"Custom AutoCast Namespace" /Namespace:"Custom Auto 1" /ContentProvider:WDS /ConfigString:D:\Images /NamespaceType:AutoCast How to join a client computer to a namespace by using Wdsmcast.exe The Windows Deployment Services client user interface will not work with Transport Server. Therefore, to connect a client to a namespace, you have two options: Use Wdsmcast.exe, which is included in the Windows Automated Installation Kit (AIK). This is a command-line utility you can use to connect to any namespace or multicast transmission that uses the Windows Deployment Services content provider. For more information about 58 this, see the following procedure. You can download the Windows AIK at http://go.microsoft.com/fwlink/?LinkID=54863. Use a custom deployment client. You can do this by using the APIs of the Windows Deployment Services transport client. You will need to create a custom client if you are using a custom content provider. For instructions on how to do this, see the Windows Server 2008 SDK. To join a namespace by using Wdsmcast.exe 1. Download and install the Windows AIK. 2. Run Copype.cmd to create a Microsoft Windows Preinstallation Environment (Windows PE) image. 3. Mount the image by using Imagex.exe, and then copy the Wdsmcast.exe into the Windows PE image. 4. If the content that you are multicasting is a .wim image, copy Imagex.exe into the Windows PE image that you just created. This is so the image can be applied after it is transmitted. 5. Unmount the image and commit the changes. 6. Boot the client computer to the image (from a CD, DVD, or USB drive, or by using the PXE capability in Transport Server). 7. Start Windows PE networking by running WPEINIT on the client computer. 8. From the client computer, run a command with the following syntax (the following table explains these options): WDSMCAST /Transfer-File /Server:<server name> /Namespace:<namespace name> /Username:<domain and user name> [/Password:<password>] /SourceFile:<file path> /DestinationFile:<file path> Syntax: Option Description /Server:<server name> The name of the Windows Deployment Services server. This can be either the NetBIOS name or the fully qualified domain name (FQDN). If the server name is not specified, the name of the local server will be used. /Namespace:<namespace The name of the namespace. This value should match the name name> given when creating the namespace on the server. This is not the "friendly" name, and it must be unique. Note When using this option with Deployment Server, the syntax is as follows: /Namespace:WDS:<ImageGroup>/<ImageName>/<Index>. 59 Option Description For example: WDS:ImageGroup1/install.wim/1 Note To view all namespaces that currently exist on the server, run WDSUTIL /get-allnamespaces. /Username:<domain and user name> The domain name and user name to connect to the server. These can be either in the format Domain\User or the format User@Domain. [/Password:<password>] The password for the user. If this is not specified, you will be prompted to enter it. /SourceFile:<file path> Path to the name of the file to be transferred, relative to the directory specified in the /ConfigString path of the namespace. For example, if you specified WDSUTIL /New-Namespace /ConfigString:C:\RemoteInstall\Images, specify /SourceFile:ImageGroup\install.wim. /DestinationFile:<file path> The complete file path and name for the destination file. How to perform common tasks The following are the most commonly used commands with Transport Server. For more information about each parameter, see Options. To start the transmission. To start a transmission, the transmission must be a ScheduledCast namespace, and there must be at least one client that has requested the transmission of data. Syntax: WDSUTIL /Start-Namespace /Namespace:<name> To display information for the clients that are connected to a namespace (for example, computer name, MAC address, IP address, speed, and percent complete) Syntax: WDSUTIL /Get-Namespace /Namespace:<name> /Show:Clients To remove a namespace Syntax: WDSUTIL /Remove-Namespace [/Server:<server name>] /Namespace:<namespace name> [/Force] For example: To remove the namespace after current client downloads are complete, run: WDSUTIL /Remove-Namespace /Namespace:"Custom Auto 1" To remove the namespace immediately and stop any current client downloads, run: 60 WDSUTIL /Remove-Namespace /Server:MyWDSServer /Namespace:"Custom Auto 1" /Force To stop a client installation completely Syntax: WDSUTIL /Disconnect-Client /ClientID:<id> /Force Important You should use this option with caution because the installation will fail and the computer could be left in an unusable state. To discontinue the download for a client but continue to transfer the image through another method (such as SMB copy). The client will fall back to another method of transfer only if the client implementation supports this behavior. Although the Windows Deployment Services client will fall back to SMB transfer, note that Wdsmcast.exe does not support any fallback mechanism. Syntax: WDSUTIL /Disconnect-Client /ClientID:<id> To view the client <id> for each namespace Syntax: WDSUTIL /Get-Namespace /Namespace:<name> /show:clients To view all clients connected to all namespaces on the server Syntax: WDSUTIL /Get-AllNamespaces Options The options in the following table apply to the sections "Creating a namespace with Transport Server" and "Using common commands" earlier in this chapter. Option Description /Server:<server name> The name of the Windows Deployment Services server. This can be either the NetBIOS name or the FQDN. If the server name is not specified, the name of the local server will be used. /Namespace:<Nam espace name> The name of the namespace. This value should match the name given when creating the namespace on the server. Note that this is not the "friendly" name, and it must be unique. Note When using this option with Deployment Server, the syntax is as follows: /Namespace:WDS:<ImageGroup>/<ImageName>/<Index>. For example: WDS:ImageGroup1/install.wim/1 Note To view all namespaces that currently exist on the server, run WDSUTIL /get-allnamespaces. /FriendlyName:<frie The friendly name of the namespace. Note that this name does not need to 61 Option Description ndly name> be unique. /Description:<descri ption> A short description of the namespace. /ContentProvider:<n The name of the content provider that supplies data to the multicast server. ame> If you are using the Windows Deployment Services content provider, specify WDS. /ConfigString:<confi g string> The configuration string for the content provider. If you are using the Windows Deployment Services content provider (WDS), specify the path to the folder where content is stored (for example, D:\Photos\Landscapes). This path can be anywhere on the server. /NamespaceType: {AutoCast|Schedule dCast} The type of namespace to be created. /Time:<YYYY/MM/D The time on the server when the namespace will start (note that you can D:hh:mm> set this option only for Scheduled-Cast transmissions). /Clients:<Num of Clients> The number of clients to wait for before the namespace will start (note that you can set this option only for Scheduled-Cast transmissions). /Force An option that deletes the transmission, even if there are current client installations. If you do not specify /Force, the transmission will be in the Delete Pending state, meaning that the transmission will be removed after clients' downloads are completed. Performing Unattended Installations You can configure the entire deployment process using Windows Deployment Services to be without user interaction. To do this, you will need to automate the PXE boot, the selection of a boot image, and Setup. Automating the PXE Boot Automating Setup Automating the Domain Join Automating the Image Capture Wizard Advanced Unattended Installation Scenarios Sample Unattend Files 62 Automating the PXE Boot In This Topic Automating the PXE Boot Automating the Selection of the Boot Image Automating the PXE Boot First to configure the client computer to perform PXE boots automatically when the computer is started, you can modify the boot order in the computer’s firmware (BIOS or Extensible Firmware Interface (EFI)) or by disabling any active partitions before booting. If there are active partitions, the option to boot from the network must be higher in the boot sequence than the hard disk drive. It is important to note that this configuration is susceptible to a boot loop, a condition that causes a computer to always boot from the network, and never from the hard disk drive. For more details, see Avoiding a Boot Loop. If there are no active partitions, the computer will be unable to boot from the hard disk drive, and it will proceed to the next boot item in the boot order. As such, we recommend that you include the option to boot from the hard disk drive before the option to boot from the network (to avoid a boot loop). Second, the network boot program (NBP) that is downloaded by the client computer must automatically continue the boot process without user interaction (for example, by pressing F12). You can configure this by doing one of the following: Specifying the default NBP of the server (per architecture) so that all clients receive the *.n12 boot program. Specifying the NBP for a particular client so that only that client receives the *.n12 boot program. Configuring unknown clients to perform PXE boots without requiring F12 (WDSUTIL /SetServer /AllowN12ForNewClients:Yes) and then booting a computer that is not prestaged. For a list of the NBPs, see the "List of NBPs" section in Managing Network Boot Programs. Note Because there is only one NBP for EFI computers, you must configure this setting within the EFI shell. Avoiding a Boot Loop When implementing a fully automated experience of booting from the network, it is often necessary to set the network as the first item in the client’s BIOS boot order and send a specific client an .n12 NBP. If you combine these two configurations, the client will automatically boot from the network without requiring user intervention, and the computer will end up in a circular 63 loop (always booting from the network and never booting from the hard disk drive). The following are best practices that you can use to avoid a boot loop: Always configure the hard disk drive as a higher priority than the network. To enable a computer that already has an operating system installed to boot automatically from the network (for example, when reprovisioning a computer), disable any active partitions before rebooting the computer to initiate the PXE boot. For prestaged computers that are configured to boot from the network before booting from the hard disk drive, toggle the BootProgram value between *.N12 and *.COM to control the automatic PXE boot behavior. For example, set it to boot\x86\pxeboot.n12 when you want to boot the computer from the network, and set it to boot\x86\abortpxe.com when you want to boot from the hard disk drive. For instructions on how to do this, see How to Manage Client Computers. For nonprestaged computers that are configured to boot from the network before booting from the hard disk drive, set the server default NBP to *.COM and configure the AllowN12ForNewClients option. This will prevent a boot loop if both of the following are true: the booting client will perform an operating system installation by using Windows Deployment Services, and the client computer is configured to join a domain, which is the default. Example Scenario Consider the following situation. Computer A has been configured with the following boot order: CD-ROM, Network, then Hard disk. On the Windows Deployment Services server, the default NBP setting for x86-based computers is boot\x86\pxeboot.n12, which is an NBP that does not require pressing F12 to boot from the network. The following sequence of events will result in a boot loop: 1. The computer is turned on. 2. Assuming there is not a bootable CD, the computer boots from the network, downloads Windows PE from the Windows Deployment Services server, and proceeds through the user interface of the Windows Deployment Services client. 3. The image installation to the hard disk drive begins. 4. After the image is applied, the computer reboots. The boot order sequence still specifies the network as a higher priority than the hard disk drive. And, the NBP received by the client is still *.N12, which causes the computer to continue the process of booting from the network. As a result, the image that was just applied to the hard disk drive will never be booted. Automating the Selection of the Boot Image Windows Deployment Services displays a menu that enables users to select a boot image. This menu is always automated, and when there are multiple boot images, one will be selected by default when the time-out value expires (which is configurable by using the Bcdedit tool). 64 However, if there is only one boot image available to the client computer, it will be selected immediately. For more information about the boot menu, see Managing the Boot Menu. Because the boot menu selection does not require any user action, the only configuration task that you need to complete is to ensure that clients are directed to the correct default boot image. There are two methods for doing this: Configure the default boot image at the server level by running WDSUTIL /Set-Server /BootImage:<Relative path>] /Architecture:{x86 | ia64 | x64} where <path> is the relative path to the RemoteInstall folder. This setting applies to all clients of a particular architecture (both prestaged and unknown computers) that connect to the server. Configure the default boot image for a client by running the command WDSUTIL /Set-Device /Device:<name> /BootImagePath:<Relative path>, where <path> is the relative path to the RemoteInstall folder. This option works only for prestaged computers. Automating Setup In This Topic Creating Unattend Files Automating the User Interface Screens of the Windows Deployment Services client Automating the Remaining Phases of Setup Creating Unattend Files To automate the entire installation you use two different unattend files: one for the Windows Deployment Services UI screens, and one for the latter phases of Setup. Two files are necessary because Windows Deployment Services can deploy two image types: Windows Vista images that support the Unattend.xml format, and Windows XP and Windows Server 2003 images, which do not support the Unattend.xml format. Windows Deployment Services client unattend file. To automate the Windows Deployment Services client user interface screens (such as entering credentials, choosing an install image, and configuring the disk), create a client unattend file. This file uses the Unattend.xml format and is stored on the Windows Deployment Services server in the RemoteInstall\WDSClientUnattend folder. For more information, see Automating the Windows Deployment Services client later in this topic. Image unattend file. Image unattend files automate the remaining phases of setup (for example, offline servicing, Sysprep specialize, and mini-setup). This file uses the Unattend.xml or Sysprep.inf format, depending on the version of the operating system of the image. It is stored in a subfolder (either $OEM$ structure or \Unattend) in the per-image folder. For more information, see Automating the Remaining Phases of Setup later in this topic. 65 It is possible to use a single unattend file throughout the entire installation process. To do this, you must pass an unattend file to Setup.exe with the /unattend:<unattend file> option, and you must configure the command-line unattend precedence appropriately. For precedence information, see Advanced Unattended Installation Scenarios. For an example file, see Sample Unattend Files. In addition, Windows Deployment Services supports implicit unattend searching and can be used in conjunction with AutoUnattend.xml. For more information about implicit search paths, see Methods for Running Windows Setup at http://go.microsoft.com/fwlink/?LinkId=120686. Automating the User Interface Screens of the Windows Deployment Services Client You automate the UI screens using the Windows Deployment Services client unattend file (Unattend.xml). To completely automate the UI screens, you must specify settings that correspond to each screen. Unfortunately, this is not easy to figure out because of the Unattend.xml design. Unattend.xml is organized by the phases of unattend setting processing. As a result, there is not always a 1:1 mapping relationship between a particular setting and a UI screen. In addition, not all of the settings that are necessary to automate the UI screens for the Windows Deployment Services client are grouped within the file. We recommend that you use Windows System Image Manager (Windows SIM) to author the Windows Deployment Services client unattend file because it abstracts the format of the unattend file and makes for a simplified authoring experience. Some of the settings in Unattend.xml that are processed by the Windows Deployment Services client are identical in syntax and form to other sections supported by Windows Vista Setup. For example, the DiskConfiguration setting used by the Windows Deployment Services client is identical to the DiskConfiguration section used by Setup. Other settings are specific to Windows Deployment Services (these reside in the WindowsDeploymentServices section) and are processed only when Setup.exe is running in Windows Deployment Services mode (see “When Setup Is Started in Windows Deployment Services Mode” in How the Windows Deployment Services Client Works (http://go.microsoft.com/fwlink/?LinkId=147067)). The Windows Deployment Services client processes only settings in the Windows PE section of the client unattend file. It will not process settings in any other sections of that file, nor will it pass on the client unattend file for further processing after the image is applied, unless at least one of the following is true: You have configured command-line precedence and are using an unattend file that was passed to Setup through the command line. You do not have an image unattend file, and the client is not configured to join a domain. To associate a client unattend file by architecture 1. Create an Unattend.xml file with settings applicable to Windows Deployment Services client screens. For examples of these setup tasks, see Sample Unattend Files. 2. Copy the client unattend file to a folder in the RemoteInstall folder. For example: 66 RemoteInstall\WDSClientUnattend. 3. Open the Windows Deployment Services MMC snap-in, right-click the server that contains the Windows Vista or Windows Server 2008 image that you want to associate the unattend file with, and then click Properties. 4. On the Client tab, select Enable unattended installation, browse to the appropriate unattend file, and then click Open. 5. Click OK to close the Properties page. Note The commands for this task are: To associate a client unattend file by architecture run WDSUTIL /Set-Server /WDSUnattend /Policy:enabled /File:<filepath> /Architecture:<arch>. To associate a client unattend file per computer, run WDSUTIL /Set-Device /Device:<computername> /ID:<GUID or MAC address> /WDSClientUnattend:<relative path> Unattend File Settings The settings in the following table must be specified in the Windows Deployment Services client unattend file to completely automate the client experience. You can find the complete details of these settings at Windows Unattended Setup Reference http://go.microsoft.com/fwlink/?LinkId=120687. For examples, see Sample Unattend Files. UI page Component Unattend setting Explanation Languageneutral page Microsoft-WindowsInternational-CoreWindows PE SetupUILanguage Specifies the language for the Windows Deployment Services client UI. This setting is required only when the boot image has setup resources for multiple languages. Welcome and keyboard selection page Microsoft-WindowsInternational-CoreWindows PE InputLocale Specifies the computer's input locale and the keyboard layout for the selected image. If this setting is not specified, a default will be chosen based on UILanguage. Even if <InputLocale> is properly configured not to display UI, the welcome page will be displayed if the credentials page <WillShowUI> value is set to Always. Credentials page Microsoft-WindowsSetup -> WindowsDeployme Credentials Specifies the user name, domain, and password of an account with proper permissions to install the specified 67 UI page Component Unattend setting ntServices -> Login Explanation image. Image selection page Microsoft-WindowsSetup -> WindowsDeployme ntServices InstallImage Specifies the image to be installed. Image selection page Microsoft-WindowsInternational-CoreWindows PE UILanguage Specifies the language for the selected image. If this setting is not specified or if the specified value does not match any of the available install languages, the image selection page will be displayed. Do not specify this value if InstallImage is a Windows Server 2003, Windows 2000, or Windows XP image. In those cases, this setting does not apply and will cause an error (which causes the image selection page to appear). Image selection page Microsoft-WindowsInternational-CoreWindows PE UILanguageFallb ack Specifies the language to be used if the computer's default UI language is only partially localized for the selected image. Disk configuration page Microsoft-WindowsSetup -> DiskConfiguration Disk Specifies the disk configuration settings. Disk configuration page Microsoft-WindowsSetup -> WindowsDeployme ntServices -> ImageSelection InstallTo Specifies the disk and partition to which the selected image is to be installed. Automating the Remaining Setup Phases You automate the remaining phases of Setup with an image unattend file (Unattend.xml or Sysprep.inf). For examples, see Sample Unattend Files. Unattend.xml. For Windows Vista and Windows Server 2008 images, author Unattend.xml by using Windows SIM, save it to a known location, and then associate the file with an image using the management tools. To do this, right-click the image in the MMC snap-in that you 68 want to associate with the unattend file, and then click Properties. On the General tab, click Allow image to install in unattend mode, click Select File, browse to select the unattend file, and then click OK twice. The Unattend.xml file will be saved to the following location: \RemoteInstall\Images\<imagegroup>\<imagename>\Unattend\ImageUnattend.xml. Sysprep.inf. For images prior to Windows Vista, author Sysprep.inf by using Setup Manager and then save these files to the $OEM$ structure of the image (for example, D:\RemoteInstall\Images\Windows XP\winxpsp2\$OEM$\$1\sysprep\sysprep.inf). Now when you deploy the image, Setup will automatically locate and use the Sysprep.inf file. Automating the Domain Join By default, all operating system installations using Windows Deployment Services result in a client computer that is joined to a domain. If a client computer is prestaged in Active Directly Domain Services (AD DS), the client will be joined to the domain as the prestaged computer. In order for the join to be successful, the user account must have permissions to join the domain and rights to create computer objects in AD DS (this is required if you are not using prestaged computer objects).For more information, see Required Permissions. In This Topic Modifying Your Unattend Files Choosing a Permissions Method Modifying Your Unattend Files The domain join process uses the image unattend file to pass data that is collected within Windows PE to the subsequent phases of Setup.exe. If an image is associated with an image unattend file, the domain join and computer name settings will be made directly to this file. However, for this to occur, you must properly the file correctly (see the Sample Unattend Files). Specifically, this means as follows: For Windows Vista or Windows Server 2008 images. The image unattend file (ImageUnattend.xml) must have the setting <UnsecureJoin>true</UnsecureJoin> in the Microsoft-Windows-UnattendedJoin component. Additionally, the Microsoft-WindowsShell-Setup component for the <specialize> unattended pass must exist, even if it is empty. For Windows XP and Windows Server 2003 images. The image unattend file in the $OEM$ structure (Sysprep.inf) must have the setting DoOldStyleDomainJoin=Yes, and it must have (at a minimum) the [Networking] and [UserData] sections, even if they are empty. If the image unattend file does not contain the proper formatting, Windows Deployment Services will assume that you have chosen to override or avoid the domain join and computer name functionality and therefore will not edit the unattend file. If a selected image does not have an 69 associated image unattend file, a template unattend file will be used to pass domain join (and computer naming) information throughout the installation process. For Windows Vista or Windows Server 2008 images, this file exists within the image itself as \System32\WDSUnattendTemplate.xml. Therefore, after the image is applied, the template file will be located offline on the disk. For Windows XP and Windows Server 2003 images, this file exists in the \RemoteInstall\Templates\Sysprep.inf folder on the server when the server is first initialized. After the image is applied, Windows Deployment Services will copy the template Sysprep.inf into the offline image and then edit it as appropriate. This file is copied from the server into the offline image as C:\Sysprep\Sysprep.inf. Choosing a Permissions Method For providing credentials in an unattend file, there are two permissions methods, that enable a computer to join a domain: unsecure join and secure join. Both of these methods are described in the following table. Unsecure join Secure join This method involves resetting the computer account to a known, shared computer password and enabling the computer to join a domain without credentials. For Windows Vista and Windows Server 2008 images, this shared computer password is a dynamically generated, strong password that is set by Windows Deployment Services. The password is inserted into the ImageUnattend.xml file as the <MachinePassword> setting. For images from an earlier version of Windows, this shared computer password is the computer name. This method is secure in the sense that it requires credentials (user name, domain, and password) before you can reset the account and perform the domain join. However, in practice this method is actually less secure because the credentials reside in the ImageUnattend.xml file in plain text. Advantages: This method uses a simplified permissions model because a single account is used throughout the enterprise to perform all domain join operations. Advantages: This method does not require placing unattend credentials in plain text in the unattend file. Disadvantages: It is possible for a malicious user to join the domain between the time the computer account was reset (in Windows PE) and when the actual domain join occurs (on first boot of the applied image). This particular attack is effectively mitigated with Windows Vista and Windows Server 2008 images because Disadvantages: Credentials are stored in plain text in the image unattend file, which is located on a shared folder on the Windows Deployment Services server. To implement a secure join, do the following to the unattend file: 1. Set UnsecureJoin = FALSE. 2. Specify the credentials for performing the domain join, and the domain that you want to join the computer to. 3. Ensure that the Microsoft-Windows-Shell70 Unsecure join Secure join the password is dynamically generated. To implement an unsecure join, set UnsecureJoin = TRUE and ensure that the Microsoft-Windows-Shell-Setup component exists for the specialize phase. Setup component exists for the specialize phase. 4. Set the <ComputerName> value to %MACHINENAME%. During installation, Windows Deployment Services will retrieve the name of the prestaged account from AD DS and replace the %MACHINENAME% string with the actual computer name. Automating the Image Capture Wizard The Image Capture Wizard will run in unattended mode when the WDSCapture.inf file exists in the same folder as the WDSCapture.exe file (that is, X:\Windows\System32 within the image), and Unattended=Yes is specified in the file. If unattended mode is set to No but WDSCapture.inf exists and has settings defined, those settings will be used to create the wizard's dialog boxes. To automate this wizard, create a WDSCapture.inf file. Then create a capture image and save this file within the image. To do this, mount the image using ImageX, save this file as Windows\system32\Wdscapture.inf (overwrite the existing Wdscapture.inf), and then unmount the image. Lastly, add the capture image to the Windows Deployment Services server. When you boot a computer into this image, the UI screens will be automated and the image will be uploaded to the server with the settings you have specified. WDSCapture.inf Unattend File Settings This section explains the format for WDSCapture.inf files. To view a sample WDSCapture.inf, see Sample Unattend Files. [Capture] Contains all of the capture settings for the Image Capture Wizard, as described in the following table. Setting Description Unattended=Yes|No Specifies whether the wizard should be in unattend mode. Yes. Specifies that the wizard is in unattend mode, and suppresses all pop-ups and user interface elements. All unattend settings are read out of this file. No. Specifies that the wizard is not in unattend mode, and uses values 71 Setting Description in the file to prepopulate the user interface. VolumeToCapture Specifies the volume that is holding the Windows installation to be captured. This setting must be in the following format: drive letter, colon, back slash. For example: c:\ ImageName Specifies the value to be set as the image name within the image metadata. This will be the image name as displayed in the Windows Deployment Services management tools and the user interface of the Windows Deployment Services client. (The Windows Deployment Services client is basically Setup.exe and supporting files.) ImageDescription Specifies the value to be set as the description within the image metadata. This will be the image name as displayed in the Windows Deployment Services management tools and the user interface of the Windows Deployment Services client. DestinationFile Specifies the full path and name of the .wim file to which the image is to be captured. SystemRoot The name of the system root folder. If this setting is not specified, \Windows, \Winnt, and \i386 will be tried. The Image Capture Wizard must locate the system root to extract the data needed to form the metadata (for example, the version of the operating system and installed languages) that is added to the .wim during the capture. Overwrite=Yes|No| Append (Default=No) Designates whether the file specified in DestinationFile should be overwritten if a file with that name already exists in the specified location. Yes. Specifies to overwrite the existing file. No. The process will cause an error if a file with the same name already exists in the specified location. Append. If a .wim file with the same name already exists, the capture should be appended as a new image within the existing .wim file. This setting often produces a much faster capture because when files from the current capture operation already reside in the .wim file (for example, if file resources in another image already exist in the .wim file), the files are not copied into the .wim file again. The image name specified must be unique within the .wim file; otherwise, you will receive an error. [ExclusionList] Defines the files and folders to be excluded from the capture. By default, this section is populated with the following items: $ntfs.log, hiberfil.sys, pagefile.sys, System Volume Information, 72 RECYCLER, winpepge.sys, and %SYSTEMROOT%\CSC. Note that the %SYSTEMROOT% variable is replaced by the value specified in SystemRoot in the [Capture] section. [WDS] Contains all of the Windows Deployment Services-specific unattend settings. Setting Description UploadToWDSServer=Yes|N o (Default=No) Specifies whether the resulting image should be added to a Windows Deployment Services server's image store. If this value is set to No, all other settings under the [WDS] section will be ignored. WDSServerName Specifies the name of the Windows Deployment Services server. This can be either a NetBIOS name or a fully qualified domain name (FQDN). WDSImageGroup The name of the image group on the specified Windows Deployment Services server. Username The user name to use when connecting to the specified Windows Deployment Services server. This name can take either of the following forms: domain\username or [email protected]. Password The password of the user account. Note We recommend that you enter credentials in the wizard user interface (UI). Credentials specified in WDSCapture.inf are stored in plain text within the capture image, and there is no way to secure these credentials. DeleteLocalWIMOnSuccess= Specifies whether the local capture image (where the capture Yes|No image was saved) will be deleted at the end of the process, assuming that the image is successfully uploaded to the Windows Deployment Services server. You should be careful when using this option with the Overwrite=append option because the entire image will be deleted (not just the new .wim that was appended to the existing image). Advanced Unattended Installation Scenarios This topic contains information about advanced tasks that you can implement with Windows Deployment Services. 73 In This Topic Passing Unattend Files to Setup by Using the Command Line Using Implicit Unattend Files Embedding an Unattend File in an Image Understanding Unattend File Precedence Setting Command-Line Precedence for Unattend Files Using Variables to Obtain Information from the Client Passing Unattend Files to Setup by Using the Command Line It is possible to pass an unattend file directly instead of obtaining the unattend file from the server. You can do this by passing /unattend:<unattend file> and /wds with Setup.exe (for example, Setup.exe /WDS /Unattend:X:\WDSClientUnattend.xml). If you are booting Windows PE by using a CD, DVD, or hard disk drive, you must also invoke the Windows Deployment Services client in discover mode by using the /WDSDiscover option. For more information about Windows Deployment Services mode, see the “When Setup Is Started in Windows Deployment Services Mode” section in How the Windows Deployment Services Client Works (http://go.microsoft.com/fwlink/?LinkID=147067). As is also the case when receiving the Windows Deployment Services client unattend file from the server, the unattend file that you passed by using the command line will be used only for the Windows PE phase. Settings corresponding to other unattended passes will be handled by the image unattend file. The following is an example scenario: 1. A client computer boots into a version of Windows PE that contains the Windows Vista Setup files. The client boot can be performed over the network, from a CD or DVD, or from the hard disk drive. 2. A custom application is invoked, which has a customized user interface (UI). 3. The application detects the computer’s MAC address and contacts a database to get the correct unattend file. 4. The application uses the Windows Deployment Services client (which is essentially Setup.exe and supporting files) to retrieve a list of available images that are stored on a Windows Deployment Services server, and then it displays this list to the user. 5. The user selects an image. 6. The application takes the selected image and inserts the appropriate data into the unattend file. 7. The application invokes Setup.exe in Windows Deployment Services mode, and then it passes Setup.exe an unattend file. 8. The installation proceeds. 74 Using Implicit Unattend Files You can use implicit unattend files, which means that if an unattend file is not specified (through the command line or from the Windows Deployment Services server), the client searches for an unattend file in several locations. The most common scenario involves using a file called AutoUnattend.xml, which is at the root of removable media (such as a CD, DVD, or USB flash drive). For more information about implicit search paths, see Methods of Running Windows Setup at http://go.microsoft.com/fwlink/?LinkId=120686. Embedding an Unattend File in an Image In general, it is a best practice to store unattend files outside of the images with which they are associated. The main reason for this is flexibility; it is easier to modify an image that is on a file share on the Windows Deployment Services server than it is to mark an image offline, export the image, mount it, modify the unattend file, and then reimport the image. However, there are some cases where you may want to include the unattend file in a boot or install image. The following is an example of a scenario in which you may want to do this. There are two types of computers in your organization — laptops and desktops. Your company policy states that all laptops should be configured with two partitions to support BitLocker Drive Encryption, and desktops should have a single partition and do not need BitLocker support. You create a custom boot image that is configured to run a simple script. The first action in the script is to use Windows Management Instrumentation (WMI) calls to determine whether a particular booted client computer is a laptop or a desktop. If the computer is a laptop, the script calls Setup.exe by using the /wds option and then passes an Unattend.xml file for laptop use (one that creates two hard disk partitions). If the computer is a desktop, the script calls Setup.exe by using the /wds option and then explicitly passes an Unattend.xml file for desktop use (one that creates only a single partition). Understanding Unattend File Precedence The following table outlines the precedence for unattend files. Note that you cannot change this precedence order. Windows Deployment Services client unattend Image unattend file file AWindows Deployment Services client unattend file that is defined always overrides an implicit unattend file. The order of precedence for this file is as follows: The order of precedence for this file is as follows: 1. Unattend files that are passed explicitly from the command line (for example, 2. Image unattend files in the $OEM$ structure 1. Explicitly assigned image unattend files (Windows Vista images only) 75 Windows Deployment Services client unattend Image unattend file file setup.exe /wds /unattend:<unattend file>) 2. Unattend files that are defined on the server 3. An implicit unattend file (AutoUnattend.xml) 3. Template unattend files (used as part of a domain join) 4. Client unattend files that have been carried over into additional phases of unattend processing Setting Command-Line Precedence for Image Unattend Files There are installation scenarios in which you may want to use the same Unattend.xml file for automating the Windows Deployment Services client and subsequent phases of Setup when performing a custom deployment solution. Note that command-line precedence does not apply to Windows Deployment Services client unattend files that are obtained from the Windows Deployment Services server. By setting the command-line precedence value, you can specify whether another unattend file (either an implicit unattend file such as AutoUnattend.xml, or an unattend file passed by using the /Unattend option) will be used instead of the image unattend file when installing a client computer. To override an existing image unattend file associated with an image, first enable unattend installations by running the command wdsutil /set-server /wdsunattend /Policy:{Enabled | Disabled}. Next, run one of the following: To allow an unattend file on the client computer to override the unattend file sent from the server, run WDSUTIL /Set-Server /WDSUnattend /CommandLinePrecedence:Yes. To force the unattend file from the server to be used, run WDSUTIL /Set-server /WDSUnattend /CommandLinePrecedence:No. The following is an example scenario: There are two types of computers in your organization — laptops and desktops. Your company policy states that all laptops should be configured with two partitions and should contain the proper Bluetooth drivers and software. It also states that desktops should have a single partition and do not need Bluetooth support. Because the majority of the computers in your organization are desktops, you create a Windows Deployment Services client unattend file that creates a single disk partition. Then you create a Windows Vista image with an image unattend file that does not install the Bluetooth drivers and software. Next, you create a single Unattend.xml file that performs all of the custom actions needed for laptop installations. Finally, you create a custom boot image that is configured to run a script. The first action in the script is to use WMI calls to determine whether a booted client computer is a laptop or a desktop. If the computer is a laptop, the script calls Setup.exe by using the /wds option and then explicitly passes the custom Unattend.xml file for laptop use. To ensure that this single unattend is used throughout the process, you set the command-line precedence value of the server appropriately. This action causes the unattend file that is passed to the Windows 76 Deployment Services client through the command line to override the existing image unattend file that is associated with the image on the Windows Deployment Services server. If the computer is a desktop, the script invokes the client normally, enabling the typical installation to continue (the client will obtain both the Windows Deployment Services client unattend file and, later, the image unattend file from the Windows Deployment Services server). Using Variables to Obtain Information from the Client The Windows Deployment Services client can obtain several pieces of information during an installation that you can use as part of your custom deployment scenario. The client will insert the proper variable valuess into your unattend file automatically as long as your file is formatted correctly. The variables that the client can use for this purpose are: %USERDOMAIN%. The name of the user's domain, which was specified either by credentials or in the Windows Deployment Services client unattend file. %USERNAME%. The user's name, which was specified either by credentials or in the Windows Deployment Services client unattend file. %USERPASSWORD%. The user's password, which was specified either by credentials or in the Windows Deployment Services client unattend file. Using this variable may pose a security risk and is not recommended. The password value will be written to the unattend file in plain text. %MACHINEDOMAIN%. The domain containing the computer account that represents the physical client computer. %MACHINENAME%. The computer name of the computer account that represents the physical client computer. %TIMEZONE%. The time zone of the Windows Deployment Services server. %ORGNAME%. The organization name of the Windows Deployment Services server. To see an example file that uses these variables, see Sample Unattend Files. Sample Unattend Files In This Topic Windows Deployment Services Client Unattend Files Example 1: Standard installation Example 2: Install a language pack Image Unattend Files for Windows Vista and Windows Server 2008 77 Example 1: Unsecure domain join Example 2: Secure domain join Example 3: Using variables Image Unattend Files for Older Operating Systems Example 1: Domain join Example 2: Using variables Example 3: Run a script Combined Image and Client Unattend File Image Capture Wizard Unattend File Note To download the Windows Deployment Services documentation (including a getting started guide, deployment guide, and WDSUTIL command-line syntax), see http://go.microsoft.com/fwlink/?LinkId=89381. Windows Deployment Services Client Unattend Files Example 1: Standard installation The following file contains all of the standard attributes that are needed to automate the UI screens. It specifies the language for the installation (<SetupUILanguage>), the credentials for the client to access the Windows Deployment Services server (<Credentials>), and the image for installing on the client computer (<ImageName>). It also configures the disk layout – for example, the image will be installed on the first partition (<PartitionID>) and the first disk (<DiskID>) on the client computer. <?xml version="1.0" ?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="windowsPE"> <component name="Microsoft-Windows-Setup" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86"> <WindowsDeploymentServices> <Login> <WillShowUI>OnError</WillShowUI> <Credentials> <Username>username</Username> <Domain>Fabrikam.com</Domain> <Password>my_password</Password> 78 </Credentials> </Login> <ImageSelection> <WillShowUI>OnError</WillShowUI> <InstallImage> <ImageName>Windows Vista with Office</ImageName> <ImageGroup>ImageGroup1</ImageGroup> <Filename>Install.wim</Filename> </InstallImage> <InstallTo> <DiskID>0</DiskID> <PartitionID>1</PartitionID> </InstallTo> </ImageSelection> </WindowsDeploymentServices> <DiskConfiguration> <WillShowUI>OnError</WillShowUI> <Disk> <DiskID>0</DiskID> <WillWipeDisk>false</WillWipeDisk> <ModifyPartitions> <ModifyPartition> <Order>1</Order> <PartitionID>1</PartitionID> <Letter>C</Letter> <Label>TestOS</Label> <Format>NTFS</Format> <Active>true</Active> <Extend>false</Extend> </ModifyPartition> </ModifyPartitions> </Disk> </DiskConfiguration> </component> 79 <component name="Microsoft-Windows-International-Core-WinPE" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86"> <SetupUILanguage> <WillShowUI>OnError</WillShowUI> <UILanguage>en-US</UILanguage> </SetupUILanguage> <UILanguage>en-US</UILanguage> </component> </settings> </unattend> Example 2: Install a language pack You can use the following example file to install a language pack. If the <UILanguage> is the same as the language on the image, then Windows Deployment Services will not install a language pack. However, if you use the following example with an English image, then (because of <UILanguage>de-de</UILanguage>) Windows Deployment Services will look for a German language pack on the server at C:\RemoteInstall\Images\<imagefilename>\Langpacks\de-de. <?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="windowsPE"> <component name="Microsoft-Windows-Setup" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86"> <WindowsDeploymentServices> <Login> <WillShowUI>OnError</WillShowUI> <Credentials> <Username>Administrator</Username> <Domain>Fabrikam.com</Domain> <Password>Password1</Password> </Credentials> </Login> <ImageSelection> <WillShowUI>OnError</WillShowUI> 80 <InstallImage> <ImageName>Windows Vista Ultimate</ImageName> <ImageGroup>ImageGroup1</ImageGroup> </InstallImage> <InstallTo> <DiskID>0</DiskID> <PartitionID>1</PartitionID> </InstallTo> </ImageSelection> </WindowsDeploymentServices> <DiskConfiguration> <WillShowUI>OnError</WillShowUI> <Disk> <DiskID>0</DiskID> <WillWipeDisk>false</WillWipeDisk> <ModifyPartitions> <ModifyPartition> <Order>1</Order> <PartitionID>1</PartitionID> <Letter>C</Letter> <Label>Vista</Label> <Format>NTFS</Format> <Active>true</Active> <Extend>false</Extend> </ModifyPartition> </ModifyPartitions> </Disk> </DiskConfiguration> </component> <component name="Microsoft-Windows-International-Core-WinPE" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86"> <SetupUILanguage> <WillShowUI>OnError</WillShowUI> 81 <UILanguage>en-US</UILanguage> </SetupUILanguage> <UILanguage>de-de</UILanguage> <SystemLocale>de-de</SystemLocale> <UserLocale>de-de</UserLocale> </component> </settings> <cpi:offlineImage cpi:source="" xmlns:cpi="urn:schemas-microsoft-com:cpi" /> </unattend> Image Unattend Files for Windows Vista and Windows Server 2008 Example 1: Unsecure domain join This file sets the password for the computer to a dynamically generated and shared password, and joins the computer to a domain without credentials. The password will be inserted into this unattend file as the <MachinePassword> value in the <Identification> section. The attributes that define this domain join method are <UnsecureJoin>true</UnsecureJoin> and the MicrosoftWindows-Shell-Setup component. For more information about this method, see the “Ensuring Security” section of Automating the Domain Join. <?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="specialize"> <component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Identification> <UnsecureJoin>true</UnsecureJoin> </Identification> </component> 82 <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ProductKey>XXXX-XXXX-XXXX-XXXX-XXXX</ProductKey> </component> </settings> </unattend> Example 2: Secure domain join This example uses the credentials specified in this file (user name, domain, and password) to perform the domain join. The attributes that define this domain join method are <UnsecureJoin>false</UnsecureJoin>, <Credentials>, and the Microsoft-Windows-Shell-Setup component. During installation, Windows Deployment Services will retrieve the name of the prestaged account from Active Directory Domain Services (AD DS) and replace the %MACHINENAME% string with the actual computer name. For more information about this method, see the “Ensuring Security” section of Automating the Domain Join. <?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="specialize"> <component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Identification> <UnsecureJoin>false</UnsecureJoin> <Credentials> <Domain>Fabrikam.com</Domain> <Password>Password1</Password> <Username>MyUserName</Username> </Identification> </component> 83 <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ComputerName>%MACHINENAME%</ComputerName> </component> </settings> </unattend> Example 3: Using variables In the following example, Windows Deployment Services will automatically replace the %USERDOMAIN%, %USERPASSWORD%, %USERNAME%, and %MACHINEDOMAIN% variables using the proper values. For more information, see "Using Variables to Obtain Information From the Client" in Advanced Unattended Installation Scenarios. <?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="specialize"> <component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Identification> <Credentials> <Domain>%USERDOMAIN%</Domain> <Password>%USERPASSWORD%</Password> <Username>%USERNAME%</Username> </Credentials> <JoinDomain>%MACHINEDOMAIN%</JoinDomain> </Identification> </component> <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" 84 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ComputerName>%MACHINENAME%</ComputerName> </component> </settings> <settings pass="oobeSystem"> <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <UserAccounts> <DomainAccounts> <DomainAccountList wcm:action="add"> <Domain>%USERDOMAIN%</Domain> <DomainAccount wcm:action="add"> <Group>Administrators</Group> <Name>%USERNAME%</Name> </DomainAccount> </DomainAccountList> </DomainAccounts> </UserAccounts> <RegisteredOrganization>%ORGNAME%</RegisteredOrganization> </component> </settings> </unattend> Image Unattend Files for Older Operating Systems Example 1: Domain join The following is an example Sysprep.inf file that sets the password of the computer account to the computer name, and joins the computer to a domain without credentials. [Identification] DoOldStyleDomainJoin=Yes [Networking] [UserData] 85 Example 2: Using variables In the following Sysprep.inf example, Windows Deployment Services will automatically replace the %ORGNAME%, %MACHINENAME%, %TIMEZONE%, and %MACHINEDOMAIN% variables using the proper values. For more information, see "Using Variables to Obtain Information From the Client" in Advanced Unattended Installation Scenarios. [UserData] OrgName = "%ORGNAME%" ComputerName = %MACHINENAME% ProductKey= "XXXXX-XXXXX-XXXXX-XXXXX-XXXXX" [GuiUnattended] TimeZone = %TIMEZONE% [Networking] [Identification] JoinDomain = %MACHINEDOMAIN% DoOldStyleDomainJoin = Yes Example 3: Run a script The following is an example Sysprep.inf file that runs a script on first logon (Command0), sets the administrator password (AdminPassword), and bypasses the Welcome screen (AutoLogon). [GuiRunOnce] Command0 = "set path=c:\scripts;%PATH%" [GuiUnattended] AutoLogon = Yes AdminPassword = Password1! OEMSkipRegional = 1 OemSkipWelcome = 1 TimeZone = %TIMEZONE% 86 [Identification] JoinDomain = %MACHINEDOMAIN% DoOldStyleDomainJoin = Yes Combined Image and Client Unattend File The following is a single .xml unattend file that automates the entire installation process (the Windows Deployment Services client UI screens and the remaining phases of Setup). To use this file, update the file with information for your environment and then configure the command-line unattend precedence appropriately (for precedence information, see Advanced Unattended Installation Scenarios). Then pass this file to Setup.exe with the /unattend:<unattend file> option. <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="windowsPE"> <component name="Microsoft-Windows-Setup" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86"> <WindowsDeploymentServices> <Login> <WillShowUI>OnError</WillShowUI> <Credentials> <Username>Administrator</Username> <Domain>Fabrikam.com</Domain> <Password>Password1</Password> </Credentials> </Login> <ImageSelection> <InstallImage> <ImageName>Install Image</ImageName> <ImageGroup>defaultx86</ImageGroup> <Filename>install.wim</Filename> </InstallImage> <WillShowUI>OnError</WillShowUI> <InstallTo> <DiskID>0</DiskID> <PartitionID>1</PartitionID> </InstallTo> 87 </ImageSelection> </WindowsDeploymentServices> <DiskConfiguration> <WillShowUI>OnError</WillShowUI> <Disk> <DiskID>0</DiskID> <WillWipeDisk>false</WillWipeDisk> <ModifyPartitions> <ModifyPartition> <Order>1</Order> <PartitionID>1</PartitionID> <Letter>C</Letter> <Label>Vista</Label> <Format>NTFS</Format> <Active>true</Active> <Extend>false</Extend> </ModifyPartition> </ModifyPartitions> </Disk> </DiskConfiguration> </component> <component name="Microsoft-Windows-International-Core-WinPE" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86"> <SetupUILanguage> <WillShowUI>OnError</WillShowUI> <UILanguage>en-US</UILanguage> </SetupUILanguage> <UILanguage>en-US</UILanguage> </component> </settings> <settings pass="specialize"> 88 <component name="Microsoft-Windows-UnattendedJoin" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86"> <Identification> <UnsecureJoin>true</UnsecureJoin> </Identification> </component> <component name="Microsoft-Windows-Shell-Setup" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86"> <ComputerName>computer1</ComputerName> </component> <component name="Microsoft-Windows-TerminalServices-RDP-WinStationExtensions" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86"> <SecurityLayer>2</SecurityLayer> <UserAuthentication>2</UserAuthentication> </component> <component name="Microsoft-Windows-TerminalServices-LocalSessionManager" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86"> <fDenyTSConnections>false</fDenyTSConnections> </component> </settings> <settings pass="oobeSystem"> <component name="Microsoft-Windows-Shell-Setup" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86"> <OOBE> <HideEULAPage>true</HideEULAPage> <NetworkLocation>Work</NetworkLocation> <ProtectYourPC>1</ProtectYourPC> <SkipMachineOOBE>true</SkipMachineOOBE> <SkipUserOOBE>true</SkipUserOOBE> </OOBE> <Display> <ColorDepth>32</ColorDepth> 89 <DPI>96</DPI> <HorizontalResolution>1024</HorizontalResolution> <RefreshRate>60</RefreshRate> <VerticalResolution>768</VerticalResolution> </Display> <UserAccounts> <LocalAccounts> <LocalAccount> <Password> <Value>Password1</Value> <PlainText>true</PlainText> </Password> <Description>My Local Account</Description> <DisplayName>John Smith</DisplayName> <Group>Administrators;Power Users</Group> <Name>John</Name> </LocalAccount> </LocalAccounts> <DomainAccounts> <DomainAccountList> <DomainAccount> <Name>Administrator</Name> <Group>Administrators;Power Users</Group> </DomainAccount> <Domain>Fabrikam.com</Domain> </DomainAccountList> </DomainAccounts> </UserAccounts> </component> </settings> </unattend> 90 Image Capture Wizard Unattend File The following is an example file that automates the UI screens of the Image Capture Wizard. To use this file, first update each section with the information for your environment. For example, the [ExclusionList] specifies the files that the capture process will exclude from capturing. Then create a capture image and save this file within the image. To do this, mount the image using ImageX, save this file as Windows\system32\Wdscapture.inf (overwrite the existing Wdscapture.inf), and then unmount the image. Lastly, add the capture image to the Windows Deployment Services server. When you boot a computer into this image, the UI screens will be automated and the image will be uploaded to the server with the settings you have specified. [Capture] Unattended=Yes VolumeToCapture=C: SystemRoot=windows ImageName="WindowsVista" ImageDescription="Windows Vista ULTIMATE with Office" DestinationFile=C:\Capture.wim Overwrite=Yes [ExclusionList] $ntfs.log hiberfil.sys pagefile.sys "System Volume Information" RECYCLER winpepge.sys %SYSTEMROOT%\CSC [WDS] UploadToWDSServer=Yes WDSServerName=WDSServer WDSImageGroup="ImageGroup1" Username=Username Domain=Domain Password=Password1 DeleteLocalWimOnSuccess=No 91 Working with Images Creating Images Filtering Images Deploying Earlier Versions of Windows Storing and Replicating Images Using DFS Servicing Images Creating Images This topic contains information about the images that you use with Windows Deployment Services. In This Topic Image Types Boot Images Discover Images Capture Images Converting RIPREP Images Note To download the Windows Deployment Services documentation (including a getting started guide, deployment guide, and WDSUTIL command-line syntax), see http://go.microsoft.com/fwlink/?LinkId=89381. Image Types Windows Deployment Services uses two basic image types, both of which use the Windows Image (.wim) file format: Install image: The operating system image that you deploy to the client computer. Boot image: The Microsoft Windows Preinstallation Environment (Windows PE) image that you boot a client into before you install the install image. To install an operating system, you first boot the computer into the boot image, and then you select the install image to install. You can also create two additional types of boot images: Capture image: A type of boot image that you boot a client computer into to capture the operating system as a .wim file. You must first create a capture image when you are creating custom install images. 92 Discover image: A type of boot image that you can use to install an operating system on a computer that is not Pre-Boot Execution Environment (PXE) enabled. When you boot a computer into a discover image, the Windows Deployment Services client will locate a valid Windows Deployment Services server, and then you can choose the install image you want to install. Boot Images These images contain Windows PE and the Windows Deployment Services client, which is Windows Vista Setup.exe with some additional functionality needed for network deployments. In most cases, you should use the standard boot image that is included on the Windows Server 2008 media (located at \Sources\boot.wim) without modification. Do not use the Boot.wim from the Windows Vista media unless your version of Windows Vista has SP1 integrated into the DVD. If you use the Boot.wim from the version of Windows Vista that does not contain SP1, multicasting will not work correctly. Creating Custom Boot Images You can also use the tools in the Windows Automated Installation Kit (AIK) to create a custom boot image. For more information, see Windows PE Walkthroughs (http://go.microsoft.com/fwlink/?LinkId=120691). When creating boot images, ensure that the image is stored in .wim format, and it is marked as bootable from RAMDISK using the /boot option with ImageX. To create custom boot image, you must manually copy the Windows Vista or Windows Server 2008 Setup.exe binary files into the custom image. The process for doing this is as follows: 1. Create a top-level folder named Sources in the custom boot image. 2. Mount the boot image that is RAMDISK-bootable in the Boot.wim file (Boot.wim contains two Windows PE images, and the bootable image is the second image). 3. Copy all of the Setup.exe files from the \Sources folder in the mounted image to the \Sources folder in the custom boot image. In addition, you must ensure that the Windows Deployment Services client is started by Windows PE. To ensure that this occurs, create an entry in the WinPESHL.ini file to start Setup.exe in Windows Deployment Services mode. For more information, see “When Setup Is Started in Windows Deployment Services Mode” in How the Windows Deployment Services Client Works (http://go.microsoft.com/fwlink/?LinkID=147067). For more information about editing WinPESHL.ini, see Include a Custom Script in a Windows PE Image (http://go.microsoft.com/fwlink/?LinkId=120692). For information about managing and modifying the boot menu, see Managing the Boot Menu. Versions of Windows PE When creating custom boot images, the version of Windows PE that you use must match or be newer than the install image. For example, you can use Windows PE 2.1 to deploy install images 93 of all versions of Windows (including Windows Vista with SP1, Windows Server 2008, and all earlier versions of Windows). You cannot, however, use Windows PE 2.0 to deploy Windows Vista with SP1 or Windows Server 2008. If you are deploying Windows Server 2003 and your boot image does not contain the Windows Deployment Services client (for example, if you are booting a Windows PE 2005 boot image into the command prompt instead of into the user interface screens of the Windows Deployment Services client), we recommend that you use the latest version of Windows PE. You can use Windows PE 2004, Windows PE 2005, Windows PE 2.0, or Windows PE 2.1, although the following caveats apply: If you are applying a .wim image of Windows Server 2003 using ImageX, you can use either the x86 or x64 version of Windows PE. In the past, if you were running Winnt32.exe for Setup.exe, you could only use x64 versions of Windows PE, but that has changed. For details, see Knowledge Base article 931761 (http://go.microsoft.com/fwlink/?LinkID=110354). If you are using Windows PE 2.0, you might run into the issue documented at http://go.microsoft.com/fwlink/?LinkID=110354. In this scenario, run the command Bootsect.exe /nt52 c: to set up the correct NTFS file system boot sector. Discover Images Discover images are generally used in scenarios where the client cannot perform a PXE boot. These images enable a computer to locate a Windows Deployment Services server and use it to install an image. To create a discover image, right-click a boot image in the MMC snap-in, and then click Create discover boot image. In most cases, you should use the Boot.wim file included on the Windows Server 2008 DVD to create your image. For instructions, see the Windows Deployment Services Getting Started Guide.When you create a discover images, you configure one of the following: Static discovery. Static discovery is when you specify the server that the computer should use. Static discovery works well in data center environments or branch offices where DHCP may not be available. One major disadvantage of static discovery is that it introduces a single point of failure. For example, if the server that is specified is unavailable, the Windows Deployment Services client will not work, and there is no way to have the client try a different server. Another flaw is that static discovery does not allow for load balancing, because all clients using a particular boot image would use the specified server. You can specify the server when you create the discover image. Dynamic discovery. If you do not specify the server to use when you create a discover image, the Windows Deployment Services client will emulate a PXE request from within Windows PE. Based on the responses to that PXE request, the client can locate a valid server and continue the installation process. 94 Creating Custom Discover Images For advanced scenarios if you want to create a custom deployment, you can create a discover image by using the tools provided in the Windows AIK. For more information, see Windows PE Walkthroughs (http://go.microsoft.com/fwlink/?LinkId=120691). To create a discover image manually 1. In the boot image, create a temporary folder in the path pointed to by the environment variable, %TEMP%. 2. Copy the appropriate Setup.exe files from the \Sources folder in the boot image located on the Windows Server 2008 DVD (it is the second image in the Boot.wim file) to the temporary folder. 3. Create a Winpeshl.ini file in the Windows\System32 folder of the applied image with the following section. For more information about editing WinPESHL.ini, see Include a Custom Script in a Windows PE Image (http://go.microsoft.com/fwlink/?LinkId=120692). [LaunchApps] %SYSTEMROOT%\sources\setup.exe, "/wds /wdsdiscover" or [LaunchApps] %SYSTEMROOT%\sources\setup.exe, "/wds /wdsdiscover /wdsserver:<server>" See the following table for more information about these options. 4. Capture the modified image into a new .wim file. 5. Update the image metadata to reflect any changes to the image name or description. There are two command-line options for Setup.exe that control the discovery behavior of the Windows Deployment Services client. These options are described in the following table. Option Description /WDSDiscover (Default) Specifies that the Windows Deployment Services client should be in discover mode. If you do not specify /WDSServer with this option, Windows Deployment Services will search for a server. For example, to start the Windows Deployment Services client in this dynamic discover mode, run the command \sources\setup.exe /wds /WDSDiscover. /WDSServer:<Server Specifies the name of the Windows Deployment Services server that the Name> client should connect to. Note that <ServerName> can be an IP address, a NetBIOS name, or a fully qualified domain name (FQDN). You must also specify /WDSDiscover. For example, to start the Windows Deployment Services client in this static discover mode, run the command \sources\setup.exe /wds /WDSDiscover /WDSServer:MyWDSServer. 95 Capture Images Capture images are boot images that contain Windows PE and the Windows Deployment Services Image Capture Wizard. When you boot a computer (that has been prepared with Sysprep) into a capture image, the wizard creates an install image of the computer and saves it as a .wim file. Then you can upload the image to the Windows Deployment Services server or copy them to bootable media (CD, DVD, USB drive, and so on). You create capture images from existing boot images — most commonly, the Boot.wim file from the installation media. For instructions on creating these images, see the Windows Deployment Services Getting Started Guide. For information about automating the wizard, see Automating the Image Capture Wizard. Regardless of which tool you use (capture images or ImageX), the high-level process for capturing images remains essentially the same: 1. Install Windows on a reference computer. 2. Perform customizations and install software. 3. Run the correct version of Sysprep for the reference computer's operating system. 4. Reboot into Windows PE. 5. Capture the offline Sysprep image into .wim format. 6. Upload the image to the Windows Deployment Services server’s image store. Comparison of ImageX and Image Capture Wizard Capture images provide a subset of the functionality included in the ImageX /capture command. For information, see ImageX Technical Reference (http://go.microsoft.com/fwlink/?LinkId=120693). The following table compares these two tools. Functionality Image Capture ImageX Wizard Captures a partial volume? No Yes Captures an image that has not been prepared by using Sysprep? No Yes Uploads directly to the Windows Deployment Services server? Yes No Can the process be automated? Yes Yes Has a GUI? Yes No Provides additional functionality beyond image capture? No Yes Enables me to specify a capture exclusion list? Yes Yes Captures directly to a network location without making a local image copy? No Yes 96 Creating Custom Capture Images In advanced scenarios, you can create a custom capture image. To create a capture image manually 1. Create a temporary folder in the path that is pointed to by the environment variable, %TEMP%. 2. Apply the contents of the source boot image from the Windows Deployment Services server’s image store to the \Temp folder. 3. Create a Winpeshl.ini file in the Windows\System32 folder of the applied image with the following section: [LaunchApps] %SYSTEMROOT%\system32\wdscapture.exe 4. Capture the modified image into a new .wim file. 5. Update the image metadata to reflect any changes to the image name or description. Converting RIPREP Images To convert RIPREP images, you must first upgrade your server to Windows Server 2008. For instructions, see http://go.microsoft.com/fwlink/?LinkId=84628 Default Conversion To convert your files, right-click the RIPREP image you want to convert in the Legacy Images node, and then click Convert to WIM. The default conversion process copies the updated version of a file to another location. There were two main factors that influenced this design decision: The original image remains unmodified, in case the conversion process fails or you want to continue to use the original RIPREP image after the conversion process is run. In RIS, you could associate multiple unattended setup installation files (.sif) with a particular image. If an image is so configured, a conversion process that is run for one .sif file would alter the backing files used by the other .sif file. The conversion process requires at least twice as much free disk space as the size of the image. This space is needed for a copy of the RIPREP image placed in the %TEMP% folder and the .wim file that was created by using the contents of the converted image in the %TEMP% folder. Note that the data in the %TEMP% folder can be removed only after the new image has been captured. In-Place Conversion You can force an in-place conversion of a RIPREP image, which will save time and the amount of disk space that you use during the conversion process. You can do this by using the /InPlace option with the WDSUTIL /Convert-RiprepImage command. It is common for multiple variations 97 of a single RIPREP image (differing only by HAL type) to exist on a server. You can save time during the conversion process by using the /Overwrite:Append option of the WDSUTIL /Convert-RiprepImage command to take advantage of single-instancing technology within the .wim format. For instructions, see the "Install Images" section in How to Manage Images. The append operation is much faster than a traditional capture because it does not need to compress and insert files that already exist in the .wim file. Files that are identical between images and that already exist within the .wim file will simply have their reference count incremented to indicate that the single file belongs to multiple images within the .wim file. The general conversion process entails first converting the first RIPREP image in the set by creating a new .wim file, and then converting the remaining RIPREP images (for the other HAL types) by appending them to the .wim file you created previously. Deploying Earlier Versions of Windows You can use Windows Deployment Services to deploy Windows Vista as well as earlier Windows operating systems such as Windows XP and Windows Server 2003. To do this, you use Sysprep to prepare the operating system, and then use a capture image to save the image in the Windows image (.wim) file format. Note that Windows Deployment Services does not recognize that the image contains an earlier operating system until the image is selected on the image selection page. When the image is selected, the image's metadata specifies the exact version of the operating system. Although Windows Deployment Services provides full functionality for applying images for Windows Vista, note the following limitations when deploying the images of earlier Windows operating systems: Sysprep must be applied to the first primary partition: Earlier operating system images that have been prepared with Sysprep must be applied to the first primary partition (for example, C:\). Applying these images to other partitions is not supported. The HAL must match: Earlier operating system images are hardware abstraction layer (HAL)-specific, meaning that they can be applied only to computers that have a matching HAL type. Therefore, Windows Deployment Services detects the local computer's HAL type and filters out images that are earlier than Windows Vista and that are not of that same HAL type. For example, if there are two images on the Windows Deployment Services server that the client has permissions to (one ACPI and the other APIC) and the client computer is ACPI, only the ACPI image will be available. This is true in both attended and unattended installation scenarios. Note that the HAL type of an image is stored in the .wim image metadata: <HAL>acpiapic</HAL> External language packs do not apply: When you are applying these images, the concept of external language packs does not apply. The language selection drop-down list on the image selection page will not let you select an additional language. Additionally, if you specify a language, locale, and keyboard layout in the Windows Deployment Services client user interface (or if you using an unattend file) the settings you specified will not be used in the 98 image that gets applied. This is because Windows Deployment Services does not support modifications to offline images older than Windows Vista that would be necessary for this functionality. You cannot apply a driver to an offline image (by using the F6 key or load driver functionality) . The API set you use to perform offline driver injection is supported only for Windows Vista images. The Boot.ini file must exist in the image: Rather than Setup generating a Boot.ini file when deploying an operating system earlier than Windows Vista, Boot.ini must already exist in the image. This is currently the default behavior of most image-based deployments, including those involving ImageX. To ensure that the Boot.ini file is included with the image 1. Deploy the image of the earlier operating system to a reference computer. 2. Use Sysprep to prepare the image. 3. Capture the image of reference computer, including the Boot.ini file. 4. Deploy the image by using Windows Deployment Services. When the image is applied, the Boot.ini file included in that image will be copied as well. Filtering Images You can restrict which install images are shown to users. These restrictions can be policy-based or enforced by the computer. Automatic Filtering by Windows Deployment Services Windows Deployment Services filters the images in the image selection page to avoid situations where a user is allowed to install an image that is not compatible. Images are filtered by hardware abstraction layer (HAL) and architecture. For Windows Vista or Windows Server 2008 images, HAL filtering is not necessary because the image contains all possible HALs (and the correct HAL is detected and put in place automatically upon first boot). If the image is of an older operating system, Windows Deployment Services will compare the HAL type (as specified in the metadata for the .wim file) to that of the destination computer. If the HAL types are identical, the image will be shown to the user. If the HAL types do not match, the image will not be displayed. The HAL information about the image is stored in the image metadata in the <HAL> section of the .wim file. Architecture filtering works as follows. For x86-based computers, you use only x86-based boot images and x86-based install images. The images that are applicable to that architecture will be 99 filtered automatically. In Windows Server 2008, however, there is new functionality that controls how images are filtered to users on x64-based computers. When you boot into the Boot.wim file that is included on the x86 version of Windows Server 2008 media from an x64-based computer, you will be able to choose from both x86-based and x64-based install images. However, if you boot into an x64-based Boot.wim file from the same computer, only x64-based boot images will be displayed. Filtering Images Manually You can specify permissions to allow only certain users rights to see a particular install image. To set permissions, right-click the image (either in the MMC snap-in or in the RemoteInstall folder), and then click Properties. It is not possible to specify permissions for different users for images within the same image group. For example, if you have two images, ImageA and ImageB, and you would like User1 to have access to ImageA and User2 to have access to ImageB, you must have each image stored in a separate .wim file. Note that setting these permissions sets the permissions on the .wim file (which contains only metadata), but not the Res.rwm file (which contains the file resources for the image). In order to secure the Res.rwm, you must create an ACL for the file. However we do not recommend this because if the permission sets differ for the files, a user could have permissions to view the .wim, but not the Res.rwm, and therefore the installation would fail. Servicing Images In This Topic Types of Servicing Servicing an Image Offline Reducing the Size of Images Types of Servicing Servicing images means updating an image that is currently available to users — for example, adding an update to your existing image. There are two types of image servicing: Offline. In the context of updating images, the term "offline" refers to updating or applying changes to an operating system image that is not currently running. For example, you might update a .wim file with security updates by using ImageX, while it sits in a folder structure or another partition. Online. In the context of updating images, the term "online" refers to updating or applying changes to an operating system that the computer is booted into. For example, installing an update by using Windows Update is an online operation. 100 Windows Vista supports offline servicing of images that have been prepared with Sysprep, whereas earlier versions of Windows do not. You can service an image offline with Package Manager or on a running Windows operating system with OCSetup, Package Manager, or the Windows Update Standalone Installer. Package Manager works only with operating system packages (hotfixes, updates, drivers, service packs, and language packs). All of these are command-line tools can install and uninstall packages. Service packs and other updates that are delivered as .msu files must be installed online on a running Windows installation with the Windows Update Standalone Installer. For more information, see Servicing an Image (http://go.microsoft.com/fwlink/?LinkId=122507). Servicing an Image Offline The following are the four high-level steps you will need to perform to service an image offline. 1. Disable the current image. To do this, right-click the image and click Disable. This allows currently connected clients to finish applying the image, but it prevents new clients from starting an installation. 2. Export the image to a location outside of the image store. To do this, right-click the image and click Export. For install images, this combines the metadata in the install.wim file with the resources in the Res.rwm file into a single .wim file and saves it to the destination location. To save space, you can also use the WDSUTIL /Export-Image command to append the images to an existing .wim file. This is also generally faster than exporting it to a new .wim file. For more information about this command, see /export-Image. 3. Service the image. In this step, you update the image using the tools in the Windows AIK. For example, you can mount the image to a folder by using ImageX, and then add the files and folders to the image. You can also load the registry hive to add, delete, or modify registry keys. If the image is a boot image, you can use PEimg.exe to add drivers to the image. After all your changes are complete, use ImageX to commit the changes to the .wim. For more information, see the following topics: Phase 5: Image Maintenance (http://go.microsoft.com/fwlink/?LinkId=120703) Package Manager Technical Reference (http://go.microsoft.com/fwlink/?LinkId=120704) Add Device Drivers to an Offline Windows Image (http://go.microsoft.com/fwlink/?LinkId=120705) Install a Language Pack to an Offline Image (http://go.microsoft.com/fwlink/?LinkID=120685) 4. Replace the current image with the updated version. In this step, you add the updated image back to the Windows Deployment Services server. If the previous image is still in use, you have two options: Wait for existing installations to complete, delete the old copy, and then replace it with the new. To do this, right-click the image and click Replace. We recommend this method because any associated external data such as language packs, unattend files, or $OEM$ folder contents will remain associated with the image. 101 Add the updated image as a new, separate image. You must also copy or associate any external data such as language packs, unattend files, or $OEM$ folder contents. Sometimes it may be more efficient to redeploy and recapture an image to add applications, rather than servicing the image offline. Reducing the Size of Images An image group is a collection of images that share common file resources and security. The following are the two components of an image group: Res.rwm file: Contains the file resources for each image group. Image.wim files: Contains the metadata that describes the content of the install image. Because the images are stored this way, removing an image from an image group does not reduce the size of the files. This is because files in the Res.rwm file that no longer belong to an image are not actually converted to free space; rather, they are just dereferenced. To reclaim free space within the Res.rwm file, you must perform the following steps: 1. Export all images from the image group to an external .wim file. 2. Create a new image group. 3. Add all exported images to the new group. When performing this procedure, you must manually copy and reassociate any external data (such as language packs and unattend files) to the new image group. Storing and Replicating Images Using DFS This section outlines the tools and topology configurations associated with the Distributed File System (DFS) role service in the File Services server role of Windows Server 2008. You may have to update your Active Directory Domain Services (AD DS) schema to use DFS to manage multiple Windows Deployment Services servers. Any issues pertaining to AD DS, updates to an AD DS schema, and AD DS maintenance and best practices are outside the scope of this document. For more information about DFS, see: Distributed File Systems Step-By-Step Guide (http://go.microsoft.com/fwlink/?LinkId=111021) Distributed File System (http://go.microsoft.com/fwlink/?LinkId=108012) Storing Files on Another Server You can store install images on another server (not a Windows Deployment Services server) using DFS and still install the images by using Windows Deployment Services. Using DFS for install images provides two main benefits: Load balancing. Clients can be directed to computers other than the Windows Deployment Services server to download the image. 102 Simplified administration. When you use DFS replication technology, you can modify images on a single server and propagate changes to other distribution points. Note You cannot redirect the boot directory (that is, \\<server>\reminst\boot) using DFS. If you do, Windows Deployment Services will not start. To configure DFS namespaces for install images: 1. Install and configure Windows Deployment Services. 2. Install the DFS role service from the File Services server role in Server Manager. For more information about DFS, see Distributed File System (http://go.microsoft.com/fwlink/?LinkId=108012) 3. Create a file share on a secondary server. Grant permissions to the Windows Deployment Services server’s computer account. For example, if the server is called MyWDSServer, grant read/write permissions to MyWDSServer$. 4. Create a new namespace in DFS Management. For example, \\fileserver\MyNamespace for a stand-alone namespace or \\corp.woodgrovebank.com\MyNamespace for a domainbased namespace. 5. Add a new folder to the namespace and create an image group on the Windows Deployment Services server as the target folder. For example, create \\MyServerOrDomain\MyNamespace\ImageGroup in DFS Namespaces, and specify \\MyWDSServer\RemoteInstall\images\DFSImageGroupName as a target folder for that folder. 6. Add images to the Windows Deployment Services server. 7. Verify that the content appears when you connect to \\MyServerOrDomain\MyNamespace\ImageGroup. 8. Repeat this procedure for additional image groups. Replicating Images DFS Replication is a server technology that you can use to replicate images between Windows Deployment Services servers. DFS Replication can decrease the total cost of ownership by making it possible for you to manage images from a single server in the environment. Changes can then be propagated to other servers without requiring interaction. A best practice is to create a single, master Windows Deployment Services server that clients do not connect to. Make all modifications to images on this server by using the Windows Deployment Services management tools and the image maintenance tools included in the Windows AIK. Next, replicate changes from this server to other servers in the topology. To prevent replication conflicts, avoid modifying or servicing the same image from multiple servers at the same time. For more information, see Distributed File System Replication: Frequently Asked Questions (http://go.microsoft.com/fwlink/?LinkId=111023). 103 To configure DFS Replication for install images: 1. Install and configure Windows Deployment Services. 2. Install the DFS role service from the File Services server role in Server Manager. For more information, see Distributed File Systems Step-By-Step Guide (http://go.microsoft.com/fwlink/?LinkID=111021) 3. Create and configure a replication group for the RemoteInstall folder or its subfolders. If you are replicating RemoteInstall subfolders, you must exclude the \Mgmt and \Tmp folders. These folders contain server-specific information that cannot be used by remote Windows Deployment Services servers. 4. Configure the BCD refresh policy by running the following command (see below for details about the options): WDSUTIL /set-server /BcdRefreshPolicy /Enabled:yes /RefreshPeriod:<time in minutes> Option Explanation /BcdRefreshPolicy Causes the server to regenerate BCD stores in the \Tmp folder for all boot images. /RefreshPeriod Determines how often the boot images are regenerated. This value is required so that any changes that you make to your boot images on the master server are reflected in the boot menus that clients receive from remote servers. If you do not make changes to boot images very often, it is okay to have a larger value. If you make changes to boot images often or if you want changes to propagate quickly, set this to a lower value. However, be careful when setting a low value. BCD generation causes CPU and disk overhead on the Windows Deployment Services server. Configuring a small value can cause performance problems on the server. A good default value is 30 minutes. How to Perform Common Tasks This topic contains procedures for performing common tasks using Windows Deployment Services MMC snap-in. and the WDSUTIL command line tool. The management tasks that you can perform with these tools fall into the following categories: Category Example tasks How to Manage Your Server Initialize and uninitialize a server View configuration information about the server Start/stop or enable/disable a server 104 Category Example tasks Update the RemoteInstall folder Set advanced server settings Create and delete prestaged accounts in Active Directory Domain Services (AD DS) View information about prestaged computers Configure settings for prestaged computers Reject/approve pending computers View information about images and image groups Create images Add, copy, export, remove, update images from the image store Set attributes and associate unattend files for install images. Convert RIPREP images Add and remove image groups Set attributes of an image group How to Create Multicast Transmissions Create multicast transmissions Manage multicast transmissions How to Modify the BCD Store Using Bcdedit To view the contents of the BCD store To configure the default selection time-out value To configure a localized boot manager experience To configure the TFTP block size and window size To configure Windows debugger options How to Manage Client Computers How to Manage Images How to Manage Your Server This section contains procedures for the tasks that are listed and described in the following table. Note that you cannot manage a Windows Deployment Services server running Windows Server 2008 from a Windows Deployment Services server running Windows Server 2003. Note To download the Windows Deployment Services documentation (including a getting started guide, deployment guide, and WDSUTIL command-line syntax), see http://go.microsoft.com/fwlink/?LinkId=89381. 105 Note Help for WDSUTIL is available by typing WDSUTIL /? at a command prompt or online at http://go.microsoft.com/fwlink/?LinkId=112194. Type Procedure General Tasks To configure Windows Deployment Services To start or stop the server To enable the server To enable logging for the Windows Deployment Services client To choose the port number for RPC To specify the network interfaces for Windows Deployment Services to listen on To configure how often the server refreshes its settings To force the server to update files in the RemoteInstall folder To configure the network profile for the server To back up the server data To configure Windows Deployment Services to run on the same computer as Microsoft DHCP To configure Windows Deployment Services to run on the same computer as non-Microsoft DHCP To turn on the DHCP authorization requirement To authorize the server in DHCP To configure the server to answer clients To set a delay in the server’s answers to PXE requests To configure unknown clients to perform PXE boots without requiring F12 To configure clients who have booted without F12 to require a key press on subsequent boots To configure the server to determine the architecture of booting clients To choose which boot images are displayed on x64-based computers To choose the default network boot program for each architecture To choose the default network boot program that does not require F12 for each architecture To choose the default boot image for each architecture To specify a domain controller for Windows Deployment Services To specify a global catalog server for Windows Deployment Services To choose whether to search for computer accounts in the domain DHCP Client Requests Client Boot Settings Active Directory Domain Services 106 Type Procedure controller before searching the global catalog Unattend File To configure the server to prestage clients by using their MAC address instead of their GUID To maintain a list of GUIDs that belong to multiple computers To specify how to generate client computer names To specify the domain and OU in which to create client computer accounts To choose whether to join client computers to the domain To choose a default unattend file for the Windows Deployment Services client To specify whether an unattend file on the client computer overrides the default unattend file General Tasks To configure Windows Deployment Services Using the MMC Using WDSUTIL 1. Install Windows Deployment Services. For more information, see the Windows Deployment Services Getting Started Guide. 1. Install Windows Deployment Services. For more information, see the Windows Deployment Services Getting Started Guide. 2. Click Start, click Administrative Tools, and then click Windows Deployment Services. 2. Click Start, right-click Command Prompt, click Run as administrator, and then run 3. In the left pane of the Windows Deployment Services snap-in, right-click the server and then click Configure Server. WDSUTIL /Verbose /Progress /InitializeServer /RemInst:<path>, where <path> is the path where you would like the RemoteInstall folder to be located. 4. Follow the instructions in the wizard. The preceding procedure does the following: 1. Creates the folder tree for RemoteInstall. 2. Creates the RemoteInstall folder with the following default permissions: Authenticated Users = Read and Execute, System = Full Control, Administrators = Full Control, and WDSServer service = Full Control 3. Installs the server files (boot files) from the \system32\reminst folder (as placed during component installation) to the new folder structure. 107 4. Updates the service parameters. 5. Sets the Trivial File Transfer Protocol (TFTP) root to point to the RemoteInstall folder root. 6. Sets the WDSServer service startup type to Auto. 7. Optionally authorizes the server in Dynamic Host Control Protocol (DHCP). 8. Starts the services. To start or stop the server Using the MMC Using WDSUTIL 1. Right-click the server, and then click All Tasks. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Click Stop Server or Start Server. 2. Run WDSUTIL /Start-Server or WDSUTIL /Stop-Server. The preceding procedure starts or stops the WDSServer service. To enable the server Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Enable-Server. The preceding procedure starts or stops the WDSServer service. To enable logging for the Windows Deployment Services client Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. To turn on client logging, run WDSUTIL /Set-Server /WDSClientLogging /Enabled:Yes. 3. To change which events are logged, run WDSUTIL /Set-Server /WDSClientLogging /LoggingLevel:{None|Errors|Warnings|Info} (each category includes all events from the previous categories). 108 The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WdsI mgSrv\ClientLogging\Enabled to 1. The level is stored at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WdsI mgSrv\ClientLogging\LogLevel, where 0 is None; 1 is Errors only; 2 is Errors and Warnings; and 3 is Errors, Warnings, and Information. To choose the port number for RPCs Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Server /RPCPort:X, where X is the RPC port number you want to use. 3. You must restart the service before the changes will take effect. To do this, run wdsutil /stop-server and then run wdsutil /start-server. The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Parameters\Rp cPort to the specified value. Note If this remote procedure call (RPC) port is changed from the default value, you must add a firewall exception for the new RPC port. To specify the network interfaces for Windows Deployment Services to listen on Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Do one of the following: To add an interface to the list, run WDSUTIL /Set-Server /BindPolicy /Add /Address:<IP or MAC address> /AddressType:{IP|MAC}. To bind to only the interfaces on the list, run WDSUTIL /Set-Server /BindPolicy /Policy:Include. To bind to all interfaces other than those on the list, run WDSUTIL /SetServer /BindPolicy /Policy:Exclude. 109 The preceding procedure sets HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSServer\Providers\WDSP XE\BindPolicy to 0 to exclude the list, and sets it to 1 to include the list (and excludes all other interfaces). The list is stored in the following key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSServer\Providers\WDSP XE\BindInterfaces (addresses are stored as MAC=XXXXXXXXXXXX or IP=10.10.2.2) To configure how often the server refreshes its settings Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Server /RefreshPeriod:<time in seconds>. The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Parameters\Up dateTime to the specified value. To force the server to update files in the RemoteInstall folder Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Update-ServerFiles. To configure the network profile for the server Using the MMC Using WDSUTIL 1. Right-click the server, and then click Properties. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. On the Network Settings tab under Network Profile, select the option that specifies the network speed of your organization. 2. Run WDSUTIL /Set-Server [/Server:<name>] /Transport /Profile:{10Mbps|100Mbps|1Gbps|Custom}. Select Custom if you want to customize the settings yourself by editing the following registry key: 110 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\Multi cast\Profiles\Custom Important You should not modify the other profiles that are provided. Instead, you should create a custom profile even if you want to change only one setting. To back up the server data To completely back up your server, you must back up the following two sets of data: Images stored in the \RemoteInstall folder. To back up images, you must perform regular backups of the \RemoteInstall folder. You can restore the content from these backups without any special qualifications. The exception to this is if your server contains Remote Installation Services (RIS) images that have been groveled by Single Instance Storage (SIS). For more information about how to restore a volume that is managed by SIS, see article 263027 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=81026). Settings generally stored in the server’s registry. To back up these settings, we recommend that you perform regular backups by using the Microsoft Volume Shadow Copy Service (http://go.microsoft.com/fwlink/?LinkId=105509). As an alternative, you can regularly archive the server's configuration settings by running the command WDSUTIL /get-server /show:config. However, if you must restore the settings, you must manually reconfigure the settings by using WDSUTIL. DHCP To configure Windows Deployment Services to run on the same computer as Microsoft DHCP Using the MMC Using WDSUTIL 1. Right-click the server, and then click Properties. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. On the DHCP tab, select Do not listen on port 67 and Configure DHCP Option #60 Tag to PXEClient. 2. Run WDSUTIL /Set-Server /UseDHCPPorts:No /DHCPOption60:Yes. The preceding procedure does the following: Sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Parameters \UseDhcpPorts to 0. Adds the option 60 PXEClient tag to all of your DHCP scopes. 111 To configure Windows Deployment Services to run on the same computer as non-Microsoft DHCP Using the MMC Using WDSUTIL 1. Right-click the server, and then click Properties. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. On the DHCP tab, select Do not listen on port 67. 2. Run WDSUTIL /Set-Server /UseDHCPPorts:No. 3. Use your DHCP server tools to set the option 60 tag to PXEClient. 3. Use your DHCP server tools to set the option 60 tag to PXEClient. The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Parameters\Us eDhcpPorts to 0. To turn on the DHCP authorization requirement Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Server /RogueDetection:Yes. The preceding procedure sets HKEY_LOCAL_MACHINE\System\CurrentControlSet\WDSServer\Providers\WDSPXE\Disab leRogueDetection to 0. To authorize the server in DHCP Using the MMC Using WDSUTIL 1. Ensure that you are a domain administrator in the root domain of the forest or an enterprise administrator. For information about delegating permissions, see “Authorizing a Server” in the Configuring DHCP topic. 1. Ensure that you are a domain administrator in the root domain of the forest or an enterprise administrator. For information about delegating permissions, see “Authorizing a Server” in the Configuring DHCP topic. 2. Right-click the server, and then click Properties. 3. On the Advanced tab, select Authorize the Windows Deployment Server in DHCP. 2. Click Start, right-click Command Prompt, and click Run as administrator. 3. Run WDSUTIL /Set-Server /Authorize:Yes. 112 The preceding procedure creates an entry for DHCP authorization under the CN-NetServices, CN=Services, CN=Configuration, DC=Domain, DC=com object in AD DS. Client Requests To configure the server to answer clients Using the MMC Using WDSUTIL 1. Right-click the server, and then click Properties. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. On the PXE Response Settings tab, do one of the following: 2. Do one of the following: To respond to all client PXE requests, select Respond to all (known and unknown) client computers. To respond to all clients’ PXE requests, run WDSUTIL /Set-Server /AnswerClients:All. To respond only to prestaged client PXE requests, select Respond only to the known client computers. To respond only to prestaged clients’ PXE requests, run WDSUTIL To not answer any client PXE requests, select Do not respond to any client computer. Note that this option will only work if Windows Deployment Services and DHCP are running on different servers. This is because although Windows Deployment Services will not respond, DHCP will. You can try to work around this issue by disabling DHCP Option 60 on the DHCP tab. /Set-Server /AnswerClients:Known. To not answer any clients’ PXE requests, run WDSUTIL /Set-Server /AnswerClients:None. The preceding procedure does the following: When the Respond to all (known and unknown) client computers check box is selected, the netbootAnswerRequests DS attribute is set to TRUE and the netbootAnswerOnlyValidClients DS attribute is set to FALSE. When the Respond only to the known client computers check box is selected, both attributes are set to TRUE. When the Do not respond to any client computer check box is selected, both attributes are set to FALSE. 113 To set a delay in the server’s answers to PXE requests Using the MMC Using WDSUTIL 1. Right-click the server, and then click Properties. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. On the PXE Response Settings tab, set the PXE Response delay in the control. 2. Run WDSUTIL /Set-Server /ResponseDelay:X, where X is the amount of time (in seconds) you want the server to wait before responding to clients. The preceding procedure sets the value of HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSServer\Providers\WDSP XE\Providers\BINLSVC\ResponseDelay to the specified time. To configure unknown clients to perform PXE boots without requiring F12 Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Server /AllowN12ForNewClients:Yes. The preceding procedure sets the value of HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSServer\Providers\WDSP XE\Providers\BINLSVC\AllowN12ForNewClients to 1. To configure clients who have booted without F12 to require a key press on subsequent boots Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Server /ResetBootProgram:Yes. The preceding procedure sets the value of HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSServer\Providers\WDSP XE\Providers\BINLSVC\ResetBootProgram to 1. 114 To configure the server to determine the architecture of booting clients Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Server /ArchitectureDiscovery:Yes. The preceding procedure sets the value of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS PXE\Providers\BINLSVC\DisableArchDisc to 0. Client Boot Settings To choose which boot images are displayed on x64-based computers Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Server /DefaultX86X64ImageType:<x86|x64|both>. The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS PXE\Providers\BINLSVC\x86x64DefaultImageType to 1 for x86-based computers only, 2 for x64-based computers only, and 0 for both types of computers. To choose the default network boot program for each architecture Using the MMC Using WDSUTIL 1. Right-click the server, and then click Properties. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. On the Boot tab, insert the path to the boot file you want to use for each architecture. For a list of network boot programs, see Managing Network Boot Programs. 2. Run WDSUTIL /Set-Server /BootProgram:<path> /Architecture:{x86|x64|ia64}, where <path> is relative to the RemoteInstall folder. 115 The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS PXE\Providers\BINLSVC\BootPrograms\<arch>\Default to the specified path. To choose the default network boot program that does not require F12 for each architecture Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Server /N12BootProgram:<path> /Architecture:{x86|x64|ia64}, where <path> is relative to the RemoteInstall folder. The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS PXE\Providers\BINLSVC\BootPrograms\<arch>\N12 to the specified path. To choose the default boot image for each architecture Using the MMC Using WDSUTIL 1. Right-click the server, and then click Properties. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. On the Boot tab, insert the path to the boot image you want to use for each architecture. In most cases, you should use the standard boot image that is included on the Windows Server 2008 media (located at \Sources\boot.wim) without modification. Do not use the Boot.wim from the Windows Vista media unless your version of Windows Vista has SP1 integrated into the DVD. 2. Run WDSUTIL /Set-Server /BootImage:<path> /Architecture:{x86|x64|i a64}, where <path> is relative to the RemoteInstall folder. The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS PXE\Providers\BINLSVC\BootImages\<arch>\BootImagePath to the specified path. 116 Active Directory Domain Services To specify a domain controller for Windows Deployment Services Using the MMC Using WDSUTIL 1. Right-click the server, and then click Properties. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. On the Advanced tab, click Let Windows Deployment Services use only the specified servers, and then enter the domain controller name. 2. Run WDSUTIL /Set-Server /PreferredDC:<name>, where <name> is a NetBIOS name or fully qualified domain name (FQDN). The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS PXE\Providers\BINLSVC\DefaultServer to the specified name. To specify a global catalog server for Windows Deployment Services Using the MMC Using WDSUTIL 1. Right-click the server, and then click Properties. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. On the Advanced tab, click Let Windows Deployment Services use only the specified servers and then enter the Domain controller name. 2. Run WDSUTIL /Set-Server /PreferredGC:<name>, where <name> is a NetBIOS name or FQDN. The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS PXE\Providers\BINLSVC\DefaultGCServer to the specified name. To choose whether to search for computer accounts in the domain controller before searching the global catalog Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 117 Using the MMC Using WDSUTIL 2. Do one of the following: To search in the domain controller before searching the Global Catalog server, run WDSUTIL /Set-Server /DomainSearchOrder:DCFirst To search only in the Global Catalog server, run WDSUTIL /Set-Server /DomainSearchOrder:GCOnly In the preceding procedure: DCFirst sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\ WDSPXE\Providers\BINLSVC\ADSearchOrder to 1 GCOnly sets it to 0. To configure the server to prestage clients by using their MAC address instead of their GUID Using the MMC Using WDSUTIL N/A 3. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Server /PrestageUsingMAC:Yes. The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS PXE\Providers\BINLSVC\ClientIdUse to 1. To maintain a list of GUIDs that belong to multiple computers Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Do one of the following: To add a GUID to the list, run WDSUTIL /Set-Server /BannedGUIDPolicy /Add /GUID:<GUID>. To remove a GUID from the list, run WDSUTIL /Set-Server /BannedGUIDPolicy /Remove /GUID:<GUID>. Note The GUID string should be specified without brackets or dashes (as seen during a PXE boot). 118 The list of banned GUIDs list will be stored at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS PXE. To specify how to generate computer names Using the MMC Using WDSUTIL 1. Right-click the server, and then click Properties. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. On the Directory Services tab, enter the naming policy string in the indicated field (see below for details). 2. Run WDSUTIL /Set-Server where <policy> is the naming policy string (see below for details). /NewMachineNamingPolicy:<Policy> The policy string works as follows: %First: the first name of the user. %Last: the last name of the user. %Username: the user name of the user. %MAC: the MAC address of the computer. %n#: an incremental n-digit number. For example, %2# will add a number to the computer name in the following order: 1,2,3,…99. %0n#: an incremental n-digit number, with zeros added before the digit. For example, %02# will add a number to the computer name in the following order: 01,02,03,…99. These can be combined in any order. A number before a tag string (such as %3First or %5Username) will crop the string to that length. For example: %61Username%# equals JohnSmi12 %2first.%last equals Jo.Smith The preceding procedure sets the netbootNewMachineNamingPolicy DS attribute to the specified policy. To specify the domain and OU in which to create computer accounts 119 Using the MMC Using WDSUTIL 1. Right-click the server, and then click Properties. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. On the Directory Services tab, click Default Directory Service location or specify the domain and organizational unit (OU) 2. Do one of the following: To create new accounts in the default computer OU in the domain the Windows Deployment Services server is in, run WDSUTIL /Set-Server /NewMachineOU /Type:ServerDomain. To create new accounts in the default computer OU in the domain the specified user account is in, run WDSUTIL /SetServer /NewMachineOU /Type:UserDomain. To create new accounts in the same OU as the specified user account, run WDSUTIL /Set-Server /NewMachineOU /Type:UserOU. To create new accounts in a different OU, run WDSUTIL /Set-Server /NewMachineOU /Type:Custom /OU:<name of OU>. The preceding procedure does the following: Sets the netbootNewMachineOU attribute on the Service Control Point (SCP) for the Windows Deployment Services server to the distinguished name of the server Sets the NewMachineOUType registry key to 1 Sets the NewMachineOUType registry key to 0 Sets the netbootNewMachineOU attribute on the SCP for the Windows Deployment Services server to the specified distinguished name To choose whether to join client computers to the domain Using the MMC Using WDSUTIL 1. Right-click the server, and then click Properties. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. On the Client tab, clear the Do not create account in Active Directory after running the WDS Client check box to join computers to the domain. 2. To join new computers to the domain, run WDSUTIL /Set-Server /NewMachineDomainJoin:Yes. The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS PXE\Providers\BINLSVC\NewMachineDomainJoin to 1. 120 Unattend File To choose a default unattend file for the Windows Deployment Services client Using the MMC Using WDSUTIL 1. Right-click the server, and then click Properties. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. On the Client tab, select the Enable client unattend check box and then choose an unattend file for the relevant architecture. 2. To turn on unattended installation and specify the unattend file, run WDSUTIL /SetServer /WDSUnattend /Policy:Enabled /File:<path> /Architecture:{x86|x64|ia64}. The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WdsI mgSrv\Unattend\Enabled to 1 and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WdsI mgSrv\Unattend\<arch>\FilePath to the specified path. To specify whether an unattend file on the client computer will override a default unattend file Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Do one of the following: To allow an unattend file on the client computer to override the unattend file sent from the server for the Windows Deployment Services client, run WDSUTIL /Set-Server /WDSUnattend /CommandLinePrecedence:Yes. To force the unattend file sent from the server to be used for the Windows Deployment Services client, run WDSUTIL /Set-server /WDSUnattend /CommandLinePrecedence:No. The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WdsI mgSrv\Unattend\CommandLineUnattendPrecedence to 1 or 0. 121 How to Manage Client Computers This topic contains procedures for the tasks that are listed and described in the following table. Help for WDSUTIL is available by typing WDSUTIL /? at a command prompt or online at http://go.microsoft.com/fwlink/?LinkId=112194. Type Procedure Prestage Computers To prestage a client computer To prestage a client computer to boot from a different server To prestage a client computer to use a network boot program other than the default To prestage a client computer to use an unattend file other than the default for the Windows PE phase of unattended setup To prestage a client computer to use a boot image other than the default To prestage a client computer to join a domain To view the attributes of a prestaged client To enable the Auto-Add policy To change the length of time approved computers are held in the Auto-Add database To change the length of time rejected and pending computers are held in the Auto-Add database To delete the rejected or approved computers table To change the rate at which pending computers will poll the server To change the number of times pending computers will poll the server To change the message displayed to pending computers To set a default network boot server for pending computers To set a default network boot program for pending computers To set a default unattend file for pending computers To set a default boot image for pending computers To set domain join options for pending computers To view the table of computers that are pending approval To approve a pending computer by using the default settings To approve all pending computers by using the default settings To approve a pending computer, but change a setting To approve all pending computers, but change a setting To reject a pending computer Configure the Auto-Add Policy Specify Settings for Pending Computers Approve and Reject Pending Computers 122 Prestage Computers To prestage a client computer Using the Active Directory Users and Computers snap-in Using WDSUTIL 1. On the server running Active Directory Users and Computers, open the Active Directory Users and Computers MMC snap-in (click Start, click Run, type dsa.msc, and then click OK). Note To manage the server remotely, you can install “AD DS Snap-Ins and CommandLine Tools” in the Remote Server Administration Tools. To do this, click Add Features in Server Manager, and install the feature from the following location: Remote Server Administration Tools>Remote Administration Tools>AD DS and AD LDS Tools>AD DS Tools>AD DS Snap-Ins and Command-line Tools. 2. In the console tree, right-click the organizational unit that will contain the new client computer. 3. Click New, and then click Computer. 4. Type the client computer name, click Next, and then click This is a managed computer. 5. In the text box, type the client computer's MAC address preceded with twenty zeros or the globally unique identifier (GUID) in the format: {XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXXXXX}. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Add-Device /Device:<name> /ID:<GUIDorMACAddress> where <GUIDorMACAddress> is the identifier of the new computer. If you use a MAC address, you must precede it with twenty zeros (0). For example: WDSUTIL /Add-Device /Device:Computer1 /ID:{E8A3EFAC-201F-4E69-953FB2DAA1E8B1B6} /ReferralServer:WDSServer1 /BootProgram:boot\x86\pxeboot.com /WDSClientUnattend:WDSClientUnatt end\unattend.xml /User:Domain\MyUser /JoinRights:Full /BootImagePath:boot\x86\images\boo t.wim /OU:"OU=MyOU,CN=Test,DC=Domain ,DC=com" 6. Click Next, and click one of the following options to specify which server or servers will support this client computer: Any available remote installation server The following remote installation server 7. Click Next, and then click Finish. 123 The command in the preceding procedure creates a computer account object in Active Directory Domain Services (AD DS) for the specified computer, with the netbootGUID attribute set to the specified ID. To prestage a client computer to boot from a different server Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Device /Device:<name> /ReferralServer:<ServerName>. The preceding procedure sets the AD DS netbootMachineFilePath attribute to the specified referral server. To prestage a client computer to use a network boot program other than the default Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Device /Device:<name> /BootProgram:<path>, where <path> is the relative path to the boot program you want from the RemoteInstall folder. The preceding procedure appends the specified path to the referral server as part of the netbootMachineFilePath attribute on the computer. To prestage a client computer to use an unattend file other than the default for the Windows PE phase of unattended setup Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Device /Device:<name> /WDSClientUnattend:<path>, where the path is relative to the unattend file you want from the RemoteInstall folder. 124 The preceding procedure sets the WdsUnattendFilePath variable in the netbootMirrorDataFile AD DS attribute on the client’s computer account object to the specified path. To prestage a client computer to use a boot image other than the default Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Device /Device:<name> /BootImagePath:<path>, where <path> is the relative path to the boot image you want from the RemoteInstall folder. This command sets the BootImagePath variable in the netbootMirrorDataFile AD DS attribute on the client’s computer account object to the specified path. To prestage a client computer to join a domain Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Do one of the following: To enable the specified user to join the client computer to the specified domain once, run WDSUTIL /Set-Device /Device:<name> /User:<user> /JoinRights:JoinOnly /JoinDomain:Yes /Domain:<domain> /ResetAccount, where: <user> is domain\user or user@domain <name> is the name of the computer <domain> is the name of the domain To enable the specified user to join the client computer to the specified domain at any time, run WDSUTIL /Set-Device /Device:<name> /User:<user> /JoinRights:Full /JoinDomain:Yes /Domain:<domain>. To join the client computer to the specified domain without granting any user rights, run WDSUTIL /Set-Device /Device:<name> /JoinDomain:Yes /Domain:<domain>. The preceding procedure sets the JoinDomain variable in the netbootMirrorDataFile AD DS attribute on the client’s computer account object to 1. It also grants the specified user rights on the computer object. 125 To view the attributes of a prestaged client Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Do one of the following: To view the prestaged client by name in the local domain, run WDSUTIL /Get-Device /Device:<name>. To view a prestaged client by ID (GUID or MAC) in the local domain, run WDSUTIL /Get-Device /ID:<ID>. Note To specify that the client is in a domain other than the local one, specify /Domain:<domain> with either of these commands. Note To search the entire AD DS forest, specify /Forest:Yes with either of these commands. The preceding procedure displays the requested information from the folder. Configure the Auto-Add Policy For more information about the Auto-Add policy, see Enabling the Auto-Add Policy at Prestaging Client Computers To enable the Auto-Add policy Using the MMC Using WDSUTIL 1. Right-click the server, and then click Properties. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. On the PXE Response settings tab, click Respond to all (known and unknown) client computers. 3. Select the check box For unknown clients, notify administrator and respond after approval. 2. Run WDSUTIL /Set-Server /AutoAddPolicy /Policy:AdminApproval. The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers \BINLSVC\AutoApprove\Policy to 1. 126 To change the length of time approved computers are held in the Auto-Add database Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Server /AutoAddPolicy /RetentionPeriod /Approved:<time in days>. The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers \BINLSVC\AutoApprove\ApprovedRetention to the specified number. To change the length of time rejected and pending computers are held in the Auto-Add database Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Server /AutoAddPolicy /RetentionPeriod /Others:<time in days>. The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers \BINLSVC\AutoApprove\OtherRetention to the specified number. To delete the approved or rejected computers table Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Delete-AutoAddDevices /DeviceType:<ApprovedDevices|RejectedDevices>. The preceding procedure deletes the contents of the approved or rejected table in the Auto-Add database. 127 Specify Settings for Pending Computers To change the rate at which pending computers will poll the server Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. To set the time between polls, run WDSUTIL /Set-Server /AutoAddPolicy /PollInterval:<time in seconds>. This command sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers \BINLSVC\AutoApprove\PollInterval to the specified time. To change the number of times pending computers will poll the server Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Server /AutoAddPolicy /MaxRetry:<retries>. The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers \BINLSVC\AutoApprove\PollMaxRetry to the specified value. To change the message displayed to pending computers Using the MMC Using WDSUTIL N/A 3. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Server /AutoAddPolicy /Message:<message>. This procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers \BINLSVC\AutoApprove\PollMessage to the specified message. 128 To set a default network boot server for pending computers Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Server /AutoAddSettings /Architecture:{x86|x64|ia64} /ReferralServer:<server name>. The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers \BINLSVC\AutoApprove\<architecture>\ReferralServer to the specified server name. To set a default network boot program for pending computers Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Server /AutoAddSettings /Architecture:{x86|x64|ia64} /BootProgram:<path>, where the <path> is relative to the RemoteInstall folder. The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers \BINLSVC\AutoApprove\<architecture>\BootProgramPath to the specified path. To set a default unattend file for pending computers Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Server /AutoAddSettings /Architecture:{x86|x64|ia64} /WDSClientUnattend:<path>, where the path is relative to the RemoteInstall folder. The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers \BINLSVC\AutoApprove\<architecture>\WdsUnattendFilePath to the specified path. 129 To set a default boot image for pending computers Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Server /AutoAddSettings /Architecture:{x86|x64|ia64} /BootImage:<path>, where <path> is relative to the RemoteInstall folder. The preceding procedure sets HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers \BINLSVC\AutoApprove\<architecture>\BootImagePath to the specified path. To set domain join options for pending computers Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Do one of the following: To enable the specified user (specified as domain\user or user@domain) to join the client computer to the specified domain once, run WDSUTIL /Set-Server /AutoAddSettings Architecture:{x86|x64|ia64} /User:<user> /JoinRights:JoinOnly /JoinDomain:Yes /Domain:<domain>. To enable the specified user to join the client computer to the specified domain at any time, run WDSUTIL /Set-Server /AutoAddSettings Architecture:{x86|x64|ia64} /User:<user> /JoinRights:Full /JoinDomain:Yes /Domain:<domain>. The preceding procedure sets: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Pr oviders\BINLSVC\AutoApprove\<architecture>\JoinRights to 0 if Join Only and 1 if Full HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Pr oviders\BINLSVC\AutoApprove\<architecture>\JoinDomain to 1. 130 Approve and Reject Pending Computers To view the list of computers that are pending approval Using the MMC Using WDSUTIL 1. Expand the server node. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Select the Pending Devices node. 2. Run WDSUTIL /Get-AutoAddDevices /DeviceType:PendingDevices. The preceding procedure displays the Auto-Add devices table from the Binlsvcdb.mdb file. To approve a pending computer by using the default settings Using the MMC Using WDSUTIL 1. Select the Pending Devices node. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Right-click the computer you want to approve, and then click Approve. 2. Run WDSUTIL /Approve-AutoAddDevices /RequestID:<ID> with the ID obtained from the Auto-Add database. The preceding procedure approves the computer. For more information, see Prestaging Client Computers. To approve all pending computers by using the default settings Using the MMC Using WDSUTIL 1. Right-click the Pending Devices node. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Click Approve All. 2. Run WDSUTIL /Approve-AutoAddDevices /RequestID:All. The preceding procedure approves the computers. For more information, see Prestaging Client Computers. 131 To approve a pending computer, but change a setting Using the MMC (name Using WDSUTIL change only) 1. Select the Pending Devices node. 2. Select the computer you want to approve. 3. On the Action menu, click Name and Approve. 4. In the dialog box, type the name you want to give the computer. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Approve-AutoAddDevices /RequestID:<ID> with the ID obtained from the Auto-Add database In addition, you can append this command with the following options: To change the name, specify /MachineName:<name> To change the organizational unit (OU) where the account will be created, specify /OU:<name of OU>. To change the user account for the domain join, specify /User:<name> where the name is domain\user or user@domain. To enable the user to join this computer to the domain only once, specify /JoinRights:JoinOnly. To enable the user to join this computer to the domain at any time, specify /JoinRights:Full. To join this computer to the domain, specify /JoinDomain:Yes. To direct the computer to install from a different Windows Deployment Services server, specify /ReferralServer:<server name>. To change the network boot program used, specify /BootProgram:<path>. To change the unattend file used for the Microsoft Windows Preinstallation Environment (Windows PE) phase of unattended setup, specify /WDSClientUnattend:<path>. To change the boot image used, specify /BootImagePath:<path>. The preceding procedure approves the computer, with the configured settings. For more information, see Prestaging Client Computers. To approve all pending computers, but change a setting Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Approve-AutoAddDevices /RequestID:All 132 Using the MMC Using WDSUTIL In addition, you can append this command with the following options: To change the OU where the accounts will be created, specify /OU:<name of OU>. To change the user account used for domain join, specify /User:<name> where the name is domain\user or user@domain. To allow the user to join these computers to the domain once only, specify /JoinRights:JoinOnly. To allow the user to join these computers to the domain at any time, specify /JoinRights:Full. To join these computers to the domain, specify /JoinDomain:Yes. To direct the computers to install from a different Windows Deployment Services server, specify /ReferralServer:<server name>. To change the network boot program used, specify /BootProgram:<path>. To change the unattend file used for the Windows PE phase of unattended setup, specify /WDSClientUnattend:<path>. To change the boot image used, specify /BootImagePath:<path>. The preceding procedure approves the computers with the configured settings. For more information, see Prestaging Client Computers. To reject a pending computer Using the MMC Using WDSUTIL 1. Select the Pending Devices node. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Right-click the computer, and then click Reject or Reject All. 2. Do one of the following: To reject a single computer, run WDSUTIL /RejectAutoAddDevices /RequestID:<ID> with the ID obtained from the Auto-Add database. To reject all computers, run WDSUTIL /Reject-AutoAddDevices /RequestID:All. The preceding procedure sets the Status field for the computer to 2 (rejected) in the table of pending computers, and it sends the Abortpxe.com file to the computer. 133 How to Manage Images This topic contains procedures for the tasks that are listed and described in the following table. Note Help for WDSUTIL is available by typing WDSUTIL /? at a command prompt or online at http://go.microsoft.com/fwlink/?LinkId=112194. Type Procedure General Tasks To export an image from the server to a stand-alone .wim file To replace an image on the server with an updated version To remove an image To add a boot image to the server To set attributes on a boot image To display the attributes of a boot image To create a capture image To create a discover image To add an install image To set the attributes on an install image To display the attributes on an install image To convert an RIPREP image to a .wim install image To make a copy of an install image within an image group To remove an image group To add an image group to the image store To set the attributes on an image group To display information about all images in an image group Boot Images Install Images Image Groups General Tasks To export an image from the server to a stand-alone .wim file 134 Using the MMC Using WDSUTIL 1. Right-click a boot or install image, and then click Export Image. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. In the dialog box, choose a file name to export the image to. 2. Do one of the following: For a boot image, run WDSUTIL /Verbose /Progress /Export-Image /Image:<name> /ImageType:Boot /Architecture:{x86|x64|ia64} /DestinationImage /Filepath:<path and file name>. For an install image, run WDSUTIL /Verbose /Progress /Export-Image /Image:<name> /ImageType:Install /ImageGroup:<image group name> /DestinationImage /Filepath:<path and file name>. 3. You can also set the following: To set these metadata fields on the image, append /Name:<name> or /Description:<description> To determine behavior when the image specified in /DestinationImage already exists, append /Overwrite:{Yes|No|Append}. Yes will overwrite the image, No will cause an error, and Append will append the new image to the existing .wim file. Note that Append is available only for install images. The preceding procedure does the following: For a boot image, it copies the file to the specified destination. For an install image, it combines the metadata in the Install.wim file with the resources in the Res.rwm file into a single .wim file at the specified destination. To replace an image on the server with an updated version 135 Using the MMC Using WDSUTIL 1. Right-click a boot or install image, and then click Replace Image. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Do one of the following: To replace a boot image, run WDSUTIL /Verbose /Progress 2. Browse to the updated version. /Replace-Image /Image:<name> /ImageType:Boot 3. Click through the rest of the wizard. /ImageFile:<path>. /Architecture:{x86|x64|ia64} /ReplacementImage To replace an install image, run WDSUTIL /Verbose /Progress /Replace-Image /Image:<name> /ImageType:Install /ImageGroup:<image group name> /ReplacementImage /ImageFile:<path>. The preceding procedure adds the new image to the image store and removes the old one. To remove an image Using the MMC Using WDSUTIL 1. Right-click a boot or install image. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Click Delete. 2. Do one of the following: For boot images, run WDSUTIL /Remove-Image /Image:<name> /ImageType:Boot /Architecture:{x86|x64|ia64} For install images, run WDSUTIL /Remove-Image /Image:<name> /ImageType:Install /ImageGroup:<image group name>. If the source image file contains more than one install image, append /SourceImage:<Source image name> to specify the image to use as a replacement. The preceding procedure deletes the .wim image file from the image store. Note If you specify /SourceImage, data folders associated with the original image (for example, folders that contains unattend files or language packs) will be kept intact and will be associated with the replacement image. Boot Images To add a boot image to the server 136 Using the MMC Using WDSUTIL 1. Right-click the Boot Images node, and then click Add Boot Image. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Enter the path to the boot image or browse to the image file, and then click Next. In most cases, you should use the standard boot image that is included on the Windows Server 2008 media (located at \Sources\boot.wim) without modification. Do not use the Boot.wim from the Windows Vista media unless your version of Windows Vista has SP1 integrated into the DVD. 3. Enter an image name and description, and then click Next. 2. Run WDSUTIL /Verbose /Progress /Add-Image /ImageFile:<path> /ImageType:Boot, where the path is a full path to the image file. 4. Review the choices, and then click Next. The preceding procedure does the following: Copies the boot image file to the folder \RemoteInstall\Boot\architecture\Images. Generates a Boot Configuration Data (BCD) store for the boot image in the folder \RemoteInstall\Boot\ architecture \Images. Generates a combined BCD store for the architecture in folder \RemoteInstall\Boot\ architecture. Extracts the required files for Pre-Boot Execution Environment (PXE) booting from \Windows\Boot\PXE in the image to the folder \RemoteInstall\Boot. If the files already exist on the server, a version check is performed so that the newest files are used. To set the attributes on a boot image Using the MMC Using WDSUTIL 1. Right-click a boot 1. Click Start, right-click Command Prompt, and click Run as image, and then click administrator. Disable to take the 2. Do one of the following: image offline. To take the image offline, run WDSUTIL /Set-Image 2. Right-click the /Image:<name> /ImageType:Boot /Architecture:<arch> image, and then click /Enabled:No. Properties. To change the name and description, run WDSUTIL /Set-Image 3. Enter the name and /Image:<name> /ImageType:Boot /Architecture:<arch> description. /Name:<name> /Description:<description>. In the preceding procedure, note the following: Taking an image offline sets the hidden file attribute on the relevant .wim file. 137 Changing the name and description changes these attributes in the metadata header of the .wim file. To display the attributes of a boot image Using the MMC Using WDSUTIL 1. Right-click a boot image. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Click Properties. 2. Run WDSUTIL /Get-Image /Image:<name> /ImageType:Boot /Architecture:<arch>. The preceding procedure displays the file name, image name, description, architecture, image type, size, creation and modify dates, default languages, operating system version, service pack level, and online and offline status of the image. To create a capture image Using the MMC Using WDSUTIL 1. In the Windows Deployment Services MMC snap-in, expand the Boot Images node. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Right-click the image to use it as a capture image (most commonly, the \Sources\boot.wim file from the installation media). 3. Click Create Capture Boot Image. 4. Type a name, description, and the location where you want to save a local copy of the file. You must specify a location so that if there is a network issue when you deploy the capture image, you have a local copy. 5. Continue to follow the instructions in the wizard, and when it is completed, click Finish. 6. Right-click the boot image folder. 2. Run WDSUTIL /NewCaptureImage /Image:<source boot image name> /Architecture:{x86|ia64| x64} /DestinationImage /FilePath:<file path>, where the file path is the path and name for the capture image. 7. Click Add Boot Image. 8. Browse and select the new capture image, and then click Next. 9. Follow the instructions in the Image Capture Wizard. 138 To create a discover image Using the MMC Using WDSUTIL 1. In the Windows Deployment Services MMC snap-in, expand the Boot images node. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Right-click the image you want to use as a discover image. In most cases, this should be the Boot.wim file from the \Sources directory of the installation DVD. 2. Run WDSUTIL /New-DiscoverImage 3. Click Create Discover Boot Image. 4. Follow the instructions in the wizard, and when it is completed, click Finish. /Image:<name> /Architecture:{x86|x64|ia64} /DestinationImage /FilePath:<path and name to new file>. To specify which server the discover image connects to, append /WDSServer:<server name or IP>. Install Images To add an install image Using the MMC Using WDSUTIL 1. Right-click the image group, and then click Add Install Image. 1. Click Start, right-click Command Prompt, and click Run as administrator. 3. Select the file to add. 3. Run WDSUTIL /Verbose /Progress /Add-Image /ImageFile:<path to .wim file> /ImageType:Install. 2. To create an image group, run WDSUTIL /Add-ImageGroup 2. Select an image group. /ImageGroup:<image group name>. 4. Proceed through the rest of the wizard. If more than one image group exists on the server, append /ImageGroup:<image group name> to specify which group the image should be added to. To skip the integrity check before adding the image, append /SkipVerify. The preceding procedure runs an integrity check on the specified image file, creates a metadataonly .wim file in the image group folder, and adds the resources in the image file to the Resource .wim (res.rwm) file for the image group. To set the attributes for an install image The following procedure sets the name, description, online and offline status, access controls, and associated unattend file for an image. 139 Using the MMC Using WDSUTIL 1. Right-click an install image, and then either click Disable to take the image offline or click Enable to bring it back online. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Set-Image Image:<name> 2. On the Action menu, click Properties. /ImageType:Install /ImageGroup:<image 3. Enter the name and description in the appropriate text boxes. group name> /Name:<name> 4. Check Allow image to install in unattended mode, and then select a file to associate an unattend file with the install image. /Description:<description> /UserFilter:<SDDL> /Enabled:{Yes|No} /UnattendFile:<path>. 5. Use the Security tab to set access controls. The preceding procedure changes image metadata or file access control lists (ACLs) on the image file to store the attributes. If you specify an unattend file, this procedure also copies it into the image store. Note that taking an image offline makes the file hidden. To display the attributes for an install image Using the MMC Using WDSUTIL 1. Right-click the image. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Click Properties. 2. Run WDSUTIL /Get-Image /Image:<name> /ImageType:Install /ImageGroup:<image group name>. The preceding procedure displays the file name, image name, description, architecture, image type, image group, size, HAL type, creation and modification time, languages, operating system version, ACLs, unattend file (if assigned), and the online or offline status of the image. To convert a RIPREP image to a .wim install image For more information, see Creating Images. 140 Using the MMC Using WDSUTIL 1. Click the Legacy Images node. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Right-click the RIPREP image you want to convert, and then click Convert to WIM. 2. Run WDSUTIL /Verbose /Progress /Convert-RiPrepImage /FilePath:<path to RIPREP image sif file> /DestinationImage /FilePath:<path and name of .wim image>. In addition, you can specify the following: 3. Enter the name, description, path, and file name, and then click Next. To give the new .wim image a name in the metadata, append /Name:<name>. To give the new .wim image a description in the metadata, append /Description:<description>. To convert the original RIPREP image, rather than a copy, append /InPlace. To determine behavior when the image file specified in /DestinationImage already exists, append /Overwrite:{Yes|No|Append}. Yes will overwrite the .wim file, No will cause an error, and Append will append the new image to the existing .wim file. To make a copy of an install image Using the MMC Using WDSUTIL N/A 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Run WDSUTIL /Copy-Image /Image:<name> /ImageType:Install /ImageGroup:<image group name> /DestinationImage /Name:<name> /Filename:<file name>. To give the new image a description, append /Description:<description>. The preceding procedure creates a copy of the metadata .wim file that corresponds to the selected image, and it sets the image name and file name (and description, if specified) to the values you specify. Image Groups To remove an image group 141 Using the MMC Using WDSUTIL 1. Right-click image group. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Click Delete. 2. Run WDSUTIL /Remove-ImageGroup /ImageGroup:<image group name>. This procedure deletes the image group folder and all of its contents from the image store. For install images, if an associated data folder exists (the folder that contains unattend files or language packs), it will be removed as well. To add an image group to the image store Using the MMC Using WDSUTIL 1. Right-click the Install Images node, and then click Add Image Group. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Enter the name for the image group. 2. Run WDSUTIL /Add-ImageGroup /ImageGroup:<image group name>. The preceding procedure creates a folder in the image store with the specified name. To set the attributes on an image group Use the following procedure to set the name and access controls for an image group. Note Changing the name renames the image group folder in the image store, and changing the security sets ACLs on the folder and its contents. Using the MMC Using WDSUTIL 1. Right-click image group, and then click Rename. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Right-click image group, and then click Security. 2. To change the name, run WDSUTIL /Set-ImageGroup /ImageGroup:<existing image group name> /Name:<new image group name>. 3. To set the security, run WDSUTIL /Set-ImageGroup /ImageGroup:<image group name> /Security:<SDDL>, where SDDL is the security descriptor you want to use for the image group, in Security Descriptor Definition Language (SDDL) format. 142 To display information about all images in an image group Using the MMC Using WDSUTIL 1. Select an image group. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. View the images in the right pane. 2. Run WDSUTIL /Get-ImageGroup /ImageGroup:<image group name>. To display the full image metadata on each image in the group, append /Detailed. How to Create Multicast Transmissions This topic explains how to use Windows Deployment Services to create multicast transmissions. In This Topic When to Implement Multicasting Prerequisites for Creating a Multicast Transmission Known Issues in Creating a Multicast Transmission Transmission Types To create a multicast transmission with Deployment Server To manage transmissions To manage clients in a transmission To configure the UDP port range for multicast To configure how the server will obtain IP addresses for multicast transmissions Note Help for WDSUTIL is available by typing WDSUTIL /? at a command prompt or online at http://go.microsoft.com/fwlink/?LinkId=112194. For information about using Transport Server to create a namespace, see Using Transport Server. When to Implement Multicasting Multicasting enables you to deploy an image to a large number of client computers without overburdening the network. When you create a multicast transmission for an image, the data is sent over the network only once, which can drastically reduce the amount of network bandwidth that is used. 143 Consider implementing multicasting if your Multicasting might not optimize your organization: installations if your organization: Has network routers that support multicasting. Has network routers that do not support multicasting. Is a large company that requires many concurrent client installations. Does not have bandwidth overload problems. Wants to use network bandwidth efficiently. This is because with this feature, images are sent over the network only once, and you can specify limitations (for example, to only use 10 percent of your bandwidth). Deploys images to only a small number of client computers simultaneously. Has disk space limitations on the client computers. (This is because the image is downloaded to client computers instead of being installed from a server.) Has enough disk space on client computers for the image to be downloaded. Meets the requirements listed in the following section. Prerequisites for Creating a Multicast Transmission To implement this feature in your organization, you must have all of the following: Routers that support multicasting. In particular, your network infrastructure needs to support the Internet Group Management Protocol (IGMP) to properly forward multicast traffic. Without the IGMP, multicast packets are treated as broadcast packets, which can lead to network flooding. At least one install image that you want to transmit on the server The Boot.wim file from the Windows Server 2008 media (located in the \Sources folder). Do not use the Boot.wim from the Windows Vista media unless your version of Windows Vista has SP1 integrated into the DVD. Internet Group Membership Protocol (IGMP) snooping should be enabled on all devices. This will cause your network hardware to forward multicast packets only to those devices that are requesting data. If IGMP snooping is turned off, multicast packets are treated as broadcast packets, and will be sent to every device in the subnet. Known Issues in Creating a Multicast Transmission You may encounter the following issues when implementing multicasting: If you use the Windows Vista Boot.wim file for multicast transmissions, you will be able to create the transmission, but people who boot into it will not be able to join it. 144 If multiple servers are using multicast functionality on a network (Transport Server, Deployment Server, or another solution), it is important that each server is configured so that the multicast IP addresses do not collide. Otherwise, you may encounter excessive traffic when you enable multicasting. Note that each Windows Deployment Services server will have the same default range. To work around this issue, specify static ranges that do not overlap to ensure that each server is using a unique IP address or Multicast Address Dynamic Client Allocation Protocol (MADCAP). To specify this option, right-click the server in the MMC snap-in, click Properties, and then click the Network Settings tab. Each transmission can be run only as fast as the slowest client. That is, the entire transmission will be slow if there is one slow client. To resolve this issue, first determine the client that is holding back the transmission (this is called the master client). To do this, view the output of the following command: WDSUTIL /Get-MulticastTransmission /Show-clients. Next, disconnect the master client. This will force the master client to run the transmission by using the Server Message Block (SMB) protocol, and the other clients' multicast performance should speed up. If they do not speed up, there is a problem with the client's hardware (for example, a slow hard disk) or a network problem. Transmission Types There are two types of multicast transmissions. Note that content is transferred over the network only if clients request data. If no clients are connected (that is, the transmission is idle), data will not be sent over the network. Auto-Cast. This option indicates that as soon as an applicable client requests an install image, a multicast transmission of the selected image begins. Then, as other clients request the same image, they too are joined to the transmission that is already started. Scheduled-Cast. This option sets the start criteria for the transmission based on the number of clients that are requesting an image and/or a specific day and time. If you do not select either of these check boxes, the transmission will not start until you manually start it. Note that in addition to these criteria, you can start a transmission manually at any time by rightclicking it and then clicking Start. 145 Consider using Auto-Cast if: Consider using Scheduled-Cast if: You work for a smaller organization or an organization where network traffic is an issue during the day. This way, you can set installations to occur during nonpeak hours or at night. To reduce the total time of the transmission. Because you can set multiple clients to start at the same time, the time will be reduced because Windows Deployment Services will not have to resend a part of the image to clients that started after the first client. You do not want the transmission to start until you manually start it (to do this, clear both check boxes when you create the transmission). You work for a large corporation or an organization with high bandwidth that can handle installations at any time. You do not want customers to have to wait for the installation to begin. To create a multicast transmission with Deployment Server Using the MMC Using WDSUTIL Do one of the following: 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. Do one of the following: Right-click the Multicast Transmission node, and then click Create Multicast Transmission. Right-click an image, and then click Create Multicast Transmission. a. To create an Auto-Cast transmission Syntax: WDSUTIL /New-MulticastTransmission /Image:<image name> /FriendlyName:<friendly name> /ImageType:Install /ImageGroup:<Image group name> /TransmissionType:AutoCast b. To create a Scheduled-Cast transmission Syntax: WDSUTIL /New-MulticastTransmission /Image:<image name> /FriendlyName:<friendly name> /ImageType:Install /ImageGroup:<Image group name> /TransmissionType:ScheduledCast [/Time:<yyyy/mm/dd:hh:mm>][/Clients:<no of clients>] To manage transmissions 146 Using the MMC Using WDSUTIL Start the transmission. If the transmission is the Scheduled-Cast type, there is at least one client, and the transmission has not started yet, you can right-click the transmission and then click Start. Delete the transmission. If you right-click the transmission and click Delete, the multicast transmission stops and each client installation will fall back to using unicast transmission. That is, the client installations will not be deleted or stopped, but they will not use the multicast transmission to complete the installation. To start the transmission Syntax: WDSUTIL /StartMulticastTransmission /Image:<image name> /ImageType:Install /ImageGroup:<image group name> Note You can start the transmission only if it is the Scheduled-Cast type, there is at least one client, and the transmission is not already started. Deactivate the transmission. If you rightclick the transmission and then click Deactivate, each client that is currently installing will continue, but no new clients will be joined to the transmission. After each current client installation is completed, the transmission will be deleted. If there are no clients when you click this option, the transmission will be deleted instantly. View the transmission's properties. To view the properties, right-click the transmission and then click Properties. Note that you cannot edit the properties of a transmission after it is created. To make a change after you have created a transmission, you need to delete it and then recreate it. To delete the transmission Syntax: WDSUTIL /RemoveMulticastTransmission /Image:<image name> /ImageType:Install /ImageGroup:<image group name> /Force To deactivate the transmission Syntax: WDSUTIL /RemoveMulticastTransmission /Image:<image name> /ImageType:Install /ImageGroup:<image group name> To view the transmission's properties Syntax: WDSUTIL /GetMulticastTransmission /Image:<image name> /ImageType:Install /ImageGroup:<image group name> Refresh the transmissions and data. To do this, right-click a transmission and then click Refresh. You can also refresh the data by pressing F5. To manage clients in a transmission 147 Using the MMC Using WDSUTIL Viewclients and see progress. To view any connected clients, expand the Multicast Transmissions node and then click the image. The connected clients (including the current installation time and the percentage complete) are shown in the right pane. Syntax: WDSUTIL /GetMulticastTransmission /Image:<image name> /ImageType:Install /ImageGroup:<image group name> /show:clients Stop a client installation. To stop the installation completely, right-click a client and then click Disconnect. You should use this option with caution because the installation will fail and the computer could be left in an unusable state. Disconnect a client from a multicast transmission. To discontinue the transmission for a particular client but continue to transfer the image through unicasting, right-click the client, and then click Bypass multicast. To view clients and see progress To stop a client installation completely Syntax: WDSUTIL /Disconnect-Client /ClientID:<id> /Force. Note You should use this option with caution because the installation will fail and the computer could be left in an unusable state. To disconnect a client from a multicast transmission but continue to transfer the image by using unicasting Syntax: WDSUTIL /Disconnect-Client /ClientID:<id> To view the client <id> for each transmission Syntax: WDSUTIL /GetMulticastTransmission /Image:<image name> /ImageType:Install /ImageGroup:<image group name> /show:clients To configure the UDP port range for multicasting This setting specifies the range of UDP ports to use for multicasting and other components, such as the Trivial File Transfer Protocol (TFTP) provider. Before you change this range, you need to have at least as many ports as you have sessions and concurrent clients accessing the server. In terms of multicasting, a session is a network interface on your server. To calculate the number of sessions, multiply the number of network adapters on your server by the number of images that could be concurrently transferred using multicasting. For example, if you have two network adapters, and clients are connected on both interfaces, the content will be sent on the network twice (once from each interface). So in this case, you would need at least two ports. Because this 148 range is also used by the TFTP provider, you will need as many available ports as you have concurrent clients accessing the server. Using the MMC Using WDSUTIL 1. Right-click the server, and then click Properties. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. On the Network Settings tab, specify the UDP port range. 2. Run WDSUTIL /Set-Server 3. You must restart the service before the changes will take effect. To do this, rightclick the server in the MMC snap-in, click All Tasks, and then click Restart. [/Server:<name>] /Transport /StartPort:x /EndPort:y. 3. You must restart the service before the changes will take effect. To do this, run wdsutil /stop-server and then run wdsutil /start-server. To configure how the server will obtain IP addresses for multicasting The server allocates a multicast IP address to each multicast session, and all connected clients listen in on that address. It's important that all IP addresses be unique on the network to ensure that each client receives the correct data. If you have a complex network, you should consider using DHCP to select the addresses. In more basic environments, you can configure a range and have the Windows Deployment Services server select the address. 149 Using the MMC Using WDSUTIL 1. Right-click the server, and then click Properties. 1. Click Start, right-click Command Prompt, and click Run as administrator. 2. On the Network Settings tab under Multicast IP Address, select one of the following: 2. Do one of the following: Obtain IP address from DHCP. You can select this option only if your DHCP server supports it. The IP address for each namespace will be obtained by using MADCAP (RFC 2730, Multicast). Use IP address from the following range. You will need to enter a range. 3. You must restart the service before the changes will take effect. To do this, rightclick the server in the MMC snap-in, click All Tasks, and then click Restart. To use MADCAP to obtain the IP address for each namespace, run WDSUTIL /Set-Server [/Server:<name>] /Transport /ObtainIPFrom:DHCP. To configure a preset range of IP addresses, run WDSUTIL /Set-Server [/Server:<name>] /Transport /ObtainIPv4From:Range /Start:x.x.x.x /End:y.y.y.y. 3. You must restart the service before the changes will take effect. To do this, run WDSUTIL /stop-server and then run WDSUTIL /start-server. Example Multicast Scripts The following examples are sample scripts that you can use with your multicast transmissions. To use each script, copy the code to a file and then save, it using the .vbs file name extension. Then open an elevated Command Prompt window and run a command that uses the following syntax: cscript <nameoffile>.vbs <WDSServer>. For example: cscript mcinfo.vbs localhost. In This Topic Stop Transmissions Slower than 1 MB per Second Display Performance Information About Clients Stop Transmissions Slower than 1 MB per Second The following Microsoft Visual Basic script will stop the transmission of the master client for any multicast session that has been transmitting data at a rate slower then 1 MB per second for longer than 60 seconds. You can configure these values by using the parameters at the top of the script. The master client is the slowest client in a transmission — that is, the client that is not capable of installing any faster while the other clients may be able to install at a faster rate. To determine the master client, view the output of the following command: WDSUTIL /Get150 MulticastTransmission /Show-clients. Note that there may be as many master clients as the server has network adapters. ' -------------Times are in milliseconds sleepTime = 5000 ' Minimum time to wait between each query to the server timeThreshold = 60000 ' Minimum time to wait before kicking the master client out of a slow session ' ------------- Speeds are in KB/sec speedThreshold = 1024 ' Minimum transfer rate for a session ' ------------- Display variables displayAllSessions = true ' Display all sessions on the server, not just the slow sessions printStatusDots = true ' Print a dot every time we contact the server. Useful to show that the script is doing something ' ------------------------------- End user defined settings -----------------------------Dim sessionDictionary, Manager, Server, hostname ' WDS Transport type definitions WdsTptDisconnectUnknown = 0 WdsTptDisconnectFallback = 1 WdsTptDisconnectAbort = 2 ' Run main main() ' ---------------------------------- main sub main if WScript.Arguments.Count < 1 then wscript.echo "[WARN]: Hostname not specified on command line, trying to connect to localhost" 151 hostname = "localhost" else hostname = WScript.Arguments.Item(0) end if ' We use a dictionary to keep track of sessions on the server Set sessionDictionary = CreateObject("Scripting.Dictionary") ' Create the Transport Manager Set Manager = CreateObject("WdsTptMgmt.WdsTransportManager") ' Connect to the server Set Server = Manager.GetWdsTransportServer(hostname) ' Echo out current settings if displayAllSessions = false then wscript.echo "[INFO]: Not displaying information for all sessions" end if if printStatusDots then wscript.echo "[INFO]: Printing status dots" end if wscript.echo "[INFO]: Speed Threshold: " + Cstr(speedThreshold) + " KB/sec, Time Threshold: " + Cstr(Int(timeThreshold/1000)) + "s, Sleep time: " + Cstr(Int(sleepTime/1000)) + "s" wscript.echo "[INFO]: Examining sessions on " + Server.name + "..." + vbCrLf ' Loop forever. User must control C out of the script to stop execution. Do while true if printStatusDots then Wscript.StdOut.Write(".") end if 152 loopAndKick() wscript.sleep(sleepTime) loop end sub ' ---------------------------------- loopAndKick sub loopAndKick ' Get a list of the namespaces on the server Set NamespaceCollection = Server.NamespaceManager.RetrieveNamespaces("", "", False) ' Get all namespaces present on the server for i = 1 to CLng(NamespaceCollection.count) Set ns = NamespaceCollection.Item(i) ' Get all contents for this namespace Set ContentCollection = NamespaceCollection.Item(i).RetrieveContents() for j = 1 to CLng(ContentCollection.count) Set content = ContentCollection.item(j) ' Get all sessions for this content Set SessionCollection = content.RetrieveSessions() for k = 1 to CLng(SessionCollection.count) Set session = SessionCollection.item(k) Set ClientCollection = session.RetrieveClients() 'Calculate the transfer rate, in KB/sec, for this session tRate = CLng(session.TransferRate) tRate = Int(tRate / 1024) ' Echo this session out to the screen if displayAllSessions then wscript.echo ns.name + content.name + ", Num clients: " + CStr(ClientCollection.count) + ", " + CStr(tRate) + " kB/sec" end if 153 ' If the session ID already exists in the dictionary, but no clients are connected, remove the entry from the dictionary if ( (CLng(ClientCollection.count) = 0) AND sessionDictionary.Exists( CLng(session.ID)) ) then wscript.echo vbTab + "Remove: " + Cstr(session.ID) sessionDictionary.Remove(CLng(session.ID)) ' If the session ID exists in the dictionary, update the session details, and kick the master client if needed elseif sessionDictionary.Exists( CLng(session.ID) ) then ' Retrieve and update timeSlow timeSlow = sessionDictionary.Item( CLng(session.ID) ) timeSlow = timeSlow + sleepTime ' If we've gone too slow for too long, kick the current master client if ( (tRate < speedThreshold) AND (timeSlow > timeThreshold) ) then ' Make sure we have a valid master client ID before we attempt to kick if Clng(session.MasterClientId) <> 0 then wscript.echo vbTab + "Kicking client: " + Cstr(session.MasterClientId) Server.DisconnectClient session.MasterClientId, WdsTptDisconnectFallback ' Reset time slow for this session timeSlow = 0 end if end if 154 ' Remove the old entry from the dictionary sessionDictionary.Remove(CLng(session.ID)) ' If the session is still too slow, add it back to the dictionary with the new time value if( tRate < speedThreshold) then wscript.echo vbTab + "Update: " + Cstr(session.ID) + ", Time slow: " + Cstr(Int(timeSlow/1000)) + "s" sessionDictionary.Add CLng(session.ID), timeSlow Otherwise, we've removed the session from the dictionary above else wscript.echo vbTab + "Remove: " + Cstr(session.ID) end if ' The session isn't in the dictionary. If the session is going too slow and has clients connected, add it to the dictionary else if( (tRate < speedThreshold) AND (CLng(ClientCollection.count) <> 0) ) then wscript.echo vbTab + "Add: " + Cstr(session.ID) sessionDictionary.Add CLng(session.ID), 0 end if end if next next next end sub Display Performance Information About Clients The following Visual Basic script displays performance information for all clients in all transmissions that are connected to the same server. ' Create the Tranport Manager Set Manager = CreateObject("WdsTptMgmt.WdsTransportManager") 155 if WScript.Arguments.Count = 0 then wscript.echo "INFO: Specify a host name on the command line to connect to a remote host" & vbCrLf Set Server = Manager.GetWdsTransportServer("localhost") else Set Server = Manager.GetWdsTransportServer(WScript.Arguments.Item(0)) end if ' Print Server name wscript.echo "Server: " + Server.name ' Get a list of the namespaces on the server Set NamespaceCollection = Server.NamespaceManager.RetrieveNamespaces("", "", False) ' Get all namespaces present on the server for i = 1 to CLng(NamespaceCollection.count) Set ns = NamespaceCollection.Item(i) wscript.echo " Namespace ID: " + CStr(ns.id) + ", Name: " + ns.name ' Get all contents for this namespace Set ContentCollection = NamespaceCollection.Item(i).RetrieveContents() for j = 1 to CLng(ContentCollection.count) Set content = ContentCollection.item(j) wscript.echo " Content ID : " + CStr(content.id) + ", Name: " + content.name ' Get all sessions for this content Set SessionCollection = content.RetrieveSessions() for k = 1 to CLng(SessionCollection.count) Set session = SessionCollection.item(k) tRate = CLng(session.TransferRate) tRate = Int(tRate / 1024) 156 ' Get all clients for this session Set ClientCollection = session.RetrieveClients() wscript.echo " Session ID: " + CStr(session.id) + ", NIC Name: " + session.NetworkInterfaceName &_ + ", tRate: " + CStr(tRate) + " kB/sec, clients: " + Cstr(ClientCollection.count) for l = 1 to Cint(ClientCollection.count) set client = ClientCollection.item(l) ' Determine if this client is the master client if Clng(session.MasterClientId) = Clng(client.id) then wscript.echo " * Client ID: " + CStr(client.id) + ", Name: " + client.name &_ + ", IP: " + client.IpAddress + ", MAC: " + client.MacAddress + ", Time connected: " + Cstr(client.JoinDuration) else wscript.echo " Client ID: " + CStr(client.id) + ", Name: " + client.name &_ + ", IP: " + client.IpAddress + ", MAC: " + client.MacAddress + ", Time connected: " + Cstr(client.JoinDuration) end if next next next next The following code is example output from the preceding script: C:\Users\administrator>cscript MCInfo.vbs localhost Microsoft (R) Windows Script Host Version 5.7 Copyright (C) Microsoft Corporation. All rights reserved. Server: wds-server.fabrikam.com 157 Namespace ID: 2471217798, Name: WDS:Server08/install-(2).wim/1 Namespace ID: 2471217799, Name: WDS:Server08/install.wim/1 Namespace ID: 2471217807, Name: WDS:Server03/amd64.wim/1 Namespace ID: 2471217808, Name: WDS:Server03/x86.wim/1 Namespace ID: 2471217810, Name: WDS:Vista/amd64.wim/1 Namespace ID: 2471217811, Name: WDS:Vista/x86.wim/1 Namespace ID: 2471217812, Name: WDS:XP_SP2/install-(2).wim/1 Content ID : 3263057331, Name: Res.rwm Session ID: 3353296855, NIC Name: Broadcom NetXtreme Gigabit Ethernet #2, tRate: 0 kB/sec, clients: 0 Namespace ID: 2471217813, Name: WDS:XP_SP2/Install.wim/1 Content ID : 3263057330, Name: Res.rwm Session ID: 3353296854, NIC Name: Broadcom NetXtreme Gigabit Ethernet #2, tRate: 883 kB/sec, clients: 1 * Client ID: 3267943420, Name: MININT-1U7QOTT, IP: 172.30.170.162, MAC: 000E7F28D375, Time connected: 1111 How to Modify the BCD Store Using Bcdedit You can use the Boot Configuration Data Editor (Bcdedit.exe) to view and modify the contents of the Boot Configuration Data (BCD) store. Bcdedit.exe is available on computers running Windows Vista and Windows Server 2008. For more information, see "Boot Configuration Data Editor Frequently Asked Questions" (http://go.microsoft.com/fwlink/?LinkId=112156). Note Note that when you modify the BCD store, you must force it to be recreated in order for your changes to take effect. To do this, either restart the WDSServer service (run wdsutil /stop-server and then run wdsutil /start-server) or run Sc control wdsserver 129. In This Topic To View the Contents of the BCD Store To Configure the Default Selection Time-out Value To Configure a Localized Boot Manager Experience To Configure the TFTP Block Size To Configure the TFTP Window Size 158 To Configure Windows Debugger Options To Turn On Emergency Management Services Settings To View the Contents of the BCD Store To view the contents of this store, run the following command at the command prompt: Syntax: bcdedit /enum all /store <path to BCD store> Example: C:\boot>bcdedit.exe /enum all /store c:\remoteinstall\tmp\X86.{05FF3388-7D7146A1-AE8A704480979281}.bcd To Configure the Default Selection Time-out Value The default selection time-out value is set to 30 seconds. You can configure this value by setting the appropriate option in the Default.bcd store for your client’s architecture, using the following steps: 1. View the existing configuration settings in the Default.bcd store by running the following command: Syntax: bcdedit /enum all /store <full path and file name of store> Example: C:\>bcdedit /enum all /store c:\RemoteInstall\Boot\x86\default.bcd Windows Boot Manager -------------------identifier {bootmgr} inherit {dbgsettings} timeout 30 Real-mode Application (10400009) -------------------------------identifier {40fe5c41-285e-412b-b4cd-0ce498e470a2} device boot path OSChooser\i386\startrom.n12 description Remote Installation Services pxesoftreboot Yes Debugger Settings ----------------identifier {dbgsettings} 159 debugtype Serial debugport 1 baudrate 115200 Device options -------------identifier {68d9e51c-a129-4ee1-9725-2ab00a957daf} ramdisksdidevice boot ramdisksdipath \Boot\Boot.SDI 2. Set the appropriate time-out value by running the following command: Syntax: bcdedit /store <full path and file name of store> /set {bootmgr} timeout <value in seconds> Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set {bootmgr} timeout 10 3. Force regeneration of the BCD store in the \Tmp folder by sending a control signal to the WDSServer service, using the following command: C:\>sc control wdsserver 129 To Configure a Localized Boot Manager Experience To configure the Boot Manager application to allow for a localized setup experience, perform the following steps: 1. View the existing settings in the default BCD store by running the following command: Syntax: bcdedit /enum all /store <full path and file name of store> Example: C:\>bcdedit /enum all /store c:\RemoteInstall\Boot\x86\default.bcd Windows Boot Manager -------------------identifier {bootmgr} inherit {dbgsettings} timeout 30 Real-mode Application (10400009) -------------------------------160 identifier {40fe5c41-285e-412b-b4cd-0ce498e470a2} device boot path OSChooser\i386\startrom.n12 description Remote Installation Services pxesoftreboot Yes Debugger Settings ----------------identifier {dbgsettings} debugtype Serial debugport 1 baudrate 115200 Device options -------------identifier {68d9e51c-a129-4ee1-9725-2ab00a957daf} ramdisksdidevice boot ramdisksdipath \Boot\Boot.SDI 2. Set the appropriate locale value by running the following command: Syntax: bcdedit /store <full path and file name of store> /set {bootmgr} locale <lang> Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set {bootmgr} locale en-US 3. Set the application path by running the following command: Syntax: bcdedit /store <full path and file name of store> /set {bootmgr} path <relative path to bootmgr.exe> Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set {bootmgr} path \boot\<arch>\bootmgr.exe 4. Force regeneration of the BCD store in the \Tmp folder by sending a control signal to the server service by specifying, using the following command: C:\>sc control wdsserver 129 To Configure the TFTP Block Size The default TFTP block size value is 1432 bytes. You can configure this value by setting the appropriate value in the default BCD store for the client architecture, using the following steps: 161 1. Determine the GUID identifier of the boot manager application by running the following command: Syntax: bcdedit /enum all /store <full path and file name of store> Example: C:\>bcdedit /enum all /store c:\RemoteInstall\Boot\x86\default.bcd Windows Boot Manager -------------------identifier {bootmgr} inherit {dbgsettings} timeout 30 Real-mode Application (10400009) -------------------------------identifier {40fe5c41-285e-412b-b4cd-0ce498e470a2} device boot path OSChooser\i386\startrom.n12 description Remote Installation Services pxesoftreboot Yes Debugger Settings ----------------identifier {dbgsettings} debugtype Serial debugport 1 baudrate 115200 Device options -------------identifier {68d9e51c-a129-4ee1-9725-2ab00a957daf} ramdisksdidevice boot ramdisksdipath \Boot\Boot.SDI 2. Set the appropriate TFTP block size value by running the following command: 162 Syntax: bcdedit /store <full path and file name of store> /set {<GUID identifier>} ramdisktftpblocksize <block size> Example: C:\>bcdedit /store c:\RemoteInstall\boot\x86\default.bcd /set {68d9e51c-a1294ee1-9725-2ab00a957daf} ramdisktftpblocksize 4096 Note We recommend that you go up in multiples (4096, 8192, 16384, and so on) and that you not set a value higher than 16384. 3. Force regeneration of the BCD store in the \Tmp folder by sending a control signal to the WDSServer service, using the following command: C:\>sc control wdsserver 129 To Configure the TFTP Window Size The default TFTP window size is 8. You can configure this value by setting the appropriate value in the default BCD store for the client architecture, using the following steps: 1. At the command prompt, determine the GUID identifier of the boot manager application by running the following command: Syntax: bcdedit /enum all /store <full path and file name of store> 2. Set the appropriate TFTP window size by running the following command: Syntax: bcdedit /store <full path and file name of store> {<GUID>} ramdisktftpwindowsize <windowsize> Example: C:\>bcdedit /store c:\RemoteInstall\boot\x86\default.bcd {68d9e51c-a1294ee1-9725-2ab00a957daf} ramdisktftpwindowsize 9 3. Force regeneration of the BCD store in the \Tmp folder by sending a control signal to the WDSServer service by running the following command: C:\>sc control wdsserver 129 To Configure Windows Debugger Options There are three debugging options that you can add by using BCDedit.exe. These options are described in the following table. Option Description /bootdebug Enables or disables boot debugging for a boot application. /dbgsettings Sets the global debugger parameters. /debug Enables or disables kernel debugging for an operating system entry. 163 To turn on debugging for boot manager 1. View the existing settings in the Default.bcd store by running the following command: Syntax: bcdedit /enum all /store <full path and file name of store> Example: C:\>bcdedit /enum all /store c:\RemoteInstall\Boot\x86\default.bcd Windows Boot Manager -------------------identifier {bootmgr} inherit {dbgsettings} timeout 30 Real-mode Application (10400009) -------------------------------identifier {40fe5c41-285e-412b-b4cd-0ce498e470a2} device boot path OSChooser\i386\startrom.n12 description Remote Installation Services pxesoftreboot Yes Debugger Settings ----------------identifier {dbgsettings} debugtype Serial debugport 1 baudrate 115200 Device options -------------identifier {68d9e51c-a129-4ee1-9725-2ab00a957daf} ramdisksdidevice boot ramdisksdipath \Boot\Boot.SDI 2. Set the appropriate debugging values by running the following command: Syntax: bcdedit /store <full path and file name of store> /set {bootmgr} bootdebug 164 <value> Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set {bootmgr} bootdebug on 3. Force the regeneration of the BCD store in the \Tmp folder by sending a control signal to the server service, using the following command: C:\>sc control wdsserver 129 To turn on debugging for a particular operating system entry (for OSLoader) 1. Determine the GUID of the operating system entry by running the following command: Syntax: bcdedit /store <full path and file name of per-image BCD store> /enum all Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\Images\boot.wim.bcd /enum all Windows Boot Loader ------------------identifier {06689f95-f69c-4937-8ded-09a966a6a319} device ramdisk=[boot]\Boot\x86\Images\boot.wim,{68d9e51c- a129-4ee1-9725-2ab00a957da f} description WinPE 5600 RC1 osdevice ramdisk=[boot]\Boot\x86\Images\boot.wim,{68d9e51c- a129-4ee1-9725-2ab00a957da f} systemroot \WINDOWS detecthal Yes winpe Yes 2. Enable debugging options by running the following command: Syntax: bcdedit /store <full path and file name of per-image BCD store> /set <GUID identifier> debug <value> Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set {06689f95f69c-4937-8ded-09a966a6a319} debug on 3. Enable the inheritance of the debug options that are in Default.bcd so that they apply to the operating system entry, using the following command: Syntax: bcdedit /store <full path and file name of per-image BCD store> /set <GUID identifier> inherit {dbgsettings} Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set {06689f95165 f69c-4937-8ded-09a966a6a319} inherit {dbgsettings} 4. Force regeneration of the BCD store in the \Tmp folder by sending a control signal to the server service, using the following command: C:\>sc control wdsserver 129 To Turn On Emergency Management Services Settings For servers equipped with the proper firmware, Emergency Management Services (EMS) provides functionality that you can use to administer a server remotely. This is useful for computers that do not support direct video output or do not have a keyboard and mouse attached. Except for hardware maintenance and replacement, all administrative functions that you can accomplish locally should be available remotely. This includes starting your system and performing system-recovery tasks. This method is typically used for high-end servers in a data center. There are generally two types of devices that support remote administration: those whose BIOS and Extensible Firmware Interface (EFI) support UI redirection, and those whose BIOS does not support UI redirection. The first class of computers is generally EFI-based, typically Itaniumbased servers. The second class of computers have had the video card removed (or the computer did not come with one), and the goal is to redirect output by using a COM port. Support for remote administration is enabled by default for Itanium-based computers that are using configuration settings specified in the default BCD store that was created for Itanium-based clients. These EMS settings are enabled and set to use the BIOS default settings (as opposed to COM port redirection). Each per-image BCD store that is generated for Itanium-based clients is set to inherit these settings from the default BCD configuration. Support for remote administration is not enabled by default for x86-based or x64-based computers that do not support BIOS redirection. To enable this support, you must do the following: Adjust the default NBP to one that supports remote administration (for example, hdlscom1.com, hdlscom1.n12, hdlscom2.com, or hdlscom2.n12). For more information about boot programs and their use, see the "Network Boot Program" section in Managing Network Boot Programs. Signal the loader to support remote administration. You can do this by using BCDedit.exe to set the appropriate EMS options in the default BCD store used for that architecture. You must enable EMS settings and, optionally, you can specify the default port and baud rate. To turn on EMS settings for a particular operating system entry (for OSLoader) 1. Determine the GUID of the operating system entry by running the following command: Syntax: BCDEDIT /store <full path and file name of per-image BCD store> /enum all 166 Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\Images\boot.wim.bcd /enum all Windows Boot Loader ------------------identifier {06689f95-f69c-4937-8ded-09a966a6a319} device ramdisk=[boot]\Boot\x86\Images\boot.wim,{68d9e51c- a129-4ee1-9725-2ab00a957da f} description WinPE 5600 RC1 osdevice ramdisk=[boot]\Boot\x86\Images\boot.wim,{68d9e51c- a129-4ee1-9725-2ab00a957da f} systemroot \WINDOWS detecthal Yes winpe Yes 2. Create the EMS settings option in the Default.bcd store by running the following command: Syntax: bcdedit /store <full path and file name of per-image BCD store> /create {emssettings} /d <description> Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /create {emssettings} /d "EMS Settings” 3. Set the baud rate by running the following command: Syntax: bcdedit /store <full path and file name of per-image BCD store> /set {emssettings} baudrate <value> Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set {emssettings} baudrate 115200 4. Set the output port type by running the following command: Syntax: bcdedit /store <full path and file name of per-image BCD store> /set {emssettings} debugtype <value> Example:C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set {emssettings} debugtype Serial 5. Set the output port number (this should match the output port of the configured network boot program (NBP)) by running the following command: Syntax: bcdedit /store <full path and file name of per-image BCD store> /set {emssettings} debugport <value> Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set 167 {emssettings} debugport 1 6. Determine the GUID of the operating system entry by running the following command: Syntax: bcdedit /store <full path and file name of per-image BCD store> /enum all Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\Images\boot.wim.bcd /enum all Windows Boot Loader ------------------identifier {06689f95-f69c-4937-8ded-09a966a6a319} device ramdisk=[boot]\Boot\x86\Images\boot.wim,{68d9e51c- a129-4ee1-9725-2ab00a957da f} description WinPE 5600 RC1 osdevice ramdisk=[boot]\Boot\x86\Images\boot.wim,{68d9e51c- a129-4ee1-9725-2ab00a957da f} systemroot \WINDOWS detecthal Yes winpe Yes 7. Enable EMS settings in the per-image BCD by running the following command: Syntax: bcdedit /store <full path and file name of the per-image BCD store> /set <GUID identifier> ems <value> Example:C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set {06689f95f69c-4937-8ded-09a966a6a319} ems on 8. Enable inheritance of EMS settings from Default.bcd values as configured above, by running the following command: Syntax: bcdedit /store <full path and file name of per-image BCD store> /set <GUID identifier> inherit {emssettings} Example: C:\>bcdedit /store c:\RemoteInstall\Boot\x86\default.bcd /set {06689f95f69c-4937-8ded-09a966a6a319} inherit {emssettings} 9. Force regeneration of the BCD store in the \Tmp folder by sending a control signal to the server service, using the following command: C:\>sc control wdsserver 129 168 Troubleshooting Troubleshooting Performance Problems Common Problems Logging and Tracing Network Ports Used Required Permissions Troubleshooting Performance Problems This topic contains information about analyzing blockages during each phase of an image installation. For more information, see Optimizing Performance and Scalability. In This Topic Analyzing Blockages in Each Phase of Installation PXE Boot Phase TFTP Download Phase Image Apply Phase Using Performance Monitoring Analyzing Blockages in Each Phase of Installation PXE Boot Phase The Pre-Boot Execution Environment (PXE) boot phase encompasses the initial boot performed by the client computer. This includes obtaining an IP address lease, locating a valid Windows Deployment Services server, and downloading a network boot program (NBP) by using Trivial File Transfer Protocol (TFTP). The amount of data transferred over the network during this phase is minimal, and the end-to-end operation typically succeeds in a matter of seconds. Given the speed at which operations in this phase are completed, you have a few options when it comes to performance tuning. The Windows Deployment Services PXE server can handle several hundred requests per second in sustained throughput. Slight performance decreases can occur if the domain controller is located across a latent network link or is overloaded. In larger environments, consider locating Dynamic Host Configuration Protocol (DHCP) and Windows Deployment Services roles on separate physical computers. 169 TFTP Download Phase The TFTP download phase of the installation process is when the boot image is downloaded to the client computer. Performance in this phase is tied directly to the following factors (in order of importance): Latency between the client computer and the server (measured by the average response time between the server and the client) Size of the boot image. For this reason, increasing boot image size will cause the TFTP download times to increase and will reduce reliability. Typically, the longer it takes to download the boot image, the more likely it is that something could go wrong. Note TFTP block size Other network conditions (such as workload, the quality of the hardware that is installed, and electromagnetic noise considerations) Diagnosing TFTP Download Performance Problems The simplest way to diagnose long download times (observed from the client computer as a progress bar below an IP address) is to look at the average response time between the client and the server it is downloading from. To do this, in Windows PE, open the Command Prompt window, type ping <server’s IP address>, and then note the average latency measured. The output will look similar to the following, where the average latency is less than 1 millisecond (which is good): C:\Windows\system32>ping 10.197.160.93 Pinging 10.197.160.93 with 32 bytes of data: Reply from 10.197.160.93: bytes=32 time=2ms TTL=60 Reply from 10.197.160.93: bytes=32 time<1ms TTL=60 Reply from 10.197.160.93: bytes=32 time<1ms TTL=60 Reply from 10.197.160.93: bytes=32 time<1ms TTL=60 Ping statistics for 10.197.160.93: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 2ms, Average = 0ms High round-trip time values indicate latency on the network, which is an indicator that TFTP download performance will be poor. To improve this performance, consider doing one or more of the following: Use a Windows Deployment Services server that is closer to each client. Remove stress and load from the network segment. 170 If the client connects to the server after multiple network hops, use the output from the tracert command to identify the latent segment, and consider rerouting TFTP traffic to avoid the hop. You can also diagnose TFTP download performance problems by examining a network trace of the download activity. Generally, the best practice is to obtain this trace from the client and server simultaneously to assess exactly where the blockage is occurring (server, client, or network). To do this, add a client and a third computer to a hub, start network traces from the server and the third computer, and then boot the client computer from the network. Addressing TFTP Download Performance Problems In the preceding example, the average latency is less than 1 millisecond, which is good. If the average latency between the client and the server is longer than 5 milliseconds, TFTP performance will be seriously degraded. You may be able to decrease the impact of latency on TFTP download times by increasing the TFTP block size. This means that more data will be sent each time, which cuts down on the number of round-trips. For instructions, see How to Modify the BCD Store Using Bcdedit. Reducing the size of the boot image can also speed up TFTP downloads. To accomplish this, do the following: Use the tools in the Windows Automated Installation Kit (AIK) to create a custom boot image that contains the Windows Setup binary files and Microsoft Windows Preinstallation Environment (Windows PE). For instructions, see Creating Images. Ensure this image has been prepared by using PEIMG.exe /prep. For more information, see PEImg Command-Line Options (http://go.microsoft.com/fwlink/?LinkId=120707). Ensure that the Windows image (.wim) file that contains the boot image does not contain extra space. A best practice is to use the ImageX /export command to export your boot image to a "clean" .wim file before adding the image to the Windows Deployment Services server. For more information, see ImageX Command-Line Options (http://go.microsoft.com/fwlink/?LinkId=120708). Ensure that the .wim file that contains the boot image is using the maximum compression format, LZX. To do this, run Imagex /info ImageFile <ImageNumber|ImageName>. For more information, see ImageX Command-Line Options (http://go.microsoft.com/fwlink/?LinkId=120708). In situations where a server is overburdened, use PXE boot referrals to direct booting clients to different PXE servers for TFTP downloads. For more information, see Managing Network Boot Programs. Alter your physical network topology by doing one or more of the following: Add a PXE server closer to the client computer. Move the client computer closer to the PXE server. Repair the existing network infrastructure (in the case of high-packet loss). Upgrade to better cabling (Cat 5e is recommended). 171 Check the condition of the switches between the client computer and the PXE server to ensure that packets are not being dropped. Image Apply Phase The image apply phase of the installation process involves transferring an install image from the Windows Deployment Services server to the client. This transfer occurs through either Server Message Block (SMB) or multicasting and is the most time-consuming part of the installation process. Diagnosing Performance Problems in the Image Apply Phase To begin, test several client computers on your network, and compare the performance with the test results outlined in the "Performance and Scalability Expectations" section in Optimizing Performance and Scalability. You can also enable logging to gather information. For more information, see the "Windows Deployment Services Client Logs" section in Logging and Tracing. If there are substantial variances between the expected results and your results, you probably have a performance blockage. To troubleshoot common blockages, ask yourself the following questions: Do performance problems occur only at certain times of the day? This may indicate a scalability problem that is probably caused by an overused network or an overburdened server. Do performance problems occur only for clients on a particular subnet or network location? If so, determine whether there is a network issue on that segment. Do performance problems occur only for clients that access a particular server? If so, check the server’s performance statistics as well as the network segment that connects the clients to the server to see whether the server is overused. Performance problems that occur across a larger group of computers generally indicate either a concurrency problem (scalability) or a blockage in the network or server. To investigate, measure the amount of time it takes to download a file (of approximately the same size as the install image) from the server to the client, in Windows PE. Or try to download the install image after it has been placed in a shared folder on the server. If the time it takes to download a large file exceeds the expectations, you should analyze the switch utilization and observe other network metrics to identify the network conditions that are impacting download times. If you suspect that the server is the blockage, use the steps in the Using Performance Monitoring section later in this chapter to identify the root cause of the blockage. Addressing Performance Problems in the Image Apply Phase Performance problems in this phase are generally caused by network congestion, or inadequate resources on the server or client. If network congestion is the issue, consider doing the following: Creating more bandwidth on the network. This may mean upgrading your network infrastructure to support greater bandwidth and higher throughput. For example, it might 172 mean moving from 100 MB to 1 GB, upgrading cabling, replacing hubs with routers or switches, or reducing the number of clients that can access a particular network segment simultaneously. Adding additional Windows Deployment Services servers to the network to handle the network demand. This means segmenting network infrastructure so that smaller groups of clients are answered by each server. Balancing the server load by adding dedicated image servers. For more information, see Storing and Replicating Images Using DFS. Reducing image size. Because larger images mean longer installation times and greater network strain, you should consider creating images that contain minimum customization, drivers, and applications; or consider creating specialized images for each department, hardware type, or function. For more information, see the "Reducing the Size of Images" section in the Servicing Images topic. Most Windows Deployment Services server blockages occur because of inadequate bandwidth (at the network adapter), slow disk subsystems, or insufficient available physical memory. To identify the source of the blockage, use the information in the next section, Using Performance Monitoring. Typical causes of performance problems on individual client computers include the following: Problems with the physical network connection between the client computer and the network topology Problems with the switching equipment A bad disk controller interface on the client computer A bad network adapter on the client computer Insufficient RAM on the client computer (512 MB of RAM is the minimum requirement for Windows Vista) Poorly performing system drivers Using Performance Monitoring You can use Windows Reliability and Performance Monitor to diagnose performance problems with Windows Deployment Services. Note, however, that this is not a complete solution. Because most performance and scalability issues in Windows Deployment Services are network related, network analysis tools may be of greater use. Nevertheless, Windows Reliability and Performance Monitor can be a powerful and quick tool for identifying resource issues on services associated with Windows Deployment Services. The following are the most useful counters for diagnosing Windows Deployment Services performance. To open Reliability and Performance Monitor, click Start, type Performance in the Start Search box, and then press ENTER. To add these counters, expand Monitoring Tools , click Performance Monitor, and then click the green plus sign (+) in the right pane. In Available Counters, scroll to the counter you want to add, and then click Add. Review the following information to maximize your server's performance. 173 Network Interface (Bytes Sent/sec) PhysicalDisk (Avg. Disk sec/Read, Avg. Disk sec/Write, and Current Disk Queue Length ). These disk counters highlight the current disk activity. The Avg. Disk sec/Read and the Avg. Disk sec/Write counter should generally take less than 10 milliseconds, and the maximum should not exceed 50 milliseconds. Anything outside these thresholds indicates that there is too little available disk space to respond to the demands that are being placed on the server. The Current Disk Queue Length counter indicates the backlog of pending input/output (I/O) requests. As you might expect, you do not want to see much here, if anything. Process (Page Faults/sec). Page faults occur when there is not enough physical memory on the server to meet the server's demands. When this occurs, the server has to copy memory from the physical RAM to a swap file on the hard disk drive, and then make room to enable the requested memory allocation to complete. This is a very expensive operation because this swap requires a series of reads and writes on the hard disk drive, and this process must be completed before the operation that caused the fault can resume. On servers where there is not enough memory, page faults can occur frequently, which significantly reduces the amount of processor time that is available to complete any other operations. If there are significant time periods with a lot of page fault activity, you should consider adding memory to the server. Processor (% Processor Time). You can tell from the % Processor Time counter whether there is enough processing power on the server to meet the demands being placed on it. If you see that processor utilization is high, use this counter for each individual process to determine the cause of the degraded performance. If the Windows Deployment Services server is configured to work with File Replication Service (FRS), and the Distributed File System Replication (DFSR) service is consuming a significant portion of processor time, you should consider increasing the boot configuration data (BCD) refresh interval to reduce the number of changes that FRS has to propagate between servers. If the server has multiple server roles, you may want to configure the roles so that they are better distributed across multiple servers. A strong correlation between network utilization and disk reads (and disk throughput) indicates that the network card may be the cause of a reduction in image deployment times. In this case, if you are not concerned with disk throughput, consider upgrading the network infrastructure to support GB Ethernet, or refactoring the Windows Deployment Services server infrastructure so that it is spread across multiple servers. WDS Multicast Server (all counters). The following list describes all of counters for multicasting. Active Clients. This counter shows the clients that are currently connected to a multicast session. Active Contents. Contents refers to the data that is being transmitted. When a client connects to a namespace, a “content” is created. The content is then removed if clients are not active in the content for 5 minutes or longer. You can have multiple contents for a single namespace if there are multiple network cards on the server. 174 Active Namespaces. This counter is essentially equivalent to a multicast transmission. A namespace is the underlying object that gets created when you create a multicast transmission. Incoming Packets/Second (in Bytes). This counter shows the sum of all incoming data packets (per second) from all multicast sessions. Outgoing Packets/Second (in Bytes): This counter shows the sum of all outgoing data packets (per second) from all multicast sessions. Total Data Packets. This counter shows the total number of data packets sent by the multicast server. Total Master Client Switches. This counter shows the total number of times that the master client has been changed in a transmission. Note that the master client is the slowest client in a transmission — that is, the client that is not capable of installing any faster, whereas the other clients may be able to install at a faster rate. Total NACK Packets. A NACK packet is a negative acknowledgement. This counter shows the total number of NACK packets received from client computers. Total Repair Packets. This counter shows the total number of repair packets sent by the server. Note that the server sends repair packets in response to NACK packets. If the number in this counter is high, relative to the Total Data Packets counter, this indicates that packet loss is occurring between the clients and the server. Ideally, the ratio of total data packets to total repair packets should be greater than 100:1. Total Slowdown Request. Clients send slowdown requests when the server is sending data faster than the client can handle it. This is usually caused by slow disk performance on the clients, or by other resource pressure (such as insufficient memory, high CPU utilization, and so on). WDS TFTP Server (all counters). The following list describes the two counters for TFTP. Active Requests. This counter shows the number of active TFTP transfers on the server. Transfer Rate/Second (in Bytes). This counter shows the total amount of data that the TFTP server is sending out per second. WDS Server (all counters). The following list describes the counters for the Windows Deployment Services server. Active Requests. This counter shows the number of currently active requests on the Windows Deployment Services server, including remote procedure calls (RPCs) to the server and multicast requests. Processed/Second. This counter shows the number of requests processed in the last second. Requests/Second. This counter shows the number of requests received in the last second. For more information about Reliability and Performance Monitor, see http://go.microsoft.com/fwlink/?LinkID=110854. For information about how to view these counters, see the following Microsoft TechNet articles: 175 Add Counters Dialog Box (http://go.microsoft.com/fwlink/?LinkId=105531) Creating Data Collector Sets (http://go.microsoft.com/fwlink/?LinkID=55157) Common Problems This chapter highlights some common issues that you may encounter when using Windows Deployment Services including the following: Type Issues Performing PXE Boots on Client Computers I am unable to perform PXE boots on client computers. When I perform a PXE boot and select a boot image, I see a command prompt. The client computer fails to get an IP address when I try to PXE boot. The client computer obtains an IP address but then fails to download a network boot program. I don't see the hard drive of the client computer on the disk configuration page of Setup. My computer loads the boot image, but it cannot access an install image. I created an unattend file, but when installation completes, my client computer is not joined to the domain. Install images do not appear on the image selection page. Troubleshooti ng x64-Based Client Computers My x64-based client computer does not have any x64-based images on the boot image selection page. My x64-based client computer is detected as x64, but it fails to boot to the default image. Performing Management Operations I can't approve a pending computer. I approved a pending computer and then deleted the computer account that was created in AD DS during the process. Now the server will not answer my client computer. I received the error: "0x2: File not found" when trying to use the management tools to manage a remote Windows Deployment Services server. Creating Custom Images When using the Image Capture Wizard to create a custom image, the volume that contains my image is not selectable. The finish button is not enabled on the final page of the image capture wizard. Multicasting My multicast transmissions are running very slowly. After enabling multicasting, there is excessive traffic on the network. 176 Performing PXE Boots on Client Computers I am unable to perform PXE boots on client computers. The most common causes for this issue are: A boot image has not been added to the server. Use the management tools to add the Boot.wim from the Windows Server 2008 media to the server. For instructions, see the Windows Deployment Services Getting Started Guide. The services for Windows Deployment Services have not been started. To fix this, run WDSUTIL /start-server to start all services. Examine the output of the command and the Windows Application event log for error messages indicating service start-up failures. The necessary firewall ports are not open on the server. Ensure that the proper ports are open to enable the client to connect to the Windows Deployment Services server. For more information, see Network Ports Used. The answer policy is not configured correctly. For example, the server is not configured to answer clients, or it is configured to answer only known clients and the client is not prestaged. To fix this, reconfigure the policy. For example, run WDSUTIL /set-server /answerRequests:all. For instructions, How to Manage Client Computers. The computer is marked as approved in the Auto-Add database, but a computer account representing the computer does not exist in Active Directory Domain Services (AD DS). To fix this, purge the database using the steps in Prestaging Client Computers topic. The computer is marked as rejected in the Auto-Add database. After a computer has been marked as rejected, the computer will not be able to PXE boot. You can clear the entry in the Auto-Add database by deleting all pending computer records (by running WDSUTIL /deleteAutoAddDevices /DeviceType:RejectedDevices) or enabling the record to be purged automatically (according to the default cleanup interval). For instructions, see the Auto-Add Database section of How to Manage Client Computers. Client boot requests are not getting routed correctly to the Windows Deployment Services server. To ensure that the IP Helper router is updated and that the Dynamic Host Control Protocol (DHCP) option configuration has been completed correctly, see "Methods of Directing a Client to the Appropriate NBP" in Managing Network Boot Programs. The client has been prestaged and a network boot program (NBP) has been defined; however, the NBP does not exist on the server. Examine the output from WDSUTIL /getdevice /Device:<device name> to determine the name and path of the NBP. Then check that location on the Windows Deployment Services server to ensure that the file exists. If it does not exist, run WDSUTIL /Set-device to direct the client to a different NBP. DHCP and Windows Deployment Services are running on the same physical computer, but the settings associated with this configuration have not been defined. To configure this, see the DHCP section of How to Manage Your Server. For more information, see Configuring DHCP. 177 When I perform a PXE boot and select a boot image, I see a command prompt. If you do not see the UI from Setup.exe when you boot into a boot image, the boot image probably does not contain the Windows Deployment Services client (which is basically Setup.exe and supporting files for Windows Deployment Services). One common cause of this is if you created an image of Windows PE by using the Windows AIK instead of using the Boot.wim file from the Windows Vista or Windows Server 2008 DVDs. To fix this, upload the Boot.wim file located in the Sources directory of Windows Server 2008 DVD. This image contains the Windows Deployment Services client and Windows PE. The client computer fails to get an IP address when I try to PXE boot. The most common causes of this problem are: There is a problem with the network. There is a problem with DHCP. To resolve these issues, check Event Viewer for events and errors, and then refer to the DHCP Infrastructure troubleshooting documentation (http://go.microsoft.com/fwlink/?LinkId=108014) for steps you can use to resolve the problem. If you are using a non-Microsoft DHCP server, contact the manufacturer for troubleshooting information. The client computer obtains an IP address but then fails to download a NBP. You may have a problem with the network or the configuration of the Windows Deployment Services server. A common cause is if a client is on a different subnet from the Windows Deployment Services server and you have not configured the server to get the PXE signal through the router. To fix this, see the "Updating the IP Helper Tables" section in Managing Network Boot Programs. I don't see the hard drive of the client computer on the disk configuration page of Setup. The most common cause of this problem is that the client computer does not have the correct storage driver from the hardware manufacturer. To fix this, do one of the following: Add the driver to the image by using the tools in the Windows AIK. Click Add Driver on the disk configuration page, and then specify the driver. My computer loads the boot image, but it cannot access an install image. The boot image may not contain the correct network driver for the client computer. To resolve this, on the client computer, press SHIFT+F10 to open a command prompt and run IPConfig. If an IP address and subnet mask are not reported in the output, this indicates that networking has not been started and it is likely that a network driver is not present. To fix this, add the driver from the hardware manufacturer to the image by using the tools in the Windows AIK. 178 I created an unattend file, but when installation completes, my client computer is not joined to the domain. There are two common causes for this issue: The image unattend file is not formatted properly. To verify that your file is correctly formatted, see Automating the Domain Join and Sample Unattend Files. The client computer does not have permissions to join a domain. To resolve this, check for an error in \Windows\panther\setupact.log under domainjoininformation, and grant the appropriate permissions. For more information, see Required Permissions. Install images do not appear on the image selection page. The most common causes of this problem are: The account whose credentials were entered on the credential screen of Windows Deployment Services client does not have permissions to read the install .wim file. These images are located at \\<WDSServer>\RemoteInstall\Images\<Image Group>. For more information, see Required Permissions. The architecture of the client computer (x86, Itanium, x64) does not match the architecture type of the install image. A client booting into an x86-based boot image will only be able to view x86-based install images on the image selection page. You may have an incompatible hardware abstraction layer (HAL) type. To deploy an image to this computer, you will need an image that has the correct HAL type — that is, an image that was captured from a computer that has the same HAL type as this computer. Troubleshooting x64-Based Client Computers My x64-based client computer does not have any x64-based images on the boot image selection page. Many x64-based system BIOS do not accurately identify the computer as x64 during the boot process. If Windows Deployment Services does not recognize the computer as x64, only x86 images will be shown. Run WDSUTIL /set-server /architecturediscovery:yes to force the Windows Deployment Services server to recognize x64 computers. My x64-based client computer is detected as x64, but it fails to boot to the default image. If an x64-based computer performs a PXE boot but does not find an x64-based image, it will be unable to complete the boot process. Ensure that your Windows Deployment Services server has the x64-based version of Boot.wim. Alternatively, you can force all x64 clients to only receive x86 boot files by configuring the default boot program—for example, configure Pxeboot.com from \RemoteInstall\boot\x86. For more information, see Managing Network Boot Programs. 179 Performing Management Operations I can't approve a pending computer. The two most common causes of this issue are the following: You do not have the correct permissions in AD DS for the computer. Each computer requires a computer certificate. For more information, see Required Permissions. The computer name is not valid. For example, the name might be too long, or it might contain characters that are not valid. I approved a pending computer and then deleted the computer account that was created in AD DS during the process. Now the server will not answer my client computer. Deleting a prestaged computer that was added to AD DS by using the approval process for pending computer involves two steps: Remove the computer account from AD DS. Remove the record in the Auto-Add database. Failing to remove the record in the database will cause the client to remain in Wdsnbp.com, and it will not proceed with booting from the network. This occurs because the record in the Auto-Add database shows the computer as approved, but a prestaged computer in AD DS will not be found (because the computer was deleted). This scenario is identical to a case where there is AD DS replication latency. For example, the server will not permit the client to proceed past Wdsnbp.com until a prestaged computer appears in AD DS. For more information, see Prestaging Client Computers. I received the error: "0x2: File not found" when trying to manage a remote Windows Deployment Services server. You may have received this error if you are trying to manage a Windows Deployment Services server running Windows Server 2008 from a Windows Deployment Services server running Windows Server 2003.This scenario is not supported. You can only manage Windows Deployment Services servers running Windows Server 2008 from a Windows Deployment Services server running Windows Server 2008. For more information, see Managing a Complex Environment. Creating Custom Install Images When using Image Capture Wizard to create a custom image, the volume that contains my image is not selectable. There are two common reasons for this problem: 180 Cause 1: The boot image does not contain the proper drivers for the computer’s hard disk drive controller. To troubleshoot this, when the Image Capture Wizard first starts, press SHIFT+F10 to open a command prompt. Run Diskpart, and then run lis disk. Select each disk (for example, sel dis 0 and sel dis 1), and then type lis vol to list each volume. Ensure that the volume that contains the offline Sysprep image is viewable. If it is not, you need to add the driver for your mass-storage controller to Windows PE so that it can detect the local disk that contains the offline Sysprep image. To do this, use one of the following procedures: To inject drivers into a boot image, and use the boot image to create a capture image: 1. Add a boot image to your server. 2. Mark the image as offline (disabled). 3. Mount the image by using ImageX and Mountrw (included in the Windows AIK). 4. Insert all of the drivers that use PEIMG.exe into the boot image. 5. Mark the image as online (enabled). 6. Create the capture image using this boot image. To load the driver yourself in Windows PE: 1. Boot into the capture image. 2. Press SHIFT+F10 to access a command prompt. 3. Use Drvload.exe to load the driver. 4. Confirm that you have access to the local disk that contains the offline image. 5. Press ALT+TAB to return to the capture wizard and continue the process. Cause 2: The volume does not contain an image that was prepared using Sysprep. To determine whether the offline image has been prepared using Sysprep: 1. Run regedit to load the offline system hive. 2. In HKEY_LOCAL_MACHINE\System, create a new key called Test. 3. Import the offline system hive from C:\windows\system32\config\system (assuming the offline operating system is located on C:\) into the empty Test key. 4. Examine the two registry keys in the imported system hive that are checked by the wizard: Ensure that HKEY_LOCAL_MACHINE\System\Setup\CloneTag exists Ensure that HKEY_LOCAL_MACHINE\System\Setup\SystemSetupInProgress is set to 1. If either of the registry keys are not set correctly, there are two likely causes: The Generalize check box was not selected when Sysprepwas run. 181 After Sysprep completed, the computer was specialized before the Image Capture Wizard was started. This can happen if you installed Windows Vista, ran Sysprep, rebooted the computer, and then failed to signal the PXE boot in time so that the computer starts to boot and the specialization process runs. You realized your mistake, restarted the computer, and signaled the PXE boot. Then you booted into Windows PE and start the image capture wizard. In this scenario, the wizard will not show the volume because the offline image is no longer generalized. To resolve either of these, boot into the image, run Sysprep again, and then perform the capture process again. The finish button is not enabled on the final page of the image capture wizard. This occurs when a name and location for the .wim file is not specified. You must specify this information even if you are uploading the resulting image to a Windows Deployment Services server. The Image Capture Wizard creates a local copy of the image first, to ensure that transient networking conditions will not interfere with the image capture process. You can specify a location for the .wim file that is on the same volume that is being captured (this will not interfere with the capture process). By default, this local image is not deleted at the conclusion of the image capture process. To delete the file, specify the appropriate unattended installation setting. For more information, see Automating the Image Capture Wizard. Multicasting My multicast transmissions are running very slowly. One typical cause of this issue occurs in environments that contain computers with different hardware configurations and architectures. In this case, some clients can run multicast transmissions faster than others. Because each transmission can be run only as fast as the slowest client, the entire transmission will be slow if there is one slow client. To resolve this issue, first determine the client that is holding back the transmission (this is called the master client). To do this, view the output of the following command: WDSUTIL /Get-AllMulticastTransmissions /Show:Clients. Next, disconnect the master client using WDSUTIL /disconnect-client /ID:<ID>, where ID is the client ID (which you can get using the /get-transmission option). Disconnecting the master client will force it to run the transmission by using the Server Message Block (SMB) protocol, and the other clients' multicast performance should speed up. If they do not speed up, there is a problem with the client's hardware (for example, a slow hard drive) or a network problem. Also, see Example Multicast Scripts for an example script that will automatically disconnect slow master clients. 182 After enabling multicasting, there is excessive traffic on the network. One common cause of this is if Internet Group Membership Protocol (IGMP) snooping is not enabled on all devices. IGMP snooping enables your network hardware to forward multicast packets only to those devices that are requesting data. If IGMP snooping is turned off, multicast packets are treated as broadcast packets, and will be sent to every device in the subnet. In cases where you cannot enable IGMP snooping, you can adjust the multicast packet time-to-live (TTL), which is 32 by default. You can change this by modifying the registry key of the network profile at: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\Multi cast\Profiles\ 32 is sufficient for most network topologies, but if your environment does not support snooping, you can use this setting to somewhat mitigate that. Logging and Tracing You can enable tracing and logging for all Windows Deployment Services components for troubleshooting purposes. The installation logs are stored at %windir%\logs\cbs\cbs.log. This chapter outlines the various logs and output that you can generate. Other than displaying a message that indicates whether the operation succeeded or failed, WDSUTIL shows minimal screen output (by default). However you can specify two additional options to enable more output. You can specify/Verbose to show detailed information about a task, and you can specify /Progress to use ellipses to indicate that a long-running process (for example, adding an image) is running and is not stalled. Even when you use these options, you can redirect the WDSUTIL output to a file. In the sample WDSUTIL command-lines in this section, these options are used wherever they provide useful information. Note You should close the Windows Deployment Services MMC snap-in when you run a WDSUTIL command. If the snap-in is open, the trace logs may not contain messages for some actions. Caution Incorrectly editing the registry might severely damage your system. Before making changes to the registry, you should back up any valued data. Component Obtain and review this output: General status of the Windows Deployment Services server WDSUTIL /get-server /show:all /detailed Windows Application log in Event Viewer Windows System log in Event Viewer Server WDSUTIL /get-server /show:all /detailed 183 Component Obtain and review this output: components Windows Application log in Event Viewer Windows System log in Event Viewer Deployment Services Diagnostics logs in Event Viewer. To locate these logs, expand Applications and Services Logs, expand Microsoft, expand Windows, and then expand Deployment-Services-Diagnostics. The Admin node contains all errors, and the Operational node contains information messages. Trace logs. To obtain these logs, you must first enable tracing in the server and management components by setting the following: HKEY_LOCAL_MACHINE\Software\Microsoft\Tracing\WDSServer Name: EnableFileTracing Value:1 Then you can obtain the trace log at %windir%\tracing\wdsserver.log Management components Enable tracing in the management and MMC snap-in components by setting the following: a. Set the following registry key to enable tracing in the management components: HKEY_LOCAL_MACHINE\Software\Microsoft\Tracing\WDSMGMT Name: EnableFileTracing Value:1 b. Set the following registry key to enable tracing in the management console: HKEY_LOCAL_MACHINE\Software\Microsoft\Tracing\WDSMMC Name: EnableFileTracing Value:1 Then you can obtain the trace logs at %windir%\tracing\wdsmgmt.log and %windir%\tracing\wdsmmc.log. WDSUTIL /get-server /show:all /detailed Windows Application log in Event Viewer Windows System log in Event Viewer Note Although the Windows Deployment Services MMC snap-in and WDSUTIL share the same API layer, in some cases the MMC adds additional processing and functionality. In instances where an error occurs, it is often worthwhile to attempt to reproduce the failure using WDSUTIL to determine if the error is localized to the MMC or 184 Component Obtain and review this output: if it is a general management API failure. Often, WDSUTIL will provide more detailed error output without enabling tracing. Where applicable, use the /detailed, /verbose, and /progress options for extra information. Windows Deployment Services client Logging in the Windows Deployment Services client serves two purposes. First, it allows you to determine if a particular client failed during installation, and it provides details regarding the failure. Second, it allows you to collect information regarding client installations including how many clients installed a particular image, and the success rate for client installs. You can view the logs in the Application event log in Event Viewer. Because a time stamp is logged with each event, you can use this information to determine how long particular phases of the client installation process took to complete. This information is especially useful when diagnosing performance problems or doing performance benchmarking. There are four logging levels: NONE: No logging (default) ERRORS: Errors only WARNINGS: Warnings and errors INFO: The highest level of logging, which includes errors, warnings, and informational events To turn on client logging, run WDSUTIL /Set-Server /WDSClientLogging /Enabled:Yes. To change which events are logged, run WDSUTIL /Set-Server /WDSClientLogging /LoggingLevel:{None|Errors|Warnings|Info} (each category includes all events from the previous categories). Regardless of the logging level, the following information is always logged: Architecture type, Client IP address, MAC address, and computer GUID, Time, and Transaction ID. Based on the configured logging level, some or all of these events are logged: Client started, Image selected, Image apply started, Image apply finished, Client finished, and Client error. To view the logs, obtain the following: Deployment Services Diagnostics logs in Event Viewer. To locate these logs, click Applications and Services Logs, click Microsoft, click Windows, and then click Deployment-Services-Diagnostics. The Admin node contains all errors, and the Operational node contains information messages. Note that in both of these logs, the architectures listed for some errors mean the following: Architecture 0 means x86 Architecture 6 means ia64 Architecture 9 means x64 Setup logs from the client computer. The setup logs appear in different 185 Component Obtain and review this output: places depending on when the failure occurred: If the failure occurred in Windows PE before the disk configuration page of the Windows Deployment Services client has been completed, you can find the logs at X:\Windows\Panther. Use Shift+F10 to open a command prompt, and then navigate to the location. If the failure occurred in Windows PE after the disk configuration page of the Windows Deployment Services client has been completed, you can find the logs on the local disk volume (usually C:\) at $Windows.~BT\Sources\Panther. Use Shift+F10 to open a command prompt, and then navigate to the location. If the failure occurred on first boot after the image was applied, you can find the logs in the \Windows\Panther folder of the local disk volume (usually C:\). Trace log from the Image Capture Wizard. To obtain these logs, do the following: a. Boot into the capture image. b. When the wizard starts, press Shift+F10 to access the command prompt. c. Enable tracing for the wizard. To do this, first run Regedit.exe. Then set the following registry key: HKEY_LOCAL_MACHINE\Software\Microsoft\Tracing\WDSCapture Name: EnableFileTracing Value:1 d. Open a second instance of the Image Capture Wizard. e. Reproduce the failure using the wizard that you just opened. Do not close the original wizard or the computer will restart. Note Note: you can use Alt+Tab to move between windows. f. PXE boot components Obtain the trace log from X:\Windows\Tracing\WDSCapture.log. Enable tracing in the server and management components and obtain the trace logs (as outlined previously). Obtain a network trace that shows the failed boot attempt. It is a best practice to obtain this trace from the client and server simultaneously to accurately assess whether the failure is occurring at the sending server or the receiving client. The process is: a. Place a client and a third computer (laptop or desktop) on a hub. b. Start network traces from the server and third computer. 186 Component Obtain and review this output: c. Boot the client from the network. Note If you are using Network Monitor to obtain the traces, ensure that the buffer size is at least 20 MB. If you configure a bufferf size too small for the capture, then packets will be lost (not appear) in the capture output. Network Ports Used Protocols Windows Deployment Services uses the following protocols for installing images: Dynamic Host Configuration Protocol (DHCP) Pre-Boot Execution Environment (PXE) Trivial File Transfer Protocol (TFTP) Remote procedure call (RPC) Server Message Block (SMB) Multicasting Ports The following table outlines the User Data Protocol (UDP) and Transmission Control Protocol (TCP) network ports that are used during image deployment. You can modify the values that have an asterisk (*) by using the instructions in How to Manage Your Server. UDP TCP 67 135 for RPC 68 if DHCP authorization is required on the server 5040* for RPC 69 137–139* 4011 Random ports from 64001 through 65000*, to establish a session with the server for TFTP and multicasting (in accordance with RFC 1783 at http://go.microsoft.com/fwlink/?LinkId=81027). 187 The following steps explain the UDP and TCP ports that are used during image deployment: 1. The client performs a PXE boot. 2. PXE uses DHCP ports and TFTP to download the binary files. For UDP and DHCP, you need to enable ports 67, 69, and 4011. In addition, TFTP endpoints are used; by default, these endpoints range from 64001 through 65000. For instructions on modifying these ranges, see How to Manage Your Server.You can also use the Network Address Translation (NAT) with the Routing and Remote Access network service to control these ports. 3. In accordance with RFC 1783 (http://go.microsoft.com/fwlink/?LinkId=81027), the client chooses random UDP ports to establish the session with the server. You should use an application exception for TFTP if you have the Windows firewall enabled on the Windows Deployment Services server. 4. The client downloads Windows PE and boots to the Windows Deployment Services client. This download also uses the same TFTP ports as mentioned previously. 5. The Windows Deployment Services client communicates with the Windows Deployment Services server to authenticate and obtain the list of available images. This conversation occurs over RPC because RPC has built-in authentication (it is one of the few completely available protocols in Windows PE). You need to allow the port for the Endpoint Mapper (TCP 135) and the port for the RPC listener for the Windows Deployment Services server (which is TCP 5040 by default). 6. The Windows Deployment Services client installs the selected image. Image transfer occurs through SMB. You need all the file-sharing and printer-sharing ports — for example, TCP 137 through 139 — for installing the image. Note In addition, if DHCP authorization is required on the server, you need DHCP client port 68 to be open on the server. Note that DHCP authorization is not required by default; but you can turn it on manually. Required Permissions This chapter outlines the following permissions and, where appropriate, how to grant them. In This Topic General Permissions Permissions for Common Management Tasks Permissions for Client Installations 188 Permissions for Server Properties Caution To modify the registry settings that are described in this guide, use only the Windows Deployment Services management tools—you should not directly edit these settings and attributes. General Permissions To fully administer a Windows Deployment Services server, you need the following permissions: Local administrator of the Windows Deployment Services server. This gives you the following rights: File permissions and permissions to the RemoteInstall folder (the management tools interact with the image store using UNC paths). Registry hive permissions. Many settings for the Windows Deployment Services server are stored in HKEY_LOCAL_MACHINE\System, and you need appropriate permissions to these locations to change them. Domain administrator of the domain that contains the Windows Deployment Services server. This gives you permissions on the Service Control Point (SCP) in Active Directory Domain Services (AD DS) for the Windows Deployment Services server. Some configuration settings for the server are stored here. Enterprise administrator (optional). This gives you Dynamic Host Configuration Protocol (DHCP) authorization permissions. If DHCP authorization is enabled, the Windows Deployment Services server must be authorized in AD DS before it will be allowed to answer incoming client PXE requests. DHCP authorization is stored in the Configuration container in AD DS. It is often useful to delegate the management of a Windows Deployment Services server to an account other than the domain administrator or enterprise administrator (and grant these general permissions to the delegated account). The delegated administrator account should be a local and domain administrator as specified above. Permissions for Common Management Tasks The following table contains common tasks and the permissions that are required for each. Task Permissions Needed Add or remove an image group Full control over C:RemoteInstall\Images\ImageGroup. Add or remove an image Full control over C:RemoteInstall\Images\ImageGroup. 189 Task Permissions Needed Disable an image Permission to read and write attributes for the associated image file. Disabling an image means hiding the Windows image (.wim) file associated with the image. Add a boot image Read and write access to the following: C:RemoteInstall\Boot C:RemoteInstall\Admin (This folder is only present if you upgrade from Windows Server 2003). %TEMP% Remove a boot image Read and write access to C:RemoteInstall\Boot. Set properties on an image Read and write permissions to the .wim metadata file that represents the image. This file is located within the image group at: C:RemoteInstall\Images\ImageGroup. Prestage a computer Permissions to create accounts in the domain, as well as write to the properties of a computer object. To grant permissions to prestage a computer 1. Open Active DirectoryUsers and Computers. 2. Right-click the organizational unit (OU) where you are creating prestaged computer accounts, and then select Delegate Control. 3. On the first screen of the wizard, click Next. 4. Add the user or group you wish to delegate control to, and then click Next. 5. Select Create a Custom task to delegate. 6. Select Only the following objects in the folder. Then select the Computer Objects check box, select Create selected objects in this folder, and click Next. 7. In the Permissions box, select the Write all Properties check box, and click Finish. Approve a Read and write permissions for the folder that contains the database file pending computer Binlsvcdb.mdb in the RemoteInstall share (for example, C:RemoteInstall\MGMT). The actual account of an approved pending computer is created by using the server’s authentication token, not the token of the administrator who is performing the approval. Therefore, in AD DS, you must grant rights to the Windows Deployment Services server’s account (WDSSERVER$) to create computer account objects for the containers and OUs where the approved pending computers will be created. 190 Task Permissions Needed To grant permissions to approve a pending computer 1. Open Active Directory Users and Computers. 2. Right-click the OU where you are creating prestaged computer accounts, and then select Delegate Control. 3. On the first screen of the wizard, click Next. 4. Change the object type to include computers. 5. Add the computer object of the Windows Deployment Services server, and then click Next. 6. Select Create a Custom task to delegate. 7. Select Only the following objects in the folder. Then select the Computer Objects check box, select Create selected objects in this folder, and click Next. 8. In the Permissions box, select the Write all Properties check box, and click Finish. Prestage a computer to join a domain The user account must have permissions to join the domain. The JoinRights registry setting determines the set of security privileges, and the User registry setting determines which users have the right to join the domain. To change the per server (per architecture) defaults, you need read and write permissions to these registry keys. The JoinRights setting is located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDS Server\Providers\WDSPXE\Providers\BINLSVC\AutoApprove\<arch> Name: JoinRights Type: DWORD Value: 0 = JoinOnly.; 1 = Full. A user that has Join only rights cannot join the domain without administrator assistance (an administrator with proper permissions on the computer account object must reset the computer account before the client installation and domain join).A user that has Full rights can reset the account and join the domain without administrator assistance. The User setting is stored at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDS Server\Providers\WDSPXE\Providers\BINLSVC\AutoApprove\<arch> Name: User Type: REG_SZ Value: Name of group or user. For this setting, there are two administration models that you can use. 191 Task Permissions Needed (recommended) You can associate a primary user to the account at the time the computer is approved. When the computer is approved, the computer account will grant the primary user 1) read and write permissions on all properties on the computer object (JoinRights = JoinOnly or JoinRights = Full), and 2) reset and change password rights on the computer object (JoinRights = Full). You can specify server defaults for the user and JoinRights that apply to all approved clients of a given architecture. The default values grant domain administrators the Full join right. If you do not assign a primary user to the computer account at the time of approval, these default values will take effect. Note If you are creating computer accounts against a non-English domain controller and you are using the default user property, you must set the Auto-Add settings to use a different account that does not contain extended characters. If the account contains a non-standard character (any character outside [A-Z, a-z, 0-9, \, -, and so on]), such as German's "Domänen-Admins", then Auto-Add will fail. To change this value, see the help at the command prompt for WDSUTIL /set-server /AutoAddSettings. Convert a RIPREP image Create a discover or capture image Read and write permissions to the %TEMP% directory and destination location Read permissions on the original RIPREP image Read and write permission to the %TEMP% directory and destination location Read permissions on the original boot image Create a multicast transmission Full control over the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDS Server\Providers\Multicast Read permissions to RemoteInstall\Images\ImageGroup. Modify a multicast Full control over the following registry key: transmission (for HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSSer example, delete, ver\Providers\Multicast deactivate, start, stop, disconnect, and so on) 192 Permissions for Client Installations In general, performing a client installation requires domain user rights. However, additional permissions may be required depending on the scenario. This section outlines the minimal set of permissions that are required to perform common installation tasks. Task Permissions Needed PXE boot a client computer No permissions are required to PXE boot a client, and no mechanism exists to secure the process of booting from the network. If security is the primary concern for you, we recommend that you use physical media (for example, that contains a discover image) to boot each computer. Select a boot image No permissions are required to select a boot image and no mechanism exists to secure entries that are displayed in the list. The first authentication mechanism occurs using the Windows Deployment Services client running within Windows PE. Select an install image The credentials provided in the user interface of the Windows Deployment Services client must be those of a domain account. After a client has been authenticated to the Windows Deployment Services server, the authenticated user must be able to read the install .wim file and Res.rwm file from the RemoteInstall folder. By default, authenticated users have permissions to do so. Join a domain The JoinRights registry setting determines the set of security privileges, and the User registry setting control which users have the right to join the domain. For more information about these settings, see the Prestaged a computer to join a domain section in the previous table. If the computer is prestaged, then the user performing the installation (or the credentials in the Unattend file for the domain join) needs the appropriate JoinDomain rights. If the computer is not prestaged (meaning Windows Deployment Services will create a computer account in AD DS), the user performing the installation (or the credentials as specified in the Unattend file for the domain join) need rights to add a prestaged computer and the appropriate JoinRights. Using /ResetBootProgram If the ResetBootProgram functionality is enabled, the user needs read and write permissions to the netbootMachineFilePath property on the prestaged computer object. If this permission is not granted and the user's boot program is set to pxeboot.n12, Windows Deployment Services will not be able to reset the NBP to pxeboot.com, forcing the computer into an infinite reboot loop. For more information, see 193 Task Permissions Needed Managing Network Boot Programs. Disabling access to the command prompt during installations By default, users can gain access to a command prompt during Windows Deployment Services installations by: Pressing Shift+F10 when Setup is running in Windows PE. Pressing Shift+F10 when the Image Capture Wizard is running in Windows PE. Holding down the CTRL key when Microsoft Windows Preinstallation Environment (Windows PE) is booting. Pressing Shift+F10 when the Out of Box Experience (OOBE) is running (OOBE is the wizard that usually runs after Setup). Important A Command Prompt window that is opened during OOBE will be running in the system context. If this window is not closed at the conclusion of Setup, the user may have access to it and therefore, system rights, even though the user is not a local administrator on the client computer. You can disable this functionality by adding a DisableCmdRequest.tag to the image. To disable access for boot images 1. In the Windows Deployment Services MMC snap-in, right-click the desired boot image and select Disable. 2. Mount the image for read and write access using ImageX which is provided in the Windows Automated Installation Kit (AIK). For more information about ImageX, see the ImageX Technical Reference (http://go.microsoft.com/fwlink/?LinkID=120693). 3. Create the file %windir%\Setup\Scripts\DisableCmdRequest.tag in the mounted image. 4. Commit the changes and unmount the image. 5. In the Windows Deployment Services MMC snap-in, right-click the desired boot image and select Enable. . To disable access for install images 1. In the Windows Deployment Services MMC snap-in, right-click the desired boot image and choose Disable. 2. Export the image to an external .wim file. 3. Mount the image for read and write access using the tools provided in the Windows AIK. 4. Create the file %windir%\Setup\Scripts\DisableCmdRequest.tag 194 Task Permissions Needed in the mounted image. 5. Commit the changes and unmount the image. . 6. In the Windows Deployment Services MMC snap-in, right-click the disabled install image and choose Replace Image. 7. Follow the instructions in the wizard to re-import the modified install image. Permissions for Server Properties The following section outlines the minimal set of permissions that are necessary to perform common management tasks using the server properties pages. To access these settings, open the Windows Deployment Services MMC snap-in, right click the server, and click Properties. Tab Settings that Require Permissions PXE Response Settings PXE response policy. The PXE response policy (for example, responding only to known clients, or responding to all clients) is stored on the server’s SCP. Configuring these settings requires read and write permissions to the SCP object. To grant permissions to the SCP object a. Open Active Directory Users and Computers. b. Click View, and then click Advanced Features (if it is not already enabled). c. Right click the computer account for you Windows Deployment Services server, and click Properties. d. On the Remote Install tab, select Advanced Settings… e. Select the Security tab, and click Add… f. Select the user, and then select Full Control on this object. PXE response delay. Configuring this setting requires read and write permissions to the following registry key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSSERV ER\Providers\WDSPXE\Providers\BINLSVC Name: ResponseDelay Type: REG_DWORD Value: Number of seconds to wait before answering PXE client requests Directory Services New client naming policy. This setting is stored in the SCP object on the server. The property is called: netbootNewMachineNamingPolicy 195 Tab Settings that Require Permissions Boot Client account location. This setting is stored in the SCP object on the server. The property is called: netbootNewMachineOU Default boot program Server-wide: This option is controlled by the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServe r\Providers\WDSPXE\Providers\BINLSVC\BootPrograms\<arch> Name: Default Type: REG_SZ Value: Path to server-wide client default boot program for this architecture. For example: boot\x86\pxeboot.com Per computer: The computer account attribute is: netbootMachineFilePath Default boot image Server-wide: This option is controlled by the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServe r\Providers\WDSPXE\Providers\BINLSVC\BootImages\<arch> Name: BootImagePath Type: REG_SZ Value: Path to server-wide client default boot image for this architecture. For example: boot\x86\images\boot.wim Client Per computer: The computer account attribute is: netbootMirrorDataFile Unattend file Server-wide: This option is controlled by the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServe r\Providers\WdsImgSrv\Unattend\x86 Name: FilePath Type: REG_SZ Value: Path to server-wide client Unattend file relative to the RemoteInstall folder. For example: WdsClientUnattend\WdsUnattend.xml Per computer: The computer account attribute is netbootMirrorDataFile Client account creation This option is controlled by the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServe r\Providers\WDSPXE\Providers\BINLSVC Name: NewMachineDomainJoin Type: DWORD 196 Tab Settings that Require Permissions Value: 0 to prevent domain joining by clients; 1 to enable it. DHCP Do not listen on Port 67. This option is controlled by the following registry key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSSERV ER\Providers\WDSPXE Name: UseDhcpPorts Type: DWORD Value: 0 disabled; 1 enabled Advanced Configure DHCP option 60 to "PXEClient".This requires that the user is able to configure the Microsoft DHCP server running on the local computer. DC/GC used by the Windows Deployment Services server (this server). These settings are stored at the following registry location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServe r\Providers\WDSPXE\Providers\BINLSVC The keys for these settings are as follows: Default domain controller: Name: DefaultServer, Type: REG_SZ, Value: FQDN for default domain controller. Default global catalog server: Name: DefaultGCServer, Type: REG_SZ, Value: FQDN for default global catalog server. DHCP authorization. Performed using DHCP APIs—you need permissions to authorize the Microsoft DHCP server. 197
