Troubleshooting PXE boot issues in Configuration Manager

Applies to: Microsoft System Center 2012 R2 Configuration ManagerMicrosoft System Center 2012 Configuration Manager

This article is intended to help administrators diagnose and resolve PXE boot failures in System Center Configuration Manager. If you're a home user and looking for help with problems, ask the Microsoft Community.

In this article:

Before You Start

Before you start troubleshooting on the PXE Service Point, we recommend that you review the following articles to see if the issues discussed could possibly be causing your issue. This isn't an exhaustive list, however it contains some of the most common PXE boot issues.

Verify IP Helpers

If the DHCP server, the client computer, the ConfigMgr server running Windows Deployment Services (WDS) and the PXE-enabled Distribution Point (DP) are all on the same subnet or VLAN, then IP Helpers aren't required.

Otherwise, if either the DHCP server, the client computer, or the ConfigMgr server running WDS and the PXE-enabled DP are on separate subnets or VLANs, which is usually the case in most environments, IP Helpers must be configured on the routers. This process varies and is dependent on the router hardware manufacturer. A general overview is outlined in Configuring Your Router to Forward Broadcasts. If additional information is needed to properly configure IP Helpers on your routers, contact the hardware manufacturer of the router.

IP Helpers are necessary because the PXE request generated by the client computer is a broadcast that doesn't travel outside of the local subnet or VLAN. If the DHCP server and/or the WDS/PXE-enabled DP aren't on the same subnet or VLAN as the client computer, they will not see or hear the PXE request broadcast from the client, thus the servers will not respond to the PXE request. To have the PXE request broadcast traverse between subnets or VLANs, the PXE request broadcast needs to be forwarded by the router to DHCP and WDS/PXE Service Point servers so that they can properly respond to the client’s PXE request.

An alternative to using IP Helpers is setting DHCP options on the DHCP server, specifically DHCP options 60 (PXE Client), 66 (Boot Server Host Name), and 67 (Boot file Name). However, DHCP options can be problematic and may not work reliably or consistently. Furthermore, the use of DHCP options to control PXE requests in ConfigMgr isn't supported by Microsoft. Therefore, the recommended and supported method for PXE booting client computers on remote subnets is by use of IP Helpers.

For additional information about DHCP Options that aren't recommended or supported, see the following articles:

IMPORTANT Before continuing, it's imperative that you verify that the routers have IP Helpers configured AND that the DHCP server does NOT have DHCP Options 60, 66, or 67 configured. Not meeting both of these criteria will cause problems with the PXE Service Point. When you check DHCP options, make sure that you check options at both the server and scope levels.

Note that in certain instances, configuring DHCP options 60, 66, and 67 may make it appear that the PXE boot process is proceeding further along than before these options were configured, however in most cases it is simply proceeding further down an incorrect path.

IMPORTANT The only exception where a DHCP Option needs to be used is when DHCP and WDS reside on the same server. In this instance, only DHCP Option 60 needs to be set. DHCP Options 66 and 67 should still NOT be set in this scenario. This is detailed in Co-hosting DHCP and WDS on the same server.

Special Consideration When Co-Hosting DHCP and WDS on the Same Server

When DHCP and WDS are co-hosted on the same computer, WDS needs a special configuration so that it can listen on a specific port. This configuration is outlined in Windows Deployment Service and Dynamic Host Configuration Protocol (DHCP). Note that according to this article, the following two actions need to be completed when WDS and DHCP are co-hosted on the same server:

  1. The value UseDHCPPorts needs to be set to 0 in the following registry location:
  2. You need to run the following WDS command:
    WDSUTIL /Set-Server /UseDHCPPorts:No /DHCPOption60:Yes

