All of a sudden my Windows 10 Workstations were not installing updates. The error message was "Windows Update failed to check for updates with error 0x8024002E". 0x8024002E equals "WU_E_WU_DISABLED Access to an unmanaged server is not allowed". So the clients were thinking my WSUS Server was an unmanaged Server?
This did not make any sense whatsoever. I investigated on how to determine what the client thought was it's default source for updates, just so I could confirm this new Windows 10 disaster called Windows Update was working the way I wanted it to. A Microsoft TechNet article lead me to check for the IsDefaultAUService in the Com Object "Microsoft.Update.ServiceManager". So I created a PowerShell oneliner to tell me what was set as default and if it was managed: (New-Object -ComObject "Microsoft.Update.ServiceManager").Services | select Name, IsManaged, IsDefaultAUService
This produced the following results:
Name IsManaged IsDefaultAUService
---- --------- ------------------
Microsoft Update False True
DCat Flighting Prod False False
Windows Store (DCat Prod) False False
Windows Server Update Service True False
Windows Update False False
This did not make any sense. Why in the world is Microsoft Update the default? I checked all my GPOs for Windows Update. Verified against several sources to confirm I had setup everything correctly, which includes disabling the DualScan feature (Ref 1).
Then I thought about it, the error "WU_E_WU_DISABLED Access to an unmanaged server is not allowed" means the client is not allowed to update from Microsoft Update, which is an "unmanaged" server. I definitely have this setting enabled, "Do not connect to any Windows Update Internet locations". OK, fine, that explains the error, my GPOs for that part are working as designed, but why is the default still Microsoft Update?
After searching on many different keyword combinations (0x8024002E was useless to search for) I finally found a conversation about telemetry and Microsoft Update (Ref 2). The relevant portion was "when we set the telemetry to 0 via GPO...leads to clients upgrading to the latest April update even though it's not even approved on the WSUS server".
Aha! My GPO setting "Windows Components/Data Collection and Preview Builds, Allow Telemetry" was definitely set to "0 - Security [Enterprise Only]". I changed "Allow Telemetry" to "1 - Basic", then ran "gpupdate /force /target:computer" on the client and then re-ran my oneliner which now looks correct and the client connected to my WSUS for updates.
Name IsManaged IsDefaultAUService
---- --------- ------------------
Microsoft Update False False
DCat Flighting Prod False False
Windows Store (DCat Prod) False False
Windows Server Update Service True True
Windows Update False False
My clients were working up until this month (August 2018), so why did this change all of a sudden? While I am not 100% sure, I did run into another blog post about Windows 10 Dual Scan. (I love his one-liner in his blog, looks familiar). The author mentions the "Out of the Box Experience (OOBE)" causing the issue (Ref 3), which of course I use when Sysprep'ing the copies of the Gold Images after installing updates, so I am assuming this is what caused the issue. Why now after so many months, I will never know. Just lucky that way, I guess.
Anyway, hopefully this will help someone figure out their issue, even if it isn't the same.
Adding my symptoms once again so the search engines pickup on them:
Windows Update failed to check for updates with error 0x8024002E, WU_E_WU_DISABLED Access to an unmanaged server is not allowed
Here are the referenced resources:
Ref 1: https://blogs.technet.microsoft.com/swisspfe/2018/04/13/win10-updates-store-gpos-dualscandisabled-sup-wsus/
Ref 1: https://blogs.technet.microsoft.com/wsus/2017/05/05/demystifying-dual-scan
Ref 2: https://social.technet.microsoft.com/Forums/windows/en-US/a4f59491-f9c2-4162-bc9c-fc83a3f216f6/windows-10-dualscan-enabled-when-telemetry-is-set-to-0?forum=win10itprogeneral
Ref 3: https://cloudenius.com/2018/04/21/update-windows-10-with-sccm-wsus-only-by-defeating-dual-scan/