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.

Invoke-DGASoftwareUpdateMaintenance 1 file(s) 60.79 KB Download

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