WSUS Cleanup for ConfigMgr

WSUS Cleanup for ConfigMgr

Since ConfigMgr 2007 was released, the recommendation and firm statement from Microsoft has been to not perform any administration within a ConfigMgr integrated WSUS instance. In particular, performing approvals or declines was something you definitely should not do. Over the past year, two issues have cropped up to change this stance.

The first issue is the WSUS app pool crashing when overloaded. Kent has an awesome post this issue so I don’t need to rehash that here: House of Cards–The ConfigMgr Software Update Point and WSUS.

The second issue is the Windows Update Agent running out of memory (mainly on Windows 7 x86 systems). This resulted in lots of pain for anyone running Windows 7 x86 in their enterprise and eventually lead to Microsoft updating the Windows Update Agent in June of this year (2015). Since then, they’ve updated it every month (for Windows 7 at least). The latest update is at Windows Update Client for Windows 7 and Windows Server 2008 R2: October 2015 and Windows Update Client for Windows 8.1 and Windows Server 2012 R2: August 2015.

One thing that came out of these two issues is the recommendation to cleanup WSUS. The reason for this is that both issues ultimately stem from the WSUS catalog being bloated and causing the out of memory problems. Thus if you can slim down the update catalog served up by WSUS to the clients, the memory required to handle that catalog by WSUS and the clients will be less. Kent’s post linked above describes how to perform normal cleanup from the WSUS admin console as well as automating this using PowerShell. This is certainly helpful, but even with this, cleanup, the update catalog in WSUS will contain a lot of unnecessary updates including any superseded updates that simply bloat the catalog. As described at Support Tip: ConfigMgr 2012 update scan fails and causes incorrect compliance status, you can go into the WSUS admin console and decline these superseded updates (along with any others you know that you will never need). Doing this will remove the update from the catalog. The just linked post also provides a nice PowerShell script to automate declining superseded updates. Hint: If you don’t know PowerShell, learn … now. Cleanup is also described at Software update maintenance in System Center 2012 Configuration Manager and a complete rundown of the Microsoft recommendations is documented at The complete guide to Microsoft WSUS and Configuration Manager SUP maintenance.

Removing updates from the catalog, as mentioned, reduces the memory required by WSUS as well as reduces the memory required by the Windows Update Agent to perform its scanning. This in turn also reduces the download size of the update catalog, the size of the WMI repository on clients (since ConfigMgr does not have to store compliance info for the updates not in the catalog), and also decreases scan times (which can have a significant impact during update deployment in OSD) — lots of benefits all around.

In addition to superseded updates though, there are many updates in most update catalogs that most enterprises don’t and won’t ever deploy. Itanium updates are the first that come to mind but there others if you dig into the update catalog; e.g., beta updates and updates for Office Accounting. Just like with the superseded updates, you could go into the WSUS admin console and manually decline these. BOOOOOOO manual. So, just like the other cleanup processes mentioned above, a PowerShell script was in order to do this (download link below and on the Scripts FTW! page). Starting with the script for declining superseded updates, I created a script that will decline all Itanium updates, beta updates, and/or updates that contain a user-defined string in their title.

The syntax for this script is nearly the same as the Decline-SupersededUpdates script with the addition of three (self-explanatory switches): DeclineItanium, DeclineBeta, and DeclineOther. If you specify DeclineOther, you must also specify a string or a list of strings that will be matched against the title of all updates in WSUS (that are not already declined) and decline them for you. Easy peasy. The script dumps out a list of all updates declined to a .csv file in the same directory that the script is in. Make sure you run it first with the SkipDecline option though; this option will prevent the script from actually declining any updates but will still create a .csv file containing all updates that would have been declined. Review this list in detail and with care before running the script without the SkipDecline option.

