Policies, rings and maintenance windows
How patch policies decide what approves itself, when devices install, in which ring order, and how they restart.
Updated
On this page
A policy decides what approves itself and when, the maintenance window, the rings and how devices restart. Every customer uses the workspace default (Standard, created automatically) unless you assign another, and a device can override its customer's policy. Each policy describes itself in plain words at the top.
Where to manage them
- Portfolio → Patching → Policies: the templates. New policy, Edit, Duplicate, Make workspace default and delete. Customers and devices using a deleted policy fall back to the default.
- Customer → Patching → Schedule & policy: the policy in effect, a picker (Workspace default or another), Customize for this customer (a copy only this customer uses), the customer's time zone, the next maintenance windows and the rings.
- Devices: select devices → More → Assign policy… or Set ring…, or a device's Settings tab.
Editing policies needs the patching permission (technicians, admins and owners).
What a policy contains
| Section | Settings |
|---|---|
| Windows updates | Per classification (security, critical, definition, update rollup, feature pack, service pack, update, driver, upgrade, tool, other): auto-approve or not, and after how many days (0–90). By default only security and critical updates auto-approve, after 2 days. Optional updates in or out. Never install these updates: KB numbers excluded on this policy's devices (exclusions) |
| Applications (winget) | Auto-approve and after how many days (default 3); Never auto-approve these package IDs; Only auto-approve these (empty means all) |
| Linux packages | Auto-approve security updates only, or all package updates, after how many days |
| macOS | Follows the OS rules: security updates by the security setting, others by the other updates setting |
| Known-exploited fast track | On by default: updates that fix a CISA KEV vulnerability skip the waiting days and ring delays |
| Rings | 1–5 rings, each with a delay of 0–30 days |
| Maintenance window | Days of the week, start time, length (30–720 minutes), time zone |
| Missed window | Wait for the next window, or install when the device comes back online within 1–72 hours, optionally waiting 0–240 minutes after it starts |
| Restarts | Never, if an update requires it, or always; warning time and message; latest restart time |
| Windows version | The version devices should run, methods and compatibility check. See Windows version upgrades |
| More | Download ahead (1–12 hours before the window), accept licence agreements, notify on failures or completion, automatic retries of a failing update (1–10 attempts) |
Rings
Rings let you test first. The default policy has Pilot (0 days) and Broad (3 days). An approved update reaches Pilot devices in their next window and Broad devices in the first window at least 3 days later. A device without a ring uses the last ring.
Put a few representative devices in Pilot: customer Schedule & policy → Rings, or select devices → More → Set ring….
Maintenance window
- A window set to customer time uses the customer's time zone (set it in Schedule & policy; until then, UTC), so one policy works for customers in different zones. You can also pick a named time zone.
- New installs don't start in the last 15 minutes of the window.
- Download ahead stages updates before the window so the window is spent installing.
- If a device is offline for its window, the policy either waits for the next window or installs when it comes back, within the hours you choose. With a delay, it waits until the device has been running that long, so the person who just switched it on isn't slowed down at once.
Excluded updates
Some updates are known to break things (a printer driver, a line-of-business app). Exclude them by KB number:
- in a policy, under Windows updates → Never install these updates, for the devices that use the policy;
- for the whole workspace, on the Patching overview under Excluded updates (owners and admins).
An excluded update shows as Excluded and never installs, even if someone approves it. Updates already sent to a device aren't recalled.
Restarts
| Setting | Behaviour |
|---|---|
| Never | Installs run; the device isn't restarted. Updates that need a restart show restart pending |
| If an update requires it | Restarts only when an installed update needs it |
| Always | Restarts after every window that installed something |
Signed-in users get your warning (none to 1 hour ahead) and message. The latest restart time can be up to 240 minutes after the window. Restarts are always refused on devices whose local administrator turned them off.
Licence agreements
Accept licence agreements is on by default. Without it, updates that need a licence accepted are skipped. macOS updates always need it (Apple's installer requires it), so macOS devices are skipped with that reason when it's off.
Which policy applies
The device's own policy if it has one, else its site's (set in RMM → Policies), else its customer's, else the workspace default. Manual installs ("install now") take EULA acceptance and the latest restart time from each device's own policy.