WSUS Internal Database grabbing a lot of RAM

My utility server runs DC, DNS and WSUS. I back it up with a Barracuda agent. Sometimes I have difficulty backing it up because WSUS grabs a bunch of RAM and there isn’t enough room for the barracuda agent to run. I mistakenly thought adding more RAM would solve the problem, but from what I’ve read WSUS is greedy – using more RAM as I make it available.

My network consultants want me to build another server just for WSUS, but I don’t have the Server licenses for it and another server would take me over the RAM need for VmWare HA.

I found this article which seems to set limits for WSUS RAM used by the internal database but I don’t really understand how to do what it suggests.

I do have SQL installed on my Great Plains accounting server. I asked our consultants if I could put the WSUS database there but run WSUS from my utility server. They said it wasn’t worth the time.

They also said the fix mentioned in the article was only temporary and that I’d have to constantly fiddle with it.

Can anyone help me keep WSUS from gobbling up RAM? Because I’ve rejected their “build a new server” idea, it seems our network consultants have washed their hands of me.

Your consultants are right in the fact that if you’re running WSUS at any scale it should really be on its own VM. That said, there really isn’t a strong argument to run WSUS anymore. You really need to take a look at Windows Update for Business and shift compatible systems to that. If you’re left with a couple older systems you can either just registry configure them to pull all updates or keep a neutered WSUS around just for them.

Yep, Like @CGreenTX advises, WSUS makes less sense these days, particularly in the era of Windows 10, work-from-anywhere, and cloud first. Personally, once I experienced setting update policies in Intune, I embraced that and never looked back! The cost of M365 is pretty negligible for churches and definitely worth considering for managing your endpoints, especially if your server is long in the tooth.

Does Windows Update for business support Server 2012? Server 2019? Microsoft Office? SQL server? It seems like it only mentions Windows 10?

Do I need a separate server for it?

I’m running 4 RDS servers, a file server and a Great Plains Server. I need to keep them up-to-date.

Windows Update for Business (WUfB) is just an endpoint update tool. It will update all Microsoft products on the endpoint, including drivers and firmware if you are on Surface, or if your OEM pushes their driver packages to WU (which many are now doing.)

WUfB does not update servers or server applications. Microsoft does have a modern solution built into azure, which can be bridged out to onprem systems - but I don’t recommend that unless you have a lot of servers.

When running modern servers such as Server 2016 or 2019 with only windows services, you can just turn the built in auto-update on and let them run themselves. For legacy servers like 2012, for servers running LoB apps (CHMS, ERP, CRM, etc etc), or for servers running RDS - I really want that to be an active patching process. Meaning that we schedule automatic updates to download but not install the updates, and we schedule a monthly patching window where we manually patch and verify functionality after patching.

WSUS is increasingly incompatible with modern Windows 10 endpoints, and can lead to all manner of breakage. Even if you don’t retire it now, you should be planning on retiring it for your Windows 10 endpoints over the next year or so.

All that said, if you are just letting WSUS patch everything right now without any manual intervention, you can just turn on auto-updates via GPO or registry file and let the whole process ride. I would recommend WUfB and auto-updates or an active maintenance window for your servers as the need dictates - but even auto updates are reliable if pushed via policy.

Bottom line is you are in a place where you must invest energy into fixing something broken. I’d recommend you at least consider moving in a direction compatible with Microsofts product roadmap.


I’ve been using WSUS so long, how do I unravel it? Do I just uninstall it and delete the group policy settings?

Then do I have to deploy this new service?

Most of my windows 10 devices are laptops. My big problem with laptop users is that they don’t ever power down which means updates download but don’t install.

Without WSUS to tattle on laptop users, how will I know if updates are installed or stuck in this netherworld waiting for a reboot that never happens?

@Kpapalia -

Windows Update for Business (WUfB) is fantastic for modern day work as it solves so many of our long standing problems. It allows you as an admin to specify how quickly you want to install patches, and when they need to be installed by. But once you have done that, windows kicks in to help the user patch. Large patches are pre-installed in the background so they apply quickly. If a reboot is needed, windows will present a very intuitive popup, letting users choose when and how to patch within the window you allow. In many circumstances windows will automatically patch the machine without user interaction due to it’s off-hours patching logic. If the user avoids patching repeatedly, it will (gracefully) force a patch cycle on the user.

Across our client base, we went from less than 75% patch compliance^ to a 98% patch compliance^ just by swapping to WUfB.

If you want to report on patch health, you’ll need InTune and to setup patch compliance reporting. But honestly unless you have a regulatory reason to do that - I probably wouldn’t bother. So long as the machine has the policy applied, the new patching system is very steady state. That is to say it does what you tell it to do.

As for how to unravel WSUS - it’s relatively straight forward, although takes a bit of work.

The rough sequence is as follows, however whoever you get skilled technical support from should be able to help you through the exact machinations for your environment.

  1. Separate your WSUS settings into it’s own GPO.
    1.If you are going to keep WSUS for servers, then separate out your servers into their own OUs, and build dedicated GPO’s for those OU’s that continue to enforce your current WSUS policies.
  2. Revert the GPO Policies pushing clients to WSUS to their default values*
  3. Wait until all workstations have checked in
  4. Remove the WSUS GPO on the relevant OU(s)
  5. Using your RMM, or via pushing the app via login script or GPO - push a Windows update registry key reset script to the OU(s) effected by this change.**
  6. Wait until all workstations have checked in / applied the reset script.
  7. Build a GPO with your desired WuFB settings and apply it to the network***
  8. Wait until all workstations have checked in, spot check on a few machines to ensure they have the settings.

It is very much worth the effort. Beyond the whole impending “need” to get off WSUS, it’s just a better solution. It’s much more user friendly, administratively friendly, and end-state determinate.


*do not remove the policies, rather set the entries back to their default configuration

**I don’t typically recommend random scripts to run - you should determine what your estate looks like and push a targeted solution. But if you need an example, check here

*** If you are using InTune, I would recommend you do it there instead of GPO. But assuming you aren’t using intune, GPO works fine. Microsoft has a great jumping off document on this here

^ Compliance as defined by successfully applying patches within 10 days of release of patch. Numbers are sampled monthly, and averaged over 12 months