I recently embarked on a mission to implement (WDS) Windows Deployment Services into our environment. Due to a multitude of factors the WDS server could not be implemented onto the existing DHCP Server, and would instead reside as an independent server on a separate VLAN.
This proved problematic as PXE booting clients broadcast a DHCPDISCOVER packet extended with PXE-specific options. DHCP servers by default will ignore the extended PXE-specific options, and routers don’t typically forward broadcast traffic. So, you guessed it, nothing worked.
I needed a way to enable clients to first get an IP from the DHCP server, and then be properly directed (across different VLANs) to the WDS server.
There turned out to be two ways of accomplishing this goal:
- Configuring routers to forward broadcasts (Setting Up IP Helpers)
- DHCP options to direct PXE clients to an appropriate NBP to download
Setting DHCP options for WDS PXE booting
My initial reaction was that the DHCP options seemed preferable. I could make one centralized change that would enable PXE booting throughout the environment. However, identifying the exact DHCP option settings that would permit cross VLAN PXE booting proved challenging.
TechNet stated the following:
Using DHCP Options 60, 66, and 67
Although Microsoft does not recommend this method, you can use the following DHCP options to direct PXE clients to an appropriate NBP to download:
• Option 60 = client identifier. You should set this to the string PXEClient. Note that this only applies if DHCP is on the same server as Windows Deployment Services.
• Option 66 = boot server host name
• Option 67 = boot file name
The above recommended settings simply did not work in any configuration.
Credit for a working solution goes to: Jason Koppe & Ned_Schneebly
Their two posts: Differential Analysis – WDS & DHCP Separation & Revisit: Differential Analysis – WDS & DHCP are extremely informative, so check them out.
They posted their working solution here: WDS server and DHCP server on two different servers
I have included their recommended settings below:
DHCP Settings to deploy x86 architecture:
Predefined Option 43 – 010400000000FF
Custom-made Option 60 – String – PXEClient
Predefined Option 66 – IP or Hostname of the WDS Server (in our case 10.150.150.1)
Predefined Option 67 – boot\x86\wdsnbp.com
One more thing to keep an eye on are open ports that need to be open to the WDS server:
UDP – 67, 68, 69, 4011
TCP – 135, 137, 138, 139, 5040
These settings worked perfectly. I was able to PXE boot any client in my environment regardless of location. I had a working solution, but that comment I ran across on the TechNet site about DHCP options not being recommended was bothering me.
Are DHCP Options the best solution for WDS PXE booting?
According to this TechNet article: Managing Network Boot Programs, the answer is no.
Quote from MS about DHCP & WDS:
Although Microsoft does not recommend this method, you can use the following DHCP options to direct PXE clients to an appropriate NBP to download
Quote from the PXE Specification:
“Redirection by the Boot Service to a TFTP service on a remote server should not be done as it is not reasonably possible for the redirecting server to know for certain that the TFTP server being redirected to is truly available.”
Another WDS deployment guide states:
“Microsoft does not support the use of these options on a DHCP server to redirect PXE clients.”
- Using DHCP options is not as reliable as updating the IP Helper tables. In testing, Microsoft has observed some issues (mainly with older PXE ROM) related to clients incorrectly parsing the DHCP options returned from the DHCP server. The result is that booting clients see a “TFTP Failed” error message. Generally, this problem occurs when the PXE ROM ignores the boot server host name value and instead attempts to download the NBP directly from the DHCP server (which likely does not have the NBP).
- If there are multiple network boot servers available to service client requests, specifying a specific network boot server may prevent load-balancing.
- Clients may be directed to a network boot server that is not available. Because the client does not have to contact a network boot server directly to determine the NBP to download, the DHCP server may direct clients to download a NBP that does not exist or to a server that is not currently available.
- Clients may bypass the network boot server’s answer settings. Many network boot servers have a mechanism that enables you to control which clients (if any) should be answered. Per the PXE standard, client computers should contact the network boot server directly to obtain the path and file name of the NBP. Using DHCP options 66 and 67 can cause the client to bypass this communication with the network boot server and therefore ignore the settings of the network boot server for answering clients.
The really significant drawback here seems to come from option 67: boot\x86\wdsnbp.com
The WDS server has a host of (NBPs) Network Boot Programs at it’s disposal:
Rather than allowing the WDS server to make a decision about which one is best for your client, you are statically setting this option via DHCP option. This limits your client’s ability to take advantage of the best NBP solution.
Example: You have a client that is capable of taking advantage of a 64bit NBP. If you have set boot\x86\wdsnbp.com on option 67, it won’t matter. Your client will utilize the 32bit NBP. This may go unnoticed by you because the 32bit NBP is still capable of deploying both 32bit and 64bit images.
It’s important to note in the above list of NBPs that wdsnbp only supports a traditional BIOS. Any devices with a modern EFI will be unable to take advantage of PXE booting if you set option 67 in this manner.
DHCP Options vs IP Helpers
I didn’t like how the DHCP options were limiting my clients so I decided to take a look at IP Helpers as an alternative solution.
I disabled DHCP options 43, 60, 66, and 67 and then had the network team add IP Helpers that pointed to the IP address of my WDS server.
This method worked just as perfectly. I could once again PXE boot from any device in my organization.
I was curious to see if there was any type of performance difference, so I flip-flopped back and forth a few times between DHCP Options and IP Helpers and pushed out several images to test clients. Results: no difference in performance. During each test PXE booting operated exactly the same, and took the same amount of time to reach a fully deployed and useable desktop on the test client.
Using the above mentioned DHCP Options will permit you to PXE boot your clients across both VLANs and subnets with both 32bit and 64bit images. Configuring IP Helpers on your network to point to the WDS server will achieve the same goal. However, the DHCP option method is generally not preferred as its limits your client’s ability to negotiate with the WDS server about what NBD would be best utilized. You must also choose between tradtional BIOS and EFI as the DHCP option forces one or the other. IP Helpers offer the same level of performance with none of these restrictions. It seems clear that IP Helpers hold an advantage over DHCP options for the purpose of PXE booting using WDS.
These two articles were extremely informative while researching our WDS implementation:
How Network Boot Programs Work
Troubleshooting the PXE Service Point and WDS in Configuration Manager 2007