Once declined in WSUS, the updates will no longer be part of the update catalog delivered to clients for compliance scanning. At this point, you should also perform an update catalog sync in ConfigMgr. This will mark the declined updates as expired in CoinfigMgr and is essentially the point of no return. After running the sync and letting it finish, remove the expired updates from any deployments (either manually or using a script like the one at Remove expired and superseded updates from a Software Update Group with PowerShell from Nicolaj). Through the expired update cleanup process described in  Software update maintenance in System Center 2012 Configuration Manager, these updates will then be completely removed from ConfigMgr. One word of caution here: Once expired and/or removed from ConfigMgr because they were expired, I don’t know of a path to getting the updates back. That’s not to say that there isn’t one, I just don’t know what it is. This isn’t a big deal though if you know the updates will never be deployed like superseded updates or Itanium updates.

Decline-OtherUpdates: Get it on GitHub
.local: Just Say No

Next Article

.local: Just Say No



  1. Outstanding Post!!! Great Script! I look forward your sessions at my first MMS in a few weeks!

    @ConfigMgrGeek – Twitter

  2. Thanks Jason, useful stuff. We’ve been battling this since this issue cropped up before the June update. Still on around 4,000 updates which are not declined but until we eradicate some of the OS versions from our environment this will be tricky to cut down further. The itanium updates were almost 700 strong so that was a decent chunk removed.

  3. I’m getting the following error:

    Connecting to WSUS server on Port 8530… Failed to connect.
    Error: Exception of type ‘Microsoft.UpdateServices.Administration.WsusInvalidServerException’ was thrown.
    Please make sure that WSUS Admin Console is installed on this machine

    My computer is Win7 and I have the WSUS console installed.

    • You’ll have to either run the script on the WSUS server itself or edit the script to connect remotely. The original script that was posted that I grabbed and modified had the remote connection capabilities disabled . From memory, I think there are just a couple of lines commented out, but don’t remember off-hand.

  4. Hi Jason,
    This is one of the best (if not THE BEST post) we have available around those crazy WSUS/SUP issues. It’s so handy how you put all the good references together here!

    If you can fix that, one of the (two) links to download the “Decline-OtherUpdates” is not working (

    You don’t have permission to access /wp-content/uploads/delightful-downloads/2016/12/ on this server.)

    I would like to contribute with another “official reference”:

    Additionally, I can tell you that I have been working with Microsoft Premier on a case and they must release a new hotfix and KB for the latest bugs on this area very soon!

    Just to reinforce the message, from my understanding, everything mentioned here is valid for WSUS 4 / WS 2012 R2.

    Thank you!

  5. Is this still available? The link ( returns:


    You don’t have permission to access /wp-content/uploads/delightful-downloads/2016/12/ on this server.


  6. Hello,

    Could you please fix download link for script?

    You don’t have permission to access /wp-content/uploads/delightful-downloads/2016/12/ on this server.


  7. With respect to declining “other updates” , is anyone using this script to decline Windows 10 Feature updates – such as the “N” versions, or the “retail” versions that are not deployed in your environment? I am curious if there is any harm (or gain) indeclining these? We deploy only the standard Education version of Windows 10 in our environment so I can’t see any value in these updates being in my SUS DB. Thoughts?

    • I haven’t tried explicitly but there’s no reason that this shouldn’t work.

  8. Jason…we have multiple software update points, none of them on the primary site server. Can this be run just on the SUP synchronizing with Microsoft or does it have to be run on all the SUPs? Thank you.

    • All WSUS instances in a ConfigMgr hierarchy are downstream from the WSUS instance on which the first SUP was installed and thus sync their catalog from this WSUS instance. Thus, you only need to run this on that first SUP and the declines will sync down from there. Not being on the site server is irrelevant.

  9. Hi Jason !

    It looks like the script Decline-OtherUpdates.ps1 is going to the local server all the time no matter of what the -UpdateServer say.
    I use this options:
    PS C:\newfiles> .\Decline-OtherUpdates.ps1 -UpdateServer “abc” -Port 8530 -Decl
    ineOther “Internet Explorer 8”
    My server name is not abc, but it declined 83 updates. I have 6 wsus servers in my sccm installation.

    But thanks for nice script !

    • When I originally modified the Microsoft provided script, their script had issues. I have a modified one where everything works that I need to post.