So I’ve installed the Transport Server service on Windows 2012 Server. This was under the Role Windows Deployment Server.
My understanding is that this adds a TFTP server to Windows and this is how PXE booting devices download the files needed to get Windows PE working and whatever Windows edition installed.
When I do tftp -i localhost GET <target file> <destination path> from the host machine it works fine. When I do tftp -i 10.0.0.250 <target file> <destination path> from a remote machine (the machine that’s RDPing to the server) it errors out with Timeout occurred Connect request failed after a minute or two of trying. If I try to get a file that doesn’t exist, it immediately fails instead.
The TFTP server is a VM and even the host can’t use tftp -i 10.0.0.250 <target file> <destination path> to get a file.
So it seems like the TFTP service can’t be accessed outside the localhost. I checked Windows Firewall and no entries were there for TFTP so I made them in Inbound for TCP 135, 137-139, 5040, 8099 and UDP 67-69, 4011.
To quote wikipedia:
‘’’
TFTP uses UDP as its transport protocol. A transfer request is always initiated targeting port 69, but the data transfer ports are chosen independently by the sender and receiver during the transfer initialization. The ports are chosen at random according to the parameters of the networking stack, typically from the range of ephemeral ports.[4]
‘’’
Look at what happens with Wireshark (it’s entirely possible you may need to get rid of the firewall almost entirely on that IP).
So I’m beginning to think that since this is Windows’ built in way to do TFTP for PXE booting, they intentionally lock down the TFTP service to only service PXE boots for security since TFTP itself has no authentication or encryption.
I think that’s the case because I can boot PXE but I can’t do anything else likely for the reason you listed.
Essentially, my issue is solved though, because it works with PXE.
Last time I did windows installs over the network it was dnsmasq serving both DHCP and tftp. The client was loading gpxelinux over tftp. gpxelinux was loading winpe image (350MB) over http. The winpe image is good enough to mount a samba share and run setup.
My setup wasn’t fully automated, the winpe parts needed manual “typing” to run, and I didn’t have to worry about network drivers much (lucked out there).
Have you considered it might be more convenient for you to try setting up and then maintaining a couple of shell scripts to have a pop-up service with these tools than it would be to maintain a windows deployment?
Overall, I’m looking for something built into Microsoft’s ecosystem because then I’d have to maintain the scripts. Not that I wouldn’t want to or couldn’t, but this is what my workflow is looking like for maintaining this now that I’ve got it working is merging ZDPs (Zero Day Patches) and other updates into the install.wim using DISM.
And that’s it. Because I realized that using the built-in boot.wim “just worked”. Meaning, now, I just PXE boot, select the Windows Version, and it’s a normal setup process from there aside from offering credentials for the domain.
Next I’ll be looking into unattend files so I don’t have to click buttons or talk to Cortana.
So, when I say "built-in boot-wim", I mean when mounting the Windows 10 Pro ISO, I just copy that sources\boot.wim to the Deployment Server instead of producing my own using Windows Assessment & Deployment Kit.
I think end game is customizing the image so that I don’t have to do anything, but only if I can’t do some things with unattend files.
The winpe.iso that I had gpxelinux was basically boot.wim with a start.cmd that did nothing but run cmd.exe for me to type in. It was made with mkwinpeimg.
I guess any driver setup,netconfig, net use, setup /unattend:foo, could go into that start.cmd.
Nice. How automated is this for you? Do you back up old install.wim versions. (for just in case scenarios).