Using DHCP to Control

UEFI & BIOS PXE

Version 1.0

2Pint Software
Or how to call a bug non supported feature and ignore it hrmpf.
3/16/15
 2Pint
S o f t w a r e
1

Contents
Overview ......................................................................................................................................................... 2
Whats required? ........................................................................................................................................ 2
Whats the Outcome .................................................................................................................................. 2
First things first - The Basics! ....................................................................................................................... 3
So why does it work with IP Helpers? .......................................................................................................... 3
Giving the right boot file - DHCP Style ......................................................................................................... 6
Enter Policy Rules ...................................................................................................................................... 6
DHCP Policy Rules is Server 2012 or above ................................................................................................ 7
Setting Up DHCP for EFI & BIOS Boots ........................................................................................................ 8
Creating Required Vendor Classes ........................................................................................................... 8
Creating New Policy Objects....................................................................................................................... 10
Adding Conditions ................................................................................................................................... 11
Defining Settings For The Rule ............................................................................................................... 14
The Summary Page ................................................................................................................................. 16
Done! ............................................................................................................................................................. 18
End Comment ............................................................................................................................................... 18

USING DHCP TO CONTROL UEFI & BIOS PXE 2PINT SOFTWARE

 2Pint
S o f t w a r e
2

Overview
This guide will help you to define DHCP options to boot of UEFI machines as well as BIOS computer
from the same WDS server, using DHCP options. Bypassing the need & requirement for IP Helpers on
the routers. Official word from Microsoft is, its not supported: But hey, it works!

This guide was created during the development work of the upcoming 2Pint Software product iPXE
Anywhere. One of the key design goals was to make sure that you could boot from WDS using DHCP
options. So we didnt take the not supported answer as a valid one and went through great pain to
try to figure out what was going on.

Whats required?
This guides go through creating DHCP scopes to boot of a WDS server. All Server version that have
been tested with is Server 2012 R2, although it should work with Server 2012 as well. So it requires:

Microsoft DHCP Server running on at least Server 2012 with some DHCP scopes set up
Windows Deployment Services running on a separate machine to the DHCP server
At least one router in between clients PXE booting and the servers, blocking
DHCP/Broadcast traffic
A BIOS client computer (can be virtual, all Hyper-V Gen1 is BIOS)
A x64 EFI client computer (can be virtual, Hyper-V Gen2 is EFI)
ConfigMgr 2012 R2 with a PXE Service Point integration set up with WDS (Optional)

This guides focuses heavily on using ConfigMgr 2012 R2 with the PXE Service Point integration with
WDS. Read more about that here: iPXE Anywhere

If you are not using ConfigMgr, you can still use this guide to help you configure WDS on its own, just
change the names of the boot loaders to the WDS ones, listed as well.

Whats the Outcome

The outcome of the guide is that you will be able to boot computers using DHCP options, with the
same process and outcome as using IP Helpers.

Client boots -> DHCP server replies -> Client contacts PXE server -> Network Loader talks to
WDS/PSP to get right boot action -> Boot WinPE (Typically).

USING DHCP TO CONTROL UEFI & BIOS PXE 2PINT SOFTWARE

 2Pint
S o f t w a r e
3

First things first - The Basics!

PXE is a software standard, which makes room for developers to interpret things slightly different.
There are also rooms for bugs and issues in the code that follows the standard, so dont expect
things to always work flawlessly.

1. If you are having issues, try to get the latest BIOS/Firmware for computer. For on board NICs
(LOM is the term us PXE nerds use which means LAN-On-Motherboard) this is typically a
BIOS update as the PXE ROM is located in the BIOS storage. For extra physical NICs the
vendors have their own tools to burn new FW into the ROM.

2. Microsofts official view is that DHCP options are not supported to boot machines from WDS,
probably because they have a bug in their software. Read about that here:

a. Using the workaround mentioned in this guide seems to work fine though, please
report any abnormalities.

b. The truth is, it works to boot machines using DHCP options, as long as you follow
this guide.

3. PXE Option 60 is used when the client requests a PXE server, and also when the Server
replies. They of course have different values depending where its being used.

4. We have tested this on a number of physical as well as virtual environments, so it seems to