However, a problem with the above recommendations is that in order to run the WDSUTIL command, WDS has to be configured. This goes against the best practice of NOT configuring WDS when installing a ConfigMgr PXE-enabled DP. However, the two settings being specified via the WDSUTIL command (UseDHCPPorts and DHCPOption60) can be configured by using alternate methods that don't require the WDSUTIL command, and therefore don't require that WDS be configured. To configure these settings without having WDS enabled, follow these steps:

  1. The UseDHCPPorts switch for WDSUTIL is actually the equivalent of setting the registry key UseDHCPPorts to a value of 0 in the following location:

    Therefore, using the UseDHCPPorts switch isn't needed as long as the registry key has been manually set. Note that if WDS hasn't been installed, this registry key may not be present.
  2. The DHCPOption60 switch configures an option for the DHCP service, not the WDS service. Therefore, instead of using WDSUTIL to set this DHCP option, an equivalent DHCP command can be used to set the same option. This can be done by using the netsh command as described in Configuring DHCP for Remote Boot Services

    To summarize what’s in the article above, close any DHCP consoles that are open, and then run the following commands in an elevated command prompt:
    netsh dhcp server \\<DHCP_server_machine_name> add optiondef 60 PXEClient String 0 comment=PXE supportnetsh dhcp server \\<DHCP_server_machine_name> set optionvalue 60 STRING PXEClient 
    These two commands set up and enable DHCP Option 60 on a DHCP server. If after running the above two commands an option named Unknown is displayed in the DHCP console instead of 060 PXE Client, reboot the server so that these settings can take effect. After the reboot, the option should display correctly. This usually only occurs if a DHCP console was left open when the two commands were run.


NOTE If DHCP is ever moved to another server and removed from the server hosting WDS, the steps above need to be reversed. To reverse the above steps, complete the following on the WDS server:

  1. Run the following command from an elevated command prompt:
    REG ADD "HKLM\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSPXE" /v UseDHCPPorts /t REG_DWORD /d 1 /f
  2. From an elevated command prompt, run the following two commands:
    netsh dhcp server \\<DHCP_server_machine_name> delete optionvalue 60netsh dhcp server \\<DHCP_server_machine_name> delete optiondef 60 PXEClient
    In the two commands above, the first disables DHCP option 60 and the second removes DHCP option 60 completely.

Troubleshooting DHCP Discovery

There are a number of important points to consider before starting to troubleshoot the initial DHCP discovery stage of the PXE booting process:

  • If you can’t see the MAC address or the DHCPREQUEST of the device you are attempting to boot in SMSPXE.log, then there may be a router configuration issue between the client and the Distribution Point (DP). 
  • Do not use DHCP options 60, 66 and 67, this is not supported
  • Test whether the device can boot when plugged into a switch on the same subnet as the PXE enabled DP. If so, the issue is likely with the router configuration.
  • Make sure that the DHCP (67 and 68), TFTP (69) and BINL (4011) ports are open between the client computer, the DHCP server and the PXE DP.

At this stage of the process, there are no logs to refer to. However, usually when the PXE boot process fails before WinPE has booted, a PXE error code is displayed. Examples of the errors you might see include the following:

  • PXE-E51: No DHCP or proxyDHCP offers were received.
  • PXE-E52: proxyDHCP offers were received. No DHCP offers were received.
  • PXE-E53: No boot filename received.
  • PXE-E55: proxyDHCP service did not reply to request on port 4011.
  • PXE-E77 bad or missing discovery server list.
  • PXE-E78: Could not locate boot server.

There are a number of web pages that document these error codes, for example, Symantec’s list of PXE error codes and their meaning.

This helps narrow down the focus of the troubleshooting, although it may be necessary to capture a network trace of the issue with a network monitoring tool such as Netmon or WireShark. The network monitoring tool needs to be installed on the PXE-enabled DP and a computer connected to a mirrored port on the switch. For more details about configuring mirrored ports, refer to the manual that's provided by the manufacturer of the specific switch or routing device.

The typical procedure is to start the network traces on both the DP and the machine connected to the mirrored port, and then try to boot the device via PXE. Once completed, stop the trace and save it for further analysis. Here is a sample trace of a DHCP conversation captured from the PXE-enabled DP:


