This guide covers common causes of why PXE boot sometimes fails by examining client misconfigurations, network settings, and SCCM distribution point requirements.

Joseph Moody

Joseph Moody is a network admin for a public school system and helps manage 5,500 PCs. He is a Microsoft Most Valuable Professional (MVP) in Cloud and Datacenter Management and blogs at

For something that seems so simple, booting PXE devices to an SCCM 2012 server can be quite complicated! In this guide, we are going to cover the many different reasons that a PXE boot can fail and how you can fix these failures.

Before we start, you should open the SMSPXE log on your distribution point. This log shows any clients trying to network boot, and you can use the log as a starting point. If you see your client listed, you can probably ignore client configuration issues. If your client isn’t listed, start with client settings first.

Client settings required for PXE boot ^

Any device attempting to network boot will have to support PXE. With some older hardware and certain models (Dell, for example), you will have to make sure the following two items are in place:

  • The network card must be enabled as a bootable device.
  • The network card must have PXE support enabled. This setting is normally found in On-board Devices within the BIOS.

While you are checking these two settings, ensure that the computer has enough RAM to load Windows PE. In Windows PE 5.1, the minimum required is 512MB. Additional RAM is required as drivers and tools are added to your Windows PE image. To be safe, we required 1GB in our environment.

Although not directly related to PXE issues, ensure that the date and time in the BIOS are very close to the actual time. If not, Windows PE will load and immediately reboot. The SMBIOS GUID may be duplicated with another machine on your network. While the machine may PXE boot, it will fail to load a task sequence. Finally, ensure that devices connected to the network cable have an active link.

DHCP or IP helper for PXE across subnets ^

After you verify your hardware settings, you can move on to the next troubleshooting layer: networking. Start by network booting a machine in the same subnet and, preferably, the same switch as your distribution point. If this works, your issue lies in the PXE broadcast and the inability for clients to locate the distribution point across subnets.

When possible, avoid using DHCP options to connect clients to a distribution point. The trouble with setting DHCP options 66 and 67 is that they increase troubleshooting complexity. For example, clients may report “PXE-E53: No boot filename received” when attempting a network boot. A client will appear to successfully PXE boot but will actually be taking a slightly longer route to failure.

The current best practice for network boots across subnets is to use IP helper addresses configured at the top network device of each subnet. For example, you would start by connecting to your core switch (or the top switch at that subnet or VLAN). For an HP switch, you would use the following commands:

If this switch had multiple VLANs configured, you would need to set the IP helper-address in each VLAN that you plan on network booting. The commands listed above (and shown in the screenshot below) are pretty universal to other switch models.

If your DHCP server is already listed as a helper address, just add your distribution point’s address after it. Each server will still respond to the appropriate requests.

Adding the IP address of the distribution point to VLAN 1.

Adding the IP address of the distribution point to VLAN 1

You should look at a few other things on this level. If you receive the error message “PXE-E51 No DHCP or proxy DHCP offers were received,” check your DHCP server. Ensure that addresses are available for lease and that the DHCP server is handing out addresses. If your DHCP server is virtual, ensure that the host is not blocking requests from getting to the DHCP server.

The DHCP guard setting in Hyper-V can cause PXE boot failures.

The DHCP guard setting in Hyper-V can cause PXE boot failures.

If you receive an error message such as PXE-E55, ensure that UDP port 4011 is open to your distribution point and is not blocked on devices between your client and server.

Is SCCM is configured for PXE support? ^

These last troubleshooting steps take place on your distribution point. The distribution point, your task sequence, and your boot media must be configured to allow PXE booting. These portions assume that the Windows Deployment Services Server service is started and running.

On the Configuration Manager console, navigate to Administration – Site Configuration – Servers and Site System Roles. Right-click the distribution point and select its properties. On the PXE tab, make sure that the Enable PXE support for clients check box is selected, along with the two check boxes that follow it.

Enabling PXE support on a distribution point.

Enabling PXE support on a distribution point

Next, check the deployment settings of your task sequence. The Make available to the following setting should include PXE.

This task sequence is only available to clients that boot off of media or PXE.

This task sequence is only available to clients that boot off of media or PXE.

Finally, open the properties of the boot image that your task sequence uses. On the Data Source tab, ensure that the Deploy this boot image from a PXE-enabled distribution point check box is selected. If not, select it; then, select the Content Locations tab and redistribute your boot image.

This boot image is PXE-enabled from the distribution point.

This boot image is PXE-enabled from the distribution point.

As you can see, troubleshooting PXE boot issues can be quite difficult. Many areas exist where the process can break down and cause problems. In this guide, we covered the major issues that I’ve encountered over the years. What PXE-related issues have you faced?

Win the monthly 4sysops member prize for IT pros


