🛡️🪟💻👈🔄Group - Update Ring – Always-On (24/7)
📄 What this group is about
The included-group for the Always-On (24/7) update ring. The cohort of devices that have no out-of-hours restart window and need manual restart coordination instead of clock-driven auto-restart. 🕛
Attached only to 🔄🪟💻 UR – Always-On (24/7). Membership in this group also excludes the device from the Production ring (which would otherwise assign by default to All Devices).
The group is deliberately empty by default. Most MKB tenants have zero genuinely 24/7 devices. Group exists so when the need shows up, only membership has to change. Not architecture. 🧰
🛠️ Configuration Table
| Setting | Value | Additional Info |
|---|---|---|
| Name | 🛡️🪟💻👈🔄Group - Update Ring – Always-On (24/7) | |
| Description | Devices that genuinely cannot restart during business hours. Updates install silently, restart is coordinated by humans during scheduled maintenance windows. Used for 24/7 signage, hospital displays, transport kiosks, hospitality check-in screens, factory floor monitors. | |
| Group type | Security | |
| Membership type | Assigned (Device Group) | Manually curated. Never a dynamic rule. Membership is a deliberate operational decision per device. |
💬 Why this matters
The fundamental question for any 24/7 device is: what happens at 03:00 on a Tuesday when Windows decides it's time to install KB5048667?
- Default Windows Update behavior: restart whenever. Public display goes black mid-shift. 💀
- Production ring: restart between 19:00 and 07:00. Except the device is on 24/7 and "07:00" is mid-shift somewhere.
- No managed ring at all: unpatched indefinitely. Cyberinsurer cries.
- This ring: patch installs silently, restart waits for a human to schedule it. 🧘
The trade-off is real. Always-On devices accumulate pending restarts and live in a "patched but not effective yet" state between the install and the operator-coordinated restart. The exploit risk on a patched-but-not-restarted device is smaller than on an unpatched one, but it's not zero.
Maintenance discipline matters. A tenant that drops devices in this group and then never coordinates restarts is in a worse spot than they would be on Production. You've been warned. 😬
Who belongs here:
- 24/7 signage in lobbies, retail windows, transport hubs
- Hospital ward displays, nurse-station monitors that can't be dark
- Hospitality check-in / digital-key kiosks where downtime breaks the guest experience
- Factory floor monitoring displays
- Always-on conference room signage that displays "current event" boards
Who does NOT belong here:
- A retail kiosk that's open 9 to 18 and powered off overnight (Production. Restart happens during the off-window.)
- A reception monitor in an office that closes weekends (Production. The weekend restart window is plenty.)
- A "we'd rather it didn't restart during work hours" wish-list device (Production. With the off-hours restart accepted as the operational cost.)
- Any device where the tenant doesn't have someone responsible for coordinating restarts (Production. Where Windows handles it.)
💡 SuperVision tip
Membership is manually assigned and stays that way. Never automate this with a dynamic rule. The entire premise of the ring is that membership is a deliberate operational decision per device.
Empty group is fine. This is the most-likely-empty of the four ring groups. Most MKB tenants will never need it. Some hospitality, healthcare, retail tenants need it for a handful of devices. Either way, the group is here when you need it.
Pair every addition with a maintenance schedule. A device added to this group should also get a recurring maintenance window logged somewhere SuperVision can see. Monthly at minimum, with the actual restart action assigned to a named human or runbook. Without that pairing, you're configuring patched-but-never-restarted devices. Which is the failure mode the whole ring exists to prevent. 🚦
Alert on pending-restart age. SuperVision should pull pending-restart age from WUfB Reports and flag any device in this group where pending restart exceeds 30 days. That's the canary that the maintenance discipline broke down for this tenant.
Exclusivity. A device belongs to exactly one ring. SuperVision's group-management flow should enforce that adding a device to Always-On removes it from Fast or Pre-Release groups if present.