Arnaud Loos


  • troubleshooting

Below is the guide I use when troubleshooting a broken WSUS installation. This can manifest as a server console error, the ever popular “it’s just not reporting in”, or through the event log. I’ll walk you through the components of WSUS and how to check and make sure each one is functioning properly.

First a note on what’s available on your platform.
If you’re on Windows 7/8/Server 2008R2/2012R2 then wuauclt works for you.
The only real command you need to know is wuauclt /resetauthorization /detectnow.
wauauclt /reportnow doesn’t do what you think and isn’t very useful.

If you’re on Windows 10/Server 2016 then wuauclt has been depricated and you have UsoClient.
usoclient.exe startscan to detect missing patches
usoclient.exe refreshsettings to refresh settings if any changes were made
usoclient.exe startdownload to download patches
usoclient.exe startinstall to install patches

You also have the option of using Powershell to initiate a scan request.

(New-Object -ComObject Microsoft.Update.AutoUpdate).DetectNow()

Speaking of Powershell, Microsoft makes a number of cmdlets available for managing WSUS Server. To see if these are available to you run

Get-Command -Module UpdateServices

These cmdlets are primarily geared towards deployment and management of the server, patches, and computers, not troubleshooting.

On the client there is a WindowsUpdate module but its only function is Get-WindowsUpdateLog which is used for generating a readable WindowsUpdate.log file in Windows 10.

There exists a third-party PS module for managing Windows Update on the client.

Install-Module PSWindowsUpdate  
Import-Module PSWindowsUpdate  
Add-WUServiceManager -ServiceID 7971f918-a847-4430-9279-4a52d1efe18d  
Get-Command -Module PSWindowsUpdate  
Get-WUList –MicrosoftUpdate  
Get-WUInstall –MicrosoftUpdate –AcceptAll –AutoReboot           


WSUS has the option of utilizing an internal WID (Windows Internal DB) or SQL database. I’m going to assume it’s installed with WID at the default path of C:\Windows\WID\.
Database related errors (other than fragmentation) usually occur at the time of installation, often during the post-installation task sequence.
While it is possible to connect to the WID and drop the SUSDB, errors at this stage are usually best fixed through a complete uninstall and reinstall.
For reference purposes I will state that you can use either SQLCMD or SQL Mgmt Studio to connect to the DB.
The connection string is np:\\.\pipe\MICROSOFT##WID\tsql\query

select name from sys.sysdatabases
drop table susdb
select name from sys.sysdatabases


Uninstall using Server Manager.
Make sure the WSUS content folder is gone as well as the IIS WSUS Administration site.
Uninstalling WSUS doesn’t always remove the WID. Remove it in Powershell with Uninstall-WindowsFeature -Name windows-internal-database
Reboot and delete c:\windows\WID\SUSDB.mdf and SUSDB_log.ldf files.


Along with selecting the WSUS Role, Windows installs ASP.NET 4.6, RSAT Tools, IIS, and the Windows Process activation service.

Install from an administrative Powershell prompt

Install-WindowsFeature -Name Updateservices,UpdateServices-WidDB,UpdateServices-services -IncludeManagementTools

Afterwards, before launching the GUI, run:

C:\Program Files\Update Services\Tools\WsusUtil.exe PostInstall CONTENT_DIR=<Directory_Path_Here, i.e. D:\WSUS>
Change the CONTENT_DIR to the correct path.

Check the client

There’s quite a few potential causes to a client not receiving updates. I’ll go through a range of troubleshooting steps and at the end give two scripts to “reset” the client if nothing else works.

Check free hard drive space.

Check the Windowsupdate log.
On Windows 10 open an administrative powershell prompt and run Get-Windowsupdatelog. The log will be on the desktop. Wait for the command to finish running.
On Windows 7 check C:\Windows\WindowsUpdate.log
This should indicate whether the issue is client based or a problem communicating to a remote endpoint.

The simplest first step in troubleshooting the client is to run the Windows Update Troubleshooter.
On Windows 10 go to the Microsoft iFixIt for WSUS site.
This will prompt you to download the Windows Update Troubleshooter (in cab file format). Save this and run.
Choosing Windows 7 on this page prompts you to right-click Network (in your system tray) and “Troubleshoot problems”. You can probably skip this step.

On Windows 10 try an online update check.

