This post will cover some basic methods to troubleshoot and fix common problems with Microsoft’s Windows Server Update Services (WSUS).
This post is part of our Microsoft 70-744 Securing Windows Server 2016 exam study guide series. For more related posts and information check out our full 70-744 study guide.
WSUS Server Checks
First we’ll cover some things to check and confirm on the WSUS server itself.
Check WSUS Service
The first thing you’ll want to do is check that WSUS is actually running and working as expected.
PS C:\Users\Administrator> Get-Service -name WsusService Status Name DisplayName ------ ---- ----------- Running WsusService WSUS Service
In this instance the WSUS service is reporting as running. If it’s not you can run the ‘Restart-Service -name WsusService’ to attempt to restart it. This service runs as the Network Service user by default.
Check IIS Service
Additionally we need to ensure that the W3SVC service is running which is IIS, as this is the service that actually listens for incoming connections on TCP ports 8530 for HTTP and 8531 for HTTPS. This service runs as the local system account by default.
PS C:\Users\Administrator> Get-Service -name W3SVC Status Name DisplayName ------ ---- ----------- Running W3SVC World Wide Web Publishing Service
Again if this service is not running, try the ‘Restart-Service -name W3SVC’ command to restart it. Once it’s running, we can use the netstat command to confirm that the WSUS server is correctly listening for incoming traffic on these ports as demonstrated below.
PS C:\Users\Administrator> netstat -an | findstr 8530* TCP 0.0.0.0:8530 0.0.0.0:0 LISTENING TCP 0.0.0.0:8531 0.0.0.0:0 LISTENING TCP [::]:8530 [::]:0 LISTENING TCP [::]:8531 [::]:0 LISTENING
Here we can see that our WSUS server is indeed listening on both 8530 and 8531 on both IPv4 and IPv6, so it looks good in that regard.
Check Port Connectivity
Just because the WSUS server is listening for connections on the correct ports does not mean that your client machines are able to connect in. By default Windows firewall will be running on the WSUS server, however when you installed WSUS it would have automatically configured two inbound rules called “WSUS” that allow both TCP 8530 and 8531 through, as shown below.
Check that these allowed inbound rules are still in place, and if not either enable them or create new ones as needed.
Check Log Files
Finally if everything on the server side is looking good, take a look at the WSUS log files. If you find any specific error messages here they should be detailed enough for you to perform further investigation (aka stick the error into Google).
- C:\Program Files\Update Services\LogFiles\Change.log – This file contains information about things that have changed in WSUS, it may be useful for seeing any recent changes that have taken place and caused the problem you’re having.
WSUS Client Checks
Now that we have confirmed that things look good from the perspective of the server we’ll perform some checks from the client, that is the Windows computer that connects to the WSUS server to download updates from.
Check Windows Update Service
In order for the Windows client system to actually perform Windows update, the wuauserv service should be running. If this service is not running, Windows update will not be able to run so restart it if required. This service runs as the local system account by default.
PS C:\Users\Administrator> Get-Service -name wuauserv Status Name DisplayName ------ ---- ----------- Running wuauserv Windows Update
Check Port Connectivity
As we have confirmed that the WSUS server is both listening on TCP ports 8530 and 8531 with appropriate Windows firewall rules, we will now confirm that we can connect to these from the client system. By default Windows firewall allows all outbound traffic, so by default Windows firewall on the client system should not prevent the outbound connectivity unless you’re running custom rules.
Additionally this does not cover any other firewalls that you may be running between the client and WSUS server, so check these are also configured with appropriate rules if you have them.
My favourite way to quickly test port connectivity in Windows is with the telnet client which must first be installed. Once installed it’s as simple as specifying the WSUS server and the port that you want to test, as shown below.
PS C:\Users\Administrator> telnet wsus.example.com 8530
This can be run through either Command Prompt or PowerShell. If it is successful, the screen will go blank. You can quit the telnet client by pressing the Control and ] keys, followed by typing quit and pressing enter.
For further information on how to test port connectivity, see our guide on pinging ports.
Alternatively you could also try to load the http://wsus.example.com:8530/Selfupdate/ (replacing wsus.example.com with your own WSUS server) page from a clients browser, if successful the page should just be plain white with no source. If you get some other error connecting then this may indicate a problem.
Check Group Policy
If the connectivity is looking good then you may next want to confirm the correct group policy is actually being applied to the client that is having problems updating. We can view the Resultant Set of Policy (RSoP) with the gpresult command, as shown below. The /r parameter is used to show the summary data only.
Applied Group Policy Objects ----------------------------- Default Domain Controllers Policy Default Domain Policy WSUS
We can see that our ‘WSUS’ GPO is indeed applied to this client computer that we ran gpresult on.
We can take this a step further and also check that the registry entries have been set as per the GPO. In the image below we are looking at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate which shows us the name of our specified WSUS server and target group that are set in the WSUS GPO.
Check Log Files
Finally if everything on the client side is looking good, take a look at the Windows update log files. To generate these, run the ‘Get-WindowsUpdateLog’ PowerShell cmdlet. This will write the WindowsUpdate.log file to C:\Users\<user>\Desktop\
Summary
The information here should give you some ideas of things to check when you encounter problems with WSUS so that you can fix common issues. The important things to remember are the location of the log files so that you can quickly identify what the problem actually is and then investigate further from there.
This post is part of our Microsoft 70-744 Securing Windows Server 2016 exam study guide series. For more related posts and information check out our full 70-744 study guide.
Hi Jarrod,
I have checked each of the items above and my server is set as such, but i am still seeing the Red X on the WSUS server and it says “computer has not reported status in 90 days.” The computer being the WSUS server itself. so weird. How can i force it to manually report to the WSUS server IP address?
thanks much,
-L
Actually the powershell command is: Get-WindowsUpdateLog
Typo I guess, missed the ‘-‘, fixed thanks.
I have followed all of these steps. Everything that I checked gave me the expected response, however, my client displays “Checking for updates” for several minutes and then the message is displayed:
There were some problems installing updates, but we’ll try again later. If you keep seeing this and want to search the web or contact support for information, this may help: (0x800704cf)
I have a long list of WSUS servers in my mmc tree. When I exit, half of them disappear. I add them back, exit the console, and they disappear again. Someone please help???