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.