How to Use Windows PowerShell ‘Get-CimInstance’ as the Modern Replacement for WMI

The Evolution of Windows Instrumentation

For over a decade, Windows administrators relied on the Get-WmiObject cmdlet to query the massive hardware and software database hidden inside the operating system (WMI). It was the gold standard for extracting CPU models, RAM capacity, and Serial Numbers via PowerShell.

However, WMI uses an old, proprietary networking protocol (DCOM) for remote management. DCOM is notoriously difficult to configure, heavily blocked by modern firewalls, and fundamentally insecure over the open internet.

Because of this, Microsoft officially deprecated Get-WmiObject in PowerShell 3.0 and completely removed it in PowerShell Core (PowerShell 7+). The modern, secure replacement is Get-CimInstance (Common Information Model). It queries the exact same hardware database, but it uses WS-Man (WinRM)-the same secure, firewall-friendly protocol used by Invoke-Command.

1. The Syntax is Almost Identical

If you have years of scripts built on Get-WmiObject, the transition is painless. In 95% of use cases, you can simply swap the verb and keep the exact same class names.

To query the local CPU using the old method:

Get-WmiObject -Class Win32_Processor

To query the local CPU using the modern method:

Get-CimInstance -ClassName Win32_Processor

The output is nearly identical, providing the manufacturer, model, and core counts. The underlying database hasn’t changed; only the vehicle used to access it has been upgraded.

2. Secure Remote Auditing

This is where CIM completely destroys WMI. If you try to run Get-WmiObject -ComputerName SERVER-01, the command attempts to punch through the firewall using random, dynamic DCOM ports. It often fails instantly.

Get-CimInstance uses standard HTTP/HTTPS WinRM ports (5985/5986), which are easily routed and secured in enterprise environments.

Get-CimInstance -ClassName Win32_BIOS -ComputerName SERVER-01

This securely fetches the remote server’s motherboard serial number without triggering legacy firewall alarms.

3. The Power of CIM Sessions

If you are writing a script that needs to pull the CPU data, the RAM data, and the Hard Drive data from a remote server, using the old Get-WmiObject meant building and tearing down three separate, heavy network connections.

CIM introduces the concept of Sessions. You build a single, lightweight connection to the remote machine once, and then rapidly fire dozens of queries through that open pipe.

# 1. Open a single, secure connection to the server
$session = New-CimSession -ComputerName SERVER-01

# 2. Fire multiple queries through the open session instantly
$cpu = Get-CimInstance -CimSession $session -ClassName Win32_Processor
$ram = Get-CimInstance -CimSession $session -ClassName Win32_ComputerSystem
$disk = Get-CimInstance -CimSession $session -ClassName Win32_LogicalDisk

# 3. Close the door when finished
Remove-CimSession -CimSession $session

This drastically reduces network overhead and speeds up massive enterprise auditing scripts by orders of magnitude.

4. Formatting the Date and Time

WMI had a notoriously awful way of displaying dates. If you asked WMI when the computer last booted, it would output a string like 20240315143000.000000-240.

CIM natively understands real-world time. If you run the exact same query with CIM:

Get-CimInstance -ClassName Win32_OperatingSystem | Select-Object LastBootUpTime

It outputs a perfectly formatted, human-readable DateTime object (e.g., Friday, March 15, 2024 2:30:00 PM). No complex parsing is required.

Conclusion

If you are still writing scripts using Get-WmiObject, you are writing legacy code. Get-CimInstance is the mandatory future of Windows hardware management. By embracing its secure WinRM protocols, lightning-fast sessions, and native date formatting, administrators can build modern inventory systems that are compatible with PowerShell 7 and strict enterprise firewalls.