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

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

Windows Deployment Services Components

Windows Deployment Services contains five main components: Windows Deployment Services Server Components. The Windows Deployment Services server service (WDSServer) is the main server-side service. It provides basic functions such as memory management, thread pooling, and network interface binding to support its subcomponents (known as providers). PXE Server Components. These components are associated with booting a client computer from the network. This includes the Pre-Boot Execution Environment (PXE) server, the PXE providers, and the Trivial File Transfer Protocol (TFTP) provider. Image Store Components. These components are associated with assisting the Windows Deployment Services client in locating, selecting, and installing an operating system image. It is the protocol used for communication to and from the client and server, unattend processing, and install image enumeration. Windows Deployment Services Client Component. 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. This application is the Setup.exe program from Windows Vista with some additional functionality that is needed for network deployments.

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. It provides basic functions such as memory management, thread pooling, and network interface binding to support its hosted subcomponents, known as providers. 7

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

Diagram of Deployment Server Components

The following diagram shows the interaction among these components for the Deployment Server role service. 8

Diagram of Transport Server Components

The following diagram shows the interaction among these components for the Transport Server role service.

RemoteInstall Folder Physical Structure

When the server is configured, a file share with the default folder name RemoteInstall and the default share name REMINST is created to contain install images, boot images, PXE boot files, and the Windows Deployment Services management tools. The RemoteInstall folder contains some or all of the following subfolders: Admin. Contains management tools specific to Remote Installation Services (RIS) functionality. This folder is present only if you upgrade from Windows Server 2003. Boot. Contains the boot images and the associated PXE boot files. Images. Contains the install images. Mgmt. Contains the Auto-Add devices database.

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.

Auto-Add Database Architecture

The Auto-Add database (named Binlsvcdb.mdb) can be found in the RemoteInstall\MGMT folder. The database is created by Windows Deployment Services the first time the Auto-Add policy is enabled. You enable the policy on the PXE Response Settings tab of the server's properties, by selecting the For unknown clients, notify administrator and respond after approval check box. The database that is used for this is the Extensible Storage Engine (ESE) database. This is the same database that is used by AD DS, Windows Internet Name Service (WINS), and Exchange. The database consists of a single table, which is shown here.
Field name Description

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

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 end goal is to enable a client computer to boot from the network and receive a network boot program (NBP) from a server. The PXE server implementation for Windows Deployment Services is divided into two pieces: a PXE server (WDSPXE) and the PXE providers. WDSPXE contains the core networking capability, and it supports a plug-in interface. Plug-ins are called PXE providers, and they can be developed by Microsoft or independent software vendors. 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. This PXE implementation enables you to do the following: Change the provider. The PXE provider installed by default (on a Deployment Server) is BINLSVC. You can remove BINLSVC from the server and replace it with a custom provider. Note that BINLSVC is not installed with Transport Server. Run multiple providers on a single server. Rather than having two PXE listeners on the network (each with its own application logic), you can have one PXE listener on the network with two or more sets of application logic. WDSPXE maintains a list of providers, and the order of providers determines how a client request is handled. This means that when a PXE request is received, the Windows Deployment Services server will hand the request to the first provider in the list. That provider has the opportunity to answer. Depending on the response from that provider, the request may be forwarded to the next provider in the list, and so on. Note that you can add a provider to the list by registering it with WDSPXE. For more information, see the PXE Providers That Are Registered section of the Windows Deployment Services Registry Entries topic.

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. One new aspect is a new firmware-independent data store that contains boot configuration data (BCD). The BCD store defines how the boot menu is configured. The store is a namespace container for BCD objects and elements that holds the information that is required for loading Windows or running other 12

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.

The BCD Store Physical Structure

There are four possible classes of client computers, so four BCD stores are created in the \Tmp folder: x86-based. This file consists of the Default.bcd file from the \Boot\x86 folder and all boot image BCDs from the \Boot\x86\Images folder. Itanium-based. This file consists of the Default.bcd file from the \Boot\ia64 folder and all boot image BCDs from the \Boot\ia64\Images folder.

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.

