Share via

How the PXE Server Works

  • Article

Applies To: Windows Server 2008

In This Topic

  • How DHCP Authorization Works

  • How the PXE Server and Providers Interact

  • How TFTP Works in Windows Deployment Services

How DHCP Authorization Works

When a Pre-Boot Execution Environment (PXE) boot is initiated, the PXE ROM requests an IP address from a Dynamic Host Configuration Protocol (DHCP) server, using the normal DHCP discovery process. As part of the initial DHCP discovery request, the client computer identifies itself as being PXE-enabled, which indicates to the PXE server that the client needs to be serviced. After the client has obtained a valid IP address from a DHCP server, the client attempts to locate and establish a connection with the PXE server to download a network boot program (NBP).

By default, the Windows Deployment Services PXE server does not need to be authorized to service client computers. However, you can enable DHCP authorization, which is also known as rogue detection. Authorization checks occur only if authorization checking is enabled and the PXE server is configured to listen on port 67. This means that authorization checks take place only in scenarios in which Windows Deployment Services is running on a computer without DHCP. If Windows Deployment Services and DHCP are running on the same physical computer, this means that the DHCP server is listening on port 67 and is responsible ensuring authorization.

After Windows Deployment Services checks for authorization, a polling mechanism runs every hour to ensure that the authorization status has not changed. You can modify the value for the polling period by using registry settings (see the DHCP Authorization section in the Windows Deployment Services Registry Entries topic). Alternatively, you can restart the PXE server to pick up the change to authorization settings immediately. If the PXE server is deemed to be unauthorized, it will not answer client requests.

How the PXE Server and Providers Interact

The following flowchart outlines how the PXE server and PXE providers interact with one another.

How TFTP Works in Windows Deployment Services

Trivial File Transfer Protocol (TFTP) is the network protocol used for downloading all files during network boots, including the boot image. TFTP is an inherently slow protocol because it requires one ACK (acknowledgment) packet for each block of data that is sent. The server will not send the next block in the sequence until the ACK packet for the previous block is received. As a result, on a slow network, the round-trip time can be very long. However, this is improved in Windows Server 2008 because of TFTP windowing. TFTP windowing enables you to define how many data blocks it takes to fill up a window. The data blocks are sent back to back until the window is filled, and then an ACK packet is sent. The result is fewer ACK packets and much faster download times for the client.

Using the BCDEdit command-line tool, you can change the TFTP block size and the TFTP window size to optimize performance in your environment. For instructions, see How to Modify the BCD Store Using Bcdedit (https://go.microsoft.com/fwlink/?LinkId=115267).

Although configuring the TFTP block size will make TFTP downloads faster, there are two things you need to be aware of:

  • TFTP is implemented in the operating system loader (Bootmgr.exe), but the send and receive functionality with User Data Protocol (UDP) is implemented in the BIOS. The BIOS buffers the network packets that make up the single TFTP block. If you make the TFTP block size too large, the buffer used by the BIOS will fill up and be overwritten, causing the download to fail. The memory buffer behavior is unique to the BIOS manufacturer, and you cannot adjust it by using Bootmgr.exe. Therefore, results may vary greatly based on the make and model of the computer. Unfortunately, there is no way to calculate the block size upper limit for a particular computer, other than trial and error.

  • The configured block size applies to all clients. You can set this value only as high as the block size upper limit that all the clients on the network support. Note that a client cannot fall back to a default block size if the configured block size is too large.