Introduction

The next area we want to look into is now how we construct our collections for patching. Now many can utilise pre-existing collections which is fine if you are doing more of a generalist type of patch approach to hit all machines, but there are various areas of why you may not want to do that.

Therefore it can be more beneficial to split these apart so there is no specific overlapping of any policies put in place. This then allows for workflows to remain in place to handle their respective tasks whilst software patching will maintain its own realm.

Definition of Patch-Based Collections

Patch-Based collections is really a term I just came up with on the fly 😊 But there is a purpose for this.

I would define these as standardised areas of which certain levels or classes of machines that would be placed within preparation for software update patching schedule.

Once of the most crucial areas in any kind of software rollout of any kind is always going to be testing. As urgent and as critical as some patches maybe, what you don’t want to do is panic patch and have potentially an issue across your whole estate because the patch either stops fundamental services from working or the machines just have a BSOD and need more further grounds for recovering.

And it’s scenarios like this where I would recommend not to use collections such as “All Systems” and “All Desktop and Server Clients”. Course it does help that neither of these collections are able to have a maintenance window, but we will cover this later.

Back to definition and structure of patch based collections, a foundational kind of approach I tend to take is something like this

This process gives somewhat a rough idea of what you would want. These are more like model types that you would implement when going forward on any effective type of patching strategy.

Now the table above isn’t an “in order” suggestion but more of outlined roles. Now of course a test collection would be very important so that the correct screenings can take place.

For example, certain desktops or servers might have very specific use or typical BAU uses. Ideally you want to have units which replicate the scenario accordingly so that when you do perform quality checks you get a realistic understanding of what can happen to your estate, rather than just pushing them out everywhere and dealing with consequences on the spot.

The other collection templates such as Critical Servers is a good to have collection especially when dealing with business critical servers which would bring an immediate P1 severity if anything happened to them, but they still have vulnerabilities which would need to be addressed via patching. And this collection of machines can have more authoritative control as to when this will happen.

The last two mentioned are more around how you split collections up so you can have a structured or staggered method of distribution of software updates. Sort of isolating or reducing potential impact in the estate and keeping a more closer eye on things.

The key is that you don’t want to go too granular otherwise managing patch management across too many collections can be a nightmare and administrative effort would be a problem. Essentially custom reports and dashboard can help create a SPOG (single pane of glass) to consolidate this but perhaps more additional effort than it needs to be.

Maintenance Windows

This subject is quite open to interpretation of how you see is the best type of window. And to be honest I don’t think there is a recommended best date or time which everyone can effectively use, even for a patch Tuesday template.

With the collection templates outlined, the maintenance windows are down to you. If going by the collection templates I would maybe recommend something like this.

Patching – Test Collection – As these are test machines and hold no bearing on any service or business criticality you may not even need a maintenance window for this. You can create one to test it before placing this on other collections, but in order to conduct quality checks without any hold ups then perhaps no window is best.

The other collections, are more prone to change management, so I would say if you have a regular template for change management when it comes to patching you may already have a base date/time which you would always go by, therefore you could build a maintenance window around that date.

I guess overall maintenance windows can have a more dynamic change structure. Because in where critical updates or issues arise it could then be a case of emergency change requests and they have to go out ASAP.

Custom Client Policies

This particular section is quite key, especially for the overall user experience of how they respond to notifications of a required reboot or a mandatory reboot.

Normally communications go out to state machines will be patched and expected to start, complete and reboot at the stated times or dates. But not every part of a business maybe able to have downtime at a certain time in the day, so in order to accommodate that and also taking into account the specific collections we have this where custom client policies come into play.

Area of interest here is a client policy which shows the amount in minutes as when a machine will reboot and the duration of time opened for when they will receive notifications that can be suppressed.

The key is really finding the right realistic balance for the user and for the administrator who puts this in place.

There is also of course the Software Updates section of the custom device settings but we will cover this in a later part.

Incremental or Scheduled/Manual Collection Updates

One of the biggest prerequisites which decides which one to go for is to of course where possible do not use All Systems or All Desktop and Server Clients as limiting collections.

For this I would suggest if you have collections which have more of a specific criticality or a process which requires more manual approach, then perhaps a schedule or manual update collection membership process is more appropriate.

If you have collections which are based more on conditional basis or common property such as an OS level, build level, specific hardware vendor or any element which multiple objects share, then an incremental update configuration would work a lot better. Though when using incremental updates do make sure you don’t have too many collections and too many that may have a lot of devices.

Next On Part 3

Next part we will go more into the Automatic Deployment rule configurations and how they play a huge part in our patching strategy but also effectively needing to watch over and ensure proper usage.