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.
I tried … and failed … to implement Server Group Patching to automate patching our Exchange clusters. That doesn’t mean I didn’t learn a few useful things about how the feature works and how to troubleshoot it.
One of the exciting parts of the pre-release Server Group Patching feature is the ability to run scripts before and after the patching process. This is key to automating workload migrations in clusters like Exchange or SQL. While it sounds promising, reality is a little underwhelming.
Hoping to use the Server Group Patching pre-release feature to patch a group of servers in order? It appears to be broken. We are the real QA team.