PXE booting with WDS – DHCP Scope vs IP Helpers

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:

  1. Configuring routers to forward broadcasts (Setting Up IP Helpers)
  2. 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
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:

List of NBPs for WDS

WDS List of NBPs

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.

Additional Reading

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

24 Responses

  1. Rod MacPherson says:

    You said “However, the DHCP option method is generally not preferred as its limits your client’s ability to negotiate with the WDS server about what NBP would be best utilized. You must also choose between traditional 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.” but you ignore the restriction that if your IP helpers point back to the WDS server as a DHCP server you have to manage all of your DHCP at the WDS, and make your WDS a single point of failure for DHCP (unless you are running WDS on multiple servers that are now going to be your DHCP servers) If there is no performance advantage to loading the x64 NBP, then why should we care if it loads the 32 bit NBP? Either NBP is capable of deploying either 32 or 64 bit images.

    Also you quote Microsoft saying that if the WDS server is down DHCP could point to a server that is not available, but in your preferred set-up that’s not an issue because the client never even gets an address because it’s DHCP server (the WDS) is not available, so that affects not just the PXE booting clients, but all DHCP clients on the network.

    Of course what Microsoft probably intended is that all of your DHCP servers will be Microsoft DHCP servers running WDS. This, of course would be the best overall solution.

    • Jake says:

      You make a good point that if you are running the WDS service on a single DHCP server that there is a single point of failure regardless of IP Helper vs DHCP option configurations.

      If there is no performance advantage to loading the x64 NBP, then why should we care if it loads the 32 bit NBP? Either NBP is capable of deploying either 32 or 64 bit images.

      For performance reasons, I don’t think you should care. Both x64 NBP and 32-bit NBP deployed images at the same rate in my tests. However, some NBP’s can only deploy to traditional BIOS’s and others can deploy to EFI/UEFI. If your environment is like mine and you are getting new equipment in that has modern EFI/UEFI bios setups than it suddenly becomes very important to ensure that your devices are receiving a compatible NBP. In order to do that, IP Helpers allow the WDS Service to make the best decision about which NBP your device will utilize.

  2. Anders M says:

    Nice post. Thanks for clarifying. Especially the part about BIOS/EFI and autonegotiation.

  3. Graham says:

    Before using the DHCP options try instead disabling NetBios over TCPIP on the WDS Server.

    ( Netbios over TCP/IP is switched off on the NIC(s) (WINS tab, IPv4 properties) on the WDS server! )

    This causes the NbtNS (Netbios name search) broadcasts on port 137 to cease and the TFTP on port 4011 to reply promptly.

    This makes UEFI PXE booting work for empty Hyper-V Generation 2 VMs as well as for physical clients.

    • thanks@gmail.com says:

      Graham, you’re the man. Thank you so much!

    • SDE Tech says:

      Wow… This actually worked for me. I could never get UEFI clients to PXE boot and all this stuff about DHCP Options and IP helpers confused me more than anything else. Then I turned NETBIOS off and BOOM everything works perfectly.

    • Zip says:

      Spent the best part of a day or so trying to get to the bottom of this. Disabling netbios over tcpip did the trick. Thank you so much!

    • Andrew says:

      Pure awesomeness, I can go to bed a happy man.

    • Paulus vO says:

      When working with IP helper addresses, configured on the switches, communicating the IP addresses of both the DHCP server(s) and a separate WDS server, make sure to “enable” the DHCP responses on the WDS server by doing the following:
      In WDS, r-click on the WDS server, and open up Properties.
      1) in tab [DHCP]: remove the tick for “Do not listen on DHCP ports”. Also the other option “Configure DHCP options to indicate that this is also a PXE server” has to stay unticked. We are NOT using any DHCP option 60, 66 or 67 anywhere ! By using the configuration of the IP-helpers on the switch, both servers will receive all DHCP packages sent from the clients, and will respond to only their part of the communication.
      2) in tab [PXE Response] : select “Respond to all client computers (known and unknown). I kept “Require administrator approval etc” unticked.

      If you only deal with x64 machines, which are configured in ‘UEFI’ mode (and why not also in ‘Secure Boot’), you may or may not specify in tab [Boot] the boot image at both “x64 architecture” and “x64 (UEFI) architecture” pointing to Boot\x64\Images\LiteTouchPE_x64.wim”.
      However, the config of the boot files and etc is extensively covered on various threads and movies.
      I could nowhere find an explicit mentioning of the WDS config on PXE responses, in case the IP helper feature is used, so that’s why I am adding this bit of info.

  4. Mark says:

    Hi I’m trying setup WDS server

    On Windows 2012 Server I’ve enabled WDS feature, also done base server configuration. DHCP server seat on different server.
    I need setup DHCP server for PXE boot. In DHCP under Scope Options I need setup options as below:

    Port 66 – ‘Boot Server Host Name’ to the IP address of my WDS Server x.x.x.x
    Port 67 – ‘Bootfile Name’ to the following path ‘Boot\x64\wdsnbp.com

    Problem is because those ports already in use for Citrix environment to publish Desktops.
    May I use different ports to do this, and setup for my WDS server alongside of settings already setup for 66, 67 ports? How I should do this?
    I need suggestions how I suppose to setup this DHCP server to make it working on both environments?
    Thank you for any suggestions.


  5. Tom says:

    Hi There,

    How can I configure IP Helper on home Modem Router?

    Would you be able to do that?

    Please advise.


    • Jake says:

      Hi Tom,

      Really depends on the model of your router.
      Most likely though, if its a typical consumer model – you will not be able to configure an IP Helper.

      • Tom says:

        Hi Jake,

        Thanks for the reply, my modem router is

        X4s Netgear Nighthawk AC2400

        I was hoping this would do IP Helping i googled it and i couldnt find anything on it, but when i spoke to a network consultant he advised that this can be possible but i never got to see him again.

  6. Alberto says:

    Thanks so much for your tutorial, it is super interesting !
    Please, do you think that dhcp config will work with my WDS, if I dont define the option 67? This way the pxe boot will get the most suitable image… what do you think? Thanks.


  7. Jason says:

    Does this article assume that the DHCP services are on the WDS server? We deploy DHCP through our Cisco switches on our imaging VLANs so no need to redirect to a DHCP server but of course we want IP helper to redirect the PXE services to our Windows Deployment server which has to be on a separate VLAN. If necessary I can setup DHCP on the WDS just for the one imaging subnet.

  8. sebus says:

    DHCP only setup does not seem to work for UEFI PXE boot. Legacy Bios PXE is fine. UEFI seems to insist on ProxyDHCP & takes no notice of DHCP configured options 60/66/67. And WDS for x64 UEFI will always send only smsboot\x64\wdmgfw.efi (which is NOT what I want, as I need it to do iPXE)

  9. Selashi says:

    Please also check which is the DHCP snooping configuration on your switch, it may be preventing the PXE booting to correctly work

  10. Tony says:

    Great post! Can you get the network configuration from your network team and post it? That would be really helpful!

  11. Pejpr says:


    Please, tell me, is there some possibility to make SCCM for only boot via PXE – just BOOT, no install after booting? I have image with rescue system made by McAfee and I need just boot from it 😉

    Thank you very much for some reply 😉

  1. September 15, 2014

    […] Because our WDS is a stand-alone server (that is the infrastructure is hosted elsewhere) we can leave both of the buttons here unchecked and move on; if you have DHCP installed on the WDS server then you’ll need to tell the WDS server not to listen on port 67 for incoming PXE boot requests and add DHCP option 60 to advertise that it is also a PXE server. You can read more about this, along with some interesting stuff on ip helpers here. […]

  2. February 29, 2016
  3. March 9, 2016

Leave a Reply

Your email address will not be published. Required fields are marked *