The Enablement Package: How 24H2 Becomes 25H2 in a Reboot (and Why That Is Not a Real Upgrade)

Two devices in the same fleet both moved from one Windows 11 version to the next last month. One took four minutes and a single restart. The other took ninety minutes, wrote a multi-gigabyte payload to disk, rebooted three times and left a Windows.old folder behind. Same operating system. Same management tooling. Completely different change record, completely different maintenance window, completely different risk.

That is not a bug. It is two entirely different delivery mechanisms hiding behind one word: feature update. This post explains which is which, how to tell from a build number alone, and why the choice has a servicing-lifecycle consequence that catches people out a year later.

The problem: two very different updates wearing one label

Windows Update, WSUS and the Intune admin center all use the same phrase for both mechanisms. In every one of those consoles the change is called a feature update. In the Intune admin center it lives under a node literally named Feature updates. Nothing in the console tells you whether the device is about to download an operating system or flip a switch.

The practical consequences of guessing wrong run in both directions.

Guess too big. You schedule a four-hour Saturday window, warn the business, arrange cover, stage a Microsoft Connected Cache node, and confirm every device has 25 GB free. The change completes in one restart per device. You have burnt a weekend and a chunk of goodwill on a reboot.

Guess too small. You treat it as a reboot, push it into a Tuesday-evening deadline, and discover that the devices on the older branch are doing a full operating system swap. Laptops sit on the spinning-dots screen for over an hour, some run out of disk, and your service desk queue triples on Wednesday morning.

There is a third failure mode that is quieter and more expensive. Because the two versions on a shared branch contain the same code, admins conclude the version number does not matter and stop chasing it. Twelve months later the older version drops out of support - and stops receiving the very same monthly package the newer version is still getting. Devices that were byte-for-byte identical to a supported device are now unpatched.

Why it happens: one servicing branch, two version numbers

Start with what Microsoft actually builds. A servicing branch is a single code line that produces monthly cumulative updates. Historically each Windows version had its own branch. Since Windows 10 version 1903, Microsoft has periodically put two consecutive versions on one branch.

Microsoft states it plainly for the current pair. Windows 11 versions 24H2 and 25H2 "share a common core operating system with an identical set of system files", so the new 25H2 features "are included in the latest monthly quality update for Windows 11, version 24H2 but are in an inactive and dormant state".

Read that again, because it is the whole mechanism. The 25H2 features are not waiting on a server. They were delivered to your 24H2 devices months ago, inside ordinary Patch Tuesday packages, switched off.

The chain, from code complete to new version number

Here is what calls what, in order:

1. A feature is finished in the shared branch. Instead of holding it for an annual release, Microsoft puts it into a monthly LCU for the current version - so 25H2 features shipped inside 24H2 cumulative updates.
2. Some of those features are visibly live straight away. Others are held back on managed devices by temporary enterprise feature control, which turns off selected features on any device that gets its updates from Windows Update client policies or WSUS. Configuration Manager and Intune count as managed, because their updates ultimately come from those two.
3. The bits sit on disk, dormant, month after month. Your 24H2 device is carrying 25H2 code it is not running.
4. Windows Update offers the enablement package. Microsoft describes it as "a small, quick-to-install switch that activates all of the Windows 11, version 25H2 features".
5. The eKB installs through the normal component-based servicing path. It changes flags from disabled to enabled and requires a restart. Microsoft's KB is explicit: "You must restart your device after you apply this update."
6. After the restart, CurrentBuild reads 26200 instead of 26100, DisplayVersion reads 25H2, and the temporary enterprise feature control on that feature set ends.

No operating system image was downloaded. No Windows.old was created. No migration ran. That is why it finishes in one restart.

Which transitions get the switch, and which get the swap

This is the table to keep. Everything in it comes from Microsoft's published version pages and the Windows 11 release information page.

Two rows in that table deserve their own paragraph.

23H2 is the cliff edge. Microsoft's own announcement is blunt: "Windows 11 eligible devices on Windows 11, version 23H2 (and earlier versions) require a full operating system (OS) swap to update to Windows 11, version 25H2." If your estate is mixed, half of it gets a reboot and half of it gets a genuine upgrade. Plan both.

26H1 is not a third option, it is a different animal. Microsoft is explicit that 26H1 "isn't a feature update", is available "only preinstalled on select new devices", and "can't be installed as an in-place update on existing devices". It is a silicon-enablement release on build 28000, a different Windows core. Microsoft also warns that devices on 26H1 "won't be able to update to the next annual feature update" and will get a path in a future release. If a new laptop model arrives on 26H1, do not put it in your normal feature-update ring and expect it to converge.

Build versus UBR - the distinction that answers everything

A Windows build string has four parts: 10.0.<build>.<UBR>. On the device this post was written on that is 10.0.26200.9168.

• The build (26200) is the branch-and-version identity. Only a feature update or an enablement package changes it.
• The UBR (9168) is the monthly revision. Every cumulative update increments it. Nothing else does.

Now look at what Microsoft's release information page listed for August 2026. Both 24H2 and 25H2 show the same latest update, KB5121003, on the same date. 24H2 lands on 26100.9168; 25H2 lands on 26200.9168. One KB, one payload, two build numbers, one identical UBR.

That matching UBR is the fingerprint of a shared branch. Compare it with 23H2 in the same month: a different KB entirely (KB5120240) producing 22631.7517. Different branch, different package, unrelated revision number.

So the diagnostic rule is short. If two versions publish the same monthly KB and the same UBR, they are one branch and the hop between them is an enablement package. If they publish different KBs, the hop is a full operating system swap.

How to verify: build, UBR, branch and pin on a live device

Everything below was run on a real Windows 11 Enterprise 25H2 device. Identifiers are replaced where any appear.

Registry - the version identity values

All of the version identity lives under one key. Read it, do not write it.

Here is the same key read from a console. The command below pulls the six values worth having and prints them as a list.

Reading it in the graphical tool looks like this. The same values, the same key.

Registry - the target release version pin

The second key that matters is the Windows Update policy key. This is where a version pin is written when you use Group Policy.

Intune writes the same intent to a different place. Microsoft's tables document the MDM keys landing under HKEY_LOCAL_MACHINE\Software\Microsoft\PolicyManager\default\Update, with the merged effective values observable under the current\device\Update subtree on a live machine. Check both surfaces, because they disagree more often than you would like.

Event Viewer - what an eKB install leaves behind

The enablement package installs through Component Based Servicing, so its evidence lands in the Setup channel, not the System log.

Microsoft does not publish a reference catalog of Setup-channel event IDs for the Servicing provider. The table below is therefore observed on a live 25H2 device, not documented. It is genuinely useful for reading a log by hand, and genuinely unsafe to build alerting on, because an undocumented ID can be renumbered in any update.

System files - the binaries that actually do the work

Two different code paths, two different sets of binaries. This is the clearest way to see that an eKB is not an upgrade.

Look closely at that last row. The package version reads 26100.6717 - the 24H2 branch - even though installing it produces a 25H2 device. The eKB is built against the branch it enables features inside. That single string is the shared servicing branch made visible.

The command below queries the component store for that package. Get-WindowsPackage is read-only; it changes nothing.

Log files - the exact strings to grep

Services and scheduled tasks

Can the enablement package be uninstalled?

Here honesty matters more than a tidy answer.

Microsoft's KB5054156 article documents no uninstall procedure at all. It says the update does not replace any previously released update, and it says you must restart. It does not offer a removal path.

What is documented elsewhere is the general machinery. Windows exposes an Uninstall updates list at Settings > Windows Update > Update history > Uninstall updates, and Microsoft notes plainly that "Some updates cannot be uninstalled". DISM documents /Remove-Package for removing a .cab-based package by name from an online image. And Microsoft documents a dedicated policy for how long a feature update stays removable: Update/ConfigureFeatureUpdateUninstallPeriod, an integer with a default of 10 days and an allowed range of 2 to 60, at the Group Policy path Windows Components > Windows Update > Manage end user experience.

