Troubleshooting guide for issues where WSUS clients are not reporting in

  • Article

image

This guide is written to assist specifically in troubleshooting WSUS when clients are not reporting in. We will examine common troubleshooting considerations that needs to be looked at on the WSUS server only, not on the WSUS client.

GPO considerations:

The first consideration is to see if the WSUS GPO has been configured and linked to the proper OU in Active Directory. Frequently I will see how the GPO might not be linked or configured. Often the WSUS server name might be incorrect or WSUS server name are configured with the incorrect port number in the WSUS GPO.

In GPO Management (or Active Directory Users and Computers), make sure the WSUS GPO is created and linked to the OU that contains the machines that is suppose to get the GPO settings for WSUS. Open up the GPU to:

Computer Configuration > Administrive Templates > Windows Components > Windows Update

As a minimum we have to enable 2 settings:

  • "Configure Automatic Updates"
  • "Specify intranet Microsoft update service location"

For the latter setting, often the server name is incorrect or the port number is not included. Confirm the port number in IIS and ensure it is included if it is not port 80. Example: "https://update.server.com:8530" . Remember to set the "update server" and the "statistics server" location.

The above is the minimum needed in any GPO for WSUS to function.

Permissions:

We have 2 types of permissions to be concerned about: NTFS permissions on the WSUS Server as well as IIS permissions and security. Sometimes if these permissions are not correct it prevents the WSUS webservices in IIS from functioning correctly and thus WSUS clients can not report in.

HTTP 401.3: DENIED BY RESOURCE ACL:

Frequently if your WSUS client (Automatic Update Agent) is healthy and your GPO is offering the correct WSUS server and port information and you still do find that WSUS client are not reporting into the WSUS console, then permissions on the WSUS server are most likely the problem.

It is not always NTFS security that is the problem, but could be IIS permissions. If you are outright getting a 401.3 error you know to focus on NTFS permissions. But, I recommend to always run Process Monitor when you start troubleshooting WSUS to make sure WSUS has all the permissions it needs on the file system and in the registry.

On the WSUS server, download Process Monitor from https://technet.microsoft.com/en-us/sysinternals/default.aspx. Follow the following steps:

1) Go to https://technet.microsoft.com/en-us/sysinternals/default.aspx

2) Look on the right-hand side and download "Process Monitor" (AKA: PocMon)

3) Extract it on the WSUS server and run "procmon.exe"

4) Click on "Filter" >>"Filter"

5) Set "Display Entries Matching These Conditions" to:

- RESULT - CONTAINS - DENIED (you have to type in the word DENIED) then INCLUDE

6) Click "Add"

7) ALSO Set "Display Entries Matching These Conditions" to:

- PATH - CONTAINS - CERTIFICATE (you have to type in the word CERTIFICATE) then EXCLUDE

8) Click "Add", "Apply" then OK

9) Stop and Start the "World Wide Web Publishing" Service

- Wait 30 seconds

10) Stop and Start the "Update Services" Service

- Wait 30 seconds

11) Go back to ProcMon

This filter will show all processes that issues an ACCESS DENIED event. For the most part your concern is to look at both W3WP.EXE (which is IIS) as well as both WSUSSERVICE.EXE and SQLSERVR.EXE.

Notice any ACCESS DENIED events and see if they were denied to a registry key or a file on the file system for the 3 above mentioned services. If you find any ACCESS DIENIED for any of the above processes denying the user account "Network Service" access, that registry key or file would need permissions set to allow the "Network Service" to have FULL CONTROL to the respective Registry Key or File. Give the permissions accordingly and keep track of the changes you make. Once you have assigned a permission, close ProcMon, run it again and see if the permission error comes up. By doing this you will make sure WSUS has all the NTFS permissions it needs to function.

** ALWAYS BACKUP YOUR REGISTRY BEFORE MAKING ANY CHANGES **

NOTE: To close ProcMon.exe properly, click on FILE >> (Uncheck) CAPTURE, then FILE >> EXIT

Some common files/folders for WSUS that needs to be confirmed that they have FULL CONTROL set for the "Network Service" account are:

  • <%windir%>\Microsoft .NET\Framework\<version>\Temporary ASP.NET Files
  • <%windir%>\Microsoft .NET\Framework\<version>\CONFIG
  • <%windir%>\Temp
  • C:\temp
  • C:\WSUS\WSUSContent
  • C:\Program Files\Update Services\WebServices

Permissions Related - IIS:

