One of the features that most interested me when I was investigating Configuration Manager where these magical things called Automatic Deployment Rules (ADRs). Our existing patch process was very manual: multiple people going into separate environments and deploying individual bulletins (I know, bulletins are not updates but that’s how that vendor delivered them) to collections of devices. It was tedious and error prone leading to inconsistency between lab and production. Just the word automatic being talked about in the same sentence as patch deployment was exciting.
It took me quite a while to get my head fully around ADRs, their quirks, and what they mean for my patching strategy. As always I’m hoping that by writing this I might save someone else a chunk of time. I don’t think any of this is ground breaking; but it’s what I wish I had neatly summarized when I started out. There’s plenty of existing guides out there telling you what to do step-by-step so there’s no sense doing that here. Instead, I want you to better understand the choices you have and how to make them.
Creating or Reusing Software Update Groups
One of the first things you need to decide when creating an ADR is whether you are going to have them create a new Software Update Group (SUG) every time it runs or whether it will reuse the same SUG. Microsoft’s own best practices say to create a new SUG every month. The main reasons for this is that a lot of the built-in reporting is based on SUGs. Also, you can’t deploy SUGs that have more than a thousand updates in them so you need to split them in some manner. Creating a SUG each month is a straightforward solution to that problem. The downside to this approach however is that you end up with SUG sprawl with each new SUG needing to be maintained. Configuration Manager will never modify an existing deployment of its own accord so it’s up to the administrator to remove updates that are no longer needed because they are superseded or expired. You’ll also want to combine SUGs at some point to clean up the console and minimize the back-end summations. Be smart and automate those tasks using the script I released: Fully Automate Software Update Maintenance in Configuration Manage.
There is another option though: reusing the same SUG. When you select this option the ADR will compare the filtered list of updates to the existing SUG. If, and only if, the two differ it will completely remove all updates from the SUG and add the updates returned by the ADR filter. This method eliminates SUG sprawl and automatically maintains the SUGs by removing expired and superseded updates providing you exclude them in your filter. One possible downside to this is if you have patch cycles that are longer than your ADR frequency. For example: you release patches monthly but you have some servers that take six weeks to patch because ‘reasons’. You need to make sure that the deployment deadlines occur far enough ahead of the next ADR run for clients to install them. If that’s not possible then you might need to create multiple ADRs and schedule them to run on alternating months. Further, if you reuse SUGs do not filter based on date otherwise you risk missing patches. Without filtering on date you are going to need to find some way of splitting up your ADRs so that they don’t create SUGs with more than a thousand updates. A simple workstations vs server split might not be enough so OS is a logical choice here.
The next thing the ADR wizard will walk you though is setting up the deployments. While this is pretty straight forward stuff there are two things worth mentioning.
First, you can configure the ADR to create disabled deployments. If you are too afraid of automation to let it fully control your patching then this is the option for you. The ADR will create everything for you but will not impact the client in any way. I much prefer full automation that requires intervention to stop but I realize every environment has its own challenges. If you still want human intervention to be required then use this option and manually verify what the ADRs did before enabling the deployments.
Second, although the wizard only creates a single deployment you can add additional deployments afterwards as of Current Branch 1511. This allows you to easily create all of your staggered roll-outs for pilot, test, validation, or whatever with a single ADR. If you upgraded from previous versions of Configuration Manager do not miss out on this opportunity to possibly reduce the number of ADRs.
Scheduling: When and How Often?
Regarding scheduling, I already wrote about this at length so I won’t repeat myself here: Patch Tuesday Is A Lie. The latest Technical Preview as of this post has scheduling offsets built in which is just fantastic. Something also worth considering is the frequency of your patch cycle. The historic norm is to run monthly cycles but before jumping to that conclusion see if a weekly cycle might work for some or all of your patching. If your organization doesn’t have a mature patch testing regimen anyways then not testing weekly is the same as not testing monthly. Patching more regularly eliminates certain procedural issues that will make your life easier. One I’ll talk about below is how to select just the updates since you last ran your ADR. Another is out of band patches. Imagine if the recent Meltdown/Spectre out of band patches were simply wrapped up in your weekly cycle and were no big deal. Lastly, as I described in the post I linked above, Microsoft is releasing some patches totally outside of the normal Patch Tuesday time frame. Keep in mind that it’s not all-or-nothing. Maybe only your workstation or Office patches are weekly and your server patches remain on a slower schedule.
ADR Filters: How do I Choose?!
Now, we get to the really fun stuff. When I started out, selecting updates felt like a dark abyss I had to jump into and find my way out of. I was never the same afterwards. Here’s a few tips and things to watch out for.
Date Released or Revised: What Does One Month Really Mean?
What you do with this filter depends entirely on your patching strategy. If you’re reusing SUGs then the whole point is to automatically maintain them each time you run your ADRs. Therefore that’s the one strategy where you don’t use this filter type at all. When creating new SUGs the goal is to generally select all the updates released since the last time you ran the ADR. This is where a weekly patch cycle is a huge benefit: setting this filter to one week is all you need. If you are using the more standard monthly cycle then be aware of what selecting one month actually does. It means subtracting one from the numerical value of the month. Since the second Tuesday (or whatever day you pick) of the the current month will not be the same as the previous month this is going to cause gaps. Historically you wouldn’t worry about that because MS had a nice reliable release schedule of the second Tuesday at 10 AM Pacific Standard Time. That’s no longer the case and patches for things like Office 365 are being released later that evening or even a day or two after Patch Tuesday. That means you can no longer afford a time gap in patch selection. The real solution for this is for the product team to allow us to select only updates that have not yet been deployed. Go vote on UserVoice right now: ADR New Search Criteria, Deployed = yes/no. In the meantime however I recommend selecting two months of patches for ADRs ran monthly. I would much rather redeploy updates a second time than not deploy them at all.
Required: Be Vewy Vewy Careful
There is something really alluring about this filter. The idea of only deploying patches that your clients actually need sounds too good to pass up. However, this is one that you need to fully understand before you use it. So let’s walk through it a bit. Configuration Manager can’t know how many clients require an update until scan result have been summarized which by default is every hour. Scan results can’t be summarized until the results are received. Clients aren’t going to send results until they’ve successfully scanned. Clients are only going to scan semi-randomly based on the scan and evaluation frequencies selected in client settings. Clients can only scan for new updates once the SUPs have completed syncing updates from MS. That’s a long way of saying that there needs to be enough time between when you sync updates and when your ADRs run for all of that to happen on a representative sample of your clients. If you’re running ADRs an hour after your sync … you are going to miss updates until the next ADR run. For this reason I highly recommend not combining this filter with the Date Released or Revised filter. If you combine them you run the very real risk of having clients that need an older update that will never be deployed because it’s older than your date filter allows. To be honest, I don’t recommend using this filter at all.
Product and Superseded Filters: Just Use Them
There’s not much to say here apart from the fact that you should be using these filters. In the case of the latter be sure to only select updates that are not superseded.
Title: Who Knew They Could Be This Useful?
This is a filter that I overlooked for quite some time. At face value I just didn’t see where it would be useful outside of a very few edge cases. Then I realized that you can prefix your search strings with the minus sign to filter out matches instead of including them. Once that’s an option there some pretty straightforward things to exclude:
- -Security Only
- -Preview Of
- -Office 365 Client Update – Monthly Channel
- -Office 365 Client Update – Semi-annual Channel (Targeted)
Beyond filtering out Itanium updates the above filters allow you to deploy only the cumulative updates and only the Semi-annual Channel for Office 365. However, I will warn you that the product teams like to go on drinking binges and wake up with the new ‘final solution’ for their naming scheme. So you need to keep an eye out for such changes which would require changes to your title filters.
Update Classifications: A Religion Unto Itself
So what you do here really depends on what you or your organization’s philosophy is on patching. At the bare minimum you should select the Critical and Security update classifications. There have been many a word spent arguing about how terrible MS’s quality control is and how less patching is universally better than more patching. Everyone has that one story where they got burned and they vowed to themselves ‘never again’. At this point however you are going to be forced into cumulative patching with Windows 10 and Server 2016 so it’s probably time to get over it. If you do then you’ll want to select at least the Update Rollups and Updates categories. You can do a coin flip and decide whether to include the Tools classification. I’ve never understood what actually goes in there and currently I see no active updates at all with that classification in my environments. The Upgrades classification is for Windows 10 Feature Updates which are better used by a servicing plan rather than an ADR (servicing plans are really just special ADRs). That leaves two more classifications: Feature and Service Packs. Feature packs are primarily major-version upgrades to MS products; .NET in particular. For this reason I don’t include either of these in my ADRs. Service Packs and new versions of .NET are major changes that need to be treated more carefully than our automated monthly process allows. Specifically on the server side where a new .NET version is likely to break web apps. For that matter, Exchange has been known to be break with newer versions of .NET and as of this posting the latest version released over 9 months ago is still not validated.
The Preview Button: Your Best Friend
When creating your update filters do not miss the Preview button in the lower right of the window. Anytime you make a change to the ADR use this to run the query and show the list of updates that would be returned. Before hitting OK and saving your changes take the time to really scrutinize what’s in there.
Is There Anything ADRs Can’t Do?
So despite their swiss-army knife appearance there are a few things that ADRs can’t do. In particular, the existing ADR filters do not allow you to select updates for the particular version of Office 365 or Windows 10. The problem with Office 365 is specific to the Semi-Annual Channel previously known as the Deferred Channel. This channel has multiple supported versions, currently 1705 and 1708, and there’s no way to automatically select the one you want. Similarly, you probably aren’t actively deploying every supported version of Windows 10. You most likely skipped one, haven’t deployed another, or have fully retired the oldest. With some cumulative updates topping 1 Gb each month it’s not ideal to deploy and distribute versions you don’t need.
One solution to this problem is to simply deploy these types of updates manually. Only slightly less distasteful is to use very specific title filters to exclude all but the versions you want. That too though is a never ending process of determining if a new version has been released and then updating your ADRs accordingly. I hate doing anything related to patching manually. For that very reason I created a plugin system to my maintenance script which can be used to decline updates in a granular way that ADRs are unlikely to ever match. In this manner I can decline all but the latest Office 365 Semi-Annual Channel update before my ADR even has a chance to run and select multiple versions. Similarly, you can filter out updates for Windows 10 versions, languages, or editions you currently don’t support. For full information on this refer to this post: Fully Automate Software Update Maintenance in Configuration Manage.
How Many ADRs Should I Have?
This is a question I’ve seen asked a few times on Reddit. The number of ADRs you have is going to be a direct function of your patching strategy. The main constraint you have is that you cannot deploy a SUG with more than a thousand updates in it. So however you decide to do things you have to make sure your ADRs will never select more than that. If you’re creating new SUGs each time the ADR runs then you should be able to get away with just a workstation and server ADRs. If you’re reusing the SUGs then you will likely have to split them up by operating systems because the number of updates for legacy OSs is astronomical. That being said, Microsoft has slowly been adding in previous patches to the cumulative updates for the legacy OSs. So going forward there should be fewer update backlogs meaning we can combine them into fewer ADRs. One last thing to consider here is if you run Office on any of your servers, terminal servers for example. If so you might consider a separate ADR for Office products.
Windows Defender Definitions: The Precious Little Snowflake of Patching
Before I end this ridiculously long post that no one in their right mind is going to read every word of let me briefly mention Windows Defender updates. If you are using Defender and would like to centralize the distribution of definition updates you will want to do so with Configuration Manager ADRs. Such an ADR will likely look drastically different than your patching ADRs. First of all you should schedule them to run at least daily if not multiple times a day. When doing so don’t forget to also sync updates at the same frequency a half hour or so ahead of the ADR. Because of this frequency and the fact that every update essentially supersedes the previous one you will want to reuse the same SUG. Filtering is dead simple: exclude superseded updates and select the Definition Updates category.