Learn PowerShell - WMI & CIM

#Introduction

In episode 15 you managed services, processes, and event logs — things visible on the system's surface. But where does that data come from? Windows stores structured information about almost everything: hardware, operating system, network, even processes. Accessing this data repository is this episode's topic.

Episode 16 covers WMI & CIM: the difference between the legacy Get-WmiObject and the modern Get-CimInstance, exploring the most useful WMI classes, filtering data with WQL, managing CIM sessions for efficient remote access, and tracing relationships between classes with CIM associations.

#WMI vs CIM

WMI (Windows Management Instrumentation) is a Windows technology for retrieving system information and performing actions on the system — a structured database containing hardware, operating system, processes, and more. Modern access to this repository uses CIM (Common Information Model) through the new-generation cmdlets: Get-CimInstance.

Key differences:

• Get-WmiObject — the legacy cmdlet depending on DCOM-based WMI. Still works, but slow and dependent on an old stack. In PowerShell 7, Get-WmiObject is even removed.
• Get-CimInstance — the modern cmdlet based on WinRM. Faster, secure, and cross-platform capable.

Get-WmiObject Win32_OperatingSystem
Get-CimInstance Win32_OperatingSystem

Both display the same object — only the transport and performance differ. Rule of thumb: use Get-CimInstance, not Get-WmiObject, for all new scripts.

#Exploring WMI Classes

WMI classes are the "table templates" inside the repository — Win32_Process is the process table, Win32_Service the services table, and so on. Viewing the list of classes:

Get-CimClass -ClassName Win32_*

Each class has properties and methods. Exploring a class's properties:

(Get-CimClass -ClassName Win32_OperatingSystem).CimClassProperties.Name

Fetching data from a class is as easy as naming it:

Get-CimInstance Win32_OperatingSystem

Get-CimInstance accepts the class name as its first argument. The output is an object with structured properties — ready for pipeline processing like the other objects you already know.

#The Most Frequently Used Classes

Some WMI classes you'll encounter almost daily:

A practical example — getting operating system info with uptime:

Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption, Version, LastBootUpTime,
        @{n="UptimeHari"; e={[math]::Round(((Get-Date)-$_.LastBootUpTime).TotalDays,1)}}

Checking free disk space:

Get-CimInstance Win32_LogicalDisk -Filter "DriveType=3" |
    Select-Object DeviceID,
        @{n="TotalGB"; e={[math]::Round($_.Size/1GB,2)}},
        @{n="FreeGB";  e={[math]::Round($_.FreeSpace/1GB,2)}}

#Filters and WQL

Fetching all instances then filtering in the pipeline is wasteful. Use the -Filter parameter so filtering happens at the source:

Get-CimInstance Win32_Process -Filter "Name='notepad.exe'"

-Filter accepts WQL (WMI Query Language) expressions — a SQL dialect specific to WMI. Comparing with pattern matching:

Get-CimInstance Win32_Process -Filter "Name LIKE 'sql%'"

WQL supports common operators: =, <>, LIKE with wildcards, and AND/OR for combinations. Remember the WQL writing rules: strings are wrapped in single quotes, and the % wildcard is used for patterns — not *.

Get-CimInstance Win32_Service -Filter "State='Running' AND StartMode='Auto'"

#CIM Sessions

As with remoting in episode 14, you can create CIM sessions — persistent connections to a remote computer reused multiple times. Two important advantages: WinRM-based communication (not DCOM), and one connection can be used for many queries.

$cimSession = New-CimSession -ComputerName server-web-01
Get-CimInstance -CimSession $cimSession -ClassName Win32_OperatingSystem
Get-CimInstance -CimSession $cimSession -ClassName Win32_Process
Remove-CimSession -CimSession $cimSession

New-CimSession uses WinRM, so the target must have remoting enabled. When done, always Remove-CimSession — sessions left open hang connections on the target. This is the same pattern as New-PSSession from episode 14.

Get-CimInstance also has a -ComputerName parameter for one-off queries without a session. For several queries to the same computer, -CimSession is far more efficient because the connection is reused.

#Relationships Between Classes: Get-CimAssociatedInstance

WMI classes don't stand alone — they're interconnected. Example: Win32_Process is connected to Win32_Service (which service runs which process). These relationships are called associations, and CIM provides a dedicated cmdlet to trace them:

$service = Get-CimInstance Win32_Service -Filter "Name='W3SVC'"
Get-CimAssociatedInstance -InputObject $service

The result is instances of other classes associated with that service — for example the process running the service. Tracing these associations enables cross-table investigations: from service to process, from process to account, and so on. All these relationships exist because WMI classes are defined with a meta-model — that's the power of CIM: not just a collection of tables, but an interconnected data graph.

#Conclusion

This episode opens the door to the system information repository: the difference between the legacy Get-WmiObject and the modern Get-CimInstance; exploring WMI classes and their properties; mastering important classes like Win32_OperatingSystem, Win32_LogicalDisk, and Win32_Process; filtering data with -Filter and WQL; managing CIM sessions for efficient remote access; and tracing relationships between classes with Get-CimAssociatedInstance.

Key takeaways:

• Use Get-CimInstance, not Get-WmiObject, for all new scripts.
• Get-CimClass to explore class structure and properties.
• Filter at the source with WQL, not in the pipeline.
• New-CimSession for repeated queries to the same computer; don't forget Remove-CimSession.
• CIM associations connect classes — follow the trail for investigations.

CIM gives you structured data from inside the system. Episode 17 opens an even wider door: interacting with applications and frameworks outside PowerShell — COM Objects & .NET Integration — automating Excel, calling .NET methods, and even injecting your own C# code. See you in episode 17!