Microsoft has quietly pushed Windows 11, version 25H2, into the Release Preview Channel—but don’t expect a parade of shiny consumer features. The update is being delivered as a lightweight enablement package on top of the existing 24H2 servicing branch, which means it activates features Microsoft already shipped earlier rather than introducing a new set of user-facing capabilities. At the same time, Microsoft is removing a couple of long‑standing legacy tools—Windows PowerShell 2.0 and WMIC (wmic.exe)—and adding a new manageability control for IT administrators to remove selected preinstalled Microsoft Store apps on managed Enterprise and Education devices. The upshot: a faster, lower‑impact upgrade path with targeted enterprise controls and a modest compatibility hit for organizations and power users still relying on decades‑old command‑line tooling.
Microsoft’s servicing model has continued to evolve since Windows 10. Rather than shipping fully distinct OS binaries for every annual release, Microsoft often stages feature binaries in monthly quality updates and later flips them on with a small “master switch” known as an enablement package (eKB). That approach was used in several recent updates and is intended to reduce upgrade downtime and risk for both consumers and enterprise fleets.
Windows 11, version 25H2 follows that pattern. The build being tested in the Release Preview Channel is from the 26200 series and is available now to Insiders for validation. Because the eKB approach reuses the same servicing branch as 24H2, the core binary set on a fully updated 24H2 system is effectively the same as 25H2—the eKB simply activates specific features that have been staged and held dormant.
This release also continues a longer trend at Microsoft: quietly cleaning up legacy toolchains and removing old, rarely‑used components that present maintenance or security concerns. PowerShell 2.0 and WMIC have been deprecated for years; 25H2 accelerates their removal from shipping images.
That said, visibility is lower than many enthusiasts expect. The traditional annual update used to be when visible UI changes and big feature announcements arrived. In the enablement‑package era, one must look to incremental releases and staged feature activations throughout the year to locate meaningful new capabilities.
For enthusiasts and general consumers, however, the approach feels muted. Annual version labels no longer guarantee a set of headline features. The public narrative around Windows releases is thus less dramatic, and users looking for visible improvements may be disappointed.
Additionally, by focusing on phased feature activations, Microsoft can more easily reserve certain capabilities for specific hardware classes (for example, AI acceleration on Copilot+ silicon) which can make the overall Windows experience feel fragmented across devices.
However, the move comes with trade‑offs. Power users and organizations with legacy automation will face patching and remediation work. Consumers and enthusiasts looking for a blockbuster annual release will be disappointed by the lack of visible new features.
Operationally, the message is straightforward: treat 25H2 as an opportunity to modernize automation and monitoring, not as a reason to change user experience strategies. Treat Release Preview as the point to validate and remediate, then stage the enablement package thoughtfully in controlled rings. By doing so, organizations can take advantage of faster upgrades while avoiding the common pitfalls that follow when deprecated tools are finally removed from the platform.
Source: Tom's Guide Microsoft's next big Windows 11 25H2 update isn't going to make anyone happy — here's why
Microsoft’s servicing model has continued to evolve since Windows 10. Rather than shipping fully distinct OS binaries for every annual release, Microsoft often stages feature binaries in monthly quality updates and later flips them on with a small “master switch” known as an enablement package (eKB). That approach was used in several recent updates and is intended to reduce upgrade downtime and risk for both consumers and enterprise fleets.Windows 11, version 25H2 follows that pattern. The build being tested in the Release Preview Channel is from the 26200 series and is available now to Insiders for validation. Because the eKB approach reuses the same servicing branch as 24H2, the core binary set on a fully updated 24H2 system is effectively the same as 25H2—the eKB simply activates specific features that have been staged and held dormant.
This release also continues a longer trend at Microsoft: quietly cleaning up legacy toolchains and removing old, rarely‑used components that present maintenance or security concerns. PowerShell 2.0 and WMIC have been deprecated for years; 25H2 accelerates their removal from shipping images.
What 25H2 actually is (and what it is not)
The short answer
- What it is: a minimal, enablement‑package style annual update that activates features already shipped on the 24H2 servicing stream, plus a few manageability changes and legacy removals.
- What it is not: a major consumer‑facing feature dump or a wholesale OS redesign. Users should not expect a large set of new UI features or dramatic visual changes.
Why Microsoft used an enablement package
- Faster upgrades: Because most files are already present, upgrades from 24H2 to 25H2 typically install quickly and require a single reboot instead of a long rebase.
- Simplified servicing: Sharing a servicing branch between 24H2 and 25H2 reduces the number of distinct binary sets Microsoft must maintain and patch monthly.
- Staged feature rollout: Features can be enabled per device, tenant, or hardware class, allowing Microsoft to gate functionality more precisely (especially AI/coprocessor features for specific Copilot+ hardware).
The concrete changes: what shipped in 25H2
No new consumer features — but important housekeeping
For end users on current builds, 25H2 brings little in terms of new visible features. The intent is to keep the user experience stable for consumers and gamers while Microsoft continues to deliver incremental improvements via its continuous innovation pipeline.Two legacy removals that matter
- PowerShell 2.0 removed: Microsoft has removed the PowerShell 2.0 engine from shipping Windows images. PowerShell 2.0 was deprecated years ago and kept only for backward compatibility; its removal reduces legacy attack surface and maintenance burden. Systems and scripts that explicitly request or rely on the PSv2 engine (for example, invoking powershell.exe with -Version 2) will stop working as expected unless remediated.
- WMIC (wmic.exe) deprecated/disabled by default: The classic WMIC utility was previously converted to a Feature on Demand and is now being disabled by default and phased out. Microsoft recommends migrating WMIC uses to PowerShell WMI/CIM cmdlets (Get‑CimInstance, Get‑WmiObject where supported) or programmatic WMI APIs.
New manageability control for Enterprise/Education
25H2 adds a policy-based mechanism that lets IT administrators remove selected preinstalled Microsoft Store packages from managed Enterprise and Education devices via Group Policy or MDM CSP. The control targets inbox Microsoft Store packages at the device level and is aimed at reducing bloat in corporate and school images during provisioning.Why everyday users will barely notice — and why that’s intentional
On a consumer laptop that has been kept up to date with monthly updates, 25H2 will likely be invisible: the binaries were already present, and installing the enablement package generally takes little time and a single restart. Microsoft designed the model to make the yearly label more of a version flag than a disruptive rebase. That reduces downtime and the chance that a large update will break existing applications.That said, visibility is lower than many enthusiasts expect. The traditional annual update used to be when visible UI changes and big feature announcements arrived. In the enablement‑package era, one must look to incremental releases and staged feature activations throughout the year to locate meaningful new capabilities.
Why power users and administrators should pay attention
Although everyday end users will probably be unaffected, power users, sysadmins, and enterprises must treat 25H2 as an operational event:- Script compatibility risk: Any script, scheduled task, installer, or legacy management tool that directly invokes PowerShell 2.0 or WMIC will fail or behave differently after these components are removed or disabled by default.
- Monitoring and agent compatibility: Older inventory and monitoring agents that call wmic.exe for quick queries will need updates, or monitoring dashboards may lose data.
- Provisioning and image hygiene: The new policy to remove default Store apps is helpful for image provisioning, but early validation shows corner cases such as leftover Start menu shortcuts or event log entries that administrators should anticipate.
- Staged features and entitlements: Because some features are gated by hardware or account entitlements (for example, Copilot+ hardware features), devices in the same environment may show different behavior depending on rollout flags and vendor driver state.
Practical compatibility checklist: what to scan and fix before broad deployment
IT teams should treat Release Preview availability as the start of formal validation, not the finish line. The following checklist is a practical, prioritized remediation plan.- Inventory and discovery
- Identify scripts, packages, and installers that explicitly request PowerShell 2.0.
- Locate uses of wmic.exe in scripts, monitoring rules, packaging, and installers.
- Map third‑party vendor agents that rely on WMIC or PSv2.
- Testing and remediation
- Run targeted searches for PSv2 and WMIC usages (example PowerShell searches):
- To find explicit PSv2 invocations:
Get-ChildItem -Path C:\ -Include .ps1,.cmd,.bat,.psm1 -Recurse -ErrorAction SilentlyContinue |
Select-String -Pattern 'powershell.exe\s+(-Version\s2|-v\s2)' -List |
Select Path, LineNumber, Line - To find WMIC usage:
Get-ChildItem -Path C:\ -Include .ps1,.cmd,.bat,.ps1 -Recurse -ErrorAction SilentlyContinue |
Select-String -Pattern '\bwmic\b' -List |
Select Path, LineNumber, Line - Inspect scheduled tasks that might execute PowerShell with version flags:
- Use schtasks /query /fo LIST /v to export tasks and search for “powershell”/“-Version 2”.
- Or use the ScheduledTasks module:
Get-ScheduledTask | ForEach-Object {
$task = $
$task.Actions | Where-Object { $.Execute -match 'powershell' } |
ForEach-Object { [PSCustomObject]@{Task=$task.TaskName; Action=$.Execute; Arguments=$.Arguments} }
} - Validate monitoring and management agents in a pilot group. Confirm inventory, alerting, and configuration tools still return expected data.
- Replace WMIC‑based queries with PowerShell CIM/WMI cmdlets. Example conversions:
- WMIC CPU GET Name,NumberOfCores -> Get-CimInstance -ClassName Win32_Processor | Select-Object Name, NumberOfCores
- WMIC OS GET Caption,Version -> Get-CimInstance -ClassName Win32_OperatingSystem | Select-Object Caption, Version
- Remediation priorities
- Critical infrastructure scripts and installers (patching servers, domain controllers, backup/restore routines).
- Monitoring and security agents (endpoint telemetry, asset inventory).
- Provisioning and image build scripts (Autopilot, PXE installers).
- Peripheral vendor drivers/installers that embed legacy calls.
- Rollout guidance
- Stage in rings: lab → pilot users → broader production.
- Use Windows Update for Business / WSUS to control enablement package rollout where desired.
- For Enterprise and Education, evaluate the new policy for removing default Store apps during provisioning; test for UI artifacts and event log behavior.
Migration guidance and quick fixes
- Target PowerShell 5.1 as the immediate compatibility target if you need a Windows‑hosted engine with broad compatibility. Long‑term modernization should adopt PowerShell 7.x (PowerShell Core) for cross‑platform and security benefits.
- Replace WMIC script fragments with PowerShell CIM/WMI cmdlets or direct WMI queries via supported APIs.
- For stubborn legacy installers that attempt to enable PSv2 during install, check vendor updates or contact the vendor. Some installers may require repackaging or running in compatibility modes.
- If a temporary workaround is required in tightly controlled environments, consider:
- Packaging a supported PowerShell 2.0 engine in a controlled, isolated manner (riskier and not recommended).
- Running the legacy tool inside a controlled virtual machine image that preserves older runtime dependencies.
Risks and trade‑offs: security, fragmentation, and perception
Security and maintenance
Removing PowerShell 2.0 and disabling WMIC by default reduces the legacy attack surface. Both components lack modern mitigation controls and have been used as living‑off‑the‑land binaries by attackers. From a security posture perspective, the removals are a positive step.Compatibility risk
Legacy scripts, installers, and third‑party tooling are the immediate cost of this security gain. Organizations with significant historical baggage in automation and on‑prem tooling will have to remediate or risk breakage.Fragmentation and user perception
The enablement‑package model shrinks the visible bump between annual versions. That’s operationally sensible, but it can frustrate users and buyers who expect a headline new‑feature experience from a yearly Windows release. With Windows 10’s end of support looming, Microsoft might be using this quieter update cycle to accelerate platform consolidation rather than to entice holdouts with a big feature list.Operational complexity for admins
Shared servicing branches simplify patching in one way but increase the need for feature‑state validation. Engineers will spend less time checking binary changes and more time validating enabled features, entitlements, and interactions with third‑party drivers.Timeline, support windows, and the broader context
- Release Preview availability: Microsoft made the 25H2 build available in the Release Preview Channel for validation ahead of general availability later in the fall.
- Expected general availability: Microsoft has signaled the GA rollout will occur in the late‑September to October timeframe; organizations should plan validation and pilot rollouts accordingly.
- Windows 10 end of support: Windows 10 reaches end of support on October 14, 2025. That deadline is a separate pressure point: organizations that must move off Windows 10 will be balancing hardware requirements, image readiness, and compatibility against Microsoft’s quieter, enablement‑first update cadence for Windows 11.
Why Microsoft’s strategy makes operational sense (and why it may disappoint enthusiasts)
From an engineering and servicing perspective, the enablement‑package model is efficient: it reduces upgrade downtime, shrinks patch surface area, and enables Microsoft to gate feature rollouts with far finer control. For enterprises, that’s a win—less user downtime and predictable upgrades.For enthusiasts and general consumers, however, the approach feels muted. Annual version labels no longer guarantee a set of headline features. The public narrative around Windows releases is thus less dramatic, and users looking for visible improvements may be disappointed.
Additionally, by focusing on phased feature activations, Microsoft can more easily reserve certain capabilities for specific hardware classes (for example, AI acceleration on Copilot+ silicon) which can make the overall Windows experience feel fragmented across devices.
Concrete recommendations: what Windows users and IT teams should do now
- Home users and typical consumers:
- You don’t need to rush to install 25H2. If your PC is current on 24H2 and you have no legacy scripts, you can wait for the normal Windows Update rollout.
- If you depend on an older piece of software that hasn’t been updated in years, test it before upgrading.
- Power users:
- Search your user scripts and scheduled tasks for explicit calls to PowerShell 2.0 and wmic.exe. Update or replace those snippets.
- Consider modernizing to PowerShell 7.x where practical.
- IT administrators and enterprises:
- Treat Release Preview as a validation gate. Run the checklist above across your most critical fleets.
- Prioritize compatibility fixes for backup/restore, imaging, monitoring, and security tooling.
- Test the new Group Policy/MDM policy for removing preinstalled Microsoft Store apps in a lab and pilot environment; watch for leftover Start menu artifacts and event log entries.
- Use feature‑ring deployment (pilot → broad) and Windows Update for Business controls to stage the eKB where needed.
- Start remediation of PSv2 and WMIC dependencies now—don’t wait until the last minute.
What’s not in 25H2 (and what remains speculative)
- 25H2 is explicitly not a major feature dump; it will not contain broad UI overhauls or a dramatic new consumer experience.
- Rumors and speculation about a “Windows 12” or a next‑generation OS persist in industry chatter, but those plans are outside the scope of 25H2 and should be treated as unverified until Microsoft provides formal details.
- Microsoft continues to deliver more targeted AI and Copilot‑era features during the year; some of those features remain gated by account entitlements, hardware class, and staged rollouts.
Final analysis: a pragmatic upgrade that’s unsurprising — and strategically sensible
Windows 11 25H2 is the logical next step in Microsoft’s servicing evolution: a lightweight, enablement‑package release that minimizes disruption and keeps the servicing pipeline lean. That model benefits enterprises and administrators who dread large rebase upgrades and long reboots. It also clears technical debt by removing outdated runtime engines and utilities that have lingered for years.However, the move comes with trade‑offs. Power users and organizations with legacy automation will face patching and remediation work. Consumers and enthusiasts looking for a blockbuster annual release will be disappointed by the lack of visible new features.
Operationally, the message is straightforward: treat 25H2 as an opportunity to modernize automation and monitoring, not as a reason to change user experience strategies. Treat Release Preview as the point to validate and remediate, then stage the enablement package thoughtfully in controlled rings. By doing so, organizations can take advantage of faster upgrades while avoiding the common pitfalls that follow when deprecated tools are finally removed from the platform.
Source: Tom's Guide Microsoft's next big Windows 11 25H2 update isn't going to make anyone happy — here's why