A network boot program (NBP) is the first file that is downloaded and executed as part of the network boot process. 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
Configuring the Network Boot Program
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 network 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 Network Boot Programs
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 network boot to continue.
|
x86-based and x64-based
|
BIOS
|
|
PXEboot.n12
|
Does not require pressing F12 and immediately begins a network 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 network 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 network boot and report back the client computer's architecture to the server.
3. Network boot 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 Network Boot Program
There are two methods for directing a client computer to the correct NBP:
Configuring Your Router to Forward Broadcasts (recommended)
You can update 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 Windows Deployment Services server. (Note that the requirement is not to rebroadcast the packet onto other network segments, but rather to forward the packet to only the specified recipients.)
If the booting client, the DHCP server, and the Windows Deployment Services 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 Windows Deployment Services server. However, if either the DHCP server or the Windows Deployment Services 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 Windows Deployment Services 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 server.
- All traffic on UDP port 4011 from the client computers to the Windows Deployment Services 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 Windows Deployment Services 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 configuring a router. 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 Windows Deployment Services servers available to service client requests, specifying a specific 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 Windows Deployment Services 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 Windows Deployment Services server’s answer settings. Many Windows Deployment Services 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 Windows Deployment Services 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 Windows Deployment Services server and therefore ignore the settings of the Windows Deployment Services server for answering clients.
Note that using DHCP options 66 and 67 is considered a Network boot referral. Therefore, if you choose this method, ensure that your implementation meets the guidelines defined in Implementing Network boot Referrals.
Implementing Network Boot Referrals
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 Windows Deployment Services server name and NBP). This referral may be initiated by either a Windows Deployment Services server or a DHCP server.
The following areas are covered in this section:
When to Implement Network Boot Referrals
You might want to consider using Network boot 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 Network 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 Network 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
Network boot referrals that do not involve using DHCP options 66 and 67 require that the referred client to be prestaged. Additionally, you must run WDSUTIL /Set-Device /Device:<name> /ReferralServer:<ServerName> for the client to specify the server 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.
.gif) Note |
| Having a RIS server act as a referral server for a back-end Windows Deployment Services server will work only if prestaged computers has a referral server (which you set by running WDSUTIL /Set-Device /Device:<name> /ReferralServer:<ServerName>) and a NBP (which you set by running WDSUTIL /Set-Device /Device:<name> /BootProgram:<path>, where <path> is the relative path to the boot program you want from the RemoteInstall folder). If the client does not have a set NBP, the RIS server will use the Startrom.com NBP (which will not exist on the backend Windows Deployment Services server if the server is in Native mode on Windows Server 2003 or is 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 a Windows Deployment Services server
|
ComputerA sends a DHCP broadcast packet and receives an IP address lease from a DHCP server and a response from WDSServer1. ComputerA contacts WDSServer1 directly on port 4011. WDSServer1 refers ComputerA to download \boot\wdsnbp.com from WDSServer2. ComputerA downloads Wdsnbp.com from Server2.
Requirements:
- The NBP from WDSServer2 must be Wdsnbp.com.
|
|
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 WDSServer1. The client computer downloads Wdsnbp.com from WDSServer1.
Requirement:
- The NBP from WDSServer1 must be Wdsnbp.com.
|
|
Second order referral using both DHCP options and Windows Deployment Services
|
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 ComputerA to download the file \boot\ x86\wdsnbp.com from WDSServer1. ComputerA downloads Wdsnbp.com from WDSServer1. Wdsnbp.com contacts WDSServer1 on port 4011. WDSServer1 refers ComputerA to download the \boot\x86\wdsnbp.com from WDSServer2. ComputerA downloads Wdsnbp.com from WDSServer2.
Requirements:
- The NBP from WDSServer1 must be Wdsnbp.com.
- The NBP from WDSServer2 must be Wdsnbp.com.
|
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:
- Prestage the device (see Prestaging Client Computers).
- Set the BIOS boot order on the computer such that the computer always boots from the network.
- Set the appropriate .n12 NBP for the computer's architecture (using the Boot tab of the server’s properties).
- 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.