Image Store Components

The image store is a collection of image groups that stores the .wim images and helps the client computer obtain and install the images. An image group is a collection of images that share security options and file resources. An image group consists of the following two components: The Res.rwm file. The resource .wim file (Res.rwm) contains the file resources for all of the images in an image group. Each image group has its own Res.rwm file. File resources are single-instanced because they are shared across the image group. To service an image (for example, to apply an update), you must have access to the Res.rwm file. Although the file name seems to indicate otherwise, the .rwm file is actually a .wim file. <imagename>.wim files. Each .wim image file contains the metadata that describes the image, but the actual file resources for the image reside in Res.rwm. The storage structure of the image group uses the imaging feature called capture by reference. This feature is most commonly used with split .wim files, which are the smaller pieces that result when you break up a large .wim file (typically so that you can fit the pieces of the file onto CDs). 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 .wim file that contains only the definition of the image, and another part that contains all the file resources for an image. This storage method is more efficient than the Single Instance Store service used in Remote Installation Services (RIS) in Windows Server 2003.

14

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), 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 with some additional functionality that is needed for network deployments. This mode differs from the normal 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, including an authentication and credentials page The ability to handle more advanced unattended installation scenarios, 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, Windows XP, 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.exe program from Windows Vista and supporting DLL files (including WDSClient.dll, WDScsl.dll, WDSclientapi.dll, and WDSimage.dll). The Windows Deployment Services client module and the supporting DLLs are loaded by Setup.exe only when it is in the Windows PE phase of Setup. The platform for running the client is Windows PE 2.0. The following diagram illustrates the Windows Deployment Services client architecture.

15

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. This protocol is an application-level protocol that uses remote procedure calls (RPCs) over Transmission Control Protocol (TCP). The communications protocol does the following: Sends GUID and MAC addresses to the server. Obtains a Windows Deployment Services client unattend file. Retrieves a list of available install images from the server.

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.

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. One aspect of this reengineering is a new firmware-independent data store that contains boot configuration data (BCD). The BCD store defines how the boot menu is configured. The store is a namespace container for BCD objects and elements that hold the information that is required to load Windows or run other boot applications. Physically, a BCD store is a binary file in the registry hive format. The file has the same file name as its corresponding .wim file. These BCD stores exist 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.

In This Topic
How Windows Deployment Services Determines the BCD Store How the BCD Store Is Created

