Friday, June 27, 2008

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.

5 comments:

Jason Koppe said...

I forgot to mention that we decoded the value for DHCP Option 43 mtftp. The PXE Specification tells us that the mtftp IP suboption code 1 is 4 bytes. So "010400000000FF" stands for option one, four byte length, and 0.0.0.0, and the terminator.

gregswallow said...

wdsnbp.com is a "special-case" Network Boot Program that handles platform detection and "network boot referral," or the use of DHCP options 66/67. The idea is that WDS's PXE provider will provide different answers according to architecture, serving out ia64-based EFI files, or x86/x64 NBPs. Microsoft has pretty awesome documentation here:

http://go.microsoft.com/fwlink/?LinkId=81031.

I'm still trying to make sense of this, myself so take my comments with a grain of salt.

Jason Koppe said...

Thanks Greg! Tom will be delivering more WDS information in an upcoming post; stay tuned.

sebus said...

Any more of the same, but with UEFI boot?

Sunil Veigas said...

Apologies if I have missed anything here.

Basically i have setup a new WDS Server and have configured all the boot imaages. We have DHCP and WDS on two different servers. As stated above I have configured DHCP scope options as 66 and 67 for x64 architecture. My clients still cannot connect inspite of trying in the same vlan where the scope is defined.