work fine, but dont get upset if it doesnt work for you.

5. You say EFI, I say UEFI, same stuff different name. Typically you can just call it UEFI and not
bother about the technicalities. UEFI & EFI FTW!

So why does it work with IP Helpers?

How does the server know which file to give the client? Is it magic? No, its not magic. Its fairly
straightforward, the client tells the server in the DHCP request which HW capabilities it has. It does
this in the Option 60 that the request has in it, also in Option 93.

A sample string that is sent in the clients request looks like the following:

PXEClient:Arch:<Type Flag>:UNDI:<Options>

The server then picks up the Type Flag and responds back with the right boot loader file. This is why
EFI and BIOS booting works from the same server when using IP Helpers and not with static DHCP
options. The PXE server gets a copy of the DHCP request with the Option 60 set, reviews it, send
back the right file (Also using DHCP Options) and the PXE Client then merges the DHCP offer and the
offer from the PXE server. Hallelujah. When using DHCP options the PXE server never gets a say, so
you have to move the smartness to the PXE server and mimic this functionality.

As of the writing of this document, the following pre-boot architecture types have been requested.
The ones in thick borders are the 3 essential ones, the rest can fairly safely be ignored depending on
the size of your organization.

USING DHCP TO CONTROL UEFI & BIOS PXE 2PINT SOFTWARE

 2Pint
S o f t w a r e
4

Type Architecture WDS Boot File PSP Boot File Comment

Name

0 Intel x86PC boot\x64\wdsnbp.com smsboot\x64\wdsnbp.com This is the typical

BIOS machine, This
machine is typically
also capable of
running x64 code.*

1 NEC/PC98 Japanese 16-bit

microcomputer
manufactured by
NEC. Old school!

2 EFI Itanium What ever happened

to Itanium?

3 DEC Alpha Oooh, I remember

the Alphas. *sigh*

4 Arc x86 boot\x86\wdsnbp.com smsboot\x86\wdsnbp.com Think Virtual Box

sends this unsure.

5 Intel Lean Oh dear, remember

Client this hype? Net-PC

6 EFI IA32 boot\x86\wdmgfw.efi smsboot\x86\wdmgfw.efi 32 bit EFI machines,

typically tablets
running x86
Windows on newer
HW.

7 EFI BC boot\x64\wdmgfw.efi smsboot\x64\wdmgfw.efi 64 bit EFI, majority

of EFI machines fall
under this category.

8 EFI Xscale Boot\arm\? WDS Not supported? XScale is a

boots ARMs but I dont microarchitecture
have one to test with. for central
processing units
initially designed by
Intel implementing
the ARM
architecture.

9 EFI x86-64 This is for systems

that are capable of
running both x86
and x64 EFI.
Systems of this sort

USING DHCP TO CONTROL UEFI & BIOS PXE 2PINT SOFTWARE

 2Pint
S o f t w a r e
5

are very rare as the

developers have to
write code to
support both
architectures.

*Type 0 machines can be both x86 and x64, the wdsnbp.com checks the CPU capabilities and sends
that info back to the WDS server, more on that below.

If you want to read more, have a look here: https://www.rfc-editor.org/rfc/rfc4578.txt

So the Type is always preceded by four zeroes, so like 00007 and 00006 for x64 and x86 EFI types. A
BIOS machine will then be 00000 as its 4 zeroes plus zero for the first Intel x86PC entry.

So EFI BC is the x64 UEFI alright, but what does BC stand for? EFI BC = EFI Byte Code. EFI Byte Code
is a processor agnostic language for device drivers, PXE, and other EFI extensions so that the code
can be written once and run on any supporting platform.

USING DHCP TO CONTROL UEFI & BIOS PXE 2PINT SOFTWARE

 2Pint
S o f t w a r e
6

Giving the right boot file - DHCP Style

Before this article the official response was, use IP helpers or you are doomed. So we are trying to
change that so that is supported and working to use DHCP style settings with WDS. We will use the
DHCP Policy Rules to control which client gets what, basically copying what WDS does with IP
Helpers, but from the DHCP server side.

Enter Policy Rules

