In 2017 two customers at roughly the same time asked me to ‘fully automate SUM’, both requests were driven by the low skill level of inbound SUM admins, the intent was to reduce the work surface for these admins, basically take out much of the SUM activity at each Patch Tuesday so that they could focus on troubleshooting to soak up issue clients.
Before then I was never asked to trick-out SUM, simply stand it up against the requirements of the customer (Products, Classifications, Languages and Deployment Collections).
So I went to town on a simple PowerShell solution to flatten the SUM role down to just running a script each month, reviewing its output then monitoring deployment progress through the three atypical deployment rings of Hard Test, Pilot then Production. Rinse and repeat each month, leaving just Out of Cycle patches to be harvested and deployed if required.
The fruit of that labour was a complex PowerShell script that pretty much stood SUM up for the current months patches in less than half an hour. I wrote that script for those customers and won’t be releasing it to the community.
I set about converting the PowerShell script into a .Net Executable and came up with PatchMaster.
It has sat in the developer dock for several months with occasional coding sessions performed against it, mostly due to lack of time to develop it further, and because I had a few gnarly problems that turned each coding session into hand-to-hand combat.
Well I cracked open the source over the Christmas break and had another go, stepped back, thought about the problems from a different angle and hey presto, as if by magic, I broke through.
I decided today that I will not commercialise this tool for SMSMarshall, instead, I will give it away to the community for free.
It will take me a few more weeks to finish this off in my spare time.
In the meantime here’s some UI shots, Alpha, things will change and the skin will be given some proper loving closer to release, right now it is a functional UI used to drive the coding taking place.
Rules: Create a rule defining what you want PatchMaster to build out for:
Guide the deployments into collections:
Preview what will be created (Will fold this into the Naming Tab functionality):
Define how your SUG’s will be named, this functionality will be folded into Preview:
There is still lots of coding to be done, but I don’t see there being any further complex coding just what I call wiring code, which doesn’t need much more than time to lay down, no clever thinking needed, that’s all been done.
Be cool to hear how you’ve automated SUM, or what automating SUM would mean to you. Would PatchMaster rock your world?
I know a few SUM admins that still build things by hand each month, what a waste of resource, PatchMaster will give back time lost to SUM each month, at least until my other ‘plank’ is implemented via the Product Group, which is to extend out the ADR feature to handle creating new Packages at each run instead of just new SUG’s, which would literally kill PatchMaster overnight (it has a few features like SUG’s for Reporting purposes, rollups etc that would still be useful) … that idea was suggested at the recent MVP Hackathon in Seattle, but didn’t get any traction (that kind of annoyed me, lots, a real lot, at least one of my other ideas was coded otherwise that week would have been entirely social), but the idea may see the light of day in future releases of ConfigMgr if I keep pressing for it, or you’ll continue using something like PatchMaster to fill this (totally) obvious Management gap in SUM.
Right then, carry on with my Christmas break now, and when I get back to the House of Power (my England home) I will burn some time on PatchMaster development.