PatchMaster V1.3–Guide

Finally have the time to sit down and work out a guide to explain what PatchMaster is, and why you want it to do what it does.

PatchMaster automates the entire SUM experience. With a one time configuration, each Patch Cycle can be initiated with full automation end-to-end, from searching for patches, to downloading and deploying them.

If you are use to rolling your own each month, burning time on the task, this turns SUM into a handle turning exercise performed with just a few clicks. And if you have your own automation in-place, this might meet the bar and replace it, but worth noting that PatchMaster cannot be launched silently, something I’ll introduce real soon.

The criteria patches have to match for PatchMaster to include them is as follows:

  • The patch has the IsLatest flag set to true
  • The patch has not been downloaded or deployed

If a patch meets this criteria, PatchMaster will take care of pushing the patch out into your environment in a repeating and predictable manner, along with producing Rollup SUG’s that let you gauge compliance status for a product.

PatchMaster requires SCCM to be configured with a SUP and WSUS in a fit-to-use state, and the SUP configured to sync the products, classifications and languages required, with a successful sync performed.

WSUS is an interesting beast of late, I am going to build some WSUS management into PatchMaster so that you can decline and delete patches from WSUS, it helps devices scan faster and produces lots network traffic (lots is an understatement, more like a flood, of late, due to Windows 10).

PatchMaster is built by Robert Marshall, EM MVP from England, using c#, .Net 4.5 and Visual Studio. and utilises the AdminUI Automation DLL’s to instruct the SMS Provider to build wonderful things for us. The MSI installer will place these DLLs alongside PatchMaster, allowing you to swap them out for different versions if required, however I’ve only tested PatchMaster on Current Branch using the B1802 AdminUI

Installing PatchMaster

PatchMaster lives on the TechNet Gallery here.

It’s not worth documenting, MSI based, choose an installation directory, next next finish. The tool can be launched by the installer once it has completed.

If you uninstall the tool, the registry settings may be removed, please make sure you backup your PatchMaster registry key once you have configured the product and are happy with said configuration.

I will at some point put this on Github alongside my other tools published there, but I want to get it working just nice,  and then it’ll get uploaded.

Configuring PatchMaster

Launching PatchMaster for the first time will induce a prompt for the SMS Provider (Site server) FQDN, this is needed so that we can connect to the site and make it our slave for a bit. Once you’ve entered the FQDN you will not be bothered any more, however if you want to change it you have to change it in the registry, I know this is a pain, I will make it act like LogLauncher a bit, and handle connection and connection history better.

Configuring PatchMaster will take a few moments and a focused head, it is a one time operation, which this guide is destined to help you walk through.

First off, let’s visit the Configure tab, and work through what is needed.

Naming Bar


The Naming Bar is used to name the following:

  • Software Update Groups
  • Software Update Deployments
  • Software Update Packages

A default set of items will be placed onto the bar, to operate the bar follow these instructions:

  • Left click a Grey button to put it onto the Naming Bar
  • Right click an orange button to remove it from the Naming Bar
  • Right-drag an item on the Naming Bar onto another item to move items around
  • Enter text into the white text box and double click it to make it appear on the Naming Bar
  • There is a drop-down box that shows the delimiter used to separate the items on the Naming Bar (it will not render but you will see the delimiter being used when PatchMaster creates objects), select a suitable delimiter or make up your own

It is very important to set the Naming Bar and to not change it after, changing the naming bar after you’ve used PatchMaster will interfere with the Out of Cycle feature.

The Naming Bar can be locked by unchecking the “Unlock” checkbox.

I recommend setting the Naming Bar as:

  • SUM
  • Year
  • Month
  • Product
  • Classification
  • Reporting
  • Out of Cycle

The Day, Month and Year items will be replaced using the Current Date, there is an exception to this rule farther below.

Software Update Package Location


When PatchMaster creates a Software Update Package, it will configure its data location as Package Source Location, and append the Package Folder text.

To get you going, here’s an example of suitable values:

Package Source Location: \YourServer\SCCMContentShare\SUM

Package Folder: AutoPatches

Distribution Points

Once PatchMaster has created a Software Update Package, it will place it on the Distribution Points you set here.

Choose the Distribution Points you want the Software Update Packages to be added too from the drop down list, and select Add DP\DP Group, it will appear in the list, repeat for all your Distribution Points.

Note that Version 1.3 requires that you update the content on your Distribution Points once PatchMaster has completed, for some reason not all the content gets placed into the DP’s SIS until an update is performed, will figure it out.

Device Groups

Device Groups are a pivotal configuration item in PatchMaster.

Rules, Deployments, Security Scopes and Deployment Settings are all bound together using Device Groups.

A basic set of Device Groups are included, suitable examples to add would be:

  • ModernOS
  • LegacyOS
  • ServerPhase1 to n

You can create Device Groups, that you can use to cater for specific Products and Classification combinations, such as splitting Classifications for a specific product such as:

