Roberts Blog

The House of SCCM and Intune on System Center Street

Tag: C#

DP_Locality flags or bitmask in SMS_UpdatesAssignment

I recently had to figure out how to properly set the DP_Locality property in the WMI SMS_UpdatesAssignment server SMS Provider class, as part of some work being done on PatchMaster, which automates the deployment of patches.

Eventually I figured it out, but at first I couldn’t quite grasp what was going on. I had to query the PG to verify my thinking (Thank you Hugo!), and in this post I’m going to go over as much detail as possible so as to spam the bejesus out of the subject.

To frame things better, every time you create a new Software Updates deployment in SCCM, a new SMS_UpdatesAssignment instance is created in WMI on the Site server to represent it.

Here’s a shot of the property sheet of a deployment, note the Neighbour DP and fall-back DP panels at the top and middle, and the WUMU\Metering panel at the bottom:

This is what it looks like behind the wizards curtain, using WBEMTEST to take a peek, DPLocality is an unsigned 32-bit integer:

* Note that you can do the same with PowerShell: get-wmiobject -namespace “root\sms\site_<YOUR SITES SITE CODE>” -query “select * from SMS_UpdateGroupAssign
ment where AssignmentID = <DeploymentID>” | Format-List -Property DPLocality

The DPLocality properties value shows 786512 (0xC0050). We’ll decode this in a moment.

That integer actually represents a bit mask, or a set of flags. This is noted in the documentation under qualifiers for that property as bits.

When I set about to decode DPLocality, I came up short. The documentation on Microsoft Docs doesn’t quite explain the bit positions properly, we’ll go over this now.

Firstly, the information you need is spread across two pages, shown below is the class, and then the class that class is inherited from:

SMS_UpdatesAssignment Server WMI Class

The property we’re looking for is DPLocality:

As is shown above, this class is actually derived from the SMS_CIAssignmentBaseClass.

Deeper into the doc for the SMS_UpdatesAssignment class we get some information on the property we want to set, DPLocality:

First note that Qualifiers calls out that this is an integer formed using a bitmask (bits), concocted using flags.

Qualifiers: [not_null, bits]

It is also noted that the DPLocality property defaults to the flag combination DP_DOWNLOAD_FROM_LOCAL | DP_DOWNLOAD_FROM_REMOTE (0x50).

We have an assertion here, it states that when these two flags are combined they weigh in at 0x50 (hex), or 80 in decimal.


So we know that DP_DOWNLOAD_FROM_LOCAL and DP_DOWNLOAD_FROM_REMOTE are both set by default, and if we build ourselves a bit-table in excel, which I do a little bit further into this post, we can essentially figure out those two flags bit positions.

When these two flags are set the following radio button switches to “Download…”:

This panel defines whether the local DP or a neighbour DP can be used by clients for this deployment.

If you remove the DP_DOWNLOAD_FROM_REMOTE flag, the “Do not…” radio button is enabled instead.

That’s LOCAL or REMOTE DP defined, now let’s quickly look at the fall-back DP option and return to it in more detail further into the post:

To toggle the fall-back DP radio control we need to set another flag called DP_NO_FALLBACK_UNPROTECTED (detailed in the SMS_CIAssignmentBaseClass doc) so as to disable the fall-back DP option, or remove the flag to enable the option as highlighted in the shot above.

There isn’t much more noted for this class in this doc page, but we are told to go visit the base class that this one was inherited from, there is more for us there, so let’s go take a look.

SMS_CIAssignmentBaseClass Server WMI Class

Nothing worthy of note here but I include a shot of the properties for this base class:

Let’s cut straight to the chase, no need to dilly dally, roll down until you find the DPLocality property:

We know this is a bit-mask, and here we have all 5 flags and their bit positions listed for us.

Yes those are bit positions and consequently starts at 0.

With these flags and bit positions (adjusted in just a moment) that’s all we need to construct and deconstruct the DPLocality value.

As I hint, actually three of the bit positions are noted incorrectly, we’ll take a ganders at that in a moment.

With this information I put together a bit-mask table in excel for easy reference, so as to figure out what the values should be, this gives me the decimal and hex value represented by the bit positions.

Here’s the bit-mask lookup table as a shot:

So armed with that initial assertion of the value 0x50 (decimal 80) from the two DP_DOWNLOAD flags being turned on, we can see that decimal 16 and 64 are added together to yield 80 (hex 0x50), that verifies bit positions 4 and 6 nicely..

So, we’re told that bit positions 4 and 6 are for the DP_DOWNLOAD flags, and bit positions 17, 18 and 19 are for the other three flags.

The problem with this is that the references to flags starts out using the bit position (bit column in table above) starting from 0 (DP_DOWNLOAD flags), and then starting from 1 (as sequence column in table above) for the other three flags, giving incorrect bit positions..

If we purely use bit position, the flags actually reside in positions 4, 6, 16, 17 and 18, and not 4, 6, 17, 18, 19. It’s an easy amendment to the docs which I’ll try to submit soon.

