Note: When updating you will need to update any existing plugins as well. Despite a seemingly quiet few months I have continued to enhance my script for maintaining software updates in WSUS and ConfigMgr. In fact, I’ve silently released new versions of the script from time to time by simply updating the binary hosted here. […]
The first release of my update reports was a total lie. There was absolutely no dashboard in what I called ‘Yet Another Software Update Dashboard’. I’ve fixed that.
Things got real last week and ‘all of a sudden’ organization realized that what the product MVPs have been saying for years is true and simply not optional: you must be running a software update maintenance script. I’ve updated mine to be more useful. Because I’m like that I guess.
Configuration Manager’s Automatic Deployment Rules are the ‘killer app’ that makes the product one of the most powerful tools for software updates. However, with that power and flexibility comes complexity that can be daunting for the uninitiated. In this post I try to brain-dump the lessons I had to learn when coming up to speed in the hope that it might help others.
When looking to prove that Configuration Manager was actually patching devices I quickly found the built-in reports lacking. I looked at existing solutions but I wanted something just stupidly simple that I could send to management and be informative at that level. At the same time I wanted to be able to drill-down so that administrators could identify and resolve any issues. Here’s what I came up with … let me know what you think in the comments section.
There’s lots of ways to define compliance but if/when you move to the cumulative update model the biggest question is simply: do I have the latest cumulative update applied. You’d think that’d be easy to report on but it gets messy quickly. Here I’ve released my first shot at it.
Installing updates during operating system deployment should be easy. I mean there’s a step called Install Software Updates for crying out loud. How hard could it be?
Historically it’s been considered taboo to touch WSUS when part of a Configuration Manager environment. Those times have now past and if you’re not actively maintaining WSUS on a regular basis it’s more than likely failing causing scan failures.
For well over a decade there’s been a social contract of sorts with Microsoft. Security patches are released on the second Tuesday of the month at 10 AM Pacific Time. They release and we start our patching processes. Well … what if they didn’t?
While some maintenance tasks have been long understood others have gained importance and understanding more recently. Either way, all of them should be fully automated as part of your patching process. I’ve created and released a script that does exactly that for every software update maintenance task that I can think of and does it in an extensible way that any organization should be able to utlize.