Hey everyone,

So at SCUG.no event Enterprise Client management last week (check out my blog post about the event here) MVP Jason Sandys talked a little about that it would be a good idea to make a script that declines updates of a certain keyword that you know you don’t want. That’s because there’s so much content in the WSUS library and being able to sort out things that’s not necessary for your environment is crucial to maintaining a lower DB size and better performance over all.

Luckily this is a super easy thing to do with Powershell but depending on how big your WSUS library is already it will take time for this script to run. In my lab environment i had about 2000 updates in my WSUS and just getting those updates with the Powershell Cmdlet Get-WsusUpdate took about 3 minutes or and i do some measurement later in this blog post just to show you but keep that in mind that his is not something that will be over in a few seconds because there’s so much data to gather.

I would recommend that you run this script locally on your WSUS to reduce any bottle necks and or other point of failures since the script will be running for quite some time or you could trigger the script remotely as a “Job” in powershell but if you want to keep it simple just run it locally.

The Script

$words = @("Flash","Bing","Beta") $updates = Get-WsusUpdate Foreach ($word in $words){ $updates | Where-Object {$_.Update.title -like "*$Word*"} | Deny-WsusUpdate }

Dissecting the Script

As you can see the script it’s self is fairly simple and the first thing we do is to state what kind of keywords we want to search for and decline in the $Words variable and in this case i’m using “Flash” “Bing” and “Beta” in an array. The second variable $Updates is where we get and store all the WSUS updates. Then we start a Foreach loop that first takes all the updates and pipes that to Where-object where we search for the updates who has that specific word in the title and then pipe that to the Deny-WsusUpdate Cmdlet.

Examples

Below i ran the script in my test environment and added the Cmdlet Measure-Command so we can get information on how long it ran for and i also ended with the method $Updates.count so show of how many updates there was in total in my WSUS library. As you can see it took 3 minutes and 5 seconds to run and the total updates where 2086. I forgot to add a count for the $updatesFilter variable in the photo but i went back and checked and there was 132 of them meaning there was 132 that got declined out of 2086.

If you now go in to WSUS and check which updates that has been declined it will look something like this

And last but not least if you haven’t already please check out Jason’s blog here because it’s just a true gold mine whit a lot of very good information.

Until next time, Cheers Timmy