🔄🪟💻 UR – Always-On (24/7)
What this ring is for 🕛
The ring for devices that have no out-of-hours restart window. Digital signage in a 24/7 lobby. Hospital displays. Transport kiosks. Factory floor monitors. Hospitality check-in screens. Anything that is not allowed to go dark during business hours, because there are no business hours.
The other rings assume a quiet window (19:00 to 07:00) where they can slip a restart in. Always-On assumes that window doesn't exist. So it installs updates silently and leaves the restart to a human. Restart gets scheduled as part of a maintenance window, not driven by a deadline timer that doesn't care whether the device is mid-broadcast. 🖥️
Deferral matches Production (14 days quality / 30 days feature). Security patches still need to land; they don't get a free pass just because the device can't reboot. What changes is how the patched-but-not-yet-restarted state is handled. And on Always-On, that's handled by the admin, not by Windows.
Why this matters 🎭
Without a dedicated ring, 24/7 devices end up in one of two bad places:
- Excluded from update management entirely. They get Microsoft's default WU behavior, which means they restart when Windows feels like it. The public display goes black mid-shift. Helpdesk gets a call. Manager gets a call. It's bad.
- In Production with a deadline timer. Eventually the deadline fires and the device restarts mid-business-hour, taking the public-facing display down at the worst possible time. Also bad.
Always-On is door number three: managed updates, no auto-restart, restart coordinated by humans. The cost is that Always-On devices live in a "patched but not effective yet" state until someone restarts them. That window is a real risk. But it's a smaller risk than either uncontrolled restart or no patching at all. 🎯
🛠️ Configuration Settings
All settings under Settings Catalog → Windows Update (CSP: ./Vendor/MSFT/Policy/Config/Update/*). Device scope.
Update servicing
| Setting | Value | Why |
|---|---|---|
Microsoft product updates (AllowMUUpdateService) | Allow | Same servicing scope as the other rings. |
Windows drivers (ExcludeWUDriversInQualityUpdate) | Block | Drivers via the dedicated profile. Same convention as the other rings. |
Enable pre-release builds (BranchReadinessLevel) | Not configured | GA channel only. |
| Upgrade Windows 10 devices to latest Windows 11 release | No | Same as Production. Don't surprise an always-on signage device with a major version upgrade. |
Deferral
| Setting | Value | Why |
|---|---|---|
Quality update deferral period (days) (DeferQualityUpdatesPeriodInDays) | 14 | Match Production. Security patches don't get a free pass just because the device can't restart. |
Feature update deferral period (days) (DeferFeatureUpdatesPeriodInDays) | 30 | Match Production. |
Set feature update uninstall period (ConfigureFeatureUpdateUninstallPeriod) | 30 | Same uninstall window across rings. |
Install and restart behavior (this is where Always-On is different)
| Setting | Value | Why |
|---|---|---|
Automatic update behavior (AllowAutoUpdate) | Auto install and notify for restart (value 1) | The headline difference. Install silently, then prompt for restart instead of taking it. Restart is a human decision, not a timer decision. |
| Active hours start | 00:00 | Effectively the whole day. Combined with the auto-update behavior above, prevents any clock-driven restart. |
| Active hours end | 23:59 |
Deadlines
| Setting | Value | Why |
|---|---|---|
| Use deadline settings | Allow | Deadlines still apply to installation. They no longer force a restart. |
Deadline for quality updates (ConfigureDeadlineForQualityUpdates) | 14 days | Two weeks after the device first sees the update, the install completes. Restart still waits for a human. |
Deadline for feature updates (ConfigureDeadlineForFeatureUpdates) | 14 days | Same window for feature updates. |
Grace period (ConfigureDeadlineGracePeriod) | 2 days | Standard grace. |
Auto reboot before deadline (ConfigureDeadlineNoAutoReboot) | Yes, never force a reboot | The other half of the headline difference. Even after the install deadline fires, Windows will not auto-restart. The restart prompt keeps showing; the device keeps running until someone acts. |
User experience
| Setting | Value | Why |
|---|---|---|
Option to pause Windows updates (SetDisablePauseUXAccess) | Enable | The IT admin or on-site operator may need to pause around a known event (a public ceremony, a live broadcast, a scheduled outage). Always-On devices need that escape hatch. |
Option to check for Windows updates (SetDisableUXWUAccess) | Enable | Letting an operator check / install on demand reduces tickets. |
Change notification update level (UpdateNotificationLevel) | Default | Operator needs to see that a restart is pending. Suppressing notifications here defeats the entire ring design. |
Caveats ⚠️
License fit. Settings Catalog on Windows 11 Pro/Business with M365 Business Premium. No tier-up needed.
"Patched but not effective" risk. Always-On devices spend time with the security patch installed but the restart still pending. The patch isn't actually protecting them yet. That's the cost of this ring. Mitigate by:
- Reviewing pending-restart state weekly per tenant (WUfB Reports surfaces this beautifully)
- Scheduling a recurring maintenance window per Always-On device (monthly, off-peak for that specific device's operational profile)
- Alerting when a pending-restart age exceeds 30 days. That's a device that's been silently unpatched-effective for a month, which is your canary that operational discipline broke down. 🚨
Driver updates still apply. The 🔄🪟💻 DU – Automatic (Recommended) profile assigns to All Devices and is not excluded by ring. Recommended drivers will install on Always-On devices and prompt for restart, same as quality updates. If a tenant has Always-On devices where this is a problem, carve those devices out of the DU Automatic profile per tenant. Rare. Most signage and kiosk hardware has stable drivers and rarely sees Recommended updates anyway.
Don't use this ring as a dumping ground. Devices that could restart between 19:00 and 07:00 belong in Production. Always-On is for devices that genuinely can't. A misclassified device here is a device that gets patched and never effectively rebooted because nobody triggered the restart. That's worse than Production.
Maintenance discipline matters more here than for any other ring. Production restarts itself; Always-On does not. If the operational discipline to coordinate restarts doesn't exist for a given tenant, those devices are objectively safer in Production (with the off-hours restart accepted as a small operational cost) than in Always-On (silently accumulating unrestarted patches). 🧘
Reversibility, handled by the next ring. Same as the other rings. The four ring policies are symmetric (every setting present in one is present in all four with its own explicit value). When a device moves between rings, the next ring's policy overwrites the tattooed values cleanly. No paired inverse needed.
💡 SuperVision tip
Baseline policy. Golden Master → Windows → Windows Updates → Update Rings → Always-On (24/7). Assigned to 🛡️🪟💻👈🔄Group - Update Ring – Always-On (24/7) and nothing else.
Tag candidates: none. The whole point of this ring is uniform restart-restraint behavior.
Cohort sizing. Whatever the tenant's actual 24/7 device count is. Could be zero (most MKB tenants), could be a dozen (hospitality, healthcare). Don't pre-populate. Add devices to the group only when their operational profile genuinely demands it.
Drift detection. The single most important setting to monitor is ConfigureDeadlineNoAutoReboot. If that flips back to "force reboot" via a stray policy or a Windows reset, an Always-On device suddenly will auto-restart, which is the exact failure this ring exists to prevent. Daily check on a sample, not quarterly. 🔍
Pending-restart age monitoring. Set up an alert in WUfB Reports for Always-On devices with pending restart age over 30 days. That's the canary for "operational discipline broke down on this tenant."
Multi-tenant scaling. Policy is identical; group composition is per-tenant. Most tenants will have an empty group. That's fine. The architecture is in place when the need arises.
👥 Group Assignments
✅ Included groups:
❌ Excluded groups:
None. Always-On is opt-in via group membership.
Standardize like a pro. Configure with intent. And remember: an unpatched 24/7 device is worse than a patched-but-not-yet-restarted one… for a while. Don't let "a while" become "forever." ⏳