Check to make sure the service is running.
Get-Service -Name wuauserv

Next check and make sure client is receiving WSUS settings from Group Policy.
Run gpresult /scope computer to see if your WSUS settings policy is being applied to the machine.
Query client registry for WSUS settings with Get-ItemProperty HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate

Telnet can be used to check port connectivity issues. If you attempt a telnet connection to an open and accessible port telnet will open a new blank command window. If the port is inaccessible the command will simply fail. Try and establish a connection to the WSUS server and port. If the connection fails check firewall settings.
telnet 8530

Let’s use Powershell to test the connectivity.
Test-NetConnection -ComputerName <WSUS_Server> -Port 8530 -InformationLevel Detailed

Don’t forget the obvious step of checking the Event log.
Application Event log as well as App and Service Logs > Microsoft > Windows > WindowsUpdateClient

Sometimes anti-virus or other endpoint security agents can interfere with network communications. Consider disabling or uninstalling these for testing.

Run sfc /scannow from an administrative command prompt to check for file corruption that can affect the client.

If you have both working and non-working clients in WSUS check c:\program files\update services\WebServices\ClientWebServices for a web.config file and compare a working file to a non-working file for differences.

If this client comes from an OS image and Sysprep wasn’t run then the issue may be that multiple clients are using the same SUSClientID key.
Check HKLM\Software\Microsoft\Windows\CurrentVersion\WIndowsUpdate and delete the current SUSClientID.
Run wuauclt /resetauthorization /detectnow from an elevated command prompt.

The sequence below will clear out the local cache of the Windows Update client
attrib -h -r -s %windir%\system32\catroot2
attrib -h -r -s %windir%\system32\catroot2\*.*
net stop wuauserv
net stop CryptSvc
net stop BITS
ren %windir%\system32\catroot2 catroot2.old
ren %windir%\SoftwareDistribution SoftwareDistribution.old
ren "%ALLUSERSPROFILE%\application data\Microsoft\Network\downloader" downloader.old
net start BITS
net start CryptSvc
net start wuauserv
The sequence below will re-register a machine with the WSUS Server:
net stop wuauserv  
net stop bits  
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 "C:\WINDOWS\SoftwareDistribution"
net start bits
net start wuauserv
wuauclt /resetauthorization /detectnow (or usoclient.exe RefreshSettings)
PowerShell.exe (New-Object -ComObject Microsoft.Update.AutoUpdate).DetectNow()

Check the Server

Check free hard drive space, for the boot volume and repository volume.

Check the Windows Update service
Get-Service -name WsusService

Check the IIS service
Get-Service -name W3SVC

Is server listening? Check open ports.
netstat -an | findstr 853*

Can you browse to http://server:8530/ClientWebServices/client.asmx?
You should see a blue and tan Client Service info page.
If not, we can try resetting the port. Open an elevated command prompt and run wsusutil usecustomwebsite false. This will change the port WSUS uses from 8530 to 80, so make sure nothing is running on port 80.
Now run wsusutil usecustomwebsite true followed then by iisreset /restart. This changes the port back to 8530 and “resets” the configuration.

Check firewall rules.
Check server side logging: c:\program files\updateservices\logfiles\SoftwareDistribution
Run sfc /scannow to check for file corruption.

  • wsusutil.exe reset
    • Checks that every update metadata row in the database has corresponding update files stored in the file system. If update files are missing or have been corrupted, WSUS downloads the update files again.
  • wsusutil.exe checkhealth
    • Check Application eventlog for entries with source “Windows Server Update Services”
  • wsusutil.exe usecustomwebsite
    • Changes the port WSUS uses. Also “resets” the port during the change.


If you go to http://WSUS_SERVER:8503 you don’t see anything. This is normal.
To test IIS go to http://WSUS_SERVER:8503/selfupdate/ and you should be prompted to save the file.

Check for http connection errors in c:\windows\system32\logfiles\httperr\

Check IP bindings.
Check to make sure the Application Pool is running.

Check IIS logs for connection errors c:\inetpub\logs\logfiles
The default IIS installation by the WSUS installer doesn’t install logging component however.
You need to enable this under Manage Computer > Roles > Web Server > Web Server > Health & Diag > HTTP Logging

And there you have it. If following this guide didn’t fix the issue hopefully you at least came across the malfunctioning component and have a better idea where to focus your Google searches.