Windows 11 26H2 with Intune: Readiness, Enablement Package and Autopatch Deployment Guide

Every year, Windows 11 gets one new "feature update" - a version bump like 24H2 or 25H2 that bundles up a year of new capabilities. The next one is version 26H2, and Microsoft has already published exactly how it plans to ship it and how admins should prepare. This post is a readiness guide, not a deployment guide, because of one fact that matters more than anything else in it: 26H2 is not out yet. Here is what is confirmed, what to do about it now, and why one very common device - Windows 11 version 26H1 - is not going where most admins assume it is.

The problem: three questions every fleet admin has about 26H2

Microsoft announced Windows 11, version 26H2 in a Windows IT Pro Blog post in June 2026, and updated that same post again in August 2026. Once an announcement like that lands, three questions show up in every admin channel and Teams chat within a day, and most of the confusion is avoidable.

Question 1: "Do I need to plan a full reimage project for 26H2?" No. Feature updates in the current Windows 11 servicing model ship as small enablement packages to devices that are already close to the target version. This is the same mechanism Microsoft used to move devices from 22H2 to 23H2, and from 23H2 onward. Nothing about 26H2 changes that.

Question 2: "My fleet is mostly on 26H1 now - are those devices on the path to 26H2?" No, and this is the single most consequential thing in this entire post. Microsoft has stated plainly that devices running Windows 11, version 26H1 cannot update to version 26H2 at all. 26H1 is not a stepping stone toward 26H2 - it is a separate, parallel track built for new hardware, and those devices will get a different future release instead.

Question 3: "Does my current deployment tooling already support this?" Yes. Microsoft names exactly three tools for getting ready: Windows Autopatch, Microsoft Intune, and WSUS. If any of those three already manage your Windows updates, you do not need to stand up anything new - you need to plan rings and validate, which the rest of this post walks through in full.

Why it happens: the shared servicing branch, in plain English

To understand why 26H2 arrives as a small update instead of a big one, it helps to know how Microsoft actually builds Windows 11 releases today. Since Windows 10's 2004-to-20H2 era, Microsoft has used what it calls a shared servicing branch: several version numbers are built from the same underlying source code, receive the same monthly security and quality updates, and go through the same compatibility testing. The version number you see - 24H2, 25H2, 26H2 - mostly describes which features are switched on, not a different codebase underneath.

Here is the mechanism, step by step:

1. Microsoft ships new features to devices continuously, inside the ordinary monthly cumulative update. Most of the time you would never notice, because many of these features arrive turned off by default.
2. Microsoft's own documentation for the Update Policy CSP confirms this directly: features that are turned off by default from monthly servicing "will be enabled in the next annual feature update." The KB article for that month's cumulative update lists which features are currently sitting dormant.
3. When the annual feature update ships, it does not need to install a new operating system. It only needs to flip a switch that turns those already-installed, already-tested features on. That switch-flip is the enablement package - small, quick to install, and far less disruptive than the historic model of a full in-place upgrade.
4. Because the underlying code, security updates, and compatibility validation are already shared across 24H2, 25H2, and the coming 26H2, an eligible device moving between these versions is, in Microsoft's own words, "similar to a regular monthly update" in most environments.

Microsoft used exactly this mechanism to move Windows 11 22H2 devices to 23H2 - its release-health page links directly to that enablement package. 26H2 is the same pattern applied one cycle later.

One more detail worth knowing before you plan anything: support lifecycles reset with every feature update, including 26H2 when it ships. Following the same pattern Microsoft documents for its current versions, expect 24 months of support for Home, Pro, Pro Education, and Pro for Workstations editions, and 36 months for Enterprise, Education, IoT Enterprise, and Enterprise Multi-session editions.

How to verify: where your fleet actually stands today

Before touching any rollout ring, find out where your devices actually sit. Three things matter: the exact version and build a device is running, whether any Windows Update for Business policy already targets or pins that device, and - if you are piloting now - whether the device is enrolled in the Windows Insider Program.

Registry: the version and build that decide everything

Every classification in this post starts from three registry values, all under one key:

Here is a Registry Editor view of that key on a device currently running 25H2:

You can read the same three values from PowerShell, which is what the companion script does across a whole fleet:

