Windows 11 25H2 Removes WMIC: Find Dependencies Before Upgrading

Windows 11 version 25H2 removes WMIC during the feature update, so organizations should treat every remaining wmic.exe dependency as an upgrade gate now. Reinstalling WMIC is defensible only as a documented, time-limited bridge for a known workload with an active migration owner; if the dependency is unknown, business-critical, vendor-controlled, or embedded in deployment media, migration and testing should block broad 25H2 deployment.
Microsoft deprecated the Windows Management Instrumentation Command-line utility in Windows 10 version 21H1, but the underlying WMI platform remains available. That distinction matters: administrators are not losing Windows instrumentation, only the legacy command-line interface used to query it.
Windows 11 version 25H2 became generally available on September 30, 2025. As detailed in Microsoft’s Windows documentation, the upgrade removes WMIC, although administrators can temporarily restore it through Optional Features or DISM.

Make the Reinstall Decision Before the Upgrade​

A 25H2 pilot should begin with dependency discovery, not with clicking Download and install. Because 25H2 is delivered to Windows 11 24H2 devices as an enablement package, an update that looks operationally modest can expose inherited automation quickly.
If a pilot device has already been upgraded, first confirm whether the WMIC capability is present. Run PowerShell as an administrator:

Get-WindowsCapability -Online |
    Where-Object Name -Like 'WMIC*'

To install the temporary compatibility feature through Settings:

1. Open Settings.
2. Select System, followed by Optional features.
3. Choose the option to view or add an optional feature.
4. Search for WMIC.
5. Select it and complete the installation.

Administrators can also use an elevated Terminal:
DISM /Online /Add-Capability /CapabilityName:WMIC~~~~
Microsoft explicitly does not recommend treating this as the solution because WMIC is scheduled for complete removal in a future Windows release. The capability therefore buys migration time; it does not restore WMIC to supported strategic status.
Reinstall WMIC only when all of these conditions are true:

• The exact dependent script, product, or management job has been identified.
• Its business owner has accepted a written retirement date.
• The dependency has a tested migration plan.
• The temporary installation can be tracked and removed centrally.
• A failed WMIC call will not silently corrupt inventory, compliance, deployment, or recovery data.

If those conditions cannot be met, hold the affected device group on its current deployment ring while the dependency is repaired. Installing WMIC everywhere “just in case” hides the scope of the problem and converts a visible upgrade failure into a future emergency.

---

Find WMIC Where Administrators Rarely Look​

The obvious search target is a shared scripts directory, but WMIC often survives inside old batch files, software packaging wrappers, scheduled tasks, logon scripts, RMM component libraries, and vendor-provided diagnostic tools. Searching only .ps1 files misses precisely the older automation most likely to call it.
The following PowerShell example scans selected repositories for textual references to wmic:

$Roots = @(
    'C:\Scripts',
    'C:\ProgramData',
    '\\FileServer\Automation',
    '\\FileServer\SoftwarePackages',
    '\\FileServer\RMM-Exports'
)

$Extensions = '*.bat', '*.cmd', '*.ps1', '*.vbs', '*.txt', '*.xml'

foreach ($Root in $Roots) {
    if (Test-Path $Root) {
        Get-ChildItem -Path $Root -Recurse -File -Include $Extensions `
            -ErrorAction SilentlyContinue |
        Select-String -Pattern '\bwmic(\.exe)?\b' |
        Select-Object Path, LineNumber, Line
    }
}

Export the results when multiple teams need to triage them:

$Results = foreach ($Root in $Roots) {
    if (Test-Path $Root) {
        Get-ChildItem -Path $Root -Recurse -File -Include $Extensions `
            -ErrorAction SilentlyContinue |
        Select-String -Pattern '\bwmic(\.exe)?\b' |
        Select-Object Path, LineNumber, Line
    }
}

$Results | Export-Csv '.\WMIC-Dependencies.csv' -NoTypeInformation

Scheduled tasks need a separate pass because a task action can contain an inline command or point to a wrapper stored elsewhere:

Get-ScheduledTask | ForEach-Object {
    $Task = $_

    foreach ($Action in $Task.Actions) {
        $CommandLine = "$($Action.Execute) $($Action.Arguments)"

        if ($CommandLine -match '\bwmic(\.exe)?\b') {
            [pscustomobject]@{
                TaskPath    = $Task.TaskPath
                TaskName    = $Task.TaskName
                Execute     = $Action.Execute
                Arguments   = $Action.Arguments
            }
        }
    }
} | Export-Csv '.\WMIC-ScheduledTasks.csv' -NoTypeInformation

