RootUsers

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.