17

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. You can change the netbootMachineFilePath by using the management tools. For more information, see How to Manage Client Computers (http://go.microsoft.com/fwlink/?LinkID=115265). 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. If one exists, it will be used. For example, if netbootMachineFilePath points to \RemoteInstall\Boot\x86\test\pxeboot.com and there is a BCD store in that folder, it will be used. This enables you to specify a BCD store for each computer. To do this, first create a folder on the server as a subfolder of the RemoteInstall folder; then copy the custom BCD and NBP (for example, pxeboot.com). Finally, prestage the device and set netbootMachineFilePath to point to the custom folder on the server that was created for that device. If no BCD store exists in the same folder as the NBP (that netbootMachineFilePath pointed to), Windows Deployment Services will send the architecture-specific BCD store in the \Tmp folder.

How the BCD Store Is Created

The Windows Deployment Services PXE Provider (BINLSVC) creates a BCD store for each image. This process happens automatically when the Windows Deployment Services server is started and BINLSVC is initialized. BINLSVC enumerates each .wim file within the appropriate \Boot\<arch>\Images folder, and it looks for images that are marked as bootable from RAMDISK. When it finds an image, the server creates a BCD store that contains an operating system entry for the image, as long as the following are true: A corresponding BCD store for the image does not already exist. The time stamp of the .wim file is newer than the matching BCD store. This would be the case if the image metadata was updated (that is, if you renamed the image and expected the new name to be reflected in the boot menu display). If you add or modify a boot image while the service is running, the server must be signaled that a change has occurred before it will begin the BCD creation and update process. If you use the Windows Deployment Services management tools to make changes, the changes will be picked up. But if you manually copy a file, the changes will not be automatically picked up. The next step in the BCD generation process is to create the BCD store that a client computer will download. To produce a BCD store that contains the required information, the information stored in Default.bcd is concatenated with the information stored in the per-image BCD stores. The following sequence of steps outlines this process. 18

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.

How Booting into a Boot Image Works

In This Topic
Overview RAMDISK Boot Image Process

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.

RAMDISK Boot Image Process

The following steps describe the overall process for booting into a boot image from the network. 1. The BIOS or Extensible Firmware Interface (EFI) of the computer signals a request to boot from the network. 2. PXE ROM gets an IP address from a Dynamic Host Control Protocol (DHCP) server and locates a server. 3. PXE ROM downloads a network boot program (NBP) by using Trivial File Transfer Protocol (TFTP). For EFI, skip to step 5. 20

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.

How Unattended Installation Works

This topic contains information about the process that takes place when you perform an unattended installation.

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

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). The process works as follows: 1. The Windows Deployment Services client starts networking and connects to the Windows Deployment Services server by using the remote procedure call (RPC) communication protocol. This entire transaction occurs over unauthenticated RPC because the client has not yet entered credentials. 2. The Windows Deployment Services client sends information to the server that will help the server identify the client. 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). 3. The Windows Deployment Services server determines the unattend file to send to the client. 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, that unattend file will be used. If the device is found but does not have a specified Windows Deployment Services client unattend file, the process continues. If the device is not found (meaning that it has not been prestaged), the process continues. 4. The Windows Deployment Services server checks its own unattend policy. This policy is defined globally and specifies whether Windows Deployment Services client unattend functionality at the server level is currently on or off. If it is off, no further action is required (as far as unattend is concerned). If it is on, the client will be passed the unattend file for its architecture. 5. 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. The Windows Deployment Services client receives the data, de-serializes it, and writes it to X:\sources\wdsunattend\wdsunattend.xml. 6. The client notifies Setup about the unattend file, which triggers Setup to read the unattend settings and populate the relevant data. Setup then proceeds in Windows Deployment Services mode For more information, see When Setup Is Started in Windows Deployment Services Mode in How the Windows Deployment Services Client Works. 7. At the conclusion of the Windows Deployment Services client installation phase, the Windows Deployment Services client unattend file is discarded and an image unattend file replaces it for the remaining phases of Setup.

22

How Unattend Works for the Remaining Setup Phases

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

Diagram of the Unattended Setup Process

The following diagram illustrates the process that take place during an unattended setup.

23

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

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

Was Windows PE started by using PXE boot?

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.

Manually Invoking Setup.exe

It is possible to force Setup.exe to start in Windows Deployment Services mode. This is particularly valuable if you want to run Setup from a Windows PE instance that was not started by a PXE boot. You can force Setup.exe to start in this mode by specifying the /wds option on the command line when starting Setup (for example, \sources\setup.exe /wds). Note that you will receive an error if you use the /wds command outside of Windows PE.

Diagram of Startup Logic

The following diagram that illustrates the Windows Deployment Services client startup logic

28

How the Image Store Works

The image store stores the .wim images and helps the client computer obtain and install the images. The image store is a collection of image groups. An image group is a collection of images that share security options and file resources.

In This Topic
When Images Are Verified How Images Are Enumerated How Images Are Compressed How Images Are Captured

29

When Images Are Verified