Related Posts

  1. Jose 2 years ago


    I am running server 2012R2 and SCCM 2012 R2. I was troubleshooting the task sequence issue(that could have been easily fixed by time sync) and I believe I made a change and can not resolve or figure out the fix. I may have inadvertantly selected HTTPS for the distribution point and now it will not PXE boot correctly. I did however try loading the images directly to the WDS server and was able to get it to boot but can not get it to communicated through SCCM as it should.


  2. Ata 1 year ago

    You saved my life Joseph, thank you very much...


  3. Author
    Joseph Moody 1 year ago

    Anytime Ata!


  4. Shyam 1 year ago

    Hi Joseph,

    I am having trouble with PXE boot  with UEFI based machines

    we are using Symantec Ghost solution suite for all our deployment tasks

    the legacy pxe is working fine its just with UEFI causing problem

    we have options set for 66 and 67 on DHCP

    ghost server IP

    DHCP server IP

    Client IP

    Under DHCP 66 option set to which is ghost server

    Under DHCP 67 option set to BStrap\X86pc\bstrap.0( which works for leagacy)

    if i remove this the legacy pxe is also not working

    If i change option 67 to BStrap\X86pc\bstrap.efi (the UEFI pxe doesnt work)

    the client is not getting the TFTP file to load from the ghost

    The only solution symantec has provided is to use ip-helper

    we have our core switch has HP pro curve

    the other switches on different buildings are cisco switches connecting to main core switch

    My question is do i have to configure ip-helper on each cisco switch and core switch(HP)

    or just configure ip helper on core switch only
    Config terminal
    Vlan 1
    IP helper-address <IPADDRESS_OF_DISTRIBUTIONPOINT>( ip address of ghost or DHCP)



  5. Author
    Joseph Moody 1 year ago

    You would configure ip helper on the top switch/router of the VLAN.

    when a device is pxe booting, it sends out a broadcast. Your router won't let broadcast go from one broadcast domain (vlan) to another one. If the pxe server isn't in the same vlan as the client, the broadcast is never forwarded to it.


  6. Dilip 1 year ago

    I have 8 DPs in different locations in two different domains with two different DHCP Servers.How should I go about it.



  7. sid 1 year ago

    Hello ,

    I have a issue in imaging after change in a subnet of machines where machine used to be imaged .
    All machines are failing at step looking for policy.

    SCCM 2012 R2 SP1 CU4
    Any help would be appreciated !!!


  8. Author
    Joseph Moody 1 year ago

    If you right click on the machine account in SCCM, do you see a deployment being sent to it? If not - can you provide some more details on how you are deploying your OS? Mandatory assignments? Unknown or known computers?


  9. Garrett 1 year ago


    I'm trying to create a build and capture task sequence. When I PXE boot the client that I intend to capture, I get this error:

    PXE-E32: TFTP open timeout

    When I look at SMSPXE.log, it doesn't show anything indicating that a client is attempting to contact the deployment server.

    Here's the interesting part! On the distribution point properties, the PXE tab is configured exactly like you're showing (except for a password requirement), but if I open up Server Manager, it does not show that the WDS role is installed. It's been my understanding that WDS is installed automatically when you enable PXE support. I can install the WDS role manually from server manager, but I'm afraid that since it wasn't installed automatically, that something else may be wrong. Some detail, I did uninstall and reinstall WSUS, so maybe I got rid of WDS at the same time? Instead of reinstalling it manually, would it be better to disable and re-enable PXE? Uninstall and reinstall the DP? This site isn't in production yet so my options are pretty much open.

    Thanks for your posts!




  10. Tony Bailey 1 year ago

    Hi Garett,


    You need to install the WDS role with default config, then when you add the role through SCCM it will configure it.





  11. Deepak Sengupta 11 months ago


    I am in process of setting up a pxe environment for Windows 7 SP1 x64 machines in my company. Wanted to know can I only use IP Helper to connect client to Distribution points, without using any options in DHCP ? My environment is running on SCCM 2012 R2 SP1 integrated with MDT.

    Thanks a lot for your time.


  12. Author
    Joseph Moody 11 months ago

    Yes - it is a best practice to only use an ip helper statement.


  13. Trey 7 months ago

    I'm using latest and greatest SCCM 1702...DPs are 2012 R2 legacy BIOS PXE Boot is working great.  No DHCP Options are set.  Trying to use UEFI to image Windows 10 and provision the newest TPM 2.0 bitlocker chips are killing me.  I get the IPV4 PXE Boot... screen up and it waits a minute and blows by it.  It's messing me up.  The only thing I can see is that we do set DHCP options for TFTP option 150 for some cisco images, but I haven't seen or heard anything that would cause that to interfere with UEFI PXE Booting...running out of ideas.  Only using x64 boot images even though it never gets that far, its like it never finds the DP when going through UEFI.  Any thoughts or ideas would help me out.


  14. Trey 7 months ago

    Holy crap...i figured it out after days working on this.  I can't believe this fixed it... Under the DP Properties and PXE tab I set the "Specify the PXE server response delay (seconds): from 5 to 0 and it started working....sigh...wth....


  15. Author
    Joseph Moody 6 months ago

    @Trey - for future reference, you can also specify a 5 second delay for the boot image prestart command.


  16. Chris Bolton 5 months ago

    I have a SCCM 1702 system setup and I am working to get PXE booting working as well. I have gotten to the point where I get PXE-E32: TFTP Timeout. Originally I had an issue with missing filename but we changed DHCP option 67 to SMSBOOT\x86\ . This fixed the file missing issue but the timeout persists. I checked all of the different locations in SCCM to make sure that my DP/MP is set for PXE boot, the task sequence and deployment are set correctly. WDS is running on the DP/MP and I see that reflected in the SMSPXE.log when I restart the WDS service in the Services.

    The test PCs show that they are getting IP addresses via DHCP thought I do not ever see the MAC address of the test physical computers show up in the SMSPXE.log. I know for a fact that the PCs I am using to test have their  correct MAC addresses added to the OSD Build collection to which the task sequence is deployed. Oh and the Windows firewall is completely off on the DP/MP and port 69 is listening on all interfaces. I am not sure what else I can check to figure out why PXE booting isn't working.

    Do you have any further suggestions for checking?




  17. Chris Bolton 5 months ago

    I found my issue after a ton of searching. This thread ( had the answer. I was getting a TFTP error 1460 which is a timeout and it turns out that a limitation in the block size for files being transferred via TFTP was what caused my issue. This seems like the kind of thing that others would run into so I will post the actual change.

    On the PXE Boot DP/MP you need to make a change to the following registry key and then restart the Windows Deployment Service in the Services MMC snap in.

    Name: MaximumBlockSize
    Type: (REG_DWORD)
    Value range: 512–1456
    Base: (Decimal)

    I have experimented with 512 and 1024 block sizes and they both seem to work however my guess is that 1024 will produce faster results when imaging. I am pulling my first image for Windows 10 using PXE Boot but unfortunately I don't have a local DP setup to handle the files so the whole process is being strung out through my WAN. I hope to get a test DP in my location later today so that further testing can move along much faster.


  18. Sedate 4 months ago

    Im having a similar issue with 1702 with the hotfix applied for the Unknown computer bug.

    I have imaged and captured fine using MDT, imported the image into SCCM and setup multiple task sequences within SCCM all set to the unknown client collection. PXE boot configured all correctly but am finding that on PXE boot all that happens is that it PXE boots to the LiteTouch wim file and all I see are the MDT Task Sequences (ones that I used to capture) rather then the SCCM Task Sequences. If I disable PXE on the DP, reboot the SCCM server and then go back to the DP and enable PXE on it, I can PXE boot happily and see all the SCCM task sequences. However I can only do this for one workstation - try pxe booting another station and it goes back to the MDT task sequences. Any pointers would be great. Cheers


  19. Jeff 3 months ago

    SO here is my delima, hope someone can help.

    i have an sccm server we use for imaging, it has been working great for over a year, and still is, to a point.

    Our server is housed in a the high school on vlan 100, ip address

    the high school has many other subnets in it, .... etc etc

    i can image across all these subnets just fine

    now we move into our remote schools, they are connected via 1GB light fiber

    we until recently had a comcast metro-ethernet multi point network connecting our schools, and SCCM worked fine across it

    we just switched to another provider for WAN connectivity and here is where the issues lies...

    it is set up exactly the same as the comcast link, just a different WAN ip space (as i had to run them in tandem for a bit)

    now i pxe boot, it connects to the sccm server, it loads a small segment of the pre-boot environment, then times out

    if i fail back to comcast it works fine, my new vendor says it is simply a l2 extension, and there is no traffic QOS/blocking/etc  set up

    i know my pxe boot settings/dhcp options etc are correct, as it works fine in house at the high school AND at remote schools using the old WAN circuit

    it is just remote schools with the NEW wan circuit that seems to be the issue.



    Users who have LIKED this comment:

    • avatar
  20. Author
    Joseph Moody 3 months ago

    I haven't faced this before and I run a very similar environment. You may consider lowering the SCCM PXE TFTP block size value. This is a registry edit and does require a restart of the WDS service.

    If that doesn't work, you could put a distribution point at those remote sites. This would also help out when you have updates/applications being deployed.


Leave a reply

Your email address will not be published. Required fields are marked *



Please ask IT administration questions in the forum. Any other messages are welcome.

© 4sysops 2006 - 2017

Log in with your credentials


Forgot your details?

Create Account