Still Using WSUS? Here’s a Quick Fix (and Prevention!) for Potential WSUS Woes

Fifteen years ago, if you had Active Directory, it was very likely you also had a WSUS (Windows Server Update Services) server as well. WSUS is available as a role to be installed on any Windows Server operating system at no extra cost. Its main purpose is to house Microsoft updates for the Windows operating system and other Microsoft products. This way, when computers on the network start to download the updates, they can just pull them across the local LAN connection instead of downloading the update for as many times as you have computers needing it. It also does light accounting for which machines have which updates installed on them and what updates they may be deficient in. The last selling point would be for larger environments where you may have a staging environment along with a production environment. With WSUS, you could approve and test new updates from Microsoft on your staging environment before pushing those same updates out to your production environment.

However, with prices of broadband going down and the work force not always coming into the office to work, having WSUS in your environment isn’t a given any longer. Also, there isn’t much benefit to WSUS if you are not going to be actively managing it. I have done more work removing WSUS from environments lately than installing it in new environments.

Troubleshooting WSUS Errors

However, one environment chose to use WSUS only for the tracking of updates, not for the repository of updates. When I configured WSUS for them, I came across an issue. After it was set up, about every few days, when launching the WSUS console, I would get the dreaded error with WSUS with the fix that never fixes WSUS—Reset Server Node.

The error is very optimistic that simply clicking this button will resolve all the issues, and the console will just load as it should. I don’t believe I’ve ever had that work, although I always click the button a few times just to see if it will magically work this time.

WSUS runs on IIS (Internet Information Services), the Microsoft web server. Inside of IIS, it runs off an application pool called WsusPool. If something stops this application pool, the console to WSUS will not connect. In my case, the application pool stopped.

Simply starting the application pool would make WSUS responsive again, but in two or three days, the application pool would stop again.

The problem turned out to be that the WSUS application pool was using too much memory, which caused it to shut itself down. The fix is right here in IIS. Right click the pool and go to Advanced Settings.

Scroll down to find Private Memory Limit (KB) in the Recycling section. Previously this was about 1.8GB, which doesn’t take WSUS that long to use when it is synchronizing and automatically approving many updates. If all this server is doing is WSUS, you can comfortably change the value to 0 (no limit).

If you find yourself deploying WSUS, go ahead and make this change to the application pool from the start and save yourself some troubleshooting time.

Have any other WSUS troubleshooting questions? Do not hesitate to contact us at any time.