Currently working for a customer who is transitioning their Patch workload from WSUS Standalone to ConfigMgr, and I’ve introduced PatchMaster to automate the middle part, the actual monthly work, leaving them to keep an eye on Reporting, and reacting to Out of Cycle patches if needs be.

They asked me for a unique scenario:

  • Security and Critical Updates must induce a controlled reboot (count down, UI experience)
  • Tools, Update Rollups and Updates must not induce a reboot

How did I model this using PatchMaster?


Firstly I created two new Device Groups:

  1. Win10-Critical-Security
  2. Win10-AllOther

I changed the following Deployment Settings for Win10-Critical-Security to:

  • Ticked Deadline – System Restart
  • Unticked Supress Reboot – Workstations

I changed the following Deployment Settings for Win10-AllOther to:

  • Unticked Deadline – System Restart
  • Ticked Supress Reboot – Workstations

Here’s the properties for Win10-AllOther:

Properties for Win10-Security-Critical:

I then went and created two Rules and referenced the new Device Groups:

I have split the Windows 10 Patch management into two distinct rules, each covering different classifications, with no overlap (or it will introduce duplication until I clean it up).

  • Win10-Security-Critical will only retrieve Critical Updates and Security Updates.
  • Win10-AllOther will retrieve in this instance Tools, Updates and Update Rollups (if any exist)

I then created a new set of Deployments, binding Win10-Security-Critical to a bunch of Collections, and binding Win10-AllOther to the same collections, with the same deployment settings (Intent, Start Date, Deadline Date) shared between the two Device Groups:

Finally, I created Security Scopes, two per Device Group, as you have to bind Deployment and Reporting to your Device Group:


Now the cool part, once that lot is setup its good to go until you want to change it.

After checking for patches, as you can see, I have multiple SUG’s created to cover everything ticked off, all our Classifications are there and have been split between our Device Groups:


I thought that was cool, being able to denote Patches as fast-lane rebooting on-demand (with the UI experience modelled in via Client Settings), and others are slow lane with no immediate press to reboot the device once they are installed, just by splitting a products classifications across multiple Device Groups, and building things out from there.

I’m sure there are lots of other scenarios the modularity I’ve built will accommodate, I hadn’t thought of this until today.

I’m yet to make a video of PatchMaster, if you haven’t heard of it yet, its an application that will automate the creation of patches. It removes almost all the human effort required to put out a bunch of patches.

Check it out here on TechNet Gallery