Posted in

26H2 is GA now: two policies decide your week

by ailona•

Windows 11 26H2 is generally available as of September 29, and for most fleets it arrives like a monthly update: a small download, one restart, no reimaging. The install is not the decision. Two policy-level controls are: the switch that turns on every dormant feature at once, and the setting that can break an elevation workflow you already depend on. Your feature update policy and update ring deferrals are plumbing rather than choices.

What actually shipped

The release is build 26300.9550, and on eligible 24H2 and 25H2 devices it lands as KB5121794, the enablement package. Microsoft calls it a master switch: the features are already resident from monthly servicing, and the package activates them. Sequencing has two more details. KB5124010, the September 22 preview cumulative, or a later one must be installed first. The build number in that prerequisite line is worth a second look: KB5121794 gives it as 26100.9546, while the KB5124010 article and the release-health history both say 26100.9550 on 24H2 and 26200.9550 on 25H2. Match the KB number rather than the build. And the package is not offered in the Microsoft Update Catalog; Windows Update and WSUS are the channels, where it syncs under Product “Windows 11” and Classification “Upgrades”.

KB5121794 applies only to 24H2 and 25H2 editions. Devices on Windows 11 26H1 cannot move to 26H2 at all: that release is a different Windows core for hardware that shipped in early 2026, and Microsoft says those devices get a future release instead. If you have 26H1 on the books, it belongs in a separate plan. Devices on 23H2 fall outside that 24H2 and 25H2 prerequisite, so they take a full feature update rather than the enablement package.

Microsoft is also rolling 26H2 out gradually with safeguard holds for known compatibility problems, so available is not the same as offered. Intune’s What’s new page for service release 2609 carried no 26H2 entry as of September 30, so there is nothing on the Intune side to wait for yet. The update rings and feature update policies you already own are the deployment lever.

Check the elevation conflict before you enable Administrator protection

Administrator protection is the security feature in this release worth understanding before anyone flips it. It keeps admin accounts deprivileged: elevation becomes just-in-time, requires Windows Hello, and uses a profile-separated hidden account, so an admin token exists only for the action that needed it. It is off by default. Microsoft lists enablement through the Intune settings catalog (in preview), CSP, Group Policy, or Windows Security. The feature arrived with KB5120998, the August 27 preview for 24H2 and 25H2 builds, so the collision below is not a 26H2-only risk: it is reachable on patched devices today. It is not supported on Windows 365 Cloud PCs or Azure Virtual Desktop session hosts.

Now the part to read before the pilot. Microsoft’s Endpoint Privilege Management troubleshooting page carries this statement, filed under organizations that enable Administrator protection:

“Administrator Protection doesn’t currently support elevations initiated from Endpoint Privilege Management. If organizations enable Administrator Protection on devices where standard users rely on Endpoint Privilege Management (EPM) to handle elevation, the elevation fails. We’re working to resolve this issue in a future release.”

EPM gives standard users controlled elevation for specific apps. Administrator protection hardens accounts that already hold admin rights. They are different layers, and on the same device they currently collide: where standard users rely on EPM, enabling Administrator protection makes those elevations fail. The fix is in progress, not shipped. Check that page before both land on one ring.

The switch that turns on everything

Windows ships some features dormant for managed devices behind temporary enterprise feature control. In Intune the setting is Allow Temporary Enterprise Feature Control, under Windows Update for Business. The Group Policy equivalent sits at Computer Configuration > Administrative Templates > Windows Components > Windows Update > Manage end user experience. It is not a per-feature control: enabling it turns on every feature behind the control at the next restart.

That is the trap in getting ahead of the release. 26H2 enables those features anyway, so flipping the policy early only moves them onto production ahead of your own validation. Enabling it to unlock one feature you want means shipping the rest of the set untested.

Some commercial defaults also change without a policy decision. Windows settings backup is enabled by default for eligible commercial devices, app-specific taskbar actions are on by default, and several File Explorer enhancements leave temporary control. Existing administrator policies are still honored, so an explicit enable or disable you already deployed wins over the new default, and restore stays separately controlled.

Rings, deferrals, and the October clock

The support clock matters here too. 24H2 Home, Pro, Pro Education, and Pro for Workstations end updates on October 13, 2026. 23H2 Enterprise and Education end on November 10, 2026. Enterprise and Education on 24H2 run to October 12, 2027, so a mixed-edition fleet is on more than one clock. Microsoft names Windows Autopatch, Intune, and WSUS as the channels for this release, so an Autopatch-managed fleet sets the version on its Autopatch group’s feature update target rather than building a parallel process. The edition-by-edition breakdown is in the earlier 26H2 post, and the full version-by-version table is on Microsoft’s Windows 11 release information page.

On the mechanics, use a feature update policy to decide the version and treat update ring deferrals as a conflict with it. Microsoft’s guidance for feature update policies is to set Feature update deferral period (days) to 0 on rings that receive one, because a nonzero deferral can delay or block the version the policy is trying to deliver. The order matters: assign the policy, wait until targeted devices report OfferReady in the Windows feature updates (Organizational) report, and only then zero the deferral. Remove the deferral first and a device can scan before the service has processed the policy, which is how you end up offered a version you did not pick.

What to do this week

  • Confirm KB5124010 or a later cumulative is on the pilot ring before you test the enablement package, and make sure WSUS has Product “Windows 11” and Classification “Upgrades” enabled so the upgrade syncs.
  • Inventory by build and edition. 24H2 and 25H2 are on the enablement-package path, 26H1 needs its own plan, and 23H2 devices sit outside the package prerequisite and take a full feature update.
  • Move the version decision into a feature update policy, and clear feature update deferrals on that ring only after the devices report OfferReady.
  • Leave Allow Temporary Enterprise Feature Control off unless a pilot has validated every behavior it enables at once.
  • Do not enable Administrator protection on devices where standard users rely on EPM. Pilot it on a ring with no EPM dependency and confirm the known-issue entry has cleared first.
  • Pilot the user-facing changes (Start menu, taskbar, Search, File Explorer) and brief the service desk before the ring widens.

Piloting 26H2 this week or waiting for the October security train is a legitimate call either way. Letting the enablement package make it for you is not. If your fleet is already on 24H2 or 25H2, the update is small enough that the pilot is cheap, and the two policy-level controls above, the enterprise feature switch and the Administrator protection conflict, are the parts that carry risk.

Sources