PXE Boot Basics.


Booting from the network using the PXE protocol involves a simple series of DHCP packets. There are three parties involved: the DHCP server, the PXE server, and the client.

  1. The client broadcasts a DHCP packet asking for the address of DHCP servers (servers that can hand out IP addresses). In the same packet, the client also specifies that it is looking for PXE (network boot) servers. This is known as a 'discover' - the client wants to discover where the servers are.
  2. The DHCP server responds with a broadcast packet (which simply tells the client that it is an address server). This is known as an 'offer' - the server is offering its services.
  3. The PXE server responds (which tells the client that it is a boot server). This is also known as an 'offer.'
  4. The client sends the DHCP server a message asking for an IP address.
  5. The DHCP server sends the client an IP address that is now assigned to it.
  6. The clients sends the PXE server a request asking for the path to the Network Boot Program (NBP).
  7. The PXE server responds with the NBP path.
  8. The client downloads the NBP and runs it.

At this point, the basic PXE boot is done. There will be additional interaction between the client and the PXE server, but that is decided by the implementation of the NBP. In the case of the WDS NBP implementation, it will ask for the path of a custom boot file (pxeboot.com or bootmgfw.efi), it will download that and run it. That custom boot file will then download the boot WIM and other files needed by Windows PE.


The Problem and the Simple Solution.


Those eight steps mentioned above normally works as long as the broadcast from the client can get to the servers. That should not be a problem when the client and the servers are on the same network. But what if the client and servers are on different networks? How will the client get an IP address from the DHCP server?


The answer is in the configuration of the routers. They need to be able to route the client requests from the network of the client to the network of the DHCP server. One such simple router rule is the "ip helper." This simply tells the router to forward the DHCP requests to the known IP address of the DHP server.


But what about the PXE requests? Simple - configure the routers to forward the client request to the PXE server - just like you do with the DHCP server. There is no other skill to learn. It is the same thing that you already know how to do and that you have already done. This time, you just need to do it for another server, the PXE server.


Go to your router, find the DHCP IP helper entry, add another one that looks exactly like that but use the IP address of the PXE server.


The Hack. The Headache. DHCP Options.


Even though there is a very, very simple solution, you will see administrators using an alternative route. This involves configuring the DHCP server to respond to the PXE requests. The rational is that the client request will always get to the DHCP server (otherwise, clients will never get IP addresses), so, let the DHCP server masquerade as a PXE server. The DHCP server will respond to the client and tell it that it is a PXE server ('PXEClient' on Option 60). It will also respond to the client with path to the network boot program (Option 67).


Pants On Fire.


The DHCP server can fool most client firmware in this manner, but not all. Some firmware are too trusting. When it is time to download the boot files, it will try to download them from the DHCP server. After all, the DHCP server did say that IT IS the PXE server. This will of course fail - the DHCP server does not have any boot files.


You can't make your DHCP server lie and expect good things to come out of it.


Static. Static. Static.


The granddaddy of the problem - whatever you put in the DHCP option (especially option 67, the boot program path), that is it.


What if you have different types of machines that want to PXE boot? BIOS, UEFI, 32-bit, 64-bit, ARM.


You see, there are different network boot programs depending on the client architecture and firmware mode. Many admins find this out the hard way. BIOS clients work (because they specified wdsnbp.com), but UEFI clients fail (because wdsmgfw.efi is needed).


Not only are the file names different, the folders are also different depending on the PXE server. For example, in WDS, the folder is 'Boot.' In SCCM/WDS, the folder is 'SMSBoot.' In the WDS-less SCCM, the folder is 'SMSBoot\{package-ID}.' In Linux, it can be anything.


You could program your DHCP server. Add logic there to detect the client architecture and firmware. It is not trivial work, and it does not make sense. The PXE server type is also something that the DHCP will not be able to programmatically determine. There is very little that you can accomplish here.


Why go this route, considering that adding an IP helper is a one-line command on a router?


There Can Only Be One.


Oh be one.


What if you have multiple PXE servers? Using multiple PXE server is a common practice for load-balancing. In a diverse environment, it is also common to find Windows, Linux and Router PXE servers all co-existing.


