SCCM PXE Network Boot Process

Architecture detection using wdsnbp

A SCCM PXE-Handshake with architecture detection uses an additional step. Before sending the final bootstrap file, the SCCM server sends out a bootstrap file which has an included architecture detection. The file is called „wdsnbp.com“. This is necessary, because the architecture information provided by the smbios is not very reliable. The wdsnbp bootstrap file sends back a DHCP request reply which contains an additional DHCP option 250. This high option is normally not used by other tools and contains information concerning the architecture of the client system.

Client pre-boot check and bootfile check

Right after the first contact of the client, die SCCM server checks for the necessary bootfiles. If the bootfiles are not present in the boot-directory (normally Remoteinstall\SMSboot), the server will not send out a DHCP offer. Since the bootfiles are extracted of the WinPE wim files during the startup of the WDS service, you should make sure, that only WinPE WIM files are stored within the SMSPXEIMAGES$ share and not full-os WIM files.

Secondarily the SCCM server checks whether the client exists within the SCCM database. If the client is unknown, the SCCM server will not send out a DHCP offer.

Note, that there has been added an unknown computer support in SCCM 2007 R2:

About Unknown Computer Support for Operating System Deployment

https://technet.microsoft.com/en-us/library/cc431374.aspx

The check of the client can be surveilled within the smspxe.log. Important are the stored procedures „lookupdevice“ and „getbootaction“ The first one checks, whether the client is known while the second one checks, what boot-file should be sent:

· Pxeboot.com (user has to press F12 to proceed – optional Advertisement)
· Pxeboot.n12 (TFTP download starts instantly - mandatory Advertisement)
· Abortpxe.com (stops the PXE Boot)

A SCCM PXE-DHCP handshake looks like that:

DHCP and PXE service run on different machines)

DHCP Discover
· Client broadcast asking for IP address and PXE-capable DHCP service
· DHCP discover package contains option 60
· DHCP discover uses port 67 UDP

SCCM site check
· SCCM server checks, whether client is known (lookupdevice)

DHCP Offer
· Reply of the DHCP server containing IP address offering on port 68 UDP
· Reply of the DHCP or PXE server containing option 60

DHCP Request
· Client broadcast, ready to acknowledge IP address and boot server (port 67 UDP)

DHCP Ack
· Server broadcast, acknowledge clients IP address and lease (port 68 UDP)

DHCP Request
· Client unicast request for options 66 (boot server) and option 67 (boot file) (port 4011 UDP)
· Unicast addresses server which offered option 60

DHCP Ack
· Server ack from PXE server including options 66 and 67 (send WDSNBP)
Start of the bootstrap file “wdsnbp” download using TFTP (UDP 69 and UDP highlevel ports)

DHCP Request
· Client unicast request for options 66 (boot server) and option 67 (boot file) (port 4011 UDP)
· Unicast addresses server which offered option 60
· Contains option 250 with architecture

SCCM site server check
· SCCM server checks for current boot action (getbootaction)

DHCP Ack
· Server ack from PXE server including options 66 and 67 (send pxeboot.n12 for example)

TFTP download of bootfile
TFTP download of WinPE

Screenshot of a sample boot:

Comments

• Anonymous
  January 01, 2003
  In a standard configuration you won't be spefifying any file at all. And you should not configure any boot server. You should rather specify DHCP helper adresses on your gateways. Thus, the client can find the SCCM server themselves and negotiate the correct bootstrap file.

• Anonymous
  January 01, 2003
  Exactly as mentioned before. You need to have 1433 open on your FW.

• Anonymous
  January 01, 2003
  Good Post. Thank you

• Anonymous
  June 20, 2011
  Do you need to configure the DHCP scope with option 60 to get this working?

• Anonymous
  September 08, 2011
  Only if WDS and DHCP server reside on the same machine.

• Anonymous
  October 04, 2011
  The comment has been removed

• Anonymous
  October 04, 2011
  Yes, it does. As you say on def port 1433

• Anonymous
  October 05, 2011
  SCCM site check · SCCM server checks, whether client is known (lookupdevice) If PXE is installed on a Secondary Site Server, when the "SCCM Server checks, whether client is known" does it verify directly against the SCCM database or does it forward the request to the Primary and then the Primary site verifies that the clients is "known"..   In otherwords, to use PXE at a secondary site would you have to open 1433 on the firewall and allow the secondary site direct access to the SQL database?

• Anonymous
  October 31, 2011
  currently im getting the following error: PXE-T01: The specified file was not found PXE-E3b: TFTP Error- File Not found PXE-M0F: Exiting Intel PXE ROM. I think may have the wrong file specified by DHCP. currently I'm telling it to give out "pxeboot.com". It doesn't specify the exact path. Our DHCP server is running solaris. Is that the correct file that I should be specifying? Do I need to put the path? If yes what would that path be? I've post this on ms-connect site and nobdy there is responding.

• Anonymous
  September 14, 2012
  What if everything goes well, until it tries to download the pxeboot.n12 file, and all it does is this: TFTP Download:  smsbootx64pxeboot.n12 . TFTP Download:  smsbootx64pxeboot.n12 . TFTP Download:  smsbootx64pxeboot.n12 . over and over, and it never downloads.

• Anonymous
  October 08, 2012
  What if the DHCP Option 250 is missing from the DHCP Request going to the SCCM PXE SP? What could be the reason for this? We currently have this issue at one location. The SCCM PXE SP is used successfully at other locations as well as the client. Any help is appreciated....

• Anonymous
  April 26, 2013
  The comment has been removed

• Anonymous
  July 08, 2013
  The comment has been removed

• Anonymous
  April 03, 2014
  Start WDS Service again.....