RMM systems deserve repository-level inspection rather than endpoint-only scanning. A component may download or generate a batch file at runtime, meaning no persistent local copy exists until the job executes. Export component definitions, script bodies, policies, monitors, and remediation packages from the RMM platform, then search those exports as text.
Inventory products and packaged applications also need an owner assigned even when the organization cannot edit their code. A vendor dependency is still an upgrade dependency; “third-party software” is not a remediation status.

Translate Behavior, Not Just Command Names​

Most WMIC inventory queries map cleanly to Get-CimInstance, but a mechanical substitution is rarely sufficient. PowerShell returns objects, while legacy WMIC scripts frequently depend on fixed text, /value output, CSV formatting, aliases, and parsing with for /f or findstr.
Common translations include:
wmic os get Caption,Version

Get-CimInstance -ClassName Win32_OperatingSystem |
    Select-Object Caption, Version

wmic computersystem get Manufacturer,Model,Name

Get-CimInstance -ClassName Win32_ComputerSystem |
    Select-Object Manufacturer, Model, Name

wmic logicaldisk get DeviceID,FreeSpace,Size

Get-CimInstance -ClassName Win32_LogicalDisk |
    Select-Object DeviceID, FreeSpace, Size

wmic process where "name='notepad.exe'" get ProcessId,CommandLine

Get-CimInstance -ClassName Win32_Process `
    -Filter "Name='notepad.exe'" |
    Select-Object ProcessId, CommandLine

The migration should preserve the consumer’s expected contract. If another tool reads a CSV file, produce deliberate CSV rather than copying PowerShell’s formatted console table:

Get-CimInstance -ClassName Win32_OperatingSystem |
    Select-Object Caption, Version |
    Export-Csv '.\OperatingSystem.csv' -NoTypeInformation

For structured integrations, JSON may be a better replacement:

Get-CimInstance -ClassName Win32_ComputerSystem |
    Select-Object Manufacturer, Model, Name |
    ConvertTo-Json |
    Set-Content '.\ComputerSystem.json'

Remote operations require additional testing. A WMIC command using remote-node and credential arguments should not be assumed to have identical authentication, firewall, delegation, or error behavior when converted to a CIM session.

$Session = New-CimSession -ComputerName 'PC-01'

Get-CimInstance -ClassName Win32_OperatingSystem `
    -CimSession $Session |
    Select-Object Caption, Version

Remove-CimSession $Session

Test remote replacements under the same service account, network boundary, privilege level, and management platform that will run them in production. An interactive success from an administrator workstation does not prove that an RMM agent running unattended will succeed.

---

Vendor Tools and Deployment Images Raise the Stakes​

Packaged applications can invoke WMIC during installation, repair, removal, licensing, or hardware detection. That means a product may appear healthy after the 25H2 upgrade but fail months later when a repair action runs.
Test the complete package lifecycle on a 25H2 device without WMIC:

1. Install the application from a clean state.
2. Launch it and exercise its hardware or inventory functions.
3. Run its repair operation.
4. Apply an available product update.
5. Uninstall it.
6. Review installer and application logs for failed command launches.

WinPE and customized deployment images require their own audit. Search task-sequence content, answer-file repositories, driver-pack wrappers, hardware detection scripts, and post-installation commands rather than assuming the production Windows scan covers deployment tooling.
Rollback testing must also verify data and job state, not merely whether Windows returns to the previous version. A management task may fail during the 25H2 test, record an incomplete inventory, and then remain “successful” after rollback because the scheduler only reports that the wrapper launched.
The safest pilot deliberately leaves WMIC absent. Reinstalling it before testing proves only that the compatibility bridge works; it does not reveal which scripts will break when that bridge disappears.

The Upgrade Gate Needs an Owner and an Exit Date​

Classify each discovery result by operational consequence. A cosmetic workstation report can usually migrate after a short validation cycle, while a dependency controlling software deployment, compliance, recovery, licensing, or remote remediation deserves a deployment hold.
A practical remediation record should capture the device group, calling script or product, business owner, replacement, test status, temporary WMIC requirement, and removal deadline. This turns WMIC from a vague legacy concern into a finite change queue.
WindowsForum’s continuing coverage of WMIC removal and broader Windows legacy-component cleanup has emphasized PowerShell CIM/WMI migration, but the decisive work happens in local repositories and vendor relationships. The question is no longer whether administrators understand that WMIC is deprecated; it is whether they can name every process that still expects wmic.exe to exist.
Microsoft has not provided a specific date for WMIC’s complete future removal in the supplied guidance. That uncertainty makes a permanent reinstall strategy less defensible, not more: every temporary restoration should be treated as borrowed time, and every unmanaged dependency should keep its affected Windows 11 25H2 deployment ring closed.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Deprecated features in the Windows client | Microsoft Learn

   Review the list of features that Microsoft is no longer actively developing in Windows 10 and Windows 11.

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

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

   Microsoft has begun removing the long‑standing Windows Management Instrumentation Command‑line (WMIC) tool from Windows images — WMIC will be absent by...

   windowsforum.com

 

[ChatGPT]

WMIC should now be treated as a dependency to eliminate, not a tool to reinstall by default. Microsoft still permits it to be enabled as a Feature on Demand on Windows 11 version 22H2 and later while that option remains available, but the practical deadline is the last day that installation path remains viable—not a later removal notice that leaves an organization with no controlled fallback.
Microsoft’s deprecated-features documentation remains the authoritative tracker for WMIC’s retirement status and its PowerShell direction of travel. WindowsForum’s Windows 11 25H2 coverage has already framed remaining wmic.exe calls as an upgrade-readiness issue: reinstalling the component may be defensible as a documented, time-limited bridge, but it is not a migration plan.

Start with an inventory that reaches beyond live PCs​

The obvious search—looking for wmic.exe on currently managed Windows devices—is necessary but incomplete. A Windows estate can carry WMIC dependencies in golden images, task sequences, deployment packages, scheduled tasks, build pipelines, vendor tools, and configuration repositories long after a support team believes the command has been retired.
Make every wmic or wmic.exe result an owned remediation record. The record should identify the calling asset, the exact command line, its expected output or side effect, the replacement command, a validation result, a business owner, and a retirement date for any temporary Feature on Demand exception.
A useful first pass should cover these locations:

1. Search PowerShell scripts, batch files, command files, installers, configuration-management content, CI/CD repositories, and packaging source for wmic, wmic.exe, and common calls such as wmic bios, wmic computersystem, wmic os, wmic process, and wmic logicaldisk.
2. Enumerate Scheduled Tasks and inspect their executable paths and arguments. WMIC is frequently buried in old health checks, inventory jobs, logon actions, and low-visibility maintenance tasks rather than in actively maintained scripts.
3. Review deployment task sequences, provisioning packages, unattend content, recovery media, and reference-image build steps. An image that does not contain WMIC can still deploy a post-install task that assumes it is present.
4. Inspect endpoint-management scripts and detection rules. Configuration repositories often retain legacy checks that run only during a repair, upgrade, rollback, or break-glass workflow.
5. Test third-party agents and vendor utilities rather than trusting product documentation. A product may invoke WMIC indirectly through a helper script, an embedded installer, or a locally generated batch file.
6. Check the images used by labs, kiosks, field devices, and specialized Windows environments. Microsoft’s Validation OS version 2604 release notes show that WMIC removal is continuing in specialized Windows images, making “we can always add it later” an unsafe automation assumption.

The key distinction is between finding text and proving execution. A repository hit may be dead code; a vendor executable may call WMIC without leaving a searchable script behind. Use endpoint telemetry, software deployment logs, process-creation auditing where available, and controlled test rings to establish which calls still execute in real workflows.

---

Translate behavior, not just command names​

PowerShell’s CIM cmdlets are the supported replacement direction, but a straight text substitution can break automation. WMIC emits formatted, often locale-sensitive text; PowerShell returns objects. That is an advantage for new code, but it means downstream parsers, CSV generation, error handling, and exit-code assumptions must be explicitly retested.
For read-only inventory, the starting mappings are usually straightforward:

# WMIC: wmic os get Caption,Version,BuildNumber
Get-CimInstance -ClassName Win32_OperatingSystem |
 Select-Object Caption, Version, BuildNumber

# WMIC: wmic bios get SerialNumber
Get-CimInstance -ClassName Win32_BIOS |
 Select-Object SerialNumber

# WMIC: wmic computersystem get Model,Manufacturer
Get-CimInstance -ClassName Win32_ComputerSystem |
 Select-Object Manufacturer, Model

# WMIC: wmic logicaldisk get DeviceID,Size,FreeSpace
Get-CimInstance -ClassName Win32_LogicalDisk |
 Select-Object DeviceID, Size, FreeSpace

These examples are not output-equivalent to WMIC, and they should not be made so unless an old consumer truly requires it. If a deployment system expects a plain serial number with no header, emit only that property. If a script needs structured disk data, keep objects through the pipeline and serialize deliberately at the boundary.
Process operations require more care. A legacy command such as wmic process call create performs a method invocation, so the closer PowerShell pattern is Invoke-CimMethod against Win32_Process. That replacement must be tested for quoting, working-directory assumptions, return values, permissions, and how the caller recognizes failure.

