System Center Configuration Manager Feedback

Suggestion box powered by UserVoice

How can we improve Configuration Manager?

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:

526 votes
Sign in
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Umair Kazim shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      • Stefan Röll commented  ·   ·  Flag as inappropriate

        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

      • bdam commented  ·   ·  Flag as inappropriate

        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: 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.

      • Dustin Hedges commented  ·   ·  Flag as inappropriate

        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).

      • Anonymous commented  ·   ·  Flag as inappropriate

        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.

      • Glenn Turner commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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?

      • Duncan Galbreath commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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.

      • Harshal commented  ·   ·  Flag as inappropriate

        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.

      • DStarke commented  ·   ·  Flag as inappropriate

        With the new servicing model WSUS seems to require a lot more attention and cleanup which is very time consuming. Without manually cleaning up WSUS we are seeing a lot of WSUS sync issues, so an automated process would be helpful.

      • AFisher commented  ·   ·  Flag as inappropriate

        I would prefer to have CM not need wsus at all, and the SUP role do all the heavy lifting

      Feedback and Knowledge Base