Client Machines Not Reporting to WSUS Properly?

Quick Fix – Client-Side Script: Choose Your Method – Command Prompt, or PowerShell

Command Prompt

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.

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.

  1. 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.
  2. 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)
  3. 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.
  4. We start the Background Intelligent Transfer Service (BITS), and the Windows Update Service (wuauserv) services.
  5. 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.
  6. 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).

UsoClient.exe Switches

    • 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.

Oh Crud!!! That Didn’t Work. Now What???

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.

/ Tags:

Share the Post

About the Author