Partager via

PXE Server Components

  • Article

Applies To: Windows Server 2008

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 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 https://go.microsoft.com/fwlink/?LinkID=110353 and Boot Configuration Data Editor Frequently Asked Questions (https://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 application’s 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.

  • 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 server’s debug log at: %windir%\Tracing\Wdsserver.log.

For more information, see How the Boot Configuration Data Store Works.