Introduction

In the previous part we covered the topic of how we would look to structure out our collections, which is quite important for the foundation for this next area in which we are going to dive into which will be around Automatic Deployment Rule Structuring.

Now creating Automatic Deployment Rules (ADR) is a very straightforward process, and can be done with your eyes shut (I wouldn’t advise this 🙂 ). But of course what we want to do is essentially establish a process where the ADR rules can function automatically, but also within the correct processes in which we want for it to be responsible for. And these are the key points in which it will require a little bit more planning on our side.

ADR: Defining of the Base

There are various methods of how the ADR rule is defined in terms of how many rules will be created as well as the type of ADR rule it will be.

The most common methods are around types such as;

• Based on OS
• Based on Product
• Based on Hardware

These types of methods are fine. But the only issue you will find is that you can run the risk of having too many ADR rules created. It’s not so much of an issue laid out like this but when you take into consideration of the administrative effort to maintain that all rules run successfully and especially with the multiple reporting points you will have it can get overwhelming.

Multiple ADR rules is fine AS LONG as the definition for which it’s made for is sensible. So when we look back at the previous part we looked at collections that would have purposes such as;

• Test Collection
• Critical Servers Collection
• Conditional Based Collections i.e. Geographical

The difference between these collections than the ones mentioned early above is that the purpose outlined is much more clearer. How you define rules for a Testing Collection is going to be very different to how you would handle business critical devices.

ADR Configuration

Now we will look to expand across the configurations of an ADR rule so we can analyse key areas which will define the planning decisions on how to develop this process further.

What we will do in this section is give an example for how each purpose based collection would look to have it’s configuration done so that the reader can have a baseline to how they would structure an ADR rule around it.

Scheduling

A very popular one always is based around patch Tuesday being a bi-weekly schedule on Tuesday. This is fine, but what we want to do is to take into consideration of the purpose based collections in which these rules would be applicable for.

So lets look at the evaluation cycle. Here is where we would define for when the rule is actually ran from.

In addition we also have to consider the deployment schedule.

Here we can look at some examples of on how we would base an ADR rule configuration according to the type of collection we would have it deploying to.

Testing Collection

A testing collection when it comes to patching should contain devices which cover most aspects of the roles all devices play and that goes for client devices and servers. These are also of course low priority as these are not being used. So given this are schedule can be ran perhaps more frequent than the others as this wouldn’t have to deal with an set maintenance windows etc having said this, a test collection with an ADR rule assigned would be a great basis for a change request to show proof of its testing and results.

There is really no right or wrong schedule for a collection such as this but ideally this would be deployed to first in order to gauge the results.

Critical Servers Collection

Now we go immediately into a realm of business critical servers. Many prerequisites also play ap part within this such as maintenance windows, client policies as well as the schedule in general.

My recommendation would be perhaps to not have this rule run automatically but maybe a possible semi-automatic approach in which we will cover later on.

Deadlines where possible should be honoured or in line with any type of change window or maintenance window which you have in place to essentially avoid anything continuing on that may take longer than expected or cause outage to the business at unwanted times.

All Client Devices/Conditional Based Collections

For the client devices, these should follow a similar pattern as stated in the critical servers collections.

Though when it comes to the patching of user devices the user experience is where the process is really going to shine. So good communications stating what will be configured within the evaluation schedule and deployment schedules will be very key, especially when there will be mandatory reboots which will soon follow afterwards.

Handling of Excluded Updates

There can sometimes be the odd windows update whether you catch it beforehand or has already been deployed and caused an issue along the way. You will of course need a way to be able to allow your ADR rule to be able to detect which updates you have labelled as a risk, so that these are not included within the updates which would be deployed within the ADR.

Marking a specific update with a specific custom severity will help keep a categorized track of what you will be potentially excluding. So that when we visit back to the configuration of your ADR we then add this into our Software Updates conditions as seen below

By default all of the software updates will not have a custom severity set, so putting it to None will ensure any which you will flag will not be included, which then gives you time to be able to test the flagged update more thoroughly.

Including Windows Server 2022 Updates

This is also an important part to consider, especially if you already have Windows Server 2022 servers in place as this is not obviously found within MECM so you will need to enable this.

Below is the Products page in the Software Update Point Properties.

Create New Software Update Group or Add to Existing Group

This would come down to preferences but lets look at this a little bit closer in a data retention or historical aspect.

Having a software update group which would remain the same and have updates just added to that one alone does make it cleaner if you are not wanting to have the ADR create one based on the timestamp the evaluation ran on. But from my experience this can make trying to track previous deployments a lot harder this way.

You can have a Data Warehouse server role which could fill this in, but where the sizing requirements could be an issue it might not be the ideal choice and especially if you have a lot of patch runs.

Having new software update groups each time can make it more simplified when running native reports as well as custom reports to be able to have a baselined look across the performance of all your managed MECM devices being patched.

Semi-Automatic ADRs??

Following up from the sections of ADR scheduling considerations, if wanting to have a more controlled way of dealing with rollouts of updates within ADRs, you could use a semi-automated approach.

When I say this I don’t mean necessarily just disabling the ADR rule and then running it when needed, but you can disable the actual deployment within the ADR rule so that once the rule runs and creates a SUG (software update group) the deployment would have been disabled.

The advantages of this? To look at the updates which are then part of the SUG but also to have a finer assessment of its compliance status across all the devices within your managed MECM. This is a good method if you are doing testing or staggered approaches to releasing updates. And granted it can defeat the object of having an ADR rule as well, but when dealing with sensitive processes or endpoints an automatic process such as this can have some slithers of doubt.

So this process is a way to at least watch piece by piece how the process is working, and then providing you a viewpoint to be able to fine tune and then have things flowing in a more automated way.

Click here to read the previous topic in the series: