Windows Deployment Services Technical Reference

Microsoft Corporation Published: March 2009 Author: Trina Gorman

Abstract
This guide provides technical information about Windows Deployment Services in Windows Server® 2008. It includes in-depth information about the components that make up this server role, how the components interact, and how Windows Deployment Services interacts with other technologies, such as Active Directory.

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 Technical Reference.....................................................................1 Abstract....................................................................................................................................1 Copyright information......................................................................................................................2 Contents..........................................................................................................................................3 Windows Deployment Services Components.................................................................................7 Windows Deployment Services Server Components......................................................................7 In This Topic.................................................................................................................................7 Windows Deployment Services Server Architecture....................................................................7 Diagram of Deployment Server Components...........................................................................8 Diagram of Transport Server Components...............................................................................9 RemoteInstall Folder Physical Structure....................................................................................10 Auto-Add Database Architecture...............................................................................................10 PXE Server Components..............................................................................................................12 In This Topic...............................................................................................................................12 What Is the PXE Server.............................................................................................................12 What Is the BCD Store..............................................................................................................12 The BCD Store Physical Structure.............................................................................................13 Image Store Components.............................................................................................................14 Windows Deployment Services Client Component.......................................................................15 In This Topic...............................................................................................................................15 What Is the Windows Deployment Services Client?..................................................................15 Windows Deployment Services Client Architecture...................................................................15 Windows Deployment Services Client Protocol.........................................................................16 Windows Deployment Services Processes...................................................................................17 How the Boot Configuration Data Store Works.............................................................................17 In This Topic...............................................................................................................................17 How Windows Deployment Services Determines the BCD Store..............................................18 How the BCD Store Is Created..................................................................................................18 How Booting into a Boot Image Works..........................................................................................19 In This Topic...............................................................................................................................19 Overview....................................................................................................................................19 RAMDISK Boot Image Process.................................................................................................20

..................22 How Unattend Works for the Remaining Setup Phases.....32 In This Topic........................................................21 How Unattend Works for the Windows Deployment Services Client..................................28 How the Image Store Works........................................................................................................................................39 How Domain Controllers and Global Catalogs Are Used...38 How Domain Controllers and Global Catalogs Work..39 In This Topic....................................26 Automatic Detection....29 In This Topic................................................................................................................................32 How Prestaged Devices Work.....................27 Manually Invoking Setup.................................................................................................................................................................................36 Diagram of the Auto-Add Policy..................................................41 How PXE Requests Work............................................................................................................................................................................................................................................................................40 How Windows Deployment Services Uses PXE..................................................................36 How Computers in a Pending State Are Handled.......................................................................................................................34 Examples......................................................................................................................................33 When Prestaged Clients Are Joined to a Domain........................................................................................................................................................................................................................................................................................24 How the Client Deals with Discover Images....................................................................................................................................36 In This Topic..............................................................................................................................................................................................................................................................................23 How the Windows Deployment Services Client Works.....................30 How Images Are Captured...........................................................................................................................................................................................................................................................34 Diagram of Prestaging Clients................................................................................................................................................................................................................................................................................41 ...........................................................................................39 How BINLSVC Communicates with Domain Controllers.....................30 How Images Are Compressed........................................................41 How PXE Requests Are Handled............................................................................................................................................................................32 How Prestaged Clients Are Located..........................21 In This Topic.............................................24 How the Client Applies Install Images.....................................................................................................................................41 In This Topic.......23 Diagram of the Unattended Setup Process......................................................................................exe...................25 When Setup Is Started in Windows Deployment Services Mode...........................................................................32 In This Section.....................28 Diagram of Startup Logic........................................................................................................................................................................................................39 How Joining a Computer to a Domain Works....30 How Images are Enumerated....35 How the Auto-Add Policy Works.........................................How Unattended Installation Works....................................29 When Images Are Verified.......................................................................31 How Windows Deployment Services Uses Active Directory.................

............................................................................................................................................................................................................................54 DHCP..............................................................................................................................56 PXE......60 Network Boot Programs....................................43 Architecture Detection.........................................................................................................................................45 How DHCP Authorization Works............................................................56 Configuring the Server to Bind to UDP Port 67 .................................................61 ..................................................................................42 How a Computer Is Identified....................................................................................49 How an NBP Is Downloaded..................57 Banned GUIDs.....................................................................................................................................50 x86-based and x64 BIOS-based computers with architecture detection...................................................................................................................................54 DHCP Authorization Cache.....................................................................................................................................................................................................................................................................................................................56 Architecture Detection..........................................................48 In This Topic..................................................................................................................................................................................52 Critical Providers for the WDSServer Service..........................57 Order of PXE Providers..........................................................44 How the PXE Response Delay Works........50 Itanium-based and x64 EFI-based computers................................................................54 DHCP Authorization.....................................................................................................................................................47 How Network Boot Programs Work.................................................................................................................................................................................................................................................................................................................................................................................................44 Example Scenario.......................................60 Per-Architecture Unattend Policy...................................................................46 How the PXE Server and Providers Interact.................51 Windows Deployment Services Registry Entries....................................45 In This Topic..........................46 How TFTP Works in Windows Deployment Services............................................................................................................................................................................When Clients Are Answered..........59 Unattended Installation.................................................................57 PXE Providers That Are Registered..................................................55 Configuring the PXE Server Not to Listen on UDP Port 67............................................................................................................................................................................................51 How PXE Referrals Work....................50 x86-based and x64 BIOS-based computers.........53 Client Answer Policy... or referrals.......................................................................................................................................................57 Bind Policy for Network Interfaces...................................................................56 PXE Response Delay.......................................................................................................................................................................................................................................45 How the PXE Server Works.................................................................................................................60 Per-Client NBP..........................................................................................................................................................53 Logging for the Windows Deployment Services Client..................................................................................58 Location of TFTP Files....43 Banned GUIDs.....................................................................................48 How Windows Deployment Services Determines the NBP...........................................60 Server Unattend Policy................................................................................ pending devices...

...63 Settings for Approved Client Computers...................................................................................................................................................64 Domain Controllers and the Global Catalog...................................................................................63 Time-Out Value......................................................................65 .................................65 Search Order.............................................................................................................................62 Auto-Add Policy......63 Message Displayed to a Pending User..............................Unknown Clients Automatically PXE Boot...............................................65 Static Configuration...........................................................................................................................................................................................................................................................................................62 Auto-Add Devices Database.....................n12 NBP....61 .................................................................................................................................................................................61 Resetting the NBP to the Default on the Next Boot........................................................

7 . thread pooling. Windows Deployment Services Server Components In This Topic • Windows Deployment Services Server Architecture • • • • Diagram of Deployment Server Components Diagram of Transport Server Components RemoteInstall Folder Physical Structure Auto-Add Database Architecture Windows Deployment Services Server Architecture The Windows Deployment Services server service (WDSServer) is the main server-side service of this deployment solution. The Windows Deployment Services server service (WDSServer) is the main server-side service. and the Trivial File Transfer Protocol (TFTP) provider. unattend processing. and installing an operating system image. These components are associated with booting a client computer from the network.Windows Deployment Services Components Windows Deployment Services contains five main components: • Windows Deployment Services Server Components. It provides basic functions such as memory management. thread pooling. • Image Store Components. and network interface binding to support its subcomponents (known as providers). enabling you to select and install an install image. and install image enumeration. • Windows Deployment Services Client Component. known as providers. It is the protocol used for communication to and from the client and server. This includes the Pre-Boot Execution Environment (PXE) server. and network interface binding to support its hosted subcomponents.exe program from Windows Vista with some additional functionality that is needed for network deployments. It provides basic functions such as memory management. the PXE providers. These components are associated with assisting the Windows Deployment Services client in locating. This application is the Setup. • PXE Server Components. selecting. The Windows Deployment Services client is an application that runs within Microsoft Windows Preinstallation Environment (Windows PE).

