Windows as a Service.
It sounds like an eminently sensible idea in world where failing to keep software up-to-date, in particular with security fixes, has a tangible negative impact on people. Treating software as a service also provides a healthy ongoing income stream, as well. 😉
At work, we had many issues with our first attempt at running an in-place upgrade from Windows 10 1511 to 1607 using ConfigMgr. They were resolved, in the end, but required a lot of effort.
So, naively, I am assuming that we couldn’t possibly quite as unlucky a second time, when testing using the same Windows 10 Servicing method for upgrading 1607 to 1703.
Alas, the upgrade to the new build itself worked without issue, but once booted into the new OS, Configuration Manager-mediated Windows Update scanning now fails.
This, from the WUAHandler.log:
OnSearchComplete - Failed to end search job. Error = 0x8024000d.
Scan failed with error = 0x8024000d.
Digging a little deeper, I’m seeing errors relating to the metadata for the updates.
[metadataintegrity] failed: hr = 0x80245004
[metadataintegrity]GetFragmentSigningConfig failed with 0x80245004. Using default enforcement mode: Audit.
We’re seeing an error relating to missing XML content, which I guess adds up with the suggestion that the metadata integrity is not validating.
0x8024000D WU_E_XML_MISSINGDATA Windows Update Agent could not find required information in the update's XML data.
It seems that perhaps third-party products being added to WSUS (such as Adobe Flash Player, before it was shipped as part of MS updates from Windows 8 onwards) may be related to the issue.
It is odd, and frustrating, that whatever issue it is only manifests in 1703, and that, once again, the nuclear option of a rebuild of a significant infrastructure piece is the dominant suggested solution.
I will update this post with any success I have resolving the issue without starting afresh with WSUS.