Microsoft pushed Windows 11 version 25H2 into the Release Preview channel on August 29, 2025, shipping it as a lightweight enablement package that activates features already lying dormant inside the latest 24H2 cumulative updates. Build 26200.5074 isn't a flashy release—there's no sweeping visual redesign—but it lands with force: PowerShell 2.0 and the WMIC command-line tool are being ripped out of the OS, and IT admins get a new policy to clean out preinstalled Microsoft Store apps on enterprise devices. The entire upgrade, for machines already current on 24H2, typically completes with a single restart and a download measured in kilobytes, not gigabytes. That speed comes at a price: any script or tool that still calls powershell.exe -Version 2 or parses wmic.exe output will break, and organizations have only a few months to find and fix them before broad deployment.

A tectonic shift in Windows servicing

The enablement package (eKB) model isn't new—Microsoft perfected it during the Windows 10 era—but its application to Windows 11's annual feature updates signals the new normal. Code for 25H2 has been trickling into 24H2 systems through monthly cumulative updates (LCUs) all year. The eKB is a master switch: when you install it, the same binaries that 24H2 uses suddenly light up with new behaviors, UI refinements, and removed components. For IT operations, the shared servicing branch means 24H2 and 25H2 get identical patches, reducing the testing matrix significantly. A device that's already on the latest 24H2 bits can transition to 25H2 almost transparently, without the traditional full reimage cycle.

That model slashes deployment time and bandwidth, but it also concentrates the breaking changes at the moment of activation. When the eKB flips the switch, all the deprecated features vanish and new features appear simultaneously. If your automation, security agents, or line-of-business apps depend on anything being removed, they'll fail immediately. There's no gradual attrition; it's a hard cut.

What's actually new in 25H2

Beyond the enablement infrastructure, 25H2 focuses on polish, security hardening, and giving IT admins more control. The UI gets incremental upgrades—think refined File Explorer, updated context menus, and subtle Fluent Design tweaks—but the star features are operational:

  • Removal of PowerShell 2.0 engine: Already deprecated for years, the legacy engine is no longer included in the image. PowerShell 5.1 and the latest PowerShell 7 remain fully supported. Scripts that explicitly invoke powershell -Version 2 will fail.
  • Removal of WMIC (wmic.exe): The ancient WMI command-line tool is gone. Microsoft recommends replacing it with PowerShell CIM cmdlets like Get-CimInstance. Monitoring scripts, SCCM configuration items, and many third-party installers that scrape WMIC output will need rewriting.
  • Policy-based removal of default Store apps: A new Group Policy and MDM CSP (./Device/Vendor/MSFT/Policy/Config/ApplicationManagement/RemoveDefaultMicrosoftStorePackages) lets Enterprise and Education admins strip select inbox Store apps at the device level. No more relying on clunky post-deployment scripts during Autopilot; you can set the policy and have the OS remove them before the user signs in.
  • Continued, hardware-gated AI features: Copilot and other AI surfaces expand selectively, but they're still locked behind NPU requirements, licensing, and telemetry opt-ins, meaning identical hardware can behave differently depending on configuration.

The last point creates a testing headache: two identical devices might show different AI features, depending on whether the user has the right Microsoft account type or hardware sensors enabled. IT will need to document expected behavior per persona.

PowerShell 2.0 and WMIC: the legacy axe falls

Organizations with long-lived automation libraries are in for a shock. PowerShell 2.0 was often called upon for compatibility with ancient scripts that couldn't parse newer syntax. Its removal is justified by Microsoft as a security measure—closing off an outdated, less-secure engine—but the real-world impact is that any script with -Version 2 or -v 2 will now throw an error. The remediation advice is clear: inventory your repos, find those calls, and upgrade the scripts to run on PowerShell 5.1 or 7. If you can't migrate immediately, containerizing the legacy code or using alternative hosts is a temporary workaround, but you'll want to eliminate that debt quickly, as future patches may further restrict compatibility shims.

WMIC's disappearance is arguably more disruptive because it was used so pervasively. System administrators for two decades typed wmic logicaldisk get name,size,freespace to grab disk info. The replacement—Get-CimInstance -ClassName Win32_LogicalDisk | Select-Object DeviceID, Size, FreeSpace—is more verbose and requires a different parsing logic in scripts. Monitoring tools that used WMIC to pull process lists or service status will break silently unless they're updated. Large enterprises often have thousands of one-liner wmic calls scattered across scheduling systems, login scripts, and configuration management tools. A complete audit is essential.

The Store app cleanup policy: powerful but unfinished

The new policy to remove default Microsoft Store packages is a godsend for companies that maintain tightly controlled golden images. Instead of running Remove-AppxPackage in a post-sysprep script—often a fragile, timing-dependent affair—administrators can now set a policy and have the apps reliably removed during provisioning. Microsoft published the CSP details in a support article, and early adopters report that the backend removal works as advertised.

But the front-end polish is lacking. Community tests (and internal Microsoft feedback) reveal that Start menu shortcuts and All Apps entries can persist as dead tiles even after the packages are gone. Clicking them does nothing, which will confuse users and trigger helpdesk calls. Microsoft will likely address this in a future cumulative update, but for now, IT shops must plan for post-removal cleanup—perhaps a script to clear the tile cache—or wait until the behavior is fixed. Intune also currently lacks a native UI for configuring this CSP, so you'll be dropping it in as a custom OMA-URI setting. That's fine for seasoned admins, but it adds friction for less experienced teams. Microsoft is expected to bring a graphical configuration blade later, but it's not in the preview yet.

A practical rollout playbook

The Release Preview status gives enterprises a tight validation window. The code is near-final, so you can start testing now. Here’s a realistic action plan:

1. Inventory and remediate legacy dependencies

Run a repository-wide search for wmic.exe and powershell.exe -Version 2. Capture every script, configuration item, GPO preference, and scheduled task that uses these. Prioritize remediation based on business criticality. Do not skip this step; the eKB activation will expose all of them at once.

2. Build a representative pilot ring

Create a pilot group covering at least 5–10% of your fleet, with a mix of hardware models, user profiles, and departmental apps. Include devices that run your endpoint detection and response (EDR) agents, backup software, VPN clients, and any legacy peripherals. Deploy the 25H2 eKB via Windows Update for Business (WUfB) or WSUS. Monitor application logs, driver stability, and user-reported glitches for at least a week.

3. Test the Store app removal policy thoroughly

Apply the new policy during Autopilot provisioning and on existing devices. Check the AppXDeployment-Server event logs for errors. Verify that no dead shortcuts remain. If they do, document a cleanup method and include it in your standard operating procedure. Also test re-provisioning apps from the Store after cleanup to ensure the policy doesn't lock out future installations.

4. Validate rollback procedures

Enablement packages can be uninstalled through standard update history. Test uninstalling the eKB on pilot devices and confirm that all agents and services return to their pre-activation state. Take snapshots or backups before testing. If you’re using third-party management tools, ensure they handle the uninstall gracefully.

5. Coordinate with ISVs

Reach out to your critical software vendors—especially those in virtualization, security, and data backup—and confirm they support 25H2. Get updated installers if needed. The shared servicing branch means most agents that work on 24H2 should continue to work on 25H2, but the removal of WMIC and PowerShell 2.0 might break some dependency checks, so don't assume.

Compatibility and risk analysis

The security upside of this release is real: killing PowerShell 2.0 eliminates a known vector for downgrade attacks, and removing WMIC closes an often-overlooked attack surface that attackers have used for living-off-the-land techniques. The Store app policy also reduces the attack surface on fresh installs, which is especially valuable for regulated industries.

But the operational risk is concentrated in organizations that have delayed technical debt management. If you have thousands of lines of unrefactored automation that date back to the Windows 7 era, 25H2 will be painful. The risk isn't just that scripts fail; it's that they might fail silently, corrupting data or leaving services in an inconsistent state. Also, the uneven rollout of AI features means that a helpdesk script for enabling Copilot might work on one machine but not another, based solely on hardware. Documentation and controlled user communication become critical.

What the Release Preview timeline means

Microsoft hasn't announced a general availability date, but the Release Preview drop on August 29, 2025 points to a public launch likely in September or October. That gives IT teams between four and eight weeks to complete validation and remediation. Installing 25H2 also resets the servicing lifespan for a device: Enterprise and Education editions get a new 36‑month support clock, while Pro, Home, and other editions get 24 months. That lifecycle reset is important for compliance planning and budget cycles. If you’re still on an older Windows 11 release approaching end of service, 25H2 might be your bridge to a longer support tail, but you must be ready before the holiday change freeze hits.

The long view: Windows updates as a toggle, not a trauma

25H2 could be the most boring feature update Microsoft has ever shipped—and that’s exactly the point. By moving to a model where the annual update is essentially a configuration change, Microsoft reduces the blast radius of each release. The trade-off is that organizations must adopt modern operational practices: continuous integration pipelines, automated testing, and a developer-like discipline around infrastructure as code. If you’re still managing endpoints with manual imaging and homegrown VBScripts, the pain will accumulate. But if your shop already treats endpoints as cattle, not pets, the transition will be anticlimactic.

Windows 11 25H2 demonstrates that the era of massive, disruptive Windows upgrades is over. IT leaders should embrace the enablement package model by investing in the tooling and processes that make it safe: robust inventory, automated validation, and rapid rollback. The Release Preview is your smoke test. Start now, or risk getting burned when the switch is flipped at scale.