Client reboots after WinPE loads

[Cahij]

Hi, Folks,

I'm used to muddling through ConfigMgr problems on my own but I've hit the wall.

Here's my situation:

I am migrating from an old ConfigMgr hierarchy to a new install (1702).

I am trying to get PXE boot working in the new environment. All of our clients and 64 bit UEFI devices. Here is what happens:

* WinPE loads and immediately after "preparing network connections", the system reboots (every single time)

* I press F8 and ipconfig /all shows a valid IP address and all other parameters ... DHCP server, DNS servers, etc. (so it is NOT a NIC driver issue)

* I can map a network drive and copy a file from the root of C: to a share on the DP, and vice versa (so it is NOT a storage driver issue)

* I can ping the FQDN of the DP

* the date and time are correct

* smsts.log contains these three suspicious entries: "Failed to download pxe variable file. Code(0x00000001)", "PxeGetPxeData failed with 0x80004005", and "TS environment is not initialized"

I have no idea what to do next!

 

 

[Config Mangler]

Try building from a USB stick to rule PXE in or out as the problem? Try legacy boot on one of the devices to rule UEFI in or out?

[benwatt]

You've probably since fixed this, but as I came across this post when searching far and wide for the same errors with PxeGetPxeData after recently upgrading our ADK to 1703, I thought I'd at least post what the fix was in our case in case it helps somebody else, as it took a long time to get to this point!

Although this can be caused by a missing network driver, in this case (and my case) you can access the network just fine. However, if you're running the 1703 version of the ADK, and have the "Optional Component" WinPE-Dot3Svc installed on the boot image, the network stack won't start, and the PC will restart as you describe, just as the "Preparing network connections" stage is reached.

This is outlined at https://support.microsoft.com/en-gb/help/4025632/windows-pe-network-winpe-dot3svc-optional-component-doesn-t-work-in-wi

Your options are to either remove the component if you don't need 802.11x support, or apply the fix Microsoft describes.