Windows Deployment Services verifies each block of images to ensure that the source image file is not corrupt. 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 .wim file or the hashes of the actual files. 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 following sequence of steps outlines this process. 1. A remote procedure call (RPC) communication channel is established between the client and the server. 2. Credentials are specified on the client computer (either manually or in an unattend file), and the user is authenticated. 3. The server enumerates all .wim files within the image store, including .wim metadata, the folder that contains the .wim file, file name of the .wim file, and the access control list (ACL) of the file. Note that only files within the first level of the image group folder are enumerated; folders and subfolders are not enumerated. This shortens the time for the image enumeration and ensures that other .wim files (such as data .wim files in a $OEM$ folder structure) are not accidentally returned during the enumeration process. 4. An authentication token is obtained by the server for the user who is logged on. 5. Any ACLs that were found during enumeration are checked against the user. 6. The server sends information for all images that the user has permissions to view back to the Windows Deployment Services client. 7. The Windows Deployment Services client performs additional image filtering, if necessary. 8. The list of available images is displayed to the user on the image selection page.

How Images Are Compressed

All images within an image group share the same compression type. The valid compression types are as follows: no compression, XPRESS (quick compression), and LZX (maximum compression). Although the decompression times are essentially equivalent for both the XPRESS and LZX types, the initial compression time (performed when the image is created) is longer for LZX. The following table shows the expected compression type for each action. 30

Action

Expected compression type

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

How Images Are Captured

The screens in the Image Capture Wizard walk you through the process of capturing the image, as described in the following sequence of steps. 1. You boot the computer into the capture image. 2. The Image Capture Wizard is started. 3. The Image Capture Wizard searches for the WDSCapture.inf file in the X:\Windows\System32 folder. If the file exists and contains settings, those settings are used. If the file exists but settings for a particular section are missing, you must enter the missing information in the UI. If the file does not exist, you must enter the missing information in the UI. 4. The Image Capture Wizard scans all local drives for an offline image that has been prepared with the Sysprep tool. Note that the wizard does not have the ability to capture a partial volume. 5. The Image Capture Wizard extracts metadata from data points in the offline image (such as the hardware abstraction layer (HAL) type, architecture, product name and type, operating system version, and language). 6. The Image Capture Wizard captures the selected volume and saves it to the specified .wim file. 7. The Image Capture Wizard updates the metadata of the image with the information that was extracted from the offline image, in addition to any values that were input by the user.

31

8. The Image Capture Wizard uploads the image to the Windows Deployment Services server (optional).

How Windows Deployment Services Uses Active Directory

Windows Deployment Services uses Active Directory Domain Services (AD DS) for a variety of reasons. AD DS is its data store, and it contains all of the necessary helper routines. Windows Deployment Services also links physical booting computers to computer account objects in AD DS. The data used by Windows Deployment Services is stored in computer account objects and Service Control Points (SCPs). Computer account objects. You can prestage a device, which means to link a physical computer to a computer account object in AD DS. By doing this, you can control the installation for the prestaged device. For example, using WDSUTIL you can configure the network boot program and the unattend file that the client should receive, as well as the server from which the client should download the boot files. Service Control Point objects. The computer account object for the Windows Deployment Services server contains a child object called an SCP object. This object is created the first time Windows Deployment Services is started, and it indicates that the computer account object is acting as a Windows Deployment Services server. The SCP object also stores some configuration settings for Windows Deployment Services (for example, whether the server should answer Pre-Boot Execution Environment (PXE) boot requests).

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. They correspond to physical devices that will boot from the network by using Windows Deployment Services.

In This Topic
How Prestaged Clients Are Located When Prestaged Clients Are Joined to a Domain 32

Diagram of Prestaging Clients

How Prestaged Clients Are Located