Translate that DisplayVersion into a plain answer with this table:

The Windows Update for Business policy mirror

If Intune or Group Policy has already targeted a device with Windows Update for Business settings, Microsoft mirrors the resulting Update CSP values into the registry. This is documented directly in Microsoft's own troubleshooting article for Intune Update rings, under one shared parent key:

Read the same key from PowerShell like this:

Event Viewer and log files: no dedicated Event IDs, but two channels that matter

Microsoft does not publish a dedicated set of Event IDs specifically for feature-update or 26H2 readiness - there is no "26H2 readiness" log source to search. What does exist, and is directly useful here, are two general-purpose channels that show whether a policy actually landed and whether Windows Update itself is behaving:

For deeper troubleshooting, Windows Update also writes trace files that you merge into one readable log with a documented PowerShell cmdlet:

If you are piloting now: Windows Insider Program enrollment

There is no Microsoft-documented registry path for reading raw Windows Insider Program enrollment state - community tools reference an undocumented key, but this post does not build detection logic on something Microsoft has not published. The verified way to check is the Settings UI itself:

1. Open Settings, then go to Windows Update.
2. Select Windows Insider Program.
3. If enrolled, this page shows the linked account and the current channel. If not enrolled, it offers a Get started button instead.

The fix: Microsoft's four-step plan, in full

Microsoft's own preparation guidance for 26H2 has four steps. Here is each one expanded into a full console walkthrough, using the actual tools named in the announcement: Windows Autopatch, Microsoft Intune, and WSUS.

Step 1: Validate today, using the Windows Insider Program

Microsoft's guidance is to preview 26H2 now through the Insider Program's Experimental channel, or wait for the Release Preview channel for closer-to-final quality. Do this on a small number of pilot devices, never on production hardware.

Intune walkthrough - target a pilot device group at a preview channel using an Update ring policy's "Enable pre-release builds" setting:

1. In the Microsoft Intune admin center, go to Devices > Windows > Manage updates > Windows updates.
2. Select the Update rings tab, then Create profile.
3. Under Basics, name the profile something like Pilot - Insider preview channel.
4. Under Update ring settings, turn on Enable pre-release builds and pick a channel. Microsoft's own reference documentation for this setting currently lists three named options: Windows Insider - Release Preview, Beta Channel, and Dev Channel.
5. Continue through Scope tags and Assignments, and assign this profile only to a small pilot device group - never to a production group.
6. Select Review + create, then Create.

The equivalent Group Policy path, if you manage devices without Intune:

1. Open the Group Policy Management Editor and navigate to the path above.
2. Enable Manage preview builds, and set it to Enable preview builds (this maps to the Update/ManagePreviewBuilds CSP).
3. Enable Select when Preview Builds and feature updates are received and choose the desired channel (this maps to Update/BranchReadinessLevel).
4. Link the GPO to an OU containing only pilot devices.

Step 2: Use your existing deployment tools

Microsoft names exactly three tools here. All three already understand feature update rollouts today - none of this requires new infrastructure.

Microsoft Intune - Feature update policies. This is the policy type that pins or targets a specific version, backed by the TargetReleaseVersion and ProductVersion CSPs:

1. In the Microsoft Intune admin center, go to Devices > Windows > Manage updates > Windows updates.
2. Select the Feature updates tab, then Create profile.
3. Give the profile a name, then specify which feature update version devices assigned to it should move to and stay on. Once 26H2 is published, it appears here as a selectable target once it exists in the service.
4. Assign the profile to a device group - start with the same pilot group used in Step 1.
5. Review and create the profile.

Windows Autopatch - deployment rings. If your fleet is Autopatch-managed, the existing ring structure already carries feature updates - you don't build a parallel process:

1. In the Microsoft Intune admin center, select Tenant administration, then under Windows Autopatch, select Autopatch groups.
2. Open an existing Autopatch group, or select Create for a new one, and step through to Update types.
3. Make sure Feature updates is one of the selected update types for this group.
4. On the Deployment settings page, use the dropdown to set the target version for feature updates. This is the exact setting that will offer 26H2 once Microsoft makes it available through Autopatch.
5. On Release schedules, review the deferral and deadline spacing already assigned across your existing deployment rings (for example Test, First, Fast, and Broad) - this is the ring structure that automatically staggers the 26H2 rollout once you set the target version above.
6. Save the group. Autopatch's device-based Microsoft Entra groups for each ring do the rest.

