WMIC Removal in Windows 11 25H2: Migrate to PowerShell CIM/WMI

Microsoft has begun removing the long‑standing Windows Management Instrumentation Command‑line (WMIC) tool from Windows images — WMIC will be absent by default on new installs and removed for systems upgraded to Windows 11, version 25H2 — and administrators must treat this as a scheduled change, not a surprise outage.

Background​

WMIC (Windows Management Instrumentation Command‑line) is a legacy text‑based front end to the WMI (Windows Management Instrumentation) infrastructure that for decades provided a compact way to query hardware, firmware, services, installed software, and other system inventory details from scripts and command prompts. Over recent years Microsoft has moved WMI interaction toward PowerShell cmdlets (CIM/WMI) and programmatic APIs, and WMIC was converted to a Feature on Demand and deprecated on older server/client builds before being removed from default images.
The official Microsoft support article published with KB ID 5067470 (original publish date: September 12, 2025) confirms WMIC will be removed when upgrading to Windows 11, version 25H2; new installs of 24H2 already omit it by default (it remains optionally installable where offered). Microsoft stresses that only the WMIC tool is removed — the WMI subsystem remains fully supported and accessible via PowerShell, COM/.NET APIs, and other programmatic interfaces.

---

Why Microsoft is removing WMIC (the rationale)​

Microsoft’s public rationale for the removal rests on three practical pillars:

• Security: WMIC is a living‑off‑the‑land tool that attackers can reuse for reconnaissance and lateral movement, and the legacy binary lacks integration with modern defensive telemetry that PowerShell and newer interfaces provide. Removing rarely needed binaries reduces predictable attacker tooling available on systems by default.
• Maintainability and complexity reduction: Keeping legacy in‑box command utilities increases test surface and long‑term maintenance burden. Consolidating to supported, observable interfaces simplifies testing and the security model for the platform.
• Ecosystem clarity: By removing deprecated binaries Microsoft signals that administrators and ISVs should target PowerShell CIM/WMI cmdlets (Get‑CimInstance, Invoke‑CimMethod, etc.) or programmatic APIs for automation going forward.

These reasons aren’t new: Microsoft documented WMIC’s deprecation years earlier and began making it optional in recent Windows 11 images; the 25H2 enablement cycle is the moment the company has chosen to finalize its removal from default images. Independent coverage and product blogs corroborate that 25H2 (delivered as an enablement package layered on 24H2) flips feature flags and includes this change.

---

What changes — the technical specifics​

What is removed, and what remains​

• Removed: the WMIC command‑line binary (wmic.exe) as a default in‑box tool applied to new 25H2 images and toggled off on systems upgraded to 25H2. It may still be offered as a Feature on Demand in some servicing channels for a time, but Microsoft’s guidance is to migrate away rather than rely on continued optional availability.
• Not removed: Windows Management Instrumentation (WMI) itself — the underlying management infrastructure remains intact and fully usable via PowerShell CIM/WMI cmdlets, COM APIs, .NET (System.Management), and other programmatic paths. Any capability previously available through WMIC is still accessible through these supported interfaces.

Deployment surface and timing​

• New installs of Windows 11, version 24H2: WMIC is already removed by default (it’s only installable as an optional feature where the FoD is available).
• Upgrades to Windows 11, version 25H2: WMIC will be removed as part of the upgrade process when the enablement package flips the configuration. Devices upgraded in place may see WMIC removed during the upgrade; behavior for in‑place systems patched across servicing cycles can vary (test to confirm in your environment).
• Insider preview and early signals: preview rings showed WMIC being disabled or removed months earlier; the enablement package model explains why the change is mostly a packaging/feature flag decision rather than shipping brand‑new binaries.

---

Immediate impact for administrators and tooling​

For most modern environments the day‑to‑day impact will be minimal: the functionality of WMI is unchanged and PowerShell provides equivalent or richer capabilities. However, there are practical areas where the change matters:

• Scripts, scheduled tasks, installers, monitoring agents, and vendor tools that call wmic.exe will fail on systems that no longer have the binary present. Those items must be identified and migrated or re‑packaged.
• Remote management and ad‑hoc queries historically done at the command prompt with wmic (for example, collecting serial numbers, listing installed hotfixes, or enumerating running processes) must shift to PowerShell or programmatic equivalents.
• Bulk automation tools that relied on wmic in batch files must be rewritten or wrapped to invoke PowerShell CLI calls or use WMI APIs directly.

Independent reporting and Microsoft’s own guidance emphasize inventoring and remediation — organizations with decades of ad‑hoc admin scripts have non‑trivial migration work ahead, whereas most new scripts should target PowerShell 7.x or Windows PowerShell 5.1 depending on compatibility requirements.

---

Practical migration guidance (step‑by‑step)​

The recommended approach follows a common, pragmatic sequence: Inventory → Convert → Test → Pilot → Rollout.

• Inventory
• Scan your estate for usage of wmic.exe and explicit PowerShell invocations of -Version 2. Search scheduled tasks, logon scripts, GPO/Startup scripts, custom installers, monitoring checks, and vendor tools. Prioritize internet‑facing systems, domain controllers, and critical servers.
• Use simple file/command searches, endpoint telemetry, and source control to find references.
• Convert
• Replace common WMIC invocations with PowerShell CIM/WMI cmdlets. Examples:
• WMIC: wmic path win32_process get Name
  PowerShell: Get-CimInstance Win32_Process | Select-Object Name
• WMIC: wmic bios get serialnumber
  PowerShell: Get-CimInstance Win32_BIOS | Select-Object SerialNumber
• WMIC: wmic logicaldisk get caption,freespace,size
  PowerShell: Get-CimInstance Win32_LogicalDisk | Select-Object DeviceID,FreeSpace,Size
• When rewriting, prefer CIM cmdlets (Get‑CimInstance, Invoke‑CimMethod) over deprecated Get‑WmiObject for modern compatibility and remoting.
• Test
• Validate converted scripts under the PowerShell versions you plan to support (Windows PowerShell 5.1 on older systems; PowerShell 7.x for new automation).
• Use powershell -c "<command>" inside batch contexts if you need to call PowerShell from legacy .cmd wrappers.
• Pilot
• Deploy converted scripts in a small pilot group or the Release Preview ring and monitor for failures.
• Engage vendors if closed third‑party installers or monitoring agents still call wmic.exe.
• Rollout and remediation
• Roll out changes in phases, monitor logs and telemetry for missing dependencies, and keep rollback plans ready for any vendor or custom tool that can’t be quickly updated.

Microsoft provides examples and migration pointers in the support article; treating this as an inventory and modernization project yields security and maintenance benefits beyond the immediate compliance with the change.

---

Common WMIC → PowerShell conversions (cheat sheet)​

• Enumerate running processes
• WMIC: wmic path win32_process get Name
• PowerShell: Get-CimInstance Win32_Process | Select-Object Name
• Get BIOS serial number
• WMIC: wmic bios get serialnumber
• PowerShell: Get-CimInstance Win32_BIOS | Select-Object SerialNumber
• List logical disks with free space
• WMIC: wmic logicaldisk get caption,freespace,size
• PowerShell: Get-CimInstance Win32_LogicalDisk | Select-Object DeviceID,FreeSpace,Size
• Query installed hotfixes
• WMIC: wmic qfe list
• PowerShell: Get-HotFix (or Get-CimInstance Win32_QuickFixEngineering for more control)
• Query services
• WMIC: wmic service get Name,State
• PowerShell: Get-CimInstance Win32_Service | Select-Object Name,State

Use CIM cmdlets for better cross‑platform and remoting behavior; Get‑WmiObject remains available on some systems but is considered legacy compared to CIM cmdlets. Where an exact field mapping is nontrivial, query the Win32_* classes with Get‑CimInstance and filter properties as needed.

---

Programmatic alternatives (for applications and integrations)​

If you have code that programmatically queries WMI, you have options that do not depend on wmic.exe:

• .NET: use System.Management or the newer Microsoft.Management.Infrastructure (MI/CIM) libraries to perform queries in C# and other .NET languages.
• COM/Native: WMI COM APIs remain available for native code.
• Cross‑platform automation: PowerShell 7.x and the CIM cmdlets offer a robust, scriptable way to interact with WMI that supports modern telemetry and security hooks.

Shifting from shelling out to wmic.exe to using programmatic APIs reduces brittle parsing and improves reliability, telemetry, and error handling. Microsoft documentation includes sample code for these approaches; vendors should be engaged to update installers that still call WMIC.

---

Risks, gotchas, and mitigation flags to watch​

• In‑place upgrade variability: Systems upgraded in place may or may not visibly lose the WMIC binary until a servicing flag is flipped; don’t assume all endpoints will be identical. Inventory and testing are essential.
• FoD availability: On some SKUs or servicing channels WMIC may remain as a Feature on Demand for a time; relying on continued optional availability is fragile and not a long‑term remediation strategy. Microsoft’s direction is clear: migrate away.
• Vendor dependencies: Some third‑party installers, management agents, and older monitoring systems still call wmic.exe. Engage vendors early — for many the fix is simple, but some vendors may ship updated packages on a slower cadence.
• Script semantics: Not every WMIC command maps one‑to‑one to a single PowerShell pipeline expression; take care with property naming, class scoping, and locale differences when porting scripts. Test edge cases such as multi‑line string parsing and custom formatting logic.
• Operational windows: Schedule pilots and rollouts with rollback plans. The recommended path is to treat the enablement package as a scheduled maintenance event; test in representative images before broad deployment.

When a claim or expectation in an internal process can’t be independently validated (for example, a vendor saying “we’ll never call wmic”), record that as a risk and require concrete remediation or compensating controls.

---

Security trade‑offs and benefits​

Removing WMIC shrinks the default living‑off‑the‑land surface available to attackers and removes a predictable toolset that has historically been abused for discovery and tampering. This change supports modern defensive telemetry (AMSI, script block logging, Constrained Language Mode), which older runtimes bypassed. For security teams, the benefits are real: fewer deprecated binaries to monitor and fewer downgrade vectors that attackers can exploit.
That said, the migration work concentrates risk in the near term: an untested or overlooked script that previously used wmic can silently fail and degrade monitoring, backups, asset tracking, or compliance automation. The security advantage is only realized if organizations complete the inventory and remediate automation before or during the enablement rollout.

---

Recommended checklist for Windows admins (quick actions)​

• Inventory: Search all repositories, GPOs, scripts, scheduled tasks and installer logs for wmic.exe and powershell -Version 2 references.
• Convert: Port the top 20 most‑used WMIC commands to PowerShell equivalents and publish them in your internal runbooks.
• Test: Validate the converted scripts on representative images (24H2 and 25H2 preview where possible).
• Vendor engagement: Ask vendors for updated installers or a list of their administrative binaries; prioritize vendors that service critical infrastructure.
• Pilot: Use a small OU or pilot ring to deploy the enablement package and monitor for automation failures.
• Monitor: Deploy telemetry to catch missing inventory, failing scheduled tasks or agent errors after upgrade.
• Document: Update internal documentation and help desk KBs to remove WMIC examples and replace them with PowerShell snippets.

---

Longer‑term modernization opportunity​

Treat the WMIC removal as a forcing function for modernization. For many organizations the conversion to PowerShell and programmatic APIs will yield higher‑quality automation: better logging, structured output, improved error handling, and easier integration with modern CI/CD pipelines. Consolidate on supported runtimes (Windows PowerShell 5.1 for legacy Windows scripts; PowerShell 7.x for new cross‑platform work) and apply secure scripting practices (enable script block logging, use signed scripts, and minimize running scripts as SYSTEM when not necessary).

---

Conclusion​

The removal of WMIC from Windows default images is a deliberate, well‑signposted change: Microsoft documents the move in KB 5067470 and encourages migration to PowerShell CIM/WMI cmdlets and programmatic APIs. The underlying WMI infrastructure remains intact, so no management capability is lost — but operational and compatibility work is required. Inventory now, convert and test scripts, engage vendors, pilot the change, and then roll it out methodically. Managed properly, this will reduce legacy attack surface and simplify long‑term automation maintenance; left unmanaged, it’s a costly last‑minute scramble during OS enablement windows.
For administrators planning the migration, prioritize the systems and scripts that are business‑critical, and treat the WMIC removal as an opportunity to standardize on supported, observable, and secure automation practices.

---

Source: Microsoft - Message Center Windows Management Instrumentation Command-line (WMIC) removal from Windows - Microsoft Support