Windows Deployment Server TFPT error PXE-E32 open Timeout
We have been running WDS for some time now using Dell hardware.
We recently received a batch of Optiplex 3010 computers and cannot get them to bot the the WDS.
It picks up an IP from the DHCP server, but we can't get it to connect to the WDS server.
If we connect a previous Dell model it immediately connects to the WDS server.
WDS and DHCP are on separate servers, but on the same LAN.
I have tried changing the UDP port policy in the registry.
I have tried changing the network driver that is used on the Dell 3010.
I have broaden the port range of WDS server.
I am at a loss of what troubleshooting step to do next.
Thanks in advance for your help.
We recently received a batch of Optiplex 3010 computers and cannot get them to bot the the WDS.
It picks up an IP from the DHCP server, but we can't get it to connect to the WDS server.
If we connect a previous Dell model it immediately connects to the WDS server.
WDS and DHCP are on separate servers, but on the same LAN.
I have tried changing the UDP port policy in the registry.
I have tried changing the network driver that is used on the Dell 3010.
I have broaden the port range of WDS server.
I am at a loss of what troubleshooting step to do next.
Thanks in advance for your help.
ASKER
Immediately after it gets the IP address, it says TFPT for a moment and has a few dots as it progresses.
We then get the PXE-E32 Open timeout error.
Then it goes through the TFPT connection attempt again and we get the following errors.
We have tried multiple versions of the network driver as shown below...
Realtek 5.788.613.2011
Realtek 7.46.610.2011
Realtek 7.67.1226.2013
Realtek 7.69.304.2013
thank you
We then get the PXE-E32 Open timeout error.
Then it goes through the TFPT connection attempt again and we get the following errors.
We have tried multiple versions of the network driver as shown below...
Realtek 5.788.613.2011
Realtek 7.46.610.2011
Realtek 7.67.1226.2013
Realtek 7.69.304.2013
thank you
We are using one of those drivers...
Realtek 7.46.610.2011
I'll assume you know WDS well yes? Going to ask the stupid question anyways...
When you added the driver did you update the deployment share and update the boot image?
Can you provide a screenshot of your Deployment Workbench showing the drivers listed?
Realtek 7.46.610.2011
I'll assume you know WDS well yes? Going to ask the stupid question anyways...
When you added the driver did you update the deployment share and update the boot image?
Can you provide a screenshot of your Deployment Workbench showing the drivers listed?
Drivers on the client side are not in use when PXE is in charge.
Try to update the BIOS of the client, it may contain an updated PXE code.
Please also check your DHCP settings, make sure that dhcp option 60 is not set to "PXEClient" for this particular hosts (since your DHCP and PXE/TFTP servers are on separate servers).
Check that you DON'T have any option 66 or 67 set on the DHCP server, since "boot file name" and "tftp-server" (aka "next-server") details are sent by WDS server (which acts as a PXE server in this case)
Check my article below (and the comments) to understand more what happens with DHCP option 60, 66 and 67:
https://www.experts-exchange.com/Networking/Misc/A_2978-PXEClient-what-is-it-for-Can-I-use-PXE-without-it.html
Regarding the error itself
PXE-E32 means that the client tried to connect to a TFTP server (which address was sent to it in DHCP offer messages, sent either by PXE/WDS server, either by DHCP in DHCP option 66 and/or in "Next-Server" field of the DHCP/BOOTP message)
If your client did not receive any dhcpoffer pakets from the WDS server (maybe because it was not authorized, not in a list of clients t to be served etc), it will try to use the DHCP server as its TFTP server. If there is no TFTP server running on the DHCP server, you will get this E32 error.
You can use a packet capture utility, filter on UDP 67, 68 and 69 (DHCP/bootp and TFTP) to see what happens
Try to update the BIOS of the client, it may contain an updated PXE code.
Please also check your DHCP settings, make sure that dhcp option 60 is not set to "PXEClient" for this particular hosts (since your DHCP and PXE/TFTP servers are on separate servers).
Check that you DON'T have any option 66 or 67 set on the DHCP server, since "boot file name" and "tftp-server" (aka "next-server") details are sent by WDS server (which acts as a PXE server in this case)
Check my article below (and the comments) to understand more what happens with DHCP option 60, 66 and 67:
https://www.experts-exchange.com/Networking/Misc/A_2978-PXEClient-what-is-it-for-Can-I-use-PXE-without-it.html
Regarding the error itself
PXE-E32 means that the client tried to connect to a TFTP server (which address was sent to it in DHCP offer messages, sent either by PXE/WDS server, either by DHCP in DHCP option 66 and/or in "Next-Server" field of the DHCP/BOOTP message)
If your client did not receive any dhcpoffer pakets from the WDS server (maybe because it was not authorized, not in a list of clients t to be served etc), it will try to use the DHCP server as its TFTP server. If there is no TFTP server running on the DHCP server, you will get this E32 error.
You can use a packet capture utility, filter on UDP 67, 68 and 69 (DHCP/bootp and TFTP) to see what happens
ASKER
smckeown777, thanks for your comment, but we are not using the deployment workbench. We are using WDS alone. After adding the drivers, the WIM file was updated.
I have mounted the WIM file and have verified that the Realtek 7.46.610.2011 driver is in the WIM file and there is no change to the behavior.
vivigatt, I have just installed Wireshark on the WDS server and will monitor the packets to see if I can determine what is happening.
Thanks
I have mounted the WIM file and have verified that the Realtek 7.46.610.2011 driver is in the WIM file and there is no change to the behavior.
vivigatt, I have just installed Wireshark on the WDS server and will monitor the packets to see if I can determine what is happening.
Thanks
OK.
Nothing you will do to teh WIM image will have any impact on that behavior, since at that point of the boot process, the wim image has not been used in anyway by the client.
It's PXE only !
Remember to check if there is a newer BIOS for your client...
Nothing you will do to teh WIM image will have any impact on that behavior, since at that point of the boot process, the wim image has not been used in anyway by the client.
It's PXE only !
Remember to check if there is a newer BIOS for your client...
ASKER
I have installed the latest BIOS version and brought it up to A10.
Still showing the same behavior.
Still showing the same behavior.
ASKER
It gets more interesting...
I failed to mention...about 2 weeks ago (09/23/2013), we were able to get two of the Dell 3010 computers to successfully boot to the WDS server and get Windows 7 installed.
When these two computers were first trying to connect to the WDS, we had to reboot several times to get the TFTP connection to work.
Interestingly enough, if I place a blank HDD in one of the two computers that has previously connected successfully, the WDS connection and process seems to run very smooth and Windows can be successfully installed.
Any suggestions on where to look next.
I have verified that we have the setting in WDS selected so our server will respond to all known and unknown client computers, so (on the surface) that doesn't appear the be the issue.
Any other suggestions?
Thanks
I failed to mention...about 2 weeks ago (09/23/2013), we were able to get two of the Dell 3010 computers to successfully boot to the WDS server and get Windows 7 installed.
When these two computers were first trying to connect to the WDS, we had to reboot several times to get the TFTP connection to work.
Interestingly enough, if I place a blank HDD in one of the two computers that has previously connected successfully, the WDS connection and process seems to run very smooth and Windows can be successfully installed.
Any suggestions on where to look next.
I have verified that we have the setting in WDS selected so our server will respond to all known and unknown client computers, so (on the surface) that doesn't appear the be the issue.
Any other suggestions?
Thanks
It seems to me that you may have 2 sources of DHCP/PXE messages that are not saying the same thing. If that is the case, one of them is actually directing the client to use a TFTP server that is not the correct one.
And you just can't predict which source will "win" (meaning which source will send the first set of messages that the PXE client can use).
Check the DHCP options as I wrote earlier. If you have option 66 or 67 set, this is a problem.
Also, check what happens on the wire, for UDP 67, 68 and 69 sent to broadcast or from/to your client (you may have to use a monitoring port on the switch on which the client is connected to in order to see the unicast traffic from/to that client)
And you just can't predict which source will "win" (meaning which source will send the first set of messages that the PXE client can use).
Check the DHCP options as I wrote earlier. If you have option 66 or 67 set, this is a problem.
Also, check what happens on the wire, for UDP 67, 68 and 69 sent to broadcast or from/to your client (you may have to use a monitoring port on the switch on which the client is connected to in order to see the unicast traffic from/to that client)
ASKER
I am out of the office this week for Exchange 2013 training and will do this testing when I return.
Thanks
Thanks
ASKER
Here is the packet capture between the client and WDS Server.
01TFPTcapture.txt
01TFPTcapture.txt
I notice that there are messages sent by 192.168.220.95 to 192.168.220.105 on UDP 4011.
UDP 4011 is used ONLY if the DHCP Server and PXE server (WDS Server in your case I presume) are running on the same host.
The PXE client knows that fact because it receives DHCP Option 60 set with "PXEClient".
Try to remove DHCP Option 60 from DHCP server config for the scope 192.168.0.0 and tell us if this is any better.
If not, let me know, I've seen "strange" things in the packets capture (next time, I may use a .cap or .pcap capture file, much better than exporting the capture as a text file). One of these strange things may be related to some firewall on your network (Cisco ASA I would say) not allowing TFTP traffic.
UDP 4011 is used ONLY if the DHCP Server and PXE server (WDS Server in your case I presume) are running on the same host.
The PXE client knows that fact because it receives DHCP Option 60 set with "PXEClient".
Try to remove DHCP Option 60 from DHCP server config for the scope 192.168.0.0 and tell us if this is any better.
If not, let me know, I've seen "strange" things in the packets capture (next time, I may use a .cap or .pcap capture file, much better than exporting the capture as a text file). One of these strange things may be related to some firewall on your network (Cisco ASA I would say) not allowing TFTP traffic.
ASKER
DHCP option 60 is not set because our WDS and DCHP servers are on separate hardware.
I tried to upload the PCAP file, but it was not an approved extension type.
I have included the PCAP file with a .txt extension. Just rename it with PCAP as the extension.
01TFPTcapture--2-.txt
I tried to upload the PCAP file, but it was not an approved extension type.
I have included the PCAP file with a .txt extension. Just rename it with PCAP as the extension.
01TFPTcapture--2-.txt
Before I investigate the pcap file...
192.168.220.95 is a "client"
192.168.220.105 is a "server". If this is not "THE SERVER", this particular host may actually be running a DHCP service (rogue?) that answers with DHCP Option 60 set. Since 192.168.220.95 sends dhcp requests to 192.168.220.105 on UDP 4011, it does mean that 192.168.220.105 did answer DHCP discover messages sent by 192.168.220.95 and in said answers, DHCP option 60 is set. There is no alternative...
192.168.220.95 is a "client"
192.168.220.105 is a "server". If this is not "THE SERVER", this particular host may actually be running a DHCP service (rogue?) that answers with DHCP Option 60 set. Since 192.168.220.95 sends dhcp requests to 192.168.220.105 on UDP 4011, it does mean that 192.168.220.105 did answer DHCP discover messages sent by 192.168.220.95 and in said answers, DHCP option 60 is set. There is no alternative...
My guess is confirmed inspecting the pcap file.
Check the 3rd frame. It is an answer from .105 and it contains DHCP option 60 filled with "PXEClient"
Check the 3rd frame. It is an answer from .105 and it contains DHCP option 60 filled with "PXEClient"
.105 is named "SCCM". It seems to be running a DHCP service... And it does expect the clients to send PXE/DHCP requests to UDP 4011.
Something else: TFTP seems not to be allowed by your Cisco ASA which prevents clients from receiving TFTP traffic on UDP 2070 (which was the port that the client used to send the TFTP read request to TFTP server and that the TFTP server used to answer to: check frame 8 for instance, the server gets an ICMP Port Unreachable apparently from .95 but actually sent by a Cisco device (the source Mac Address is now the one of a Cisco device)
Last but not the least: The capture is incomplete, I can't see the DHCPDISCOVER messages that begin the DHCP/PXE dialog
Something else: TFTP seems not to be allowed by your Cisco ASA which prevents clients from receiving TFTP traffic on UDP 2070 (which was the port that the client used to send the TFTP read request to TFTP server and that the TFTP server used to answer to: check frame 8 for instance, the server gets an ICMP Port Unreachable apparently from .95 but actually sent by a Cisco device (the source Mac Address is now the one of a Cisco device)
Last but not the least: The capture is incomplete, I can't see the DHCPDISCOVER messages that begin the DHCP/PXE dialog
ASKER
I've requested that this question be deleted for the following reason:
delete question
delete question
Why is this being deleted?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I've done a 3010 with WDS recently and no issues - but I think I had to add the latest driver from their site - which driver did you add to the boot image?