When a client computer attempts to boot from the network, limited data is transferred from the client to the server as part of the Pre-Boot Execution Environment (PXE) protocol. Windows Deployment Services can locate prestaged clients by using either of the following: GUID (recommended). 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 GUID format occurs in two formats: String format (also known as wire format). Example: 0123456789ABCDEF0123456789ABCDEF Display format. 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. For details, see How to Perform Common Tasks (http://go.microsoft.com/fwlink/?LinkId=115268). MAC address. The MAC address is a 128-bit hardware address that uniquely identifies each node of a network. 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. 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))). This filter ensures that a device will be found if it is prestaged using either a computer GUID or a MAC address. The netbootGUID attribute on a prestaged client is used to store the value of the physical computers GUID or the MAC address. You can use the Ldp GUI tool to view this value. When a PXE request is submitted, it contains both of these values in the DHCPREQUEST packet. The computer's GUID is in the Dynamic Host Control Protocol (DHCP) options (tag 97 in DHCP options), 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. The server extracts both pieces of information, binds against an AD DS server, and searches for a match on either value. If a match is found, the client is considered known. If no match is found, the client is considered unknown. 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. Two computers are found in AD DS with the same MAC address. For example, if you prestage the MAC address of Server1, then you build and prestage Server2 by using the network adapter from Server1. Now you have two prestaged devices in AD DS with the same MAC address. Two devices in AD DS represent a single physical computer one device prestaged with a computer GUID, and the other one prestaged with a MAC address. 33

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. You can override this by running the /JoinDomain:No command on the command line (for example, WDSUTIL /Set-Device /Device:Computer2 /User:Domain\user /JoinRights:JoinOnly /JoinDomain:No). If a client computer is not prestaged, the per-server policy settings dictate the domain join behavior (for example, the computer name and location in AD DS). In all cases where Windows Deployment Services creates a computer object to facilitate the domain join process, the account that is created will contain either the client's GUID or MAC address (as stored in the netbootGUID attribute). This automatic prestaging is beneficial because if you rebuild a computer (for example, from a failed hard disk drive), the computer will be joined to the same domain using the same computer name. For instructions on setting these options, see the Prestage Computers section in How to Manage Client Computers (http://go.microsoft.com/fwlink/?LinkID=115265).

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.

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.

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, the computer will be in a pending state. 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.

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.

Diagram of the Auto-Add Policy

The following diagram illustrates the Auto-Add policy.

38

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. BINLSVC is in charge of communicating with Active Directory. When joining a computer to a domain, BINLSVC performs the following sequence of steps. 1. BINLSVC determines that it needs to perform a domain join. For nonprestaged accounts, the client receives the domain join policy setting for unknown accounts. For prestaged accounts, the client receives the value of the JoinDomain registry setting as configured by /JoinDomain command line option. 2. The credentials of the user are entered into the credentials page, either manually or by using an unattend file. Note that the remaining steps in this sequence are performed in this users context. 3. For nonprestaged accounts, BINLSVC creates a computer object in Active Directory Domain Services (AD DS), using the settings from the server (such as the computer naming policy or what organizational unit (OU) to create the computer account in). 4. BINLSVC resets the client computer account in AD DS. For nonprestaged computers, this is the computer account created in step 3. 5. BINLSVC looks for an image unattend file. If the image unattend file exists (and is in the correct format), the information that is required to perform the domain join (the computer name, the domain, and the computer password (for Windows Vista images)) is inserted into the image unattend file. If an image unattend file does not exist, the template unattend file for the image type is used. The information required to perform the domain join (the computer name, the domain, and computer password (for Windows Vista images)) is inserted into the template unattend file.

How Domain Controllers and Global Catalogs Are Used

AD DS topologies are generally organized by domain and by site. A domain is a collection of user objects, computer objects, and other objects. These objects share a common directory database, 39

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.

How BINLSVC Communicates with Domain Controllers

In some situations, the Windows Deployment Services server must create computer objects on behalf of the user. To do this, BINLSVC binds to a domain controller from where the computer account is created. For example, if there is a company named Datum Corporation with two domains in a forest adatum.com and sub.adatum.com and BINLSVC needs to create a computer account in sub.adatum.com, it will use a domain controller from sub.adatum.com. BINLSVC communicates directly with domain controllers in the following circumstances: When using the Auto-Add devices policy to add computer accounts to AD DS. When creating computer objects on behalf of users.

When querying for the attributes listed earlier in this topic that are not part of the partial attribute set.

40

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, there are three possible return values: Service the client request. This signals that the provider is answering the client. Ignore the client request. This signals that the provider has processed the request and, using its policy settings, has determined that it owns answering the client and that it should ignore the client request. In this case, the client PXE boot will eventually time out. 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. The following flowchart traces the PXE response logic when two or more providers are registered.

41

When Clients Are Answered

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

42

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. 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). Also, it is fairly common for a network adapter to be moved from one computer to another. Therefore, the uniquely identifying feature of one computer can easily be transferred to another.

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

