Why Release Preview Is the Wrong Time to Start Planning

Most organizations treat Release Preview as a signal to begin awareness. It should be the signal to finalize decisions.

By the time a build reaches Release Preview, Microsoft has completed its internal validation cycle. The build is functionally complete. What changes between Release Preview and General Availability is primarily documentation, localization polish, and last-mile telemetry corrections — not core behavior. If you're waiting for GA to start ring design, you've lost six to eight weeks of structured testing time.

The implication for regulated industries is sharper. If your organization operates under SOC 2, HIPAA, PCI-DSS, or FedRAMP, your change management policy likely requires a defined testing window before production deployment. That window needs to start now, against the Release Preview build, not against the GA build after it lands in Windows Update for Business.

---

What 26H2 Actually Changes at the Architecture Level

Before you can design a ring strategy, you need to understand what you're testing. Generic "compatibility testing" is not a plan.

26H2 introduces changes in four areas that matter to enterprise security and compliance teams:

Kernel Integrity and Virtualization-Based Security (VBS): 26H2 expands the default enforcement scope of VBS on eligible hardware. Devices that previously ran with VBS in audit mode may shift to enforced mode post-upgrade. This directly affects endpoint detection rules, memory integrity attestation in Conditional Access, and any third-party security tooling that operates at the kernel level.

Security Baseline Delta: Microsoft's Security Compliance Toolkit baseline for 26H2 introduces policy changes across Credential Guard configuration, LSASS protection, and SMB signing enforcement. If your current Intune configuration profiles are pinned to the 23H2 baseline, you will have drift the moment 26H2 deploys — and that drift may not surface in compliance reporting until the next evaluation cycle.

Application Compatibility Surface: The Windows App SDK and WebView2 runtime versions bundled with 26H2 differ from 23H2. Line-of-business applications that embed WebView2 or depend on specific Win32 API behaviors in the graphics or audio subsystems need explicit validation, not assumption-based sign-off.

Defender Platform Integration: 26H2 ships with updated Defender platform binaries that change the timing and scope of certain scan behaviors. Organizations running custom detection rules in Defender for Endpoint need to validate that existing custom indicators and detection logic behave consistently post-upgrade.

None of these are theoretical risks. Each one maps to a specific failure mode that your ring strategy needs to catch before it reaches production.

---

The Default Microsoft Cadence Is Not Your Cadence

Microsoft's default Windows Update for Business configuration will begin moving devices toward 26H2 according to Microsoft's internal release schedule. That schedule is optimized for broad compatibility and consumer deployment velocity — not for enterprise change control, security validation cycles, or regulatory audit timelines.

If you have not explicitly configured deferral policies in Intune, your devices are subject to Microsoft's default servicing timeline. For organizations with formal change advisory boards, quarterly release windows, or compliance-mandated testing periods, that default behavior is a governance risk.

The mechanism to control this is Windows Update for Business deferral policies, applied through Intune's Update Rings for Windows 10 and later. The critical parameters are:

• Feature update deferral period: The number of days after Microsoft's release date before the update is offered to devices in that ring.
• Deadline and grace period: The maximum number of days a user can defer an offered update before it installs automatically.
• Pause state: A temporary hold that can be applied to stop update delivery while an issue is investigated.

What most organizations get wrong is treating deferral as a binary — either deferred or not. A mature ring strategy uses graduated deferrals across population segments, with explicit validation gates between each ring.

---

Designing a Ring Architecture That Survives an Audit

A ring strategy that can't be explained to an auditor isn't a strategy — it's a hope. The following architecture is designed for organizations with formal change control requirements.

Ring 0 — Insider/Canary (IT-owned devices, voluntary): These devices run Release Preview builds. They exist to surface breaking changes before GA. Population: 10–25 devices, all IT-owned, no production workloads. Deferral: 0 days. This ring should already be running 26H2 Release Preview builds today.

Ring 1 — Early Adopters (IT staff and willing power users): These devices receive the GA build with a 0-day deferral. Population: 50–150 devices. Validation period: 14 days minimum before Ring 2 advancement. This ring generates the telemetry and support ticket data that informs Ring 2 readiness.

Ring 2 — Pilot Production (representative business units): Deferral: 14–21 days post-GA. Population: a small, representative slice of the total managed estate, selected to represent application diversity, hardware diversity, and geographic distribution. Validation gate: formal sign-off from application owners and security team before Ring 3 advancement.

Ring 3 — Broad Production: Deferral: 45–60 days post-GA. This is the majority of your managed estate. Advancement from Ring 2 to Ring 3 should require documented approval in your change management system.

Ring 4 — Sensitive/Regulated Workloads: Deferral: 90 days post-GA. This ring covers devices in regulated environments — clinical workstations, financial trading systems, manufacturing control interfaces, or any device subject to a specific compliance framework that mandates extended validation. Maximum deferral under Windows Update for Business is 365 days for feature updates.

---

Querying Your Current Ring State in Intune and Defender

Before you can adjust your ring strategy, you need to know where your devices actually are. The following queries give you ground truth.

KQL — Identify devices not yet assigned to an Update Ring in Intune (via Microsoft Defender for Endpoint advanced hunting):

