共用方式為

Managing Network Boot Programs

  • 發行項

Applies To: Windows Server 2008

This topic only applies to the initial release of Windows Server 2008.

A network boot program (NBP) is the first file that is downloaded and executed as part of the network boot process and it controls the beginning of the boot experience (for example, whether or not the user must press F12 to initiate a network boot). NBPs are specific to both the architecture and firmware of the client.

In This Topic

  • Configuring the Network Boot Program

  • List of Network Boot Programs

  • Directing a Client to the Appropriate Network Boot Program

    • Configuring Your Router to Forward Broadcasts (recommended)

    • Using DHCP Options 60, 66, and 67

  • Implementing Network Boot Referrals

    • When to Implement Network Boot Referrals

    • Requirements

    • Referral Examples

Note

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

Configuring the Network Boot Program

You specify the default NBP for each architecture on the Boot tab of the server’s properties (right-click the server in the MMC snap-in, and click Properties). You can also override the default NBP 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 prestaged (or known) clients receive the default NBP (most commonly a NBP that requires users to press F12) and unknown clients receive a NBP that will cause them to perform a network boot automatically (without F12). This configuration is particularly useful in a lab environment where you want to deploy images to new computers, but you do not want existing computers to automatically boot to the network.

List of Network Boot Programs

The following table lists the available NBPs.

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 the user to press 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 equivalent of Bootmgr.exe for EFI-based computers. In EFI (Extensible Firmware Interface), 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, this NBP 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 that you can use to direct a client computer to the correct NBP:

  • Configuring Your Router to Forward Broadcasts (recommended). The client contacts the server directly for this information.

  • Using DHCP Options 60, 66, and 67. A DHCP server relays this information to the client.

You can update the routing tables for your networking equipment to make sure that DHCP traffic is directed correctly. For example, you can use the ip helper-address command if you have a Cisco router. When configured correctly, all DHCP broadcasts from the client computer will be directed to a DHCP server and a 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 your router. 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 are 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), Microsoft recommends that you update your router. 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.

  • If the router has a built in firewall, you need to allow traffic through UDP port 4011 (as well as any UDP ports used for TFTP and multicasting as specified on the Network Settings tab of server properties in the Windows Deployment Services MMC snap-in).

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. You should set this to the string PXEClient. Note that this only applies if DHCP is on the same server as Windows Deployment Services.

  • 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. 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 the Implementing Network Boot Referrals section below.

If you configure these options, client computers will 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 will download the NBP through Trivial File Transfer Protocol (TFTP) on UDP port 4011. Microsoft does not recommend this method for the following reasons:

  • Using DHCP options is not as reliable as configuring a router. In testing, clients have incorrectly parsed the DHCP options that were returned from the DHCP server and as a result, the client received a “TFTP Failed” error message. Generally, this problem occurs when the PXE ROM ignores the boot server host name and attempts to download the NBP directly from the DHCP server.

  • If there are multiple Windows Deployment Services servers available to service client requests, specifying a specific server may prevent load-balancing. In contrast, using router forwarding tables you can forward the request to multiple servers.

  • Clients may be directed to a Windows Deployment Services 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.

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. This referral may be initiated by either a Windows Deployment Services server or a DHCP server. The following topics are covered in this section:

  • When to Implement Network Boot Referrals

  • Requirements

  • Referral Examples

When to Implement Network Boot Referrals

You might want to consider a 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 Windows Deployment Services server.

  • To limit 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 network boot requests are answered over a wide area network (WAN), but you want a local server to provide the boot image.

  • To enable you to keep only one copy of an image and therefore reduce the overhead of keeping 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 correct server. A back-end server is the server that the client will download the NBP from. Second, you will need to prestage clients and direct them to a back-end server. 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

  • If you are not using DHCP options 66 and 67, in order to configure a network boot referral, you must prestage the client and you must run WDSUTIL /Set-Device /Device:<name> /ReferralServer:<ServerName> 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 refer clients, and maintain backward compatibility for RIS servers. If a RIS server attempts to refer a client computer to a Windows Deployment Services server, the client computer will receive an incorrect network boot program, which may cause the client to fail to boot.

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. In addition, in each example the NBP on the Windows Deployment Services server must be Wdsnbp.com.

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.

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.

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.