Hello -
I am trying to PXE boot to our WDS/MDT server on a VM and it continually gives me an TFTP download error. Failed to restart TFTP. It works with no problems on a physical machine, so i'm not sure why the VM is having such issues. Any help would be appreciated.
Hi,
Can you post a little bit more details on your configuration?
Is the VM picking up an IP from DHCP? If so, are all the DHCP options configured correctly?
Is DHCP service running on the same server as WDS?
What OS is the WDS/MDT server running? 2008R2 or 2012R2?
If it is 2008R2 have a look here.. https://support.microsoft.com/en-us/kb/2673007
You can turn on WDS logging and attempt to pxe again. Check event viewer and then report back to us..
WDSUTIL /Set-Server /WDSClientLogging /Enabled:Yes
WDSUTIL /Set-Server /WDSClientLogging /LoggingLevel:info
-Brian
Sure - I am getting an IP from the DHCP server, it is then showing the IP of the WDS server that is trying to PXE boot to. Then i get a TFTP download error. We are running Windows 2012 R2. DHCP server is not on the same server as WDS. It is actually at another facility with a different subnet.
Logging has been enabled. Where can I find the log files to review?
Attached is a screenshot of the error when trying to PXE boot.
WDS logging options and locations are documented here: Microsoft KB 936625: How to enable logging in Windows Deployment Services (WDS) in Windows Server 20...
Just to confirm your setup... Let us know if any of this is incorrect: You have a DHCP relay running on 10.x.x.x (the "local network") which forwards to 132.y.y.y. The DHCP server at 132.y.y.y (running which software?) is giving out addresses on 10.x.x.x, configured with the appropriate netmask and a default gateway, plus the bootfile information which points to the Windows 2012 R2 WDS server. The WDS server is providing TFTP service on the local network. The virtual machine client connects successfully to the WDS TFTP server on the local network, and fetches the network bootstrap program (WDSNBP), but once the NBP is running it is unable to initiate TFTP to the same WDS TFTP server.
So is it correct that the DHCP server is the only part in the other facility, and all the TFTP is to a local machine with reasonably low latency? On the same 10.x.x.x subnet as the booting client? Do you have multiple 10.x.x.x subnets, or is every 10.x.x.x in your screenshot all within the one subnet?
Are you using either gPXE or iPXE when booting the physical machines?
Cheers,
--
Darius
Yes, that all sounds correct. 132.y.y.y is the DHCP server running Windows 2003 R2. The DHCP server is the only part of this that is located at the other facility. We do have different subnets within the company for the 10.x.x.x. The servers are 10.x.x.x and the DHCP clients are 10.x.y.x. The virtual machine is pulling the correct DHCP 10.x.y.x address (as are the physical machines, obviously). I have got it to PXE boot on rare occasions. It's probably only 5% of the time, however. Nothing changes in the setup or the virtual machine (other than a reboot) when it works or doesn't work to PXE boot. I will review the logs today.
Thanks.
This is the error that I am receiving in the Event Viewer logs:
The Following Client failed TFTP Download:
Client IP: 10.2.y.x
Filename: boot\x86\wdsnbp.com
ErrorCode: 1460
File Size: 30832
Client Port: 2072
Server Port: 56872
Variable Window: false
Hi,
You said you are running WDS 2012 correct?
If so, on the WDS server properties, right click - > properties -> TFTP tab -> Set Maximum block size to 1400 (try 1300 if 1400 doesnt work). -> Uncheck "Enable Variable Windows Extension"
Post back your results.
Correct, running Server 2012 R2, WDS version 6.3.9600.16384. Setting to 1400 & 1300, then restarting WDS services still encountered the same TFTP download error.
Ok.. Is there a firewall between the VM that's PXE booting and the WDS Server?
If so please validate the ports are opened :
https://technet.microsoft.com/en-us/library/cc732918(v=ws.10).aspx
I'm starting to run out of ideas =(.
There is a firewall but not between the VM and the WDS server. Only from the VM, DHCP, WDS server.
Just curious, can you try using VMXNET3 NIC instead of e1000?
You bet. I have tried it, but I will try it again with the settings changed.
And you're positive that the network gained from DHCP (132.xxx ) can access the WDS server with the ports in that Microsoft KB article i provided a few posts ago?
When you deploy physical machines, they receive the same DHCP IP address and are in the same location traversing the same network devices to get to the WDS server right?
Same thing, unfortunately. TFTP download failed.
Yes, 132 can access the WDS server on those ports. The physical machines are in the same location as the VM's and DHCP is providing the same IP addresses. Like I mentioned - I have got the VM's to PXE boot, but it is only about 5% of the time. Once they PXE boot the MDT screen freezes and cannot proceed.
OK.. Can you try using a Discover image? Create it, copy it to the datastore where the VMs are located and mount the ISO.
I've used this before in my WDS environment on certain machines that didn't support pxe or wouldn't stay connected the entire time.
I think if that works, it will have to be a work around for now.
Sure. One problem, however, I am not seeing Microsoft Windows AIK under All Programs? I installed all the tools with the Windows 10 ADK and still do not see it. Am I missing something?
Are there any other VMs running on the same ESXi host? (Relatedly: Is the WDS server a VM on that host, or on a separate host?)
One random thought (quite likely off the track, but just possibly also an explanation): If your ESXi host's VM network NIC is attached to a switch port with "port security" or similar features enabled, there may be a limit to the number of MAC addresses which the switch will allow to associate with that physical switch port... This can lead to weird/surprising connectivity issues when new virtual machines come online. It's a weird problem the way you're describing it, and I'm struggling to come up with any other/better explanations right now... the only other possibility I can think of is duplicate MAC addresses and/or duplicate IP addresses.
Cheers,
--
Darius