PXE boot both legacy BIOS and UEFI

We’re in the planning stages of a Windows 10 upgrade project at work. At the same time, we’re looking at a desktop hardware refresh across the company. As much as I would love to run thin clients served out of a super-redundant-shiny-cloud-hardened-supercharged-datacenter…the reality is we have too many dependencies to make something like that viable, given our resources in IT. So, we’re pricing out new desktop systems to replace the old ones (one good thing, is desktop systems are getting smaller and smaller).

New desktop systems now come with UEFI instead of the traditional BIOS. We provision and manage our desktop systems using Microsoft SCCM. We also use network boot, namley PXE boot, to kick-off our desktop imaging process.

During our migration to the new desktop hardware, we will have to support in our environment both the old desktops running legacy BIOS and new desktops running UEFI. One of the problems with this is the network bootfiles for UEFI & BIOS are different. So how does the PXE client know which boot file to get?

There are a few ways to accomplish this task. In our environment, PXE clients look to our DHCP servers to direct them where to go. How does DHCP know which bootfile to serve up? The answer is in the DHCPDISCOVER broadcast packet from the PXE client. Let’s take a peek inside, courtesy of Wireshark:

Discover broadcast from a Legacy BIOS PXE client:

Option 93 shows x86 arch and Option 60 Vendor Class shows client arch id

And a discover broadcast packet from a UEFI client:

Option 93 shows EFI arch and Option 60 Vendor Class shows client arch id

As we can see here, we’ve learned the PXE Client identifies itself to the DHCP server during the discovery phase by carrying it’s architecture within the options. Now it’s up to the DHCP server to do something with this information.

When everything was legacy BIOS, there was no need to pay attention to these options. There was a single bootfile served from the SCCM server that all endpoints would receive during PXE boot. Now that we have a requirement to serve 2 different bootfiles, we can use Option 60 to identify the PXE Client architecture. But how does the DHCP server cope with this? By using Policies.

We must first create custom Vendor Classes in the DHCP server (Microsoft DHCP in this example):

right-click the parent IPv4 container under your server name

Now we create 2 custom vendor classes to identify each PXE architecture that we will be expecting (in our case BIOS and EFI as seen in the packets above). For EFI we add in the description field “PXEClient:Arch:00007” and for BIOS define “PXEClient:Arch:00000”.

Add your value in the “Description” field..which is weird but hey it’s microsoft

Now it’s time to create the policies. These will be server policies, so right-click Policies under the top-level server, not the one under Scope:

Give your policy a name and description. For your conditions you need to define Vendor Class equals <display name of your previously defined custom vendor class>.

Under “Options”, this is where we define which boot server and bootfile to use. Here is the SCCM bootfile for EFI:

Create another policy for your BIOS clients and that’s it. Now under your scope options you will see bootfile and servers for each PXE client architecture:

I have not set this up in Linux, however I believe it is possible using dhcpd with client classing and subclasses. Would be a good project to get this working under Linux as well.

I hope some will find this useful.