Pretty much rounding off the UI logic after major coding underneath.

Rule system is pretty much done now:

Deployments can be assigned to individual Device Group members, get’s complicated, but you can carve out as many server (or client) deployments as you want (so as to stagger\stage):

If you use RBA to split off admin and read access to SUGs then the Security Scopes feature  will let you go crazy with permissions:

If you want patches to be ignored, you can jot them down here and PatchMaster will ignore them, useful if there are select patches that must not be deployed (IE related stuff for example):

Ok this looks a real mess right now lol, it’ll get some loving soon, but here you can extend ot the Device Group entries, opening things up quite a bit for Security Scopes and Deployments:

Here’s the latest patches that haven’t been downloaded and deployed based on the rules you’ve defined, at about this point things get exciting because if there are no patches listed, there is nothing to deploy, so opening PatchMaster and eyeballing here let’s you know if there’s any need for action:


This is where I’ve spent the last several hours of coding time on PatchMaster, getting the SUG names formatted correctly, and then coding the Out Of Cycle stuff:

This is so cool, it handles Out of Cycle releases with ease, you can run the tool pretty much any day a new patch is out to scoop it up:

And that light brown bar:


You pretty much drag the order around, and add too it by selecting one of the buttons:


A right click removes the entry, like this:


You set the format of the SUG up and leave it alone. I see this being setup with Year, Month, Product, Classification so as to avoid the massive amount of Patches per SUG caused by Windows 7 and Windows 8, then a month later changing to Year, Month, Product, net result will be less SUG’s.

I’ve configured for all Windows 7, 8, 10, Server 2012 R2 and 2016:

And we get a whopping 1,878 patches returned, those are the latest patches that are applicable for deployment:


I’ve told it to use SUM – <PRODUCT> – <Out of Cycle> as the SUG name format:


Note the patch count (total items) per SUG in the above shot.

Here’s the same patches but using SUM – <PRODUCT> – <Classification> – <Out of Cycle> as the SUG name format:

I envision that you’ll spend your first hour configuring this tool, then every time there is a need to push out patches you’ll launch it, go to the Preview tab and click Build Payload, and that’ll be SUM administration over with for you, leaving you the monitoring side to turn too.

You’ll only need to turn to admin tasks in the worst case scenario, where you want to stop patches going out. So you’d have to disable offending deployments via PowerShell, the SCCM Console or perhaps I’ll build something like that into PatchMaster.

Clean up, you can see a tab in the screenshots called Software Update Cleanup, the plan for V2 is to allow you to clean up SUG’s etc that contain stale patches, keeping object growth to a minimum while still pushing out everything that is needed (not superseded etc).

So when will this be released, alas we’re looking at a few weeks from now.

I’m pretty much just tidying up the UI and existing code, and then its full focus on actually building the Software Update Groups for Deployment, SUG’s for Reporting purposes, Software Update Packages, deploying them to the DP, and then creating all the deployments.

Bit of a grind to knock that lot out, so before I begin I’m hovering over what’s already written to fix and tighten things up, still things that are a bit wobbly.

I might beta the UI soon, as it’ll run on a Site server just fine, it just won’t build anything, fit for seeing what patches are there and what SUG’s it would create and non-development environment testing (real world testing).