A network boot program (NBP) is the first file that is downloaded and executed as part of the Pre-Boot Execution Environment (PXE) boot process. Note that NBPs are specific to both architecture and firmware (BIOS or EFI), and they control the first boot experience (EFI stands for Extensible Firmware Interface). 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, because both are capable of running this program.

In This Topic

Note

For information about avoiding a boot loop, see Automating the PXE Boot.

Configuring the NBP

There is an NBP specified for each architecture (defined on the Boot tab in the properties of the Windows Deployment Services server). However, you can override the NBP for each server on a per-client basis (by running WDSUTIL /Set-Device /Device:<name> /BootProgram:<path>). For example, you may want to configure an NBP so that known clients receive the per-server default (presumably an NBP that requires pressing the F12 key, and unknown clients receive an 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.

List of NBPs

The following table lists the available NBPs in Windows Deployment Services.

NBP Description Architecture Firmware

PXEboot.com

(Default) Requires the user to press the F12 key for a PXE boot to continue.

x86-based and x64-based

BIOS

PXEboot.n12

Does not require pressing F12 and immediately begins a PXE boot.

x86-based and x64-based

BIOS

AbortPXE.com

Boots the computer by using the next boot item in the BIOS without waiting for a time-out.

x86-based and x64-based

BIOS

Hdlscom1.com and Hdlscom2.com

Causes computers that do not support firmware console redirection to display "Press space or F12 for network boot," using console redirection to serial port 1 or 2. Users can proceed with the boot process by pressing either key, or they can exit the boot process by not pressing either key.

x86-based and x64-based

BIOS

Hdlscom1.n12 and Hdlscom2.n12

Causes computers that support firmware console redirection will not display the prompt "Press space or F12 for network boot" and the computer will not wait for user input.

x86-based and x64-based

BIOS

Bootmgfw.efi

The EFI equivalent for Bootmgr.exe. In EFI, the choice of whether or not to perform a PXE boot is handled within the EFI shell, and not by the NBP.

x64-based and Itanium-based

EFI

Wdsnbp.com

An NBP developed for Windows Deployment Services that serves the following general purposes:

1. Architecture detection

2. Pending computer scenarios. When the Auto-Add policy is enabled, it is sent to pending computers to pause the PXE boot and report back the client computer's architecture to the server.

3. PXE referral cases (including use of Dynamic Host Control Protocol (DHCP) options 66 and 67)

x86-based and x64-based

BIOS

Directing a Client to the Appropriate NBP

There are two methods for directing a client computer to the correct NBP:

Updating the IP Helper Tables

Updating the IP Helper tables means updating the routing tables for your networking equipment to make sure that DHCP traffic is directed correctly. When configured correctly, all DHCP broadcasts from the client computer will be directed to both a valid DHCP server and a valid network boot server. (Note that the requirement is not to rebroadcast the packet onto other network segments, but rather to perform a forward of the packet to only those recipients that are listed in the IP Helper table.)

If the booting client, the DHCP server, and the network boot server are all located on the same network segment, you should not have to configure these tables. The client’s DHCP broadcasts will reach both the DHCP server and the network boot server. However, if either the DHCP server or the network boot server is on a different network segment than the client, or if they are on the same network segment but the network is controlled by a switch or router, we recommend that you update these tables. After the client computer has obtained its IP address, it contacts the network boot server directly (again using DHCP packets) to obtain the name and path of the NBP to be downloaded. The following are the specific changes that you need to make:

  • All DHCP broadcasts by client computers on User Data Protocol (UDP) port 67 should be forwarded directly to both the DHCP server and the Windows Deployment Services PXE server.

  • All traffic on UDP port 4011 from the client computers to the Windows Deployment Services PXE server should be routed appropriately (these requests direct traffic, not broadcasts, to the server).

Using DHCP Options 60, 66, and 67

Although Microsoft does not recommend this method, you can use the following DHCP options to direct PXE clients to an appropriate NBP to download:

  • Option 60 = client identifier (set to the string PXEClient)

  • Option 66 = boot server host name

  • Option 67 = boot file name

For instructions on configuring these options, see the "DHCP" section in How to Manage Your Server. When using these DHCP options, client computers receive an IP address lease, information about the boot server, and information about the NBP directly from the DHCP server. Clients will not contact the network boot server by using DHCP, but they download the NBP through Trivial File Transfer Protocol (TFTP). Microsoft does not recommend this method for the following reasons:

  • Using DHCP options is not as reliable as updating the IP Helper tables. In testing, Microsoft has observed some issues (mainly with older PXE ROM) related to clients incorrectly parsing the DHCP options returned from the DHCP server. The result is that booting clients see a “TFTP Failed” error message. Generally, this problem occurs when the PXE ROM ignores the boot server host name value and instead attempts to download the NBP directly from the DHCP server (which likely does not have the NBP).

  • If there are multiple network boot servers available to service client requests, specifying a specific network boot server may prevent load-balancing.

  • Clients may be directed to a network boot server that is not available. Because the client does not have to contact a network boot server directly to determine the NBP to download, the DHCP server may direct clients to download a NBP that does not exist or to a server that is not currently available.

  • Clients may bypass the network boot server’s answer settings. Many network boot servers have a mechanism that enables you to control which clients (if any) should be answered. Per the PXE standard, client computers should contact the network boot server directly to obtain the path and file name of the NBP. Using DHCP options 66 and 67 can cause the client to bypass this communication with the network boot server and therefore ignore the settings of the network boot server for answering clients.

Note that using DHCP options 66 and 67 is considered a PXE boot referral. Therefore, if you choose this method, ensure that your implementation meets the guidelines defined in Implementing PXE Referrals.

Implementing PXE Referrals

A PXE referral (also known as a network boot referral) occurs when a client is directed to download an NBP from a different server than the one it was in communication with through DHCP (as part of the process to discover the network boot server name and NBP). This referral may be initiated by either a network boot server or a DHCP server.

The following areas are covered in this section:

When to Implement PXE Referrals

You might want to consider using PXE referrals in the following scenarios:

  • To direct a client to download a NBP that is located on a different computer or network location. This may be especially helpful when using DHCP options 66 and 67, because the client is typically answered directly by the DHCP server and is redirected to the network location that contains the NBP.

  • To enable load balancing. It may be advantageous to direct a class of clients to a particular Windows Deployment Services server to limit network traffic to a server.

  • To support complex network and AD DS topologies. Sometimes the networking and AD DS topology do not line up. This could be because incoming PXE requests are answered by a computer over a wide area network (WAN), but you would like a local server to provide the boot image.

  • To remove the need for image replication and duplicate image maintenance. Using referrals can enable you to keep only one copy of an image, therefore maintaining a single release point to update and service. Additionally, using referrals will reduce the amount of overhead it takes to keep multiple images in sync.

Configuring PXE boot referrals involves two steps. First, you must configure the front-end and back-end servers. A front-end server is the server that will answer the client’s PXE boot request and direct the client to the proper server and NBP. A back-end server is the server that the client will download the NBP from. Second, prestage clients and direct them to a back-end server and, optionally, the NBP to download. This second step is required only if you are not using DHCP options 66 and 67 to redirect clients. To configure these settings, see How to Manage Your Server.

Requirements

PXE boot referrals that don't involve using DHCP options 66 and 67 require that the referred client to be prestaged. Additionally, the netbootMachineFilePath attribute of that computer account must be populated with (at a minimum) the server name that the client should use. In environments that contain both Remote Installation Services (RIS) and Windows Deployment Services servers, only the Windows Deployment Services servers should act as referral servers. This enables the Windows Deployment Services server to control the referral process, correctly referring clients to new Windows Deployment Services servers and maintaining backward compatibility for RIS servers.

Note

Having a RIS server act as a referral server for a back-end Windows Deployment Services server will work only if prestaged computers have both the referral server name and the NBP name defined in the netbootMachineFilePath attribute. Failing to populate the NBP name will cause the RIS server to populate the value automatically with Startrom.com (which will not exist on the backend Windows Deployment Services server if the server is in Native mode on Windows Server 2003, or if you are running Windows Server 2008).

Referral Examples

Referrals are classified based on the number of jumps the client must make before it downloads and executes an NBP. The following table contains three examples of referrals. Each of these examples supports the referral of x86-based or x64 BIOS-based clients, but does not support the referral of Itanium-based and x64 EFI-based clients

Example Details

First order referral from PXE server

ComputerA sends a DHCP broadcast packet and receives an IP address lease from a DHCP server and a response from PXE Server1. ComputerA contacts PXE Server1 directly on port 4011. PXE Server1 refers the client to download \boot\wdsnbp.com from Server2. The client computer downloads Wdsnbp.com from Server2.

Requirements:

  • The NBP that the client computer is directed to download from the TFTP server (Server2 in this example) must be Wdsnbp.com.

  • The network boot server performing the referral (PXE Server1 in this example) must be running Windows Deployment Services.

First order referral using DHCP options

ComputerA sends a DHCP broadcast packet and receives an IP address lease from a DHCP server. The lease also contains values for DHCP options 66 and 67, referring the client to download the file \boot\ x86\wdsnbp.com from Server1. The client computer downloads Wdsnbp.com from Server1.

Requirement:

  • The NBP that the client computer is directed to download from the TFTP server (Server1 in this example) must be Wdsnbp.com.

Second order referral using both DHCP options and PXE server

ComputerA sends a DHCP broadcast packet and receives an IP address lease from a DHCP server. The lease also contains values for DHCP options 66 and 67, referring the client to download the file \boot\ x86\wdsnbp.com from PXE Server1. The client computer downloads Wdsnbp.com from PXE Server1. Wdsnbp.com contacts PXE Server1 on port 4011. PXE Server1 refers the client to download the \boot\x86\wdsnbp.com from Server2. The client computer downloads Wdsnbp.com from Server2.

Requirements:

  • The NBP that the client computer is directed to download from the PXE server (PXE Server1 in this example) must be Wdsnbp.com.

  • The NBP that the client computer is directed to download from the TFTP server (Server2 in this example) must be Wdsnbp.com.

  • The network boot server performing the referral (PXE Server1 in this example) must be running Windows Deployment Services.

Enabling Architecture Detection

To work around client architecture reporting problems, you can enable an architecture detection feature on your Windows Deployment Services server. When enabled, the client is sent a NBP (wdsnbp.com) before downloading the normal NBP for the client’s architecture. Wdsnbp.com performs an architecture detection test on the client processor and then reports the value back to the server, using a DHCP packet. After the server receives the information, it sends the correct NBP to the client.

When enabled, architecture detection is performed on every x86-based computer in the environment. This feature is turned off by default because the detection process adds time to boot, increases network traffic, and increases the server's load. You can enable architecture detection by running the command WDSUTIL /Set-Server /ArchitectureDiscovery:Yes.

Avoiding a Boot Loop

When implementing an automated experience of booting from the network, it is often necessary both to set the network as the first device in the client’s BIOS boot order and to send a specific client the .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 from the hard disk drive). To work around this scenario, you should perform the following steps:

  1. Prestage the device (see Prestaging Client Computers).

  2. Set the BIOS boot order on the computer such that the computer always boots from the network.

  3. Set the appropriate .n12 NBP for the computer's architecture (using the Boot tab of the server’s properties).

  4. Turn on the computer, and let it boot from the network.

When you configure the installation in this way, the path to the NBP will be reset after the image is applied, as one of the final actions performed by Windows Deployment Services. This 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 first in the BIOS boot order), but the computer will be sent the .com NBP. After waiting for the user to press the F12 key, this option will time out and the device will boot from the hard disk drive.