ππͺπ» UR β Pre-Release (Acceptance)
What this ring is for π§ͺβ
The acceptance cohort. Sits between Fast and Production, pulling updates one week after the canaries. Its job is to catch the regressions that Fast missed because Fast is, frankly, a weird sample.
Think about who's in Fast: IT laptops, dev VMs, the IT director's machine. That's a deliberately strange slice of the fleet. Different drivers, different apps, different usage patterns than the actual humans you serve. Pre-Release fills that gap with one representative device per OEM model and per department. The Dell that accounting uses. The HP that lives at reception. The one rogue Surface Studio that ended up in the design team.
A device sits in exactly one ring. Pull it out of Pre-Release and it falls into Production via the All-Devices default. Production then rewrites the tattooed Pre-Release values on the next sync. Clean handoff, no leftover state. π
Why this matters π―β
A two-ring model (Fast β Production) leaves a hardware-shaped hole. If a regression hits a specific Dell driver, or a Lenovo dock firmware, or that ancient HP all-in-one in the reception desk, it won't surface in Fast (which doesn't have those devices) and it will surface in Production (where there's no time to react). π³οΈ
Pre-Release plugs that hole with coverage, not volume:
- One device per OEM model the MSP supports
- One device per department with distinct workflows
- One representative remote worker (different network profile, different update arrival timing)
- One representative Cloud PC if applicable
Pre-Release is optional in practice for tenants under ~30 devices. On a small tenant the variance in the fleet is so low that Fast β Production gives enough signal. The policy and group still exist; the group just stays empty until the tenant grows past 30 devices. No architecture change needed when it does. π
π οΈ 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, not the ring. |
Enable pre-release builds (BranchReadinessLevel) | Not configured | GA channel only. Still not the Windows Insider Program. π |
| Upgrade Windows 10 devices to latest Windows 11 release | Yes | Same upgrade signal as Fast. |
Deferralβ
| Setting | Value | Why |
|---|---|---|
Quality update deferral period (days) (DeferQualityUpdatesPeriodInDays) | 7 | One full week behind Fast. Any patch Microsoft pulled has been pulled by now, and second-week community signal is in. |
Feature update deferral period (days) (DeferFeatureUpdatesPeriodInDays) | 21 | Three weeks of Fast plus upstream signal before this ring touches a feature update. |
Set feature update uninstall period (ConfigureFeatureUpdateUninstallPeriod) | 30 | Same uninstall window as Fast. |
Install and restart behaviorβ
| Setting | Value | Why |
|---|---|---|
Automatic update behavior (AllowAutoUpdate) | Auto install and restart at maintenance time | Same shape as Fast and Production. |
| Active hours start | 07:00 | Same workday window as Fast. |
| Active hours end | 19:00 |
Deadlinesβ
| Setting | Value | Why |
|---|---|---|
| Use deadline settings | Allow | |
Deadline for quality updates (ConfigureDeadlineForQualityUpdates) | 5 days | Slightly more breathing room than Fast. These are real users with real workflows. |
Deadline for feature updates (ConfigureDeadlineForFeatureUpdates) | 7 days | A full workweek to install a feature update. |
Grace period (ConfigureDeadlineGracePeriod) | 2 days | Same grace as Fast. |
Auto reboot before deadline (ConfigureDeadlineNoAutoReboot) | Yes (reboot before deadline) | Out-of-hours reboot preferred over interactive force. |
User experienceβ
| Setting | Value | Why |
|---|---|---|
Option to pause Windows updates (SetDisablePauseUXAccess) | Enable | The Pre-Release cohort is curated by IT. They can be trusted with a pause button. |
Option to check for Windows updates (SetDisableUXWUAccess) | Enable | Harmless and reduces tickets. |
Change notification update level (UpdateNotificationLevel) | Default | Notification UX matches Fast. |
Caveats β οΈβ
License fit. Settings Catalog on Windows 11 Pro/Business with M365 Business Premium. No tier-up needed.
Empty group is the default for small tenants. Shipping this policy with an empty included group is intentional, not a bug. The architecture exists; populating the group is a tenant-by-tenant operational call, not a deployment decision. Chef's kiss π¨βπ³π for the small tenant that gets to keep things simple.
Reversibility, handled by the next ring. Identical to Fast. Every setting tattoos. The three rings are symmetric; every setting in Pre-Release also exists in Fast and Production with its own explicit value. When a device moves between rings, the next ring's policy overwrites the tattooed values cleanly. No paired inverse policy needed.
Don't double-assign. A device belongs to exactly one ring's included group. If a device ends up in both Fast and Pre-Release groups, the most restrictive deferral wins (Pre-Release), which defeats the whole point of having Fast. SuperVision should enforce mutually-exclusive membership.
π‘ SuperVision tipβ
Baseline policy. Golden Master β Windows β Windows Updates β Update Rings β Pre-Release (Acceptance). Assigned to π‘οΈπͺπ»ππGroup - Update Ring β Pre-Release (Acceptance) and nothing else.
Tag candidates: none. Same logic as Fast: ring identity is not a tenant preference.
Cohort sizing. 15 to 25% of the fleet once the group is populated. Composition matters more than the number. Pick devices that cover the variance in the fleet (OEM model, department, region). Don't just pick the loudest volunteers, because the loudest volunteers are usually IT and they're already in Fast.
Drift detection. Same surfaces as Fast (deferral days and pause access). Quarterly check.
Multi-tenant scaling. Identical policy across tenants. Group composition is whatever each tenant picked for representative coverage. Tenants under ~30 devices typically leave the group empty.
π₯ Group Assignmentsβ
β Included groups:β
β Excluded groups:β
None. Pre-Release is opt-in via group membership.
Standardize like a pro. Configure with intent. And remember: the point of an acceptance ring isn't to test the patch (Microsoft already did that). It's to test the patch against your actual fleet. π¬