Share via

WSUS: Advanced Troubleshooting Guide

  • Article

Background

An issue with WSUS on Windows Server 2016 which resulted into computers not reporting correctly to WSUS.

Even when you think having configured everything correctly because computers where connecting to WSUS (they targeted the right WSUS groups from the Group Policy in the WSUS Console), they where not reporting their status to WSUS.

Tips

However many don't realize this, the most effective way to resolve issues is to understand the problem.

  • Don't just start to search the web blindly, get to know the (basic) inner workings of an application
  • Locate all the logging, many applications have documented default logging locations
  • If necessary, increase logging. Many applications have options to add information to logging.
  • Check if requirements are met

What is WSUS

WSUS is largely built on IIS (Microsoft Internet Information Services), .NET Framework and MMC (Microsoft Management Console).

It uses WID (Windows Internal Database) or Microsoft SQL Server as its database engine. It acts the same way as the publicly available Windows Update, but with WSUS you are able to deploy updates to your systems at your own pace and compliance requirements . Off course you are able to offload your internet connection by downloading your updates locally, but that never was my primary concern.

You can even create an Internet-facing downstream server, so that your systems download your own approved updates even outside your office(s).

This way you keep your systems up-to-date and/or secure (which off course is largely recommended), without your systems being incompliant to your own requirements.

Inner-workings

https://i-technet.sec.s-msft.com/dynimg/IC16980.gif

Figure: Overview of the WSUS process

Source: Microsoft Corporation - https://technet.microsoft.com/en-us/library/cc539281.aspx

This figure made by Microsoft shows how WSUS works.

Requirements

In the official Deployment Guide made by Microsoft, the first step it says is to ‘plan’ your deployment.

Immediately followed by requirements. First check if requirements are met (Reference 1).

In many cases the requirements are never checked when implementing a solution.

Even when you deployed it yourself, dare to second-guess yourself!

Depending on IIS, .NET Framework and SQL/WID, WSUS can actually get issues from configuration problems of these services.

Make sure you don’t just check WSUS, check all the parts that make WSUS.

For this the requirements are important, because these services are a requirement for a reason: they are important to WSUS its architecture.

Best-Practices

Best practices are never a requirement.

It can make sure an application/service runs at its best, but only requirements are needed for an application/service to run normally.

Logging

Logging you can find in the following locations:

Reporting to Windows Server Update Services on Client: C:\Windows\SoftwareDistribution\reportingevents.txt (this file is always there – even when using public Windows Update)

Log of retrieving updates on Client: Get-WindowsUpdateLog (generates a log file on your desktop from Event Tracing for Windows)

IIS on Server: c:\inetpub\logfiles (or check the inetpub location in IIS)

In the example I've set I said that computers had issues reporting.

I knew they connected to WSUS (otherwise group-targeting wouldn’t have worked), however they where not reporting status to WSUS.

This has led for me to check the reportingevents.txt on the client, since Windows Update was connecting to WSUS, just not reporting to it.

This is an example how you can use logging to support your first theories about the problem itself.

Coming to a conclusion

Coming to a conclusion with major WSUS issues can be a bit of a struggle.

WSUS is a complex product, reliant on many technologies.

A conclusion can’t be made before you know where the issues lie:

On the client or the server

In IIS or maybe SQL.

Make sure you know the issue, there always has to be a place where some error is reported in logging.

Example

However targeting worked (computers where placed in the right Computer folders in WSUS), computers wouldn’t report.

When I looked into the ReportingEvents log in C:\windows\SoftwareDistribution folder, it showed a error “Windows Update Client failed to detect with error 0x8024401c”.

However this error wasn’t consistent (sometimes it did succeed, but it mostly didn’t)

It looked rather odd.

Browsing the web more people are talking about issues in IIS.

So I compared the Advanced configuration of the WSUS app pool in IIS (server 2016) to an old environment I have built (2012R2), I saw it had an Private Memory Limit of 1.8GB.

Changing this to 0 (unlimited), computers immediately started reporting.

References