You want to PXE Boot? Don't use DHCP Options.

[Kerwin Medina]

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.