You want to PXE Boot? Don't use DHCP Options.
Published Oct 19 2018 04:40 PM 312K Views
Microsoft

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.

 

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

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:

https://sccmcanuck.wordpress.com/2017/03/18/using-dhcp-to-boot-wds-to-bios-uefi-with-sccm/

Copper Contributor

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!

Copper Contributor

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.:grinning_face::smiling_face_with_smiling_eyes:

Copper Contributor

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!

Copper Contributor

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

Copper Contributor

Great write-up on this topic, thanks!

Copper Contributor

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? 

Copper Contributor

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. ^^

Microsoft

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:

https://docs.microsoft.com/en-us/sccm/osd/plan-design/infrastructure-requirements-for-operating-syst...

Copper Contributor

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

Copper Contributor

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.

Brass Contributor

I have a customer, which only specifies DHCP 066 option, and it Works. I have told them, that iphelper is supported solution, not AD DHCP, but there is money involved if iphelpers would be configured and they want cost savings. Nothing we can do right now.

Copper Contributor

Excellent article, that´s why Network Administrators are always my friends.  Sometimes little solutions resolve big problems and are just in front of our nose.  Great day.

Copper Contributor

This post is pure gold. I was looking for the info about PXE vs DHCP boot for Citrix Provisioning Services and there was no clear explanation (most of people call PXE boot as booting from DHCP with options 66 and 67). Thanks a lot!

Copper Contributor

Hi , It works wonderfully

Thanks for sharing

Copper Contributor

Hello, I have WDS and DHCP servers on the same subnet, but on different servers, When I try to PXE boot, it fails with "pxe-e16 no offer received". I captured packets with wireshark and it stucks on DHCP Offer process. client is sending DHCP discover, then there is DHCP Offer, and this 2 steps repeats several times, there is no DHCP request and ACK. We added ip helper that points to WDS server, I'm not using DHCP options 66 and 67. Please any suggestions, Thank You

Microsoft

This really isn't the place for troubleshooting PXE issues. I would recommend posting in the proper forums or opening a case.

Copper Contributor

This is actually bad advice to just add another IP helper address. IP helper address is there for dhcp relay not pxe. pxe should be set in dhcp options. Your basically providing people with a hack, not actually fixing the issue. And cisco's documentation is pretty specific that this is for dhcp relay

Microsoft

PXE is basically a subset of DHCP, so I am not sure that your point is valid. When you use IP Helpers for PXE, you are relaying part of the DHCP request. I am also not sure why you think an IP helper is only for one specific purpose. IP Helpers are a network technology supported by and used by multiple network vendors. It's not a "Cisco" technology. If Cisco's documentation says IP Helpers are for DHCP relay, then that would include PXE since again, PXE is a subset of DHCP.

Ultimately when you use DHCP options, you are splitting the PXE boot process between the DHCP server and the PXE server, which complicates things and introduces additional points of failure. Most of these failures are at the network level outside of Microsoft's control. Why would you do that when you can just allow the PXE server to handle the whole PXE request? Ultimately, a PXE request is a network request, so why wouldn't you handle it at the network level?

What I can say is that we have resolved thousands of customers over the years by having them switch from DHCP options to IP Helpers. Plain and simple, IP Helpers are more reliable, so why wouldn't you use them? There's nothing to "fix" here. Part of the DHCP option issues is the way OEMs implement PXE on the devices themselves, so it's not even a Microsoft problem to fix. You are welcome to go to the OEMs and have them fix the issue on all of their devices, or you can just use IP Helpers and have the problem resolved.

After supporting PXE for 15 years, I can absolutely that this isn't bad advice, and I have never had a single customer ever complain to me after switching from DHCP options to IP Helpers.

Microsoft

Hi
I am a bit new to DHCP. I have a basic doubt. Can DHCP DISCOVERY message be broadcasted by the client even before the Kernel has been booted up. If yes, then is it the job of the NIC to broadcast the message or is some other thing is involved in sending the message.

Thanks

Microsoft

PXE is handled by the hardware, not the OS. In the case of UEFI devices, its handled by the UEFI firmware. In the case of BIOS/MBR devices, its handled by the aNIC card. So the answer to your questions are yes and yes.

Copper Contributor

Dear

My formal environment DHCP is configured on the switch, and the server and client are not on the same network. How do I configure an ip helper。

The network equipment is all Huawei。Are there specific instructions and steps for configuring iphelper。The next error message is displayed when the DHCP server is used to relay port 67:

>>Start PxE over IPu4.
Station Ip address is 10.0.0.1
Server IP address is 10.0.0.2
NBP filename is
NBP filesize is 0 BytesPXE-E23:Client received TFTp error from server.
>>Start PKE over IPu6.

Microsoft

Microsoft doesn't make Huawei equipment so doesn't have the specifics on how to configure IP Helpers on Huawei equipment. For that you need to contact Huawei. Overview of WHAT needs to be configured though is documented here:

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/c...

Copper Contributor

Dear all 
  I ran into an issue where I installed the secondary site through the primary site. However, you cannot boot from PXE in the secondary site. This problem

Version history
Last update:
‎Oct 19 2018 02:02 PM
Updated by: