Windows has an old command-line tool called wmic. For twenty years it was the fastest way to ask a Windows computer a question from a script - things like "what's your serial number?" or "which updates are installed?" - all without opening any menus. Microsoft has now removed it completely from Windows 11. If you've never heard of wmic before, that's fine - this post explains what it was, why it's gone, and exactly what to type instead if you find an old script that still uses it.
Watch on YouTube · Subscribe at @EndpointWeekly
Microsoft has removed a command-line tool called wmic.exe from Windows 11. The removal arrives in the August 2026 preview update (KB5067470) for versions 24H2 and 25H2, and it also applies to 26H1. It is not coming back. The good news: only that one old tool is gone - the system underneath it still works exactly as before. If an old script or program on your computer uses the word wmic, replace it with a PowerShell command called Get-CimInstance. The free script in this post checks a computer for you and tells you exactly what needs fixing.
The problem: an old tool just vanished, and nothing warns you
WMIC stands for Windows Management Instrumentation Command-line. That's a mouthful, so here's the plain version: it was a small program, wmic.exe, that you typed commands into to ask Windows questions or make small changes - similar to typing an address into a search bar instead of clicking through menus. It was popular in scripts and installers because it was quick to use and came built into Windows for free.
Microsoft has been warning about this for a long time, but most people never noticed. Here's the timeline, in plain terms:
| Year | What happened |
|---|---|
| 2016 - 2021 | Microsoft quietly marked WMIC as "old and on its way out" (the technical word is deprecated), but it still worked fine. |
| 2022 | WMIC became optional - still included, but Microsoft signalled it wanted people to stop using it. |
| 2024 | WMIC was switched off by default, though you could still turn it back on if you needed it. |
| 2025 | Upgrading to a new version of Windows would remove it, but you could still add it back manually. |
| 2026 | Removed for good. As of the August 2026 update, there is no way to bring it back at all. |
Microsoft does offer a small temporary download, called wmic_dlc.zip, for anyone who needs a bit more time. Think of it as a spare tyre, not a permanent fix - use it to buy time while you update your old scripts, not as something to rely on long-term.
Here's the part that catches people out: when wmic disappears, nothing pops up to warn you. A script that uses it simply fails the moment it tries to run that line:
The tricky part is that nobody remembers where every old wmic command is hiding. In a typical workplace, they turn up in places like:
- Old
.batfiles - simple script files people wrote years ago and forgot about. - Sign-in scripts that run automatically when someone logs into their computer.
- Software deployment tools used by IT teams to install programs across many computers at once.
- Installer programs from other companies - the software itself may quietly use
wmicbehind the scenes. - Scheduled tasks - things set up to run automatically on a timer, sometimes years ago.
- Monitoring tools that check on computers and report back to IT.
wmic internally, you can't see that just by looking at your own files - it fails quietly during installation, and the only clue might be a line buried in that program's own log file.Why it happens: it was old, and it was risky
To understand what's actually disappearing, it helps to know that wmic was never the real engine - it was just a front door. Behind that front door sits a much bigger system called WMI (Windows Management Instrumentation), which is the part of Windows that actually stores and manages information about the computer - things like installed software, hardware details, and running programs. wmic was just one of several ways to knock on that door and ask a question. There are other doors, like PowerShell, that do the exact same job.
The 2026 change removes only the front door. The room behind it - WMI itself, and the Windows service that runs it - stays exactly as it was.
wmic.exe tool, is going away. Everything built on modern PowerShell commands like Get-CimInstance keeps working with no changes needed.So why bother removing it at all, if it still worked? Two reasons.
First, it's simply old. It was flagged as outdated back in 2016, and Windows has had a fully capable replacement in PowerShell for well over a decade. Keeping unused, ageing tools around forever adds cost and risk for Microsoft with very little benefit.
Second, security. Because wmic was trusted, signed by Microsoft, and built into every Windows computer, attackers loved it. A tool that's already installed and already trusted is far more useful to an attacker than one they have to sneak in themselves - security teams call this a "living-off-the-land" tool. One particular trick, wmic /node:, let someone run commands on a different computer over the network, which attackers used to quietly spread from machine to machine while looking like normal IT activity.
Microsoft Defender (the built-in Windows antivirus and security tool) already has rules that specifically watch for this kind of misuse. Two of its "Attack Surface Reduction" rules directly cover this: one blocks processes started via PSExec or WMI commands, and another blocks a persistence trick that abuses WMI. Removing wmic.exe itself closes the door even further. If your workplace uses Configuration Manager to manage computers, be careful turning on the PSExec/WMI rule everywhere at once - Configuration Manager itself relies heavily on WMI to function, so test it on a few machines first.
Get-WmiObject that looks like an obvious replacement, but it's also on its way out - it doesn't exist at all in the newer version of PowerShell (PowerShell 7). Skip it. Go straight to Get-CimInstance instead, which works the same way in every current version of PowerShell.How to verify: is this tool still on your computer?
Before fixing anything, check three things: is the tool itself still there, does Windows think it's installed, and do any of your own scripts still mention it.
Check 1 - is the file still there? This works on any regular computer, no special permissions needed:
Check 2 - what does Windows itself think? Windows keeps a list of optional add-ons, and WMIC used to be one of them. This check needs to be run as an administrator:
While it still exists on a computer, a normal user can also see it without PowerShell at all:
- Open Settings, then go to System, then Optional features.
- Look under Added features and type WMIC in the search box.
- On a computer with the August 2026 update installed, it won't appear in the list at all - that's expected, not an error.
Check 3 - the one that actually matters most: do any of your own files still use it? Here's a simple search across one folder:
Checking every folder by hand is slow, which is exactly why the companion script for this post exists. Get-WmicDependencyReport.ps1 runs all three checks above automatically and writes the results to a spreadsheet (CSV file) you can share with your team. You can download it from the Windows-11-Scripts repository, and you can see it running for real further down this post.
The fix: what to type instead
Every old wmic command has a modern replacement using a PowerShell command called Get-CimInstance. Think of it as asking the exact same question, just through a newer, better-supported window. These replacements work the same way on every current version of Windows, and they even work against other computers on the network, not just the one you're sitting at.
Here's a lookup table for the most common commands you're likely to find in old scripts:
Old command (wmic) | New command (PowerShell) | Notes |
|---|---|---|
wmic qfe list brief | Get-CimInstance Win32_QuickFixEngineering | Lists installed updates. Get-HotFix does the same thing with a friendlier name. |
wmic process list brief | Get-CimInstance Win32_Process | Lists running programs. |
wmic bios get serialnumber | Get-CimInstance Win32_BIOS | Select-Object SerialNumber | The single most common old command out there. |
wmic os get version | Get-CimInstance Win32_OperatingSystem | Select-Object Version, BuildNumber | Shows the Windows version and build number. |
wmic logicaldisk get name,freespace | Get-CimInstance Win32_LogicalDisk | Shows drive letters and free space. |
wmic computersystem get model | Get-CimInstance Win32_ComputerSystem | Shows the manufacturer, model, and memory in one go. |
wmic service list brief | Get-CimInstance Win32_Service | Lists Windows services, including the account each one runs as. |
wmic cpu get name | Get-CimInstance Win32_Processor | Shows the processor name and core count. |
wmic product get name,version | Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*' | Lists installed software. Deliberately NOT the obvious-looking replacement - see the warning below. |
wmic product where name='X' call uninstall to become Get-CimInstance Win32_Product, but don't do that. Microsoft's own documentation warns that simply looking up software this way can accidentally trigger every installed program on the computer to re-check and repair itself in the background - which can cause real slowdowns or even break things, just from asking a question. Use the registry-based command in the table above instead - it's instant and completely safe to run.If you need to check computers over the network rather than sitting in front of them, the same Get-CimInstance command works remotely too - just add the computer's name:
Get-CimClass -ClassName Win32_*disk* will list every matching option for you to explore.Can IT policy control this removal? No. Worth saying clearly: there is no setting anywhere - not in Group Policy, not in Intune, not in any admin console - that can stop, delay, or reverse this removal. It happens regardless. The only thing within your control is finding and fixing the old commands before the removal reaches your computers. Here are two practical ways to do that at scale.
Option 1 - search sign-in scripts stored on the company network. These are a classic hiding spot, and IT staff can search them directly:
- Open the Group Policy Management tool and pick a policy that runs scripts when someone logs in.
- Check its Settings tab to see which script files it actually runs.
- Instead of checking each policy one by one, point the companion script at the whole shared folder where these scripts live, and let it search everything at once.
- Fix any old command found by editing that script file directly - no policy needs to change, since it's the file itself that gets updated.
Option 2 - run the check automatically across many computers with Intune. If your workplace manages computers through Microsoft Intune, you can deploy the companion script to run itself and report back:
- Sign in to intune.microsoft.com and go to Devices > Scripts and remediations.
- Choose Platform scripts, then Add > Windows 10 and later.
- Give it a name like WMIC dependency report, and upload
Get-WmicDependencyReport.ps1. - Assign it to a small test group of computers first.
- Once it's run, check the results for each computer under the script's Device status page.
Where does the output actually show up? This trips people up the first time. There's no live terminal window - Intune captures whatever the script prints and shows it back to you in the console, but the exact place depends on which of the two tools above you used:
- For a Platform script (Option 2 above): go to Devices > Scripts and remediations > Platform scripts, select your script, then Monitor > Device status (or User status) for a per-device breakdown.
- For a Remediation (covered next): go to Devices > Scripts and remediations, select the remediation package, then Device status for the overview, or open a specific device's own page and look under Monitor > Remediations for just that machine.
Get-WmicDependencyReport.ps1's full walkthrough-style report can run longer than that if it finds a lot of hits, so anything past the limit simply won't show up in the console. That's exactly why the script also supports -ExportCsv - write the full, untruncated detail to a file share or a company reporting tool instead of relying on the console text box.Now, the remediation question: can any of this actually be fixed automatically? Mostly, no - and it's worth being honest about why. Rewriting an old script that calls wmic means picking the right replacement from the table above, and often testing it against that specific script's logic. That needs a person, not automation. There's no safe way for a script to guess which Get-CimInstance line to substitute into someone else's .bat file.
There's exactly one part of this that CAN be safely automated: putting the old tool back, temporarily, if it's still available on that Windows build. That's not a real fix - it's the same idea as Microsoft's own wmic_dlc.zip stopgap - but it buys a team time to do the real migration work without an outage in the meantime.
Remediate-WmicDependencies.ps1 only reinstalls the WMIC Feature on Demand as a temporary bridge. It does not fix a single script. If you deploy it, you still have to go and update every script the detection script found - this just stops things from breaking today while that work happens. Once a device is on a build where WMIC has been fully removed (the expected end state after the August 2026 update), this script cannot bring it back at all, and it says so plainly instead of pretending to succeed.To wire this up as a real, self-healing Intune Remediation - not just a report - use the two scripts below instead of Get-WmicDependencyReport.ps1. They matter because Intune has a strict rule for this feature specifically: a remediation script only runs if the detection script exits with code 1. The standalone report script in this post uses exit code 2 for "found, but not an error," which works fine as a Platform script but will never trigger a paired remediation - Intune is only watching for exit code 1. Detect-WmicDependencies.ps1 and Remediate-WmicDependencies.ps1 follow that exact rule, and Intune also supports deploying the detection script completely on its own, with no remediation attached, if you only want the checking part.
- Go to Devices > Scripts and remediations and select Create script package.
- Give it a name, e.g. WMIC dependency bridge.
- Upload
Detect-WmicDependencies.ps1as the Detection script file, andRemediate-WmicDependencies.ps1as the Remediation script file. You can leave the remediation script out entirely if you only want detection. - Set Run this script using the logged-on credentials to No, so both scripts run as SYSTEM with the rights they need.
- Assign it to a small test group first, and pick a daily schedule.
- Check results under Device status, or export them to a CSV for a wider review.
Here's both scripts running for real, back to back, on the same test computer used throughout this post:
Proof it worked: a real check on a real computer
This is a genuine run of the companion script, Get-WmicDependencyReport.ps1, on a real Windows 11 computer, pointed at a small test folder containing one old batch file and one old script file that both use wmic. Nothing here is invented - the folder paths have just been shortened, and anything that could identify the real device has been replaced.
Three things in that output are worth pointing out. First, this computer is on the newest version of Windows (25H2) and yet Step 3 still says the old tool is Installed - even though Microsoft's own notice says it should be removed at that point. In practice, whether it lingers depends on each computer's individual update history, which is exactly why the script checks for real instead of guessing from the Windows version number alone.
Second, notice the script found the risky wmic product ... call uninstall pattern inside an old script file - that's the exact command the red warning earlier in this post is about. Third, it also caught a line that quietly saves its result to a text file - the kind of failure that's easy to miss completely, because nothing appears on screen to say it went wrong.
One more thing worth knowing: if a step in the script genuinely can't run - for example, if you forget to run it as an administrator - it says so clearly instead of pretending everything is fine. A result that quietly comes back "clean" because a check secretly failed would be far more dangerous than an honest error message.
One more genuine run, same computer, this time with no -ScanPath given at all - showing what happens when you skip that step:
This is the same behaviour described earlier applied to Step 4 specifically: the script never quietly treats "I didn't check" the same as "I checked, and it's fine." Skip -ScanPath and it tells you exactly that, by name, rather than folding it into a falsely reassuring summary line.
References
- Microsoft Support — Windows Management Instrumentation Command-line (WMIC) removal from Windows
- Microsoft Learn — Available features on demand
- Microsoft Learn — Win32_Product class
- Microsoft Learn — Get-CimInstance (CimCmdlets)
- Microsoft Learn — Differences between Windows PowerShell 5.1 and PowerShell 7.x
- Microsoft Learn — Attack surface reduction rules reference
Download it from Imran76Awan/Windows-11-Scripts — no sign-in required. It is read-only: it reports and never changes a device or anything in Intune. Validate it in your own environment before relying on the output.