How the PXE Response Delay Works

The PXE protocol defines the client time-out for a PXE request as 28 seconds (although in practice, many vendors have implemented a much shorter time-out value). 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. The response delay applies only to clients that are not prestaged. 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. Because this method depends on timing, general networking factors (slow client, dropped packets, and so on) can cause unintended results. It is possible that the desired PXE provider may not have the opportunity to answer the request within the specified time-out period. For example, consider that provider A is first in order, followed by provider B. The PXE request comes in and is handed to provider A. According to the policy, provider A should not answer the client. Provider A begins conversation with its data store. The response is so slow from the data store that the client's PXE request times out before 44

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.

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

How DHCP Authorization Works

When a Pre-Boot Execution Environment (PXE) boot is initiated, the PXE ROM requests an IP address from a Dynamic Host Configuration Protocol (DHCP) server, using the normal DHCP discovery process. As part of the initial DHCP discovery request, the client computer identifies itself as being PXE-enabled, which indicates to the PXE server that the client needs to be serviced. After the client has obtained a valid IP address from a DHCP server, the client attempts to locate and establish a connection with the PXE server to download a network boot program (NBP). By default, the Windows Deployment Services PXE server does not need to be authorized to service client computers. However, you can enable DHCP authorization, which is also known as rogue detection. Authorization checks occur only if authorization checking is enabled and the PXE server is configured to listen on port 67. This means that authorization checks take place only in scenarios in which Windows Deployment Services is running on a computer without DHCP. If Windows Deployment Services and DHCP are running on the same physical computer, this means that the DHCP server is listening on port 67 and is responsible ensuring authorization. After Windows Deployment Services checks for authorization, a polling mechanism runs every hour to ensure that the authorization status has not changed. 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). Alternatively, you can restart the PXE server to pick up the change to authorization settings immediately. If the PXE server is deemed to be unauthorized, it will not answer client requests.

How the PXE Server and Providers Interact

The following flowchart outlines how the PXE server and PXE providers interact with one another.

46

How TFTP Works in Windows Deployment Services

Trivial File Transfer Protocol (TFTP) is the network protocol used for downloading all files during network boots, including the boot image. 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

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.

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. The NBP dictates whether the client can boot from the network, whether the client must press F12 to initiate the boot, and which boot image the client will receive. NBPs are both architecture and firmware specific (BIOS or EFI) specific. On BIOS computers (per the PXE specification), the NBP is a 16-bit, real-mode application. As such, you can use the same NBP for both x86-based and x64-based operating systems that have BIOS .

In This Topic
How Windows Deployment Services Determines the NBP How an NBP Is Downloaded How PXE Referrals Work

48

How Windows Deployment Services Determines the NBP

When you run WDSUTIL /Set-Device /Device:<name> /BootProgram:<path> for a computer, the command sets the netbootMachineFilePath attribute of the prestaged computer (that is, the computer account that represents the client computer in AD DS). In the following netbootMachineFilePath attribute syntax, <PathToNBP> and <NameOfNBP> are optional, and you can specify <Server> to indicate the PXE server referral. <Server>\<PathToNBP>\<NameOfNBP> For example:
netbootMachineFilePath: machine\OSChooser\i386\startrom.com netbootMachineFilePath: machine.domain.com\boot\x86\pxeboot.n12 netbootMachineFilePath: machine netbootMachineFilePath: machine.domain.com

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.

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, pending devices, or referrals