WSUS. Feature updates are published to WSUS under the Upgrades classification. Once Microsoft ships 26H2, it appears in WSUS as a new entry once your existing Windows 11 product category is enabled - there is no separate "26H2 product" to hunt for ahead of time, because the product entry is "Windows 11," not one row per version:

1. Open the WSUS Administration Console and go to Options > Products and Classifications.
2. On the Products tab, confirm Windows 11 is checked (it's listed under All Products > Microsoft > Windows).
3. On the Classifications tab, confirm Upgrades is checked - Microsoft's own documentation confirms feature updates are published under this classification, and leaving it unchecked is the most common reason feature updates never appear in a WSUS console at all.
4. Synchronize the server. Once 26H2 exists as a published update, it appears automatically under this same configuration - nothing further to change ahead of time.
5. To auto-approve it for a pilot ring once it appears, go to Options > Automatic Approvals, create a rule scoped to the Upgrades classification, the Windows 11 product, and your pilot computer group, with a short approval deadline.
6. To approve it manually instead, go to Updates, create a new update view scoped to Upgrades and Windows 11, then approve the specific update for the ring you want first.

Step 3: Plan your rollout rings

Whichever tool you use, the underlying idea is identical: a small pilot group first, then wider rings based on what the pilot tells you. Microsoft's own Windows Update for Business documentation gives a concrete worked example using three rings with staggered deferral periods - pilot at 0 days, a fast ring at 1 day, and a slow ring at 2 days for quality updates, which is the same pattern Windows Autopatch uses by default for its own rings.

Step 4: Stay current on monthly updates

Because features ship dormant inside ordinary monthly cumulative updates and only switch on at the enablement package moment, a device that has fallen behind on monthly updates is missing the exact code that 26H2 needs to flip on. Staying current isn't a separate task from getting ready for 26H2 - it is the preparation.

Proof it worked: a real readiness report

The companion script for this post, Get-Windows26H2ReadinessReport.ps1, is read-only. It checks the current version and build against the classification table above, checks the Windows Update for Business policy mirror, and reports whether the raw Windows Insider enrollment check was skipped and why. Here is a genuine run, on a real Windows 11 device, with the hostname replaced:

This is a genuine run against a real corporate laptop, with the device name replaced and the last four digits of the build revision redacted. The result lines up exactly with the independently verified release-health data used throughout this post: this device is on 25H2, build 26200.9168, which is current as of the August 2026 cumulative update.

The same script also produces a CSV row when run with -ExportCsv, for fleet-wide reporting:

Two things are worth pointing out about this run. First, notice the empty PolicyValuesFound entries from the gotcha earlier in this post never appear here - the fixed version of the script only reports a policy as "set" when it actually has a non-empty value, which is exactly the kind of real bug that only shows up by running a script against a real device instead of trusting the documentation alone. Second, this device passed with exit code 0 precisely because it is on 25H2 with no overriding policy - a device on 26H1, or one with a stale TargetReleaseVersion pin, would exit with code 2 (informational) instead, and a genuinely failed registry read aborts loudly with exit code 1 rather than printing a false-clean summary.

References

• Microsoft Learn — Windows 11 - release information
• Windows IT Pro Blog — Get ready for Windows 11, version 26H2
• Microsoft Learn — Configure Windows Update client policies by using CSPs and MDM
• Microsoft Learn — Update Policy CSP
• Microsoft Learn — Update Rings Policy Settings for Microsoft Intune
• Microsoft Learn — Manage Windows Update Ring Policies for Microsoft Intune
• Microsoft Learn — Manage Windows Feature Updates for Microsoft Intune
• Microsoft Learn — Manage Windows Autopatch groups
• Microsoft Learn — Troubleshoot Update ring policies for Windows devices
• Microsoft Learn — Deploy updates using Windows Server Update Services
• Microsoft Learn — Assign devices to servicing channels for updates
• Microsoft Learn — Windows Update log files