Invoke-CimMethod -ClassName Win32_Process -MethodName Create `
 -Arguments @{ CommandLine = 'notepad.exe' }

Avoid treating Get-WmiObject as the strategic endpoint simply because it resembles older examples. The goal is to move the script’s logic to the current CIM-based approach, then simplify it around PowerShell objects rather than preserve every WMIC formatting quirk.
WindowsForum’s earlier guidance on migrating WMIC to PowerShell CIM and WMI is useful reading for administrators building a command-by-command replacement catalog. The operational rule is simpler: every replacement needs a test that compares the information or action the business process actually relies on, not merely whether PowerShell produced some output.

Build a controlled Feature on Demand exception path​

The Feature on Demand option is valuable precisely because it can buy time for a narrow, measured remediation effort. It becomes dangerous when it quietly restores a tool across broad fleets without an owner, expiry, or upgrade test.
If a critical dependency cannot be replaced before an image refresh or feature update, document a temporary exception with all of the following:

• The affected device group, application or workflow, and technical owner must be named.
• The reason CIM replacement is blocked must be recorded in operational terms, such as a vendor dependency awaiting an update.
• The required WMIC command and its replacement candidate must be listed together.
• The exception must have an end date and a validation milestone, rather than remaining open until the next operating-system project.
• The workflow must be tested both with WMIC present and with WMIC absent, so the organization knows what fails when the bridge is removed.

This is where image engineering matters. Do not assume a Feature on Demand installed on a reference device will behave as intended through every servicing, language, repair, reset, or upgrade path. Test the exact image and deployment sequence that will reach production. Microsoft’s removal work in Validation OS is a warning that optionality is not a durable platform contract for old tooling.

---

Remote CIM exposes migration risks WMIC scripts may have hidden​

Local WMIC replacements are often easy. Remote management is where migrations expose assumptions about credentials, firewalls, name resolution, delegation, and endpoint configuration.
PowerShell 5.1 is embedded in many existing Windows automation environments, while PowerShell 7 may be present on administrative workstations, servers, or automation runners. A script that succeeds interactively in one host does not automatically have the same remoting behavior, module availability, authentication flow, or network path when run from the other. Treat the PowerShell host as part of the test case.
CIM also changes the conversation from “does this executable exist?” to “can this management operation reach and authenticate to the target?” Test local execution first, then test remote execution from the actual service account or automation identity. Confirm target firewall policy, allowed management protocols, DNS behavior, certificate or trust requirements where applicable, and whether the task runs under an interactive or noninteractive context.
Do not conceal those failures by adding broad firewall exceptions or switching to more permissive credentials. A WMIC migration is a good opportunity to narrow management access, standardize the account model, and document which endpoints are intended to accept remote administration.

Make vendors prove their path off WMIC​

Third-party software is the part most likely to escape a repository search. Administrators should ask vendors a direct, testable question: does the current supported release invoke wmic.exe, require it to be installed, or generate scripts that call it?
The answer should include the product version under support, the relevant Windows versions, and a remediation route if WMIC is absent. “We have not seen a problem” is not an assurance; it may only mean the vendor tested against an image where WMIC was still installed.
This issue also overlaps with other legacy-component cleanup. WindowsForum’s coverage of PowerShell 2.0 removal makes the broader point: old administrative dependencies tend to cluster in the same scripts, images, and vendor integrations. An inventory that finds WMIC should also flag obsolete PowerShell assumptions and other hard-coded management tools for review.

Frequently Asked Questions​

Should administrators remove WMIC immediately from every device?
Not necessarily. First identify active dependencies and replace them in controlled rings. The priority is preventing unmanaged reliance on a Feature on Demand path that may not remain available.
Can a team keep installing WMIC as a Feature on Demand indefinitely?
No long-term assumption should rest on that option. Microsoft describes WMIC as deprecated, and its removal activity in specialized Windows images shows why organizations should regard installation as temporary remediation time.
Is WMI itself being removed with WMIC?
No. WMIC is the legacy command-line utility; Microsoft’s replacement direction is PowerShell-based CIM and WMI management. The migration work is about changing the command interface and automation design.
What is the most important test after replacing a WMIC call?
Validate the business outcome: the correct inventory value reaches its consumer, the intended management action completes, and failures are detected correctly under the actual account and deployment conditions.
The organizations least exposed to WMIC’s next removal step will not be those that reinstall it most quickly. They will be the ones that use the remaining Feature on Demand window to turn every surviving wmic.exe invocation into a named, tested PowerShell/CIM replacement before the fallback itself disappears.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Deprecated features in the Windows client | Microsoft Learn

   Review the list of features that Microsoft is no longer actively developing in Windows 10 and Windows 11.

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

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

   Microsoft has begun removing the long‑standing Windows Management Instrumentation Command‑line (WMIC) tool from Windows images — WMIC will be absent by...

   windowsforum.com