zawtowers

Have you checked the logs in C:\$windows.~bt\Sources\Panther to see what errors there are (it's a hidden system folder when you do upgrades)? There should be a few logs in there, notably an activity and error log which might point you in the right direction. Also check C:\windows\ccm\logs\UpdateDeployment.log (if deployed via ConfigMgr) as that should also report back some errors to during any updates before restart.

Cheers for that. I looked at that, which I was already along the same lines of, but realised a couple of things - as below: As the PFX cert on the CMG has a path to intermediate and root CA, I specified both .cer files in the site properties The CMG config (in the Admin page of the Configmgr console) showed a new version increased by 1, so then synced the config I then created the boot media, using a self-signed cert. It also added the intermediate and root CA certs into the boot image I booted, and the SMSTS.log showed it could auth to the CMG (because the certs were both there and full path to the cert on CMG was able to auth) I could see the task sequences. Specifying the root CA alone did not work in the site properties, I had to do the root and intermediate, then update the CMG config and boot media.

Which version of the VPN client are you running? I'm just wondering if in fact the VPN client has services and/or drivers at kernel level in the OS running which are not compatible with Windows 10 1909, hence it is rolling back to 1809 as it's deemed to be a failure. Normally though the update would actually stop and tell you that there's a driver issue with an error.

As @anyweb stated, alwys best to check that the MAC Addresses both the USB-Ethernet dongle and the dock tried are both in the duplicate hardware itentifiers. Also, it would be worth checking SMSPXE.log on the DP Server to see if the client has in fact got an IP and is awaiting approval, or maybe it doesn't show the key press to continue with PXE boot. I've seen this with Intel NUCs where it doesn't actually display the "press ENTER" prompt to continue to boot (when UEFI booting), but if you press ENTER it does carry on, almost as if the firmware doesn't for whatever reason think the message needs displaying. Might be worth checking that with the Surface Go just in case it's a similar thing.

Cheers to you both - that's pretty much what it looks like to me. The cert on the CMG is the server auth cert (so server auth between the ConfigMgr server and the CMG works, as does token based auth via the CMG to the MP) but of course there's no client auth in there. In theory replacing the internal CA cert with a public CA cert (and of course ensuring the DNS CNAME is set as well so the CNAME references the CMG instance) would mean WinPE uses its approved CA list to connect to the cert on the CMG. It'd definitely be worth testing further from the MS product team to see if that's a viable solution for those using token-based auth, or if there's a way that the bulk registration token could be injected into the client in the boot media (so it has a valid token in the media itself) which could alleviate.

I'm getting the same error as HeroicBandit in SMSTS.log with the generated boot media. There's no PKI, and the site is using the Configmgr cert for HTTP site systems. The only certificate issued by the internal CA is the one with the subject name of our CMG, which is present on the CMG. Clients are authenticating with token fine, so I know the CMG is working for existing clients. Is this a limitation because there's no PKI on the site system itself and so has no path to authenticate via the internal CA when using boot media?

When booting from PXE, SCCM will use the version of the Windows PE boot image on your PXE enabled distribution point. If this is not updated on the DP, it will still be using the last version that you uploaded, along with any SCCM binaries that were present in there. You should where possible ensure that the latest version of the Windows 10 ADK (and therefore WinPE) is updated, and ensure that your boot images are updated with those ADK binaries (there is an option for this when you update the boot images). The latest WinPE images also have correct and updated network drivers, so should be quicker retrieving policy and dependencies from each of the DPs and management point. Also check how site assignments are set on your boundaries and boundary groups as well as the site servers including DPs are associated to those groups. It could be for example you're PXEing to a local DP, but the boundary group doesn't have the local DP as a server it can use, and may be going elsewhere. See also this article for increasing the speed of loading the WinPE image - the TFTP Window Size setting really works well and works in all versions from 1606 onwards: https://ccmexec.com/2016/09/tweaking-pxe-boot-times-in-configuration-manager-1606/