How do you fake all of these with a single DHCP server response? Such a method completely breaks down here.


In the IP helper world, you simply add an IP helper entry for each PXE server. You can add as many as you need or as many as you want. Yes boss. For the load-balancing case, PXE servers can be up or down in a group, and you don't have to do any additional configuration. For the diverse environment case, the different PXE servers can selectively choose to respond to the clients that they recognize.


To Boot Or Not To Boot.


When you add PXE options to the DHCP replies, this results in the client 'always' booting. The client will always download the network boot file (specified in the DHCP reply) and run it.


This is problematic in some UEFI settings because the client may never attempt to boot from the hard drive once it has been instructed to start a network boot and the network boot fails (e.g., there is not task sequence deployment for the client). This is also problematic for mixed-OS environments. Your Linux machine would be instructed by the DHCP server to download and run the Windows network boot program.


In the IP helper world, the true PXE server decides whether or not it will respond and serve a network boot file. In the Configuration Manager case, it will only respond if there is a task sequence deployed to the client.


It's A Small World (After All).


Befriend your network administrators. Be nice to them, out of a genuine heart.


Your network administrator just needs to add that one single line of 'IP helper' router configuration that points to your PXE server. It is next to the configuration line that points to the DHCP server.


Do It Right, The First Time.


If something is anyway worth doing, one might as well do it right. Your loved ones will thank you for being home early on weekdays and for being home on weekends. The administrators who will take over the work after you will also thank you. Lastly, I will thank you - I don't have to keep seeing and answering the same PXE issue on Configuration Manager forums. So, thank you, in advance.


Occasional Contributor
Thanks Kerwin. Now you, me, and every other ConfigMgr admin can simply point to this blog post.

IP helpers work perfectly unless you have some cheap and/or old hardware router in place that cannot do IP helping. :)

In this case playing with DHCP policies and custom vendor classes might be the only option: at least for affected subnet. 


Therefore I would add this link or similar to the post:


Frequent Visitor

This seems to be extremely useful information. Why not include it in the official documentation??

I laughed. I cried. But tears of joy. We who are support engineers salute you!

Occasional Visitor

I work in a Fortune 300 company where I had to explain a lot about IP helper address. It was 3 years back. Within my team, members were insisting DHCP scope options for PXE and I was trying to explain how beneficial is IP helper address. Who won the battle ? Me...


Thanks for reminding those who still wants to stick with DHCP scope options.😀😊

Senior Member

This makes so much sense, are you implying a single PXE server? In a multi national organisation across three regions we could consolidate down from 60 PXE servers to 3!

Occasional Visitor

When you use ip helpers do you remove all three scopes or just 66 and 67?

Occasional Visitor

Great write-up on this topic, thanks!

Senior Member

Is this also the case if the DHCP server at a site is also the WDS server? With both roles on the same machine we need to use the options in DHCP to get it to work. Is this expected or should it work without? 


Wow thanks for that one!


I was tinkering around today with the pxe boot on different subnets.  I've read it isn't recommended to use the DHCP scope options and so I didn't do...

I used the ip-helper address, but didn't know that I needed another one for the PXE-Server. ^^


If DHCP and WDS are on the same server (not the same subnet), then you need to leave DHCP Option 60 configured. Otherwise you should remove all three DHCP Options 60/66/67. See the following docs:


Occasional Visitor

Thanks a lot Kerwin, you explained like if it was a proper windows Doc 

Occasional Visitor

I am the "Network Administrator" for our university.  You know; the one to be nice to. :-)


On our WIN 2016 DHCP servers we spun up policies to ID the Boot type: Legacy x86 and x64, UEFI x64, and UEFI x86 so that options 66 and 67 would change depending on how the host is equipped and configured.  Our SCCM Admin is currently seeing those same issues that Mr. Medina stated: "always booting".  With Legacy if there isn't job to process it move on and complete the boot process.  However, he reports that the UEFI systems sit and wait for additional manual information which doesn't arrive as no one is driving the keyboard.


I appreciate this thread.  We are going to make adjustments to our test network.  If successful, I will add and update.  Who knows, maybe even if we fail.


Take care.