WSUS – High CPU due to “supersedence” updates.

Lately I have been seeing high CPU (90-100%) usage on servers where the Windows Server Updates Services (WSUS) is installed.

This is mainly caused by updates that is superseded, and is filling the database causing the CPU to spike.

Read More

WSUS – Windows 10 Clients – Error 0x8024500c

Error

Just finished troubleshooting an error with Windows 10 clients (build 1607 and above) contacting WSUS server getting 0x8024500c like below while searching updates.

The client had an on-premise WSUS server which they wanted to push out Windows Updates, instead of using the internet (windowsupdate.microsoft.com).

Cause/Solution

They had configured the following group policy to enable:

  • Computer Configuration\Administrative Templates\Windows Components\Windows 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 Configuration\Administrative Templates\System\Internet Communication Management\Internet 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.

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\Update
    • BranchReadinessLevel
    • DeferFeatureUpdatesPeriodInDays
    • DeferQualityUpdatesPeriodInDays
    • DeferUpdatePeriod
    • DeferUpgradePeriod
    • ExcludeWUDriversInQualityUpdate
    • PauseDeferrals
    • PauseFeatureUpdates
    • PauseQualityUpdates
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings
    • BranchReadinessLevel
    • DeferFeatureUpdatesPeriodInDays
    • DeferQualityUpdatesPeriodInDays
    • ExcludeWUDriversInQualityUpdate
    • DeferUpgrade

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 Configuration\Administrative Templates\Windows Components\Windows Update“.

You can set this group policy on those 1607 clients by adding the following registry through group policy.

  • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
    • 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

You can test the Windows Update by executing the following command in a elevated command prompt.

  • usoclient.exe StartScan

Troubleshooting

Registry Keys

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 HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /s
  • reg query HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Update
  • reg query HKLM\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings

Windows Update Log

Check the Windows Update log by running the following command in PowerShell.

  • Get-WindowsUpdateLog

CBS Log

Check the Component-Based Servicing log here.

  • C:\Windows\Logs\CBS

That is my 2 cents, hope you can use it!