In addition to NTFS permissions occasionally being incorrectly set for WSUS, from time-to-time we find IIS permissions being incorrect or out of sync. Ensure that IIS Virtual Directories (vDir's/webservices)) are set as shown below:

image

After you have confirmed the security and had to make a change to it in IIS, remember to do a IISRESET. If there are other websites on the server in addition to WSUS, do a stop/start of the WSUS website.

Confirming your WSUS server permissions and IIS security is healthy:

Once you have made all the needed security changes to NTFS as well as IIS, re-run ProcMon a few times and ensure no ACCESS DENIED events, it is time to test the health of the WSUS server.

Look in the Application Log to see if you had prior "Windows Update Services" errors. Open a command line and run the following:

CD c:\Program Files\Update Services\Tools

wsusutil checkhealth

This will initiate a WSUS healthcheck and force events to be written to the Application log. If all of the security changes you made earlier rectified the health of WSUS you should see no "Windows Update Services" errors. If the issue you were having were security related, most often prior to start fixing the issues you would have seen the following Event ID's: 12052, 12042, 12022, 12032, 12012 and/or 12002.

Re-run Procmon (with the same 2 filters we added before) and re-start IIS wait 30-seconds then re-start the "Update Services" service. If ProcMon still gives no more ACCESS DENIED events other than the CERTIFICATE events, you would have to look into resetting the IIS IUSR account.

How to identify what HTTP 401.x error you might be experiencing:

When we troubleshoot WSUS clients that are not reporting into the WSUS server we frequently might be experiencing a HTTP 401.x error. There are 2 ways to see which 401 error you might be having 401.1, 401,2, etc. One way is to open one of the URL's below from the WSUS-client and see if you are getting a HTTP 401 error:

  • https://servername/SimpleAuthWebService/SimpleAuth.asmx
  • https://servername/selfupdate/wuident.cab
  • https://servername/clientwebservice/susserverversion.xml
  • https://servername/content/<valid-sub-folder>/<valid-filename.CAB

The second way is to open the IIS Log on the WSUS server. This file is located in C:\WINDOWS\system32\LogFiles\W3SVC1. Find the log file with the most recent date. In the log file you will see references to the WSUS vDir's: APIRemoting32, Selfupdate, SimpleAuthWebservice, Content, etc. To see if you are Getting 401.x errors you must look at the complete line of the log entry. Here is an example:

2009-01-27 16:45:10 W3SVC310782280 10.10.1.10 HEAD /selfupdate/wuident.cab 0901271645 8530 - 10.10.1.43 Windows-Update-Agent 401 1 0

Above you can see an HTTP 401.1 being generated on the SelfUpdate webservice.

HTTP 401.1: DENIED BY INVALID USER CREDENTIALS:

This error code will have you focus on the credentials of the IUSR account. If you are receiving a 401.1, from a WSUS perspective it means we have to go and look at IIS to make sure the IUSR username and password is correct for Anonymous access on all the WSUS vDir's. Occasionally the IIS guest account (IUSR_ account) has it's password out of sync between the IIS Metabase, Active Directory OR SAM (depending if the IUSR account is a local or domain account) and the credentials entered as the Anonymous user and password for the WSUS Virtual Directories in IIS. We need to make sure that the correct user account and credentials are used at 3 places:

  • In Active Directory or Local Account.
  • In the IIS Metabase.
  • In IIS for each of the 9 WebServices under the "WSUS Administration" (or Default) Website.

Ensure that the IUSR account is not locked. Sometimes a 401.1 error could be caused by a locked IUSR account. Then query the IIS Metabase to establish what the existing IUSR password is:

Edit c:\Inetpub\AdminScripts\ADSutil.vbs

Search for the line that reads "IsSecureProperty = True" and change it to "IsSecureProperty = False". Save and close the file.

From command line run:

Cscript adsutil.vbs get w3svc\anonymoususerpass

This will return an output like this:

anonymoususerpass : (STRING) "ThisIsTheIUSRaccountPassword"

Take note of the password, INSIDE of the quotes. The quotes are not part of the password. For safety, copy it into notepad.

Go to either Active Directory (if a domain account is used for the IUSR account) or find the LOCAL ACCOUNT for IUSR. In most cases IUSR will be a local account. Reset the password for your IUSR account with the password we just pulled from the IIS Metabase.

Open IIS Manager and expand the WSUS (or default) website where the WSUS Virtual Directories are located. Right-click on the vDir >>Properties >>Directory Security >>EDIT. Update the IUSR account with the password we pulled from the IUSR Metabase. Do this for each of the below vDir's:

  • ClientWebService
  • Content
  • DSSAuthWebService
  • Inventory
  • ReportingWebService
  • ServerSyncWebService
  • SimpleAuthWebService
  • SelfUpdate

If WSUS is the only website on this server, do a IISRESET. If it is not, just stop/start the WSUS Administration website in IIS.

IMPORTANT: If WSUS is the only website on your server you will be safe to reset the IUSR account. If it is not the only web application running on your server, consider copying the old IUSR account and create a new account called something like IUSR_WSUS and use this account and its password to configure your WSUS vDIR's in IIS.

HTTP 401.2: DENIED BY SERVER CONFIGURATION

If you are getting a 401.2 HTTP error it will steer you in the direction of looking at IIS configuration once again. Most often you will have to review your IIS webservices for WSUS and look at the Authentication Configuration that has been set for them. Make sure they are configured as per the above table named * WSUS website IIS webservices configuration. Look at the properties of a webservice >>Directory Security tab >>EDIT (Authentication and Access Control), and make sure they are set as explained in the above table named: * WSUS website IIS webservices configuration.

For More Information see KB907273 - Troubleshooting HTTP 401 Errors in IIS

Justin Luyt | Senior Support Engineer