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.
Troubleshooting Steps
Client-Side Script
Remove the affected devices from the WSUS MMC console. On each affected system, run once from an elevated (Run as administrator) prompt:
PowerShell
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()Command Prompt
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.
http://server.domain.local:8530/selfupdate/iuident.cab
https://server.domain.local:8531/selfupdate/iuident.cab (if SSL is enabled)
Then try to browse to:
http://server.domain.local:8530/ClientWebService/client.asmx
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.htmOpen 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 the Windows Firewall enabled?
Is the Windows Firewall enabled on client? As noted by Microsoft, some of the errors that you might see in Windows Update logs:
DownloadManager Error 0x800706d9 occurred while downloading update; notifying dependent calls.
Or
[DownloadManager] BITS job {A4AC06DD-D6E6-4420-8720-7407734FDAF2} hit a transient error, updateId = {D053C08A-6250-4C43-A111-56C5198FE142}.200 <NULL>, error = 0x800706D9
Or
DownloadManager [0]12F4.1FE8::09/29/2017-13:45:08.530 [agent]DO job {C6E2F6DC-5B78-4608-B6F1-0678C23614BD} hit a transient error, updateId = 5537BD35-BB74-40B2-A8C3-B696D3C97CBA.201 <NULL>, error = 0x80D0000A
Go to Services.msc and ensure that Windows Firewall Service is enabled. Stopping the service associated with Windows Firewall with Advanced Security isn’t supported by Microsoft. For more information, see I need to disable Windows Firewall.
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 PowerShell:
Resolve-DnsName wsus.domain.local
Resolve-DnsName server.domain.localFrom Command Prompt:
ping wsus.domain.local
ping server.domain.localAre 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.localIf 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.localTo 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.
Did You Incorrectly Enable SSL?
If you have enabled SSL on WSUS which is both Microsoft’s and AJ Tek’s recommended way, you should have enabled SSL using the proper WsusUtil.exe configuressl command, however before you run the command you must set ‘Require SSL’ to True on some of the IIS Virtual Directories. If you do the right ones, SSL will be configured, but if you do MORE than what is needed, SSL will still enable but you may encounter 403 Forbidden issues. Make sure that ALL virtual directories are set to ‘Require SSL’ = False except for ‘SimpleAuthWebService’, ‘DSSAuthWebService’, ‘ServerSyncWebService’, ‘APIRemoting30’, and ‘ClientWebService’. An easy way to configure SSL for WSUS is by referencing How to Setup, Manage, and Maintain WSUS: Part 7 – SSL Setup for WSUS and Why You Should Care! as this article has every step you need to take and made it into a set of PowerShell commands to make it easier to implement.
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.
Are you using Configuration Manager?
Ensure that your Software Update Point Component Properties have it set to “Create all WSUS reporting events”.
Is WSUS in a Healthy State?
The easiest way to check if WSUS is in a healthy state is by using Microsoft’s utility to check the health of your WSUS server and then review the event viewer Application Event logs to confirm everything is healthy.& "$env:ProgramFiles\Update Services\Tools\WsusUtil.exe" checkhealth
If it is not in a healthy state, you should investigate and fix these isssues. If in the Application Event Log there is an error from Windows Server Update Services, event ID 12002, saying “The Reporting Web Service is not working.”, you may need to restart the WSUS Administration site in IIS and verify again that “The Reporting Web Service is working correctly.” Sometimes even a restart of the server is not enough.
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.
