Just finished troubleshooting an error with Windows 10 clients (build 1607 and above) contacting WSUS server getting 0x8024500c like below while searching updates.
blog.tofte-it.dk/wp-content/uploads/2017/08/0x8024500c-300×140.jpg 300w” sizes=”(max-width: 589px) 100vw, 589px” class=”” style=”max-width: 100%; margin: 0.5em auto; display: block; height: auto;”>
The client had an on-premise WSUS server which they wanted to push out Windows Updates, instead of using the internet (windowsupdate.microsoft.com).
They had configured the following group policy to enable:
- Computer ConfigurationAdministrative TemplatesWindows ComponentsWindows Update
- Do not connect to any Windows Update Internet location
This caused the Windows Update on the clients to break, instead they should disabled the above and configured the following instead:
- Computer ConfigurationAdministrative TemplatesSystemInternet Communication ManagementInternet Communication settings
- Turn off access to all Windows Update features
The above will allow users to download apps on the Windows Store, but still only allowing the users to use the on-premise WSUS server.
Unfortunately Microsoft introduced a new feature called “Dual Scan” (read more about it here) which allows the Windows clients to access both WSUS and the internet, which would potentially bypass the local WSUS.
To disable the dual scan, the client needs to have the following registry keys deleted.
If though you set the matching group policies to “Not Configured” or “Disable”, it will not delete the keys but only set them to zero (DWORD) in the registry.
For those clients that are running build 1607, you need to install kb4025334 which will add a local policy “Do not allow update deferral policies to cause scan against Windows Update” under “Computer ConfigurationAdministrative TemplatesWindows ComponentsWindows Update“.
You can set this group policy on those 1607 clients by adding the following registry through group policy.
- Key: DisableDualScan
- Value: 0x1
- Type: DWORD
The WSUS server was also tuned a little, because all resources was used. This caused the clients to take a long time to talk and eventually timeout.
- All superseded updates was declined in the WSUS management console.
- The WSUS IIS application pool (“WsusPool“) was also tunned with the following settings (remember IISRESET afterwards):
- .NET Framework Version: v4.0
- Already on Windows Server 2012 above, but this server was Windows Server 2008 R2
- Queue Length: 2000
- Private Memory Limit: 7843200
- .NET Framework Version: v4.0
You can test the Windows Update by executing the following command in a elevated command prompt.
- usoclient.exe StartScan
If you want to see what registry keys you have on your client, you can run the following in a command prompt with elevated rights.
- reg query HKLMSOFTWAREPoliciesMicrosoftWindowsWindowsUpdate /s
- reg query HKLMSOFTWAREMicrosoftPolicyManagercurrentdeviceUpdate
- reg query HKLMSOFTWAREMicrosoftWindowsUpdateUXSettings
Windows Update Log
Check the Windows Update log by running the following command in PowerShell.
Check the Component-Based Servicing log here.
That is my 2 cents, hope you can use it!