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.

[ms_button style=”normal” link=”https://github.com/jason4tw/ConfigMgrScripts/blob/master/SoftwareUpdates/Decline-OtherUpdatesWithExclusionPeriod.ps1″ size=”medium” shape=”rounded” shadow=”yes” block=”no” target=”_blank” gradient=”no” color=”#4f4f4f” text_color=”#ffffff” icon=”fa-github” icon_animation_type=”” border_width=”0″ class=”” id=””] Decline-OtherUpdates: Get it on GitHub[/ms_button]