You can see that the initial DHCPDISCOVER by the PXE client is followed by a DHCPOFFER from the DHCP server and the PXE DP. The request from the client ( is made and then acknowledged by the DHCP server ( Once the PXE client has an IP address(, it sends a request to the PXE DP ( which acknowledges it with the network boot program details.

Capture a simultaneous network trace on the client and the DP to see if the conversation is occurring as expected.

  • Ensure that the DHCP services are running and available.
  • Verify that the WDS service is running on the DP.
  • Make sure that there are no firewalls blocking the DHCP ports between the server and the client.
  • Verify that the client computer is able to boot when on the same subnet as the DP.
  • Ensure IP Helpers are configured correctly if booting from a different subnet than the DP.

Troubleshooting TFTP Transfer

If the error on PXE boot refers to TFTP, then you may have a problem transferring the boot files. Examples of these errors include the following:

  • PXE-E32: TFTP open timeout.
  • PXE-E35: TFTP read timeout.
  • PXE-E36: Error received from TFTP server.
  • PXE-E3F: TFTP packet size is invalid.
  • PXE-E3B: TFTP Error - File not Found
  • PXE-T04: Access Violation

Monitoring the network by using Netmon or Wireshark is a good way to try and troubleshoot these errors. Here is an example of the data captured from a PXE client when a TFTP Open timeout occurs:


Here the client is sending read requests for the file but isn't receiving a response. This indicates that something is preventing the acknowledgment from being received by the client. Here is what it should look like:


You can try the following troubleshooting steps:

  • Reduce the block size on the PXE enabled DP (see
  • Verify that the WDS service is started on the DP.
  • Ensure that the TFTP port is open between the client computer and the DP.
  • Verify that the permissions on the REMINST share/folder are correct.
  • Check the WDS logs for additional TFTP errors.
  • Verify that the RemoteInstall\SMSBoot\x86 and \x64 folders contain the following files:

  • The fonts exist in SMSBoot\Fonts:

  • The boot.sdi file exists in the RemoteInstall\SMSBoot directory:


WinPE Boot Issues - Drivers

The most common issues that occur during this phase are driver related. On the whole, the latest version of WinPE contains the vast majority of network and mass storage drivers. However, there are occasions where a needed driver isn't included and thus it needs to be imported into the boot WIM. There are a couple of important points to note here regarding this:

  • Only import the drivers you need. Don’t simply import every driver you have into the boot image.
  • Only consider adding NIC or mass storage drivers. It is unnecessary to include other drivers.

The SMSTS.log file (located in X:\Windows\temp\SMSTS) is the most useful resource to troubleshoot these issues (remember to enable the command prompt during boot so you can examine this file). If you do not see a line logged with a valid IP address similar to the one below then you probably have a driver issue:

To verify, simply press F8 and run IPCONFIG at the command prmpt to determine whether the NIC is recognized and if it has an IP address.

WIM Files
Also make sure that both x86 and x64 boot images exist on the DP. You can see the WIMs in the following directory (they will also be in the content library):

Make sure that they have been marked Deploy this boot image from the PXE-enabled distribution point in the properties of the boot image.

Configuration Manager Policy Issues

Another common issue with PXE boot is with Task Sequence deployments. In the following example, the Task Sequence is deployed to an unknown computer but it is already in the database. The first symptom is that the PXE boot is aborted:


Upon further investigation you will notice the following in SMSPXE.log:

We can see here that when the NBS stored procedures ran, they found no available policy and thus the boot action was aborted. The reverse can also be true (i.e. when a machine is unknown but the Task Sequence is deployed to a collection of known machines).

You can try the following troubleshooting steps:

  • Verify that the computer you attempt to boot exists in a collection that is targeted with a Task Sequence deployment.
  • Ensure that you have checked the Enable unknown computer support PXE setting on the DP.
  • If you are deploying the Task Sequence to unknown machines, verify that the computers do not already exist in the database.

Need Further Help?

If you need further help resolving this issue, see our TechNet support forum or contact Microsoft Support.