Released V1.1 last night, while I was ‘adjusting’ back to UK time from Seattle time, I fixed up the problem causing V1.0 to become a Tech Demo with no fangs.
I let it run overnight, and all my minions are lined up for Windows 7, 8, 8.1 and 10:
We even have special Software Update Groups that you will use for product reporting per month, a rollup of a patches classifications per product:
The build out downloaded 48.9GB of Patch content! Stored in respective Software Update Packages and placed onto the DP.
So let’s get on with some brief instructions.
The way you use PatchMaster is you launch and configure it the once.
It stores its information in HKLM\Software\SMSMarshall\PatchMaster.
You then use it to find any released patches, and go ahead and build out.
PatchMaster fits in well with most environments, replacing most of the ‘human’ activity around building out a SUM Deployment. You can drop it in without making much change at all to the process overall, while hoovering up buckets of time that would otherwise be spent working SUM at each turn of the handle.
The impact PatchMaster has on Software Update Management comes from its ease of use, and is all about scheduling, how quickly you want to put patches into your environment. PatchMaster’s automation means you can go-fast with little administrative energy expelled.
You can go two ways:
A classical schedule recognises ‘Patch Tuesday’ and the Out of Cycle patch releases. You’d fire up PatchMaster on or after Patch Tuesday, or when you become aware of a patch that has been released or re-released, and begin building out. Patches are predictably released into the environment. This is how most of us do things now.
A zero-day patching schedule literally introduces patches into your environment as they are released, in a staged fashion. PatchMaster becomes a part of your morning checks routine, if any patches are noted you raise a Change Control, once approved you let PatchMaster do all the work from there, leaving just monitoring of the deployment during its up-take, reacting if there are critical errors amongst the early adopters. The Change Control process becomes the bottleneck in this model, but if zero-day patching scheduling is agreed upon from high-up, then Change Control becomes merely a formality for tracking purposes, as it should for patching.
I’ll produce a proper guide to PatchMaster once the dust has settled, for now, saddle up, take it into your dev\sandpit environment, have fun with it and once you’re confident take it into production.
I already plan to clean up the SUG’s, filtering out stale patches, removing entire SUG’s, all that stuff will come in the next big release.
It’s available on TechNet Gallery along with a bunch of my other tooling