Worth noting that you just need to add these flag’s decimal value together to produce a valid integer.

There are four combinations for the Neighbour and fall-back DP, these are:

  • Neighbour No – Fall-back DP Yes = DP_DOWNLOAD_FROM_LOCAL

To handle WUMU and Metering just add their decimal value in once you’ve calculated the Remote\Local\Fall-back DP options.

And that’s about all you need to handle DPLocality.

Since I was handling this for a C# project, I might as well pass on what I wrote, I’m sure it can be done better, this is enabling code not the high of perfection code.

Below I show a method used to encode the bitmask based on some .Net controls ‘state’, I.e. a checkbox is checked or unchecked:

private int handledplocalityBitmask()


if (!globalObjects.GlobalClass.disableProcessing)


int tosendInt = 80;

if (cb_deployment_downloadNeighbour.Checked && cb_deployment_defaultFallback.Checked) tosendInt = 80;

if (cb_deployment_downloadNeighbour.Checked && !cb_deployment_defaultFallback.Checked) tosendInt = 131152;

if (!cb_deployment_downloadNeighbour.Checked && cb_deployment_defaultFallback.Checked) tosendInt = 16;

if (!cb_deployment_downloadNeighbour.Checked && !cb_deployment_defaultFallback.Checked) tosendInt = 131088;

if (cb_deployment_usemsUpdates.Checked) tosendInt = tosendInt + 262144 ;

if (cb_deployment_allowMetered.Checked) tosendInt = tosendInt + 524288 ;

return tosendInt;


return 0;


The four variations on Default and Neighbour are covered, and WUMU and Metering are added in at the end.

To decode the bitmask requires some more interesting coding.

First define some flags and respective decimal values that can be referenced later on:

public enum DPLocalityBitMask
     DP_ALLOW_WUMU = 262144,

And here is the code sitting in a method that does the decoding:

// Handle DPLocality Bitmask Combinations (expect Metering and WUMU)

var DPLocalityMask = (DPLocalityBitMask)adeploymentProperty.DPLocality;

var decodedDPLocality = new List<DPLocalityBitMask>();

foreach (DPLocalityBitMask DPLocalityBit in Enum.GetValues(typeof(DPLocalityBitMask)))

    if (DPLocalityMask.HasFlag(DPLocalityBit))

// Neighbour, Fallback

if (decodedDPLocality.Contains(DPLocalityBitMask.DP_DOWNLOAD_FROM_LOCAL) && decodedDPLocality.Contains(DPLocalityBitMask.DP_DOWNLOAD_FROM_REMOTE))
     cb_deployment_downloadNeighbour.Checked = true;                       

if (decodedDPLocality.Contains(DPLocalityBitMask.DP_DOWNLOAD_FROM_LOCAL) && !decodedDPLocality.Contains(DPLocalityBitMask.DP_DOWNLOAD_FROM_REMOTE))
     cb_deployment_downloadNeighbour.Checked = false;

if (decodedDPLocality.Contains(DPLocalityBitMask.DP_NO_FALLBACK_UNPROTECTED))
     cb_deployment_defaultFallback.Checked = false;
     cb_deployment_defaultFallback.Checked = true;
// Metered network

if (decodedDPLocality.Contains(DPLocalityBitMask.DP_ALLOW_METERED_NETWORK))
     cb_deployment_allowMetered.Checked = true;
     cb_deployment_allowMetered.Checked = false;

// Use WUMU

if (decodedDPLocality.Contains(DPLocalityBitMask.DP_ALLOW_WUMU))
     cb_deployment_usemsUpdates.Checked = true;
     cb_deployment_usemsUpdates.Checked = false;


PatchMaster Source Code now On Github

I’ve created a repository on GitHub for PatchMaster here.

The entire Visual Studio 2015 authored C# code base seems to be published AOK:


I reserve no rights on this code, feel free to use however you see fit. Obviously a release of an out and out clone with no enhancements will be frowned upon.

I’ll continue to maintain this code branch,which is actually the source code for the next release V1.6. There’s only one or two changes made to the V1.5 code yielding V1.6. I’ll need to have several more changes put in place before I release V1.6.

I’m sure the source code will really help any of you out there that are trying to do something similar or along the same lines, automation of patching.


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
  • Left-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
  • OOC doesn’t move around properly, you need to drag buttons behind it to get OOC to sit at the end of the Naming Bar

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!

PatchMaster–Unique Deployment Settings for each Product Classification

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

PatchMaster V1.1

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:


Staggered deployments:


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.

How do I use PatchMaster?


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.

How does PatchMaster change my SUM process?


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:

  • Classical patching schedule
  • Zero-day patching schedule

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.

Where can I get PatchMaster?


It’s available on TechNet Gallery along with a bunch of my other tooling here.

There’s also a guide on how to use PatchMaster, which will link to future updates as the product iterates.

Powered by WordPress & Theme by Anders Norén