So, most Non-Microsoft DHCP servers can review the info in the DHCP requests and respond with
different options depending on whats in the request. Microsoft was a bit late to the table however,
and it wasnt until Server 2012 that this feature was introduced. And most people dont know about
it.

So in order to use these new policies, we need to set up a vendor class to capture the Option 60
information. Then we will use this option to capture requests from clients that match this class.

In a typical environment you want to use 4 class definitions (although you could use less):

1. Vendor class for BIOS machines (x86 and x64)

2. Vendor class for x86 UEFI machines

3. Vendor class for x64 UEFI machines

4. Vendor class for x86 & x64 EFI capably HW

When it comes to BIOS machines, the support for x86 and x64 is detected by the initial boot loader,
Windows Deployment Services Network Boot Program in short form WDSNBP, then add .com and
you got the filename. So wdsnbp.com is exactly the same for x86 and x64 HW, this then detects
which capabilities the client has and talks back to the WDS/PSP server. Trivia is that this binary is
actually not 32 bit or 64 bit, its a 16 bit executable. This then loads BootMgr.exe that loads BIOS
machines, and this file is somewhat special as its a compressed file containing several files, but lets
not talk about that here. Anyone interested can use this as a starting point of different Windows
compression algos: http://www.coderforlife.com/microsoft-compression-formats/

Aaaaanyhow, back to the DHCP rules.

USING DHCP TO CONTROL UEFI & BIOS PXE 2PINT SOFTWARE

 2Pint
S o f t w a r e
7

DHCP Policy Rules is Server 2012 or above

DHCP Policy objects were introduced in Windows Server 2012, so if you are on 2008, you cannot do
these coolio thingies. Upgrade or go with a free Linux DHCP like ISC DHCP, your choice.

A dummy guide to how to set up and work with Microsoft DHCP Policies can be found here:
https://technet.microsoft.com/en-us/library/hh831538.aspx

Might be worth to skim the article above to get an idea of how it works before continuing.

If you are using ISC DHCP, you can find a good sample script by fellow iPXE geek Robin Smidsrd.

https://gist.github.com/robinsmidsrod/4008017

The interesting bits looks like this:

elsif exists user-class and option user-class = "gPXE" {

# If someone has an old version of gPXE burned into their ROM,
# load a more recent iPXE
filename "ipxe.pxe";
}
elsif option arch = 00:06 {
# EFI 32-bit
# I like to use iPXE-provided drivers, so therefore give ipxe.efi
# to all non-iPXE clients, use snponly.efi if you have unsupported
# or misbehaving NICs
filename "ipxe-x86.efi";
#filename "snponly-x86.efi";
}
elsif option arch = 00:07 {
# EFI 64-bit
# I like to use iPXE-provided drivers, so therefore give ipxe.efi
# to all non-iPXE clients, use snponly.efi if you have unsupported
# or misbehaving NICs
filename "ipxe-x64.efi";
#filename "snponly-x64.efi";
}
elsif option arch = 00:00 {
# Legacy BIOS x86 mode
# I like to use iPXE-provided drivers, so therefore give ipxe.pxe
# to all non-iPXE clients, use undionly.kpxe if you have unsupported
# or misbehaving NICs
filename "ipxe.pxe";
#filename "undionly.kpxe";
}
else {
# Unsupported client architecture type, so do nothing
}

A bit of a spoiler, but basically we detect the incoming architecture flag and set the reply filename to
something we know will work well. So lets go and configure our MS DHCP the same way.

USING DHCP TO CONTROL UEFI & BIOS PXE 2PINT SOFTWARE

 2Pint
S o f t w a r e
8

Setting Up DHCP for EFI & BIOS Boots

First of all, we expect that you have at least one scope on your DHCP server, this article is not on how
to set up DHCP, its about how to boot EFI machines with DHCP. So dont ask us about DHCP in
general

Creating Required Vendor Classes

Vendor classes are used to identify machines booting, its basically a way for the DHCP server to
detect that one machines should fall under a specific category. Not that hard to grasp, really.

Ok, lets do it! Right click the IPv4 object in the DHCP console and select Define Vendor Classes
The following pic will give a hint of where its at:

The DHCP Vendor Classes pop shows up, hit the Add button and the following little nice screen
New Class is staring at us. Give the first Class a proper name, so that people that read this after
you have left the company in the path of becoming a successful rock star get it as well. I Named
mine PXEClient (UEFI x64), the display name has nothing to do with anything, its just a name, like
Bob. The description can contain anything as well, typically something sensible. That was the easy
part, now it gets a wee bit tricky, but I will hold your hand.

Ok, just under where it says ASCII: we can actually set the mouse pointer there and type stuff in.
This is where it a bit tricky; things are case sensitive so it needs to look exactly like this:

PXEClient:Arch:00007

Exactly like that, nothing more, nothing less, like below:

USING DHCP TO CONTROL UEFI & BIOS PXE 2PINT SOFTWARE

 2Pint
S o f t w a r e
9

Then we hit the OK button, and we get back to the DHCP Vendor Classes screen and we see our
little entry added:

Thats it, we created our Vendor Class and linked it to the data that a UEFI x64 client will send out in
its DHCP request.

USING DHCP TO CONTROL UEFI & BIOS PXE 2PINT SOFTWARE

 2Pint
S o f t w a r e
10

Creating New Policy Objects

Hit the close button on the Vendor Class with all the force you got and hurry over to the next node,
the Policies node. Here we right click and get the New Policy option as the first one, select it.

Also, please note that you can create Policies from the Scope Node as well, they dont have to be
Server wide. Its up to you. Server Policies are for all Scopes, makes sense. If server Policies win over
Scope Policies, I would assume so but dont really know. The DHCP Policy wizard appears, amazing,
time to go crazy on the keyboard, Policy Name and Description:

USING DHCP TO CONTROL UEFI & BIOS PXE 2PINT SOFTWARE

 2Pint
S o f t w a r e
11

Type in some meaningful info, remember the rock start career is calling. Hit the Next button when
you have typed in something creative. This takes you to the Condition page of the Wizard, here is
where we match up the Policy with the Vendor Class we just created.

Keep in mind that there are x86 UEFIs as well, so if you want to support them as well you need to
define another Vendor Class with the value of PXEClient:Arch:00006. The 6 indicates x86 and 7 is
x64, remember the table in the beginning of this article? Good.

Click the Next button to take us to the Conditions.

Adding Conditions
Hit the Add Button to add in a new Condition.

The AND/OR button doesnt come in to play here as we will only have one rule.

In the Add/Edit Condition page we select Vendor Class from the Criteria drop down, and select
the Equals Operator. Then we select our PXEClient (UEFI x64) Vendor class that we just selected.
Select it. The screen below shows how its supposed to be looking:

USING DHCP TO CONTROL UEFI & BIOS PXE 2PINT SOFTWARE

 2Pint
S o f t w a r e
12

Ensure that the Append Wildcard (*) check box is selected. This makes sure that rest of the string
is not used in the comparison. The smart people that clicked the RFC link and read a little will know
that the entire Option 60 string looks something like PXEClient:Arch:00007:Undi:. So it continues
after 00007, hence the wildcard operator. Moving on. Hit the Add button, again, yes I know its
tiresome. Puh!

Now the page should look like the one above, we have added a Value and we can press the Ok
button. This takes us back to the Conditions page, listing our newly added Condition. Make sure that
the little * is available after the Rule, this means the wildcard is in play. If you forget to click this
before you hit the Add button you have to remove the Condition and then add it in again.

USING DHCP TO CONTROL UEFI & BIOS PXE 2PINT SOFTWARE

 2Pint
S o f t w a r e
13

Hit the Next button and move on.

Depending on where you created the Policy there might be a question whether to limit the policy to a
certain range, select No on that and move on by clicking Next after selecting No.

USING DHCP TO CONTROL UEFI & BIOS PXE 2PINT SOFTWARE

 2Pint
S o f t w a r e
14

Defining Settings For The Rule

This takes us to the DHCP settings, basically what to respond to the client if a machine matches the
Criteria rule we created earlier. Scroll down to the Option 60, 66 and 67 entries.

