A little note on ADR

Do you really know what Automatic Deployment Rules (ADRs) in ConfigMgr do?


ADRs Do not
First -  ADRs do not (directly) deploy updates.
Clients do not know about ADRs, so - if you are troubleshooting an update installation issue on clients, troubleshooting an ADR is not relevant.
Of course you sould validate that an ADR did evaluate successfully and that the update package is successfully distributed to distribution points, but those are not client side issues.


ADRs Do
There are three (3) things an ADRs do:
- Create or update a deployment package (and download updates to the deployment package).
- Create or update an update group.
- Create or update update deployments on that update group.


Updating an ADR does not change or update an update group, its update deployments, or the reference update package.
This only happens at the time where the ADR is evaluated and then only if the criteria specified in the ADR results in a change to the update group.

ADR Troubleshooting

For ADR troubleshooting, there is one log to rule them all: ruleengine.log. 

Ruleengine.log is of course on the site server.

This log has everything in it, including details about update downloads. 

ADR Tips

- Space your ADR evaluations so 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.

- Set the available offset time for all deployments to allow forvthe newly downloaded content to get to your distribution points.

- 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 use 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 includes the following:

- Itanium

- Beta

- Version Next

- Windows 10 versions not in the environment or unsupported

- SharePoint