Manually Creating DHCP Scope Options

This page is a similar to the parent page, but with manual instructions in case you do not want to use the more superior and convenient option of PowerShell.

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

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

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

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):

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

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:

1. Make sure you cover all the different “Types” of HW you want to boot.

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

3. Any issues, give us a shout on the regular support channels.

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