Since there is a bug in the EFI (Yeah, we call it a bug, unsure if Microsoft after reading this article will
continue to call it a bug or maybe updates the code, read about that here: )

So since the world is upside down in Microsoft EFI land, True is False and False is True. This means
that Option 60 should be set for machines that are NOT on the same box.

Typically this is always the case, since you are using IP Helpers to get to the DHCP server to start
with, otherwise no DHCP IP Address. So that will always work. Trivia is though, that it seems like EFI
always accepts the Option 60 set in the reply offer if using DHCP scopes to control the loader
selection, even if its combined with IP Helper. Which it shouldnt do really.

So the option 60 is added in the reply package, defined above as PXEClient, dont confuse this with
the Request Option 60 which we know is like PXEClient:Arch:000 etc. Now if you dont have

USING DHCP TO CONTROL UEFI & BIOS PXE 2PINT SOFTWARE

 2Pint
S o f t w a r e
15

Option 60 to choose in the list you can go and add it following these instructions:
https://msdn.microsoft.com/en-us/library/dd128762(v=winembedded.51).aspx

Scroll down to the option 66 and 67 and set 66 to the FQDN or IP of the boot server, safest is the IP
as DNSs can sometimes not work, but feel free to try it out.

Then we got the IP added, lets move on to option 67.

Here we add the Windows Deployment Services ManaGement FirmWare or WDSMGFW.EFI for short,
so smsboot\x64\wdsmgfw.efi is the path we type in. Ok, nearly there, hit the Next button and we can
then see the summary. We are on the home stretch now

USING DHCP TO CONTROL UEFI & BIOS PXE 2PINT SOFTWARE

 2Pint
S o f t w a r e
16

The Summary Page

It is what it says

Looks right to me, Microsoft sure does know how to write wizards. Hit the Finish button and take a
well-deserved break.

Make sure the Policy is in the Enabled state and listed like below:

If you are really keen, then add in another option for x86 and x86x64 EFI as well as BIOS machines.

Use the table in the beginning of this article as the base for the values, if you cant figure it out, then
maybe its time for that rock star career sooner rather than later? Or ping us an email and we will
come and help you.

So what we have now looks like this:

USING DHCP TO CONTROL UEFI & BIOS PXE 2PINT SOFTWARE

 2Pint
S o f t w a r e
17

This of course means that no other machines than x64 UEFI machines, but what about those BIOS
boxes? One feature" is that DHCP Rules override default Scope options, so you can create default
option 66 & 67 for BIOS machines and if you only have Type 0 (BIOS remember?) and Type 7 (x64
UEFI machines) you are good to go.

If you do define default options 66 and 67 for the scope it looks like this:

Maybe not the clearest, so having different rules for different HW types could be a cleaner solution,
but adds overhead as more rules needs to be processed.

If you want you can also create 3 Policies and then let the policies decide which options that are set.
Like the pic below:

USING DHCP TO CONTROL UEFI & BIOS PXE 2PINT SOFTWARE

 2Pint
S o f t w a r e
18

Done!
Believe it or not, you are done, go ahead and try it out, if its not working we have some videos on or
site on how to set it up that you can follow!

Things to watch out for:

1. Make sure you cover all the different Types of HW you want to boot.
2. This setup could force an x86 image on to a x64 machine, failing the boot process with a
winload.efi error. More on that over here on Niall Bradys blog:
http://www.niallbrady.com/2014/08/18/why-do-i-get-a-winload-efi-status-0xc0000359-error-
when-using-uefi-network-boot-in-system-center-2012-r2-configuration-manager/
3. A lot of people (especially Microsoft employees and MVPs) will tell you that booting PXE
from WDS using DHCP options is not supported. It can safely be ignored.
4. Any issues, give us a shout on the regular channels.

Of course, if you are using the upcoming 2Pint Software tool iPXE Anywhere all of these issues
would go away, nice huh?

End Comment
Using DHCP Policies is a powerful way of controlling which boot file etc. a machine should have. You
can also filter out MAC addresses etc. if you want, controlling it on a per HW type, regardless of
capabilities. Let us know if that is interesting and we will write about that as well.

USING DHCP TO CONTROL UEFI & BIOS PXE 2PINT SOFTWARE