WSUS server repeatedly runs out of disk space every 1-2 months despite cleanup - what evidence should be collected before expanding storage?

Before approving more storage, collect evidence in this order:

1. Confirm whether local WSUS storage is still the right design.
   • With local storage, approved update files are downloaded and stored on the WSUS server.
   • Microsoft states WSUS needs at least 20 GB for local update storage and recommends at least 40 GB.
   • If clients have good Internet bandwidth but slow WAN access to WSUS, remote storage on Microsoft Update can reduce local disk use.
2. Measure what is consuming space.
   • WSUSContent / update file store: this is the primary place to check because locally stored update binaries are usually the largest consumer.
   • SUSDB: metadata is stored in the WSUS database, not in the content folder.
   • IIS / WSUS operational state: repeated pool recycling can contribute to WSUS instability and failed client scans, though not directly to content growth.
3. Verify that cleanup was complete, not just “run.” Essential WSUS maintenance from the provided guidance includes:
   • Run the Server Cleanup Wizard.
   • Remove unused updates and update revisions.
   • Remove older unapproved updates and revisions.
   • Delete client computers that have not contacted the server in 30 days or longer.
   • Delete update files not needed by updates or downstream servers.
   • Decline expired updates.
   • Decline superseded updates only when all documented conditions are met.
4. Check whether approved superseded updates are blocking cleanup.
   • If updates were autoapproved, they can remain Approved and not be removed by the Server Cleanup Wizard.
   • To make those superseded updates eligible for declination, approval must at minimum be manually changed to Not Approved.
   • The wizard then verifies that a newer update is approved and that no client still needs the older one before declining it.
5. If the environment is hierarchical, verify cleanup order.
   • Cleanup should be run on the lowest downstream/replica WSUS server first, then move upward.
   • Running cleanup upstream first can create database mismatches and synchronization failures.
6. After large cleanup activity, collect post-cleanup maintenance evidence.
   • Microsoft recommends reindexing SUSDB after large deletions because indexes become fragmented.
   • Then run the WSUS Server Cleanup Wizard.
   • Then run IISReset or recycle the WsusPool application pool to clear cached catalog state.
7. Review WsusPool settings if the server shows instability during scans or sync. Recommended settings in IIS Manager > Application Pools > WsusPool > Advanced Settings:
   • Queue Length: 2000
   • Idle Time-out: 0
   • Ping Enabled: False
   • Private Memory Limit (KB): 0
   • Regular Time Interval (minutes): 0
   • The guidance also says to disable virtual and private memory limits by setting them to 0. Repeated recycling can cause HTTP 503 scan errors and force cache rebuilds.

Evidence to collect before concluding storage must be expanded:

• Current size of the local WSUS content directory.
• Current size of SUSDB.
• Results of the Server Cleanup Wizard, especially whether it removed:
  • unused updates/revisions
  • obsolete computers
  • unneeded update files
  • expired updates
  • superseded updates
• Whether superseded updates are still Approved because of autoapproval.
• Whether the server is upstream or downstream in a hierarchy, and the order cleanup was run.
• Whether SUSDB was reindexed after major cleanup.
• Whether WsusPool is recycling because of default IIS memory and timeout settings.
• Whether private update files imported from Microsoft Update Catalog were present, because cleanup removes those and they must be reimported.

How to identify orphaned or unnecessary content:

• Use the Server Cleanup Wizard item that deletes update files not needed by updates or downstream servers.
• Also remove unused updates and revisions, decline expired updates, and handle superseded updates correctly.
• Do not manage WSUS by directly editing the database; Microsoft warns this can corrupt WSUS and block future upgrades.

What the provided guidance supports as likely causes:

• Expected growth from choosing local storage for update files.
• Incomplete cleanup, especially superseded updates left Approved by autoapproval.
• Stale client records not removed.
• Fragmented SUSDB after large deletions, followed by poor maintenance.
• WsusPool recycling and cache rebuild behavior causing operational issues.

What is not supported by the provided guidance:

• A Microsoft baseline for normal monthly WSUS growth.
• Product-specific attribution of growth to drivers, feature updates, languages, or legacy products.
• A supported reporting method in the provided material that breaks growth down by those categories.
• Quantified field examples of reclaimed storage from similar incidents.

Practical conclusion: If the content directory is the main consumer, cleanup results show little reclaimable content, superseded/expired updates are already handled, obsolete computers are removed, SUSDB has been reindexed, and local storage is still required by design, then storage expansion is justified. If any of those checks fail, the evidence points to a maintenance or configuration gap first.

References:

• Plan your WSUS deployment
• Server cleanup wizard
• Resolved: Windows Server Update Services sync operations issues and timeouts | Microsoft Support
• Windows Server Update Services best practices