Microsoft has taken another step in its plan to remove the Windows Management Instrumentation Command-line, or WMIC, from Windows 11. The Release Preview update KB5120998, dated August 14, states that WMIC will not be included in 24H2 or 25H2, nor will it be available as a Feature on Demand (FoD). Simply assuming that new installations won't have wmic.exe present is no longer sufficient.
WMIC has been deprecated for some time. But there's a meaningful operational difference between the earlier period, when it could be restored via FoD if needed, and now, when it can't. If batch files or monitoring configurations still reference the executable by name, the result won't be a warning—it will be a broken dependency. The general availability timeline hasn't been announced, but administrators and software vendors need to decide what to replace before this rolls out.
KB5120998 Closes the "Reinstall" Escape Route
The update applies to Build 26100.9267 (24H2) and Build 26200.9267 (25H2) in the Windows 11 Release Preview Channel. Microsoft's release notes state that starting in August 2026, both versions will no longer include WMIC, and FoD will no longer be available either. This has not been confirmed as a widely released general availability update at this time. The release notes describe both staged and general rollouts, but they don't specify a date when it will reach all users.
Even so, the scope isn't narrow. Since 24H2 and 25H2 share this Release Preview update, avoiding a future feature update to 25H2 won't solve the problem—devices still maintaining 24H2 are affected too. Organizations that apply Release Preview updates internally ahead of schedule can use this as a basis for verification before general release, but it shouldn't be treated as if it's already been broadly deployed to production environments.
The FoD being removed here is WMIC~~~~, used in the legacy procedure. Earlier documentation listed it as a feature available from Windows 11 22H2 onward, and also explained that it wouldn't be pre-installed in 24H2. However, once a system reaches the state described in KB5120998, using that documentation as a basis for a reinstallation workaround would be incorrect.
A Gradual Removal Process Since 2021
Microsoft deprecated WMIC on client Windows back in 2021. Deprecation is a category indicating that no new development will occur and signaling future removal—it didn't mean existing operations would immediately stop working.
Tracking the changes since then clarifies exactly what this update is switching over.
| Timeframe | Windows-side State | Administrator Options |
|---|---|---|
| 2021 | WMIC deprecated | Could keep existing calls in place while preparing to migrate |
| 2022, Windows 11 22H2 | Pre-installed and enabled as FoD | Could still use legacy commands on devices that needed them |
| 2024, 23H2/24H2 | Disabled by default, or not pre-installed | Could restore it by adding the FoD |
| 2025, upgrade to 25H2 | Installed WMIC removed | Could still re-add it via FoD |
| August 2026 Release Preview | WMIC not included, FoD not available | Must move to alternative approaches |
With earlier default changes, administrators could get by for a while by incorporating the FoD addition into device images or procedures. That option disappears with this update. Along with .bat and .cmd files that invoke wmic, .ps1 scripts that launch wmic.exe from PowerShell also need to be examined. Logon scripts, scheduled tasks, and deployment packages may still contain string-based calls as well. Asset management/monitoring agents and operational documentation also constitute the same kind of dependency when something breaks.
What's Being Removed Is wmic.exe—WMI Itself Remains
What's being removed is the WMIC command-line wrapper—not the Windows Management Instrumentation (WMI) infrastructure or service itself. Conflating the two leads to overestimating the scope of migration work. Microsoft states that WMI remains accessible through PowerShell cmdlets, .NET's System.Management, the COM API, and other languages.
WMIC served as an entry point for querying WMI classes using command strings and formatted text output. For example, in a migration example Microsoft provides, wmic path win32_process get Name is replaced with Get-CimInstance Win32_Process | Select-Object Name. The former displays result columns as output, while the latter passes CimInstance objects down the pipeline. This difference matters more than it might appear.
Existing WQL (WMI Query Language) queries don't need to be discarded either. PowerShell documentation explains that WQL queries usable with Get-WmiObject can also be used with Get-CimInstance -Query. That said, WMI cmdlets are already deprecated and are not included in PowerShell 6 and later. The list of differences for PowerShell 7.x also confirms that WMI v1 cmdlets such as Get-WmiObject have been removed. New workflows should naturally be designed around CIM cmdlets as the standard.
Migration Is About Fixing the Output Contract, Not Just Renaming Commands
Mechanically replacing wmic with Get-CimInstance won't automatically make all automation work as-is. Scripts that split WMIC's output on whitespace, search for column headers, or compare localized display strings need to be restructured to work with PowerShell's object-returning approach instead. This distinction is an important implementation consideration that follows from Microsoft's migration examples and how CIM cmdlets return values.
Even after a replaced command succeeds, verification continues. Process exit codes and error-handling branches should be checked together with the calling process. You also need to test whether all required properties are present and how empty results are handled. For instance, if only the process name is needed, specify it explicitly with Select-Object Name. If the original script passed a text table to a downstream tool, that handoff format needs to be redefined as well.
Remote queries introduce even more conditions to verify. Get-CimInstance uses WSMan by default. Microsoft provides examples of using CimSession to connect with different credentials, and New-CimSessionOption for using DCOM with older systems. Unless credentials, the transport method used, firewall traversal conditions, and the shape of returned objects are all verified in the same test, a single successful test on one local machine doesn't mean migration is complete.
Dependencies to Identify Before General Release
Start by searching repositories and deployment scripts for calls to wmic and wmic.exe. Task definitions and operational procedures should be examined the same way. Once you find matches, treat interactive procedures and automated executions separately. For the former, prepare documentation rewritten with CIM commands; for the latter, test with the actual combination of execution accounts and target devices.
Next, categorize what each query is actually for. If it's simply retrieving values from a class like Win32_Process, it's relatively straightforward to replace with Get-CimInstance and explicit property selection. On the other hand, even for something like retrieving BIOS information from Win32_BIOS, if a downstream process depends on the ordering of text, obtaining the same values alone isn't sufficient—you also need to verify the specifications of whatever monitoring product or distribution tool consumes the results.
Microsoft warns of impacts not only on applications and scripts that depend on WMIC, but also on automated deployment and monitoring. Tools and operational documentation need updating as well. Rather than waiting for a general availability date to be set, running the replacement logic on Release Preview machines and confirming that return values, permissions, and remote connections all work correctly is what allows a transition to operations without WMIC.