Documente Academic
Documente Profesional
Documente Cultură
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
How Unattended Installation Works..............................................................................................21 In This Topic...............................................................................................................................21 How Unattend Works for the Windows Deployment Services Client.........................................22 How Unattend Works for the Remaining Setup Phases............................................................23 Diagram of the Unattended Setup Process...............................................................................23 How the Windows Deployment Services Client Works.................................................................24 How the Client Applies Install Images........................................................................................24 How the Client Deals with Discover Images..............................................................................25 When Setup Is Started in Windows Deployment Services Mode...............................................26 Automatic Detection............................................................................................................27 Manually Invoking Setup.exe..............................................................................................28 Diagram of Startup Logic....................................................................................................28 How the Image Store Works.........................................................................................................29 In This Topic...............................................................................................................................29 When Images Are Verified.........................................................................................................30 How Images are Enumerated....................................................................................................30 How Images Are Compressed...................................................................................................30 How Images Are Captured.........................................................................................................31 How Windows Deployment Services Uses Active Directory..........................................................32 In This Section...........................................................................................................................32 How Prestaged Devices Work......................................................................................................32 In This Topic...............................................................................................................................32 How Prestaged Clients Are Located..........................................................................................33 When Prestaged Clients Are Joined to a Domain......................................................................34 Diagram of Prestaging Clients...................................................................................................34 Examples...............................................................................................................................35 How the Auto-Add Policy Works...................................................................................................36 In This Topic...............................................................................................................................36 How Computers in a Pending State Are Handled......................................................................36 Diagram of the Auto-Add Policy.................................................................................................38 How Domain Controllers and Global Catalogs Work.....................................................................39 In This Topic...............................................................................................................................39 How Joining a Computer to a Domain Works............................................................................39 How Domain Controllers and Global Catalogs Are Used...........................................................39 How BINLSVC Communicates with Domain Controllers...........................................................40 How Windows Deployment Services Uses PXE...........................................................................41 How PXE Requests Work.............................................................................................................41 In This Topic...............................................................................................................................41 How PXE Requests Are Handled..............................................................................................41
When Clients Are Answered......................................................................................................42 How a Computer Is Identified....................................................................................................43 Banned GUIDs.......................................................................................................................43 Architecture Detection............................................................................................................44 How the PXE Response Delay Works.......................................................................................44 Example Scenario..................................................................................................................45 How the PXE Server Works..........................................................................................................45 In This Topic...............................................................................................................................45 How DHCP Authorization Works................................................................................................46 How the PXE Server and Providers Interact..............................................................................46 How TFTP Works in Windows Deployment Services.................................................................47 How Network Boot Programs Work...............................................................................................48 In This Topic...............................................................................................................................48 How Windows Deployment Services Determines the NBP........................................................49 How an NBP Is Downloaded......................................................................................................50 x86-based and x64 BIOS-based computers....................................................................50 x86-based and x64 BIOS-based computers with architecture detection, pending devices, or referrals....................................................................................................................50 Itanium-based and x64 EFI-based computers.................................................................51 How PXE Referrals Work..........................................................................................................51 Windows Deployment Services Registry Entries..........................................................................52 Critical Providers for the WDSServer Service............................................................................53 Client Answer Policy..................................................................................................................53 Logging for the Windows Deployment Services Client..............................................................54 DHCP........................................................................................................................................54 DHCP Authorization...............................................................................................................54 DHCP Authorization Cache.................................................................................................55 Configuring the PXE Server Not to Listen on UDP Port 67....................................................56 Configuring the Server to Bind to UDP Port 67 .....................................................................56 PXE...........................................................................................................................................56 Architecture Detection............................................................................................................56 PXE Response Delay.............................................................................................................57 Banned GUIDs.......................................................................................................................57 Order of PXE Providers..........................................................................................................57 PXE Providers That Are Registered.......................................................................................57 Bind Policy for Network Interfaces..........................................................................................58 Location of TFTP Files...........................................................................................................59 Unattended Installation..............................................................................................................60 Server Unattend Policy...........................................................................................................60 Per-Architecture Unattend Policy...........................................................................................60 Network Boot Programs.............................................................................................................60 Per-Client NBP.......................................................................................................................61
Unknown Clients Automatically PXE Boot..............................................................................61 .n12 NBP................................................................................................................................61 Resetting the NBP to the Default on the Next Boot................................................................62 Auto-Add Devices Database......................................................................................................62 Auto-Add Policy......................................................................................................................63 Message Displayed to a Pending User..................................................................................63 Time-Out Value.......................................................................................................................63 Settings for Approved Client Computers................................................................................64 Domain Controllers and the Global Catalog..............................................................................65 Static Configuration................................................................................................................65 Search Order..........................................................................................................................65
The providers provide the true functionality associated with the service. Although technically the WDSServer service can start without these providers, the server would be entirely useless or severely limited in functionality without them. Therefore, these providers are marked as "critical" meaning that if the provider does not load and initialize successfully, the WDSServer service should log an error and not start. There are six providers that are included with the Deployment Server installation (note that the Transport Server installation includes only Wdspxe.dll, wdstftp.dll, wdsmc.dll, and wdscp.dll). These providers are listed and described in the following table.
Provider Description
Wdspxe.dll
The PXE server, which is the module used for Pre-Boot Execution Environment (PXE) booting. Note that the PXE server itself also has its own set of providers, called PXE providers. For more information, see PXE Server Components. The Windows Deployment Services PXE provider, which is used as part of the management operations for Auto-Add device functionality. Binlsvc.dll registers itself with the WDSServer service and requests a remote procedure call (RPC) endpoint. It is also a PXE provider that is loaded by Wdspxe.dll (see the following diagram). The Trivial File Transfer Protocol (TFTP) server. TFTP is the protocol used to download the boot image, and to boot files such as Pxeboot.com, Wdsnbp.com, Bootmgr.exe, and Default.bcd. The image store component, which is the module used by the Windows Deployment Services client when communicating with the server. The server registers an RPC endpoint for communication between client and server. The multicast server. The multicast content provider. Note that it is not loaded directly into WDSServer; instead, it is loaded by Wdsmc.dll.
Binlsvc.dll
Wdstftp.dll
Wdsimgsrv.dll
Wdsmc.dll Wdscp.dll
OSChooser. Contains the RIS menu screens and associated PXE boot files. This folder is present only if you upgrade from Windows Server 2003. Setup. Contains RISETUP and RIPREP images. This folder is present only if you upgrade from Windows Server 2003. Templates. Contains an image unattend template for images from an earlier version of Windows, to support computer naming and domain join scenarios. Tmp. Contains temporary files used by Windows Deployment Services, including the Boot Configuration Data (BCD) stores. WdsClientUnattend. Contains the unattend installation files (Unattend.xml) files used by the Windows Deployment Services client.
RequestID
An automatically generated number that uniquely identifies the request. This value is also specified in the command line to approve or reject the device. The MAC address of the client. The computer GUID of the client. 10
MACAddress UUID
Field name
Description
Active
Windows Deployment Services adds a record when it receives the DHCP request from a client, and Active is set to FALSE. When Wdsnbp.com is downloaded by the client, this field is set to TRUE. This way, you see only one pending request from 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. The name of the user who changed the status. The client architecture. The referral server. The boot program that the client should use. The suggested organizational unit (OU) for where the computer account will be created. The owner of the computer account. The relative path to default boot image. The relative path to the Windows Deployment Services client unattend file. The name of the computer that was added (not a calculated value, but the actual computer name that was used).
All requests are uniquely represented in the database by the RequestID value. If a device was previously added to the database, Windows Deployment Services will search the table for the MACAddress, and the corresponding record will be used. The same status is used for the device. Therefore, there should never be a case in which a unique device has more than one record in the database. All of the values for ReferralServer, BootProgramPath, MachineOU, Owner, Boot, Image Path, and WDSUnattendFilePath come from the defaults for the Auto-Add policy that are defined on the Windows Deployment Services server. You can override these values when the device is approved. For information about changing these values, see How to Manage Client Computers (http://go.microsoft.com/fwlink/?LinkID=115265).
11
boot applications. Physically, a BCD store is a binary file in the registry hive format. The file has the same file name as its corresponding .wim file. These BCD stores reside in the folder that contains the boot image (for example, RemoteInstall\Boot\<arch>\Images\Boot.wim and RemoteInstall\Boot\<arch>\Images\Boot.wim.bcd). For more information about BCDs, see http://go.microsoft.com/fwlink/?LinkID=110353 and Boot Configuration Data Editor Frequently Asked Questions (http://go.microsoft.com/fwlink/?LinkID=65818). The boot manager reads the BCD store into a set of boot entries that describe the operating systems and tools that can be started. A boot entry consists of the GUID for the application to start and a list of the applications BCD elements. This is all kept in memory after being read by the boot manager. As a result, the relevant information about a boot entry (its application path, operating system path, and description) is contained in the BCD element list. There are boot settings that are common to any available operating system displayed in the boot menu. These settings include the following: General boot manager settings, such as the time-out value (the period of time after which the default operating system is selected automatically). Debugger settings related to enabling debugging in the loader. The device options for booting Microsoft Windows Preinstallation Environment (Windows PE) from RAMDISK, such as the path to the Boot.sdi file. These options are defined in a BCD store for each architecture, located at RemoteInstall\Boot\<arch>\Default.bcd. Each boot image is represented in the BCD store as an available Windows boot loader option, 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). The architecture-specific BCD stores are created in the \Tmp folder. A clean-up thread deletes the contents of the \Tmp folder at a specified interval (the default interval is every 24 hours). The following rules apply: The current (in-use) architecture-specific BCD store is not purged by this process. The previously active BCD store is not purged immediately.
This helps you avoid the scenario in which a client boots from the network and is referred to pick up FileA. Meanwhile, a change on the server has triggered the creation of a new file, FileB. FileA is deleted. The client attempts to download FileA and fails because the file was purged. For this reason, the previously active file is deleted after clean-up.
13
x64-based. This file consists of the Default.bcd file from the \Boot\x64 folder and all boot image BCDs from the \Boot\x64\Images folder. x86-based and x64-based (this corresponds to if you run WDSUTIL /set-server /DefaultX86X64ImageType:both). This file consists of the Default.bcd file from the boot\x86 folder and all boot image BCDs from both the \Boot\x86\Images and \Boot\x64\Images folders. The naming convention for constructed BCD stores is as follows: Architecture. {RandomGUID}.bcd (for example, X86.{05FF3388-7D71-46A1-AE8A704480979281}.bcd). The GUID ensures that any newly generated BCD store will not interfere with or overwrite an existing BCD store. 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). They are then deleted by BINLSVC. If debug tracing is active, you can see the current active BCD store for each architecture in the Windows Deployment Services servers debug log at: %windir%\Tracing\Wdsserver.log. For more information, see How the Boot Configuration Data Store Works.
14
15
Obtains a list of well-known settings (for example, timezone) so that these values may be used during installation. Obtains domain join settings. When Setup.exe is started, the Windows Deployment Services client starts networking and initiates communication with the Windows Deployment Services server. This initial session is an anonymous session that uses unencrypted RPCs. This session is created using the normal RPC process. First, the client binds to the Windows Deployment Services servers End Point Mapper to determine which RPC port the Windows Deployment Services server is listening on (by default, this is port 5040). Next, the Windows Deployment Services client connects (through RPC) directly to the Windows Deployment Services server. During this initial session, the client sends information (such as GUID) to the image store. The Windows Deployment Services server then does the following: Uses this information to determine whether the client is prestaged. Performs subsequent processing on the server to direct the client to the proper unattend file and domain join settings (if these have been configured). 16
Authenticates the client, based on the credentials entered in the UI or in unattend settings. At this point, the session between the client and server switches to encrypted RPC. After the server has the clients credentials, image enumeration occurs during a secured session.
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
In This Topic
How Windows Deployment Services Determines the BCD Store How the BCD Store Is Created
17
1. BINLSVC receives a signal to begin creating a BCD store. This causes the regeneration of all BCD stores for all architectures. 2. The Default.bcd file is copied from the RemoteInstall\Boot\<arch> folder to the \RemoteInstall\Tmp folder. 3. 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. 4. One boot image is marked as the default. The first alphabetic image will be the default image (unless you overwrite it). You can overwrite the default image by using the Boot tab of the server's properties in the MMC snap-in.
Overview
You can boot Windows Preinstallation Environment 2.0 (Windows PE 2.0) in either of two formats: Flat file. With this format, Windows PE files live in a flat file directory structure (not an image). Windows PE is booted directly from the flat file directory. 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. This method of booting Windows PE 2.0 is not available when booting from the network. RAMDISK. With this method, a virtual disk volume is created in the RAM to hold the boot image (which contains Windows PE). The boot image is downloaded while booting from the network and saved to this location. Windows PE is then run directly from that media. The following steps outline the general process when booting to RAMDISK. 1. Step 1: Select an operating system entry. The Boot Configuration Data (BCD) format contains two entries that signify a RAMDISK boot. First, a device object is created to represent the RAMDISK object. This device object defines the parameters that are necessary to create the actual RAMDISK by defining the disk volume file. Second, an operating system entry is created that specifies the operating system image and references the RAMDISK device object (by its globally unique identifier, or GUID). The following is sample output from the BCD store obtained by using Boot Configuration Data Store Editor.
Device options -------------identifier {68d9e51c-a129-4ee1-9725-2ab00a957daf}
19
ramdisksdidevice ramdisksdipath
boot \Boot\Boot.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.wim,{68d9e51c-a129{7c7c9843-cb93-4096-a930-1d6ab763a4d0} ramdisk=[boot]\Boot\x86\Images\Boot.wim,{68d9e51c-a129-
2. Step 2: Create the RAMDISK. The RAMDISK itself involves two parts: a disk (volume) image and a file-system. The \boot\boot.sdi file, stored on the RemoteInstall folder during the initial configuration of the server, serves both of these functions. The .sdi file is a disk image that has been formatted with the NTFS file system. The process of booting from RAMDISK involves placing the Boot.sdi file into memory and pointing the loader at that file as if it were an actual disk. The operating system loader contains code to mount the volume and search the NTFS file system for a .wim file that contains the boot image. 3. Step 3: Boot Windows PE. A RAMDISK boot image must be in a .wim file, and it must be explicitly marked as being able to boot from RAMDISK. You can mark the image as bootable by using the /boot option in ImageX when either creating (for with the /capture, /append, and /export options, for example) or modifying (with the /info option, for example) the boot image. Marking an image with the /boot option causes certain properties of the image to be propagated to the header of the .wim file (which is looked at by the loader when it is trying to discover what image is bootable). Although a .wim file may contain multiple images, only one image can be marked as able to boot from RAMDISK.
4. The NBP downloads the operating system loader by using TFTP, using the User Data Protocol (UDP) stack from the PXE ROM. 5. The loader downloads (using TFTP) the associated files needed to boot into Windows PE from RAMDISK. These files include the following: a. A Boot Configuration Data (BCD) store. This replaces the Boot.ini file, which tells the loader how to boot the operating system. b. An .sdi disk image. c. The boot image, in .wim format. d. Font files for the boot menu. You can configure the boot menu to be in a different language, so these files are downloaded to display the localized boot menu. The TFTP download occurs using the UDP stack from the PXE ROM. The TFTP protocol is implemented in the loader, so the user can see a progress bar. 6. The RAMDISK is produced by creating the disk image in memory and appending the .wim file to the disk. 7. Windows PE boots by using the image in the .wim file. The following diagram illustrates what happens in the RAM of a client computer.
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
22
23
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.
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.
26
Automatic Detection
The default method and most common way to invoke the Windows Deployment Services client is for Setup.exe to detect automatically that it should start in this mode. This method is used when you use the Boot.wim from the Windows Vista media (in the \Sources folder). The Boot.wim file contains its own \Sources folder that includes the Setup.exe file and associated files. At boot time, Windows PE must start a shell application. You can explicitly define this application by using entries in the WinPESHL.ini file, or it can be implicitly discovered through code in Windows PE. In the latter case, Windows PE looks for Setup.exe in the \Sources folder and, if the program is present there, Windows PE automatically starts the application. This happens if the WinPESHL.ini file does not exist or if it contains an empty [LaunchApp] section. When Setup.exe is running, two additional checks are automatically performed to determine whether Setup should start in Windows Deployment Services mode. If the answer to either or both of the following questions is No, Setup will not start in Windows Deployment Services mode.
Check Explanation
When a computer running Windows Vista PXE boots, 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. 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). Setup.exe looks at the data in the BootServerReply value of HKLM\System\CurrentControlSet\Control\PXE. 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. If the Windows PE instance was not booted, meaning that the computer was booted from some other media (such as a DVD, CD, USB key, or hard disk drive), you must manually invoke the Windows Deployment Services mode of Setup. The packet contains the IP address of the PXE server that the boot image was downloaded from. The Windows Deployment Services client uses this information to 27
Check
Explanation
determine which Windows Deployment Services server to contact. Is Setup.exe running from the Windows system drive? Before starting in Windows Deployment Services mode, the next check is to locate where Setup.exe is running. If Setup.exe is running from the same location as the system drive of Windows PE (for example, X:), Setup will start in Windows Deployment Services mode. If Setup.exe is running from a location other than the system drive, Setup will start in normal mode. This accounts for the case in which Windows PE is booted from a nonMicrosoft PXE server and Setup.exe is started from a shared network folder. In this scenario, Windows Deployment Services is not present in the environment, and Setup.exe will therefore not start in Windows Deployment Services mode.
28
In This Topic
When Images Are Verified How Images Are Enumerated How Images Are Compressed How Images Are Captured
29
Action
Create an image group. Add the first image to an image group. Add subsequent images to an image group. Export an image. Append an image to an existing .wim file. Create an install image by using the Image Capture Wizard. Create a new capture image. Create a new discover image. Convert a RIPREP 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 .wim file Either LZX or XPRESS. The default compression type is XPRESS. LZX LZX LZX
31
8. The Image Capture Wizard uploads the image to the Windows Deployment Services server (optional).
In This Section
How Prestaged Devices Work How the Auto-Add Policy Works How Domain Controllers and Global Catalogs Work
In This Topic
How Prestaged Clients Are Located When Prestaged Clients Are Joined to a Domain 32
34
Examples
The following example cases outline the Windows Deployment Services search behavior, depending on your configuration. Note that you would run WDSUTIL /Set-Server /DomainSearchOrder:GCOnly (also the default configuration) to search global catalogs first and then search domain controllers. Conversely, you would run WDSUTIL /Set-Server /DomainSearchOrder:DCFirst to search domain controllers first and then search global catalogs.
Scenario Result
Case A /DomainSearchOrder:GCOnly
BINLSVC connects to global catalog-A. The object is not found, 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. No further action is required by BINLSVC. Result: BINLSVC connected to one server.
Case B /DomainSearchOrder:GCOnly
BINLSVC connects to global catalog-A. The object is found. Global catalog-A also contains a writeable copy of the prestaged device object in its domain controller partition. AD DS attributes are read from there. Result: BINLSVC connected to one server.
Case C /DomainSearchOrder:GCOnly
BINLSVC connects to global catalog-A. The object is found. Global catalog-A does not contain a writeable copy of the prestaged device object in its domain controller partition. Therefore, BINLSVC must connect to domain controller-B to read the additional Windows Deployment Services attributes from the computer object. Result: BINLSVC connected to two servers.
Case D /DomainSearchOrder:DCFirst
BINLSVC connects to domain controller-B. The object is not found. BINLSVC connects to global catalog-A to determine whether the object exists in the forest. The object is not found. Result: BINLSVC connected to two servers.
Case E /DomainSearchOrder:DCFirst
BINLSVC connects to domain controller-B. The object is not found. BINLSVC connects to global catalog-A to determine whether the object exists 35
Scenario
Result
in the forest. The object is found. Global catalog-A also contains a writeable copy of the prestaged device object in its domain controller partition. AD DS attributes are read from there. Result: BINLSVC connected to two servers. Case F /DomainSearchOrder:DCFirst BINLSVC connects to domain controller-B. The object is not found. BINLSVC connects to global catalog-A to determine whether the object exists in the forest. The object is found. Global catalog-A does not contain a writeable copy of the prestaged device object in its domain controller partition. Therefore, BINLSVC must connect to domain controller-C to read the additional Windows Deployment Services attributes from the computer object. Result: BINLSVC connected to three servers. Case G /DomainSearchOrder:DCFirst BINLSVC connects to domain controller-B. The object is found. BINLSVC reads additional Windows Deployment Services attributes from domain controller-B. Result: BINLSVC connected to one server.
36
2. Windows Deployment Services checks the Auto-Add policy to see it should answer clients. If the Auto-Add policy is set to answer clients, the process continues. If the Auto-Add policy is set to not answer clients, the client request is ignored. 3. Windows Deployment Services queries AD DS. If the device is prestaged, the device is answered and Auto-Add policy is not used. If the device is not prestaged, the process continues. 4. If the Auto-Add policy is set to answer only known clients and the client is not prestaged, the client request is ignored. If the server is set to answer all clients even those that are not known the process continues. 5. The Auto-Add policy is queried. If pending functionality is enabled, then the client will await approval from the administrator. If pending functionality is not enabled, then the client installation will proceed. 6. The Auto-Add devices database is queried. If the device does not exist in the Auto-Add devices database, this computer has not attempted to boot before. Skip to step 7. If the device does exist in the Auto-Add devices database and the status of the device is approved, the device is placed into the pending queue awaiting AD DS replication. Actions beginning at step 3 will be repeated per the clients defined polling interval. If the device does exist in the Auto-Add devices database and the status of the device is rejected, the client request is ignored. If pending functionality is turned on, the device is added to the Auto-Add devices database. 7. The device remains in the pending state until one of the following occurs: If the device is approved, it is sent the settings for its architecture. Additionally, it is possible for you to override the defaults when you manually approve a device. Skip to step 8. If the device is rejected, it will be sent the file Abortpxe.com, causing the device to boot to the next device in the boot order. If the device times out, the device will boot from the next device in the boot order. If the user cancels the PXE request, the device will boot from the next device in the boot order. The device will re-enter the pending state on the next reboot if the Auto-Add Devices database still contains the computer entry. 8. If the device is approved, the following will occur: A unique name is created for the device, and the device will be added to AD DS, 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). The computer and all of its properties will be added to a domain controller where the computer account object will be created. The computer is sent another network boot program (NBP). If you did not specify this NBP when the device was approved, the default settings will be used. 37
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 computer record is updated to approved in the Auto-Add devices database. If this process fails, the device is still answered.
38
security policies, and security relationships with other domains. Objects within a domain are only writeable on domain controllers for that domain. A site consists of one or more TCP/IP subnets. The site enables you to configure AD DS access and replication topology to take advantage of the network topology. 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. If local domain controllers and global catalogs are not available, BINLSVC uses those that are outside of the local site (preferring those that are available with the lowest site cost). BINLSVC searches the global catalog for attributes, including netbootGUID and netbootMachineFilePath. Using a global catalog greatly reduces search times and avoids unnecessary Lightweight Directory Access Protocol (LDAP) referrals. BINLSVC queries a writeable domain controller for the domain where the Windows Deployment Services PXE server resides. . It queries for the following attributes: netbootAnswerOnlyValidClients, netbootAnswerRequests, netbootMaxClients, netbootSCPBL, netbootServer BINLSVC uses the DSGetDcName() API. It passes the DS_GC_SERVER_REQUIRED flag whenever it needs to locate a global catalog. For more information, see DSGetDcName() (http://go.microsoft.com/fwlink/?LinkId=81494). BINLSVC searches global catalogs before searching domain controllers when attempting to locate computer account objects. By doing this, a single search against AD DS can find a prestaged computer. If you do not have a local global catalog, you should have BINLSVC use a local domain controller rather than connect across a wide area network (WAN) to a global catalog.
When querying for the attributes listed earlier in this topic that are not part of the partial attribute set.
40
41
42
Banned GUIDs
Various system builders and vendors have failed to implement GUIDs correctly per the PXE spec. The most common errors occur when no GUID is set or when several computers have the same GUID. The duplicate GUID problem seems to be more prevalent on x64-based computers. Because it is difficult to change the GUID on a computer, Windows Deployment Services filters known bad (not valid) GUIDs. To configure this behavior, you first must identify any duplicate GUIDs and then add the GUIDs to the BannedGuids registry key (see Windows Deployment Services Registry Entries). Then, if a computer with a banned GUID attempts a network boot, the 43
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 clients architecture. This enables a PXE server to know (at boot time) the exact architecture of the client from the first network boot packet. On many x64-based computers, the architecture value either is not set or is not set to the expected value. Generally, this means that the architecture is specified as x86-based but the computer is x64-based. The client system architecture values are listed in the following table.
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
provider A can state that it does not want to answer the client. The request then gets forwarded to provider B. The constraints associated with the PXE request time-out can create several issues, including the following: A malfunctioning provider toward the beginning of the order can negatively affect providers at the end of the order. External entities can cause undesirable results. As in the preceding example, if an external data source is slow in responding, it may cause the client to fail when it attempts a PXE boot. There is a limit to how many providers can be on the same server at one time. For example, assume that each provider takes one second to process the request and hand it to the next provider. 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, because of the number of providers registered and the time that it takes each provider to process the request.
Example Scenario
The following is an example of a coexistence scenario. Assume that there are two AD DS forests on the same local area network (LAN) segment: One forest serves AdventureWorks.com, and a second forest serves AlpineSkiHouse.com. Adventure Works wants its PXE server to answer only computers it knows about. Alpine Ski House wants its PXE server to answer all requests, even those from clients that are not prestaged. To set the PXE server for Adventure Works to answer only known clients, Alpine Ski House wants to set their PXE server to delay answering clients until a specified time threshold is met. The intent is that if a client request is still active after the time threshold has been reached, the client is unknown (not prestaged) and should be answered by the PXE server for Alpine Ski House. 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. For Windows Deployment Services to respond to the clients boot request, this value must be greater than the value of the response delay setting. The exception to this occurs for prestaged clients, which will always be answered by the server immediately.
45
46
the next block in the sequence until the ACK packet for the previous block is received. As a result, on a slow network, the round-trip time can be very long. However, this is improved in Windows Server 2008 because of TFTP windowing. TFTP windowing enables you to define how many data blocks it takes to fill up a window. The data blocks are sent back to back until the window is filled, and then an ACK packet is sent. The result is fewer ACK packets and much faster download times for the client. Using the BCDEdit command-line tool, you can change the TFTP block size and the TFTP window size to optimize performance in your environment. For instructions, see How to Modify the BCD Store Using Bcdedit (http://go.microsoft.com/fwlink/?LinkId=115267). Although configuring the TFTP block size will make TFTP downloads faster, there are two things you need to be aware of: TFTP is implemented in the operating system loader (Bootmgr.exe), but the send and receive functionality with User Data Protocol (UDP) is implemented in the BIOS. The BIOS buffers the network packets that make up the single TFTP block. If you make the TFTP block size too large, the buffer used by the BIOS will fill up and be overwritten, causing the download to fail. The memory buffer behavior is unique to the BIOS manufacturer, and you cannot adjust it by using Bootmgr.exe. Therefore, results may vary greatly based on the make and model of the computer. Unfortunately, there is no way to calculate the block size upper limit for a particular computer, other than trial and error. The configured block size applies to all clients. You can set this value only as high as the block size upper limit that all the clients on the network support. Note that a client cannot fall back to a default block size if the configured block size is too large.
In This Topic
How Windows Deployment Services Determines the NBP How an NBP Is Downloaded How PXE Referrals Work
48
The following is example output of the netbootMachineFilePath attribute, obtained by using the Ldp graphical user interface (GUI) tool, which you can use to view objects stored in AD DS.
***Searching... ldap_search_s(ld, "DC=domain,DC=com", 2, "(&(objectClass=*)(netbootMachineFilePath=*))", attrList, 0, &msg)
Result <0>: (null) Matched DNs: Getting 1 entries: >> Dn: CN=Prestage1,CN=Computers,DC=domain,DC=com 5> objectClass: top; person; organizationalPerson; user; computer; 1> cn: Prestage1; 1> distinguishedName: CN=Prestage1,CN=Computers,DC=domain,DC=com; 1> name: Prestage1; 1> netbootMachineFilePath: machine.domain.com\boot\x86\pxeboot.n12; 1> canonicalName: domain.com/Computers/Prestage1;
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, Windows Deployment Services reads the netbootMachineFilePath attribute of the clients computer account object to determine the path and file name of the correct NBP. Is the unknown client configured to perform PXE boots without requiring F12? You can set this value by running WDSUTIL /Set-Server /AllowN12ForNewClients:Yes. If you configure this setting, Windows Deployment Services looks for a prestaged device in AD DS. If it does not find one, then the device is classified as unknown and, the device will be sent 49
the .n12 NBP. If the device is found in AD DS, Windows Deployment Services sends the device the default NBP for the clients architecture. What is the default NBP for the clients architecture? If the client does not have the netbootMachineFilePath specified in the computer account object in AD DS, the default NBP will be used.
x86-based and x64 BIOS-based computers with architecture detection, pending devices, or referrals
50
51
As illustrated in this diagram, a new client sends a PXE request. This request is answered by the active Windows Deployment Services server (WDS referral server in this diagram). Clients that have been prestaged in Active Directory Domain Services (AD DS) will be answered by this PXE server. WDS referral server checks AD DS to verify whether a computer account object exists for this client. This check reveals that the client was prestaged, and a property in the computer account indicates that the clients referral server is WDS server 3. At this point, WDS referral server passes the request on to WDS server 3 , using the DHCPREQUEST packet. The client then begins the Trivial File Transfer Protocol (TFTP) download of the NBP from WDS server 3. Note that in the network design of this diagram, the only purpose of PXE referral servers 1, 2, and 3 is to provide images of the operating system. These servers do not respond to initial client service requests. Rather, WDS referral server services all PXE requests, checks AD DS for the existence of a prestaged computer account object, and then refers the client to the specified Windows Deployment Services server.
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
Topic
Subtopic
Unknown Clients Automatically PXE Boot .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, use the management tools. Do not modify these registry keys directly. For instructions on how to modify them, see How to Perform Common Tasks (http://go.microsoft.com/fwlink/?LinkId=115268).
Values: False means that client requests will not be answered, and True means that they will be answered. You can configure Windows Deployment Services to answer all incoming PXE requests or only those from prestaged clients (for example, WDSUTIL /Set-Server /AnswerClients:All). The policy is stored in the registry at
53
Values: False means that all client requests will be answered, 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. This time is only used when a successful authorization process has been 54
Name
Description
performed, irrespective of whether the server was previously authorized. Type: DWORD Default value: 3,600 seconds (one hour) AuthFailureRetryTime Specifies the amount of time (in seconds) that the PXE server will wait if any step of authorization fails. So, if the PXE server is unable to query AD DS successfully, this value is used to determine the time before trying AD DS again. DisableRogueDetection Type: DWORD Default value: 30 seconds Type: DWORD
This cache is used whenever the PXE server receives an error while communicating with AD DS. The cached results are used to authorize or unauthorize DHCP, and then AuthFailureRetryTime
55
is used to determine when to query AD DS again. Authorization of PXE servers occurs on the child objects of CN=NetServices, CN=Services, CN=Configuration, DC=Domain, and DC=com.
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, the following registry value is configured:
56
Value: 0 or not present means that the architecture discovery is enabled; 1 means that it is disabled (this is the default value).
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, with one string per line. The correct format is as follows: {1acbf4473993e543a92afadb5140f1c8}, which should match what you see when you perform a PXE boot on a client (without dashes).
57
Creating a registry entry pointing to their .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 .dll Designating the provider as critical by adding the IsCritical registry setting (optional) Specifying the entry point routine in the provider .dll
The first option listed is considered the standard server configuration, and all of the other cases are more advanced networking scenarios. To satisfy all four configurations, WDSPXE has the ability to listen only on particular network interfaces. These interfaces may be specified either by IP address or by MAC address. During installation, the PXE server is automatically configured to listen on all active (that is, nondisabled) interfaces. After installation, you can adjust the default behavior by using the settings for the registry keys listed in the following table. 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. This can be either of the following values: 0 means exclude (this is the default value). That is, interfaces that are defined in BindInterfaces will be excluded. 1 means include. That is, only those interfaces that are defined in BindInterfaces will be included. Note 58
Entry
Data type
Changes to BindPolicy are automatically picked up by the PXE server and do not require a service restart. BindInterfaces REG_MULTI_SZ Lists all interfaces that the PXE server should listen on or exclude, 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. If BindPolicy is set to 0 (exclude), set BindInterfaces to the IP addresses or MAC addresses for the interfaces that you want to include. The default value is blank (no interfaces are excluded or included). You can specify MAC addresses as a sequence of hexadecimal characters, and you can format them with uppercase or lowercase hexadecimal characters, raw, or separated by colons or dashes. IP addresses must use dotted notation (for example, MAC:ABCDEFABCDEForIP:10.10.2.2.). To add a MAC address to the BindInterfaces list, you can use the WDSUTIL command-line tool. To add an IP address, you must edit the registry value manually. Caution Make sure that the IP or MAC addresses you enter are correct. Otherwise, the service will start, log an event, and then stop.
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
Value: The file path to the Windows Deployment Services client unattend file (for example, D:\RemoteInstall\WDSClientUnattend\WDSClientUnattend.xml).
60
Per-Client NBP
Configuring a network boot program (NBP) for each server is the default method. You can override this method on a per-client basis. The NBP is defined by the following registry settings (where <arch> is either x86, x64, 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, boot\x86\pxeboot.com). Name: .n12 Type: REG_SZ Value: The relative path to the NBP that will be sent by using the AllowN12ForNewClients setting (for example, boot\x86\pxeboot.n12). For more information, see Unknown Clients Automatically PXE Boot.
.n12 NBP
Windows Deployment Services sends the defined .n12 NBP according to the following registry settings (where <arch> is either x86, x64, or IA64): HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINL SVC\BootPrograms\<arch> Name: .n12 61
Type: REG_SZ
Value: The relative path to the NBP that will be sent according to the AllowN12ForNewClients setting (for example, boot\x86\pxeboot.n12). Note Although the setting implies that new and unknown clients will receive the .n12 NBP, you can also configure the any other combination by specifying an NBP other than.n12.
If you combine these two configurations, the client will automatically boot from the network without requiring user intervention and the computer will end up in a circular loop (always booting from the network and never booting from the hard disk drive). The following 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.
1 means that during the imaging process, the value stored in the netbootMachineFilePath attribute in AD DS for the prestaged device will be cleared. The value for the referral server is also stored in the netbootMachineFilePath attribute. Therefore, when you specify 1 and this value is cleared, any server in the domain can answer the client the next time it reboots. Using this option ensures that on the next boot, the computer will receive the default server NBP (commonly the .com version). Therefore, the computer will try to boot from the network (because the network is listed first in the BIOS boot order), but the computer will be sent the .com NBP. After allowing sufficient time for the user to press the F12 key, this option will time out and the device will boot from the hard disk drive. The value is cleared after the image is applied, as one of the final actions performed by Windows Deployment Services.
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.
Value: Message shown to the user by Wdsnbp.com. The default setting is for this to be blank.
Time-Out Value
The client state is not maintained on the server. Rather, the Wdsnbp.com program polls the server for the settings in the following keys after it has paused the clients boot. 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). The default setting for these values is to poll the server every 10 seconds for 2,160 tries, bringing the total default time-out to six hours. 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
The name of the Windows Deployment Services server that the client should download the NBP from.
Value: The name of the server to refer the client to. The default setting is for this value to be blank (no server name). Name: BootProgramPath Type: REG_SZ
Value: The partial path and NBP that the client should receive. The default setting is for this value to be blank (no path). The name of the boot image, which 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. The primary user associated with the generated computer account. This user will be granted JoinRights authorization, as defined later in this section. Name: BootImagePath Type: REG_SZ
Value: The name of the boot image that the client should receive. The default setting is for this value to be blank (no boot image). Name: User Type: REG_SZ
Value: The owner of the computer account that was created. The default setting is the domain administrator. Name: JoinDomain Type: REG_DWORD
Value: 0 or not defined means that the computer should be joined to the domain. 1 means that the computer should not be joined to the domain. Specifies the type of rights to be assigned to the user. JoinOnly requires the administrator to Name: JoinRights Type: REG_DWORD Value: 0 or not defined means 64
Configuration setting
Registry value
reset the computer account before the user can join the computer to the domain. Full gives full permissions to the user (including the right to join the domain).
Static Configuration
In some circumstances, you may want to statically configure the domain controller and the global catalog that Windows Deployment Services will use. 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. 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, so this value must be a writable domain controller. Name: DefaultGCServer Type: REG_SZ Value: The name of the global catalog that Windows Deployment Services should use. This can be either the NETBIOS name or the FQDN.
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, and then the domain controller; 1 means that the domain controller will be searched first, and then the global catalog. Setting this value to 1 may lead to less efficient use of AD DS in a multidomain environment. If a prestaged device is not found in the local domain controller, Windows Deployment Services must perform an additional query against a global catalog because the 65
domain controller is not guaranteed to have knowledge of all objects. Therefore, 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.
66