How does the PXE boot process work?

Published 10-07-2019 04:01 PM 65.5K Views

Within the IT department imaging devices for end users is something that we’ve probably all had to do at some point, either manually or with an automation product such as Windows Deployment Services (WDS), Microsoft Deployment Toolkit (MDT) or System Centre Configuration Manager (SCCM). 


There are a lot of moving parts to imaging devices using one of the tools mentioned above, and there can be a lot of pain points in the process.  When you are trying to image a device you are usually trying to interact with it before the pre-installed Operating System (OS) launches or interact it when it doesn’t have an OS installed on it.  And to do that we want to interact with the Preboot Execution Environment or PXE as its commonly referred to. And this is often the part that can cause a lot of pain.


The PXE environment in its simplest form is the process of having your device boot from its network card.  For the device to boot into the PXE environment it needs to receive the relevant instructions.  The most common way of trying to do this is to configure your Dynamic Host Configuration (DHCP) server to store and serve this information.


PXE Boot Process


Using your DHCP server to store and serve this information looks like this:


  • The device sends out a DHCP broadcast and states that it needs to PXE boot (you’ve often initiated this request by hitting F12 on the device as it starts up)
  • The DHCP server picks up this broadcast and replies with a suggested IP address to use. If the server has the information on how to PXE boot, that information is included in its reply
  • The device then replies to the server and uses the provided address
  • Then the device contacts the PXE boot server (traditional a WDS server or SCCM server) and requests the boot file (also known as the Network Boot Program (NBP)) that it was told to look for from the DHCP server
  • The file is then loaded and launched on the client


Within your DHCP server, Option 66 or Option 67 are the ones that you set within your scope options with the required information. Option 66 specifies which server to contact and 67 is the name of the file to request. This method can work fine when your clients are on the same part of your network as your servers and if you are only utilising one type of device architecture.


However, when your devices are on another part of the network from your servers, or you have a mix of BIOS, UEFI, 32-bit, 64-bit, ARM devices, it all gets a bit messy.


Especially as each of those device types need a different boot file delivered to them and DHCP only allows you to specify one boot file.   Over the years I’ve learnt the hard way that each device needs a specific boot file and I know colleagues that have also fallen foul to this issue as well.  


IP Helpers


The ultimate answer and supported method is to use IP helpers.  These are options that are specified within your networking equipment.  Using IP helpers tells your device where to go for the boot file then your PXE/WDS/SCCM server dynamically delivers the correct boot file for the device architecture/firmware.  Utilising the IP helper method also allows you to specify more than one server so you can build multiple within your environment, then if one is offline the device should just use the next available one rather than fail, so you have a loose “load balanced/redundancy” solution in place.


Network Administrator

My advice, if you are someone who is involved in building devices for your end users, is befriend your network administrator and ask them to configure the necessary IP helpers for you. 


A little solution like this can save you a lot of time.


Happy device building!



Without a doubt this is the best approach to getting a complete environment to support all your pxe needs.  Having done imaging myself, befriending your network admin IMHO is essential - there are many factors that the impact proper deliver (or blocking where req) or pxe packets, your design needs to take delivery (network eq, server versions) and configuration (uefi/bios) options as well as security.  Once all factors are understood a proper an effect design is possible 


I am having this issue but am not sure why as I have a small network, DC is handing DHCP, DHCP is configured to point to WDS server (and NBP file). everything is current and 64-bit. Machine is set to PXE boot but fails. I know nothing about IP Helpers or even where to begin there so I'd rather not get into it as I am under a time constraint. Any ideas? Thanks!!


@stogiefan sorry to hear you are having issues.  Without an error message or more information it will be really hard to offer any advice. Have you got an error message or any log files that might help at all?


No sorry, I can get a VM to boot right to it but a real machine will not, it just sits at the PXE boot screen. Like it's probably hitting the server but not the boot file. Thanks anyway!

Frequent Visitor

How can I find out which files or Services to Whitelist for PXE and WDS ? (getting blocked from FireEye)


There are lots of sites with the requirements, is an old one, you also need dhcp relay which is UDP 4011.  Also how your configure it for UEFI or BIOS also makes a difference - not at the network level, but its something that is easily confused as 'PXE Not answering or being blocked'


@dt070202 Are you looking for file name and extensions to whitelist?

Frequent Visitor

@Techielass Yes .. Not sure how to gather all of that information.,  


@dt070202 If you go to the "Download the boot files" section of this article - you will find some more information.  Hopefully this will help.   


I've never used FireEye before but if it's blocking things does the log files not sure explicitly what it is blocking? 

Frequent Visitor

@Techielass Yes this is exactly what I was looking for !! Thank You ... 

Version history
Last update:
‎Oct 08 2019 03:28 AM
Updated by: