Windows 11 26H2 Is Now in Release Preview: How to Test and Prepare Your Intune Environment Before GA

On 27 August 2026, Microsoft moved Windows 11, version 26H2 into the Release Preview channel as build 26300.9278. That sounds like routine Insider chatter, but it is not. Every previous milestone for 26H2 - the Dev and Beta channel builds, the earlier Insider flights - was aimed at enthusiasts testing pre-release code on throwaway hardware. Release Preview is different: it is the channel Microsoft explicitly tells commercial customers to use for validating a build before it becomes generally available. The Windows Insider blog post announcing this says as much: organizations can now deploy 26H2 through Windows Update client policies or WSUS and validate it against their own environment ahead of GA.

That is a real change in what "prepare for 26H2" means this week. Until yesterday, an IT admin's options were either wait, or run 26H2 on a handful of Insider-enrolled test devices with no formal support path. From now until general availability - expected later in 2026 - there is a supported, low-effort way to run 26H2 against your real Intune policies, your real Defender baseline, and your real Autopilot profiles, before a single production device touches it. This post is that pilot plan.

The problem: Release Preview changes the calculus, and the seeker experience can act before you decide

Here is the specific situation as of 27 August 2026. Windows 11 26H2 build 26300.9278 (KB5120998) is live in the Release Preview channel. For devices already on 24H2 or 25H2, it installs as an enablement package: roughly 174 KB, one restart, no new files to copy down because the 26H2 code has already been sitting dormant inside your monthly cumulative updates for months. Microsoft's own framing is that this unlocks features that were already present but switched off for commercial devices - Windows Settings Backup, app-specific taskbar actions, and a set of File Explorer changes - rather than introducing a new codebase to test from scratch.

The part that catches admins out is the Release Preview channel's seeker experience. Any device enrolled in Release Preview that meets Windows 11 hardware requirements will now offer 26H2 through Windows Update of its own accord, the same way it offers a monthly cumulative update - it does not wait for you to request it. If you have Insider-enrolled devices in your estate (test VMs, a lab, a pilot group left over from an earlier Autopilot proof-of-concept) and you have not explicitly pinned their target feature-update version, some of them may already be sitting on 26H2 without anyone deciding that on purpose.

Why it happens: the 24H2/25H2/26H2 shared servicing branch and the enablement package

The reason a feature update can arrive this small and this fast is the shared servicing branch. Microsoft's own whitepaper on the shared servicing model lays out the mechanism: 24H2 (build 26100), 25H2 (build 26200) and 26H2 (build 26300) are all developed from the same underlying branch. Rather than building three separate operating systems, Microsoft ships one shared code line and layers version-specific feature flags on top of it. A device running 24H2 or 25H2 already has almost everything 26H2 needs sitting inertly in its own installed binaries - delivered to it over the preceding months as ordinary cumulative updates. The eKB's only job is to flip those flags on and update the reported build number.

This is exactly why Release Preview validation is realistic to do properly in days, not weeks. You are not testing a new kernel, a new driver model, or a new update engine - you are testing whether a specific set of features your organization has never had turned on before behaves correctly against your existing Intune policies, your existing Defender configuration, and your existing app estate. The risk surface is narrow and known. That is also why Microsoft is comfortable inviting commercial validation this early: the underlying OS has already been running in production, unchanged, for months.

How to verify: read your fleet's current feature-update posture before you pilot anything

Before you configure a single pilot ring, confirm three things: what build your devices are actually on, whether any policy is already pinning (or failing to pin) a target version, and whether the Windows Update client has logged any feature-update activity you did not expect. All three are readable with tools you already have.

If that last command shows KB5120998 already installed on a device you did not enroll in a pilot, stop and treat it as a finding, not a formality - it means the seeker experience got there before your policy did.

The registry key and the event log above are the two surfaces worth knowing in full, not just the one value or one event ID that happens to answer today's question.

The fix: build the Release Preview pilot, ring by ring