// Devices reporting to MDE that have no Intune Update Ring assignment
// Cross-reference DeviceInfo with known ring tag values
DeviceInfo
| where OnboardingStatus == "Onboarded"
| where isempty(MachineGroup) or MachineGroup !in ("Ring0", "Ring1", "Ring2", "Ring3", "Ring4")
| project DeviceName, OSVersion, MachineGroup, LastSeen
| order by LastSeen desc

KQL — Surface devices still running 23H2 or earlier that are in Ring 3 or Ring 4 (potential deferral policy gap):

DeviceInfo
| where OnboardingStatus == "Onboarded"
| where OSVersionInfo contains "22H2" or OSVersionInfo contains "23H2"
| where MachineGroup in ("Ring3", "Ring4")
| summarize DeviceCount = count() by OSVersionInfo, MachineGroup
| order by DeviceCount desc

PowerShell — Export current Intune Update Ring deferral settings via Microsoft Graph (requires DeviceManagementConfiguration.Read.All):

$rings = Get-MgBetaDeviceManagementDeviceConfiguration `
    -Filter "isof('microsoft.graph.windowsUpdateForBusinessConfiguration')" `
    -ExpandProperty assignments

foreach ($ring in $rings) {
    $settings = $ring.AdditionalProperties
    [PSCustomObject]@{
        RingName                    = $ring.DisplayName
        FeatureDeferralDays         = $settings['featureUpdatesDeferralPeriodInDays']
        QualityDeferralDays         = $settings['qualityUpdatesDeferralPeriodInDays']
        DeadlineDays                = $settings['featureUpdatesWillBeRolledBack']
        AutomaticUpdateMode         = $settings['automaticUpdateMode']
        AssignmentCount             = $ring.Assignments.Count
    }
}

PowerShell — Check local device's current Windows Update for Business deferral configuration (run on managed endpoint):

$wufbPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"

$deferralConfig = [PSCustomObject]@{
    DeferFeatureUpdates         = (Get-ItemProperty -Path $wufbPath -ErrorAction SilentlyContinue).DeferFeatureUpdates
    DeferFeatureUpdatesPeriodInDays = (Get-ItemProperty -Path $wufbPath -ErrorAction SilentlyContinue).DeferFeatureUpdatesPeriodInDays
    DeferQualityUpdates         = (Get-ItemProperty -Path $wufbPath -ErrorAction SilentlyContinue).DeferQualityUpdates
    DeferQualityUpdatesPeriodInDays = (Get-ItemProperty -Path $wufbPath -ErrorAction SilentlyContinue).DeferQualityUpdatesPeriodInDays
    PauseFeatureUpdatesStartTime = (Get-ItemProperty -Path $wufbPath -ErrorAction SilentlyContinue).PauseFeatureUpdatesStartTime
}

$deferralConfig | Format-List

These queries are not one-time diagnostics. Build them into a recurring operational review — monthly at minimum, weekly during active ring advancement windows.

---

Governance Considerations for Regulated Environments

If your organization operates in a regulated industry, 26H2 adoption is a compliance event, not just an IT event. That distinction changes who needs to be involved and what documentation is required.

Change Advisory Board integration: Feature update deployments that affect kernel behavior, security baseline configuration, or authentication stack components should be submitted as standard changes — not emergency changes, and not informal deployments. The 26H2 changes to VBS enforcement scope and LSASS protection qualify under most CAB definitions of a significant system change.

Evidence collection for audit: Your ring advancement gates need to produce artifacts. A Defender for Endpoint report showing zero critical detections over a 14-day Ring 1 observation window is an audit artifact. A Teams message saying "Ring 1 looks fine, let's move to Ring 2" is not. Define what evidence each gate requires before you start advancing rings.

Deferral documentation: If your compliance framework requires you to demonstrate that security updates were applied within a defined window, your 90-day Ring 4 deferral needs to be documented as an approved exception, not an undocumented configuration. The deferral is legitimate — but only if it's intentional and recorded.

Rollback planning: Windows 11 feature updates support a rollback window of 10 days post-installation by default. That window can be extended via policy, but it cannot be extended indefinitely. If your change control process requires a 30-day rollback capability, you need to address that gap explicitly — either through imaging, cloud PC snapshots in Azure Virtual Desktop, or an alternative recovery approach.

---

Operational Readiness Before Ring Advancement

Ring advancement decisions should be data-driven. The following signals should be evaluated before moving any ring forward.

Application compatibility telemetry: Intune's feature update compatibility reports surface known application compatibility issues before deployment. These reports pull from Microsoft's compatibility database and your own inventory. Review them against your Ring 2 device population before advancing.

Support ticket volume: A spike in support tickets from Ring 1 devices in the 72 hours post-upgrade is a hard stop signal. Define your threshold before deployment begins — not after.

Defender health state: Devices that complete a feature update and then show degraded Defender sensor health or missing heartbeat in MDE are a security gap, not just an operational issue. Build a post-upgrade Defender health check into your Ring 1 validation process.

Compliance policy re-evaluation: After a feature update, Intune compliance policies re-evaluate on the next check-in cycle. Devices that were compliant before the update may temporarily show as non-compliant if the update changes a setting that a compliance policy evaluates. Monitor your compliance dashboard for anomalous non-compliance spikes in the 24–48 hours after Ring 1 and Ring 2 deployments.

---