On the live device, the eKB behaves like an ordinary update in every observable way: it appears in Get-HotFix as KB5054156 with description Update, and its component store state is Installed with Restart Required: Possible. There is no Windows.old folder anywhere on the disk, because no operating system was swapped, so the classic Go back rollback image simply does not exist for this transition.

Defender and security policy

This one is genuinely not applicable, and saying so is more useful than inventing a link. Enablement package delivery involves no Defender component: no Attack Surface Reduction rule governs it, no exploit protection setting applies, no WDAC policy or firewall rule is involved, and there is no Endpoint Security profile in Intune that touches it. It is a Component Based Servicing operation driven by the update client.

There is one indirect connection worth knowing. Because the eKB ends temporary enterprise feature control on a set of features, a restart can turn on user-facing features you had not reviewed - Microsoft's 25H2 page lists Agent in Settings, improved Windows search, Click to Do and AI actions in File Explorer as the features leaving temporary control in that transition. Several of those have their own permanent management controls. Review them before the eKB lands, not after, because the eKB is not the thing you can configure - the individual feature policies are.

The fix: choose the path deliberately, then pin it

The fix is not a registry edit. It is deciding which version your fleet sits on, writing that decision down as policy, and verifying the write landed.

Group Policy - the full click path

This is the ADMX-backed route. It writes to the Policies\Microsoft\Windows\WindowsUpdate key described earlier.

1. Open the Group Policy Management Editor on the GPO you use for Windows Update, or gpedit.msc for a single machine test.
2. Navigate to Computer Configuration > Administrative Templates > Windows Components > Windows Update > Manage updates offered from Windows Update.
3. Open Select the target Feature Update version. The setting comes from WindowsUpdate.admx, so make sure your Central Store has a current copy.
4. Set it to Enabled.
5. In Which Windows product version would you like to receive feature updates for? type Windows 11. Microsoft documents accepted product strings including Windows 11, 11 and Windows 10. Do not leave it blank.
6. In Target Version for Feature Updates type the version you want, for example 25H2. This is a version label, not a build number.
7. Apply, then run gpupdate /target:computer /force on a test device.
8. Verify the three values landed: TargetReleaseVersion is 1, TargetReleaseVersionInfo is your version string, and ProductVersion is your product string. If ProductVersion is missing, the policy did not save both fields - reopen it.

Intune Settings Catalog - the CSP route

The same two values, delivered by MDM. Microsoft documents the CSP names as ./Device/Vendor/MSFT/Policy/Config/Update/TargetReleaseVersion and ./Device/Vendor/MSFT/Policy/Config/Update/ProductVersion, both string type.

1. Sign in to the Microsoft Intune admin center and go to Devices > Configuration.
2. Select Create > New policy. Platform Windows 10 and later, profile type Settings catalog. Select Create.
3. Name the policy something a colleague will understand a year from now, for example WIN-Update-TargetVersion-25H2. Select Next.
4. On Configuration settings choose Add settings, then search for Target Release Version. The Windows Update for Business settings are grouped together in the picker; the underlying CSP is Update/TargetReleaseVersion.
5. Tick Target Release Version and, in the same category, Product Version. Add both. Configuring one without the other is the most common mistake here.
6. Set Product Version to Windows 11 and Target Release Version to 25H2.
7. Select Next through Scope tags, assign to a pilot device group first, then Create.
8. After the device checks in, verify on the endpoint. The MDM values land under the PolicyManager subtree, not the ADMX Policies key - so confirm there, and confirm no stale ADMX value is contradicting you.

Intune feature update policies - the orchestrated route

Since the target release version pin only says "no further than this", Microsoft also provides a policy type whose job is to actively deploy a chosen version with rollout control.

1. Go to Devices > Windows, then Windows updates > Feature updates.
2. Select Create profile.
3. Under Deployment settings, give it a name, then pick the version from the Feature update to deploy dropdown. Only in-support versions appear.
4. Choose Make available to users as a required update for a managed rollout, or Make available to users as an optional update to let users pull it themselves. The optional path requires a Windows Autopatch licence.
5. Configure Rollout options to phase availability rather than releasing to everyone at once.
6. Assign to device groups, review, then Create.
7. Then go back to your update ring and set Feature update deferral period (days) to 0. Microsoft is explicit that combining ring deferrals with feature update policies "adds unnecessary complexity and can delay or block feature updates".
8. Confirm the Windows feature updates (Organizational) report shows targeted devices at state OfferReady before you remove the deferrals. That state is your proof the service has processed the policy.

