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

 

[ChatGPT]

Microsoft’s quiet September update is doing something few users expected: it’s starting to excise two long‑running legacy administration tools from Windows 11 images — Windows PowerShell 2.0 and WMIC (Windows Management Instrumentation Command‑Line) — as part of the preparation for the 25H2 enablement package and ongoing hardening of the platform. The change is deliberate, broadly signposted by Microsoft earlier this year, and already visible in Insider preview builds; for administrators and organizations that still rely on these tools the result will be an operational sprint to inventory, test, and remediate old automation. (support.microsoft.com)

---

Background / Overview​

PowerShell 2.0 first shipped in 2009 and was a watershed for Windows automation: remoting, modules, jobs and richer scripting arrived with it. Microsoft formally deprecated PowerShell 2.0 years ago and left it in images as an optional compatibility feature to avoid breaking legacy scripts and installers. WMIC likewise has been on a long deprecation path — a command‑line wrapper for WMI that enterprises used for quick inventory and management tasks, but which the PowerShell CIM/WMI cmdlets superseded. Microsoft’s rationale for removing both is straightforward: these binaries are legacy attack surface, complicate testing and maintenance, and no longer align with modern security telemetry and detection capabilities. (support.microsoft.com)
Microsoft documented the PowerShell 2.0 removal in a formal support bulletin (KB ID 5065506) published August 11, 2025, and confirmed the change is present in Insider builds. The more visible, end‑user‑facing step came as Windows 11, version 25H2 was released to the Release Preview Channel as an enablement package layered on top of 24H2; 25H2 explicitly lists the removals as part of a smaller, stability‑focused update rather than a feature‑heavy rebase. The September cumulative update (KB5065426) and the 25H2 enablement packaging are both pieces of that servicing work. (support.microsoft.com)

---

What exactly changed — technical specifics​

The two components being removed or disabled​

• Windows PowerShell 2.0 (the legacy v2 engine)
• The v2 engine is being removed from shipping Windows images and will not be present as an optional in‑box feature on new images of affected releases. If a script or process explicitly requests the v2 runtime (for example, launching powershell.exe -Version 2), that invocation will no longer start the legacy engine and will fall back to whatever default PowerShell runtime exists on the system (typically Windows PowerShell 5.1) or fail if no suitable runtime is available. Microsoft published an official KB with mitigation guidance. (support.microsoft.com)
• WMIC (wmic.exe)
• The WMIC command‑line front end is deprecated and being removed from shipping images. Microsoft expects administrators to migrate to PowerShell WMI/CIM cmdlets (Get‑CimInstance, Invoke‑CimMethod, etc.) or to use programmatic WMI/CIM APIs instead. WMIC’s deprecation and staged disablement had been visible across Insider rings for months before final removal. (blogs.windows.com)

Timeline and scope​

• Microsoft first published the PowerShell 2.0 removal guidance as KB 5065506 on August 11, 2025; the policy states removal begins in August 2025 for Windows 11 version 24H2 and in September 2025 for Windows Server 2025. Insider preview builds reflected the change as early as July 2025. (support.microsoft.com)
• Windows 11 version 25H2 (delivered as an enablement package) entered Release Preview in late August 2025 and lists the removals (PowerShell 2.0 and WMIC) among its changes; the servicing model means removal will be toggled on in-place for devices in scope. (blogs.windows.com)

Important note on KB numbers: some coverage and blogs referenced the September cumulative update (KB5065426) that ships as part of the September servicing cadence. The technical removal of the legacy PowerShell engine is described in KB5065506; KB5065426 is the September cumulative package for the OS. Readers should not rely on a single KB number reported in secondary articles without checking Microsoft’s support entries for the authoritative guidance. (support.microsoft.com)

---

Why Microsoft is removing them — security and maintainability​

• Security (primary driver)
  PowerShell 2.0 predates modern defensive primitives: it lacks AMSI integration, robust script block logging, Constrained Language support and many telemetry hooks that defenders and EDR solutions rely on. That makes the v2 engine a downgrade vector attackers can exploit to evade detection. WMIC, similarly, is a well‑known living‑off‑the‑land tool that threat actors reuse for enumeration and lateral movement. Removing these legacy binaries reduces predictable attack vectors. (support.microsoft.com)
• Maintainability and complexity reduction
  Shipping multiple in‑box runtimes increases test surface, complicates module compatibility and imposes long‑tail maintenance costs. Consolidating on supported, observable runtimes (Windows PowerShell 5.1 for legacy Windows‑tied scenarios and PowerShell 7.x for modern cross‑platform automation) simplifies development and support. (support.microsoft.com)
• Ecosystem clarity
  By removing legacy artifacts, Microsoft signals to ISVs and admins which runtimes to target going forward. This reduces fragmentation in the ecosystem and encourages migration to cmdlet‑based automation that’s easier to audit and secure. (blogs.windows.com)

---

Who will be affected — real impact assessment​

Most consumer devices and modern business deployments will see little or no day‑to‑day change: modern scripts use PowerShell 5.1 or PowerShell 7.x, and mainstream tools have already migrated away from WMIC. But the pain points are real and concentrated:

• Environments that still run scripts or installers that explicitly request powershell.exe -Version 2 will either have those invocations fallback to a different runtime or fail entirely. Those are the highest‑risk breakages.
• Legacy installers that check for an in‑box PowerShell 2.0 feature (registry checks, file presence checks) may fail if the expected artifact is absent.
• Lightweight monitoring or ad‑hoc inventory scripts that use wmic.exe to parse quick results will break until rewritten to use PowerShell CIM/WMI cmdlets or updated tooling that calls WMI APIs.
• Embedded or specialized appliances, older management suites, and some OEM imaging workflows can be surprised by the change if they relied on the preinstalled components.

Independent reporting and community experience from Preview rings show the impact is localized but non‑zero; organizations must treat this as a planned compatibility cutoff and act accordingly. (windowscentral.com)

---

Practical, step‑by‑step guidance for IT teams​

1. Inventory: find where PowerShell v2 or WMIC are used​

• Search code repositories, configuration management scripts, scheduled tasks and packaged installers for these patterns:
• powershell.exe -Version 2
• wmic.exe
• Registry checks for HKLM:\Software\Microsoft\Windows\PowerShell\1\PowerShellEngine (legacy detection)
• On endpoints, run elevated checks:
• Check optional feature state (client):
• Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2
• Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root
• On servers, check Windows feature:
• Get-WindowsFeature PowerShell‑V2
• Quick DISM check:
• Dism /online /Get-Features | findstr /i PowerShellV2
  These commands and feature names are the documented, canonical way to detect v2 components. (devblogs.microsoft.com)

2. Test: run scripts under supported runtimes​

• Remove explicit -Version 2 invocations and test the scripts with:
• Windows PowerShell 5.1 (wins the broadest backwards compatibility with Windows features)
• PowerShell 7.x (recommended for new automation; install the latest supported 7.x and test for module compatibility)
• For WMIC scripts, translate to CIM/WMI PowerShell cmdlets:
• Replace wmic path win32_operatingsystem get caption with Get‑CimInstance -ClassName Win32_OperatingSystem and parse the object model rather than brittle text output.
• Use continuous integration to run regression tests against 24H2 images (or 25H2 Release Preview) to catch runtime differences early.

3. Remediate and modernize​

• Replace WMIC text‑parsing scripts with structured PowerShell cmdlets (Get‑CimInstance, Get‑WmiObject where compatibility is required, or use CIM sessions for remote operations).
• Update installers to not depend on a legacy v2 registry key; instead check for a supported runtime or require the presence of %windir%\system32\WindowsPowerShell\v1.0\powershell.exe.
• For appliances or third‑party software that require v2, engage vendors for updated builds; if vendors can’t update, consider containment strategies (dedicated legacy images, virtual machines) while migrating.

4. Policy and automation​

• Use Group Policy, MDM, and scripting to remove the feature proactively from test images to expose breakages before the servicing flag flips in production.
• Add detection rules to vulnerability scanners and baseline audits to identify residual dependencies (CIS/Tenable checks commonly include PowerShell v2 detection).

---

Quick remediation recipes (commands)​

• Check for PowerShell v2 (client):
• Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2
• Disable PowerShell v2 now (if you want to proactively remove it):
• Dism /online /Disable-Feature /FeatureName:MicrosoftWindowsPowerShellV2Root
• Replace a WMIC query with a CIM cmdlet:
• Old: wmic /node:server os get caption
• New: Get-CimInstance -ComputerName server -ClassName Win32_OperatingSystem | Select-Object -ExpandProperty Caption

These commands are widely documented in Microsoft’s PowerShell team guidance and community audit checklists. Test them in a lab before rolling them enterprise‑wide. (devblogs.microsoft.com)

---

Strengths of Microsoft’s approach — what this cleanup delivers​

• Reduced attack surface: removing binaries attackers know and reuse stops a class of downgrade tricks and makes defense simpler.
• Clear migration path: PowerShell 5.1 remains in many Windows SKUs and PowerShell 7.x is available for modern automation, so organisations have supported alternatives.
• Operational efficiency: enablement‑package deployment and shared servicing branches reduce upgrade friction for mainstream customers.
• Encourages modernization: moving from text‑parsing CLI tools to structured cmdlets or APIs yields more maintainable and auditable automation.

These are defensible, well‑argued objectives that align with modern security and lifecycle practices. (support.microsoft.com)

---

Risks and potential pitfalls — what to watch for​

• Silent breakage: some installers or legacy scheduled tasks call the v2 engine implicitly; fallback to 5.1 may not preserve exact behavioral semantics, producing failures that are hard to trace unless you’ve inventoried usage.
• Third‑party dependencies: vendor products (older management agents, older versions of Microsoft server products) may implicitly rely on v2. Those dependencies can be expensive to remediate if vendors are no longer supporting older builds.
• Inconsistent rollouts: because the change is being delivered as part of servicing and enablement packaging, some devices (upgraded in‑place vs freshly imaged) may retain v2 binaries longer — creating a heterogeneous estate that complicates testing and incident response.
• Operational blind spots: ad‑hoc scripts on jump boxes, consultants’ toolkits, and undocumented automation are the likely vectors of surprise failures.

Administrators should assume the removal is permanent for new images and treat any lingering v2 presence as legacy technical debt to be eliminated. (windowscentral.com)

---

Strategic view: a larger refactor of Windows​

This cleanup is not merely cosmetic housekeeping. Removing long‑lived legacy engines enables deeper refactoring inside Windows: less code to test, fewer compatibility constraints, and a smaller attack surface to maintain. Microsoft’s move to shipping 25H2 as an enablement package and to give administrators more control over preinstalled apps and AI features is consistent with a strategy of modularizing the platform and reducing default feature bloat. That trend gives large organizations better control — but it also forces them to take responsibility for the migration work. (blogs.windows.com)

---

What readers should do this week — a prioritized checklist​

• Inventory: run repository and endpoint searches for powershell.exe -Version 2 and wmic.exe usage.
• Test: pick a pilot group and validate critical automation against PowerShell 5.1 and PowerShell 7.x.
• Remediate: convert WMIC scripts to Get‑CimInstance and update installer checks to detect supported PowerShell runtimes.
• Vendor outreach: contact ISVs for supported builds if their products rely on v2.
• Schedule: coordinate a remediation sprint so that production imaging and deployments use tested, updated artifacts before 25H2 is enabled in your servicing channel.
  Following these steps will convert a forced migration into a modernization opportunity. (support.microsoft.com)

---

Caveats and unverifiable or evolving points​

• Several publications and blogs referenced different KB numbers in early coverage. The authoritative Microsoft entry that describes the PowerShell 2.0 removal is KB 5065506 (published August 11, 2025), while the September cumulative update package for the OS carries KB 5065426. Confusion in the press about which KB “caused” removals is understandable; administrators should rely on Microsoft’s support articles and the Windows Insider blog for authoritative timelines. If a third‑party article cites a different KB than Microsoft’s support statements, treat that claim cautiously and confirm against Microsoft’s bulletin. (support.microsoft.com)
• Microsoft’s servicing model (enablement package for 25H2 layered on 24H2) means the visual manifestation of removals can differ between fresh images, in‑place upgrades, and devices that skipped certain servicing windows. The behavior of an individual device depends on its update history. Test on representative images. (blogs.windows.com)

---

Final analysis — balancing security, risk, and effort​

This cleanup is the kind of technical debt reduction security teams usually ask for: it removes a well‑known downgrade vector and nudges the ecosystem toward observable, auditable automation. The benefits to telemetry, forensic visibility, and reduced maintenance burden are real. However, the operational cost will be front‑loaded and concentrated: small organizations with few legacy scripts will barely notice; large enterprises with decades of accumulated, ad‑hoc tooling must prioritize and execute migrations now rather than later.
The pragmatic path for most IT teams is clear: treat the removal as scheduled, inventory aggressively, automate testing, and use remediation sprints to modernize tooling. Doing so will reduce future incident response complexity and align estates with supported, secure automation runtimes.
Microsoft’s removal of PowerShell 2.0 and WMIC is a strategic, security‑first step with sensible technical rationale — but it’s also a call to action. Administrators have a finite runway: use it to inventory, test, and modernize before the servicing flag flips across your estate. (support.microsoft.com)

---

Conclusion
The September servicing window and the 25H2 enablement package mark a defined turning point: Microsoft is now actively pruning legacy administration tools from Windows images to simplify the platform and reduce risk. For defenders and platform owners that is good news; for administrators still anchored to ancient scripts it is a predictable, urgent migration task. Inventory first, test widely, migrate to PowerShell 5.1 or 7.x and to PowerShell CIM/WMI cmdlets, and coordinate vendor updates — that sequence will minimize disruption while capturing the security benefits of a smaller, cleaner Windows image. (support.microsoft.com)

---

Source: Red Hot Cyber Goodbye PowerShell 2.0 and WMIC! The great Windows 11 cleanup has begun.

 

[ChatGPT]

Microsoft’s recent servicing work quietly strips two long‑standing legacy administration tools — Windows PowerShell 2.0 and WMIC (wmic.exe) — from new Windows 11 images and from the 25H2 enablement cycle, a change Microsoft documents in its formal support bulletin (KB 5065506) and that is already visible in Insider preview builds. (support.microsoft.com)

Background​

PowerShell 2.0 arrived in 2009 and for many years served as the default automation engine for Windows administrative tasks. Microsoft deprecated the v2 engine in 2017, keeping the runtime in images as a compatibility concession for legacy scripts and installers. Over time, security teams and product groups flagged v2 as a persistent downgrade vector because it predates modern telemetry and defensive primitives such as AMSI, script block logging, transcription, and constrained language mode. The formal removal is the culmination of that deprecation path. (support.microsoft.com)
At the same time WMIC, a command‑line front end to WMI used for quick inventory and management tasks, has been on a long deprecation path and is being excised for similar reasons: it increases legacy attack surface and has largely been superseded by PowerShell’s CIM/WMI cmdlets. (blogs.windows.com)

---

What exactly changed​

The technical shift in images and servicing​

• Microsoft published the removal guidance under KB 5065506, with an original publish date of August 11, 2025. The KB states the removal begins for Windows 11, version 24H2 (rolling into later builds) starting August 2025, and for Windows Server 2025 in September 2025. Insider preview builds showed the PowerShell 2.0 feature removed as early as July 2025. (support.microsoft.com)
• Windows 11, version 25H2 is being delivered as an enablement package (an eKB) layered on top of the 24H2 servicing branch. That enablement package flips feature flags rather than replacing the entire OS image — a delivery model that makes it practical to remove legacy components from new shipping images while minimizing upgrade downtime. The 25H2 Release Preview notes explicitly list the removals (PowerShell 2.0 and WMIC). (blogs.windows.com)

Practical effect for admins and power users​

• For clean installs and newly imaged systems based on the affected releases, the PowerShell 2.0 engine will not be present as an optional in‑box feature. Scripts or processes that explicitly request the v2 runtime (for example: powershell.exe -Version 2) will no longer be able to start the legacy engine. In many cases the OS will fall back to the default installed Windows PowerShell runtime (typically PowerShell 5.1) or to another available pwsh runtime, but fallback is not a guaranteed compatibility fix for all edge cases. (support.microsoft.com)
• For in-place upgraded systems the binary may remain until reimaging or until a future update explicitly removes it. Insider rings already show the component absent in preview images, so organizations running Insider builds have had an early look at compatibility impacts. (support.microsoft.com)

---

Why Microsoft removed these components — security and maintainability​

The rationale Microsoft states — and that independent reporting echoes — clusters into three themes:

• Security hardening: PowerShell 2.0 was designed before AMSI and modern script‑level logging were introduced. Attackers have historically leveraged older engines to bypass defenses; removing v2 closes a persistent downgrade path. WMIC has also been widely misused in living‑off‑the‑land attacks. (support.microsoft.com)
• Ecosystem simplification: Supporting multiple in‑box runtimes complicates testing for Microsoft and third‑party module authors. Consolidation around PowerShell 5.1 (for Windows‑tied compatibility) and the cross‑platform PowerShell 7.x (pwsh.exe) reduces fragmentation. (learn.microsoft.com)
• Technical debt reduction: Old CLR hosting patterns and legacy binaries increase maintenance overhead. Removing rarely used legacy code reduces image size and long‑tail engineering costs. (support.microsoft.com)

These drivers are defensible: removing code that weakens telemetry and offers attackers downgrade options is a measurable security win. The tradeoff is operational: customers with genuinely required legacy dependencies now have a fixed migration horizon.

---

Who will notice — risk profile and edge cases​

Most modern desktops, laptops, and managed enterprise fleets will see little or no impact. Standard automation in the last decade has moved to PowerShell 3.x and later, and many toolchains already use PowerShell 7.x.
The groups that need immediate attention are predictable:

• Environments with legacy scripts, installers, or scheduled tasks that explicitly call powershell.exe -Version 2.
• Applications or installation routines that check for the presence of the optional PowerShell v2 feature during setup.
• Old monitoring, inventory, or deployment tooling that invokes wmic.exe in scripts, scheduled jobs, or agents.
• Appliances or line‑of‑business servers that internally host the PowerShell v2 runtime or expect specific v2 behavior.

For those scenarios, behavior can vary from silent fallback to 5.1 (which may still work) to explicit failures or subtle logic errors. Administrators must treat this change as a compatibility sprint rather than as a purely security-only patch. (support.microsoft.com)

---

Audit and detection — how to find dependencies​

Inventory first. The fastest way to avoid surprises is to detect where your estate still relies on the old tools.

• Check whether the v2 optional feature is present on a machine:
• Client (desktop) optional feature:
• Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2
• Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root
• Server feature (Server SKUs):
• Get-WindowsFeature PowerShell‑V2
• DISM alternative:
• Dism /online /Get-Features /format:table | find "MicrosoftWindowsPowerShellV2Root"

These are the canonical inspection commands used by admins.

• Search repositories and file shares for explicit invocations and calls. Example PowerShell search (run from a build server or repository root):
• Search scripts for explicit v2 invocations:
• Get-ChildItem -Recurse -Include .ps1,.bat,.cmd,.psm1 | Select-String -Pattern "powershell.exe.-Version\s2" -List
• Search for WMIC usage:
• Get-ChildItem -Recurse -Include .ps1,.bat,.cmd,.psm1 | Select-String -Pattern "\bwmic\b" -List
• Audit scheduled tasks, services and installer logs for command lines that reference powershell.exe -Version 2 or wmic.exe. Use Task Scheduler PowerShell queries or examine exported task XML for command lines.

If visibility into end‑user devices is limited, prioritize servers, management hosts, deployment servers, build agents, and images used to create new machines. Quieter consumer endpoints are less likely to host legacy automation, but corporate images and staging VMs are common trouble spots.

---

Remediation and migration guidance — a practical checklist​

Below is a prioritized plan IT teams can follow to reduce risk and operational friction.

• Inventory
• Run the feature checks and script searches above.
• Identify installers and vendor apps that check for v2 or call WMIC.
• Prioritize
• Classify findings by criticality: production servers and deployment infrastructure first, developer images and test machines later.
• Test
• On isolated test images that mirror production, uninstall or emulate the removal and run automation and installers to find failures.
• Use the Windows 11 Release Preview/Insider channel to validate behavior for your workloads. (blogs.windows.com)
• Migrate
• Replace WMIC calls with PowerShell CIM/WMI cmdlets. Example:
• Old WMIC: wmic logicaldisk get name,size,freespace
• Replacement: Get-CimInstance -ClassName Win32_LogicalDisk | Select-Object DeviceID,Size,FreeSpace
• Replace explicit v2 invocations with either:
• Remove the “-Version 2” flag so scripts run under the default engine (test vigorously), or
• Rewrite to modern PowerShell cmdlets and target PowerShell 7.x where cross‑platform modern behavior is desired.
• Vendor engagement
• Reach out to ISVs and third‑party vendors running installers that reference v2 or WMIC. Request updated installers or guidance.
• Contingency options
• For a small set of unfixable legacy appliances, consider:
• Reimaging to a supported baseline that includes the older code (temporary, not long‑term),
• Running legacy tooling inside a hardened VM or container where v2 remains available but isolated from production endpoints.
• Communicate and document
• Notify stakeholders and service owners of the timeline and testing windows.
• Update runbooks and incident playbooks for any changes in behavior.

These steps reflect vendor guidance and common migration best practices promoted across the community. (support.microsoft.com)

---

Concrete replacements — WMIC → PowerShell examples​

WMIC was often used for short, one‑line queries. Replacing commands is usually straightforward.

• Example: replace querying logical disks
• WMIC:
• wmic logicaldisk get DeviceID,Size,FreeSpace
• PowerShell (CIM):
• Get-CimInstance -ClassName Win32_LogicalDisk | Select-Object DeviceID,Size,FreeSpace
• Example: system product info
• WMIC:
• wmic computersystem get manufacturer,model
• PowerShell:
• Get-CimInstance -ClassName Win32_ComputerSystem | Select-Object Manufacturer,Model

The CIM cmdlets are well documented, return structured objects, and integrate cleanly into automation pipelines — a functional and security improvement over string‑parsing WMIC output.

---

Enterprise deployment advice — timelines and channels​

• Use the Release Preview Channel (25H2 eKB) and staging rings to validate changes before broad rollout. The 25H2 enablement package flips features on quickly for devices already on 24H2, which accelerates testing. (blogs.windows.com)
• Control rollout with familiar tooling:
• Windows Update for Business or WSUS for phased delivery.
• Feature management via Group Policy and MDM CSP to control preinstalled apps (25H2 adds a policy for removing selected Microsoft Store apps on Enterprise/Education devices). (blogs.windows.com)
• Consider imaging strategy: since new shipping images will omit the legacy binaries, update gold images and deployment pipelines early to avoid surprises when new machines are created.

---

Strengths of Microsoft’s approach​

• Measured security improvement: removing a runtime that lacks modern telemetry reduces a clear downgrade vector attackers have abused.
• Predictable timeline: publishing KB guidance and reflecting the change in Insider builds allows enterprises to test and plan.
• Small update footprint: the enablement package model makes activation fast on devices already at 24H2, reducing operational downtime during validation. (support.microsoft.com)

---

Risks and potential downsides​

• Compatibility friction: some organizations will find hard dependencies that require non-trivial fixes, particularly installers or third‑party tools no longer maintained.
• Operational hidden costs: time spent auditing, testing, and rewriting legacy automation is real cost and can compete with other priorities.
• False sense of invisibility: while most environments are unaffected, failures may be subtle — e.g., a scheduled maintenance script that silently skips steps under PowerShell 5.1 — so complacency is risky.

Where claims in press coverage suggest immediate breakage for all users, treat those as overstated; the authoritative KB and Insider notes describe a staged, image‑level removal and clearly recommend migration rather than implying spontaneous systemwide failure. Always verify by testing critical workloads. (support.microsoft.com)

---

Quick checklist for a 48‑hour triage​

• Run the feature presence checks on a sample of images (see Audit section).
• Search your code repositories and deployment servers for "-Version 2" and "wmic".
• Identify and flag any installers that query for the v2 feature during setup.
• Test critical scripts against PowerShell 5.1 and pwsh 7.x in an isolated lab.
• Communicate the timeline to application owners and vendors.

---

Final assessment​

Microsoft’s removal of PowerShell 2.0 and WMIC from new Windows 11 images and from the 25H2 servicing activation is a security‑forward and maintenance‑driven decision that modernizes the platform’s default baseline. For most modern environments the change will be unobtrusive; for a minority — those with decades‑old automation or unmaintained third‑party installers — this change will require targeted engineering work.
The practical takeaway is simple and urgent: inventory first, test quickly, and remediate where necessary. Use the PowerShell CIM cmdlets and PowerShell 7.x for modernization, and lean on the Release Preview channel and phased deployment tooling to avoid surprises. Microsoft’s KB guidance and the Release Preview notes provide the authoritative timeline and behavior details that should drive enterprise planning. (support.microsoft.com)

---

The removal marks a clear moment in Windows platform modernization — a pragmatic tradeoff that tightens security and reduces long‑term maintenance burden at the cost of short‑term migration effort for environments still tethered to legacy tooling.

---

Source: HotHardware Windows 11 Patch Deletes PowerShell 2.0 And One More App Power Users Will Miss