How PXE Requests Work

Applies To: Windows Server 2008

In This Topic

• How PXE Requests Are Handled

• When Clients Are Answered

• How a Computer Is Identified

  • Banned GUIDs

  • Architecture Detection

• How the PXE Response Delay Works

  • Issues

  • Example Scenario

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.

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 server’s properties (right click the server in the MMC-snap in, and click Properties).

The following diagram illustrates the answer policy.

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 GUID will be stripped from the packet so that the packet will contain only the MAC address of the client.

Architecture Detection

Each computer that will be booting from the network should have DHCP option 93 to indicate the client’s architecture. 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.

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 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 client’s 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.