DHCP Configuration
Using IP Helpers
If you are using IP Helpers to direct your PXE traffic then your routing hardware should be configured to redirect DHCP Requests to both your DHCP server and to the 2PXE Server. The PXE Boot request will be picked up and processed directly by 2PXE Server. The request package contains all of the information required by 2PXE to ascertain the hardware type and machine identification in order to ensure that the correct boot information can then be sent to the requesting client.
If you are using IP Helpers then the rest of this DHCP Configuration section can be skipped as it only applies to environments that are using DHCP options to handle PXE boot requests.
Using DHCP Options
If you are not using IP helpers to control the PXE process, you need to do some changes to your DHCP infrastructure to allow PXE booting to work. The DHCP server must be configured to enable it to reply to a requesting client with enough information to allow the client to obtain a boot file. This includes the IP Address of the PXE Server, the appropriate boot file name (according to client hardware type) and the URL and Port number for the https session.
You need to define the IP of the server to do the initial download from, using the next-server field (Which Microsoft sets by using Option 66, which allows a DNS name that is then resolved to an IP that as setting the next-server field.)
You need to define the appropriate filename to boot. This is unique per hardware type and needs to be defined through a rule or other DHCP server logic. If you are using IP Helpers, this is handled directly by the 2PXE service, but when using the DHCP server, the DHCP server has to do this logic filtering instead. This is Option 67.
We need to define the HTTPS url and Port for iPXE to use when communicating with the 2PXE Service. As we are using HTTPS this string needs to exactly match the host header of the machine, otherwise the TLS session will fail.
NOTE: To reiterate – “this needs to match the host header of the machine” this means it must be in lower case, must be spelt correctly and must contain a trailing slash:
https://<server.f.q.d.n>:<port>/
The following table shows what you need to set to make sure 2PXE works as it should and example values:
DHCP Name Field
Microsoft Name
Value
Example
Next-Server (SIADDRR)
Option 66
IP of the 2PXE server
192.168.10.30
Filename
Option 67
Boot file name
Unique per HW type
BIOS both x64 and x86
Boot\x86\undionly.kpxe
UEFI – x64
Boot\x64\snponly_x64.efi
EUFI – x86
Boot\x86\snponly_x86.efi
Option 175
Option 175
Url of 2PXE FQDN in lowercase and Port number
https:// pxe01.2pint.local :8050/
Note: This needs to be lowercase and must contain the port and end with a slash “/”
Configuring a Microsoft DHCP server for 2PXE server
This is an example setup where the 2PXE server IP is 192.168.10.30 and the FQDN host name is PXE01.2pint.local and the default port is 8050. This guide will help you to define DHCP options to boot of UEFI machines as well as BIOS computer from the same 2PXE server, using DHCP options and thus bypassing the need & requirement for IP Helpers on the routers.
What’s required?
This guides go through creating DHCP scopes to boot of a 2PXE server using a Microsoft DHCP server, it requires:
Microsoft DHCP Server running on at least Server 2012 with some DHCP scopes set up
A 2Pint Software 2PXE Server providing boot services
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)
What’s 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 2PXE server -> iPXE Network Loader talks to 2PXE over https to get correct boot action -> Boot WinPE (Typically).
First things first - The Basics!
PXE is a software standard, which makes room for developers to interpret things slightly differently which means that unexpected bugs and issues in the code are a way of life. If you have worked with PXE before you will know that things do not work flawlessly at all times.
If you are having issues, try to get the latest BIOS/Firmware for computer. For on board NIC’s (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 NIC’s the vendors have their own tools to burn new FW into the ROM.
Microsoft’s official view is that DHCP options are not supported to boot machines from WDS, but we think that that is probably because they have a bug in their software. Read about that here:
https://2pintsoftware.com/a-bug-is-a-bug-a-wds-dhcp-options-rant/
Using the workaround mentioned in this guide works, If it doesn’t then please report any abnormalities to us and we can help. The simple fact is, it does work to boot machines using DHCP options, as long as you follow this guide.
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? Magic? No, it’s actually fairly straightforward. As part of the DHCP request (In particular Options 60 and 93) the client sends the servers quite a bit of information about its hardware and other identifying information.
The Option 60 string sent as part of the clients request is in the following form:
PXEClient:Arch:<Type Flag>:UNDI:<Options>
The server picks up the Type Flag and can respond with the correct boot loader file. This is how EFI and BIOS booting can work from the same server when using IP Helpers but not with static DHCP options. With IP Helpers the PXE server directly receives a copy of the DHCP request which contains the Option 60 information. The PXE Server can then review this information and send back the appropriate boot file information (Also using DHCP Options). The PXE Client can then merge the DHCP and PXE server offers to form the necessary request. When using DHCP options the PXE server doesn’t get to talk to the client during this early exchange, so the processing must be moved to the DHCP server to 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.
Type
Architecture Name
2PXE Boot File
Comment
0
Intel x86PC
boot\x86\undionly.kpxe
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\undionly.kpxe
Think Virtual Box sends this… unsure.
5
Intel Lean Client
Oh dear, remember this hype? Net-PC…
6
EFI IA32
boot\x86\snponly_x86.efi
32 bit EFI machines, typically tablets running x86 Windows on newer HW.
7
EFI BC
boot\x64\snponly_x64.efi
64 bit EFI, majority of EFI machines fall under this category.
8
EFI Xscale
Not supported?
XScale is a microarchitecture 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 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 server, more on that below.
If you want to read more, have a look here: https://www.rfc-editor.org/rfc/rfc4578.txt
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.
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.
NOTE: There was some confusion in the industry around this technology so some machines might report in as type 9 (EFI- x86-64). In this case try upgrading the firmware.
DHCP Policy Rules for controlling boot files
Most Non-Microsoft DHCP servers can review the info in the DHCP requests and respond with different options depending on what’s in the request. Microsoft was a bit late to the table however, and it wasn’t until Server 2012 that this feature was introduced and a lot of Administrators are not aware of this functionality.
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):
Vendor class for BIOS machines (x86 and x64)
Vendor class for x86 UEFI machines
Vendor class for x64 UEFI machines
Vendor class for x86 & x64 EFI capable HW
When it comes to BIOS machines, the support for x86 and x64 is detected by the boot loader itself. As all x64 machines can run x86 code, the x64 BIOS request is handled by the x86 file.
NOTE: DHCP Policy objects were introduced in Windows Server 2012, so if you are on 2008, you cannot do these cool things. Upgrade or go with a free Linux DHCP like ISC DHCP, your choice.
If you need some basic understanding around how to set up and work with Microsoft DHCP Policies then please have a read of the following Microsoft article: https://technet.microsoft.com/en-us/library/hh831538.aspx
Creating Required Vendor Classes
Vendor classes are used to identify machines booting, it’s basically a way for the DHCP server to detect that one machines should fall under a specific category.
Right click the IPv4 object in the DHCP console and select “Define Vendor Classes…”
The DHCP Vendor Classes dialogue box will appear, hit the “Add…” button and the “New Class” dialogue box will appear. Give the first Class a proper name, so that people that read this after you have left the company, on the path to becoming a successful rock star, get it as well. In this example we have named it “PXEClient (UEFI x64)”. The display name has nothing to do with functionality, it’s just used for identification purposes. The description can contain anything as well, but hopefully something sensible.
Next, in the ID, Binary, ASCII window, under where it says “ASCII:” Click in that space and you will then be able to enter information into this field as follows:
PXEClient:Arch:00007
Please note that this is case sensitive so it must be entered exactly like the above, nothing more, nothing less. Once complete you should have:
Then we hit the OK button, and we get back to the “DHCP Vendor Classes” screen where you will see the new entry:
That’s it, we created our first Vendor Class and linked it to the data that a UEFI x64 client will send out in its DHCP request. Now, if you want you can create one more for x86 UEFI and also one for BIOS. The x86 UEFI one should appear as follows:
And for the BIOS entry like this:
When complete the three new vendor classes will appear as follows:
Creating new scope options
Once our PXE booted client needs to contact iPXE, it needs the FQDN URL of the 2PXE server. This is configured via DHCP option #175. This option does not appear by default, so it must be added.
Right click the IPv4 node in the console and select “Set Predefined Options...”
This will take you to the Predefined Options and Values screen, where you can add new settings. Click the “Add...” button.
This allows you to set up a template which will define how the option should behave and look when being set as a DHCP scope option. Enter details as follows:
Name: This can be anything describing the option
Data type: This should be set to String
Code: This should be set to 175
Description: This can be set to a little novel about life, or just describing the DHCP option and usage. Once entered you should have the following:
Once you click “OK” you can also fill in a default value that administrators will see when adding the DHCP option to their scope::
Click “OK” to close the Option dialog.
Creating new policy objects
Next we need to configure Policies. Right click on the Policies node and choose the “New Policy” menu option.
Please note that you can create Policies from the Scope Node as well, they don’t have to be Server wide. The DHCP server evaluates policies sequentially according to an assigned processing order. The DHCP administrator assigns the processing order to the policies. If policies exist at the server and scope levels, the server applies both sets of policies and evaluates the scope policies before the server policies. The processing order for a scope level policy defines the order of evaluation within the scope. If there are no policies defined at the scope level, the policies at the server level apply to the scope.
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 that was created previously..
Keep in mind that there are x86 UEFI’s as well, and if these require support then you would define another Vendor Class with the value of PXEClient:Arch:00006. The 6 indicates x86 and 7 is x64, as per the table at the beginning of this article.
Click the “Next” button which allows you to set Conditions. Click the Add Button to add in a new Condition.
The AND/OR button doesn’t come in to play here as we will only have one rule. In the “Add/Edit Condition” page select “Vendor Class” from the “Criteria” drop down, and select the “Equals” Operator. Then select the PXEClient (UEFI x64) Vendor class from the list:
Ensure that the “Append Wildcard (*)” check box is selected as below. 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 Append wildcard operator:
Click on the Add button.
The completed condition will appear as above. Next click the “Ok” button. This takes returns back to the Conditions page which now lists the newly added Condition. Make sure that the asterisk * is in the Rule Value to ensure that the wildcard is in play. If you forget to check this before you hit the “Add” button you will have to remove the Condition and add it in again.
Hit the “Next” button and move on.
Depending on where a Policy is created there is the ability to limit the policy to a certain IP Address range. Select “No” to this option and then click Next to move on.
Next to configure in the wizard are DHCP settings. This denotes what is sent to the client once it matches the Criteria rule created earlier. Options 60, 66 and 67 are all required.
Firstly Option 66 - Enter the IP Address (not the hostname) of the 2PXE server as the string value for this option.
Next Option 67:
The Option 67 string contains the iPXE file path details to snponly_x64.efi (the UEFI x64 file) The full path details are from the \ProgramData\2PintSoftware\2PXE\RemoteInstall directory.
Next set DHCP option 175 to configure the 2PXE server DNS name
Put in the correct value for the server as below, all lowercase, port number and ending “/” value. Note that this is https and accordingly must exactly match what is returned form the lookup. This is the reason for the lower case form and trailing slash.
Running DHCP server on the same server as 2PXE
NOTE: This part is only required when running 2PXE on the same server as the DHCP server – usually only in a Lab/POC environment.
Option 60 is added in the reply package as “PXEClient”. Don’t confuse this with the Request Option 60 which is like “PXEClient:Arch:000…” etc.
NOTE: If Option 60 does not appear in the list you can add it by following these instructions: https://msdn.microsoft.com/en-us/library/dd128762(v=winembedded.51).aspx
This setting forces the PXE client to use port 4011 when communicating to the PXE server service as the DHCP port will be in use by the DHCP server service.
The Summary Page
You can now complete the wizard. Hit the “Finish” button and make sure the Policy is in the “Enabled” state and listed as below:
The DHCP Scope Options should now appear as follows:
Configuration Options
At the moment our example set up is only for x64 UEFI machines, but what about those BIOS boxes? And x86 UEFI?
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 would then be good to go. As there are not many x86 UEFI machines around anymore this may be enough.
If you do define default options 66 and 67 + 175 for the scope it looks like this (Yes, you can then remove DHCP option 175).
This is not the clearest solution, but having different rules for different hardware types does add overhead as more rules need to be processed.
Another option is to create 3 separate policies which allows the options to be set per policy. This is probably the most efficient way:
Then looking at the individual options, you will see the three Policy rules each giving out 66,67 and 175:
Things to watch out for:
Make sure you cover all the different “Types” of HW you want to boot.
A lot of people (especially Microsoft employees and MVP’s) will tell you that booting PXE from using DHCP options is not a good idea, they can safely be ignored.
Any issues, give us a shout on the regular support channels.
There is a Branchcache Bob video in the on the 2Pint web site that steps through a close approximation of the above as it applies to WDS.
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. or you can control it on a per Hardware type regardless of capabilities.
Last updated