50

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

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.

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

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

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, and 0 means not critical.

Client Answer Policy

Windows Deployment Services has a global on/off policy that controls whether or not client requests are answered. The policy is stored at HKLM\System\CurrentControlSet\Services\WDSSERVER\ProvidersWDSPXE\Providers\BIN LSVC. Name: netbootAnswerRequests Type: REG_SZ

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

HKLM\System\CurrentControlSet\Services\WDSSERVER\ProvidersWDSPXE\Providers\BIN LSVC. Name: netbootAnswerOnlyValidClients Type: REG_SZ

Values: False means that all client requests will be answered, and True means that only prestaged clientsss will be answered.

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), and 1 means enabled. Name: LogLevel Type: REG_DWORD Value: 0 or not set means OFF, 1 means ERRORS, 2 means WARNINGS, and 3 means INFO.

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

Default value: 0 means enabled, and 1 means disabled.

DHCP Authorization Cache

Whenever the PXE server successfully queries AD DS, 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. Type: DWORD The following table indicates that the last query to Localnetwork showed that the server was authorized, but Domain1 was denied.
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. 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.

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 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. Use this setting in configurations where the PXE server and DHCP are on different physical computers. This is the default value for the setting. 0 means that the PXE server will not listen on port 67. Use this setting in configurations where Windows Deployment Services and DHCP are located on the same physical computer.

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. In these circumstances, you can configure the server to bind to UDP Port 67 in nonexclusive mode by passing the SO_REUSEADDR option. For more information, see Using SO_REUSEADDR and SO_EXCLUSIVEADDRUSE (http://go.microsoft.com/fwlink/? LinkId=82387). 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, the following registry value is configured:

56

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; 1 means that it is disabled (this is the default value).

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

Order of PXE Providers

A registering provider can select its order in the existing provider list. 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

 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

Bind Policy for Network Interfaces

There are various possible network adapter configurations that you can use, 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, each with one IP address Two or more network adapters, with at least one having more than one IP address

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

Description and values

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.

Location of TFTP Files

The TFTP root is the parent folder that contains all files available for download by client computers. By default, the TFTP root is set to the RemoteInstall folder as specified in the following registry setting: 59

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, and 1 means enabled.

Per-Architecture Unattend Policy

Unattend files are architecture specific, 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, 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.xml).

Network Boot Programs

Per-Client NBP Unknown Clients Automatically PXE Boot .n12 NBP Resetting the NBP to the Default on the Next Boot

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.

Unknown Clients Automatically PXE Boot

In some cases, 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). Unknown clients receive a NBP that will cause them to perform a PXE boot automatically. This configuration is particularly useful in a lab environment where you want to immediately image new computers, but you want to ensure that existing computers are not sent through the imaging process by accidentally booting from the network. 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 .n12 NBP.

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

Resetting the NBP to the Default on the Next Boot

When implementing a fully automated experience of booting from the network, it is often necessary to do the following: Set the network as the first device in the clients BIOS boot order. Send a specific client an .n12 NBP.

If you combine these two configurations, the client will automatically boot from the network without requiring user intervention and the computer will end up in a circular loop (always booting from the network and never booting from the hard disk drive). The following 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.

Auto-Add Devices Database

If a computer requires approval before the installation will start, the computer will be in a pending state. One of the advantages of using the pending functionality is that at the time the device is approved, you can specify settings that control the clients installation experience. These settings can be global, per architecture, or specified for each approved computer. Auto-Add Policy 62

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.

Message Displayed to a Pending User

The following registry key contains the text message that is displayed to the user by Wdsnbp.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.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

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, x64, or ia64). These settings are defined per architecture, and they apply to all approved devices unless they are manually overridden when the device is approved. 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.

Name: ReferralServer Type: REG_SZ

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

The name of the NBP that the client should download.

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

Specifies whether or not the device should be joined to the domain.

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

JoinOnly. 1 means Full.

Domain Controllers and the Global Catalog

Static Configuration Search Order

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