TFTP is the protocol used to download the boot image. The image store component.com. Therefore. which is the module used for Pre-Boot Execution Environment (PXE) booting. Provider Description Wdspxe.dll registers itself with the WDSServer service and requests a remote procedure call (RPC) endpoint.The providers provide the true functionality associated with the service. called PXE providers.dll Wdsmc.exe.dll (see the following diagram).com.dll. it is loaded by Wdsmc.dll Diagram of Deployment Server Components The following diagram shows the interaction among these components for the Deployment Server role service. wdstftp. For more information.dll). Note that it is not loaded directly into WDSServer. The Windows Deployment Services PXE provider. and to boot files such as Pxeboot. wdsmc.dll. these providers are marked as "critical" — meaning that if the provider does not load and initialize successfully.dll Wdsimgsrv. which is the module used by the Windows Deployment Services client when communicating with the server. Wdsnbp.bcd. see PXE Server Components.dll. the WDSServer service should log an error and not start. The server registers an RPC endpoint for communication between client and server.dll Wdstftp.dll The PXE server. The Trivial File Transfer Protocol (TFTP) server.dll. and Default. the server would be entirely useless or severely limited in functionality without them. These providers are listed and described in the following table. The multicast server. which is used as part of the management operations for Auto-Add device functionality. Bootmgr. Note that the PXE server itself also has its own set of providers. The multicast content provider. instead. Binlsvc. Although technically the WDSServer service can start without these providers. 8 . It is also a PXE provider that is loaded by Wdspxe. and wdscp. Binlsvc.dll Wdscp. There are six providers that are included with the Deployment Server installation (note that the Transport Server installation includes only Wdspxe.

Diagram of Transport Server Components The following diagram shows the interaction among these components for the Transport Server role service. 9 .

and the Windows Deployment Services management tools. This value is also specified in the command line to approve or reject the device. • Templates. which is shown here. This is the same database that is used by AD DS. 10 MACAddress UUID . Contains the install images. and Exchange. You enable the policy on the PXE Response Settings tab of the server's properties. Contains RISETUP and RIPREP images. Contains the Auto-Add devices database. • WdsClientUnattend.mdb) can be found in the RemoteInstall\MGMT folder. Field name Description RequestID An automatically generated number that uniquely identifies the request. a file share with the default folder name RemoteInstall and the default share name REMINST is created to contain install images. Contains the boot images and the associated PXE boot files.xml) files used by the Windows Deployment Services client. to support computer naming and domain join scenarios. • • • Boot. This folder is present only if you upgrade from Windows Server 2003. This folder is present only if you upgrade from Windows Server 2003. Auto-Add Database Architecture The Auto-Add database (named Binlsvcdb. The MAC address of the client. notify administrator and respond after approval check box. The database consists of a single table. The computer GUID of the client. Contains temporary files used by Windows Deployment Services.RemoteInstall Folder Physical Structure When the server is configured. • OSChooser. PXE boot files. Contains management tools specific to Remote Installation Services (RIS) functionality. Images. boot images. Contains an image unattend template for images from an earlier version of Windows. • Tmp. Contains the RIS menu screens and associated PXE boot files. The RemoteInstall folder contains some or all of the following subfolders: • Admin. This folder is present only if you upgrade from Windows Server 2003. Windows Internet Name Service (WINS). • Setup. Mgmt. including the Boot Configuration Data (BCD) stores. by selecting the For unknown clients. The database that is used for this is the Extensible Storage Engine (ESE) database. The database is created by Windows Deployment Services the first time the Auto-Add policy is enabled. Contains the unattend installation files (Unattend.

and WDSUnattendFilePath come from the defaults for the Auto-Add policy that are defined on the Windows Deployment Services server. this field is set to TRUE. BootProgramPath. When Wdsnbp. The suggested organizational unit (OU) for where the computer account will be created. The same status is used for the device. there should never be a case in which a unique device has more than one record in the database.microsoft. The referral server. 0 = Pending 1 = Approved 2 = Rejected Status StatusChangeTime StatusChangeUser Architecture ReferralServer BootProgramPath MachineOU Owner BootImagePath WDSUnattendFilePath MachineName The time stamp that indicates when the status was last changed. 11 . The client architecture.com is downloaded by the client. see How to Manage Client Computers (http://go. If a device was previously added to the database.com/fwlink/?LinkID=115265). This way. The owner of the computer account. you see only one pending request from server. Owner. Therefore. and Active is set to FALSE. and the corresponding record will be used. All requests are uniquely represented in the database by the RequestID value.Field name Description Active Windows Deployment Services adds a record when it receives the DHCP request from a client. The name of the computer that was added (not a calculated value. Windows Deployment Services will search the table for the MACAddress. The boot program that the client should use. The relative path to the Windows Deployment Services client unattend file. The name of the user who changed the status. Image Path. MachineOU. The relative path to default boot image. but the actual computer name that was used). You can override these values when the device is approved. Boot. For information about changing these values. All of the values for ReferralServer.

and it supports a plug-in interface. The PXE provider installed by default (on a Deployment Server) is BINLSVC. The PXE server implementation for Windows Deployment Services is divided into two pieces: a PXE server (WDSPXE) and the PXE providers. the request may be forwarded to the next provider in the list. This means that when a PXE request is received.” and they can be developed by Microsoft or independent software vendors. Plug-ins are called “PXE providers. WDSPXE maintains a list of providers. That provider has the opportunity to answer. What Is the BCD Store Microsoft has completely reengineered the boot environment for Windows Vista to address the increasing complexity and diversity of modern hardware and firmware. and so on. • Run multiple providers on a single server. WDSPXE contains the core networking capability. you can have one PXE listener on the network with two or more sets of application logic. One new aspect is a new firmware-independent data store that contains boot configuration data (BCD). Rather than having two PXE listeners on the network (each with its own application logic). This PXE implementation enables you to do the following: • Change the provider. Note that you can add a provider to the list by registering it with WDSPXE. see the “PXE Providers That Are Registered” section of the Windows Deployment Services Registry Entries topic. Note that BINLSVC is not installed with Transport Server. the Windows Deployment Services server will hand the request to the first provider in the list. The BCD store defines how the boot menu is configured. The end goal is to enable a client computer to boot from the network and receive a network boot program (NBP) from a server. For more information.PXE Server Components In This Topic • • • What Is the PXE Server What Is the BCD Store The BCD Store Physical Structure What Is the PXE Server Pre-Boot Execution Environment (PXE) technology is a standard created by Intel that establishes a common and consistent set of pre-boot services within the boot firmware. The providers enable you to develop individual PXE solutions while taking advantage of the core networking PXE code base that is included with Windows Deployment Services. and the order of providers determines how a client request is handled. Depending on the response from that provider. You can remove BINLSVC from the server and replace it with a custom provider. The store is a namespace container for BCD objects and elements that holds the information that is required for loading Windows or running other 12 .

This is all kept in memory after being read by the boot manager. and description) is contained in the BCD element list. For this reason. These options are defined in a BCD store for each architecture. The boot manager reads the BCD store into a set of boot entries that describe the operating systems and tools that can be started. These settings include the following: • General boot manager settings. This file consists of the Default. 13 .wim.bcd). These BCD stores reside in the folder that contains the boot image (for example. located at RemoteInstall\Boot\<arch>\Default.com/fwlink/?LinkID=65818). The previously active BCD store is not purged immediately.wim file. The following rules apply: • • The current (in-use) architecture-specific BCD store is not purged by this process.bcd file from the \Boot\x86 folder and all boot image BCDs from the \Boot\x86\Images folder.bcd file from the \Boot\ia64 folder and all boot image BCDs from the \Boot\ia64\Images folder. The client attempts to download FileA and fails because the file was purged. such as the path to the Boot. For more information about BCDs.com/fwlink/?LinkID=110353 and Boot Configuration Data Editor Frequently Asked Questions (http://go. and each boot image on the server has a corresponding BCD store that contains a boot loader entry (which describes how to boot that particular image).wim and RemoteInstall\Boot\<arch>\Images\Boot. see http://go. FileA is deleted. This helps you avoid the scenario in which a client boots from the network and is referred to pick up FileA. The file has the same file name as its corresponding . the previously active file is deleted after clean-up. There are boot settings that are common to any available operating system displayed in the boot menu. The BCD Store Physical Structure There are four possible classes of client computers.microsoft. A boot entry consists of the GUID for the application to start and a list of the application’s BCD elements. FileB.bcd. • Debugger settings related to enabling debugging in the loader. a BCD store is a binary file in the registry hive format. the relevant information about a boot entry (its application path. Meanwhile. A clean-up thread deletes the contents of the \Tmp folder at a specified interval (the default interval is every 24 hours). Physically. a change on the server has triggered the creation of a new file. • The device options for booting Microsoft Windows Preinstallation Environment (Windows PE) from RAMDISK.sdi file.boot applications. RemoteInstall\Boot\<arch>\Images\Boot. This file consists of the Default. Each boot image is represented in the BCD store as an available Windows boot loader option.microsoft. • Itanium-based. operating system path. The architecture-specific BCD stores are created in the \Tmp folder. As a result. such as the time-out value (the period of time after which the default operating system is selected automatically). so four BCD stores are created in the \Tmp folder: • x86-based.

rwm file. X86. This file consists of the Default. Image Store Components The image store is a collection of image groups that stores the .log. {RandomGUID}. The storage structure of the image group uses the imaging feature called “capture by reference. The image store in Windows Deployment Services takes this concept a step farther by creating a split media set consisting of two parts: one part that contains an “empty” .bcd file from the boot\x86 folder and all boot image BCDs from both the \Boot\x86\Images and \Boot\x64\Images folders.rwm file is actually a . Each . the . but the actual file resources for the image reside in Res. Although the file name seems to indicate otherwise.rwm) contains the file resources for all of the images in an image group.bcd (for example.” This feature is most commonly used with “split” . to apply an update).wim file.wim images and helps the client computer obtain and install the images. which are the smaller pieces that result when you break up a large .wim files. For more information. File resources are single-instanced because they are shared across the image group. • <imagename>. This file consists of the Default. To service an image (for example.rwm file. An image group consists of the following two components: • The Res.wim file (Res. An image group is a collection of images that share security options and file resources.rwm. Old BCD stores that are not currently in use by active clients are kept for 24 hours (to ensure that they are not still going to be used by a booting client that is responding very slowly). Each image group has its own Res.wim image file contains the metadata that describes the image.bcd file from the \Boot\x64 folder and all boot image BCDs from the \Boot\x64\Images folder.wim files. and another part that contains all the file resources for an image.wim file (typically so that you can fit the pieces of the file onto CDs).bcd). If debug tracing is active. The GUID ensures that any newly generated BCD store will not interfere with or overwrite an existing BCD store. you must have access to the Res.wim file that contains only the definition of the image. • x86-based and x64-based (this corresponds to if you run WDSUTIL /set-server /DefaultX86X64ImageType:both).• x64-based.{05FF3388-7D71-46A1-AE8A704480979281}.rwm file. 14 . see How the Boot Configuration Data Store Works. you can see the current active BCD store for each architecture in the Windows Deployment Services server’s debug log at: %windir%\Tracing\Wdsserver. This storage method is more efficient than the Single Instance Store service used in Remote Installation Services (RIS) in Windows Server 2003. The naming convention for constructed BCD stores is as follows: Architecture. They are then deleted by BINLSVC. The resource .

WDSclientapi. This mode differs from the normal Setup. The platform for running the client is Windows PE 2. Windows XP.exe only when it is in the Windows PE phase of Setup. WDScsl. including an authentication and credentials page • The ability to handle more advanced unattended installation scenarios. and WDSimage. including obtaining an unattend file from a Windows Deployment Services server and performing variable string replacement • The ability to deploy install images from Windows 2000. Setup.exe mode in that the Windows Deployment Services client has the following features: • Logic to interact with a Windows Deployment Services server to retrieve the list of available install images and perform the installation • A unique set of user interface (UI) screens.dll). This application is. in fact. The following diagram illustrates the Windows Deployment Services client architecture. The Windows Deployment Services client module and the supporting DLLs are loaded by Setup.exe program from Windows Vista and supporting DLL files (including WDSClient. 15 .Windows Deployment Services Client Component In This Topic • • • What Is the Windows Deployment Services Client? Windows Deployment Services Client Architecture Windows Deployment Services Client Protocols What Is the Windows Deployment Services Client? The Windows Deployment Services client is an application that runs within Microsoft Windows Preinstallation Environment (Windows PE).0.dll. and Windows 2003 along with Windows Vista and Windows Server 2008 Windows Deployment Services Client Architecture The Windows Deployment Services client consists of the Setup. enabling you to select and install an install image from a Windows Deployment Services server.dll.exe from Windows Vista with some additional functionality that is needed for network deployments.dll.

Obtains a Windows Deployment Services client unattend file. This initial session is an anonymous session that uses unencrypted RPCs. this is port 5040). This session is created using the normal RPC process. Retrieves a list of available install images from the server. The Windows Deployment Services server then does the following: • Uses this information to determine whether the client is prestaged. the Windows Deployment Services client starts networking and initiates communication with the Windows Deployment Services server. the Windows Deployment Services client connects (through RPC) directly to the Windows Deployment Services server. timezone) so that these values may be used during installation. First. • Obtains domain join settings.exe is started.Windows Deployment Services Client Protocol The Windows Deployment Services client communicates with the image store of the Windows Deployment Services server by using a control protocol used for passing information between the client and the server. 16 . the client binds to the Windows Deployment Services server’s End Point Mapper to determine which RPC port the Windows Deployment Services server is listening on (by default. Next. When Setup. • Performs subsequent processing on the server to direct the client to the proper unattend file and domain join settings (if these have been configured). the client sends information (such as GUID) to the image store. • Obtains a list of well-known settings (for example. The communications protocol does the following: • • • Sends GUID and MAC addresses to the server. This protocol is an application-level protocol that uses remote procedure calls (RPCs) over Transmission Control Protocol (TCP). During this initial session.

a BCD store is a binary file in the registry hive format.wim and RemoteInstall\Boot\<arch>\Images\boot. At this point. For more information about BCDs.bcd). One aspect of this reengineering is a new firmware-independent data store that contains boot configuration data (BCD). In This Topic • • How Windows Deployment Services Determines the BCD Store How the BCD Store Is Created 17 . The BCD store defines how the boot menu is configured.microsoft.wim. After the server has the client’s credentials. the session between the client and server switches to encrypted RPC. The store is a namespace container for BCD objects and elements that hold the information that is required to load Windows or run other boot applications.wim file. The file has the same file name as its corresponding .• Authenticates the client. based on the credentials entered in the UI or in unattend settings. Physically.com/fwlink/?LinkID=110353. Windows Deployment Services Processes • • • • • • • How the Boot Configuration Data Store Works How Booting into a Boot Image Works How Unattended Installation Works How the Windows Deployment Services Client Works How the Image Store Works How Windows Deployment Services Uses Active Directory How Windows Deployment Services Uses PXE How the Boot Configuration Data Store Works Microsoft has completely reengineered the boot environment for Windows Vista to address the increasing complexity and diversity of modern hardware and firmware. These BCD stores exist in the folder that contains the boot image (for example. RemoteInstall\Boot\<arch>\Images\boot. see http://go. image enumeration occurs during a secured session.

If one exists.com). • If no BCD store exists in the same folder as the NBP (that netbootMachineFilePath pointed to). the server creates a BCD store that contains an operating system entry for the image. But if you manually copy a file. This process happens automatically when the Windows Deployment Services server is started and BINLSVC is initialized. How the BCD Store Is Created The Windows Deployment Services PXE Provider (BINLSVC) creates a BCD store for each image. 18 . first create a folder on the server as a subfolder of the RemoteInstall folder. BINLSVC enumerates each .com/fwlink/?LinkID=115265). the changes will not be automatically picked up. it will be used. To produce a BCD store that contains the required information. prestage the device and set netbootMachineFilePath to point to the custom folder on the server that was created for that device. The next step in the BCD generation process is to create the BCD store that a client computer will download.com and there is a BCD store in that folder. The following sequence of steps outlines this process.How Windows Deployment Services Determines the BCD Store The netbootMachineFilePath attribute specified on a computer object in AD DS can contain either a redirection to a different server (for a Pre-Boot Execution Environment (PXE) referral) or the path and name of a network boot program (NBP) that the client should receive. the changes will be picked up. If you add or modify a boot image while the service is running. as long as the following are true: • A corresponding BCD store for the image does not already exist. If you use the Windows Deployment Services management tools to make changes.microsoft.bcd is concatenated with the information stored in the per-image BCD stores.wim file within the appropriate \Boot\<arch>\Images folder. The following logic is used for determining which BCD store file the client should receive: • If the netbootMachineFilePath attribute is specified. the Name Binding Protocol will look for a BCD store in the same path as the NBP that netbootMachineFilePath points to. When it finds an image. Finally. Windows Deployment Services will send the architecture-specific BCD store in the \Tmp folder.wim file is newer than the matching BCD store. This enables you to specify a BCD store for each computer. and it looks for images that are marked as bootable from RAMDISK. the information stored in Default. pxeboot. You can change the netbootMachineFilePath by using the management tools. For more information. if you renamed the image and expected the new name to be reflected in the boot menu display). see How to Manage Client Computers (http://go. if netbootMachineFilePath points to \RemoteInstall\Boot\x86\test\pxeboot. • The time stamp of the . To do this. the server must be signaled that a change has occurred before it will begin the BCD creation and update process. This would be the case if the image metadata was updated (that is. For example. then copy the custom BCD and NBP (for example. it will be used.

If the flat file directory exists on the network. Windows PE will attempt to load and run directly over the network without first copying the files locally to the client computer. The boot image is downloaded while booting from the network and saved to this location. 3. BINLSVC receives a signal to begin creating a BCD store. Windows PE is booted directly from the flat file directory. With this format. Device options -------------identifier {68d9e51c-a129-4ee1-9725-2ab00a957daf} 19 . The boot loader options for each boot image BCD store are obtained from the per-image BCD stores (located in the \Boot\<arch>\Images folder) and then inserted into the new BCD store in the \Tmp folder. Windows PE is then run directly from that media.bcd file is copied from the RemoteInstall\Boot\<arch> folder to the \RemoteInstall\Tmp folder. Windows PE files live in a flat file directory structure (not an image). With this method. First. This device object defines the parameters that are necessary to create the actual RAMDISK by defining the disk volume file. 1. How Booting into a Boot Image Works In This Topic • • Overview RAMDISK Boot Image Process Overview You can boot Windows Preinstallation Environment 2.0) in either of two formats: • Flat file. Step 1: Select an operating system entry. The following is sample output from the BCD store obtained by using Boot Configuration Data Store Editor. 2. or GUID). One boot image is marked as the default. This method of booting Windows PE 2. an operating system entry is created that specifies the operating system image and references the RAMDISK device object (by its globally unique identifier. a device object is created to represent the RAMDISK object.0 is not available when booting from the network. The following steps outline the general process when booting to RAMDISK. The Default. • RAMDISK. a virtual disk volume is created in the RAM to hold the boot image (which contains Windows PE). This causes the regeneration of all BCD stores for all architectures. Second. The Boot Configuration Data (BCD) format contains two entries that signify a RAMDISK boot.1.0 (Windows PE 2. 4. You can overwrite the default image by using the Boot tab of the server's properties in the MMC snap-in. The first alphabetic image will be the default image (unless you overwrite it).

SDI Windows Boot Loader ------------------identifier device 4ee1-9725-2ab00a957daf} description osdevice 4ee1-9725-2ab00a957daf} systemroot detecthal winpe \WINDOWS Yes Yes WinPE 5472 with NIC ramdisk=[boot]\Boot\x86\Images\Boot. serves both of these functions. The BIOS or Extensible Firmware Interface (EFI) of the computer signals a request to boot from the network. 2. 1. The operating system loader contains code to mount the volume and search the NTFS file system for a . A RAMDISK boot image must be in a .sdi file is a disk image that has been formatted with the NTFS file system. and it must be explicitly marked as being able to boot from RAMDISK. Step 2: Create the RAMDISK. PXE ROM downloads a network boot program (NBP) by using Trivial File Transfer Protocol (TFTP).{68d9e51c-a129{7c7c9843-cb93-4096-a930-1d6ab763a4d0} ramdisk=[boot]\Boot\x86\Images\Boot.wim file may contain multiple images.sdi file into memory and pointing the loader at that file as if it were an actual disk.wim. RAMDISK Boot Image Process The following steps describe the overall process for booting into a boot image from the network. The RAMDISK itself involves two parts: a disk (volume) image and a file-system. 20 . skip to step 5. You can mark the image as bootable by using the /boot option in ImageX when either creating (for with the /capture.wim file. stored on the RemoteInstall folder during the initial configuration of the server.{68d9e51c-a129- 2. only one image can be marked as able to boot from RAMDISK.ramdisksdidevice ramdisksdipath boot \Boot\Boot. 3. Although a . Marking an image with the /boot option causes certain properties of the image to be propagated to the header of the . PXE ROM gets an IP address from a Dynamic Host Control Protocol (DHCP) server and locates a server. /append. Step 3: Boot Windows PE. The process of booting from RAMDISK involves placing the Boot.wim file that contains the boot image.sdi file. for example) or modifying (with the /info option.wim.wim file (which is looked at by the loader when it is trying to discover what image is bootable). The . and /export options. For EFI. for example) the boot image. 3. The \boot\boot.

You can configure the boot menu to be in a different language. In This Topic • • • How Unattend Works for the Windows Deployment Services Client How Unattend Works for the Remaining Setup Phases Diagram of the Unattended Setup Process 21 . in . so the user can see a progress bar. How Unattended Installation Works This topic contains information about the process that takes place when you perform an unattended installation.wim file to the disk. This replaces the Boot. 7. The TFTP download occurs using the UDP stack from the PXE ROM. Font files for the boot menu.4. The following diagram illustrates what happens in the RAM of a client computer.sdi disk image. The RAMDISK is produced by creating the disk image in memory and appending the . using the User Data Protocol (UDP) stack from the PXE ROM. A Boot Configuration Data (BCD) store. b. so these files are downloaded to display the localized boot menu. c.wim file. The loader downloads (using TFTP) the associated files needed to boot into Windows PE from RAMDISK. The boot image. These files include the following: a. An . 5. Windows PE boots by using the image in the .wim format. The TFTP protocol is implemented in the loader. The NBP downloads the operating system loader by using TFTP. 6. which tells the loader how to boot the operating system. d.ini file.

2. which triggers Setup to read the unattend settings and populate the relevant data.How Unattend Works for the Windows Deployment Services Client You can configure unattended installation based on per-computer settings or per-server settings (with per-computer settings taking precedence). 4. the process continues.xml. 22 . If it is off. the process continues. that unattend file will be used. This includes the values that are used to prestage the client (the computer's GUID or MAC address) and the client's architecture (because many settings are architecture specific). This policy is defined globally and specifies whether Windows Deployment Services client unattend functionality at the server level is currently on or off. and writes it to X:\sources\wdsunattend\wdsunattend. The Windows Deployment Services server determines the unattend file to send to the client. the client will be passed the unattend file for its architecture. The Windows Deployment Services server reads the data from the client unattend file and then passes the data (not the file) to the client through the RPC communication channel. At the conclusion of the Windows Deployment Services client installation phase. The Windows Deployment Services client starts networking and connects to the Windows Deployment Services server by using the remote procedure call (RPC) communication protocol. no further action is required (as far as unattend is concerned). The process works as follows: 1. • If the device is found but does not have a specified Windows Deployment Services client unattend file. de-serializes it. Setup then proceeds in Windows Deployment Services mode For more information. 3. 6. The server then queries for an account in Active Directory Domain Services (AD DS) that matches the GUID or MAC address. • If the device is found and has a specified Windows Deployment Services client unattend file. If it is on. the Windows Deployment Services client unattend file is discarded and an image unattend file replaces it for the remaining phases of Setup. see “When Setup Is Started in Windows Deployment Services Mode” in How the Windows Deployment Services Client Works. • If the device is not found (meaning that it has not been prestaged). This entire transaction occurs over unauthenticated RPC because the client has not yet entered credentials. 7. The Windows Deployment Services server checks its own unattend policy. The Windows Deployment Services client sends information to the server that will help the server identify the client. The Windows Deployment Services client receives the data. 5. The client notifies Setup about the unattend file.

5. however. • For Windows Vista and Windows Server 2008 images. The Windows Deployment Services client queries the server to determine whether the image has an associated unattend file (for Windows Vista images only). Setup resumes in the OfflineServicing unattend pass. • For images from an earlier version of Windows. locates the unattend file. the Windows Deployment Services client copies the entire $OEM$ folder structure associated with an image (note that the $OEM$ structure is optional). 23 . Diagram of the Unattended Setup Process The following diagram illustrates the process that take place during an unattended setup. that if an image unattend file was also directly associated with an image. which triggers Setup to read the unattend settings and populate the relevant data. 2. this structure may contain the image unattend file. the unattend file is copied to the RAMDISK of the boot image as X:\sources\wdsunattend\WdsImageUnattend. and begins processing any remaining settings that are specified in the unattend file. Setup starts in the applied image. 3. 4. Be aware. the image unattend file will take precedence over the unattend file in the $OEM$ folder. The Windows Deployment Services client replaces the unattend variables and injects the domain join information into the temporary copy of the image unattend file. the Sysprep. The client notifies Setup about the unattend file.How Unattend Works for the Remaining Setup Phases The image unattend process works as follows: 1.inf file should be placed in the $OEM$\$1\Sysprep folder.xml. If it does. At the conclusion of the image apply phase. The computer reboots into the applied image.

How the Windows Deployment Services Client Works
The Windows Deployment Services client is an application that runs within Microsoft Windows Preinstallation Environment (Windows PE),enabling you to select and install an install image from a Windows Deployment Services server. This application is, in fact, Setup.exe from Windows Vista running in Windows Deployment Services mode. • • • How the Client Applies Install Images How the Client Deals with Discover Images When Setup Is Started in Windows Deployment Services Mode

How the Client Applies Install Images
When you perform a Pre-Boot Execution Environment (PXE) boot on a computer and select a boot image, the Windows Deployment Services client performs the following actions: 1. Determines that Setup should start in Windows Deployment Services mode. 2. Starts Windows PE networking (if it is not already started). 24

3. Discovers a Windows Deployment Services server (this may be from the PXE registry key or by using a discover image). 4. Establishes an unsecured session to the Windows Deployment Services server. 5. Determines the Windows Deployment Services client logging level (if specified) and starts the logging process. 6. Checks to determine whether there is an unattend file for the Windows Deployment Services client. 7. Proceeds through the Windows Deployment Services client UI screens (UI language selection, keyboard layout, and credentials). 8. Establishes a secure session to Windows Deployment Services server by using the user's credentials. 9. Receives a list of images from the server and displays it to the user. 10. Receives a list of external language packs (for images for Windows Vista and Windows Server 2008). 11. Proceeds through the Windows Deployment Services client UI screens (image selection, disk configuration, and progress). 12. Applies the image. When performing multicast deployments, the image is copied and then applied. However, when using unicast functionality, the image is applied over the network and is not copied to the client computer. All data is sent in compressed blocks of data. When these data blocks are received, the data is expanded and written to the disk. 13. Services the offline image (for example injects drivers). 14. Sets boot parameters (for example, the Boot Configuration Data (BCD) display language). 15. Copies the $OEM$ folder (if it exists) for the image. 16. Applies a language pack (if necessary). 17. Retrieves the value of unattend variables (for example, timezone) from the server. 18. Checks for a per-image unattend file and copies it (if it exists). 19. Checks domain join settings in the unattend file (for example, whether or not to join the domain, what computer name to use, what domain to join, what credentials to use, and so on). 20. Creates an account in Active Directory Domain Services (AD DS) for the computer, if necessary. If an account already exists, the client resets the account. 21. Performs variable replacement on the unattend file (including time zone, domain join settings, and so on). 22. Restarts the computer.

How the Client Deals with Discover Images
When you perform a PXE boot on a computer and select a discover image, the Windows Deployment Services client performs the following actions: 25

1. The client downloads the boot image from the server and the image boots. At boot time, Setup.exe is invoked and it parses any command-line options that were passed to it. Setup sees that it is in Windows Deployment Services discovery mode and connects to the specified server to download the install image. 2. Setup.exe (Autorun) is launched automatically by Windows PE (through the commands specified in WinPEshl.ini). 3. Setup.exe (Autorun) parses the command lines passed to it (at a minimum, setup.exe /WDS /WDSDiscover, and optionally, setup.exe /WDS /WDSDiscover /WDSServer:MyWDSServer). Setup realizes that it should be in Windows Deployment Services mode. Autorun continues to run in the background (never showing UI) and invokes regular Setup.exe with the command-line arguments as they are passed in. 4. Setup.exe detects that it is in Windows Deployment Services discovery mode. One of the following occurs: • If a server name was specified using the /WDSServer option, the Windows Deployment Services client contacts that server directly. (Skip to step 7.) • If /WDSServer was not specified, the client will initiate a PXE request by broadcasting a Dynamic Host Control Protocol (DHCP) discover packet with the PXE option (option tag 60 set to the string PXEClient) to destination port UDP 67. The client waits for a response from a valid PXE server. The emulated PXE request sent by the Windows Deployment Services client adheres to the standards specified by the PXE specification (including using the specified response delay settings). 5. When a valid Windows Deployment Services server is located, the client sends a DHCP request packet to UDP port 4011 of the responding PXE server (in the case of static mode, the client sends the packet to the server specified with /WDSServer). The client expects a valid response (DHCP acknowledgment signal, or ACK) from the PXE server. 6. The client connects to the Windows Deployment Services server by using the specified communication channel, and the normal installation steps continue.

When Setup Is Started in Windows Deployment Services Mode
Setup.exe in Windows Vista is composed of many modules. When Setup.exe is started, it loads the appropriate modules. The Windows Deployment Services client (implemented as WDSclient.dll) is one of these modules. There are two ways to start Setup.exe in Windows Deployment Services mode: • • Automatic Detection Manually Invoking Setup.exe

26

wim file contains its own \Sources folder that includes the Setup. meaning that the computer was booted from some other media (such as a DVD. or it can be implicitly discovered through code in Windows PE. or hard disk drive). When Setup. This method is used when you use the Boot. CD. The Windows Deployment Services client uses this information to 27 . At boot time. USB key. you must manually invoke the Windows Deployment Services mode of Setup.ini file.exe to detect automatically that it should start in this mode. If the answer to either or both of the following questions is No.exe looks at the data in the BootServerReply value of HKLM\System\CurrentControlSet\Control\PXE.exe file and associated files. Windows PE must start a shell application. The Boot.exe is running. Windows PE automatically starts the application. a response packet containing boot server information (such as the IP address and name of the network boot server) is inserted into the registry of the boot image at HKLM\System\CurrentControlSet\Control\PXE.wim from the Windows Vista media (in the \Sources folder).exe in the \Sources folder and. You can explicitly define this application by using entries in the WinPESHL.ini file does not exist or if it contains an empty [LaunchApp] section. Setup. This information is preserved throughout the boot process because it is passed from the loader to the kernel in the loader message block (it is inserted into the registry by the kernel). two additional checks are automatically performed to determine whether Setup should start in Windows Deployment Services mode. Windows PE looks for Setup. In the latter case. If the Windows PE instance was not booted. Setup will not start in Windows Deployment Services mode.Automatic Detection The default method and most common way to invoke the Windows Deployment Services client is for Setup. if the program is present there. This value controls the following two aspects of starting Windows PE: • The fact that the key exists is an indicator that the Windows PE instance was booted from the network. Check Explanation Was Windows PE started by using PXE boot? When a computer running Windows Vista PXE boots. This happens if the WinPESHL. • The packet contains the IP address of the PXE server that the boot image was downloaded from.

Setup will start in normal mode.exe is started from a shared network folder. Windows Deployment Services is not present in the environment. the next check is to locate where Setup. Diagram of Startup Logic The following diagram that illustrates the Windows Deployment Services client startup logic 28 .exe is running. \sources\setup. This is particularly valuable if you want to run Setup from a Windows PE instance that was not started by a PXE boot.Check Explanation determine which Windows Deployment Services server to contact.exe is running from a location other than the system drive.exe to start in this mode by specifying the /wds option on the command line when starting Setup (for example. • If Setup. Setup will start in Windows Deployment Services mode. In this scenario.exe is running from the same location as the system drive of Windows PE (for example. This accounts for the case in which Windows PE is booted from a nonMicrosoft PXE server and Setup. and Setup. Manually Invoking Setup.exe to start in Windows Deployment Services mode. • If Setup.exe will therefore not start in Windows Deployment Services mode. Is Setup. X:). You can force Setup.exe /wds).exe It is possible to force Setup. Note that you will receive an error if you use the /wds command outside of Windows PE.exe running from the Windows system drive? Before starting in Windows Deployment Services mode.

The image store is a collection of image groups. An image group is a collection of images that share security options and file resources.How the Image Store Works The image store stores the . In This Topic • • • • When Images Are Verified How Images Are Enumerated How Images Are Compressed How Images Are Captured 29 .wim images and helps the client computer obtain and install the images.

The following sequence of steps outlines this process. Credentials are specified on the client computer (either manually or in an unattend file). The types of images that Windows Deployment Services verifies are as follows: • • • • Images that you create by using the Image Capture Wizard Images that you add to the server Images that you export (the external image file that was exported is verified) Images that you replace on the server How Images are Enumerated Install images are enumerated between the Windows Deployment Services client and the image store. The Windows Deployment Services client performs additional image filtering. The following table shows the expected compression type for each action. and the user is authenticated. Note that only files within the first level of the image group folder are enumerated. 1. 8.wim file. folders and subfolders are not enumerated. The server sends information for all images that the user has permissions to view back to the Windows Deployment Services client. The valid compression types are as follows: no compression. and the access control list (ACL) of the file. the folder that contains the . including . The verification process compares the Secure Hash Algorithm (SHA-1) hashes of the image file with known good values from either a check block in the . A remote procedure call (RPC) communication channel is established between the client and the server. 3.wim metadata. This shortens the time for the image enumeration and ensures that other .wim files within the image store. An authentication token is obtained by the server for the user who is logged on.wim file. and LZX (maximum compression). 4. XPRESS (quick compression).wim file or the hashes of the actual files. Although the decompression times are essentially equivalent for both the XPRESS and LZX types. if necessary. 6.wim files (such as data . 30 . The server enumerates all . the initial compression time (performed when the image is created) is longer for LZX. 7. The list of available images is displayed to the user on the image selection page.When Images Are Verified Windows Deployment Services verifies each block of images to ensure that the source image file is not corrupt. file name of the . How Images Are Compressed All images within an image group share the same compression type. Any ACLs that were found during enumeration are checked against the user. 2.wim files in a $OEM$ folder structure) are not accidentally returned during the enumeration process. 5.

and language). You boot the computer into the capture image. 1. 7. architecture. Create a new capture image. No compression type The same compression type as the image The same compression type as the image group The current image group compression type The same compression type as the . those settings are used. operating system version. 31 . The Image Capture Wizard searches for the WDSCapture. • If the file does not exist. The Image Capture Wizard scans all local drives for an offline image that has been prepared with the Sysprep tool.wim file. The Image Capture Wizard extracts metadata from data points in the offline image (such as the hardware abstraction layer (HAL) type. LZX LZX LZX How Images Are Captured The screens in the Image Capture Wizard walk you through the process of capturing the image.inf file in the X:\Windows\System32 folder. The Image Capture Wizard captures the selected volume and saves it to the specified . Append an image to an existing . 6. 3. • If the file exists and contains settings. 4. The default compression type is XPRESS. 2.wim file. Convert a RIPREP image.Action Expected compression type Create an image group. Add the first image to an image group. as described in the following sequence of steps. Note that the wizard does not have the ability to capture a partial volume. you must enter the missing information in the UI. Create a new discover image. • If the file exists but settings for a particular section are missing. Add subsequent images to an image group. Create an install image by using the Image Capture Wizard. in addition to any values that were input by the user. you must enter the missing information in the UI. Export an image. The Image Capture Wizard updates the metadata of the image with the information that was extracted from the offline image. product name and type. 5.wim file Either LZX or XPRESS. The Image Capture Wizard is started.

The computer account object for the Windows Deployment Services server contains a child object called an SCP object.8. as well as the server from which the client should download the boot files. How Windows Deployment Services Uses Active Directory Windows Deployment Services uses Active Directory Domain Services (AD DS) for a variety of reasons. They correspond to physical devices that will boot from the network by using Windows Deployment Services. which means to link a physical computer to a computer account object in AD DS. and it indicates that the computer account object is acting as a Windows Deployment Services server. you can control the installation for the prestaged device. You can prestage a device. and it contains all of the necessary helper routines. The SCP object also stores some configuration settings for Windows Deployment Services (for example. The data used by Windows Deployment Services is stored in computer account objects and Service Control Points (SCPs). By doing this. AD DS is its data store. In This Section • • • How Prestaged Devices Work How the Auto-Add Policy Works How Domain Controllers and Global Catalogs Work How Prestaged Devices Work Prestaged clients are computer account objects that are created within Active Directory Domain Services (AD DS) before the operating system is installed. whether the server should answer Pre-Boot Execution Environment (PXE) boot requests). • Computer account objects. Windows Deployment Services also links physical booting computers to computer account objects in AD DS. using WDSUTIL you can configure the network boot program and the unattend file that the client should receive. For example. This object is created the first time Windows Deployment Services is started. In This Topic • • How Prestaged Clients Are Located When Prestaged Clients Are Joined to a Domain 32 . The Image Capture Wizard uploads the image to the Windows Deployment Services server (optional). • Service Control Point objects.

Windows Deployment Services can locate prestaged clients by using either of the following: • GUID (recommended). The GUID format occurs in two formats: • String format (also known as wire format). it contains both of these values in the DHCPREQUEST packet.com/fwlink/?LinkId=115268). and the MAC address is in the Ethernet Source Address part of the packet. The PXE server forwards the PXE request to the Windows Deployment Services server.microsoft. and searches for a match on either value. This filter ensures that a device will be found if it is prestaged using either a computer GUID or a MAC address. If a match is found. Example (using the same GUID as the first bullet): {67452301-AB89EFCD-0123-456789ABCDEF} The management tools enable you to specify the GUID in either format. if you prestage the MAC address of Server1. For example. You can use the Ldp GUI tool to view this value. 33 . The following are three scenarios in which the booting device will not be uniquely identified and the server will return an error: • Two computers are found in AD DS with the same computer GUID. For details. then you build and prestage Server2 by using the network adapter from Server1.• Diagram of Prestaging Clients How Prestaged Clients Are Located When a client computer attempts to boot from the network. • MAC address. • Two devices in AD DS represent a single physical computer — one device prestaged with a computer GUID. The netbootGUID attribute on a prestaged client is used to store the value of the physical computer’s GUID or the MAC address. The following is the Lightweight Directory Access Protocol (LDAP) search filter used by Windows Deployment Services: (&(objectCategory=<DN of Computer Schema object>)(| (netbootGUID=<GUID>)(netbootGUID=MAC))). Example: 0123456789ABCDEF0123456789ABCDEF • Display format. binds against an AD DS server. the client is considered unknown. The computer's GUID is in the Dynamic Host Control Protocol (DHCP) options (tag 97 in DHCP options). If no match is found. limited data is transferred from the client to the server as part of the Pre-Boot Execution Environment (PXE) protocol. see How to Perform Common Tasks (http://go. Now you have two prestaged devices in AD DS with the same MAC address. and the other one prestaged with a MAC address. The first part of the address is unique to the company that produced the device and is a sequence of digits that are unique to a device manufactured by that company. • Two computers are found in AD DS with the same MAC address. the client is considered known. The server extracts both pieces of information. When a PXE request is submitted. A computer's GUID is a unique 32-character hexadecimal value supplied by the manufacturer of the computer that is stored within the system BIOS. The MAC address is a 128-bit hardware address that uniquely identifies each node of a network.

In all cases where Windows Deployment Services creates a computer object to facilitate the domain join process. the computer name and location in AD DS). see the “Prestage Computers” section in How to Manage Client Computers (http://go. You can override this by running the /JoinDomain:No command on the command line (for example. the account that is created will contain either the client's GUID or MAC address (as stored in the netbootGUID attribute). from a failed hard disk drive). 34 .microsoft. If a client computer is not prestaged. the computer will be joined to the same domain using the same computer name. the per-server policy settings dictate the domain join behavior (for example. This automatic prestaging is beneficial because if you rebuild a computer (for example. WDSUTIL /Set-Device /Device:Computer2 /User:Domain\user /JoinRights:JoinOnly /JoinDomain:No). For instructions on setting these options. Diagram of Prestaging Clients The following flowchart shows the connections that the Windows Deployment Services PXE provider (BINLSVC) will make to locate a prestaged device and read its attributes.When Prestaged Clients Are Joined to a Domain If a client computer is prestaged in AD DS. the client will be joined to the domain as the prestaged device.com/fwlink/?LinkID=115265).

The object is not found. Result: BINLSVC connected to one server. AD DS attributes are read from there. Global catalog-A also contains a writeable copy of the prestaged device object in its domain controller partition. The object is not found. depending on your configuration. BINLSVC connects to global catalog-A to determine whether the object exists in the forest. No further action is required by BINLSVC.Examples The following example cases outline the Windows Deployment Services search behavior. which means that either the device has not been prestaged or AD DS replication latency has caused the device not to replicate to that global catalog. Note that you would run WDSUTIL /Set-Server /DomainSearchOrder:GCOnly (also the default configuration) to search global catalogs first and then search domain controllers. The object is not found. you would run WDSUTIL /Set-Server /DomainSearchOrder:DCFirst to search domain controllers first and then search global catalogs. The object is not found. Case C /DomainSearchOrder:GCOnly BINLSVC connects to global catalog-A. Case E /DomainSearchOrder:DCFirst BINLSVC connects to domain controller-B. The object is found. Global catalog-A does not contain a writeable copy of the prestaged device object in its domain controller partition. BINLSVC must connect to domain controller-B to read the additional Windows Deployment Services attributes from the computer object. Conversely. Scenario Result Case A /DomainSearchOrder:GCOnly BINLSVC connects to global catalog-A. Case B /DomainSearchOrder:GCOnly BINLSVC connects to global catalog-A. Result: BINLSVC connected to two servers. Result: BINLSVC connected to two servers. The object is found. BINLSVC connects to global catalog-A to determine whether the object exists 35 . Therefore. Case D /DomainSearchOrder:DCFirst BINLSVC connects to domain controller-B. Result: BINLSVC connected to one server.

The object is not found. The object is found. Result: BINLSVC connected to one server. Therefore. BINLSVC must connect to domain controller-C to read the additional Windows Deployment Services attributes from the computer object. Case F /DomainSearchOrder:DCFirst BINLSVC connects to domain controller-B. Result: BINLSVC connected to two servers. The following steps detail the process a pending computer goes through to get approved: 1. A client Pre-Boot Execution Environment (PXE) boot request is received by the PXE server and passed to Windows Deployment Services. The object is found. BINLSVC reads additional Windows Deployment Services attributes from domain controller-B.Scenario Result in the forest. 36 . The object is found. Global catalog-A also contains a writeable copy of the prestaged device object in its domain controller partition. How the Auto-Add Policy Works In This Topic • • How Computers in a Pending State Are Handled Diagram of the Auto-Add Policy How Computers in a Pending State Are Handled If a computer requires approval before the installation will start. AD DS attributes are read from there. the computer will be in a pending state. Case G /DomainSearchOrder:DCFirst BINLSVC connects to domain controller-B. Global catalog-A does not contain a writeable copy of the prestaged device object in its domain controller partition. BINLSVC connects to global catalog-A to determine whether the object exists in the forest. Result: BINLSVC connected to three servers.

If the device is approved. the device is answered and Auto-Add policy is not used. • The computer and all of its properties will be added to a domain controller where the computer account object will be created. • If the device does not exist in the Auto-Add devices database. Windows Deployment Services queries AD DS. 37 . The Auto-Add policy is queried. • If the device is rejected. The device will re-enter the pending state on the next reboot if the Auto-Add Devices database still contains the computer entry. If the server is set to answer all clients — even those that are not known — the process continues. • If the user cancels the PXE request. this computer has not attempted to boot before. The Auto-Add devices database is queried. • If the device does exist in the Auto-Add devices database and the status of the device is approved. Additionally. the device will boot from the next device in the boot order. using the Auto-Add policy settings (if a name was not specified when you approved the device using the WDSUTIL command-line utility or the MMC snap-in). it will be sent the file Abortpxe. 6. causing the device to boot to the next device in the boot order. The device remains in the pending state until one of the following occurs: • If the device is approved. If the Auto-Add policy is set to answer only known clients and the client is not prestaged. Skip to step 8. the device is added to the Auto-Add devices database. it is possible for you to override the defaults when you manually approve a device. the process continues. • If the device times out. then the client will await approval from the administrator. then the client installation will proceed. the client request is ignored. and the device will be added to AD DS. If pending functionality is enabled. the following will occur: • A unique name is created for the device. • The computer is sent another network boot program (NBP). the process continues. Skip to step 7. the client request is ignored. If pending functionality is not enabled. • If the device does exist in the Auto-Add devices database and the status of the device is rejected. the device is placed into the pending queue awaiting AD DS replication. 3. the default settings will be used. the client request is ignored. 4. If the device is not prestaged. 5. the device will boot from the next device in the boot order. Actions beginning at step 3 will be repeated per the client’s defined polling interval. Windows Deployment Services checks the Auto-Add policy to see it should answer clients. If the Auto-Add policy is set to answer clients. If the device is prestaged. it is sent the settings for its architecture. • If pending functionality is turned on. If the Auto-Add policy is set to not answer clients. 8.2. 7. If you did not specify this NBP when the device was approved.com.

Diagram of the Auto-Add Policy The following diagram illustrates the Auto-Add policy. If this process fails. • The computer record is updated to approved in the Auto-Add devices database. 38 . the device is still answered.Note All computer properties as set on the prestaged computer account are immediately in effect (as if the client had always existed in AD DS and Windows Deployment Services searched and found it there).

The credentials of the user are entered into the credentials page. this is the computer account created in step 3. the client receives the domain join policy setting for unknown accounts. the client receives the value of the JoinDomain registry setting as configured by /JoinDomain command line option. For nonprestaged accounts. BINLSVC resets the client computer account in AD DS. When joining a computer to a domain. 3. 39 . 2. How Domain Controllers and Global Catalogs Are Used AD DS topologies are generally organized by domain and by site. and other objects. BINLSVC creates a computer object in Active Directory Domain Services (AD DS). A domain is a collection of user objects. For nonprestaged computers. the domain. BINLSVC looks for an image unattend file. either manually or by using an unattend file. BINLSVC is in charge of communicating with Active Directory. These objects share a common directory database. 4. 5. BINLSVC performs the following sequence of steps. and the computer password (for Windows Vista images)) is inserted into the image unattend file.How Domain Controllers and Global Catalogs Work In This Topic • • • How Joining a Computer to a Domain Works How BINLSVC Uses Domain Controllers and Global Catalogs How BINLSVC Communicates With Domain Controllers How Joining a Computer to a Domain Works The Windows Deployment Services Pre-Boot Execution Environment (PXE) provider is named BINLSVC. • If an image unattend file does not exist. and computer password (for Windows Vista images)) is inserted into the template unattend file. The information required to perform the domain join (the computer name. Note that the remaining steps in this sequence are performed in this user’s context. using the settings from the server (such as the computer naming policy or what organizational unit (OU) to create the computer account in). For nonprestaged accounts. the information that is required to perform the domain join (the computer name. the template unattend file for the image type is used. computer objects. 1. the domain. • If the image unattend file exists (and is in the correct format). For prestaged accounts. BINLSVC determines that it needs to perform a domain join.

Objects within a domain are only writeable on domain controllers for that domain. netbootAnswerRequests. • BINLSVC searches global catalogs before searching domain controllers when attempting to locate computer account objects. you should have BINLSVC use a local domain controller rather than connect across a wide area network (WAN) to a global catalog. It queries for the following attributes: netbootAnswerOnlyValidClients. For more information. and security relationships with other domains.adatum. BINLSVC communicates directly with domain controllers in the following circumstances: • • When using the Auto-Add devices policy to add computer accounts to AD DS. It passes the DS_GC_SERVER_REQUIRED flag whenever it needs to locate a global catalog.microsoft. A site consists of one or more TCP/IP subnets. How BINLSVC Communicates with Domain Controllers In some situations. . Using a global catalog greatly reduces search times and avoids unnecessary Lightweight Directory Access Protocol (LDAP) referrals.com/fwlink/?LinkId=81494). • When querying for the attributes listed earlier in this topic that are not part of the partial attribute set. The following rules apply to how BINLSVC uses AD DS: • BINLSVC prefers to use domain controllers and global catalogs that are available within the same AD DS site as the PXE server. see DSGetDcName() (http://go. netbootMaxClients.com. The site enables you to configure AD DS access and replication topology to take advantage of the network topology.com — and BINLSVC needs to create a computer account in sub. To do this. For example. including netbootGUID and netbootMachineFilePath. netbootServer • BINLSVC uses the DSGetDcName() API.adatum. BINLSVC binds to a domain controller from where the computer account is created. it will use a domain controller from sub. a single search against AD DS can find a prestaged computer. netbootSCPBL. BINLSVC uses those that are outside of the local site (preferring those that are available with the lowest site cost).security policies. By doing this. If local domain controllers and global catalogs are not available. • BINLSVC searches the global catalog for attributes. if there is a company named Datum Corporation with two domains in a forest — adatum.com and sub. When creating computer objects on behalf of users. If you do not have a local global catalog. • BINLSVC queries a writeable domain controller for the domain where the Windows Deployment Services PXE server resides.com.adatum. the Windows Deployment Services server must create computer objects on behalf of the user. 40 .

This signals that the provider has processed the request and. In this case. using its policy settings. This signals that the provider is answering the client. • Pass the client request. The provider can choose not to answer the request and instead instruct the PXE server to pass the request to the next provider in the list.How Windows Deployment Services Uses PXE • • • How PXE Requests Work How the PXE Server Works How Network Boot Programs Work How PXE Requests Work In This Topic • • • How PXE Requests Are Handled When Clients Are Answered How a Computer Is Identified • • • • • Banned GUIDs Architecture Detection Issues Example Scenario How the PXE Response Delay Works How PXE Requests Are Handled When a Pre-Boot Execution Environment (PXE) request is handed to a provider. The following flowchart traces the PXE response logic when two or more providers are registered. has determined that it owns answering the client and that it should ignore the client request. 41 . the client PXE boot will eventually time out. there are three possible return values: • Service the client request. • Ignore the client request.

or to not answer any client PXE requests.When Clients Are Answered You can configure the server to respond to all client PXE requests. These settings are located on the PXE Response Settings tab of the server’s properties (right click the server in the MMC-snap in. to respond only to prestaged client PXE requests. 42 . and click Properties). The following diagram illustrates the answer policy.

Because it is difficult to change the GUID on a computer. it is fairly common for a network adapter to be moved from one computer to another. The duplicate GUID problem seems to be more prevalent on x64-based computers.How a Computer Is Identified There are two pieces of information that a client computer booting from the network sends to the server that enable the server to identify the client: the GUID and the MAC address. To configure this behavior. Also. Therefore. the uniquely identifying feature of one computer can easily be transferred to another. Windows Deployment Services filters known “bad” (not valid) GUIDs. The most common errors occur when no GUID is set or when several computers have the same GUID. you first must identify any duplicate GUIDs and then add the GUIDs to the BannedGuids registry key (see Windows Deployment Services Registry Entries). Then. the 43 . Banned GUIDs Various system builders and vendors have failed to implement GUIDs correctly per the PXE spec. GUIDs are generally preferred over MAC addresses because a GUID (containing 32 hexadecimal characters) is more likely to be unique than is a MAC address (containing 12 hexadecimal characters). if a computer with a banned GUID attempts a network boot.

The client system architecture values are listed in the following table. This means that a PXE server must respond within that time period to ensure that the client boots from the network and that it does not pass to the next device in the boot order. It is possible that the desired PXE provider may not have the opportunity to answer the request within the specified time-out period. Clients that are prestaged will be answered irrespective of the value of the response delay. Although the PXE protocol is not well suited for situations in which multiple PXE servers are servicing the same client base. using the client time-out value and retry logic can make it possible for multiple PXE servers to coexist on the same network segment. followed by provider B. According to the policy. Type Architecture 0 1 2 3 4 5 6 7 IA x86 computer NEC/PC98 IA64 computer DEC Alpha ArcX86 Intel Lean Client X64 x64 EFI How the PXE Response Delay Works The PXE protocol defines the client time-out for a PXE request as 28 seconds (although in practice. Generally. provider A should not answer the client. general networking factors (slow client. For example. The response is so slow from the data store that the client's PXE request times out before 44 . Provider A begins conversation with its data store. this means that the architecture is specified as x86-based but the computer is x64-based. and so on) can cause unintended results. On many x64-based computers. the architecture value either is not set or is not set to the expected value. many vendors have implemented a much shorter time-out value). The PXE request comes in and is handed to provider A.GUID will be stripped from the packet so that the packet will contain only the MAC address of the client. Architecture Detection Each computer that will be booting from the network should have DHCP option 93 to indicate the client’s architecture. dropped packets. Because this method depends on timing. This enables a PXE server to know (at boot time) the exact architecture of the client from the first network boot packet. consider that provider A is first in order. The response delay applies only to clients that are not prestaged.

The exception to this occurs for prestaged clients. Example Scenario The following is an example of a coexistence scenario. if an external data source is slow in responding.com. including the following: • A malfunctioning provider toward the beginning of the order can negatively affect providers at the end of the order. and a second forest serves AlpineSkiHouse. To set the PXE server for Adventure Works to answer only known clients.com. For Windows Deployment Services to respond to the client’s boot request. How the PXE Server Works In This Topic • • • How DHCP Authorization Works How the PXE Server and Providers Interact How TFTP Works in Windows Deployment Services 45 . Client A boots and is supposed to be serviced by the provider that is 29th in the list. The client will time out before the PXE request makes it to that provider. which will always be answered by the server immediately. Adventure Works wants its PXE server to answer only computers it knows about. it may cause the client to fail when it attempts a PXE boot. Alpine Ski House wants to set their PXE server to delay answering clients until a specified time threshold is met. • There is a limit to how many providers can be on the same server at one time. assume that each provider takes one second to process the request and hand it to the next provider. the client is unknown (not prestaged) and should be answered by the PXE server for Alpine Ski House. The request then gets forwarded to provider B. As in the preceding example. Assume that there are two AD DS forests on the same local area network (LAN) segment: One forest serves AdventureWorks. Windows Deployment Services makes it possible for you to configure a response delay value. All PXE request packets have a DHCP option value that indicates the time (in seconds) since the most recent boot.provider A can state that it does not want to answer the client. • External entities can cause undesirable results. Alpine Ski House wants its PXE server to answer all requests. this value must be greater than the value of the response delay setting. The intent is that if a client request is still active after the time threshold has been reached. For example. The constraints associated with the PXE request time-out can create several issues. because of the number of providers registered and the time that it takes each provider to process the request. even those from clients that are not prestaged.

which indicates to the PXE server that the client needs to be serviced. you can enable DHCP authorization. After Windows Deployment Services checks for authorization. you can restart the PXE server to pick up the change to authorization settings immediately. it will not answer client requests. 46 . By default. Authorization checks occur only if authorization checking is enabled and the PXE server is configured to listen on port 67. After the client has obtained a valid IP address from a DHCP server. the client computer identifies itself as being PXE-enabled.How DHCP Authorization Works When a Pre-Boot Execution Environment (PXE) boot is initiated. the client attempts to locate and establish a connection with the PXE server to download a network boot program (NBP). this means that the DHCP server is listening on port 67 and is responsible ensuring authorization. which is also known as rogue detection. If Windows Deployment Services and DHCP are running on the same physical computer. the Windows Deployment Services PXE server does not need to be authorized to service client computers. using the normal DHCP discovery process. How the PXE Server and Providers Interact The following flowchart outlines how the PXE server and PXE providers interact with one another. You can modify the value for the polling period by using registry settings (see the DHCP Authorization section in the Windows Deployment Services Registry Entries topic). As part of the initial DHCP discovery request. the PXE ROM requests an IP address from a Dynamic Host Configuration Protocol (DHCP) server. Alternatively. a polling mechanism runs every hour to ensure that the authorization status has not changed. If the PXE server is deemed to be unauthorized. This means that authorization checks take place only in scenarios in which Windows Deployment Services is running on a computer without DHCP. However.

How TFTP Works in Windows Deployment Services Trivial File Transfer Protocol (TFTP) is the network protocol used for downloading all files during network boots. TFTP is an inherently slow protocol because it requires one ACK (acknowledgment) packet for each block of data that is sent. The server will not send 47 . including the boot image.

For instructions.exe. The NBP dictates whether the client can boot from the network. causing the download to fail. Note that a client cannot fall back to a default block size if the configured block size is too large. The result is fewer ACK packets and much faster download times for the client. this is improved in Windows Server 2008 because of TFTP windowing. there is no way to calculate the block size upper limit for a particular computer. the NBP is a 16-bit. Unfortunately. the round-trip time can be very long. As such. Although configuring the TFTP block size will make TFTP downloads faster. real-mode application. NBPs are both architecture and firmware specific (BIOS or EFI) specific. TFTP windowing enables you to define how many data blocks it takes to fill up a window. and then an ACK packet is sent. You can set this value only as high as the block size upper limit that all the clients on the network support. whether the client must press F12 to initiate the boot.exe). there are two things you need to be aware of: • TFTP is implemented in the operating system loader (Bootmgr. How Network Boot Programs Work A network boot program (NBP) is the first file downloaded and executed as part of the Pre-Boot Execution Environment (PXE) boot process. and you cannot adjust it by using Bootmgr. On BIOS computers (per the PXE specification). see How to Modify the BCD Store Using Bcdedit (http://go. • The configured block size applies to all clients. other than trial and error. However. Therefore. you can change the TFTP block size and the TFTP window size to optimize performance in your environment. The data blocks are sent back to back until the window is filled.microsoft.the next block in the sequence until the ACK packet for the previous block is received. the buffer used by the BIOS will fill up and be overwritten. results may vary greatly based on the make and model of the computer. If you make the TFTP block size too large. Using the BCDEdit command-line tool. As a result. The BIOS buffers the network packets that make up the single TFTP block. and which boot image the client will receive. The memory buffer behavior is unique to the BIOS manufacturer. on a slow network. but the send and receive functionality with User Data Protocol (UDP) is implemented in the BIOS. In This Topic • • • How Windows Deployment Services Determines the NBP How an NBP Is Downloaded How PXE Referrals Work 48 . you can use the same NBP for both x86-based and x64-based operating systems that have BIOS .com/fwlink/?LinkId=115267).

Windows Deployment Services uses the following logic when determining what NBP to direct the client to download: • Is the client prestaged? If the client is prestaged in AD DS.domain.com\boot\x86\pxeboot. 2. computer.com/Computers/Prestage1.DC=domain.. • Is the unknown client configured to perform PXE boots without requiring F12? You can set this value by running WDSUTIL /Set-Server /AllowN12ForNewClients:Yes. then the device is classified as unknown and.n12 netbootMachineFilePath: machine netbootMachineFilePath: machine. In the following netbootMachineFilePath attribute syntax.DC=com".DC=com 5> objectClass: top. the command sets the netbootMachineFilePath attribute of the prestaged computer (that is. which you can use to view objects stored in AD DS.CN=Computers. organizationalPerson. and you can specify <Server> to indicate the PXE server referral..com\boot\x86\pxeboot. the computer account that represents the client computer in AD DS). 1> cn: Prestage1. <PathToNBP> and <NameOfNBP> are optional. If you configure this setting.DC=domain.DC=com.CN=Computers. the device will be sent 49 . 1> canonicalName: domain. <Server>\<PathToNBP>\<NameOfNBP> For example: netbootMachineFilePath: machine\OSChooser\i386\startrom.n12.How Windows Deployment Services Determines the NBP When you run WDSUTIL /Set-Device /Device:<name> /BootProgram:<path> for a computer.domain. 0. Windows Deployment Services looks for a prestaged device in AD DS. Windows Deployment Services reads the netbootMachineFilePath attribute of the client’s computer account object to determine the path and file name of the correct NBP. attrList.domain. 1> distinguishedName: CN=Prestage1. ***Searching. ldap_search_s(ld. "(&(objectClass=*)(netbootMachineFilePath=*))". 1> name: Prestage1. "DC=domain. user.com The following is example output of the netbootMachineFilePath attribute. obtained by using the Ldp graphical user interface (GUI) tool. If it does not find one.com netbootMachineFilePath: machine. person. 1> netbootMachineFilePath: machine. &msg) Result <0>: (null) Matched DNs: Getting 1 entries: >> Dn: CN=Prestage1.

pending devices. the default NBP will be used. or referrals 50 . If the device is found in AD DS. How an NBP Is Downloaded The following diagrams illustrate the program download flow for the NBPs delivered with Windows Deployment Services. x86-based and x64 BIOS-based computers x86-based and x64 BIOS-based computers with architecture detection. • What is the default NBP for the client’s architecture? If the client does not have the netbootMachineFilePath specified in the computer account object in AD DS.the . Windows Deployment Services sends the device the default NBP for the client’s architecture.n12 NBP.

Itanium-based and x64 EFI-based computers How PXE Referrals Work A PXE referral (also known as a network boot referral) is the term for when a client is directed to download an NBP from a server other than the one it was in communication with through Dynamic Host Control Protocol (DHCP). This referral may be initiated by either a network boot server or a DHCP server. The following diagram shows the PXE referral process for a sample Windows Deployment Services configuration within a large organization. 51 .

The client then begins the Trivial File Transfer Protocol (TFTP) download of the NBP from WDS server 3. Windows Deployment Services Registry Entries Topic Subtopic Critical Providers for the WDSServer Service Logging for the Windows Deployment Services Client DHCP • DHCP Authorization • Configuring the PXE Server Not to Listen on UDP Port 67 • Configuring the Server to Bind to UDP Port 67 PXE • • • • • • • Unattended Installation • • Network Boot Programs • Architecture Detection Response Delay Banned GUIDs Order of PXE Providers PXE Providers That Are Registered Bind Policy for Network Interfaces Location of TFTP Files Server Unattend Policy Per-Architecture Unattend Policy Per-Client NBP 52 . WDS referral server checks AD DS to verify whether a computer account object exists for this client. and 3 is to provide images of the operating system.As illustrated in this diagram. This check reveals that the client was prestaged. WDS referral server services all PXE requests. These servers do not respond to initial client service requests. the only purpose of PXE referral servers 1. and a property in the computer account indicates that the client’s referral server is WDS server 3. At this point. This request is answered by the active Windows Deployment Services server (WDS referral server in this diagram). checks AD DS for the existence of a prestaged computer account object. Note that in the network design of this diagram. 2. and then refers the client to the specified Windows Deployment Services server. a new client sends a PXE request. using the DHCPREQUEST packet. WDS referral server passes the request on to WDS server 3 . Clients that have been prestaged in Active Directory Domain Services (AD DS) will be answered by this PXE server. Rather.

For instructions on how to modify them. see How to Perform Common Tasks (http://go.n12 NBP • Resetting the NBP to the Default on the Next Boot Auto-Add Database • • • • Domain Controllers and the Global Catalog • • Auto-Add Policy Message Displayed to a Pending User Time-Out Value Settings for Approved Client Computers Static Configuration Search Order To modify any of these registry settings. Do not modify these registry keys directly. and True means that they will be answered.com/fwlink/?LinkId=115268). The policy is stored in the registry at 53 . You can configure Windows Deployment Services to answer all incoming PXE requests or only those from prestaged clients (for example. use the management tools. Critical Providers for the WDSServer Service Critical providers for the WDSServer service are indicated by the following registry value: HKLM\System\CurrentControlSet\Services\WDSServer\Providers • • • Name: IsCritical Type: REG_DWORD Value: 1 means critical.microsoft. and 0 means not critical.Topic Subtopic • Unknown Clients Automatically PXE Boot • . WDSUTIL /Set-Server /AnswerClients:All). The policy is stored at HKLM\System\CurrentControlSet\Services\WDSSERVER\ProvidersWDSPXE\Providers\BIN LSVC. Client Answer Policy Windows Deployment Services has a global on/off policy that controls whether or not client requests are answered. • • Name: netbootAnswerRequests Type: REG_SZ • Values: False means that client requests will not be answered.

• Name: LogLevel Type: REG_DWORD Value: 0 or not set means OFF. Logging for the Windows Deployment Services Client The values for logging level are stored in the following keys of the Windows Deployment Services server: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSServer\Providers\WdsI mgSrv\ClientLogging There are two keys: • Name: Enabled Type: REG_DWORD Value: 0 or not set means not enabled (default). This time is only used when a successful authorization process has been 54 . 1 means ERRORS. 2 means WARNINGS. and 1 means enabled. and 3 means INFO. and True means that only prestaged clientsss will be answered. DHCP • • • • DHCP Authorization DHCP Authorization Cache Configuring the PXE Server Not to Listen on UDP Port 67 Configuring the Server to Bind to UDP Port 67 DHCP Authorization The following registry keys for DHCP authorization are located under HKLM\System\CurrentControlSet\Services\WDSSERVER\Providers\WDSPXE: Name Description AuthRecheckTime Specifies the amount of time (in seconds) that the PXE server will wait before rechecking its authorization.HKLM\System\CurrentControlSet\Services\WDSSERVER\ProvidersWDSPXE\Providers\BIN LSVC. • • Name: netbootAnswerOnlyValidClients Type: REG_SZ • Values: False means that all client requests will be answered.

but Domain1 was denied. • Type: DWORD • Default value: 3. • Type: DWORD The following table indicates that the last query to Localnetwork showed that the server was authorized. Registry key name Type Value Default Localnetwork Domain1 REG_SZ REG_DWORD REG_DWORD Value not set 0x00000001 (1) 0x00000000 (0) This cache is used whenever the PXE server receives an error while communicating with AD DS.Name Description performed. and 1 means disabled. irrespective of whether the server was previously authorized. So. The cached results are used to authorize or unauthorize DHCP. if the PXE server is unable to query AD DS successfully.600 seconds (one hour) AuthFailureRetryTime Specifies the amount of time (in seconds) that the PXE server will wait if any step of authorization fails. • • DisableRogueDetection • Type: DWORD Default value: 30 seconds Type: DWORD • Default value: 0 means enabled. the results are cached under HKLM\System\CurrentControlSet\Services\WDSSERVER\Providers\WDSPXE\AuthCache as follows: • Name: <domainname> • Value: 1 indicates that the last successful communication with AD DS authorized this server to act as the DHCP server. this value is used to determine the time before trying AD DS again. DHCP Authorization Cache Whenever the PXE server successfully queries AD DS. and then AuthFailureRetryTime 55 .

and DC=com. Configuring the PXE Server Not to Listen on UDP Port 67 You can configure this so that port 67 can be used by the DHCP server. The following is the registry key that contains the configuration required to have the server listen in nonexclusive mode by passing the SO_REUSEADDR flag: HKLM\System\CurrentControlSet\Services\WDSServer\Parameters • • Name: SharedPorts Type: REG_DWORD PXE • • • • • • • Architecture Detection Response Delay Banned GUIDs Order of PXE Providers PXE Providers That Are Registered Bind Policy for Network Interfaces Location of TFTP Files Architecture Detection When you enable architecture detection. 0 means that the PXE server will not listen on port 67. DC=Domain. Authorization of PXE servers occurs on the child objects of CN=NetServices. Use this setting in configurations where the PXE server and DHCP are on different physical computers. you can configure the server to bind to UDP Port 67 in nonexclusive mode by passing the SO_REUSEADDR option. In these circumstances. CN=Services. The following registry value controls this behavior: HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE • Name: UseDHCPPorts • Value: 1 means that the PXE server will listen on port 67. CN=Configuration. see “Using SO_REUSEADDR and SO_EXCLUSIVEADDRUSE” (http://go.com/fwlink/? LinkId=82387). Configuring the Server to Bind to UDP Port 67 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.is used to determine when to query AD DS again. For more information.microsoft. Use this setting in configurations where Windows Deployment Services and DHCP are located on the same physical computer. This is the default value for the setting. the following registry value is configured: 56 .

1 means that it is disabled (this is the default value). Order of PXE Providers A registering provider can select its order in the existing provider list. in seconds> Banned GUIDs The registry location of the banned GUIDs is as follows: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDS PXE • • Name: BannedGuids Type: REG_MULTI_SZ • Value: GUID strings. The provider order is maintained in the registry at the following location: HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\ • • • Name: ProvidersOrder Type: MULTI_SZ Value: Ordered list of providers PXE Providers That Are Registered PXE providers register with the server by doing the following: • Creating a valid key (to represent their provider) in the following folder: HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers 57 . PXE Response Delay The following is the registry key that holds the PXE response delay: HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINL SVC • • • Name: ResponseDelay Type: REG_DWORD Value: <delay time. which should match what you see when you perform a PXE boot on a client (without dashes). The correct format is as follows: {1acbf4473993e543a92afadb5140f1c8}.HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINL SVC • • Name: DisableArchDisc Type: REG_DWORD • Value: 0 or not present means that the architecture discovery is enabled. with one string per line.

you can adjust the default behavior by using the settings for the registry keys listed in the following table. That is.dll • • Designating the provider as critical by adding the IsCritical registry setting (optional) Specifying the entry point routine in the provider . These interfaces may be specified either by IP address or by MAC address. Note 58 . To satisfy all four configurations. These settings are stored in the following folder: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSServer\Providers\WDSP XE Entry Data type Description and values BindPolicy REG_DWORD Specifies the default binding behavior and determines whether the PXE server binds to all IP addresses or to none. the PXE server is automatically configured to listen on all active (that is. • 1 means include. This can be either of the following values: • 0 means exclude (this is the default value).dll Bind Policy for Network Interfaces There are various possible network adapter configurations that you can use. only those interfaces that are defined in BindInterfaces will be included. each with one IP address Two or more network adapters. That is. After installation. During installation. interfaces that are defined in BindInterfaces will be excluded.dll at the following location: HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\< Custom Provider Name> Name: ProviderDLL Type: REG_SZ Value: The full path and file name of the provider .• Creating a registry entry pointing to their . and all of the other cases are more advanced networking scenarios. with at least one having more than one IP address The first option listed is considered the standard server configuration. including the following: • • • • One network adapter with a single IP address One network adapter with multiple IP addresses bound to the single adapter Two or more network adapters. WDSPXE has the ability to listen only on particular network interfaces. nondisabled) interfaces.

or separated by colons or dashes. raw. and then stop. Otherwise. and you can format them with uppercase or lowercase hexadecimal characters. you can use the WDSUTIL command-line tool. Location of TFTP Files The TFTP root is the parent folder that contains all files available for download by client computers. IP addresses must use dotted notation (for example. You can specify MAC addresses as a sequence of hexadecimal characters. BindInterfaces REG_MULTI_SZ Lists all interfaces that the PXE server should listen on or exclude. the TFTP root is set to the RemoteInstall folder as specified in the following registry setting: 59 .2. MAC:ABCDEFABCDEForIP:10. The default value is blank (no interfaces are excluded or included). the service will start. log an event. To add a MAC address to the BindInterfaces list. you must edit the registry value manually.10. By default. Caution Make sure that the IP or MAC addresses you enter are correct. To add an IP address.2. based on the setting of BindPolicy: • If BindPolicy is set to 1 (include). set BindInterfaces to the IP addresses or MAC addresses for the interfaces that you want to exclude.).Entry Data type Description and values Changes to BindPolicy are automatically picked up by the PXE server and do not require a service restart. • If BindPolicy is set to 0 (exclude). set BindInterfaces to the IP addresses or MAC addresses for the interfaces that you want to include.

HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSTFTP\ • • • Name: RootFolder Type: REG_SZ Data: <full path and folder name of the TFTP root> Unattended Installation • • Server Unattend Policy Per Architecture Unattend Policy Server Unattend Policy This policy is defined in the Windows Deployment Services server registry at the following location: HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\WdsI mgSrv\Unattend • • • Name: Enabled Type: REG_DWORD Value: 0 or not set means disabled. x64. or ia64): HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\WdsI mgSrv\Unattend\<arch> • • Name: WDSUnattendFilePath Type: REG_SZ • Value: The file path to the Windows Deployment Services client unattend file (for example. D:\RemoteInstall\WDSClientUnattend\WDSClientUnattend. and 1 means enabled.xml). Per-Architecture Unattend Policy Unattend files are architecture specific. Network Boot Programs • • • • Per-Client NBP Unknown Clients Automatically PXE Boot .n12 NBP Resetting the NBP to the Default on the Next Boot 60 . so you need a unique file for each architecture. These values are stored in the registry at the following location (where <arch> is either x86.

boot\x86\pxeboot. This configuration is particularly useful in a lab environment where you want to immediately image new computers. or IA64): HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINL SVC\BootPrograms\<arch> There are two keys that define the NBP: • Name: Default Type: REG_SZ Value: The relative path to the default NBP that all booting clients of this architecture should receive (for example. x64.n12 Type: REG_SZ Value: The relative path to the NBP that will be sent by using the AllowN12ForNewClients setting (for example. see Unknown Clients Automatically PXE Boot. • Name: . or IA64): HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINL SVC\BootPrograms\<arch> • Name: . it may be useful to further segment the server NBP so that the following are true: • Known clients receive the per-server default (presumably a NBP that requires pressing the F12 key).n12 NBP according to the following registry settings (where <arch> is either x86. but you want to ensure that existing computers are not sent through the imaging process by accidentally booting from the network. • Unknown clients receive a NBP that will cause them to perform a PXE boot automatically.n12 NBP.n12 61 . The NBP is defined by the following registry settings (where <arch> is either x86. boot\x86\pxeboot. Unknown Clients Automatically PXE Boot In some cases. For more information.Per-Client NBP Configuring a network boot program (NBP) for each server is the default method.com). .n12 NBP Windows Deployment Services sends the defined .n12). The policy setting for unknown clients to perform a PXE boot automatically is stored in the following registry key: HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINL SVC\ • • • Name: AllowN12ForNewClients Type: REG_DWORD Value: 0 or not set means not enabled 1 means that unknown clients are sent the . You can override this method on a per-client basis. x64.

n12 NBP. the computer will receive the default server NBP (commonly the .n12. Therefore.n12 NBP. After allowing sufficient time for the user to press the F12 key. 1 means that during the imaging process. you can specify settings that control the client’s installation experience. Auto-Add Devices Database If a computer requires approval before the installation will start. Using this option ensures that on the next boot. you can also configure the any other combination by specifying an NBP other than. the computer will try to boot from the network (because the network is listed first in the BIOS boot order). The value is cleared after the image is applied.com version). the value stored in the netbootMachineFilePath attribute in AD DS for the prestaged device will be cleared. the computer will be in a pending state. as one of the final actions performed by Windows Deployment Services. or specified for each approved computer. • Auto-Add Policy 62 . The following registry key controls these settings: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSServer\Providers\WDSP XE\Providers\BINLSVC • • • Name: ResetBootProgram Type: REG_DWORD Value: 0 or not set means no action. per architecture. Note Although the setting implies that new and unknown clients will receive the . The value for the referral server is also stored in the netbootMachineFilePath attribute.n12). it is often necessary to do the following: • • Set the network as the first device in the client’s BIOS boot order. any server in the domain can answer the client the next time it reboots. the client will automatically boot from the network without requiring user intervention and the computer will end up in a circular loop (always booting from the network and never booting from the hard disk drive). Send a specific client an . One of the advantages of using the pending functionality is that at the time the device is approved. Therefore.• Type: REG_SZ • Value: The relative path to the NBP that will be sent according to the AllowN12ForNewClients setting (for example. this option will time out and the device will boot from the hard disk drive. but the computer will be sent the . when you specify 1 and this value is cleared.com NBP. boot\x86\pxeboot. Resetting the NBP to the Default on the Next Boot When implementing a fully automated experience of booting from the network. If you combine these two configurations. These settings can be global.

The default setting for these values is to poll the server every 10 seconds for 2. The values for these settings are sent to the client by the server in the DHCP options field of the DHCP acknowledge control packet (ACK). Rather. bringing the total default time-out to six hours. the Wdsnbp.160 tries.com program polls the server for the settings in the following keys after it has paused the client’s boot.com.• • • Message Displayed to a Pending User Time-Out Value Settings for Approved Client Computers Auto-Add Policy The following registry settings control the Auto-Add policy: HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINL SVC\AutoApprove • • • Name: Policy Type: DWORD Value: 0 or not present means no Auto-Add policy (no action). 1 means pending. The default setting is for this to be blank. HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINL SVC\AutoApprove • Name: PollInterval Type: DWORD Value: The amount of time (in seconds) between polls of the server • Name: PollMaxRetry Type: DWORD Value: The number of times the server will be polled before a time-out occurs 63 .com when the device is in a pending state: HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINL SVC\AutoApprove • • Name: PendingMessage Type: REG_SZ • Value: Message shown to the user by Wdsnbp. Time-Out Value The client state is not maintained on the server. Message Displayed to a Pending User The following registry key contains the text message that is displayed to the user by Wdsnbp.

• • Name: BootProgramPath Type: REG_SZ The name of the NBP that the client should download. x64. Specifies the type of rights to be assigned to the user. • Value: 0 or not defined means that the computer should be joined to the domain. The primary user associated with the generated computer account. The default setting is for this value to be blank (no server name). • • Name: JoinDomain Type: REG_DWORD Specifies whether or not the device should be joined to the domain. or ia64). and they apply to all approved devices unless they are manually overridden when the device is approved. • JoinOnly requires the administrator to • • • Name: JoinRights Type: REG_DWORD Value: 0 or not defined means 64 . • • Name: BootImagePath Type: REG_SZ • Value: The name of the boot image that the client should receive. Setting this value means that the client will not see a boot menu because the specified boot image will be processed automatically. • • Name: ReferralServer Type: REG_SZ • Value: The name of the server to refer the client to. as defined later in this section.Settings for Approved Client Computers The following registry settings control additional properties that you can set on an approved pending device (where <arch> is either x86. These settings are defined per architecture. 1 means that the computer should not be joined to the domain. which the client should receive. The name of the boot image. The default setting is for this value to be blank (no boot image). The default setting is the domain administrator. • • Name: User Type: REG_SZ • Value: The owner of the computer account that was created. They are located at the following location: HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINL SVC\AutoApprove\<arch> Configuration setting Registry value The name of the Windows Deployment Services server that the client should download the NBP from. This user will be granted JoinRights authorization. The default setting is for this value to be blank (no path). • Value: The partial path and NBP that the client should receive.

1 means that the domain controller will be searched first. and then the domain controller.Configuration setting Registry value reset the computer account before the user can join the computer to the domain. JoinOnly. Search Order The following registry key controls the preferred search order: HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINL SVC • • Name: ADSearchOrder Type: REG_SZ • Value: 0 or not set means that the global catalog will be searched first. • Full gives full permissions to the user (including the right to join the domain). If a prestaged device is not found in the local domain controller. The settings for these options are as follows: HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINL SVC • Name: DefaultServer Type: REG_SZ Value: The name of domain controller that Windows Deployment Services should use. and then the global catalog. Domain Controllers and the Global Catalog • • Static Configuration Search Order Static Configuration In some circumstances. Windows Deployment Services must perform an additional query against a global catalog because the 65 . you may want to statically configure the domain controller and the global catalog that Windows Deployment Services will use. so this value must be a writable domain controller. This can be either the NETBIOS name or the FQDN. This can be either the NETBIOS name or the fully qualified domain name (FQDN). Note that you cannot use read-only domain controllers with Windows Deployment Services. • Name: DefaultGCServer Type: REG_SZ Value: The name of the global catalog that Windows Deployment Services should use. Setting this value to 1 may lead to less efficient use of AD DS in a multidomain environment. 1 means Full.

if this value is set to 1. Windows Deployment Services may have to perform two searches to find the prestaged computer object when it otherwise would have needed to do only one search.domain controller is not guaranteed to have knowledge of all objects. 66 . Therefore.

Sign up to vote on this title
UsefulNot useful