Windows 11 25H2 Removes PowerShell 2.0 and WMIC: Migration Guide

Microsoft’s September servicing quietly removes two long‑standing administration tools — the legacy Windows PowerShell 2.0 engine and the WMIC (Windows Management Instrumentation Command‑line) tool — from certain Windows 11 images, a deliberate security‑first move that closes well‑documented downgrade vectors but also forces real migration work for organizations and power users that still depend on those utilities. (support.microsoft.com)

Background​

Microsoft announced that the 2025 annual Windows 11 update (version 25H2) is being delivered as an enablement package layered on top of the 24H2 servicing branch rather than as a full OS rebase. That deployment model flips feature flags on already‑shipped binaries and reduces upgrade downtime, but it also marks the moment when Microsoft will excise some legacy components from shipping images — notably PowerShell 2.0 and WMIC. (blogs.windows.com)
The removal is not a surprise: Microsoft formally deprecated Windows PowerShell 2.0 years ago and documented the eventual removal in a support bulletin (KB ID 5065506) published August 11, 2025. The KB states the removal begins with Windows 11, version 24H2 (rolling into later builds) and for Windows Server 2025 in September 2025, and it recommends migration to supported runtimes (Windows PowerShell 5.1 or PowerShell 7.x). (support.microsoft.com)
At a practical level, this change affects shipping images and new installs. Systems upgraded in‑place may or may not retain the binary until reimaging or until an update specifically removes it; Insider preview builds already show the component removed in July 2025. Microsoft and independent reporting emphasize that most modern environments will feel little day‑to‑day difference — but any environment that explicitly invokes PowerShell v2 or scripts that call wmic.exe must remediate. (support.microsoft.com)

---

What was removed — technically and practically​

PowerShell 2.0 engine​

• What it is: Windows PowerShell 2.0 is the legacy PowerShell engine introduced in 2009 that delivered early automation and remoting capabilities. It was deprecated in 2017 but remained available for compatibility. (support.microsoft.com)
• What Microsoft changed: the PSv2 engine will no longer be included in new shipping Windows 11 and Windows Server images starting with the 2025 servicing cycle. Calls that explicitly request the legacy runtime (for example, powershell.exe -Version 2) will not be able to start the v2 engine; Windows will instead start the default installed PowerShell runtime (typically Windows PowerShell 5.1) or another available runtime. (support.microsoft.com)

WMIC (wmic.exe)​

• What it is: WMIC is a classic command‑line front end for WMI that many scripts, monitoring tools, and installers historically used to query system inventory and configuration.
• What Microsoft changed: WMIC is deprecated and being removed from shipping images. Microsoft’s guidance is to use the PowerShell WMI/CIM cmdlets (for example, Get‑CimInstance, Invoke‑CimMethod) or programmatic WMI/CIM APIs instead. The removal helps reduce the living‑off‑the‑land risk where attackers reuse built‑in binaries for malicious activity. (blogs.windows.com)

---

Why Microsoft removed these tools: the security and maintainability argument​

Microsoft’s stated rationale has three core pillars: security, ecosystem simplification, and technical debt reduction.

• Security: PowerShell 2.0 predates modern defensive primitives such as AMSI (Anti‑Malware Scan Interface), script block logging, transcription, Constrained Language Mode, and other telemetry hooks that defenders rely on. The older engine provides a downgrade path attackers have used to bypass newer detection features. Similarly, WMIC has long been abused by threat actors to enumerate systems and execute living‑off‑the‑land techniques. Removing these binaries reduces the attack surface and removes a predictable toolset adversaries frequently rely on. (support.microsoft.com)
• Ecosystem simplification: Shipping fewer in‑box runtimes makes testing and compatibility easier for Microsoft and third‑party module authors. Consolidating on supported runtimes (PowerShell 5.1 on Windows and PowerShell 7.x cross‑platform) reduces the burden of validating behavior across multiple legacy engines. (support.microsoft.com)
• Technical debt reduction: Old runtime hosting behaviors and legacy CLR dependencies complicate maintenance. Trimming seldom‑used components reduces long‑tail support overhead and allows Microsoft to focus on a smaller, more secure base image.

These reasons are defensible from an enterprise security posture perspective: removing known downgrade vectors is a direct way to stop a class of evasion techniques. However, the operational reality is that removal equals migration work, and that work has cost and risk.

---

Who will be affected — and how badly​

• Most consumer PCs and modern corporate endpoints that use modern scripts and management tools will be effectively unaffected.
• Organizations with legacy line‑of‑business scripts, installers, imaging pipelines, or monitoring agents that call powershell -version 2 or wmic.exe will face breakage until they remediate.
• ISVs and third‑party tools that rely on WMIC output or the PSv2 runtime may need updates from vendors.
• Imaging and deployment teams must treat new ISOs and enablement packages as potentially different images — Microsoft even delayed ISO publication for 25H2 briefly, underscoring the operational impact of the change. (blogs.windows.com)

---

Practical migration and remediation guide (operational playbook)​

The removal is manageable if treated as a discrete migration project. The following is a recommended, prioritized playbook for IT teams and power users.

1. Inventory and discovery (week 0–1)​

• Scan repositories, deployment scripts, scheduled tasks, installers, and management tooling for:
• Calls to powershell.exe -version 2 or powershell -v 2
• Executions of wmic or wmic.exe
• Legacy installers that check for PSv2 presence
• Tools that help:
• Search in source control for strings like -Version 2 and wmic
• Use endpoint telemetry / EDR query features to find processes invoking wmic.exe in the last 90 days
• Outcome: prioritized inventory of scripts and systems that require changes.

2. Quick win: convert common WMIC queries to CIM/WMI cmdlets​

• Replace WMIC disk query:
• WMIC old: wmic logicaldisk get name,size,freespace
• PowerShell replacement: Get-CimInstance -ClassName Win32_LogicalDisk | Select-Object DeviceID,Size,FreeSpace
• Replace WMIC process query:
• WMIC old: wmic process where name='notepad.exe' get processid
• PowerShell replacement: Get-CimInstance -ClassName Win32_Process -Filter "Name='notepad.exe'" | Select-Object ProcessId
• Replace WMIC OS query:
• WMIC old: wmic os get Caption,Version,BuildNumber
• PowerShell replacement: Get-CimInstance -ClassName Win32_OperatingSystem | Select-Object Caption,Version,BuildNumber
• These replacements return object output that is easier to script against and more robust in modern automation pipelines.

3. Migrate PowerShell v2 scripts to modern runtimes​

• Preferred paths:
• PowerShell 7.x (GA) — cross‑platform, modern CLR (.NET 9/.NET Core), active development; ideal for new automation. PowerShell 7.5 is generally available and recommended for STS scenarios, while PowerShell 7.4 is the current LTS for conservative production deployments. (devblogs.microsoft.com)
• Windows PowerShell 5.1 — still the Windows‑bound, in‑box runtime for many traditional Windows management scenarios (backwards compatible in many cases).
• Migration steps:
• Remove any forced invocation of -Version 2 from scripts.
• Run scripts under PowerShell 5.1 and then under PowerShell 7.x to find behavioral differences (CIM vs. WMI APIs, cmdlet parameter changes, module compatibility).
• Update modules that rely on CLR2 hosted behaviors; prefer supported module versions built for PowerShell 5.1+ or PowerShell 7.
• Testing: Create a simple compatibility matrix (script × runtime) and use automated test harnesses to validate output and error codes.

4. Vendor and product checks (parallel)​

• Pull support matrices from AV/EDR, backup, management, and monitoring vendors to confirm compatibility with PowerShell 7.x and the absence of WMIC.
• For any tools that still rely on WMIC, ask vendors for updated versions or documented workarounds.

5. Pilot and phased rollout (2–6 weeks)​

• Use Windows Insider Release Preview or a small WUfB/WSUS ring to test the enablement package and confirm behavior in representative hardware/software sets. Monitor logs and telemetry daily during the pilot. (blogs.windows.com)
• Maintain rollback and snapshot images for quick recovery if a vendor compatibility issue appears.
• Communicate with helpdesk and prepare triage playbooks for common breakage scenarios (failed scheduled tasks, monitoring gaps).

6. Full deployment and follow‑up​

• Stagger the rollout using rings (pilot → business-critical → broad).
• Track remediation completions in a central ticketing system and schedule revalidation windows.

---

Detection snippets and hands‑on commands​

Use these quick commands to locate likely problem spots:

• Find scripts that explicitly request PowerShell v2 in a directory:
• Get-ChildItem -Path C:\scripts -Recurse -Include *.ps1 | Select-String -Pattern "-Version 2" | Select-Object Path,LineNumber,Line
• Search for WMIC usage in a filesystem:
• Get-ChildItem -Path C:\ -Recurse -Include [I].ps1,[/I].bat,[I].cmd,[/I].psm1 | Select-String -Pattern "wmic" | Select-Object Path,LineNumber,Line
• Test a migration of a WMIC command:
• Get-CimInstance -ClassName Win32_LogicalDisk | Select-Object DeviceID,Size,FreeSpace