This is the plan itself, in the order the user's own outline calls for: build the pilot ring, validate Intune policies and apps, validate Defender and the security baseline, validate Autopilot provisioning, understand your rollback window, then run the production readiness checklist before you widen anything.

Step 1 - Create the enterprise pilot ring

Two different settings are in play here, and conflating them is the most common mistake in a 26H2 pilot. Getting a device onto the Release Preview build itself is controlled by the branch-readiness setting (BranchReadinessLevel) - available in both Intune and Group Policy. Protecting your broad fleet from drifting onto 26H2 by accident is a separate setting (TargetReleaseVersion) - also available in both. Once 26H2 itself reaches general availability, there is a third, newer mechanism - Intune's dedicated Feature update policy - which is cloud-orchestrated and has no Group Policy equivalent at all.

Via Intune (Settings Catalog / Update rings):

1. Sign in to the Intune admin center.
2. Go to Devices › Windows › Update rings and select Create profile.
3. Name it clearly, e.g. "26H2 Release Preview Pilot" - do not reuse an existing broad ring for this.
4. Under Update settings, set Feature update deferral period (days) to 0 for this pilot ring only (you want it to take what the branch setting below offers, not defer it further).
5. Set Enable pre-release builds to Yes and choose Windows Insider Program - Release Preview as the branch.
6. Under Assignments, assign this ring to a small, deliberately chosen device group - ideally 5-20 devices covering your most common hardware and application profiles, not a random sample.
7. Leave your existing broad rings on their current deferral and target version unchanged. They are your control group.

Via Group Policy (for hybrid-joined or on-prem-managed devices):

1. Open gpmc.msc and right-click the pilot device OU.
2. Select Create a GPO in this domain, and Link it here... and name it to match your Intune pilot ring.
3. Edit the GPO and navigate to Computer Configuration › Administrative Templates › Windows Components › Windows Update › Windows Update for Business.
4. Enable Select when Preview Builds and Feature Updates are received and set the branch readiness level to Windows Insider Program - Release Preview. This is the setting that actually pulls 26H2 onto the pilot OU - link this GPO to the pilot OU only.
5. On a separate GPO linked to your broad/control-group OUs (not the pilot OU), enable Select the target Feature Update version, set Product version to "Windows 11" and Target Version to your current GA version (e.g. "25H2"). This is what stops the broad fleet from drifting onto 26H2 while your pilot runs - it is a fleet-protection setting, not part of building the pilot itself.

When 26H2 reaches general availability, replace the pre-release branch pin with the dedicated policy built for this: Devices › Windows › Windows updates › Feature updates › Create profile. Pick 26H2 from the Feature update to deploy dropdown, assign it to the same pilot group, and wait for the devices to report OfferReady in the Feature Updates (Organizational) report before you turn the pre-release branch setting off. This policy is cloud-orchestrated through the Windows Update for Business deployment service - it has no Group Policy equivalent, and unlike BranchReadinessLevel it writes nothing you can read back from the local registry; the report is the only place to confirm it landed.

Step 2 - Validate Intune policies and applications on 26H2

1. Confirm the pilot devices show Compliant in Devices › Monitor › Compliance after the upgrade completes - a device that silently drops to Not evaluated is a stronger signal of a real regression than one that fails outright.
2. Re-run every Settings Catalog and Administrative Template profile assigned to the pilot group through Devices › Configuration › Monitor › Device status and confirm each still reports Succeeded, not just that it was applied historically.
3. Check every Win32, Store and LOB app assigned to the pilot group under Apps › Monitor › App install status - a taskbar or Explorer-shell change can occasionally break an app's silent-install detection logic without breaking the app itself.
4. If your organization uses Windows Autopatch, move the pilot device group into Autopatch's Test ring rather than running a parallel manual pilot - Autopatch already tracks version progression, soak periods, and rollback per its own deployment-ring model, and duplicating that with a second manual ring just creates two sources of truth for the same devices.

Step 3 - Defender and security baseline testing

