> For the complete documentation index, see [llms.txt](https://documentation.2pintsoftware.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.2pintsoftware.com/2pxe-server/4.0/configuration/dhcp-configuration/configuring-dhcp-scope-options.md). # Configuring DHCP Scope Options ## Example Microsoft DHCP Server configuration This is an example setup where the 2PXE server IP address is 192.168.10.30, the FQDN host name is PXE01.2pint.local, and the default port is 8050. The steps below define DHCP options to boot both UEFI and BIOS computers from the same 2PXE server, avoiding the need for IP Helpers on the routers. #### What is required? Creating DHCP scope options to boot from a 2PXE server using a Microsoft DHCP server 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 between the PXE booting clients and the servers, blocking DHCP broadcast traffic * A BIOS client computer (can be virtual; Hyper-V Generation 1 VMs use BIOS) * An x64 EFI client computer (can be virtual; Hyper-V Generation 2 VMs use EFI) #### What is the Outcome? When finished, you can 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 the correct boot action -> Boot WinPE (typically). #### First things first - The Basics! PXE is a software standard that leaves 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 know that things do not always work flawlessly. 1. If you are having issues, try to get the latest BIOS/firmware for the computer. For onboard NICs (LAN on Motherboard, or LOM), this is typically a BIOS update, because the PXE ROM is stored in the BIOS. For additional physical NICs, the vendors have their own tools to burn new firmware into the ROM. 2. Microsoft’s official view is that DHCP options are not supported for booting machines from WDS, but 2Pint Software believes this is because of a bug in WDS. Read about that here: [https://2pintsoftware.com/a-bug-is-a-bug-a-wds-dhcp-options-rant/](https://2pintsoftware.com/news/details/a-bug-is-a-bug-a-wds-dhcp-options-rant) The workaround described here works. If it does not work for you, report any abnormalities to 2Pint Software support for help. Booting machines using DHCP options does work, as long as you follow these steps. How does the server know which file to give the client? Magic? No, it is actually fairly straightforward. As part of the DHCP request (in particular, options 60 and 93), the client sends the server quite a bit of information about its hardware and other identifying information. The Option 60 string sent as part of the client's request is in the following form:\ **PXEClient:Arch:\:UNDI:\** 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 does not get to talk to the client during this early exchange, so the processing must be moved to the DHCP server to mimic this functionality. The following preboot architecture types have been defined. The essential ones are types 0 (BIOS), 6 and 7 (x86 and x64 UEFI), and 11 (ARM64 UEFI); the rest can fairly safely be ignored, depending on your organization.
TypeArchitecture Name2PXE Boot FileComment
0Intel x86PCboot\x86\undionly.kpxeThis is the typical BIOS machine. This machine is typically also capable of running x64 code.*
1NEC/PC98Japanese 16-bit microcomputer manufactured by NEC. Old school!
2EFI ItaniumWhatever happened to Itanium?
3DEC AlphaRemember the Alphas?
4Arc x86boot\x86\undionly.kpxeVirtualBox might send this.
5Intel Lean ClientOh dear, remember this hype? Net-PC…
6EFI IA32boot\x86\snponly_x86.efi32-bit EFI machines, typically tablets running x86 Windows on newer hardware.
7EFI BCboot\x64\snponly_x64.efi64-bit EFI. The majority of EFI machines fall into this category.
8EFI XscaleNot supported?XScale is a microarchitecture for central processing units initially designed by Intel implementing the ARM architecture.
9EFI x86-64This 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.
10ARM 32-bit UEFINot supported
11ARM 64-bit UEFIboot\arm64\snponly_arm64.efiARM64 devices, such as Copilot+ PCs and Surface devices with Snapdragon processors.
16x64 UEFI HTTP Boothttp://<server>:8049/2PXE/Boot/x64/snponly_x64.efiUEFI HTTP Boot (the request's Option 60 starts with HTTPClient instead of PXEClient). See UEFI HTTP Boot below.
19ARM64 UEFI HTTP Boothttp://<server>:8049/2PXE/Boot/arm64/snponly_arm64.efiUEFI HTTP Boot on ARM64 devices. See UEFI HTTP Boot below.
\*Type 0 machines can be either x86 or x64. The boot loader checks the CPU capabilities and sends that information back to the server (see below). The `snponly` file names shown are the defaults. If the **iPXE Bootloader binary to use** setting is set to **Native** or **USB**, 2PXE uses the `snponly_drv_.efi` or `snponly_usb_.efi` file in the same folder instead, so use the matching file name in your DHCP options. ### UEFI HTTP Boot 2PXE also supports UEFI HTTP Boot, where the device's firmware downloads the boot loader over HTTP instead of TFTP. These requests identify themselves with an Option 60 value that starts with `HTTPClient` (architecture type 16 for x64, or 19 for ARM64). When 2PXE receives the request directly (on the same subnet, or through IP helpers), it answers automatically with the URL of the iPXE boot loader on its HTTP port, for example `http://:8049/2PXE/Boot/x64/snponly_x64.efi`. The port is set by the **RunOnNonHttpsPort** setting (8049 by default), and must be allowed through the firewall. HTTP is used rather than HTTPS because the firmware usually does not trust the 2PXE certificate. When using DHCP options instead, create a vendor class for `HTTPClient:Arch:00016` (x64) or `HTTPClient:Arch:00019` (ARM64), and in the matching policy set Option 60 to `HTTPClient` and Option 67 to the full URL above. For more information, see RFC 4578: The type is always padded with zeros to five digits, for example 00007 and 00006 for the x64 and x86 EFI types. A BIOS machine is 00000: four zeros plus 0 for the Intel x86PC entry. EFI BC is the x64 UEFI type, 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. {% hint style="info" %} **NOTE:** There was some confusion in the industry around this technology, so some machines might report as type 9 (EFI x86-64). In this case, try upgrading the firmware. {% endhint %} ## DHCP Policy Rules for controlling boot files Most non-Microsoft DHCP servers can review the information in DHCP requests and respond with different options depending on what is in the request. Microsoft was a bit late to the table, however: this feature was only introduced in Windows Server 2012, and many administrators are not aware of it. To use these policies, you need to set up a vendor class to capture the Option 60 information, and then use it to match requests from clients in that class. In a typical environment, you use one vendor class for each type of machine that you want to boot, for example: 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 ARM64 UEFI machines When it comes to BIOS machines, the support for x86 and x64 is detected by the boot loader itself. Because all x64 machines can run x86 code, the x64 BIOS request is handled by the x86 file. For an introduction to setting up and working with Microsoft DHCP policies, see the following Microsoft article: ### Creating Required Vendor Classes Vendor classes identify booting machines and allow the DHCP server to recognize the architecture information sent by each client. Choose either method below. Both methods create the vendor classes used by the DHCP policies in the following steps. {% tabs %} {% tab title="DHCP Console" %} Right-click the IPv4 node in the DHCP console and select “Define Vendor Classes…” ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/BDVng8MQDahOf2PpzXon/30.png) In the DHCP Vendor Classes dialog box, click the “Add…” button to open the “New Class” dialog box. Give the first class a clear name, so that anyone who reads it later understands it. In this example, it is named “PXEClient (UEFI x64)”. The display name has nothing to do with functionality; it is only used for identification. The description can also contain anything, but preferably something sensible. Next, in the ID, Binary, ASCII window, click in the space under “ASCII:” and enter the following: PXEClient:Arch:00007 Note that this is case-sensitive, so it must be entered exactly as shown above, nothing more, nothing less. Once complete, you should have: ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/6Johz5rLrVg7vgNdw0iO/31.png) Click the OK button to return to the “DHCP Vendor Classes” screen, where you can see the new entry: ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/pJRNtC206bA9niE7i6Qg/32.png) That is it: the first vendor class is created and linked to the data that a UEFI x64 client sends in its DHCP request. Now, if needed, create one more for x86 UEFI and one for BIOS (and one for ARM64 UEFI, using PXEClient:Arch:00011). The x86 UEFI one should appear as follows: ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/fHMbsKOAKgVJYgFphcJh/33.png) And the BIOS entry like this: ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/LyKuuibzylBEzXKEOY8h/34.png) When complete, the new vendor classes appear as follows: ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/NWJTcoOl0KglaNkhoKwV/35.png) {% endtab %} {% tab title="PowerShell" %} Vendor classes are used to identify booting machines; they are a way for the DHCP server to detect that a machine falls into a specific category. {% hint style="info" %} The steps below use PowerShell to configure DHCP scope options. Run the PowerShell commands on a Windows DHCP server, or install the DHCP management tools:\ **Install-WindowsFeature DHCP -IncludeManagementTools** {% endhint %} To create the required vendor classes using PowerShell, use the following commands: ``` # Define PXE Vendor Classes (global) Add-DhcpServerv4Class -type Vendor -name 'PXEClient (BIOS x86 & x64)' -Data 'PXEClient:Arch:00000' Add-DhcpServerv4Class -type Vendor -name 'PXEClient (UEFI x86)' -Data 'PXEClient:Arch:00006' Add-DhcpServerv4Class -type Vendor -name 'PXEClient (UEFI x64)' -Data 'PXEClient:Arch:00007' Add-DhcpServerv4Class -type Vendor -name 'PXEClient (UEFI Arm32)' -Data 'PXEClient:Arch:00010' Add-DhcpServerv4Class -type Vendor -name 'PXEClient (UEFI Arm64)' -Data 'PXEClient:Arch:00011' ``` {% endtab %} {% endtabs %} ### Creating new scope options When the PXE-booted client needs to contact 2PXE, it needs the URL of the 2PXE server, using its FQDN. This is configured with 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...” ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/2dv8fjkK6NRV99LqEmgr/36.png) This opens the Predefined Options and Values screen, where you can add new settings. Click the “Add...” button. ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/9HesrSDUzh1yb0ZMPgVW/37.png) This allows you to set up a template that defines how the option behaves and looks when it is set as a DHCP scope option. Enter the 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 any text describing the DHCP option and its usage. Once entered, you should have the following: ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/MPYPdjmyvNAvGoxRJ6iU/38.png) Once you click “OK”, you can also fill in a default value that administrators see when adding the DHCP option to their scope: ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/08kvVDilWg3apeWSGERR/39.png) Click “OK” to close the Option dialog. ### Creating new policy objects Next, configure the policies. Right-click the Policies node and choose the “New Policy” menu option. ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/xY6aqtlMpaZSfK9iKKaQ/40.png) Note that you can also create policies from the scope node; they do not 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. Enter a meaningful name and description, and click **Next**. This takes you to the Conditions page of the wizard, where the policy is matched to the vendor class that was created previously. ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/ke2tDUjGPquCQUKAm43u/41.png) Keep in mind that there are x86 UEFI machines as well. If these require support, define another policy using the vendor class with the value PXEClient:Arch:00006. The 6 indicates x86 and 7 is x64, as shown in the table above. Click the “Next” button, which allows you to set conditions. Click the “Add” button to add a new condition. ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/Ly2XbiRHDkBZtykhlR1N/42.png) The AND/OR button does not come into play here, because there is only one rule. On 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: ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/yzpjJEgfZ12Any9XJUoc/43.png) Ensure that the “Append Wildcard (\*)” check box is selected, as shown below. This makes sure that the rest of the string is not used in the comparison. The entire Option 60 string looks something like PXEClient:Arch:00007:Undi:…, so it continues after 00007, hence the wildcard: ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/meh8zJ0DQ0ALKqufviOP/44.png) Click on the Add button. ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/vWtsNUzZDZrrZZhvm9e5/45.png) The completed condition appears as above. Next, click the “OK” button. This returns you 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 select this before you click the “Add” button, you have to remove the condition and add it again. Click the “Next” button to continue. ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/PmtkkB6dh3BmmvnnREtM/46.png) Depending on where a policy is created, you can limit the policy to a certain IP address range. Select “No” for this option, and then click Next to continue. Next, configure the DHCP options in the wizard. These are sent to the client once it matches the condition created earlier. Options 60, 66 and 67 are all required. ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/OqleKbhwCLn1Wr28tR2f/47.png) First, option 66: enter the IP address (not the host name) of the 2PXE server as the string value for this option. ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/UGcIVepeFbdGkBlSzNk8/48.png) Next, option 67: ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/OPhlanx9vT1xOENxqd7y/49.png) The Option 67 string contains the path to snponly\_x64.efi (the UEFI x64 file). The path is relative to the \ProgramData\2Pint Software\2PXE\RemoteInstall directory. Next, set DHCP option 175 to configure the 2PXE server DNS name: ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/dywQujxKof0tVkqdD3kr/50.png) Enter the correct value for the server, as shown below: all lowercase, with the port number and an ending “/”. Because this is HTTPS, it must exactly match what is returned from the lookup, which is the reason for the lowercase form and trailing slash. ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/ieBvw1LJDinzrVzlox40/51.png) ## **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. ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/2dLRheoJUEB7AZaMRprO/52.png) Option 60 is added to the reply packet as “PXEClient”. Do not confuse this with the request's Option 60, which looks like “PXEClient:Arch:000…”. NOTE: If Option 60 does not appear in the list, you can add it by following these instructions: This setting forces the PXE client to use port 4011 when communicating with the PXE server service, because the DHCP port is in use by the DHCP server service. **The Summary Page** You can now complete the wizard. Click the “Finish” button, and make sure the policy is in the “Enabled” state and listed as below: ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/49FhhwSPgZjIbRF13ADu/53.png) The DHCP Scope Options should now appear as follows: ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/VGvD9JV1IjnRYs0udiDZ/54.png) ### **Configuration Options** At this point, the example setup only covers x64 UEFI machines. What about BIOS machines, and x86 UEFI? One useful feature is that DHCP policies override default scope options, so you can create default options 66 and 67 for BIOS machines. If you only have type 0 (BIOS) and type 7 (x64 UEFI) machines, that is all you need. Because there are not many x86 UEFI machines around anymore, this may be enough. If you define default options 66, 67 and 175 for the scope, it looks like this (and you can then remove DHCP option 175 from the policy): ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/pkCUwOoAX2HSaG9dQifL/55.png) 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 three separate policies, which allows the options to be set per policy. This is probably the most efficient way: ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/Kwwv8k1JnytAkRbybBce/56.png) Looking at the individual options, you then see the three policies, each giving out options 66, 67 and 175: ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/QLTulUSYqvbZmXVyUDH0/57.png) Things to watch out for: 1. Make sure you cover all the different hardware types you want to boot. 2. Many people (especially Microsoft employees and MVPs) say that PXE booting using DHCP options is not a good idea; that advice can safely be ignored. 3. If you have any issues, contact 2Pint Software through the regular support channels. 4. There is a BranchCache Bob video on the 2Pint Software website 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 a machine receives. You can also filter on MAC addresses, or control it per hardware type, regardless of capabilities. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://documentation.2pintsoftware.com/2pxe-server/4.0/configuration/dhcp-configuration/configuring-dhcp-scope-options.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.