Microsoft has pushed Windows 11 version 25H2 (build 26200.5074) into the Release Preview channel, and it’s unlike any major feature update you’ve installed before. Instead of a multi-gigabyte download, 25H2 arrives as a featherweight enablement package—a tiny update that simply flips on features already hidden inside monthly cumulative updates. For the 10 million-plus devices running Windows 11 24H2 with the latest patches, the transition to 25H2 will feel more like a routine security fix than a full OS upgrade.

This release isn’t about flashy UI overhauls. Microsoft is using the 25H2 milestone to tighten security, clean up legacy components, and give IT administrators finer-grained control over enterprise devices. The enablement package model, which has been used in previous update cycles, makes the upgrade fast—often requiring only a single restart—while minimizing network bandwidth and user disruption. But beneath that smooth surface, there are breaking changes that demand immediate attention from system administrators and developers.

The enablement package: a master switch for features

An enablement package (eKB) is a small download—typically under 100KB—that acts like a master switch. For months, Microsoft has been seeding feature code into the regular cumulative updates for Windows 11 24H2, but it has kept those features dormant through registry flags. The eKB simply flips those flags from “off” to “on.” After a quick reboot, the device reports itself as running version 25H2 and gains access to the new capabilities.

This approach has clear advantages: downtime is negligible, network traffic is slashed, and IT teams can schedule the switch without a lengthy installation. Microsoft used a similar strategy for past updates like 21H2 to 22H2, but 25H2 marks the first time an annual feature release is being delivered this way from the start. For companies that struggled with big feature-update rollouts, this is a welcome relief—provided they are already on 24H2 and up to date with monthly patches.

Shared servicing branch: one branch to rule them both

Because 25H2 is built on the same core code base as 24H2, both versions share a single servicing branch. That means monthly quality updates (LCUs and SSUs) apply uniformly to both, and security fixes flow to all devices regardless of which “feature” version they report. For administrators, this simplifies patch management: you validate one set of updates, not two. It also means that if you’re current on 24H2 patches, you already carry most of the 25H2 code. The eKB just unlocks it.

The shared branch also resets support clocks: Enterprise and Education editions get a new 36-month servicing window, while Pro and Home editions reset to 24 months from the 25H2 release date. This extended timeline is a boon for organizations that plan their hardware and software lifecycles carefully.

What’s new: removals, deprecations, and IT controls

Microsoft isn’t packing 25H2 with eye candy. Instead, it’s removing long-deprecated components and handing admins a new policy lever to control the bloat.

PowerShell 2.0 gets the axe

PowerShell 2.0 has been a deprecated security risk for over a decade, and in 25H2 it is being removed from shipping images. Scripts or applications that explicitly invoke PowerShell with the -Version 2 switch will now fail to load the legacy engine. Instead, they’ll run under the default Windows PowerShell 5.1 host—or, if installed, PowerShell 7. For most modern automations, this is a non-issue, but any script that relies on ancient PSv2-specific behavior will break. IT teams must hunt down these dependencies now.

WMIC is gone (almost)

The Windows Management Instrumentation Command-line tool (wmic.exe) has been deprecated since Windows 10 and is being actively removed. Microsoft wants you to migrate to PowerShell CIM/WMI cmdlets, which are more secure and scriptable. But wmic is still embedded in countless legacy scripts, scheduled tasks, and monitoring agents. Its removal can cause subtle failures in inventory systems, deployment workflows, and third-party management tools. The fix is straightforward: replace each wmic call with its modern equivalent, like using Get-CimInstance instead of wmic logicaldisk.

Policy-controlled removal of default Store apps

Enterprise and Education editions gain a new Group Policy and MDM CSP setting called “Remove Default Microsoft Store packages.” When enabled, it prevents certain preinstalled Store apps from appearing on new user logons and, in many cases, strips them from existing profiles. This is not a blanket purge—admins select from a curated list of apps—but it’s a first-party solution for image hardening and cutting OOBE clutter. Early testing by third-party tooling vendors shows that the policy sometimes leaves behind dead tiles or shortcuts, so IT shops should validate it thoroughly before a broad rollout.

How the upgrade actually works

From Windows Update, the eKB will appear as an optional update for Release Preview testers and, eventually, a seeker experience for Insiders. In managed environments, it will flow through WSUS, Windows Update for Business, and Intune. The package itself is tiny; once installed, a single restart activates the features. Devices not running 24H2 will need a full feature update first—the eKB path is only available for systems already on that code base.

Administrators using Configuration Manager or on-premises WSUS should double-check that their product classifications and UUP settings expose the enablement package correctly. In past releases, some consoles didn’t display small eKBs as expected, leading to confusion. Microsoft recommends pilot testing in your management infrastructure before widespread deployment.

The risks beneath the simplicity

While the eKB model is elegant, it isn’t without landmines. The staged-code approach means features have been sitting dormant on devices for months; activating them all at once could surface unexpected conflicts with third-party drivers, security software, or specialized utilities. The removal of PSv2 and WMIC will almost certainly break some legacy automation, and discovering those breaks requires active scanning—they won’t show up until the scheduled task fails or the monitoring alert goes silent.

For the new Store app removal policy, the gap between provisioning prevention and full cleanup may leave remnants that confuse users or affect imaging consistency. And as always, any OS feature activation can alter behavior in ways that only real-world testing reveals.

What IT teams must do now

The 25H2 enablement package is already in Release Preview, so the clock is ticking. Administrators should treat this as a formal validation milestone, not an experimental curiosity. Here’s a prioritized action plan:

  1. Enroll a pilot group—a handful of production-representative devices—into the Release Preview channel and install build 26200.5074. Pay attention to boot times, driver behavior, and application compatibility.
  2. Inventory legacy dependencies—scan all scripts, Group Policy objects, SCCM packages, scheduled tasks, and vendor agents for calls to wmic.exe or powershell -version 2. Use the PowerShell snippets provided in Microsoft’s guidance to search across file shares and task configurations.
  3. Remediate scripts—replace every wmic call with its CIM equivalent. For example, change wmic logicaldisk get name,size,freespace to Get-CimInstance Win32_LogicalDisk | Select-Object DeviceID,Size,FreeSpace. Test PSv2-reliant scripts under PowerShell 5.1 first, then consider migrating to PowerShell 7.
  4. Validate vendor software—contact your antivirus, backup, and monitoring vendors to confirm that their agents don’t depend on the deprecated components. Some installers historically invoked PSv2, and they may fail on 25H2 images.
  5. Lab-test the app-removal policy—on a clean Enterprise VM, enable “Remove Default Microsoft Store packages” and observe both new user logons and existing profiles. Check the AppxDeployment-Server operational log for removal events and verify that no dead shortcuts remain.
  6. Confirm distribution plumbing—in WSUS/SCCM environments, ensure that the Windows 11 product and appropriate classifications are selected, and that the eKB appears as expected. UUP consolidations can sometimes hide small packages.
  7. Plan a phased rollout—use the standard rings: pilot, broad pilot, targeted deployment, full production. Know how to uninstall the eKB via DISM, PowerShell, or Windows Update history if you need to roll back within the support window.
  8. Monitor post-activation—watch Windows update event channels and endpoint telemetry for regressions, especially around driver crashes or performance dips.

Security wins and the ever-evolving threat landscape

The removal of PSv2 and WMIC is a direct hit against living-off-the-land (LoL) techniques favored by ransomware operators and nation-state actors. Both binaries have been used for reconnaissance, lateral movement, and persistence precisely because they are signed, trusted, and ubiquitous. Eliminating them shrinks the attack surface and forces adversaries to look for alternative tools—which can then be more easily monitored and blocked.

However, security is a cat-and-mouse game. As soon as one LoL binary disappears, attackers shift to another. Security teams should complement this hardening with robust endpoint detection and response (EDR), application control, and behavior analytics. The 25H2 release is a strong step forward, but it’s not a silver bullet.

Developer and vendor impact

ISVs and internal development teams must check their installers, runtimes, and background services. Any setup routine that tries to invoke PSv2 or wmic will fail on a vanilla 25H2 system. Vendors should publish updated agents and documentation before the update lands broadly. Modernizing away from these deprecated components also aligns with Microsoft’s long-term security roadmap, so the effort pays off beyond this single release.

The bottom line

Windows 11 25H2 is a pragmatic, security-focused release that uses the enablement package model to deliver real administrative benefits without the usual upgrade pain. For enterprises, the combination of a reset servicing clock, legacy component removal, and new app-provisioning controls is a clear win—but only if IT teams do the prep work. The Release Preview build is the starting gun. Audit your scripts, test your images, and validate your update pipelines now, because the upgrade itself will be fast, quiet, and irreversible if you’re not ready.