1. Confirm the pilot group's assigned Security baseline profile (whether the MDM Security Baseline or the Microsoft Defender for Endpoint baseline) still reports each setting as applied under Endpoint security › Security baselines › [baseline name] › Monitor after the upgrade, not just before.
2. Run a full Defender scan and confirm Real-Time Protection, Cloud-delivered protection, and Tamper Protection status all still show Enabled in Endpoint security › Antivirus for the pilot devices.
3. Deliberately exercise the specific behaviors your ASR rules police - e.g. Office child-process creation, script execution from email - on a pilot device and confirm the same rules still fire the same way they did pre-upgrade. Do this on a test device, never a device with real user data.
4. If you customize Windows Firewall or BitLocker settings via a security baseline, confirm both remain in their expected state; Settings Backup being newly enabled by 26H2 for commercial devices is exactly the kind of setting that can interact unexpectedly with a locked-down BitLocker or firewall configuration profile.

Step 4 - Autopilot provisioning testing

If any part of your fleet is provisioned through Windows Autopilot, run at least one full provisioning pass against 26H2 before you widen the ring - the Enrollment Status Page is one of the more sensitive surfaces to a feature-flag change, since it gates the desktop behind a strict app/policy/certificate completion check.

1. Take one spare or wiped device already registered in your Autopilot deployment profile - do not repurpose a live pilot user's machine for this.
2. Confirm the device's assigned Enrollment Status Page profile under Devices › Enrollment › Enrollment Status Page targets the same pilot device group as your 26H2 update ring, so the OOBE pass genuinely lands on 26H2, not on whatever the broad deployment profile still targets.
3. Run the device through Autopilot end to end and confirm the ESP completes within its configured timeout (60 minutes is the default) with every tracked app, policy, and certificate showing as installed - not just that ESP eventually let the user through.
4. Confirm the device correctly registers as compliant and shows the expected OS version in Intune within a normal sync interval afterward.

Step 5 - Update and rollback considerations

Every eKB-based feature update carries the same rollback mechanics as a full feature update: a default 10-day window during which the device can be reverted via Settings › System › Recovery › Go back, backed by the same rollback files Windows keeps after any feature update. Know this window before you need it, not after.

1. On every pilot device, extend the rollback window to 30 days with DISM /Online /Set-OSUninstallWindow /Value:30 immediately after the upgrade completes, before Windows.old and the rollback files have any chance of being cleaned up by disk-space pressure or a well-meaning cleanup script.
2. Document the exact date each pilot device took the eKB, so you know precisely when the rollback window closes for that device.
3. Treat "Go back" as the pilot's actual exit-criteria backstop: if a pilot device shows a real regression you cannot fix quickly, roll it back and capture logs before you troubleshoot further, rather than leaving it broken while you investigate.

Step 6 - Production readiness checklist

Do not widen the ring past the pilot group until every row below is genuinely green, not "green enough."

Proof it worked: what a clean pilot looks like before you widen the ring

Illustrative example of a pilot device that has cleared every gate above - reconstructed here rather than pulled from a live tenant, since a real capture would carry this organization's own device names and group tags:

A device in that state - pinned intentionally, compliant, fully applied baseline, apps intact, rollback window deliberately extended - is what "ready to widen the ring" actually looks like. Widening from there means moving the same pilot device group's ring assignment to your next-widest ring (or, if you use Autopatch, promoting the group from Test to First) and repeating this same checklist against that larger group before you move again.

References

• Releasing Windows 11, version 26H2 to the Release Preview Channel — Windows Insider Blog, 27 August 2026
• Manage Windows feature updates in Microsoft Intune — Microsoft Learn
• Configure Windows feature update policies — Microsoft Learn
• Update ring policy settings reference — Microsoft Learn
• Configure Windows Update client policies by using CSPs and MDM — Microsoft Learn
• Learn about Intune security baselines for Windows devices — Microsoft Learn
• Windows Autopilot Enrollment Status Page — Microsoft Learn
• DISM operating system uninstall command-line options — Microsoft Learn

Microsoft MVP community deep-dives