🛡️🪟💻👈🔄Group - Update Ring – Pre-Release (Acceptance)
📄 What this group is about
The included-group for the Pre-Release (Acceptance) Windows update ring. Devices in here pull feature and quality updates one week after the Fast canaries. Long enough for any Microsoft pull-back to have happened, short enough to still beat Production by a full patch cycle. The "lab fleet" without the lab. 🔬
Attached only to 🔄🪟💻 UR – Pre-Release (Acceptance). Nothing else.
This group is deliberately empty by default on small tenants. On tenants with fewer than ~30 devices, Fast → Production produces enough signal and Pre-Release adds bureaucracy without adding much detection. Populate the group only when the fleet grows enough that device-mix variance is worth catching. 🌱
🛠️ Configuration Table
| Setting | Value | Additional Info |
|---|---|---|
| Name | 🛡️🪟💻👈🔄Group - Update Ring – Pre-Release (Acceptance) | |
| Description | Devices on the Pre-Release update ring (7-day Quality / 21-day Feature deferral). Used to validate updates against the actual fleet mix (one representative device per OEM model and per department) before they reach Production. | |
| Group type | Security | |
| Membership type | Assigned (Device Group) | Curated by the MSP. Not a dynamic rule. Membership is deliberate. |
💬 Why this matters
The Fast ring is too small and too atypical to catch every regression. IT laptops are not a representative sample of anything except IT laptops. Pre-Release closes that gap with coverage, not volume:
- One device per OEM model (Dell, HP, Lenovo, Surface, that one Tongfang nobody knows how it got there)
- One device per department (accounting, sales, shop-floor, reception)
- A representative Cloud PC if the tenant uses them
- A representative kiosk-style device if the tenant has them in active use
The goal isn't more bodies in the testing pool. It's covering the variance in the fleet so issues affecting one OEM driver or one LOB app don't surface for the first time in Production at 9am on a Monday. 😬
Who belongs here once populated:
- The first laptop of each model the MSP supports
- One device from each department with distinct workflows
- One representative remote-worker device (different network, different update arrival)
- One representative Cloud PC if applicable
Who does not belong here:
- The whole IT team (they're already in Fast)
- Volunteers who "want new features first" (also Fast)
- Mission-critical endpoints (Production)
- Devices that are already in Fast. A device belongs to exactly one ring. 🚦
💡 SuperVision tip
Membership is manually assigned and stays that way. Like Fast, this is one of the rare groups where automation should not take over. The value of Pre-Release is in who is in it, not in how many. A dynamic rule that auto-adds every Dell laptop dilutes the cohort into a second Production ring nobody is watching.
Cohort sizing. 15 to 25% of the fleet once populated. Composition over count. 🎯
Empty group is fine. Pre-Release policy applies to nobody when the group is empty. Architecture in place, no devices yet. That's a feature, not a bug.
Exclusivity. A device belongs in either Fast, Pre-Release, Production (default), or Always-On. Never two. If the SuperVision flow that manages ring membership can enforce this with a "remove from any other ring group on add" step, wire it up.