SCCM 2012 - PXE-E32: TFTP Open timeout (Network Steve Forum)

SCCM 2012 - PXE-E32: TFTP Open timeout

When I trying deploy through PXE in the vmware workstation 10.0, I'm getting the error below

Error: PXE-E32: TFTP Open timeout
TFTP....

The machine got the IP addresss and I'm stop in below error

Client MAc ADDR: 00 0C 29 6C 3F   GUID: xxxxxxxxxxxxxxx
Client IP : 192.168.100.15    MASK: 255.255.255.0   DHCP IP : 192.168.100.254
GATEWAY IP: 192.168.100.1     192.168.100.2
PXE-E32: TFTP Open timeout
TF

October 24th, 2013 12:22am

more details regarding the error

Free Windows Admin Tool Kit Click here and download it now

October 24th, 2013 12:30am

The "PXE-E32" error indicates that the PXE did not get a reply from the TFTP server when sending a request to download its boot file.

Has this ever worked using this method? Have you configured IP Helper (or DHCP scope options if necessary) so that the WDS server can be located?

October 24th, 2013 1:51am

does the PXE boot work with a physical machine?

did you include VMWare workstation drivers in your bootimage?

are you using DHCP options or IP helpers?

Free Windows Admin Tool Kit Click here and download it now

October 24th, 2013 1:53am

Do you see the MAC address of the VM in smspxe.log on the PXE-enabled DP?

October 24th, 2013 3:33am

The Physical machine is working fine , but booting from VMware workstation is NOT working ?

Please advise

Free Windows Admin Tool Kit Click here and download it now

October 27th, 2013 2:40am

Do you see the MAC address of the VM in smspxe.log on the PXE-enable

October 27th, 2013 4:58am

I'm getting this error in the SMS PXE logs " device is not in the database" and "device is in the database" . Even the device in the database I'm getting the same error

step that I did:

a. Manually Adding the Device the MAC

b. Manually Adding the Device the MAC and the GUID

c. Advertise in the "Uknown Computer" and Advsertise in the "TEST Collection" where I added the MAC address and gUID

Please find below the error

