OSD, PxE, IP helpers, DHCP options – Isn’t there a better way?

OSD, PxE, IP helpers, DHCP options – Isn’t there a better way?

A recent myITForum community discussion posted on the SCCM email list server raised the question of which technique was the best way to get a bare metal PxE booting computer to find a PxE server that could respond to the PxE boot request. Remember, this is a special case boot option where the computer powers up, essentially using the “F12 – Boot to Network” BIOS option, The system is essentially saying to the network “Hey!!! Is there anybody out there with a boot image I can use to get up and running here?” In order to “find” the source of such an image (a PxE server that can respond to this request), some assistance from the routed IP network is needed to locate this special purpose server.
In the community discussion IP Helpers were considered the preferred method, as DHCP Options were unpredictable, not working as expected, and caused erroneous error messages during the PxE boot process. Once IP Helpers were employed, things “just worked. This prompted a survey of the community to determine a general consensus on the subject. This produced some very interesting responses, including the fact that DHCP Options are not recommended, and apparently aren’t supported anyway:
TechNet: Important: Microsoft does not support the use of these options on a DHCP server to redirect PXE clients

Using DHCP Options 60, 66, and 67

If you configure these options, client computers will receive an IP address lease, information about the boot server, and information about the NBP directly from the DHCP server. Clients will not contact the Windows Deployment Services server by using DHCP, but they will download the NBP through Trivial File Transfer Protocol (TFTP) on UDP port 4011. Microsoft does not recommend this method for the following reasons:

  • Using DHCP options is not as reliable as configuring a router. In testing, clients have incorrectly parsed the DHCP options that were returned from the DHCP server and as a result, the client received a “TFTP Failed” error message. Generally, this problem occurs when the PXE ROM ignores the boot server host name and attempts to download the NBP directly from the DHCP server.
  • If there are multiple Windows Deployment Services servers available to service client requests, specifying a specific server may prevent load-balancing. In contrast, using router forwarding tables you can forward the request to multiple servers.
  • Clients may be directed to a Windows Deployment Services server that is not available. Because the client does not have to contact a Windows Deployment Services 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 Windows Deployment Services server’s answer settings.

Further, one cannot do UEFI or BIOS based PxE booting when using DHCP Options. Regardless, it really doesn’t come down to Microsoft’s support stance, but really comes down to the Network Interface Card (NIC) and what or how the manufacturer implements this process (or not). If the NIC does the wrong thing, it is very difficult to troubleshoot the problem.
Using IP Helpers you can monitor the network traffic to determine where things may be going wrong. It is no longer a function of the NIC. Things just generally “work” better. Furthermore, it is also important to consider BIOS updates as there are often updates to the PxE boot code in them
Then there is this reference that further talks to managing network boot program options:
Furthermore, getting all of this to come together properly in some environments you may well find that you will need to meddle with configuring layer 3 switches, or your routers themselves. Add to all of this the simple fact that you need any number of remote PxE servers out in the wild to support this capability in those remote offices and you get a good idea of the cost and hassle related to implementing and managing this capability.

Confused yet?

Well don’t be. There is a better and far simpler! way!
You may already know that 1E Nomad is the proven standard for moving systems management data of all kinds and sizes in an SCCM environment across any size of the wide-area-network with no impact to business traffic. It does this using its patented Reverse-QoSTM technology. There are a significant number of features and capabilities in this product, but this post will focus on just one.
So what’s Nomad got to do with this OSD and PxE boot scenario and all the IP related fussing about to get it working? Simple, really – Nomad also includes PXE Everywhere (formerly known as PXE Lite)! This is a simple client agent installation that allows the SCCM Administrator to forget about PxE servers and all that cost and confusion entirely. You now have the capability of a traditional PxE server, but delivered via by one or more existing end-user computers on each desired subnet throughout the entire estate. This is accomplished without the need for any IP configuration at all: no IP Helpers; no router configuration; no switch configuration. Simply install the Nomad tools extension on your Configuration Manager server, and configure the Nomad OSD integration components. Then Install the PXE Everywhere Central service and related PXE Everywhere client agents where desired. Now simply plug in the bare metal computer and power it up. The PxE boot request is “seen” by the local PXE Everywhere computer. A quick check by that PXE Everywhere machine to the corresponding PXE Central IIS service for authentication and image determination, and JOB DONE. You now have a PxE boot capability everywhere you need it, and have the added benefit of having the Nomad product to get the content where you need it without impacting the WAN as an added bonus.
The bottom line here is really simple. With 1E Nomad and its PXE Everywhere feature you have a serious OSD and software distribution capability, fully integrated with Configuration Manager with no added infrastructure, no kernel level device drivers, no JAVA dependencies, leveraging industry standard networking protocols, and you’ve eliminated the need for any traditional PxE servers and all the related IP configuration work needed to get it working. All of this is pretty slick technology, and we’ve not even scratched the surface of the native Nomad capabilities at all! That’s a topic that’s already been addressed extensively here on the 1E blog by people far smarter than me. Hopefully this little note will help clear away the fog of IP configuration confusion.
By the way, if you are reading this blog then you really should be on that myITForum list server referenced above! It is a real community-driven gold mine of information for the SCCM Administrator! I hope you found this blog useful. It’s been far too long since my last post, but I intend to be much more active here in the coming months, so stay tuned!


Digital Employee Experience (DEX) in the Enterprise: Progress, Patterns, and Gaps

DEX Report