Revisit: Differential Analysis - WDS & DHCP

Tom and I wanted to make a couple statements and clarifications about our post earlier this week. First, we got the environment to function. Read on to find out how.

Purpose
The reason we undertook this project was two fold: primarily to see if it would work, but also because we believe that an established DHCP infrastructure should welcome a separate WDS server -- we believe that WDS should be able to function within the same domain but on a different server than the DHCP service. It should be as simple as specifying which DHCP services work with WDS.


Semi-Functional?
This morning, we were able to get a deployment of Vista running beyond the standstill we had a few days ago. The procedures we described in our previous post were wrong. We had defined DHCP option 67 as boot\x86\pxeboot.com because thats what was on the original WDS+DHCP server.

Wrong DHCP Option 67

This, caused the client to load and execute the files in the following order:

Capture of failing boot session

So, after some more searches on Google, we came across this article. Apparently, we skipped steps 1 and 2 of the Deployment Process (load WDSNBP, validate DHCP packet, and download pxeboot.com). The change we made today (changing DHCP option 67 from boot\x86\pxeboot.com to boot\x86\wdsnbp.com) caused the PXEClient to load and exeucte wdsnbp.com prior to loading and executing pxeboot.com. In fact, we're pretty sure that WDSNBP sends the DHCP request that causes the server to send the ACK with boot\x86\pxeboot.com as DHCP option 67.

Capture of working boot session.

So here are the DHCP settings to define in order to run WDS with a pre-existing DHCP infrastructure.

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
  

Limitations
We're pretty sure that we're losing functionality doing this. Our setup launches TFTP right after the first DHCP transaction -- skipping a request/ACK. (this is what DHCP option 43 accomplishes). It appears that the DHCP request/ACK that we're skipping might be the packet that tells the WDS server which architecture the client is running (x86, x64, ia64).

Capture of original WDS+DHCP transactions

Knowledge
We don't know much about WDS and how its innards function -- we're learning while experimenting. This, most definitely, leads to some dead-ends with respect to progress. Further, when trying to learn about wdsnbp.com, we found Network Bootstrap Program (NBP). However, there isn't a lot of information on exactly what it accomplishes. We assume its some enhanced PXE kernel.

Attention to detail
Because we're barreling through this process, we missed some obvious signs that the change in the filename was the solution. First, the loading dialog on the workstation after it receives an address states its executing WDSNBP.

Contrarily, we assumed that the boot file name (DHCP Option 67) meant something in the first DHCP transaction when WDS and DHCP existed on the same server; this value means nothing in the first DHCP transaction when WDS and DHCP exist on the same server. When we added DHCP Option 43 (PXE subption for mtftp), we instructed our client to immediately download and execute whichever file we specified in DHCP option 67. Apparently this needs to be architecture specific wdsnbp.com.


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

Quote from MS about DHCP & WDS
"Microsoft does not support the use of these options on a DHCP server to redirect PXE clients."

While the PXE developers might not recommend it and Microsoft says the don't support it, we accomplished it (although its architecture specific). Yay.