Update 2018-04-20: I’ve rolled the information in this post and updated it, into a new post about setting up a WSUS server from scratch on Windows Server 2016 Core. The post is also suitable for a regular Windows Server 2016 server with a GUI. You can read it here.

I’ve been dealing with some issues with a WSUS server recently. It services around 1000 devices, mostly Windows 10 with some Windows 7, Windows Server 2016/2012 R2/2012 and 2008 R2. The WSUS server provided updates for a variety of Microsoft products including Office, Exchange, SQL, Visual Studio, Windows Defender to name a few. The WSUS server is running on Windows Server 2016 Standard which is WSUS version 10.0.14393.1066 although I’m sure these configuration tweaks could benefit previous versions too. The WSUS database is the Windows Internal Database. The issues I’d been experiencing were the Error: Unexpected Error/Reset Server Node (Event ID 7053) issue, generally bad performance, and Windows Update timing out when searching for updates (0x8024401C).

Thankfully the issues were easily resolved, here’s what I found. Firstly to tackle the performance issue. I’d setup a Scheduled Task to run a PowerShell script, weekly, to clean up the WSUS database, but this had stopped running due to a username/password error. This was easily fixed. As the script had not run in a few weeks I sensed that the script was going to need some time to run, so I decided to increase the specification of the WSUS VM first. The number of clients that it was expected to service had increased over time too, so I felt it was only right I do this. It was running on 2 vCPUs and 4GB RAM, I increased this to 6 vCPUs and 8GB RAM. Once I’d done this, I ran the script. After an hour or so, it failed which I consider to be normal when database maintenance hasn’t been done in a while. I ran the script again and after a few hours it completed successfully. I increased the schedule of the script to run daily instead of weekly. I also updated the script to add logging and to email the log when it had completed running - something I had been intending to do but not got around to.

Here’s the completed script for you to use. The logging and email sections of the script follow the same conventions I’ve been using for my Image Factory and Hyper-V backup scripts.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

# -------------------------------------------
# Script: wsus-maintenance.ps1
# Version: 1.1
# Author: Mike Galvin twitter.com/digressive
# Date: 24/04/2017
# -------------------------------------------
 
##Set Variables
$wsussrvr = "wsus1"
$wsusport = "8530"
 
##Set Log Location
$log = "E:\scripts\wsus-maintenance.log"
 
##Set Mail Config
$toaddress = "[email protected]"
$fromaddress = "[email protected]"
$subject = "WSUS Maintenance"
$mailserver = "mail.contoso.com"
 
##Start Log
Start-Transcript $log
 
Get-WsusServer -Name $wsussrvr -PortNumber $wsusport
Get-WsusServer | Invoke-WsusServerCleanup -CleanupObsoleteComputers -CleanupObsoleteUpdates -CleanupUnneededContentFiles -CompressUpdates -DeclineExpiredUpdates -DeclineSupersededUpdates
 
##Stop Log
Stop-Transcript
 
##Send Mail
$body = Get-Content -Path $log | Out-String
Send-MailMessage -To $toaddress -From $fromaddress -Subject $subject -Body $body -SmtpServer $mailserver
 
##END

Now that the general performance and house keeping had been done I left the server along to see how things went for a a day or two. After a day performance was better but I still had some timeouts with Windows 10 clients detecting updates. On previous versions of WSUS I’d always tweaked the IIS Application Pool settings and so far hadn’t had to do that with the Server 2016 version, so I decided to make some changes there.

Here’s the changes I made

Changed the Private Memory Limit (KB) to 0 - This actually removes the memory limit. I’d actually suggest making it slight less that the memory available on your server, but I’ve not had any issue from setting this to 0 yet.

Change the Service Unavailable Response from HttpLevel to TcpLevel - The documentation states that change this to TcpLevel will reset the connection rather than return a HTTP 503 error. I found this via a Google Search and haven’t had any issues since making this change.

Change Limit Interval (minutes) from 5 to 15 - This specifies the reset period for the CPU monitoring and throttling limits for the application pool.

Change the Queue Length from 1000 to 2500 - This increases the queue length for the application pool.

I’m not convinced that I needed to do all four of these changes. I think the changes to the Private Memory Limit and Queue Length were necessary but I’m not so sure about the others. I’d suggest that you might want to show more restraint that I did at the time and make one change at a time to see if it solves the issue.

After making these changes the performance of the WSUS server was greatly increased and the Windows 10 clients detected updates without issue, and continue to as I write this.

If you have any questions or comments please leave them below.

-Mike