Recently I got on a kick to fully automate everything I could as it relates to software updates in Configuration Manager. While other scripts exist I wanted that one script to rule them all. I also wanted it to be completely PowerShell, flexible enough so that it could work in nearly every environment, and have decent logging. I believe I’ve achieved those goals and encourage you to try it out and give me any feedback you may have:
09/19/20: Latest version is 2.5.1
First A Word from My Legal Department
For the love of all you hold dear, test the ever-living-crap out of this script by running it with the -WhatIf switch and pouring through the logs to understand what the script would do. I also recommend using the UpdateListOutputFile parameter to output a comma-delimited list of updates that will be declined. Seriously, anything you do to your organization with this script is totally not my fault. Once an update has been declined in WSUS and synced to Configuration Manager I honestly don’t know how you bring it back. I’m … sure … there’s a way somehow.
Edited to Add: Jon Warnken over at mrbodean.net answered the question I was too lazy to even ask. To bring back a declined update you can approve it in the WSUS (via the console or script) and then initiate a full sync. When you sync updates from within the console you only do a delta or incremental sync so that won’t work To fully synchronize it must be initiated by the Configuration Manager sync schedule or via a script. John provides the few lines of codes needed to so in this blog post. If you’re using my Invoke-DGASoftwareUpdatePointSync script to schedule the syncs after Patch Tuesday those will work as well.
What Can it Do?
The script can be used to do any or all of the following:
- Detect if a synchronization is occurring and wait for success before resuming.
- Decline superseded updates.
- Decline updates by a list of titles.
- Decline updates based on external plugin scripts.
- Output a comma-delimited list of declined updates.
- Run the WSUS Cleanup Wizard.
- Initiate a software update synchronization.
- Remove expired and declined updates from software update groups.
- Delete software update groups that have no updates.
- Combine software update groups into yearly groups.
- Set the maximum run time for updates by title.
- Remove unneeded files from the deployment package source folder.
- Update the deployment packages used by ADRs either monthly or yearly.
- Directly call the stored procedures to delete obsolete updates.
- Add crucial indexes that make WSUS run faster overall.
- Delete updates that have been declined from the WSUS database entirely.
What, Where, When, and How?
While the script’s parameters can be called directly, the download includes the configuration file that I use in my production environments. The script will default to that configuration file if no other parameters are provided. The only change required to make actual changes is to remove or comment out the WhatIfPreference parameter. Before doing that though be sure modify the configuration as desired, run it, and review the logs to confirm that it would perform the actions you desire. That allows you to call the script very simply:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -executionpolicy bypass -noninteractive -File \\#PATH TO SCRIPT FOLDER#\Invoke-DGASoftwareUpdateMaintenance.ps1
Currently this script must be ran on the primary site server as it makes certain queries to WMI classes that only reside there. If I was a better person or developer I could probably figure it out. Unfortunately I’m neither of those things. In theory, when 1706 hits critical mass the newer cmdlets could allow it to be more portable but I don’t really see the value. If you do for some reason, let me know the use case. The user running this is going to need a lot of permissions to a bunch of things and the primary site’s system account is perfect on that front.
The script is designed to be ran between the time your Software Update Point(s) sync updates from Microsoft and when your ADRs run. This allows the plugin scripts to preemptively decline updates that ADR selection can’t properly filter. Nothing prevents you from running it any time you like of course. In fact, if you have not been maintaining updates I recommend running this manually outside of your normal patching cycle first.
To make this all happen automatically, I super highly recommend you create a status filter rule that triggers based on the update synchronization ending successfully. To do so, create a rule that runs your desired command when the SMS_WSUS_SYNC_MANAGER component sends a status with message ID 6702. Should look a little like this:
Warning: Do NOT use the -Force parameter when creating the status filter rule if you are also using the ReSyncUpdates parameter. That will create an infinite loop whereby the script is triggered by a synchronization and then initiates another synchronization.
Plugin Scripts You Say?
At some point someone is bound to ask ‘can it decline this’ and the answer will always be yes. Simply take the template plugin script file I’ve provided and use it to add whatever bat-shit-crazy logic you want in order to add updates to the DeclinedUpdates hash table. One of the key use-cases for plugin scripts is to to fill gaps in the Automatic Deployment Rule (ADR) filtering capabilities. There’s a limit to the logic that such filters can support. The logic you can put in a PowerShell script is only limited by your imagination, ability, and the data at hand. By declining updates and initiating a sync before the ADRs run you can filter out updates that ADR selection cannot. Be warned though, it is not a simple matter to bring back declined updates so there is a certain amount of risk in declining updates before you even get to see them in the Configuration Manager console.
I have provided a set of standard plugins that you can make use of. To do so you must first move them out of the Disabled folder and into the root of the Plugins folder. Running this set of plugins alone has declined over 900 updates in my environment. Note that some plugins will need to be edited before you can run them.
- Decline-Office365Editions: Use this plugin script to decline Office 365 editions that you do not deploy. If you leave the LatestVersionOnly variable at its default value of True the script will determine what the highest version is for each edition and decline older versions. This is particularly important for editions like the Semi-Annual edition that has multiple supported versions. You will need to un-comment and fill in the SupportedEditions array. Any edition not listed will be declined. This script has a variable called KnownEditions that lists all currently known editions which are matched against each title. This will hopefully prevent the script from going awry when the Office product team decides to get drunk, bring out a dart-board, and come up with a new naming scheme. When they do, you will have to update this variable.
- Decline-Windows10Editions: Use this plugin script to decline Windows 10 feature updates for editions you do not support. Like its Office 365 brethren it has the same SupportedEditions variable you will need to modify and the KnownEditions variable you may need to manage in the future. With the release of Windows 10 version 1709 all editions are now packaged in two editions (whose updates were named exactly the same … sigh) and each duplicated for x86 and x64. So long term I don’t think this plugin will be needed.
- Decline-Windows10Languages: Use this plugin script to decline Windows 10 updates for languages that are not configured to download software update files in the site’s Software Update Point component. I don’t know why the Windows 10 feature updates ignore this setting but it does and this solves that problem. There’s nothing to configure here but if you are using ADRs or manually downloading updates for languages not configured in the component I recommend not using this plugin script.
- Decline-Windows10Versions: Use this plugin script to decline Windows 10 updates for versions your organization no longer supports or never deployed in the first place. This script has a variable called UnsupportedVersions that you must un-comment and enter the list of versions (ex. 1511) that you do not support. Updates matching one of these versions will be declined.
Here’s the summary of declined updates after running this in my production environment for the first time. This environment was around two years old at the time and had never been maintained apart from Configuration Manager’s built-in feature to run the WSUS Cleanup Wizard.
All Updates = 10921
All Updates Except Declined = 9768
All Superseded Updates = 5141
Superseded Updates Declined = 4979
Updates Declined by Title for *Itanium* = 807
Updates Declined by Title for *ia64* = 46
Updates Declined by Title for *Beta* = 7
Updates Declined by Title (Total) = 860
Updates Declined by Plugin for Decline-Windows10Languages = 312
Updates Declined by Plugin for Decline-Windows10Versions = 38
Updates Declined by Plugin for Decline-Windows10Editions = 496
Updates Declined by Plugin for Decline-Office365Editions = 58
Updates Declined by Plugin (Total Unique) = 904
Total Newly Declined Updates = 6435
Total Active Updates = 3333
You’re reading that right. By running this script I have reduced the number of updates every single device in my organization scans against from 9,768 to 3, 333 … a 66% reduction. That’s the kind of thing that makes a huge difference in terms of WSUS and Windows Update Agent performance. It’s enough to be the difference between success and failure.
I have only tested this script on Current Branch 1702 and above. Some or all of the script may work on earlier versions but I don’t have the resources or inclination to create that many test environments.
The WSUS console and cmdlets must be installed.
The Configuration Manager console and cmdlets must be installed.
The script must be ran on or from the primary site server.
The user needs to be part of the WSUS Administrators group on SUPs.
The user needs full access to the deployment package source folders.
The user needs the appropriate rights in SCCM to modify the objects your chosen parameters will impact.
So yea … run this as the primary server’s system account. Use psexec /s /i cmd.exe to do so.
Every parameter listed below is optional but you must select at least one of the action parameters for the script to do anything. I have provided extensive documentation within the script itself and running Get-Help should really be all you need. But you’re lazy. I’m lazy. We’re all basically lazy. So here you go:
Loop through the software update Deployment Packages and remove any sub-folders whose name does not match a GUID of an update in the package.
Loop through every Software Update Group and remove any expired or newly declined updates.
Path to an INI file containing the configuration you wish used. If the script is ran with zero parameters then the script will default to using a configuration file named config.ini in the root of the script directory.
Combine Software Updates Groups so that only the provided number of groups exist per Automatic Deployment Rule. The first group created for a given year will be renamed by having its timestamp truncated to just its year and will have the remaining groups updates added to it.
Loop through every PowerShell script file (.PS1) in the Plugins folder relative to the script and call its Invoke-SelectUpdatesPlugin function. This allows users to decline updates using whatever logic they desire. The download includes some examples as well as a template to build from. In order to use the provided plugin scripts you will need to copy them from the Disabled folder into the root of the Plugins folder. Some of them need to be edited before they are ran. See the Plugin Script section above above for more details.
Provide an array of titles that will be used to decline updates in WSUS. Wildcards are of course supported. Note that passing in an array via the command line is a bit tricky and you must use the -command option when using this parameter. See the example above for how to do this.
Only declines updates that do not supersede other updates. Must be used with the DeclineSuperseded parameter. Honestly, I have no idea why you want to use this but I put this in for completeness as compared to other scripts.
Declines updates that are superseded in WSUS. Refer to the DeclineLastLevelOnly and ExclusionPeriod parameters for options regarding which superseded update you decline.
When this switch is used the script will track the date that it declines updates using a datafile stored in the script’s directory. When the update has been declined for longer than the configured ExclusionPeriod the script will delete the update from WSUS entirely using the WSUS API calls. This can drastically reduce the amount of data stored in the WSUS database.
An array of strings that can be used to exclude updates from certain products from being declined regardless of the method used to decline them.
An array of strings that can be used to exclude updates from being decline regardless of the method used to decline them.
An integer that controls how many months to keep updates before declining and/or deleting them. When declining updates this is based on the creation date of the superseding update rather than the superseded update. When deleting updates this is based on when the script declined the updates. This parameter must be used with the DeclineSuperseded or DeleteDeclined parameters and only impacts those two features. If this parameter is not defined then the script will use the exclusion period configured in the Software Update component for declining superseded updates or default to 3 if used in WSUSStandalone mode.
If your environment or a the environment of a close ‘friend’ has never been maintained and the script times out when ran then run the script manually one time using this option. 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 24 hours 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 script creates an empty file in the its directory to mark the last time it ran and will not run again if that file is newer than 24 hours unless the Force parameter is used. Be very very careful with this parameter. If used in conjunction with the ReSyncUpdates parameter as part of a status filter rule you can create a forever loop.
An array of string that can be used to define which products to decline updates from. No updates outside of the listed products will be declined.
Specify an alternate log file path. By default the script will create the log in the same folder as the script.
Specify the maximum size of the log file before it rolls over and rename the current log with the ‘.lo_’ extension. The default is 2 MB.
Provide a hash-table where the keys are titles and the values are the number of minutes to set matching updates’ maximum run-time to. Wildcards are of course supported for the titles. Note that passing in a hash-table via the command line is a bit tricky and you must use the -command option when using this parameter. See the example above for how to do this.
Remove the custom indexes from the WSUS database if they exist.
Remove any Software Update Groups that do not contain any software updates. Must be used with the CleanSUGs parameter.
Initiate a full Configuration Manager software update synchronization. This will run after the updates have been declined in WSUS and will expire the declined updates in Configuration Manager.
Runs the WSUS Cleanup Wizard with all the options selected after declining updates. Even though Configuration Manager includes this feature now I’ve included this for completeness. To be honest, I’m not certain what Configuration Manager is actually doing on this front. I’ve had the built-in feature enabled from day one and yet when I ran this manually in my environments the first cleanup run took 1-2 hours and cleaned up thousands of items. Subsequent runs took minutes. As an added bonus it will write the results to the log file.
Provide the site code of the site you wish to connect to. By default the script will try to identify the site by the PS-Drives available or from the registry. In environments with a CAS this parameter must be provided.
If you wish to run the script against a stand-alone WSUS server then specify the FQDN of the WSUS server using this parameter. When doing so the script will prevent you from also including parameters that only apply to a Configuration Manager environment.
If you specified the StandAloneWSUS parameter you may optionally specify whether to connect via SSL or not. If this parameter is not used the script will try to connect without using SSL.
If you specified the StandAloneWSUS parameter you may optionally specify the port to connect upon. If not specified the port will default to 8531 if the StandAloneWSUSSSL switch is used and 8530 if it is not.
Specifies the number of minutes to wait after a software update synchronization has occurred before continuing script execution. The default is 5 minutes.
-UpdateADRDeploymentPackages [string (‘Yearly’,’Monthly’)]
Creates new deployment packages on either a yearly or monthly basis and updates the ADRs to use them. When used, the name of the deployment package and the source folder for the package must end with four digits that represent the desired period. For yearly packages a four-digit year (ex. 2017) must be used and for monthly packages use YYMM (ex. 1710 for October 2017).
Specify a file path where the script will output a comma delimited text file listing the details of every update it declines and the reason why it was declined.
Check for and if necessary create additional indexes that help run WSUS perform better. This feature is highly recommended and can be crucial to successfully running the FirstRun feature or the WSUS Cleanup Wizard in general. Note, these indexes are not supported by Microsoft.
Last, but not least, use this to test what the script will do without making any changes. Refer to the log or use the UpdateListOutputFile parameter to output a list of declined updates.