Windows 10 – Critical and Security = Win10-Critical-Security

Windows 10 – All other Patch Classifications = Win10-AllOther

This will also split Deployment Settings so that they can be tailored to suite the purpose of the Device Group.

Deployment Settings

Whenever you add a new Device Group, a Deployment Setting will be created using default values, and linked to the new Device Group.

This allows you to tailor the deployment settings, so that any Deployments that are linked to this Device Group will be configured according to these settings.

As you can see, almost all options for a deployment are supported, with Allow Metered Internet and Fall back to MU not in yet, there are a few other things that could be included but for now these deployment properties should be enough for most cases, subsequent versions will introduce more options.

Out of Cycle Patch SUG Suffix

If Microsoft releases patches after PatchMaster has created Software Update Groups, the name of the SUG \ SUP and Deployment will include your Out of Cycle Tag (default OOC) which will include a 3-digit incremental serial number.

If you deploy Patches for April and more patches are released, the next objects to be created will have the OOC tag added.

Ideally your Naming Bar should include the Month

Time Machine

Yes I invented a Time Machine.

This one will alter the Date used when creating SUG\SUP\Deployment names, as long as Day, Month or Year are included. It will not alter the Dates for a Deployments schedule.

With the Time Machine turned off, the current Date will be used when creating names.

Reporting Software Update Groups

I haven’t actually ever turned this checkbox off.

No only kidding, if you turn off Reporting Software Update Groups you won’t benefit from a Rollup SUG being created which can be used to report against. This is important if multiple SUG’s are created, if there is no rollup SUG then you have to report against each individual SUG to measure compliance.

Now let’s move to the Rules tab.

Rules are instructions to the PatchMaster Engine, telling it which Products and their Classifications and Languages should be handled.

If you are all minimalist you could have a single Rule, which includes all required products, classifications and languages, but that would be seriously boring, and limiting, so let’s set a scenario and work through it to produce a set of Rules.

We want:

  • Windows 10, all classifications excluding Definition and Upgrades
  • Windows 2016, all classifications excluding Definition

Special requirements are:

  • Windows 10 to be split between Critical + Security, and all other classifications
  • English language only

To achieve this we’d setup three Device Groups:

  • Win10-Security-Critical
  • Win10-AllOther
  • Server2016-Low-Criticality

We then configure the Deployment Settings for each Device Group, allowing Security + Critical to reboot at deadline, and not to suppress the reboot (with Client Settings smoothing out the experience a little).

Now we have the Device Groups we need for this scenario, we can build out the Rules.

Rule Number 1

The first Rule is bound to Win10-Security-Critical, includes both Architectures, Critical and Security classifications, English for Language, we also specify some values for Ignore Builds, which is:

  • Version 1607, Version 1511, Version 1507, ARM64, Version Next

This removes all 1607, 1511, 1507, ARM64 and Version Next patches, PatchMaster will ignore them, you may need some of these build versions to be patched so its up to you what is excluded.

Rule Number 2

The second Rule is bound to Win10-AllOther, includes both Architectures, and the rest of the classifications as described above (obviously excluding Critical and Security), English for Language, we also specify some values for Ignore Builds, which is:

  • Version 1607, Version 1511, Version 1507, ARM64, Version Next

Rule Number 3

The third rule is to bound to Server2016-Low-Criticality, includes both Architectures, all classifications except Definitions, English for Language, we also specify some values for Ignore Builds, which is:

  • Windows Server Next

It should look like this:


That finishes the configuration needed for our Rules.

Now let’s move to the Deployments tab.

PatchMaster will automatically create Deployments for each Software Update Group that it creates.

These Deployments are configured based on the Deployment Settings and its linked Device Group, thus, the first thing you select when creating a Deployment is, the Device Group.

Since you need to bind a Deployment to a Device Group, it makes sense to create as many Device Groups as you require, while setting their unique Deployment Settings.

Now, you may already have a bunch of SUM collections that you already use, in the screenshot below you’ll see I am deploying to a single collection (in my lab), instead of a multi-phased deployment across multiple collections, they are there but I’m lazy and besides, the shot would look very busy!

If you haven’t already established a deployment strategy that includes hard testing, piloting and live deployment, then consider creating Collections for your devices based on those three phases, and staggering the deployment dates (2 days of hard test, 5 days of pilot, 7th or 8th day go live).

So start off creating a new Deployment by selecting the Device Group, then the Target Collection.

Choose your Intent, Available or Required, making sure your Deployment Settings are set in accordance with what you want to happen (hidden, visible, interactive).

The Available Date Offset (Days) is the amount of days from when the tool builds the objects, for when the deployment will become Available to the targeted devices. So choosing zero (0) means immediate (o days from now), 3 means in three days time from now.

The Deadline Date Offset (Days) works the same way, it is an offset from now. You would make this the same date as Available, or separate them based on what you want to happen.

