Microsoft has pushed Windows 11 version 25H2 into the Release Preview channel, signaling that the annual feature update is nearly ready for broad deployment. But this year’s release is less a feature explosion and more a deliberate housecleaning. Instead of splashy new consumer capabilities, 25H2 focuses on removing deprecated components, tightening security, and handing enterprise administrators a long‑requested lever to purge unwanted apps from their fleet.

The update arrives as a lightweight enablement package (eKB) layered on top of the existing Windows 11 24H2 servicing branch. That architectural choice means organizations can move from 24H2 to 25H2 with a single restart rather than a full‑scale OS reinstall. For IT teams, the immediate takeaway is clear: begin validation now, but treat the Release Preview as a formal pilot window—not a green light to flip the switch across production machines.

What an enablement package actually does

An enablement package exploits a shared servicing model that Microsoft has refined over several Windows releases. Feature binaries are shipped in a disabled state inside monthly cumulative updates. When the company declares the next version ready, a compact eKB (typically measured in kilobytes, not gigabytes) toggles those dormant features on. The result is a version bump that feels more like a monthly quality update than a traditional feature upgrade.

Because 24H2 and 25H2 share the same code base, compatibility testing is dramatically simplified. Teams can concentrate on validating the newly activated features—plus any removed components that might break existing workflows—rather than re‑certifying an entirely new OS image. However, the flip side is that feature visibility can be staggered across devices. Not every PC will light up the same capabilities at the same time, thanks to hardware‑gating, license checks, and phased rollout schedules.

What’s changing: removals take center stage

Microsoft’s own announcement and supporting documentation emphasize what’s going away as much as what’s being added. The two headline removals—Windows PowerShell 2.0 and the WMIC command‑line tool—are not buried in fine print. They represent a deliberate security‑hardening push that may force overdue script‑migration projects in enterprise environments.

Windows PowerShell 2.0 is being ejected

PowerShell 2.0 was officially deprecated years ago but lingered as an optional compatibility component. It lacks modern defensive features such as script block logging, constrained language mode, and anti‑malware scan interface integration. Attackers have long abused the ability to invoke powershell.exe -Version 2 as a downgrade vector that bypasses logging and policy controls. By removing the engine entirely from shipping images, Microsoft closes that avenue and reduces maintenance complexity.

For most users, the change is invisible. But any script, installer, or vendor toolkit that explicitly calls PowerShell 2.0 will fail silently or throw an error. Administrators must inventory their estate for patterns like powershell -Version 2 or powershell.exe -v 2. A quick PowerShell one‑liner can surface them:

Get-ChildItem -Path <repository> -Recurse -Include *.ps1 | Select-String -Pattern "powershell.*-Version 2|-v 2" -List

The recommended migration path is to PowerShell 5.1 for maximum Windows‑specific compatibility or to cross‑platform PowerShell 7.x for modern automation.

WMIC is deprecated and will break existing scripts

WMIC (wmic.exe) has been a staple of system management for two decades. It’s often used in quick-and-dirty scripts to query disk information, process lists, or service status. Microsoft is removing it for the same security and modernization reasons that drove the PowerShell 2.0 purge. WMIC is frequently abused by malware and lateral‑movement tools, and its old‑style output parsing doesn’t mesh well with modern automation.

The practical impact is significant: any batch file, monitoring rule, or installer that shells out to wmic.exe will break. Teams need to convert those invocations to PowerShell CIM/WMI cmdlets. Two common examples illustrate the migration pattern:

  • Disk information
    Old (WMIC): wmic logicaldisk get name,size,freespace
    New (CIM): Get-CimInstance -ClassName Win32_LogicalDisk | Select-Object DeviceID, Size, FreeSpace
  • Process listing
    Old: wmic process where name='notepad.exe' get processid
    New: Get-CimInstance -ClassName Win32_Process -Filter "Name='notepad.exe'" | Select-Object ProcessId

The migration may also require adjustments for string‑output formatting differences between WMIC and the object‑oriented CIM cmdlets.

New enterprise control: removing built‑in Store apps at scale

While 25H2 subtracts old tools, it adds one management capability that enterprise administrators have been requesting for years. A new Group Policy and MDM CSP control allows IT to remove select default Microsoft Store packages from Enterprise and Education devices—cleanly and at the device level, not per‑user.

This directly answers complaints about “bloatware” on managed images. Instead of relying on fragile logon scripts or post‑deployment cleanup, administrators can now define a policy that strips out unwanted apps before the user ever sees the desktop. Initial community testing, however, warns that the unprovisioning process may leave behind dead Start menu shortcuts in early builds. Pilot testing should include a detailed UI audit to confirm that tiles and shortcuts are fully removed.

The policy can be configured through Administrative Templates (Computer Configuration > Administrative Templates > Windows Components > Store) or via a custom MDM CSP path for Intune. Its availability underscores Microsoft’s gradual pivot toward giving commercial customers more authority over the Windows shell.

Practical steps for IT: inventory, remediate, pilot

25H2’s arrival in Release Preview should trigger a structured, ring‑based validation plan. The advice below synthesizes Microsoft’s guidance with community‑field experience.

  1. Inventory and discovery
    Scan for explicit PowerShell 2.0 invocations and WMIC usage across scripts, scheduled tasks, and third‑party management agents. Don’t forget to check for installer wrappers that probe for legacy components during setup.

  2. Remediate WMIC scripts
    Convert all WMIC queries to CIM equivalents. Test the output thoroughly—differences in property names or formatting can trip up downstream parsing logic.

  3. Migrate PowerShell 2.0‑dependent scripts
    Port to PowerShell 5.1 or 7.x. Verify scheduled tasks and vendor installers that attempt to enable the legacy engine; those will no longer succeed on images that lack it.

  4. Build a pilot ring
    Assemble a representative group covering high‑volume OEM SKUs, Surface devices, and any ARM64 hardware in use. Deploy 25H2 via Windows Update for Business (WUfB) or WSUS rather than allowing broad seeker downloads.

  5. Validate thoroughly
    Test line‑of‑business applications, endpoint protection agents, VPN clients, printer drivers, and backup/restore workflows. Monitor for UI regressions—Start menu pinning inconsistencies and dead tiles are the most commonly reported artifacts.

  6. Rollout and rollback planning
    Capture full backups or VM snapshots before the upgrade. Confirm that the uninstall and recovery procedures work with the eKB, bearing in mind that combined SSU+LCU packaging can complicate rollbacks. Expand rings only after a clean telemetry monitoring period.

Risks, trade‑offs, and what to watch in production

Despite the low‑friction upgrade path, 25H2 introduces several operational considerations that demand attention.

Fragmented feature visibility
Because many features are hardware‑ or license‑gated, two machines on the same build may show different capabilities. Copilot+ features, for example, require an NPU and specific licensing, meaning they won’t appear on all devices even when 25H2 is installed. This inconsistency can confuse users and complicate helpdesk documentation.

Legacy compatibility edge cases
Most users won’t notice the PowerShell 2.0 and WMIC removals, but edge cases persist. Very old vendor installers, custom automation that relies on obscure PSv2 behaviors, or scripts that parsed WMIC’s peculiar output formatting may fail unexpectedly. These are easily missed in quick inventories and can cause scheduled‑task failures in production.

UI artifacts
Community testers report that the new Store‑app removal policy sometimes leaves behind dead Start tiles or shortcuts. Though cosmetic, such glitches undermine user confidence. Pilot deployments should include a structured UI/UX check in addition to functional compatibility testing.

Privacy and on‑device AI considerations
Features like Recall (local snapshot indexing for search) and other AI‑powered enhancements promise productivity gains but raise questions about local data capture, retention, and device migration. Administrators should plan privacy reviews and configure filter lists before enabling AI features broadly on managed devices. Treat these features as opt‑in until organisational policies and compliance reviews are complete.

Strengths and notable positives

  • Low‑disruption upgrades: The enablement package model cuts downtime drastically—one restart versus a lengthy installation.
  • Security‑minded cleanup: Removing PowerShell 2.0 and WMIC reduces the attack surface and eliminates well‑known downgrade and scripting‑abuse vectors.
  • Better enterprise control: The new policy to remove default Store packages gives IT direct authority over image cleanliness, addressing a long‑standing pain point.
  • Incremental polish: Minor UI refinements, File Explorer AI actions, and Click‑to‑Do improvements are quality‑of‑life updates that, when delivered, add value without fanfare.

Shortcomings and risks

  • Not a blockbuster consumer update: 25H2 is more about activation and cleanup than sweeping consumer features. Many end users will find it uninspiring compared with 24H2’s more noticeable additions.
  • Possible fragmentation: Hardware‑gated AI features mean inconsistent experiences across otherwise identical systems.
  • Migration overhead for niche automation: Organizations with heavy WMIC or PowerShell 2.0 dependency will need to invest real effort in remediation. Though the cost is concentrated, it can be non‑trivial for affected teams.

How to get 25H2 now

Insiders can join the Release Preview channel and “seek” the update via Settings → Windows Update. Microsoft plans to publish ISOs and Azure Marketplace images in the coming week to support clean installations and lab testing. Note that community‑reported build numbers (for example, Build 26200.5074) should be treated as indicative; always verify the exact build on your own test devices. While Release Preview implies near‑final code, it remains a validation phase. Deploying to production without a validated pilot is risky.

Final assessment

Windows 11 25H2 is a pragmatic, enterprise‑friendly release that prioritizes stability, manageability, and security hardening over headline consumer features. Delivered as an enablement package, it continues Windows’ evolution toward faster, lower‑impact feature activations. The removal of legacy components—PowerShell 2.0 and WMIC—is an overdue security decision that reduces attack surface but demands disciplined remediation from organizations still dependent on those tools.

For many IT teams, 25H2 will be a low‑friction and beneficial step forward. For those with legacy automation, it is a call to action: inventory and remediation should be treated as top‑priority tasks during the Release Preview validation window. Pilot carefully, plan rollbacks, and treat the eKB enablement as a switch that should only be flipped after the estate is ready.

Windows 11 25H2 cleans house more than it dazzles—and that, for many organizations, is precisely what makes it valuable.