Remove the affected devices from the WSUS MMC console and then from an administrative command prompt on each affected system, run:
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()
Remove the affected devices from the WSUS MMC console and then from an administrative PowerShell prompt on each affected system, run:
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()
Wait 24-48 hours after running the client-side script above to see if the issues have gone away. Normally it is noticeable within an hour, but sometimes it takes longer.
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
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.
Oh Crud!!! That Didn’t Work. Now What???
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, check firewall settings and port settings, and continue to It’s my WSUS server!
From an Administrative Command or Administrative 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.
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
Resolve-DnsName wsus.domain.local Resolve-DnsName server.domain.local
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’re using SSL.
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!
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 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).
$(New-Object -ComObject "Microsoft.Update.ServiceManager").Services | Select-Object Name, IsDefaultAUService
Ensure that your Software Update Point Component Properties have it set to “Create all WSUS reporting events”.
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 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.