Microsoft has confirmed the next annual feature update, Windows 11, version 26H2, and the headline for IT is a familiar one: this is an enablement package (eKB), not a full OS swap. If you have been through the 24H2 to 25H2 cycle, the playbook is almost identical – but there are a couple of new wrinkles worth planning around. This post walks through the supported upgrade paths, how you drive it with Windows Autopatch and Intune, and how to actually track the rollout from pilot to production.

What 26H2 actually is

26H2 shares the same servicing branch as 24H2 and 25H2. That means for devices already on those versions, the upgrade is delivered as a tiny enablement package – around 174 KB – that simply flips the version and build number (build 26300) after a single restart. No multi-gigabyte download, no long offline phase, no feature-update reboot marathon. The new capabilities ship continuously through monthly cumulative updates and are switched on by the eKB.

Microsoft frames it as “a predictable, low-disruption update experience for organizations and IT professionals,” and from a deployment standpoint that is exactly what it is – an update ring approval rather than a migration project. Expect general availability in the fall of 2026, in line with previous H2 releases.

Upgrade paths – know your starting point

The delivery method depends entirely on the version a device is sitting on today:

• Windows 11 24H2 / 25H2 – direct eKB upgrade. ~174 KB, one restart. This is the easy 95% for most managed fleets.
• Windows 11 23H2 and older – different servicing branch, so no eKB. These need the full feature-update media path (~6.5 GB download and the full upgrade experience).
• The 26H1 caveat – 26H1 sits on a separate Windows core branch and does not roll forward to 26H2 via the standard enablement path. If you have any 26H1 (specialized/insider) devices, plan a different route for them.
• Windows 10 – no shortcut here. These are full upgrades (or, frankly, replacements) and should already be on your end-of-support migration plan.

Action before fall: run an inventory split by OS version now. Anything not already on 24H2/25H2 is your long-tail – get those onto a current branch first so 26H2 becomes a one-restart eKB rather than a 6.5 GB project.

Driving it with Windows Autopatch

If you are on Autopatch, 26H2 is close to trivial to approve – it appears in the feature update flow like any other release, and because the payload is tiny, distribution can complete in a day rather than weeks.

The mechanics you already rely on still apply. Autopatch groups split your estate into deployment rings – Test, First, Fast, and Last. If you do not define extra rings, Test acts as your pilot and Last as production. Releases flow sequentially through the rings, and Autopatch monitors device telemetry the whole way – if failure or compatibility signals spike, it can automatically pause progression to the next ring.

• Pilot: keep Test/First small but representative – mix hardware models, key line-of-business apps, and a few power users who will actually report friction.
• Soak time: because the eKB is so small, the temptation is to rush. Resist it – the value of a pilot is the soak window, not the download time. Give each ring a real bake period to surface app and driver issues.
• Safety net: you retain Pause, Resume, and Rollback for feature updates directly from Intune if a ring goes sideways.

Not on Autopatch? The same model is available with Intune Feature Update profiles plus Update Rings – you target 26H2 as the feature update version and stagger deferrals/rings manually. You lose the automatic ring progression and telemetry-driven pause, but the staged approach is the same.

Tracking pilot to production

This is where most rollouts get loose. “We deployed it” is not the same as “we can prove the estate moved.” Here is the reporting stack I lean on:

1. Reports > Windows Autopatch – the two Autopatch reports give you ring-level rollout status and quality/feature update health. This is your primary “where is each ring” view.
2. Reports > Device management > Windows Updates – the feature update report and readiness reporting validate which devices are eligible and which are blocked, before and during the push.
3. Email notifications – make sure your Autopatch admin contacts are current so you actually receive the proactive alerts rather than discovering issues in a dashboard.
4. A simple version-count KQL/report – track devices reporting build 26300 over time as your single “percentage on 26H2” number for management. Watch the curve per ring, not just the total.

Define your exit criteria before you start: e.g. pilot ring at >95% success with zero unresolved Sev-1 app issues for X days before releasing the next ring. Let the telemetry and your soak window – not the trivial download size – gate each promotion.

Support lifecycle

The usual split applies: Enterprise, Education, IoT Enterprise and Enterprise multi-session get 36 months of support, while Home, Pro, Pro Education and Pro for Workstations get 24 months (support running to roughly October 2028). Factor that into whether 26H2 is a “move now” or a “this fall” decision for each ring.

A short pre-flight checklist

• Inventory by OS version – identify anything not on 24H2/25H2.
• Get the long-tail (23H2 and older, Windows 10) onto a current branch first.
• Flag any 26H1 devices for a separate path.
• Confirm Autopatch groups / Intune feature update profiles and rings are sane.
• Verify Autopatch admin contacts and reporting access.
• Write down your per-ring exit criteria and soak windows.

Further reading and references

• Get ready for Windows 11, version 26H2 – the official Windows IT Pro Blog announcement (the canonical source).
• Windows Autopatch groups overview – Microsoft Learn, deployment rings and group model.
• Manage Windows Update ring policies in Intune – Microsoft Learn.
• Windows 11 release information – Microsoft Learn, build and servicing reference.
• Microsoft says Windows 11 26H2 is coming soon – BleepingComputer, upgrade-process summary.
• Microsoft urges IT admins to prepare for 26H2 – Petri.

Bottom line: 26H2 is an approval, not a migration – for the devices that are on a current branch. Spend your effort on the long-tail and on a disciplined pilot-to-production cadence, and the eKB itself will be the least interesting part of the project.