none
WDS on W2K8R2, Clients give PXE-E32 "TFTP open timeout"

    General discussion

  • Server 1: Server 2K8R2, roles: AD, DNS, File, Print, IIS, WDS

    Server 2: Server 2K3R2, roles: AD, DNS, File, App, DHCP

    The servers exist on separate subnets. Our WDS services have been working in the current configuration for the past 18 months. A few weeks ago we began getting TFTP errors on boot from our clients when PXE booting. The client pulls an IP from DHCP from the correct scope, which is acknowledged in the event log for both DHCP and WDS. The client then fails with a PXE-E32 error "TFTP open timeout" (and from time to time "TFTP cannot read", but 90% of the time it's a timeout), acknowledged in WDS Admin event log as Event 4101 Error 1460, TFTP failed.

    The issue does not appear to be limited to a specific hardware or boot agent and has been seen on previously known working hardware and boot agents.

    This event is intermittent. It will fail consistently for a period of time, then resolve itself and allow connections with no hangups. 

    I am at a loss. I have just moved from a technician to junior admin role and appear to be spinning my wheels at this point. Here are the steps I've taken to troubleshoot and resolve:

    • Confirm DHCP and WDS not on same server = Confirmed

    • Test with DHCP Options 66, 67 in place and without anyway (conflicting white papers and anecdotal on this, didn't affect either way) = Confirmed

    • Verify boot.wim correct for architecture = YES, both x86 and x64

    • Verify ports available to WDS: UDP - 67, 68, 69, 4011, TCP - 135, 137, 138, 139, 5040 = Verified with telnet

    • Microsoft KB 977512 - Broaden UDP Port listening range from 64000-65000 to 50000-65000, applied

    • Microsoft KB 2673007 - Bad Vendor info, applied

    • Microsoft KB 975710 - TFTP block size too large, applied

    The Admin and Operational log for WDS does not appear to be very detailed where this error is concerned. I've tried to perform due diligence in researching a solution before requesting assistance - Any help appreciated!

    EDIT: I came across KB936625 to enable additional "trace" logging that should contain more verbose detail on the TFPT provider, however enabling trace logging and then setting the disable flag to 0 for disable logging in the TFTP key, no log was generated in %windir%\Tracing\wdsserver.log - maybe I performed this task incorrectly?

    FINAL EDIT: For anyone else dealing with this, I think I've found the culprit and it's a pretty rookie error born out of bad communication and poorly documented change management. The DHCP role on the server is a new one that was added in the past few months after the primary DHCP service failed on another server. When this new role was built out, EXCLUSIONS were not made for existing infrastructure sitting within the DHCP scopes. In short, DHCP was giving out addresses in the lower part of the scope which we had reserved for switches and a few other static devices. The symptom was on again off again because, as we cycled in new laptops to try, new IPs were issued to the unique adapters trying t oconnect. Once they got into the range no longer being used by infrastructure, they were able to connect to TFTP without issue.

    Thursday, October 10, 2013 4:10 PM

All replies


  • FINAL EDIT: For anyone else dealing with this, I think I've found the culprit and it's a pretty rookie error born out of bad communication and poorly documented change management. The DHCP role on the server is a new one that was added in the past few months after the primary DHCP service failed on another server. When this new role was built out, EXCLUSIONS were not made for existing infrastructure sitting within the DHCP scopes. In short, DHCP was giving out addresses in the lower part of the scope which we had reserved for switches and a few other static devices. The symptom was on again off again because, as we cycled in new laptops to try, new IPs were issued to the unique adapters trying t oconnect. Once they got into the range no longer being used by infrastructure, they were able to connect to TFTP without issue.

    -FCOE_Tech

    FCOE_Tech

    Thanks for sharing the information.


    Regards, Santosh

    I do not represent the organisation I work for, all the opinions expressed here, are my own and posted AS IS.

    Friday, October 11, 2013 3:33 AM