Software Updates and Automatic Deployment Rules in ConfigMgr

Software Updates and Automatic Deployment Rules in ConfigMgr

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 contain1Update 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.
Example ADR List Using Product Categories

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 screenshot2Always 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).
Custom ADR Evaluation Schedule for 1200 US Central Time (UTC -5/6) on the Day After Patch Tuesday

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 appropriate3Note 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.
The Criteria for the All Workstation Updates Product Category Based ADR

How Many Update Packages

  • Use a single update package4These 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 needed5Many 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.
Master and Sub-collections for Software Updates

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 ran6In 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. 7If 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 days8A 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 approach9My 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.

Footnotes   [ + ]

1. Update groups, for performance reasons, can only contain 1,000 updates; this is enforced by the console but not necessarily the SDK.
2. Always keep in mind that at least twice a year, the second Wednesday occurs before the second Tuesday during a month.
3. 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.
4. These are called Deployment Packages in the console but I refuse to call them that because they have nothing to do with deployments.
5. 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.
6. 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.
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.
8. 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.
9. 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.
Software Update Point Facts

Next Article

Software Update Point Facts

13 Comments

Cancel

  1. 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.

  2. 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.

  3. 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.

  4. 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

  5. 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.