I’m introducing Available Date Offset (Time) and Deadline Date Offset (Time) in Version 1.4, which allows you to set what time the deployments will run, Version 1.3 sets the deployment time to Now (when you run the tool) while setting the date component to the day Offsets, so if you run the tool at 3pm the patches will become available at 3pm on the chosen date.

Here’s how it should look:


Now let’s move to the Security Scopes tab.

Each Software Update Group that is created will have Security Scopes bound too it, as long as there are rules here.

It is important to note that you should create two rules per Device Group, one for Deployment SUG’s, and one for Reporting SUG’s.

Setting RBA on a SUG so that only accounts that have that Security Scope is useful for letting Managers etc. see the Reporting SUG but not see the Deployment SUG.

As you can see in the shot below, I’ve set up an entry for each Device Group times 2, one for Scope Type Deployment and one for Scope Type Reporting. My Security Scopes in SCCM are called Deployment and Reporting:


If that’s been setup correctly we can move onto using PatchMaster!

This is a one-time configuration, everything is stored in HKLM\Software\SMSMarshall\PatchMaster. This key can be backed up if desired, it is quite important to have a copy of it because if it changes (for the worse, a misconfiguration, accidental deletion), it will affect your automation of SUM.

Using PatchMaster

Now the exciting part!

Now configuration is over, let’s close PatchMaster and start it back up, this makes sure it reads back everything you’ve entered. Do a visual inspection yourself, make sure all is well.

When PatchMaster launches it switches to the Log tab, and spews out updates on what it is doing as it spins up. This can take a few moments depending on how crazy fast, or crazy slow your device \ server is.

Once the loading is complete and PatchMaster has configured itself, the UI will be lit up and ready for use, and it’ll switch to the Available Patches tab.

Switching to the Available Patches tab automatically, puts you in front of any Patches found, right away. If there is anything listed there is something to do, nothing listed, you can close PatchMaster.

If you change the Rules you should click Build to refresh the Patch an SUG list.

If you change the Naming Bar you should use Refresh SUGs button to see your changes implemented, clicking Build does the same as the SUGs are rebuilt.

Here’s what those Rules found for me, I have Windows 10 patches already downloaded and deployed, so its found everything related to Windows 2016 for me:


You’ll notice that the top section details the Software Update Groups that will be created, and the bottom section details all the patches that have been found, in this case 4 SUG’s and 6 patches.

The SUG name should be as you set it using the Naming Bar, if it isn’t up to par, tweak the Naming Bar and come back here, click Refresh SUGs. The only point to the Refresh SUGs button is for this purpose, and when you monkey around with the Time Machine. The name of the SUG should change to reflect any changes you made to the Naming Bar if you did.

We have 6 patches ready for deployment, we have 3 Deployment SUG’s and 1 Reporting SUG.

We can see that the Device Group for each SUG is shown, and that all the SUG’s are going to be built using the Server2016-Low-Criticality device group. Awesome.

Before we get too excited there is one feature that you need to know exists, and that is the ability to exclude patches that you want to skip.

If you right click a patch in the Patch list, you can send it to the Ignore Patch list, another tab will show the Ignore Patch list, and from there you can right click and reinstate it. This is if you wanted to strip out IE or .Net Framework upgrade patches until LOB issues are resolved.

PatchMaster will require Internet access, it’ll run under your ID and try to download from Microsoft over HTTP, if this is restricted by your organisations Proxy, then focus on your accounts IE Proxy settings, or perhaps running PatchMaster on a device that has unfettered excluded-from-proxy access to the internet. The Site server should be able to access the internet, PatchMaster will run there in most cases.

Now its time to click that Build button!

Once a build gets underway, it’ll switch the Log tab and show you detailed progress of activities taking place, keep an eye out for errors on your first run through.

Once PatchMaster has completed, it should show that no patches have been found.


If patches are listed, you might see the SUGs named with the Out of Cycle Tag, this is most likely due to the Deployment failing to be created, or the Content failing to download. The log (in product) will show what happened, copy\paste it out into OneNote\Notepad and analyse it for noted burps. To restart after failure, delete the SUGs and SUP’s created, the content will be overwritten but you can delete that too if you like. Ideally setup PatchMaster in your developement\sandpit\lab environment, work out how you want it to operate, see it in action then bring it into production.

Any issues, have a look at how you’ve configured things, if its clearly a bug then ping me on twitter (@RobMVP) or use the Q&A section on the TechNet Gallery where PatchMaster is published.

I’ve tested PatchMaster with Windows 10 and Windows 2016 patch management, using Current Branch Build 1802, I expect it to work with down-level build versions, it most likely will work with SCCM 2012 R2 but may need AdminUI DLL’s to be swapped out. Not tried it.

I hope the tool works for you, and that it saves you a bunch of time that would have otherwise been burnt with click-drudgery doing SUM each month and during Out of Cycle releases!

Happy Patching!