<![LOG[Begin validation of Certificate [Thumbprint 9733001C4F488EE84A86A2DC81479F7D3262A9C3] issued to '8d4012f3-7252-4e85-891a-b4ff4421a1e4']LOG]!><time="07:48:03.370-240" date="10-28-2013" component="SMSPXE" context="" type="1" thread="5608" file="ccmcert.cpp:1245">
<![LOG[Completed validation of Certificate [Thumbprint 9733001C4F488EE84A86A2DC81479F7D3262A9C3] issued to '8d4012f3-7252-4e85-891a-b4ff4421a1e4']LOG]!><time="07:48:03.370-240" date="10-28-2013" component="SMSPXE" context="" type="1" thread="5608" file="ccmcert.cpp:1386">
<![LOG[Client lookup reply: <ClientIDReply><Identification Unknown="0" ItemKey="0" ServerName="" ServerRemoteName=""><Machine><ClientID/><NetbiosName/></Machine></Identification></ClientIDReply>
]LOG]!><time="08:11:12.534-240" date="10-28-2013" component="SMSPXE" context="" type="1" thread="4100" file="libsmsmessaging.cpp:6363">
<![LOG[00:0C:29:6C:3F:1D, 08544D56-DCF7-D4D5-D1CC-409FCF6C3F1D: device is not in the database.]LOG]!><time="08:11:12.534-240" date="10-28-2013" component="SMSPXE" context="" type="1" thread="4100" file="database.cpp:483">
<![LOG[Client lookup reply: <ClientIDReply><Identification Unknown="0" ItemKey="16777335" ServerName="" ServerRemoteName=""><Machine><ClientID/><NetbiosName/></Machine></Identification></ClientIDReply>
]LOG]!><time="08:20:49.266-240" date="10-28-2013" component="SMSPXE" context="" type="1" thread="4100" file="libsmsmessaging.cpp:6363">
<![LOG[00:15:B7:D2:86:F0, 80222D0B-0F4C-DC11-8052-B05987052608: device is in the database.]LOG]!><time="08:20:49.266-240" date="10-28-2013" component="SMSPXE" context="" type="1" thread="4100" file="database.cpp:483">
<![LOG[Client boot action reply: <ClientIDReply><Identification Unknown="0" ItemKey="16777335" ServerName="" ServerRemoteName=""><Machine><ClientID/><NetbiosName/></Machine></Identification><PXEBootAction LastPXEAdvertisementID="" LastPXEAdvertisementTime="" OfferID="" OfferIDTime="" PkgID="" PackageVersion="" PackagePath="" BootImageID="" Mandatory=""/></ClientIDReply>
]LOG]!><time="08:20:49.438-240" date="10-28-2013" component="SMSPXE" context="" type="1" thread="4100" file="libsmsmessaging.cpp:6561">
<![LOG[00:15:B7:D2:86:F0, 80222D0B-0F4C-DC11-8052-B05987052608: no advertisements found]LOG]!><time="08:20:49.438-240" date="10-28-2013" component="SMSPXE" context="" type="1" thread="4100" file="database.cpp:483">
<![LOG[Begin validation of Certificate [Thumbprint 9733001C4F488EE84A86A2DC81479F7D3262A9C3] issued to '8d4012f3-7252-4e85-891a-b4ff4421a1e4']LOG]!><time="08:48:03.366-240" date="10-28-2013" component="SMSPXE" context="" type="1" thread="7916" file="ccmcert.cpp:1245">
<![LOG[Completed validation of Certificate [Thumbprint 9733001C4F488EE84A86A2DC81479F7D3262A9C3] issued to '8d4012f3-7252-4e85-891a-b4ff4421a1e4']LOG]!><time="08:48:03.366-240" date="10-28-2013" component="SMSPXE" context="" type="1" thread="7916" file="ccmcert.cpp:1386">
<![LOG[Client lookup reply: <ClientIDReply><Identification Unknown="0" ItemKey="16782654" ServerName="" ServerRemoteName=""><Machine><ClientID/><NetbiosName/></Machine></Identification></ClientIDReply>
]LOG]!><time="09:04:30.956-240" date="10-28-2013" component="SMSPXE" context="" type="1" thread="4100" file="libsmsmessaging.cpp:6363">
<![LOG[00:0C:29:6C:3F:1D, 08544D56-DCF7-D4D5-D1CC-409FCF6C3F1D: device is in the database.]LOG]!><time="09:04:30.956-240" date="10-28-2013" component="SMSPXE" context="" type="1" thread="4100" file="database.cpp:483">
<![LOG[Client lookup reply: <ClientIDReply><Identification Unknown="0" ItemKey="0" ServerName="" ServerRemoteName=""><Machine><ClientID/><NetbiosName/></Machine></Identification></ClientIDReply>
]LOG]!><time="09:11:12.094-240" date="10-28-2013" component="SMSPXE" context="" type="1" thread="4100" file="libsmsmessaging.cpp:6363">
<![LOG[00:0C:29:06:F4:5C, 06494D56-AB1D-1748-BEC0-E4A5B906F45C: device is not in the database.]LOG]!><time="09:11:12.094-240" date="10-28-2013" component="SMSPXE" context="" type="1" thread="4100" file="database.cpp:483">
<![LOG[Client lookup reply: <ClientIDReply><Identification Unknown="0" ItemKey="16782654" ServerName="" ServerRemoteName=""><Machine><ClientID/><NetbiosName/></Machine></Identification></ClientIDReply>
]LOG]!><time="09:11:23.420-240" date="10-28-2013" component="SMSPXE" context="" type="1" thread="4100" file="libsmsmessaging.cpp:6363">
<![LOG[00:0C:29:6C:3F:1D, 08544D56-DCF7-D4D5-D1CC-409FCF6C3F1D: device is in the database.]LOG]!><time="09:11:23.435-240" date="10-28-2013" component="SMSPXE" context="" type="1" thread="4100" file="database.cpp:483">

Free Windows Admin Tool Kit Click here and download it now

October 28th, 2013 5:32am

After fighting with the same problem for some hours I finally found the error in MY system - and your 2 gateways at the pxe-clients could be a hint that you have the same problem :

The story: I have an VMWAre ESX server, connected with many IP-Ranges and many WDS-Servers in many domains. All PXE-Clients working fine, only in one subnet all clients gave the error with PXE-E32.

One thing was sure soon: the TFTP on the WDS Server never got a request from the PXE-client, if the client was in that subnet.

