In this blog we will review Automatic Deployment Rules (ADRs) and how they can be used to simplify and automate your patching processes in Microsoft Configuration manager.
What is an ADR
When a Software Update Group (SUG) is deployed as a result of an ADR evaluation, updates can be automatically deployed to devices in a target collection. This means that you don’t have to manually select which updates to deploy, resulting in a huge time saving effort
Additionally, by using an ADR to create deployments, you can ensure that all of the devices in your environment are kept up to date with the latest security patches and other important updates. This is critical for maintaining a secure and compliant environment.
NOTE: Latest Information on ADRs can be found at
Getting Started with ADRs
1. Launch your ConfigMgr Console
2. Configure the Software Update Point Role within your ConfigMgr Console. You must have at least one Software Update point defined in your hierachy.
3. Define the classifications for patching, select what you require. Selecting un-needed classifications will add un-necessary bloat in the Windows Server Update Server (WSUS) database.
4. Now align your products as required. Again, be selective here select what you require and ideally nothing more.
5. Define your Sync Schedule as required according to your company’s policy.
For clarity you want to align patching process and if possible, with your evaluation schedule of your ADR rule. More to come on this further in the document.
Creating and Defining an ADR
Within your ConfigMgr console, select Software Library > Overview > Software Updates > Automatic Deployment Rules.
If you right click on the Automatic Deployment Rules Icon, you should get a popup window.
Provide a Name and select a Collection, ideally a test one to being with. Choose whether you want to create a new Software Update Group (SUG) each time the ADR is evaluated or if you want to use the same one each time.
Set your type of deployment. I set REQUIRED as I am targeting a test group to validate those updates.
Here by using set filters it allows you to be granular and specific on the output. Use the preview button here to see excepted results.
Define here how you require those updates to be evaluated. This is critical on how you would like those ADR to perform.
An ADR evaluation can run as often as 3 times a day.
Define when you want the software updates to be available and the deadline for installation.
Define how updates are shown in the Software Center, what happens after the deadline is reached. Also define the restart options based on the OS type (server vs workstation).
Generate alerts in Console as well sending alerts to SCOM if required.
What are Deployment Packages?
Similar to software distribution packages, deployment packages are simply the collection of files needed for a set of updates. They must have a source folder and be available to clients by assigning them to distribution points. There is no way to create a deployment package from the console, you can only create one using the Deploy Software Updates Wizard or the Download Software Updates Wizard.
Create your Deployment package. I created a new deployment package to align with a NEW universal naming convention UNC share for ADR rules associated with PMPC.
I create a UNC share where the binaries go for that ADR rule being set.
Here I target what distribution point I want the content to flow to.
The default is fine here, unless your Software Update Point does not have access outbound.
You can select additional languages as required, this increases the content significantly here.
New feature allowing cloud based as a preferred source. Other factors come to play here, such as split tunneling.
Summary on that ADR creation.
For the Progress and Completion, just select next.
Congratulations, you have now created an ADR rule to help deploy software updates to your organization! Now you can add additional deployments to that rule allowing for more control on how those updates go out.