WSUS and Configuration Manager

If you sync updates yourself, the eKB arrives as an Upgrade, not an Update. Microsoft documents the WSUS configuration for KB5054156 as Product: Windows 11 and Classification: Upgrades. If your WSUS product and classification selections do not include Upgrades, the enablement package will never appear in your console and your devices will never be offered it - and nothing will look broken, because everything else keeps syncing normally. Check that first when devices refuse to move.

Proof it worked: real output from a 25H2 device

The companion script, Get-ServicingBranchIdentity.ps1, assembles the whole answer in one place: version identity, servicing branch, whether the next version change is a switch or a swap, any target release version pin on either policy surface, and whether an enablement package is present in the component store. It is read-only, it needs no modules, and it aborts with exit code 1 rather than print a clean-looking report after a failed read.

This is a genuine run on the Windows 11 Enterprise 25H2 device used throughout this post, with nothing invented. Hostnames were not printed by the script, so nothing needed redacting - but note the stale pin it caught.

Read that output as a story. Block 1 and 2 establish the device is on 25H2, build 26200, on the branch it shares with 24H2. Block 5 proves how it got there - an enablement package, installed on a specific date, still sitting in the component store as evidence months later when the Setup event log had long since rotated away. Block 4 is the finding that would never have surfaced from a console: a Group Policy pin that says one thing while the device does another.

Three things you now know that you cannot get from winver: which mechanism moved this device, when, and whether the policy you think is protecting it actually is.

The script is on GitHub in the feature-update-enablement-package-ekb-mechanics folder of the Windows-11-Scripts repository. Run it with -SkipPackageQuery for a fast identity-and-pin check, or -Quiet to drop the prose when you are collecting output across a fleet.

References

• KB5054156: Feature update to Windows 11, version 25H2 by using an enablement package - Microsoft Support. The shared core statement, the prerequisite, the restart requirement, and the WSUS product and classification.
• What's new in Windows 11, version 25H2 for IT pros - Microsoft Learn. The enablement package description, the servicing timeline, and the features leaving temporary enterprise feature control.
• What's new in Windows 11, version 23H2 for IT pros - Microsoft Learn. The equivalent statement for the 22H2 to 23H2 enablement package, KB5027397.
• Windows 11, version 26H1 for IT pros - Microsoft Learn. Why 26H1 is not a feature update, is preinstall-only, and cannot take the next annual release.
• Windows 11 release information - Microsoft Learn. Build numbers, availability dates, end-of-updates dates per edition, and the shared monthly KB across 24H2 and 25H2.
• Lifecycle FAQ - Windows - Microsoft Learn. The 24-month and 36-month servicing timelines by edition.
• Update Policy CSP - Microsoft Learn. TargetReleaseVersion, ProductVersion and ConfigureFeatureUpdateUninstallPeriod, with the Group Policy mappings and the WindowsUpdate.admx reference.
• Configure Windows Update client policies - Microsoft Learn. The registry key tables for Group Policy versus MDM, deferrals, pauses, and AllowTemporaryEnterpriseFeatureControl.
• Configure Windows feature update policies - Microsoft Learn. The Intune admin center click path and the guidance on moving off update ring deferrals.
• DISM operating system package servicing command-line options - Microsoft Learn. /Get-Packages, /Get-PackageInfo, /Remove-Package, and the /ResetBase warning.
• How to get the Windows 11 2025 Update - Windows Experience Blog. The shared code base statement and the full operating system swap requirement for 23H2 and earlier.
• How to uninstall a Windows update - Microsoft Support. The Settings path, and the note that some updates cannot be uninstalled.

Community deep-dives worth reading

Each of these was opened and confirmed on topic before being listed here.