With ESX it is easy to change the subnet of a machine, and I found out: the same (virtual) client, the same NIC, the same DHCP-Server, the same WDS-Server - working perfekt in all subnets from this domain, but in that special subnet (the main subnet, where all the clients in my building are connected) it did not work!!!

After some trying and guessing I recognised that the client got TWO gateways in this subnet (same picture than your client!!!) - the first one I never configured anywhere as a gateway, the second was the right one (10.8.8.252 the wrong one, 10.8.8.254 the really one).

That was strange, because my DHCP-Server had only one (the second one). The first one was a switch. Strange more - while trying around one time I got another IP as the first one (10.8.8.250) - an address from the same subnet, but another switch. played around with new installed DHCP-Servers - same effect.

After some wondering and trying I found the problem in MY case (maybe other people have other problems): I have HP Procurve switches and use DHCP-relay-agent at this switches.

What never made problems before: I had the DHCP-relay-Agent activated at more than ONE switch on the same subnet. Didnt know that this could be a problem ...

The IP of the switch with the IP-Helper-Address is the primary gateway that the PXE-client is showing, the real gateway is number two- and he tries to conact the TFTP-Server only over the first gatway.

After I removed the "ip helper-address" on the other switches I got only one gateway and the client booted like a charm.

Maybe this hint can help somebody ...

======

TEGO3

January 22nd, 2014 5:11pm

After fighting with the same problem for some hours I finally found the error in MY system - and your 2 gateways at the pxe-clients could be a hint that you have the same problem :

The story: I have an VMWAre ESX server, connected with many IP-Ranges and many WDS-Servers in many domains. All PXE-Clients working fine, only in one subnet all clients gave the error with PXE-E32.

One thing was sure soon: the TFTP on the WDS Server never got a request from the PXE-client, if the client was in that subnet.

After some wondering and trying I found the problem in MY case (maybe other people have other problems): I have HP Procurve switches and use DHCP-relay-agent at this switches.

What never made problems before: I had the DHCP-relay-Agent activated at more than ONE switch on the same subnet. Didnt know that this could be a problem ...

After I removed the "ip helper-address" on the other switches I got only one gateway and the client booted like a charm.

Maybe this hint can help somebody ...

======

TEGO3

Proposed as answer by Remy K 23 hours 39 minutes ago

Free Windows Admin Tool Kit Click here and download it now

January 22nd, 2014 10:08pm

After fighting with the same problem for some hours I finally found the error in MY system - and your 2 gateways at the pxe-clients could be a hint that you have the same problem :

The story: I have an VMWAre ESX server, connected with many IP-Ranges and many WDS-Servers in many domains. All PXE-Clients working fine, only in one subnet all clients gave the error with PXE-E32.

One thing was sure soon: the TFTP on the WDS Server never got a request from the PXE-client, if the client was in that subnet.

With ESX it is easy to change the subnet of a machine, and I found out: the same (virtual) client, the same NIC, the same DHCP-Server, the same WDS-Server - working perfekt in all subnets from this domain, but in that special subnet (the main subnet, where all the clients in my building are connected) it did not work!!!

After some trying and guessing I recognised that the client got TWO gateways in this subnet (same picture than your client!!!) - the first one I never configured anywhere as a gateway, the second was the right one (10.8.8.252 the wrong one, 10.8.8.254 the really one).

That was strange, because my DHCP-Server had only one (the second one). The first one was a switch. Strange more - while trying around one time I got another IP as the first one (10.8.8.250) - an address from the same subnet, but another switch. played around with new installed DHCP-Servers - same effect.

After some wondering and trying I found the problem in MY case (maybe other people have other problems): I have HP Procurve switches and use DHCP-relay-agent at this switches.

What never made problems before: I had the DHCP-relay-Agent activated at more than ONE switch on the same subnet. Didnt know that this could be a problem ...

The IP of the switch with the IP-Helper-Address is the primary gateway that the PXE-client is showing, the real gateway is number two- and he tries to conact the TFTP-Server only over the first gatway.

After I removed the "ip helper-address" on the other switches I got only one gateway and the client booted like a charm.

Maybe this hint can help somebody ...

======

TEGO3

You saved my day. Was looking into the same problem for some days now!!

April 1st, 2015 4:05am

This topic is archived. No further replies will be accepted.