Tag: Configuration Manager (page 1 of 2)
1/9/19 Update: The most recently released SSU (KB4486458) was given a distinctive title (2019-01 Servicing Stack Update for Windows 10 Version 1703). If Microsoft is reliable in this (to be determined) you could create an specific ADR for them and deploy ahead of your regular scheduled patch cycle. Still seems kinda janky to me though. […]
As a rule, you shouldn’t need to do this but there is currently a specific use case where you will. The impact of getting it wrong is not pretty so learn from my mistakes. Then vote on UserVoice to make the whole thing just go away.
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.
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 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.