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.
Deploying Updates
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 you can do:
- -Itanium
- -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.
To be clear, I’m not telling you that you should be excluding certain updates but simply how you can do so with this technique and demonstrating with examples. It’s been pointed out to me that rouge IT might be installing or manually configuring Office 365 channels you don’t intend to support. If you chose to filter out certain channels be certain to check the Office 365 Client Management dashboard to verify the channels in your environment.
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.
We were trying to use ADRs for ‘annual’ content to limit the number of updates in a group, but can’t choose more than 9 months in the date rage.
I think the answer there is: Don’t do that. I’m not sure exactly what you are trying to do but the date ranges available are definitely limited. At some point you just stop filtering by date all together. I can’t think of why I’d want to routinely deploy the last years worth of updates.
Only to limit the total number of updates in a group and the total number of groups. That allows us to easily group them into annual ones. Having monthly new groups seems to have some admin overhead in cleaning them up. Less so if groups are reused and recycled annually. We may use quarterly range, which should cover any gaps for some in-field/offline systems.
Oh forgive me, I was having a boy look. ‘1 year’ option is there, was just looking for ’12 months’ after the ‘9 months’ haha.
Great post Bryan! I’ve finally arrived at a company that has requirements which mean ADR’s have to be run weekly. The drawback with this is that you can’t reuse the SUGs as the ADR’s would run and renew the SUG before it’s had a chance to go out to Pilot and Production. This means that with five ADR’s (Win10, Office365, Servers, Office Legacy and Third party) running weekly you hit 260 SUGs a year which is a lot of clean-up work. Any thought son ways around this? How have you implemented it using weekly ADRs? Cheers!
That’s SUG sprawl. Follow the link in that section above to my maintenance script. It will automatically combine those SUGs for you.
Thanks, I will take a look at that. It doesn’t look like there are many other options. Perhaps 5 weekly ADRs which can reuse the USG. more ADRs but less SUG sprawl.
Right, if you really wanted to re-use SUGs then you could set up 4/5 of them. As long as your first one’s deadlines are well ahead of when they run against a month later you should be fine.
If you’re trying to deploy updates weekly but taking a month to actually install them then I guess you’re doing it wrong anyways.
I suppose, it’s more like two weeks and then remediation of any that errored. Pilot Servers get patched during mw’s across 1st week, then prd get patched during mw’s across 2nd week.
I was hoping that the new ADR filters would help out with my solution but the lowest search is ‘older than 30 days’. I want to have two ADR’s which reuse SUGs, one pilots updates released in the last seven days. The other deploys all updates older than seven days to production. The workaround would be to run the production ADR an hour or two before the pilot ADR and select only ‘is deployed’ updates.
Good article Thanks
I have to disagree with your assessment for the Required flag, you just need to time your Sync properly, for example if your sync runs at 4pm on patch tuesday, have the ADR run at 11 PM, it gives plenty of time for machine to report their scan. And if you are scared of missing a patch, add released or revised last 3 months. That way if for whatever reason you miss a patch on a given month you’ll most certainly catch it the next time
If you want to use Required, that’s fine, you just need to know what it all entails. You need to make sure that a fully representative sample of devices have checked in. At large scales that simply might not happen in the timeframe you describe.
Likewise, you have to accept releasing patches a cycle behind (usually a month). In many orgs that just doesn’t fly. If you have any kind of PCI/HIPPA requirements that’s straight up not an option.
Using both required and a released/revised is pretty much indefensible in my eyes. It’s one thing to risk deploying a patch a month late. The risk of not deploying a needed patch at all … that really should be unacceptable. To be fair, this is less of an issue with OS updates but if you have other updates, especially some 3rd party stuff it’s very likely to happen and you have no way of knowing.
i agree that it could cause an issue for 3rd party updates, for OS/Office updates i’ve been using that particular config for years with multiple clients without issue. Some businesses even run a script to force the software update scan every hour on a subset of machines to make sure that when the ADR runs the number of patches downloaded reflect what is really required.
Also i usually put in place a process to consolidate the SUG’s every year in order to maintain a clean environment and to remove patches that are no longer required from the deployment packages. Having those “backlog” SUG’s allows for easy reporting for patches in a given year and if something shows up in the environment that hasn’t been patched it will show up in the reports and be remediated
.
Recently went from a 100+GB deployment package at one client to 15GB.
Really interesting piece of reading that confort me in the way I manage ADR.
I will also get a look at your script, they look really useful. 🙂
I ended up reading every word and found this information very useful. I appreciate you clearing up some of my questions. Cheers!
This is just a perfect description of my ADR configuration! I feel so validated!
Anyway – I want to use Description to exclude updates for builds I know I don’t have in my environment but can’t figure out the usage. For instance, I’d like to add a description filter for:
-“Windows 10 Version 1511” (The intent being any description which contains that exact phrase.)
It doesn’t seem to matter, though, what I type into the filter – I either get everything excluded, or everything included.
Any gotchas about the description filter, or references about it? I’m pretty aggressive about reading the documentation and it doesn’t say a lot more than the context description on the Description Filter dialogue box.
Actually – I should clarify. It doesn’t matter what I type into a description filter, _as measured by clicking on the “Preview” button_….I get all or nothing. I haven’t actually tried letting an ADR rule run with a description filter.
Hmm, I’ve never used that field before but from the looks of it it should work similar to the title. As I understand it, if you use quotation marks that means the entire description field must match that exactly.
To be honest though, if you want to exclude certain builds … why use description over the title field?
Dumb carelessness. I don’t have “Title” as a filter option on the “Software Updates” tab of ADR properties, so I was substituting “Description” as if it were the same thing….which of course it isn’t.
So that solves that mystery….Do you have Title as a filter option? I’m on 1806 and do not.
Are you per-chance using the Architecture filters? There’s a known issue of sorts where you can’t use both. More specifically, the Architecture filters really is a Title filter and there’s some kind of problem right now.
Bullseye….well done and much appreciated!
Bryan, Thanks for this post, it’s good to see how ADRs can apply to reduce the manual work of patching.
I agree that we should select Security and Critical Updates that have not been superseded, but Microsoft sometimes supersede Critical patches that cause functional issues, replaces them by new patches, and labels the new patches with severity “None”, and marks the bad patch it replaces as “superseded”. You run the risk of either skipping a month, or deploying a patch that could cause functional issues on the clients. This situation happened in July and in Oct 2018. The only solution I have identified to get around this is to have a separate “Ad-Hoc” ADR, where you specify a small number of individual patches by name. Then you have to have additional deployments to manage this extra ADR.
I’m a bit confused by the scenario you lay out and your solution to it. Absolutely, it’s safe to say that MS is going to screw us over with poorly tested patches from time to time. The solution there is to test the patches extensively. Further, I recommend making use of the new patch offset feature to release your patches a two or more days after Patch Tuesday. Lastly, follow some people on Twitter and monitor the Sysadmin subreddit’s Patch Tuesday mega-thread. Put that all together and with any luck you will have time to hear of any bad patches, carefully scrutinize your test results, and then act accordingly. If that means waiting a month then so be it. If that means manually pushing out (instead of an ADR) something that MS re-released then that’s fine too. It’s just a matter of evaluating the security vs operational risks.
I’m working in an environment where we use ADRs and SUGs. This article is super helpful. Thank you so much!!!
Thanks Bryan, this was very helpful.
Thank you very much for this post. I find patching extremely tedious, and I’m looking for any help I can get streamlining it.
Thanks for all the hard work and the scripts!