Share via

Issue with PXE boot

Pickering, Billy 0 Reputation points
2026-02-13T16:02:16.42+00:00

I have a WDS server running separate of DHCP on Server 2019 that I am only using the PXE portion so it will boot into another product to image the PCs on our network. Everything has been working fine, but recently I have started having an issue where it contacts the DHCP server, gets an IP then goes to Downloading NBP file... and just stops, pegs the network card out and proceeds no further.

The NBP filename is boot\x64\wdsmgfw.efi

I had it work once this morning, then the second machine I tried did this. I rebooted the server; it worked once then stopped again on the same model machine. I cannot find any information as most I have seen says they get the file downloaded successfully but doesn't proceed from there.

I have the TFTP settings set to 0 as suggested and i'm at a total loss on what has happened.

Windows for business | Windows Server | Devices and deployment | Other
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Harry Phan 15,905 Reputation points Independent Advisor
    2026-02-13T16:16:45.9033333+00:00

    Hi Billy, this behavior usually indicates a TFTP transfer stall rather than a DHCP or PXE misconfiguration. Since the client receives an IP and identifies the NBP file, the handoff from DHCP to WDS is working. What’s failing is the actual transfer of boot\x64\wdsmgfw.efi. On Server 2019, this is often caused by a corrupted or mismatched boot image in the WDS store, or by NIC driver issues on the client side.

    Well now you need to clear and regenerate the boot images by removing and re‑adding them in the WDS console, ensuring they match the architecture. Then confirm that the WDS service is bound to the correct NIC and that UDP port 69 (TFTP) and the ephemeral ports are not being filtered by firewalls or network appliances. If the transfer pegs the NIC and stalls, it can also be a sign of MTU mismatch; try forcing the TFTP block size to 1456 in the WDS server registry under HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSTFTP\ReadSize. Finally, test with a different hardware model to rule out client NIC firmware issues. If the problem persists intermittently, you may need to patch Server 2019 to the latest cumulative update, as several PXE/TFTP fixes were included post‑release.

    0 comments
  2. Q&A Assist
    2026-02-13T16:02:30.72+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    It sounds like you're experiencing issues with the PXE boot process, specifically with the downloading of the Network Boot Program (NBP) file. Here are a few troubleshooting steps and considerations that may help resolve the issue:

    1. Check DHCP Options: Since your WDS server is separate from the DHCP server, ensure that DHCP options 60, 66, and 67 are not configured on the DHCP server. These options can interfere with the PXE boot process when the servers are not co-hosted. Only DHCP Option 60 is needed if DHCP and WDS are on the same server.
    2. Verify IP Helpers: If the WDS server and the client machines are on different subnets, ensure that IP Helpers are correctly configured on your routers. This is crucial for forwarding PXE requests across subnets.
    3. TFTP Settings: You mentioned that TFTP settings are set to 0. Ensure that the TFTP service is properly configured and that the timeout settings are appropriate. Sometimes, increasing the timeout can help if the network is slow.
    4. Network Traffic: Since you mentioned that the network card is pegged out, monitor the network traffic to see if there are any unusual spikes or issues that could be causing the slowdown. This might indicate a network congestion issue or a problem with the TFTP server.
    5. Logs and Errors: Check the event logs on the WDS server for any errors or warnings that might give more insight into why the NBP file is not downloading successfully. Look for any specific error codes that could indicate a problem.
    6. Test with Different Clients: If possible, try booting different models or configurations of client machines to see if the issue is isolated to a specific type of machine or if it is more widespread.

    If the problem persists after these checks, consider reviewing the WDS configuration or consulting with your network administrator for further assistance.

    References:

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.