Dam Good Admin

Or at least not entirely useless

Software Update Maintenance Script Updated: All the WSUSness

I’m too tired for snark right now (damn MMSMOA prep) so this is going to be kinda straight.

Multi-Site/CAS Support

I’ve slowly but surely revising the maintenance script I wrote and released last year and occasionally updating it as things are pointed out.  I hope that by now multi-site/CAS environments are supported.  If you run such an environment please reach out and let me know if you have any issues.  Unlike users with a single site you may need to specify the site code when running the script.

Stand-Alone WSUS Support

I had a couple of questions or requests regarding stand-alone WSUS support.  While I really do think AdamJ’s maintenance script is better than mine in this regard there are a couple of benefits of running mine in tandem.  Mostly the logging (logging is godliness people) and the plugins.  So the script now supports three additional parameters: StandAloneWSUS, StandAloneWSUSPort, and StandAloneWSUSSSL.  There’s logic in there to make sure the rest of the parameters make sense and that you don’t try and do anything ConfigMgr related when StandAloneWSUS is specified.  See the full documentation here for more info.

I’ll warn you that I don’t plan on testing this use case extensively so if you encounter issues let me know and I’ll do my best to address them.

Forgive Me Father For I Have Sinned Support

The other problem users reported encountering early on is that the script would time out.  Running this kind of maintenance script has a catch 22 built into it.  In order to maintain the update catalog you need to get the catalog from your WSUS server.  That tends to timeout in an environment that has never seen maintenance.  Which of  course is the whole problem you’re trying to fix in the first place.  As if by magic, such environments have seemingly popped out of the woodwork last week.  In such environments manually running the WSUS Cleanup Wizard from within the WSUS Console tends to time out and crash at some point … maybe hours/days into the process.  To get the script to run successfully there’s a couple of things you can try.  First, restart IIS and run the script ASAP when it comes back up.  If that doesn’t work you can also try and block network traffic to the server so that WSUS isn’t trying to respond to clients while you try to maintain it. If that doesn’t work …

I’ve added a FirstRun parameter that directly calls the stored procedures laid out in MS’s compleat guide to yadda yadda blog post.  When used, it will connect directly to the WSUS database (SUSDB) and get a list of obsolete updates using the spGetObsoleteUpdatesToCleanup stored procedure.  It then loops through and deletes each one using the spDeleteUpdate stored procedure.  This mimics what the WSUS cleanup wizard does but with a 30 minute timeout instead of the default 30 second one.  Be aware that this may take hours, days, weeks, or even longer to complete.  However, it most likely will complete unlike the wizard.  Afterwards you should be able to run the script normally.

The FirstRun parameter should be considered experimental at this point.  I know it works but none of my environments have any obsolete updates to really test it against.  You know … because I’ve been maintaining it like a boss.

Ok, that’s it … go grab the latest version


  1. Your script works perfect. i have just one question?
    How to filter out the updates for ARM64 based systems (like KB4456655)
    is it just adding a name to one of the scripts or do you need to edit the scripts ?

  2. Hey Brian,

    Great script, just a quick question as maybe I am missing something.

    When I run the script I am using the same switches that you have documented however what I have noticed is while the expired updates no longer appear in my list of All Software Updates when I look at the deployment packages the expired updates still remain.

    Is there an easy way to clean these out? They show downloaded but not deployed which I guess is a good thing and I’ve checked the membership to see if the updates are part of a update group and they are not. It would be great to have a way to clean up the content stores as well as it appears I still have the content floating around out there in the ether and would really like to clean up these groups.

    For example I have an ADR for Endpoint Protection Updates. The Update Group has 13 items listed after clean up, yet the deployment package 2.9 GB and hundreds of expired package and the size on disk is over 9 GB. I looked at Nickolaj’s script, http://www.scconfigmgr.com/2017/08/17/clean-software-update-packages-in-configmgr-with-powershell/, and it seems to do the needful but I thought I would see if this is also something covered in your script.

    • Bryan Dam

      July 24, 2018 at 1:26 pm

      The script doesn’t currently do that though it wouldn’t be hard to add. However, there is already a background maintenance process built into ConfigMgr that does exactly that. So if you do nothing right now they’ll be removed from the deployment package within a week or so.

      What the script does do is compare the package source folder to the updates in the deployment package and removed any source data that’s been orphaned for whatever reason. In my experience it’s pretty rare for that to happen.

      • Curious as our deployment package for the ADR for Defender Updates has expired updates in it dated back to January, so even thought they were expired and they were still in the deployment package. Is there a way to kick off the maintenance process manually to see if something is amiss?

        Maybe its just us but I’m finding a lot of orphaned data still in the document packages. In most cases I have been able to reduce our footprint one some of the older packages significantly.

  3. Hello, I’m trying the StandAloneWSUS command and I’m getting the error “A parameter cannot be found that matches”.

    • Bryan Dam

      June 19, 2018 at 11:57 am

      That suggests that you aren’t specifying the WSUS server you are trying to connect to.

      • Hi, there are absolutely no records of the word ‘standalone’ in your script at all. Did you upload an old version by mistake?

      • I’m not a programmer, so I didn’t want to bother you, but yeah, I couldn’t find anything about standalonewsus when searching through the script. I was wondering if this was an upload of an older version too. Thanks for your help and work on this script!!

        • Bryan Dam

          June 25, 2018 at 9:43 am

          Ok, nope, I’m the idiot here. Somewhere along the line I screwed up a merge and overwrote the version of the script that has the stand alone WSUS functionality. I’ll have to sort that out and will reply here when that’s resolved.

          • Bryan Dam

            June 25, 2018 at 3:29 pm

            Just uploaded a new version that should have that functionality added back in.

  4. Do nothing, the user succesfully passed a hashtable. Good job user … good job. LOL That line made my day!

    • Bryan Dam

      June 14, 2018 at 6:22 pm

      Haha, awesome. Someone finally read the code close enough to see that little joke. Passing an array/hashtable is incredibly powerful but not straightforward to do.

  5. Dustin, I’ve gotta figure out what’s wrong with the email notification on my blog. The script fully supports the WhatIf parameter.

  6. Hey man, not gonna lie, this is pretty awesome. However I’d like to see a “LogOnly” parameter or something that actually just spits out what it “would” decline/remove/change vs. actually changing it and output that to a specified file for review.

Leave a Reply

© 2018 Dam Good Admin

Theme by Anders NorenUp ↑