This document describes common scenarios for implementing DHCP in relation to PXE boot with particular focus on Configuration Manager.
Assumptions and audience
Audience must familiar with basic IP networking principles.
The background
In order for a client to perform a PXE boot, there must be a DHCP service available, this is not required to be a Microsoft DHCP service. Any DHCP server is good.
The following diagram shows a typical network setup
In this case the client and the server is on the same network, which is the simplest setup you will come across, normally the setup will be more advanced, but in order to explain the basics, we will start with this simple model.
The DHCP Process
During a normal DHCP process the following happens:
- The client sends out a DHCP broadcast on the network
- The broadcast is picked up by the server
- The server replies with a broadcast containing the MAC address of the client and a suggested IP address
- The client replies back to the server, indicating that it will use the provided address
The PXE Boot process
When a client initiates a PXE boot (often by pressing a key of selecting a particular boot option during start-up) the process changes a little bit:
- The client sends out a DHCP broadcast on the network, with a flag stating that it needs to PXE boot
- The broadcast is picked up by the server
-
The server replies with a broadcast containing the MAC address of the client and a suggested IP address
- If the server configuration has any information on how to PXE boot, this information is included in the reply to the client.
- The client replies back to the server, indicating that it will use the provided address
- The client then contacts the PXE boot server (is this case the same server) and requests the bootfile specified in the boot information sent back from the server
- The file is loaded and launched.
PXE Configuration on the DHCP server
Traditionally the PXE configuration has been made on the DHCP by setting either server or scope options, typically Option 66 and 67 are used, option 66 specifies the server to contact, 67 is the name of the file to request.
Another method of providing the boot information is to have a service listen for the DHCP request coming from the client and then send an additional reply back to the client. This is commonly known as dynamic PXE boot.
PXE booting from Configuration Manager Distribution Point
Configuration Manager provides dynamic PXE boot using the WDS service (available in Windows Server)
A typical simple setup could look like the following
The PXE server is installed on the SCCM DP (the WDS service).
Now the boot process is as follows:
- The client sends out a DHCP broadcast on the network, with a flag stating that it needs to PXE boot
- The broadcast is picked up by the server
- The server replies with a broadcast containing the MAC address of the client and a suggested IP address
- The WDS service also replies back to the client with information on how to PXE boot
- The client replies back to the server, indicating that it will use the provided address
- The client then contacts the PXE boot server (is this case the SCCM DP server) and requests the bootfile specified in the boot information sent back from the server
- The file is loaded and launched.
This method has the great advantage that it is dynamic and therefore it can send back information based on the type of client requesting a PXE boot, whereas a setup using options configured on the DHCP cannot.
Why is this important in this case?
A PXE boot on a BIOS based system is using one method, whereas UEFI based systems are using another, therefore the PXE server must be able to dynamically provide different information according to the client type.
Also note: For UEFI PXE boot to work correctly with SCCM DPs the underlying OS must be Windows Server 2012 R2 or later.
Additional scenarios
Given that a typical network setup today is a lot more complex than the examples given above I will go through some of these to illustrate how to successfully implement PXE boot in such environments
Multiple subnets
The common method of setting up networks today is to have multiple subnets connected by routers or switches providing router-like functionality.
A typical setup could look like the following:
In this setup the DHCP server is in one subnet, the SCCM DP in another and the client is connected to a third network.
Given that DHCP traffic is based primarily on broadcasts, and broadcasts are normally contained within a subnet (in order to control spamming of the network). As such DHCP and also PXE will not work in a setup like this.
The way to fix this is to implement IP Helpers.
IP Helpers is a function implemented in routers to allow broadcast traffic to pass between networks in a controlled manor. It is important to note that IP Helpers typically forwards a specific type of traffic to a specific target (IP address).
In the given example an IP Helper must forward DHPC requests from subnet 10.10.30.0 to 10.10.10.10 to allow the client to obtain an IP address from the DHCP server.
For PXE boot requests to be answered correctly by the SCCM DP server, an additional IP Helper must also forward the request to 10.10.20.10.
The resulting setup looks like this
Note that in the case where the DHCP Server and the SCCM DP is on the same subnet, there must still be two IP Helpers implemented as IP Helpers are directed to a specific IP Address.
Special cases: 1E Nomad with PXE Everywhere
In some scenarios special features like 1E Nomad and PXE Everywhere may be implemented, and that may change the way you should implement DHCP and PXE boot.
There are two typical setups for this approach.
Central DHCP Server
A typical setup for Nomad with PXE Everywhere would be like to following:
The DHCP Server is placed in a central location, and will provide DHCP addresses to clients, using an IP Helper. However, the PXE functionality is provided by local clients running the PXE Everywhere component. In this case there must not be an IP Helper that forwards the DHCP request to the SCCM DP, as we intend for PXE boot requests to be serviced locally. If the IP Helper was setup the client would attempt to contact the SCCM DP to PXE boot.
So but not having the additional IP Helper the DHCP request is forwarded only to the DHCP which provides an IP Address to the client, and the PXE Everywhere service will reply to the same DHCP request to provide PXE boot information.
For this to work successfully the DHCP Server should not provide any PXE information either dynamically or using static option as that will cause confusion for the client trying to PXE boot.
Local DHCP Server
In some Nomad scenarios there may not be a central DHCP server to provide IP addresses to clients. The can be done by the local router, maybe a SOHO (Small Office Home Office) router. These routers are typically not able to provide any PXE boot information, which in this case is a good thing. The client will follow the normal process to obtain an IP address and the PXE Everywhere service will reply to the DHCP with the required PXE Boot information.
The following shows a setup for this case:
Conclusion
- Never use DHCP options, BIOS and UEFI based devices require different replies from PXE Server
- In routed networks use IP Helpers to both the DHCP server and the PXE server
- Do not install DHCP and PXE service on the same server unless it REALLY makes sense
- It is safe to rely on local DHCP functionality but may require an IP Helper pointing to the PXE Server if this is not local
- Windows Server 2012 R2 or later is required for UEFI boot to work correctly
Translated Article to Russian language here https://alexandrelizarov.wordpress.com/2016/03/02/%D0%BD%D0%B5%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE-%D0%BF%D1%80%D0%BE-dhcppxe-%D0%B8-sccm/