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.
MBischAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

smckeown777Commented:
What happens after it gets the IP? Can you provide screenshot of what you see?

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?
0
MBischAuthor Commented:
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
screen cap
0
smckeown777Commented:
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?
0
10 Tips to Protect Your Business from Ransomware

Did you know that ransomware is the most widespread, destructive malware in the world today? It accounts for 39% of all security breaches, with ransomware gangsters projected to make $11.5B in profits from online extortion by 2019.

vivigattCommented:
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:
http://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
0
MBischAuthor Commented:
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
0
vivigattCommented:
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...
0
MBischAuthor Commented:
I have installed the latest BIOS version and brought it up to A10.
Still showing the same behavior.
0
MBischAuthor Commented:
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
0
vivigattCommented:
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)
0
MBischAuthor Commented:
I am out of the office this week for Exchange 2013 training and will do this testing when I return.
Thanks
0
MBischAuthor Commented:
Here is the packet capture between the client and WDS Server.
01TFPTcapture.txt
0
vivigattCommented:
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.
0
MBischAuthor Commented:
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
0
vivigattCommented:
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...
0
vivigattCommented:
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"
0
vivigattCommented:
.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
0
MBischAuthor Commented:
I've requested that this question be deleted for the following reason:

delete question
0
smckeown777Commented:
Why is this being deleted?
0
smckeown777Commented:
@vivigatt's comment - http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Q_28256097.html#a39571453

Seems to be the closest to an answer after his analysis of the wireshark capture...I'd assign points to that if the OP doesn't want to participate anymore at this point...
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Legacy OS

From novice to tech pro — start learning today.