Troubleshooting Guide to WSUS

I have had an issue with WSUS on Windows Server 2016 which resulted into computers not reporting correctly to WSUS.

Thinking that I have 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.

Actions Required To Troubleshoot These Issues In WSUS

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.


Figure: Overview of the WSUS process

Source: Microsoft Corporation –

This figure made by Microsoft shows how WSUS works.


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 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 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.


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.


Reference 1: Requirements by Microsoft for WSUS (Chapter 1.1 Plan your WSUS Deployment – Review considerations and requirements) –
Reference 2: Troubleshooting IIS issues
Reference 3: How to read the Windows Update Log File
Reference 4: Changing the inetpub location

Sync AD Groups with Microsoft Teams (BETA)

Microsoft Teams doesn’t allow you to define a group for membership (dynamically).
When you add an Azure AD group to a Team, all users will be added once.
Once someone is added to that group, it won’t be added to the team automatically.

For this I created this script.
You define an Active Directory group and a Microsoft Team to manage.
All users that are in the AD group, but aren’t in the Team will be added (as a member).
All users that aren’t in the AD group, but are in the Team will be removed from the Team.
Offcourse except owners.
If an owner is in the Team, but isn’t in the AD Group it will generate a warning and continue.

You can find it on Technet Gallery:

Step 1:
Create an Service Account in your Active Directory domain.
This service account needs an UPN suffix with a verified Office 365 domain.

For example: It can be, but cannot be user1@contoso.local.
Where is added as a verified domain in Office 365.

Sync your Active Directory domain with Azure AD (it normally does every 30 minutes automatically).
Also make sure the Service Account has read-rights in your Active Directory.

Step 2:
Go to Office 365 and add an Office 365 license to the Service Account (with the Teams subscription).

Step 3:
Go to and add the service account as an owner of the Teams you want to manage from AD.

Step 4:
Add the users of the Teams you want to manage to the AD groups you want to sync.

Step 5:
Add AD Groupname and Team name you want to sync to Teams.csv (example csv is in the zip-file), with a comma as a delimiter.
Every line is an Active Directory group and Team that needs to be synced.


Step 6:
Run Powershell as the service user and browse to the location.
run Set-SecureTeamUserInfo.ps1 and type in the credentials of the service account (UserPrincipalName, not SamAccountName).
Credentials are now securely saved in the folder so the script can sign in to Office 365.

Posted in Scripts, Teams



Problems with WSUS on Server 2016

Yesterday I have had an issue with computers not reporting to a newly installed WSUS server.
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 this was the issue: 

On Windows Server 2016, the “Private Memory Limit (KB)” was set to 1.8GB.  

You should reset it to 0, so that WSUS can decide the memory usage of the WSUS Application Pool.
Once set, all issues with WSUS were gone.
Computers started reporting in immediately (off course this depends on the reporting configuration in your Group Policies). 

Deploying an RDS farm in an Server Core environment

Note: The RD Web Access role requires Desktop Experience; In Server 2016 you can’t change between core and desktop anymore. 

First of all, I have made a script that will install and configure all roles and tools.
It installs the management tools on the server which the script runs on (from this server you can manage the core RDS environment).
Then it will ask on what servers which roles needs to be installed.
Find it on Technet 

After everything is installed, add the servers to server manager on the management server.
However already installed and configured, you need to add the license server and RD Gateway to the farm.
It is already connected to the Connection Broken, but are not automatically detected by Server Manager. 

Afterwards you should use Server Manager to add certificates to the RD Access Roles.
I would use a Wildcard certificate for RD Gateway and RD Web Access, since they are accessed over the internet.
Certificates for the broker role can be issues by your own CA, or if you use a public domain name in your internal domain (example, I would request an additional wildcard certificate for your internal domain. 

The first part of the installation can be accomplished by following the steps in the RDS Farm setup script, the second part you’ll need to do using Server Manager. 

Saving on certificates in an multi-tenant Exchange environment

By default, alot of companies buy certificates for Exchange based on the domains that are added to Exchange.
While a company is expanding, it can be very expensive.

In an organization using enormous amounts of domains, it can be challenging to keep up with certificates.
These issues you don’t have with Office 365, since Microsoft is responsible for Autodiscover.

When hosting your own multi-tenant Exchange environment, you can actually use an SRV record instead of an CNAME or A record.
This way it will announce that the corresponding service is hosted elsewhere.

This way you only need the (likely wildcard) certificate of the providing company.
You have an serviceprovider called Adatum Services, which hosts
The IT admin adds a domain ( to the multi-tenant Exchange environment.
Instead of adding an A record to the Exchange Client Access Server, you add an SRV record telling the Outlook client that the Autodiscover service is hosted elsewhere: on

The record for would look as:
Name: @
Protocol: TCP
Port: 443
Service: _Autodiscover
Priority: 10
Weight: 1

Now you don’t have to make changes to your certificates, everytime an domain is added to your Exchange environment.

Posted in Collaboration, Exchange (General)



User interaction script for SCCM

This script (made by me) allows you to use user-interaction to notify your users about an installation or update of software.
It also allows you to push an installation (with administrator priviliges), while still including the user in the process.

If there is no interaction within 20 seconds per notification, it will go on.

You can also specify a process to check, and notify the user that the application needs to be closed to continue the installation (if the process is running off course).
It will re-check every 20 seconds, but will not continue until the process is closed.

This means that if the user isn’t behind his/her desk, and nothing conflicting is running, it will continue.
This makes the process of installing and updating software a lot more user friendly, but will not compromise compliance.

Download from Technet