A common point of confusion for folks just starting with System Center Configuration Manager (ConfigMgr or SCCM) is exactly what Automatic Deployment Rules (ADRs) do.

What ADRs Don’t Do

The first thing to note about ADRs is they don’t directly deploy updates. Thus, if you are troubleshooting an update install issue on a single client, troubleshooting an ADR is meaningless and unrelated. Validating that an ADR evaluated successfully and that the update package is successfully distributed to all necessary distribution points is certainly something to validate when troubleshooting, but those are not client side issues. Clients know nothing about ADRs or their evaluation.

What ADRs Do

There are three things and only three things that an ADR does:

• Create or update an update group.*
• Create or update update deployments on that update group.*
• Download and add updates to the update package referenced in the ADR.

* Create if you choose for the ADR to create a new update group one each time it is evaluated; update existing if you choose to reuse the same update group.

In the case of reusing update groups, there is a link between an ADR and the update group it creates, however, this link is not persistent. Simply updating an ADR doesn’t change or update the linked update group, its update deployments, or the reference update package. That only happens at the time that an ADR is evaluated and then only if the criteria specified in the ADR results in a change to the update group.

ADR Troubleshooting

When it comes to ADR troubleshooting, there is one log to rule them all: ruleengine.log. Ruleengine.log is on the site server of course because clients don’t know anything about ADRs.

This log has everything in it including details about update downloads. As usual, if you are looking for issues in this log, read the log, don’t just look for yellow or red lines. Also, if a line is red or yellow, read the line again as some of the completely normal, non-failure messages in this log have the trigger keywords within them; e.g., error.

ADR Tips

• Space your ADR evaluations out so that they don’t run at the same time or on top of each other. This will spread out the load and eliminate the possibility of database and download contention issues which do occasionally occur.
• Set the available offset time for all deployments to at least one or two hours (or more depending on your infrastructure). This gives the newly downloaded content a chance to get to your distribution points before clients start requesting it.
• Use multiple deployments. If you have multiple ADRs that have the exact same update criteria specified that are intended to go to different collections (for a phased deployment), collapse these ADRs and use multiple deployments instead.
• Don’t use the Required attribute unless you absolutely have to in order to control network bandwidth usage. The Required attribute is a lagging, reactive indicator. If a product is in-scope to be updated by ConfigMgr, be proactive and deploy all possible applicable updates for those products.
• Use the Custom Severity attribute to filter out unwanted updates. Manually set unwanted updates to Low Custom Severity and then include only the other custom severities (None, Moderate, Important, Critical) in the update criteria.
• Decline unwanted updates directly in WSUS manually or using a script. This has the added benefit of pruning the WSUS update catalog used by clients and ConfigMgr which in turn has many benefits including expiring the updates in ConfigMgr. Common updates to decline this way include the following:
  • Itanium
  • Beta
  • Version Next
  • Windows 10 versions not in the environment or unsupported
  • SharePoint