Windows 11 25H2 and annual servicing explained

Every autumn, Microsoft ships an annual Windows 11 feature update, and every autumn a share of IT departments treats it like an OS migration — pilots, imaging conversations, a spreadsheet with a thousand rows. That instinct is a decade out of date. The way Windows servicing works now, the annual update — 25H2 being the current one — is closer to a large monthly patch than to an upgrade, and the real management question is not "how do we deploy it?" but "which lifecycle clock are we on, and is our update policy set up so this happens on its own?"

Here's the model, and how to run it in a Microsoft 365 shop.

The shared servicing branch

The technical fact that changes everything: Windows 11 24H2 and 25H2 run the same codebase — the same servicing branch, receiving the same monthly cumulative updates. Microsoft develops new features once, ships them to both versions inside the monthly updates in a disabled state, and "releasing 25H2" largely means flipping those features on.

For a device already on 24H2, the 25H2 update is delivered as an enablement package — a small activation switch, installed like a monthly update, with a single restart. Minutes, not hours. No reinstall, no driver roulette, minimal compatibility delta, because the binaries were already on the machine and had been running for months. (Devices coming from 23H2 or earlier take a full feature update swap, since they're crossing onto a new branch.)

If you remember the Windows 10 era's 1809-style upgrade traumas: that's the thing this architecture was built to end. The compatibility risk now arrives gradually through monthly updates all year; the annual release mostly renames what you already have.

The clocks: why 25H2 still matters

If the enablement package changes so little, why care? Because the support lifecycle is tied to the version label:

• Enterprise and Education editions: 36 months of servicing from each annual release.
• Pro (and Home): 24 months.

When a version leaves support, it stops getting security updates — that's the deadline that matters. The version label on a device is really a timestamp on its security-update entitlement, and the annual update is how you wind the clock. An Enterprise fleet can legitimately skip a version (36 months spans three releases); a Pro fleet is on a tighter cadence and should take every one, or every other at most.

The adjacent clock everyone already heard: Windows 10 reached end of support in October 2025. Extended Security Updates exist as a paid bridge (up to three years for organisations), but ESU is a fee for standing still. If parts of the estate are still on Windows 10 with ESU, the money conversation is "what's blocking Windows 11 hardware eligibility," not "which Windows 11 version."

How to run the annual update

For an Intune-managed Microsoft 365 organisation, the machinery is Windows Update for Business — policies that tell devices what to install and when, with Microsoft's infrastructure doing the delivery. The pieces:

• Update rings control monthly quality updates and deferrals: a pilot ring (IT plus volunteers, no deferral), a broad ring (a week's deferral), and a conservative ring for genuinely fragile contexts. See Microsoft Intune and device management for where this sits in the Intune stack.
• Feature update policies pin devices to a named version — "move to Windows 11 25H2" — and can schedule a gradual rollout between two dates. This is the annual-update control: update the target version in the policy, phase by ring, done.
• Safeguard holds are Microsoft pausing the offer to devices with a known incompatibility (a driver, an app). Respect them — they're doing telemetry-informed piloting for you — and check the Windows release health dashboard when a cohort seems stuck.
• Windows Update for Business reports (or Intune's built-in reporting) show per-device version and update status, which is what your compliance dashboard should actually watch.

Two decisions worth making deliberately:

1. Deadline-driven, not consent-driven. Set feature-update deadlines with a grace period (a common shape: 7-day deadline, 2-day grace after that) so updates install without users being able to postpone forever. Goodwill-based patching produces the long tail that gets exploited.
2. Take the annual update within a few months of release, even on Enterprise's 36-month clock. Since 25H2 is an enablement package over 24H2, deferring buys almost no risk reduction while shortening your runway. Skip-a-version strategies made sense when feature updates were disruptive; with shared servicing branches, the update is cheap and currency is free hardening.

If you'd rather not own even this much machinery, Windows Autopatch (included with Windows 10/11 Enterprise E3 and up, hence most Microsoft 365 E3/E5 tenants) runs the rings, the rollout phasing, and the pause/rollback decisions as a service. For organisations without a dedicated client-engineering function it's the honest default. The classic on-prem route — Configuration Manager and WSUS — still works, but WSUS is deprecated for new investment and the direction of travel is unambiguously cloud-delivered updates; the co-management guide covers living in between.

What's actually in 25H2

Deliberately last, because it's the least operationally important part. Beyond the accumulated AI-and-quality features that shipped through the year (heavily weighted toward Copilot+ hardware), 25H2's notable admin-relevant changes are removals: PowerShell 2.0 and the WMIC command-line tool are gone. If you have login scripts, monitoring agents, or installers from the late 2000s, this is your compatibility testing surface — grep the estate for wmic before the broad ring, and be glad it's the worst of it.

There's also a new Enterprise/Education policy to remove selected preinstalled Microsoft Store apps — small, but a sign Microsoft is finally giving admins supported answers to debloating.

26H2 outlook

The model above is about to get its third consecutive proof. Microsoft confirmed in mid-2026 that Windows 11 26H2 will also ship as an enablement package, on the same servicing branch that 24H2 and 25H2 already share, and released it to the Release Preview Channel on 27 August 2026 (build 26300.9278). General availability is expected in the autumn, per the usual cadence — Microsoft hasn't committed to a date at time of writing.

What that means in practice is exactly what this guide predicts:

• From 24H2 or 25H2: the 26H2 update is a tiny enablement package and a single restart. The features have been arriving disabled through the monthly cumulative updates all year.
• From 23H2 or earlier: a full feature-update swap onto the current branch — the multi-gigabyte kind. If part of the estate is still there, that's the cohort to plan for; everyone else gets an afternoon.
• The clocks reset as usual: installing 26H2 starts a fresh 36-month servicing window for Enterprise/Education and 24 months for Pro.

Operationally, nothing changes in your machinery: when 26H2 reaches general availability, update the target version in the feature-update policy (or let Autopatch do it), phase by ring, and check the reporting. If you set the model up for 25H2, 26H2 is the year you find out it was worth it.

The bottom line

Treat Windows servicing as a policy you configure once and an annual afternoon, not an annual project: rings with deadlines, a feature-update policy pointed at the current version, safeguard holds respected, Autopatch if you'd rather delegate the whole thing. The organisations that struggle with Windows updates in 2026 are almost never struggling with Windows — they're struggling with an operating model that still assumes every version is a migration.