WSUS Reporting starts and ends with the Windows Update Agent (WUA) on each individual client. If the client is not reporting properly, it can show up in many different ways. Sometimes it will be obvious (the Last Status Report column is not updating to a recent date) and in other cases it may be that the client simply is not getting the updates that it should be. Sometimes, the device may still be receiving some updates and the Last Contact column is getting updated with recent dates. Remember, “Last Status Report” and “Last Contact” are 2 different columns, and the Last Contact column is hidden by default.
Start from the top of these troubleshooting steps and work your way to the bottom.
Remove the affected devices from the WSUS MMC console. On each affected system, run once from an elevated (Run as administrator) prompt:
Stop-Service -Name BITS, wuauserv -Force Remove-ItemProperty -Name AccountDomainSid, PingID, SusClientId, SusClientIDValidation -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\ -ErrorAction SilentlyContinue Remove-Item "$env:SystemRoot\SoftwareDistribution\" -Recurse -Force -ErrorAction SilentlyContinue Start-Service -Name BITS, wuauserv wuauclt /resetauthorization /detectnow (New-Object -ComObject Microsoft.Update.AutoUpdate).DetectNow()
net stop bits net stop wuauserv reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v AccountDomainSid /f reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v PingID /f reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientIDValidation /f rd /s /q "%SystemRoot%\SoftwareDistribution" net start bits net start wuauserv wuauclt /resetauthorization /detectnow PowerShell.exe (New-Object -ComObject Microsoft.Update.AutoUpdate).DetectNow()
Long Explanation: What is this Doing? Should I be Afraid of Running this?
This client-side script is something you should not be afraid of. Let’s walk through what is happening and why we’re doing it.
- We stop the Background Intelligent Transfer Service (BITS), and the Windows Update Service (wuauserv) services because we’re working with items that are in use by these services.
- We remove the following registry keys if they exist:
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\AccountDomainSid (usually errors out but is included to be totally inclusive but I haven’t seen this since before 2005)
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\PingID (usually errors out but is included to be totally inclusive but I haven’t seen this since before 2005)
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\SusClientId (This is what is responsible for most issues – duplicate SusClientId entries across multiple clients)
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\SusClientIDValidation (This also is responsible with SusClientId)
- Remove the SoftwareDistribution folder from the Windows folder on the system drive – represented using a dynamic variable. This folder contains the history of Windows Update locally on the machine, but it also includes things like the cache of the downloads and temporary files that Windows Update uses. We remove this folder so that it will be recreated by the Windows Update Agent the next time it checks for updates, creating a corruption-free cache.
- We start the Background Intelligent Transfer Service (BITS), and the Windows Update Service (wuauserv) services.
- We run the Windows Update Client (wuauclt) and tell it to reset the authorization to re-create the SusClientId and SusClientIDValidation registry keys. We’ve also stuck on the /detectnow switch on the end of that command to initiate a detection for updates for Windows 8.1 systems and lower.
- We’ve run the PowerShell equivalent of /detectnow for Windows 10 systems and Server 2016+ systems as they no longer use /detectnow as it has been deprecated. (We can also use UsoClient.exe StartScan instead of the PowerShell line however, Microsoft never intended UsoClient.exe to be used by anything other than the system itself through the orchestrator so your mileage may vary. The correct way is the PowerShell API).
UsoClient.exe Switches (Not Official – Community Found)
- StartScan – Used To Start Scan
- StartDownload – Used to Start Download of Patches
- StartInstall – Used to Install Downloaded Patches
- RefreshSettings – Refresh Settings if any changes were made
- StartInteractiveScan – May ask for user input and/or open dialogues to show progress or report errors
- RestartDevice – Restart device to finish installation of updates
- ScanInstallWait – Combined Scan Download Install
- ResumeUpdate – Resume Update Installation On Boot
Background: What is SusClientId and What Symptoms Does Having Duplicate SusClientId Entries have?
WSUS servers use the SusClientId to identify unique devices and then associate the computer’s hostname to the unique identifier for easy recognizable display purposes. Because more than 1 system has the exact same SusClientId, the WSUS server replaces the computer object’s hostname with the latest hostname that communicated with the server. This gives the appearance of a magician’s disappearing act with computers objects.
More than 75% of the time that clients have issues, it is due to cloning or imaging computers. Systems that are the ‘golden’ image are often created in an environment that allows the system to communicate with any WSUS server, including Microsoft’s Windows Update. The moment a client system communicates with a Windows Update server, it creates 2 registry keys that are essentially a security identifier (SID) [SusClientId] and a validation key [SusClientIDValidation] that gives a unique hardware identifier in a binary form. The Windows Update Agent is supposed to use a hardware validation routine to determine whether the current client hardware has changed since the SusClientId value was created, and if it has, it is “supposed to” regenerate both the SusClientId and the SusClientIDValidation. “Supposed to” doesn’t always equate to “does” and this is where the problem lies.
Why Should I Remove Affected Devices from the WSUS MMC Console?
It is best to remove the affected devices from the WSUS MMC first. Why? We’ve seen the client-side script above run and the issue still exist, however every single time when you delete the computer object from the WSUS MMC console first, and then run the commands on EACH affected system, it always works, so we now solely recommend removing the affected computers first, and then running the client-side script.
Are your WSUS ports open? Is IIS running properly?
WSUS by default will run on ports 8530/8531 (2012+) and ports 80/443 (2008 and lower). The best thing to do would be to test the connections from an affected client system.
Try to download the WSUS iuident CAB file from the client machine.
https://server.domain.local:8531/selfupdate/iuident.cab (if SSL is enabled)
Then try to browse to:
https://server.domain.local:8531/ClientWebService/client.asmx (if SSL is enabled)
If you can download the cab file and browse to the Client Web Service URL (using both URLs if you’re using SSL), then your ports are open and IIS is functioning properly; continue troubleshooting. If you can’t download the cab file and browse to the Client Web Service URL, check firewall settings (Microsoft and 3rd party firewalls) and port settings.
Group Policies: Are your policies pointing to the correct place?
Is the client actually receiving the correct GPO and the correct policies? From an elevated (Run as administrator) Command or PowerShell prompt on an affected client, run the following:
gpresult /h gpo.htm
Open the newly created gpo.htm file (created in the current folder) and verify it’s location URLs (all 3 as noted in part 4 of my part blog series on How to Setup, Manage, and Maintain WSUS.) If the GPOs are pointing to the correct place at the client; continue troubleshooting.
Is it DNS?
Especially if you’re using a generic FQDN like wsus.domain.com, you’ll want to make sure your systems are actually resolving the name to the actual IP of the server you’re trying to get the clients to communicate with. Even if it is the FQDN of a specific server, just verify DNS is working from the client side.
From Command Prompt:
ping wsus.domain.local ping server.domain.local
Are you using a DNS Alias?
wsus.domain.com when the FQDN is WSUS-01-SEA.domain.local.
In these instances, you will need to configure the correct SPN records. Microsoft Docs: Service Principal Names
To see if it is related to the SPN:
setspn -Q HTTP/WSUSServerName.domainame.local
If you find that it has a bad SPN record, you’ll want to delete the bad record. To do that:
setspn -D HTTP/WSUSServerName.domainame.local
To list all of the SPNs for a specific hostname:
setspn -L [Hostname]
If you are using a CNAME for your WSUS SSL Certificate, you must add the appropriate HTTP/CNAME record:
setspn -S HTTP/CNAME.domain.com [Hostname] setspn -S HOST/CNAME.domain.com [Hostname]
Is the Non-SSL Port Blocked?
When SSL is enabled on a WSUS system, the port switches to port 8531 (2012+) or port 443 (2008 and lower). Many administrators assume that because WSUS is now responding on the SSL port, that they can now cut the non-SSL port out of the equation and block the HTTP port (8530/80). Unfortunately, that causes problems as WSUS using SSL still will use the HTTP channel for data. Both ports are required to be open when you are using SSL.
Is IPv6 Disabled?
Many IT administrators like to try to disable things that they don’t use. One of the protocols they disable is IPv6 because they don’t have IPv6 setup on their network and only use IPv4. This is a mistake because ever since Windows 7, IPv6 has been enabled by Microsoft and is used by the client systems to communicate with itself and other services on the system. Stop hurting yourself by disabling IPv6!
Do you have any Remote Monitoring & Managing (RMM) Software on your systems?
If you have RMM software installed, such as SolarWinds RMM, they monitor and solidify the the Windows Update registry keys so that alternative applications cannot change the settings (the RMM software will almost immediately change it back). If you have any of these RMM softwares, disable or uninstall them to verify that they are not the cause of your issues.
Verify The Registry
Verify that: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate\AU\UseWUServer is set to 1.
Use the following PowerShell to pull all the properties and values from the WindowsUpdate registry key and AU key.
Get-ItemProperty -Path 'HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate' Get-ItemProperty -Path 'HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate\AU'
Use the output to not only inspect the UseWUServer value and make sure it’s set to 1, but also to check for any errors in the URL (which CANNOT HAVE a trailing slash on it).
Are the GPO Templates Updated?
As noted in Part 3 of How to Setup, Manage, and Maintain WSUS, you will want to get the latest Administrative Templates (.admx/.adml) for Windows which are located at:
Get the latest one, even if it’s not for the OS you are installing. These are backwards compatible and cumulative meaning that the latest one will have all the updates from each of the preceding admx files. Install these Administrative Templates in your Central PolicyDefinitions folder on your Domain Controller.
This flows into the next point about Scan Sources – you will want to make sure you are specifying the scan source policy.
What is the Scan Source of the Windows Update Agent?
Is WSUS The Default Automatic Update Service? What is the scan source of the Windows Update services? Use the PowerShell below to find out.
$(New-Object -ComObject "Microsoft.Update.ServiceManager").Services | Select-Object Name, IsDefaultAUService
If Windows Server Update Services is not set to True, and your GPOs have the proper settings, you have a dual scan scenario happening. This again flows into the next step.
Are You Specifying WUfB Policies?
Are you specifying Windows Update for Business (WUfB) policies?
If you are using WSUS:
DON’T SPECIFY ANY WUfB POLICIES!!!!
If you have any of them specified, set them all to ‘Not Configured’.
More information is in the article Dual Scan – Making Sense of Why So Many Admins Have Issues.
Do not mistake the Policy “Do not allow update deferral policies to cause scans against Windows Update” (or the associated registry key HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate\DisableDualScan) as a fix for this – this too is a WUfB policy.
Is the WSUS server missing required files?
The easiest way to fix this (you can’t easily tell without doing wireshark captures) is to run a WsusUtil Reset which will go through all files, confirm they are not corrupted and missing, and ONLY download or re-download missing or corrupted files from Microsoft.
& "$env:ProgramFiles\Update Services\Tools\WsusUtil.exe" Reset
Unfortunately, you can’t tell how much progress has been completed, or what has been done, or when this is finished. It is best to assume it is going to take a full 24 hours (longer if it has to download a lot of data and you have a slow connection).
It’s my WSUS server!
It may be your WSUS server that’s the problem. Clients request updates and cause the WSUS server to communicate back and forth and compare the updates that are already installed on the client system with what updates are available within WSUS. The available updates include all of the updates excluding declined updates that the server knows about. When you’re not doing the proper maintenance on the WSUS server, the comparative lists grow big and can time out the server’s connection. Due to this timeout, reporting back to the server can be affected. By performing the proper maintenance on the WSUS server, you effectively reduce the amount of data that needs to be compared against thereby making the time shorter and the client able to respond to the request. Part 8 of my blog series on How to Setup, Manage, and Maintain WSUS explains what should be done on a regular basis to maintain your WSUS instance. Alternatively, you can simply WAM your server ® and you won’t need to worry about WSUS maintenance anymore.