Manually building a software update group every month doesn't scale, and deploying the same updates to every device on the same day is how a bad patch becomes an outage. In this post I'll build a single automatic deployment rule (ADR) in Configuration Manager that creates the monthly group and deploys it in rings — pilot, early adopters, broad and servers — with schedules you can predict and logs that prove each run worked.
How it works#
An ADR runs on a schedule, after a software update point (SUP) synchronisation, or when you click Run Now. It selects updates that match your criteria, downloads them into a deployment package, puts them into a software update group and deploys that group. One ADR can carry several deployments, each targeting its own collection with its own schedule and user experience. That's what turns one rule into rings.
Before you start, you need:
- A successful SUP synchronisation. Create the ADR after the first sync, especially on non-English sites, so classification names match.
- One collection per ring. Use exclude rules so a device lands in only one ring.
- Maintenance windows on server collections, with Apply this schedule to set to Software updates or All deployments.
- A package source share where both you and the SMS Provider's computer account have write permission.
Here's the design used in this post. In an ADR, the deadline is counted from the available time, and both are counted from the rule's evaluation:
| Ring | Collection | Available | Deadline (after available) |
|---|---|---|---|
| 0 – Pilot | IT and test devices | As soon as possible | 2 days |
| 1 – Early | A representative slice of each department | 2 days | 3 days |
| 2 – Broad | All other workstations | 7 days | 7 days |
| Servers | Server collections with maintenance windows | 7 days | 1 day, installed inside the window |
Step-by-step#
1. Create the rule#
Go to Software Library › Software Updates › Automatic Deployment Rules and select Create Automatic Deployment Rule. On the General page:
- Template: Patch Tuesday.
- Collection: Ring 0 – Pilot.
- Choose to create a new software update group each time the rule runs. When a rule adds to an existing group, it first removes everything already in that group, which suits daily definition updates but not monthly patching.
- Leave Enable the deployment after this rule is run selected, or clear it if you want a manual review gate: the site then creates the group and distributes content but leaves the deployment disabled.
On Deployment Settings, set the type to Required.
2. Define the update criteria#
On the Software Updates page, combine property filters such as:
- Date Released or Revised: a short recent window, so the rule only picks up this month's releases.
- Product: the Windows client and server products you actually sync.
- Update Classification: Security Updates and Critical Updates, plus any others you deploy monthly.
- Superseded: No.
- Architecture: exclude what you don't run, but keep x86 alongside x64 unless you're sure, because 32-bit components exist on 64-bit systems.
Preview the results before moving on. A rule can return at most 1,000 updates.
3. Schedule evaluation with an offset#
On Evaluation Schedule, run the rule on a monthly schedule. ADRs can be offset from a base day: if Patch Tuesday content only reaches your SUP on Wednesday local time, schedule the second Tuesday with a one-day offset. Make sure a synchronisation completes before the rule runs, and never schedule evaluations more often than synchronisations. Avoid running a "new group" rule after every sync, or you'll get a new group each time.
4. Configure the pilot deployment#
- Deployment Schedule: choose client local time or UTC. Available As soon as possible; deadline Specific time, 2 days. The effective deadline includes a random delay of up to two hours.
- User Experience: keep notifications on and decide whether installs and restarts may happen outside maintenance windows at the deadline. Enable re-evaluation after restart so devices pick up anything that becomes applicable.
- Download Settings: decide whether clients may use neighbour or site default boundary group distribution points.
- Deployment Package: create one package for the rule (for example, Windows monthly updates), reuse it, and target a distribution point group.
On the Summary page, use Save As Template so future rules start from the same settings.
5. Add the remaining rings#
Select the rule and choose Add Deployment in the ribbon. The wizard repeats the collection, deployment settings, schedule, user experience, alerts and download pages. Add Ring 1, Ring 2 and Servers with the timings from the table. For servers, set the deadline behaviour so installation and restarts wait for the maintenance window.
Tip: Since version 2203, available and deadline times are calculated from when the evaluation is scheduled to start, not when it finishes, so ring timings no longer drift with long downloads.
Verify#
- Select the rule and click Run Now (only in a test cycle — it creates a real group). Check the Last Error Code column, then open
ruleengine.logon the site server. A healthy run contains lines like these (exact wording can vary between versions):TextCRuleHandler: Processing Rule with ID:1, Name:Windows monthly updates. Rule resulted in a total of 4 updates 1 update(s) need to be downloaded in package "PS100012" We need to create a new UpdateGroup/Deployment CRuleHandler: Rule 1 Successfully Applied! - If downloads fail, read
PatchDownloader.log; for ADRs it's in%windir%\CCM\Logson the site server when the client is installed there. - Under Software Update Groups you should see a new group, and under Monitoring › Deployments one deployment per ring with the expected available and deadline times.
- Track progress with View Status on each deployment, the Monitoring › Overview › Security › Software Updates Dashboard, and the reports in the Software Updates – A Compliance category.
Tips & gotchas#
- Bad patch? Stop the later rings. Disable or delete the Ring 1, Ring 2 and Servers deployments on that month's group before their available time; the pilot has already told you what you need to know.
- Use the Deployed filter carefully. It helps find updates you haven't deployed yet, but an update deployed to your pilot already counts as deployed.
- Maintenance windows must fit the updates. An update won't start if its maximum run time doesn't fit in the remaining window — see updates not installing from Configuration Manager for the client logs.
- Keep the catalogue lean. ADRs evaluate faster against a maintained SUP — see software update point and WSUS maintenance.
- Organise. Since version 2207 you can put ADRs in folders, which helps once you have separate rules for Windows, Microsoft 365 Apps and definitions.

