Trials of a Network Admin

One of my earliest posts pertained to troubleshooting we did to fix PXE booting for some UEFI Windows tablets we were deploying. The issue there stemmed from what turned out to be an incorrect PXE configuration that wasn’t allowing the deployment server to dynamically serve the proper boot file.

Since those changes, we’ve been working with a few models of 32-bit UEFI tablets for about a year without issue and could successfully image the devices as many times as needed. So when we started bringing in some different tablets we were surprised to find we were once again having problems.

This time around, the devices (specifically the Acer SW5-012 and ASUS T100) would PXE boot once and attempt to image. Many times things would work and we’d have a properly imaged tablet. Other times imaging would fail. When that happened, or if for some reason we needed to reimage, we ran into very strange behavior. The device would attempt to PXE boot and then fail, claiming it could not find the device’s internal storage. And sure enough, while a unit fresh out of the box showed internal storage in the BIOS, once the imaging process wiped the storage, the BIOS no longer showed any internal storage. We could still install Windows directly from a UEFI bootable USB drive, but PXE would not work.

The fact that other 32-bit UEFI tablets did work really threw us off. Packet captures even showed that both the working and non-working devices reported the same “IA32 EFI” architecture during the DHCP process.

We ultimately stumbled on a piece of MS documentation (which I can’t find as I type this up) that indicated the problem came down to the OS version of the WDS deployment server in use. According to this link, support for 32-bit UEFI devices is only present in Server 2012, but the original documentation we found specified 2012 R2. What I can say with certainty is we now have 32-bit UEFI working with WDS on 2012 R2.

We really would like to understand why some 32-bit UEFI devices work while others don’t. Our best guess is it has something to do with the eMMC storage in the problem devices, but we can’t explain it. At least it’s fixed. Hopefully this solves the problem for someone else, as it was quite frustrating and took up a lot of our time.