Author: Bryan Dam (page 2 of 3)
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?
It has not been a good year for hardware manufacturers or the companies that slap parts together to create end-user devices. Apparently when they write drivers the put safety first and security was somewhere on the second page. Here’s how I’ve been trying to handle this. If you have a better way, I’d love to hear it.
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 reasons you may not want to share at Configuration Manager administrator parties you may find yourself managing clients that are not domain joined. Often administrators assume Configuration Manager can’t do that or is severely limited. Read on for all the gory details.
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.