These snippets are starting points; scale them with enterprise‑grade discovery tools for cross‑endpoint coverage.

---

Benefits — the upside of removal​

• Reduced attack surface: removing old engines eliminates known downgrade and evasion vectors attackers used to bypass script telemetry and AMSI.
• Cleaner baseline: fewer legacy binaries mean less testing complexity and faster validation cycles for both Microsoft and third‑party developers.
• Modern toolchain alignment: forcing a move to PowerShell 5.1 / 7.x and CIM‑based tooling modernizes automation and makes system inventory output more consistent and object‑oriented.

---

Risks and real‑world downsides​

• Breakage risk: poorly inventoried scripts, unattended scheduled tasks, or third‑party installers could silently fail, causing service or monitoring gaps.
• Vendor readiness: some legacy software vendors may not have updated installers or guidance; forcing enterprises to create fragile workarounds.
• Operational cost: scanning, testing, and rewriting automation takes engineering effort and time — for some environments, the remediation timeline will be measured in weeks or months.
• Perception and change fatigue: admins who have tolerated legacy behavior for years may resent forced migrations, especially when the immediate operational value is low for end users.

Where claims about breakage risk are anecdotal or vary by environment, label them as such and treat each claim as environment‑specific: test, don’t assume.

---

Recommended policies and hardening actions​

• Block or log use of removed binaries where possible: configure EDR or local AppLocker rules to detect or prevent attempts to run wmic.exe on endpoints that should no longer use it.
• Adopt a policy: “No explicit -Version 2 calls” in any automation checklist; enforce via code review.
• Standardize on a supported PowerShell baseline: pick PowerShell 7.x (or 5.1 for legacy compatibility) as the default runtime for new scripts, and document the decision in your internal platform playbook. (devblogs.microsoft.com)
• Use CI pipelines to run sanity checks for scripts against the target runtime and include automated test cases for critical scripts.

---

Timeline, advisories and where to validate facts​

• Microsoft’s support bulletin KB 5065506 (published August 11, 2025) is the canonical statement confirming the removal schedule and the mitigation guidance. (support.microsoft.com)
• The Windows Insider blog post announcing the Release Preview availability of Windows 11, version 25H2 confirms the enablement‑package model and explicitly calls out PSv2 and WMIC removals. (blogs.windows.com)
• Independent outlets (Windows Central, The Verge and others) reported the same changes and discussed ISO timing and rollout nuances; these reports are useful for operational context and show how the community is reacting. (windowscentral.com)

If any claim appears in a vendor blog or community thread but is not mirrored by Microsoft’s KB/blog, treat it as anecdotal and verify with the official support article or vendor guidance.

---

Bottom line: security gain, operational cost​

The removal of PowerShell 2.0 and WMIC from Windows 11 images is a straightforward, defensible security move that reduces attack surface and simplifies the platform baseline. That said, it is not cost‑free: organizations must inventory dependencies, convert WMIC scripts to CIM/WMI cmdlets, and migrate or validate PowerShell v2 scripts against supported runtimes (Windows PowerShell 5.1 or PowerShell 7.x). The technical lift is small for many shops, but for some legacy environments it will require measured effort and careful vendor coordination.
Treat this as an opportunity to modernize automation, bake safer scripting patterns into CI/CD, and remove brittle dependencies on legacy binaries. Follow a disciplined migration program (inventory → convert → pilot → phased rollout) and prioritize remediation in high‑risk, high‑visibility, and compliance‑sensitive systems.

---

Quick checklist (for immediate action)​

• Inventory scripts and automation for -Version 2 and wmic usage.
• Convert common WMIC commands to Get‑CimInstance or equivalent CIM cmdlets.
• Test scripts under PowerShell 5.1 and PowerShell 7.x; prefer PowerShell 7.x for new work. (devblogs.microsoft.com)
• Engage vendors for affected third‑party tools and request updated installers or guidance.
• Pilot the enablement package in a Release Preview ring or a small WSUS/Windows Update for Business ring. (blogs.windows.com)
• Implement monitoring and rollback plans before wide deployment.

---

The change is definitive: Microsoft’s KB and Release Preview announcement codify the removal, and the security case is strong. The practical work now falls to administrators: inventory, test, and migrate. Done methodically, this is a manageable modernization project that measurably hardens an environment against well‑known attacker techniques. (support.microsoft.com)

---

Source: PCWorld Windows 11's September patch secretly deletes two programs. Here's why