Configuring Automatic Update Rules (ADRs) in System Center Configuration Manager (ConfigMgr or SCCM) comes up often in the forums and at customers as there is no one, clear-cut way to configure them. Here’s a run-down of what I normally recommend and configure:
How Many ADRs
- Use one ADR per product category or product; e.g., Workstation OS updates, Server OS updates, Office updates, and Other updates OR Windows 7 Updates, Windows 10 Updates, Windows Server 2012 Updates, etc.
- If you are still managing Windows Server 2008 or 2008 R2, then a generic product category won’t work for these as there are way too many updates for a single update group to contain((Update groups, for performance reasons, can only contain 1,000 updates; this is enforced by the console but not necessarily the SDK.)). In this case, you’ll have to use an ADR for each product, multiple even depending on the classifications that you include.
- The following screenshot shows how simple it truly can be.
How Often Should ADRs be Evaluated
- Monthly for most ADRs. The only class of updates that are issued more frequently, in general, is Endpoint Protection and Windows Defender definition updates; these should be evaluated at least once a day.
- Any more frequently than monthly will quickly become a burden to test, a burden on your end-users, and a burden to maintain.
- This, of course, does not include one-off zero-day or other high-priority updates.
When Should ADRs be Evaluted
- For non-definition ADRs, anytime after 1000 US Pacific Time (UTC -7/8) on the second Tuesday of the month which is when Microsoft schedules the main, monthly publishing of the WSUS catalog.
- For definition ADRs, I recommend 0600 and 1800 every day.
- I strongly recommend that you wait at least 12 hours after 1000 US Pacific Time though to account for delays or other issues that are not uncommon with the publishing of the catalog. As of ConfigMgr 1802, setting an offset from the second Tuesday is possible as shown in the following screenshot((Always keep in mind that at least twice a year, the second Wednesday occurs before the second Tuesday during a month.)). This is useful for the delay as described or for those folks in the eastern hemisphere where 1000 US Pacific Time is the next day already (or both).
How Many Software Update Groups
- Use one software update group per ADR.
- Reuse update groups each month.
What Criteria Should Each ADR Use
- Each ADR should filter on a set of products within a category or a single product.
- Each ADR can also filter on classification and language as appropriate((Note though that Windows 10 and Server 2016/2019 Cumulative Updates (CUs) aren’t always of one classification. To deploy all CUs for these products, you need to include the Updates, Security Updates, and Critical Updates classification.)).
- Each ADR should exclude superseded updates.
- ADRs should not filter on the Required attribute or any dates. Resulting software update groups should contain all updates for a product category or product. Anything less is reactive instead of proactive and security needs to be proactive. Using these attributes also leaves the door open for a new system to enter the environment needing an update no longer deployed or for an update to be removed on an existing system. In both cases, systems will be unpatched with no immediate action enforced to apply the update.
- With products updated using CUs, this is largely moot as there won’t ever be any more than a single non-superseded update anyway.
- For products with traditional update models, this does mean more disk space usage. That’s an easy trade-off though as security should easily override any disk space concerns or costs.
- The following screenshot shows how simple the criteria should be.
How Many Update Packages
- Use a single update package((These are called Deployment Packages in the console but I refuse to call them that because they have nothing to do with deployments.)) for each ADR. This creates some separation and organization to the update binaries. Which package an update is in isn’t explicitly important because the clients don’t really care — clients can download an applicable update from any package available to them as there is no connection to the update group or deployment used to assign the update to a client.
- Having some separation is beneficial though for content distribution purposes or if you encounter package integrity issues. It also allows you to selectively distribute update packages to different DPs depending on the clients using that DP; e.g., not distributing server updates to DPs not servicing any server OS client systems.
How Many Deployments Per ADR
- Use multiple deployments on each ADR to create deployment phases as needed((Many folks missed and/or still don’t know that as of 1602, multiple deployments can be configured on each ADR. This enables an ADR to create and update multiple, separate deployments on the software update group linked to it.)).
- Each deployment should target a collection representing a separate phase
- Enable the deployments for test or pilot phases.
- Disable the deployments for production phases. This creates an explicit “gate” requiring an administrator to flip the deployment to enabled each month after they perform a quality check of the update group, the deployments, and the status of the updates in the update group.
- Alternatively, use a single deployment to target a “master” collection of systems where actual update deployment times are dictated by maintenance windows applied to collections containing a subset of the membership of the “master” collection.
- This approach is typically best used with servers as guaranteeing that user systems are ever on during any defined maintenance window is difficult if not impossible.
- The following screenshot shows a simple example of this. The red arrow indicates the master collection where the deployment is targeted. The green arrows indicate the sub-collections that are limited to the “master” collection and contain a subset of the members of the master collection; maintenance windows are applied to these sub-collections to control when update deployments are enforced by the clients in these collections.
What About Manual Clean-up
- There’s none required.
- ADRs will effectively auto-groom their connected update groups every time they run; i.e., they will remove expired and superseded updates automatically while adding new updates released since the last time that the ADR ran((In reality, update groups are completely cleared out each time the ADR runs and only updates that meet the ADRs update criteria and added. The end effect is thus as described: all superseded and expired updates are removed from the update groups automatically.)) ((If the evaluation of an ADR would result in no changes in the membership of an update group, then no action is actually taken.)).
- Expired updates that are no longer deployed will also be removed from update packages and update package source locations automatically by the update catalog synchronization cycle after seven days((A bonus here as of ConfigMgr 1810 is that any updates that ConfigMgr flips to expired will be declined directly within WSUS thus effectively removing them from the WSUS catalog.)).
Two (Small) Drawbacks
Update Deployment Time Tracking
- By reusing the same update groups every month, you lose the ability to explicitly track when an update was deployed. In most organizations, this is not an issue as the month an update was released is also when it was deployed.
- Unfortunately, the built-in reports don’t filter on the date released so if you are are interested in this, then you’ll either have to write your own reports or better yet, use one of the awesome sets released by the community including those by Gary Simmons.
- If your organization truly cares about the exact month or time when an update was deployed, there’s no way to explicitly track this in the current version of ConfigMgr (although I’ve been bugging the product team about this for a while now).
- By not reusing update groups, i.e., creating new update groups every month, you do (kind of) get all of this because you will have update groups for each month. In reality, though, there’s no guarantee that updates weren’t added to or removed from these update groups after the fact, so I’d honestly say this is questionable at best until the product group adds definitive tracking.
No Deploy Period
- Using a single set of ADRs and update groups for each product or product category as described above results in a period of time where no updates will be deployed at all. This is the period between when the ADRs run each month and when they become required. Depending on your update cycle, this could be as little as a few days (and thus not a big deal) or it can be as long as a few weeks. The longer that this no deploy period lasts, the shorter the actual deploy period lasts as well which will certainly impact overall compliance and is thus undesirable.
- Why does this happen? When the ADR runs, it resets the available and deadline times on all deployments to something in the future and thus, nothing is currently deployed anymore (except to maybe your test collections).
- If you have a large deployment cycle where this significant no deploy period will be impactful (anything more than a week would certainly be impactful IMO), then doubling the number of ADRs and software update groups will address this shortcoming without a lot of additional overhead or work.
- Basically, you create two ADRs for each product or product category. Both sets are exactly as noted above except that each runs bi-monthly: specifically one runs in odd months, and one runs in even months thus leap-frogging over each other every month.
- The ADRs for the same product or product group use the same update package thus nothing additional is required as far as disk space or network goes.
- The n-1 ADR will contain compliance information of all previous updates and continue to deploy all previous updates.
Advantages
- Simple and well organized.
- Minimum clutter with the fewest possible update groups and ADRs.
- Self-cleaning. No monthly, quarterly, or annual clean-up of any kind.
- Comprehensive and proactive.
Disadvantages
- You’ll need more disk space and there will possibly be some additional bandwidth requirements. This is an easy trade-off IMO though in the name of security.
- No others that I know of.
Hints
- Use a script to create your ADRs particularly if you go for the two ADR approach((My scripts for this (among other things) are located on GitHub — the Build-CMDefaultConfig.ps1 in the Build folder which in turn uses the CMDefaultConfig.json configuration file.)).
- Always check the status of your ADRs and the distribution of the update packages as failures in either of these are the most common root causes of issues with software updates (besides WSUS being old and decrepit).
- Use multiple methods as needed. There’s no rule that says you have to do it all one way.
Hi,
for this topic here: “What About Manual Clean-up”
It´s right, the Softwareupdategroup will be clean-up but I saw that the created package will not be clean-up, here you must look from time to time that that will not increase to many and let your old updates in there.
No, that’s incorrect. Update packages and source content will get cleaned up automatically. This doesn’t happen during ADR evaluation though. See https://techcommunity.microsoft.com/t5/Configuration-Manager-Archive/Software-Update-Content-Cleanup-in-System-Center-2012/ba-p/273069 and https://support.microsoft.com/en-us/help/3090526/software-update-maintenance-in-system-center-2012-configuration-manage for details on this process.
Thx, that is what I saw in the practise but I will read your links and check it.
This exact setup I had until this month when my Windows 10 OS ADR failed for some reason at recreating the deployment schedules. This meant that January Windows 10 patches were deployed to production since the deployment deadlines still had the December dates in them. I’ve now switched to monthly software update groups. At the end of the year I’m planning to clean them up and unifiy them in a single update group for 2019. In this way I can maintain continuous deployment to newly deployed machines as well.
Failures happen. Changing to new update groups every month won’t change that. For your exact issue, that’s why I recommend disabling the deployments targeting product collections and that way you can QC what’s going on. Honestly, if I had to guess, the ADR evaluation probably resulted in no changes meaning that it specifically chose not to change anything.
> At the end of the year I’m planning to clean them up and unifiy them in a single update group for 2019
Yuck.
Any recommendations for handling groups that would end up containing more than 1000 updates? Example: Server Updates for Server 2008-2016. I currently handle this with a “Baseline” Group (updates prior to 2017), 2017 Group, 2018 Group and 2019 Monthly with ADR.
For now (1 more year) you end up having to create a separate ADR just for 2008 and one for 2008 R2. If you are deploying all update classifications as well, then you really need two for each from memory that are set up per classification. This is annoying but trivial ultimately if you are using a script to set up your ADRs.
Thanks Jason, a much needed post!
These are the different methods I had rough notes on with the advantages/disadvantages:
• Separate by Year\All in one: You can group updates for all products together in one group for the each year and deploy out to every device in the environment. For example, this means that updates for Windows Server 2016, Windows 10 and Office 2016 are deployed to both Workstations and Servers.
Positives: Less to see and manage in the SCCM Console
Negatives: Causes manual work, clutter, and is more complex in general. It also increases overhead on the clients if they must maintain and report on compliance for updates that can’t possibly be applicable to them
• Separating by Workstation and Server: This is the same as the method above but breaks out the updates into Server and Workstation groups
Positives: Less overhead that the method above. Less to see and manage in the SCCM Console
Negatives: Causes manual work, clutter, and is more complex in general. It also increases overhead on the clients if they must maintain and report on compliance for updates that can’t possibly be applicable to them
• Separate by Products:
Positives: Less maintenance and less overhead during scanning
Negatives: You do not know exactly when an update was deployed, however, that’s generally not vital info.
• Required: Only updates actually required by devices will be downloaded and held within SCCM
Positives: SCCM does not have to store updates that are not required by devices. Much easy to decommission\delete updates for Products that are no longer required
Negatives: A reactionary approach. It will miss updates needed by clients right now like those deployed during OSD. If an old machine comes online then it will result in a few hundred extra updates having to be downloaded that month
An excellent supplement to my post; thank you for sharing.
Most of our ADRs fail with ‘failed to download content’ every time they run. The rulenegine.log indicates about 60 failures. We are syncing from an upstream WSUS server and running 1806. I am trying to find out whats missing but the ruleengine.log lists contentID and UpdateID which I cant seem to match with the update its complaining about. Any ideas?
Thanks
The v_UpdateInfo view in the database has these ids in it from memory.
v_updateinfo has a column called CI_ID which seems to match the contentID specifed in ruleengine.log. However, for the download failures, the CI_ID does not appear in the view. So it would appear that v_updateinfo only contins successful download info.
Im curious as to what the ADR is actually looking at to determine what to download. The reason is that maybe I can discover that these failed downloads are not stuff thats really needed and delete them from the ADRs source of truth to eliminate the errors?
Hi David,
Keep in mind that there isn’t a 1 to 1 relationship between updates and files. Some updates contain many files. If you review the Content Information tab on the Properties dialog for any update, you’ll see the files in that update along with the COntent ID and location where that file will be downloaded from. The vSMS_CIContentFiles view will show you this info directly. The COntentID is a foreign key to another linking view as well which in turn can probably be linked to v_UpdateInfo but I’m not sure of the exact view relationships to walk for this off-hand.
I would love to do this for all updates in our company. But the management has dictated that there will be a week long window for users to install the updates before the deadline and then with an 8 hour reboot countdown.
Currently use ADR’s for EP definitions, servicing stack updates, and O365 updates.
Sorry, not following at all. There’s no reason what I’ve outlined above will prevent this. SImply set the deployment deadlines as +7 days. The reboot countdown has nothing to do with ADRs either, that’s configured in client settings.
I’ve recently switched from monthly evaluation cycles to weekly ones, where the ADR’s run during the weekend.
In conjunction with footnote 7 (If the evaluation of an ADR would result in no changes in the membership of an update group, then no action is actually taken.), it catches all updates that MS releases in the meantime and through Binary Differential Replication on the Deployment Packages it keeps bandwidth usage for distribution in check too.
Other than that, i do almost everything the same. My filters are bit tighter though;
– Architecture: x86 and x64
– Title “-Preview”
But a nice post, always interesting to see how others do it.
The problem with running ADRs weekly and catching non-Patch Tuesday updates is now you’re subjecting your users to further interruptions and reboots. The whole point of Patch Tuesday is to balance user interruptions with security. If your users tolerate this, great — most organization’s users won’t tolerate this though.
As for Binary Differential Replication (BDR), BDR is completely useless for updates as BDR operates on differences between two version os of the same file. Update files are never changed and thus BDR has zero effect other than actually adding overhead to the process.
thanks for this
but i don’t understand the “no deploy period” solution
if two ADR use the same update package, you will deploy immediately to production new updates that will be find by ADR of month +1 no ?
First ADR gets for exemple january updates. add them to windows 10 package, deploy to test collection immediately, to production collection two weeks later
second ADR will run next month, it will download february updates, add them to windows 10 package, deploy to test collection immediately, to production collection two weeks later
but the first deployments in the january ADR now have also the february updates, and the “two weeks later” for production have passed, so february update will be immediatly available for all, no ?
Really late reply here (sorry missed this comment). No to the above as you don’t deploy update packages. You deploy updates or update groups, not packages. The packages are simple containers for files and have no direct correlation to update deployments.
Thus, the Odd ADR (the one that ran in January) updated the Odd Update Group with all updates released up to January. The Even ADR (the one that runs in February) updates the Even Update Group with all updates released up to February. The Odd Update Group is unaffected by the Even ADR thus the deployment on the Odd update group still only deploys updates released up to January.
Okay, after reading, reading, and rereading I think I understood the principle of even and odd months.
but I have another question. If I create an ADR by OS (windows 7, 10, 2012 R2 etc), is it better to target deployments on collections that only contain the OS in question, or it doesn’t matter. I know that Windows will automatically eliminate patches that do not concern it, but isn’t it better to only present to an OS the patches that interest it (avoid that a Windows 10 workstation has to check 700 Windows 7 patches for example)?
Translated with www.DeepL.com/Translator
First, it’s not exactly Windows itself filtering out non-applicable updates but is more of a combination of the ConfigMgr agent respecting the compliance scan data (which is produced by the Windows Update Agent) and not trying to install not applicable updates at all.
Is it better to have tighter targeting? Yes. But it’s not a significant difference on a small scale since all managed clients scan for the compliance of all updates in the WSUS catalog and not just those deployed to the client. If you’ve automated the process of creating ADRs, then adding in additional ADRs is pretty trivial so if that is the path you choose, great.
Hi Jason,
First : Great Articles, very helpfull for us for our project ! And thanks for that.
After reading several articles and others topics, I see differents answer for our question : do we need a Domain Policy for the managed clients ? Official documentation say no, local policy is pushed by SCCM. But seems to be often recommended by topics.
Problem : in our context, managed clients without an policy specified the WSUS Server with SUP Role (separated server ConfigMgr with other sccm roles) doesn’t receive updates.
ADR are functionnal, packages deployed, all other seems to be fine. We don’t have any problem with other standard package deployment.
Any idea ?
Thanks,
The local group policy applied by the ConfigMgr client agent is sufficient to enable ConfigMgr to deploy updates to clients; however, it doesn’t prevent some undesirable behaviors or necessarily configure everything that may be desired. That’s where a supplemental group policy or configuration item comes in. In particular, configuring automatic updates to disabled is strongly recommended to disable the Windows Update Agent from going off and doing its own thing like rebooting systems.
For troubleshooting, always start with wuahandler.log on the client(s).
For update classifications, if we choose “updates” and “update rollups” is that redundant and making the package bigger than it needs to be? Can we just do update rollups each month?
No, not redundant as updates can only exist in a single product classification although the only updates that appear in the update rollups classification anymore are Windows Malicious Software Removal Tools. Monthly quality update rollup appear in UPdates, Security Updates, or Critical Updates depending on what added to the rollup for that month.
Thank you Jason! I had trouble finding that defined anywhere.