Need WSUS Maintenance tasks
There should be a few built in maintenance tasks to go through and complete all the maintenance tasks that are needed for WSUS. I find having to run through these steps every month to be quite tedious requiring a lot of change control each month to get the maintenance work completed for WSUS.
Everything described in this article should be automatically done by CM: https://blogs.technet.microsoft.com/configurationmgr/2016/01/26/the-complete-guide-to-microsoft-wsus-and-configuration-manager-sup-maintenance/
This is in 1806 TP
Where and How do you use it. I am running 1806 and can not seem to find anything.
Currently 1806 has WSUS cleanup but it only runs update cleanup on CAS and Primary sites. There is no mention of the indexing of WSUS or extending this option to Secondary Sites. Will the update cleanup be expanded in a future release to encompass everything in the blog. https://blogs.technet.microsoft.com/configurationmgr/2016/01/26/the-complete-guide-to-microsoft-wsus-and-configuration-manager-sup-maintenance/
Where is it in TP 1806?
Jose Riano commented
how come no support for secondary sites?
Stefan Röll commented
Configure all WSUS Servers as Replica of the top level WSUS. With that configuration you only have to clean-up updates (decline superseded, remove unneeded etc.) on the top level WSUS.
For all replica servers, you only need to run the SUSDB reindex script to keep them happy
Can you add update group cleanup and package cleanup.
Exemple from Nikolaj : https://github.com/SCConfigMgr/ConfigMgr/tree/master/Software%20Updates
And other exemple from Bryan : http://damgoodadmin.com/2018/04/17/software-update-maintenance-script-updated-all-the-wsusness/
Maybe it find a place in site maintenance. :-)
Agreed, but in the meantime AdamJ's cleanup script does all the hardwork ;)
There's a whole bunch of stuff that needs to be done to keep WSUS afloat.
SQL maintenance for one. There's already discussion about handling that better for the CM DB so it seems logical to extend that to the WSUS DB(s) as well. Let's use the local admin and SA right for doing good. I imagine the WID use case is a complicating factor there.
Fixing ConfigMgr's use of the WSUS cleanup wizard is another. In every environment I've seen, the wizard as ran by ConfigMan doesn't seem to do anything. Despite ConfigMgr running the wizard for years simply running it manually has always cleaned out thousands of updates and computers. There's practically no logging so that would be an easy baby step ... put the results of the API call into the ConifgMgr logs to show what was done.
The most important thing though, the thing that's going to have the most impact, is actually declining updates in WSUS. It's the only way to decrease the number of updates in the catalog that WSUS has to generate and cache and that clients scan against. The WSUS cleanup wizard will _never_ decline updates because ConfigMgr never approves updates which is a documented requirement of the wizard. A pretty straight-forward first step would be to decline updates that ConfigMgr expires based on the supersedence rules. I already have a UV item for this here: https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/19709440-when-expiring-updates-based-on-supersedence-rules. To really make a difference though you have to go beyond just superseded updates and decline updates you will never deploy. A bunch of ways to approach that. The simplest is to allow users to manually decline from the console. A simple automated solution could be to mimic the supersedence process but for updates that haven't been deployed in X months since their released/modified date. More complex could be a reverse ADR of sorts that lets you decline certain category of updates (ex. Itanium, x86, Security Only). Literally anything that declines updates in WSUS would be a huge step forward.
Matt Schultz [BCBSNE] commented
Agreed, having CVE info in the metadata for reporting would be helpful for our security team.
Dustin Hedges commented
Would love to see CVE information pulled in as metadata so we can provide reporting to our InfoSec teams based on CVE (since that seems to be all they care about lately).
Also configure or recommend (in Status messages) the WSUS best practice configuration, like, recommended Windows CUs, AppPool Private Memory Limit, ASP.NET timeouts, Queue Length, ... There is many articles around, like
Also add filtering (declining) of unneeded updates (x86, Itanium, ...) would be very welcome.
Nectarios Gritzalis commented
Please don't forget about SUPs that are not on the primary site.
Glenn Turner commented
Perhaps also do a cleanup of the content share and the distribution points after the updates are expired in case there are orphaned distribution packages
Mark Brown commented
Whilst this is not directly a WSUS server issue, it is related: When the "WSUS house of cards" collapses and wua client scans timeout, the 10 minuite wua scan retry interval causes as the entire client estate to DDOS' the already overwhelmed WSUS.
Can this timeout interval be made configurable in client settings? Would you like me to raise a separate uservoice for this?
Jayson Gabler commented
Good idea, why are we still having to do this manually?
Duncan Galbreath commented
This is especially painful for hierarchies with several remote secondary sites. A lot of manual maintenance that must be done to avoid major issues.
Chris Trees commented
The WSUS cleanup checkbox does not do all the required actions to keep the SUP in a healthy state. Definitely need a complete solution for this.
Anoop C Nair commented
Isn't this already started https://www.anoopcnair.com/setup-wsus-cleanup-task-sccm-console/ ?
WSUS is a pain point with no improvements over the years for it. WSUS also needs an upgrade and should take care of all cleanup when we select option in SUP setting. We need option to select schedule for cleanup and which cleanup to be running selection checkbox with logging that what is really getting cleaned.