Introduction to WMI

Author by Mitchell Grande

The average Windows administrator has come across WMI at least a few times, maybe while troubleshooting an issue or building out a monitoring solution.  WMI is a centralized repository of information within the Windows server, and understanding how to effectively use it can simplify some administrative tasks.

What is WMI

WMI - Windows Management Instrumentation - can be thought of like a database of information about a Windows computer.  Nearly every piece of information about a Windows device is stored within the WMI repository.  Some examples of data types are: network interfaces, physical and logical disks, local user accounts, performance data, and many others.  In addition to storing data about these different types of objects, some of them have functions, known as methods, that you can invoke to change their settings.  For example, the NetworkAdapterConfiguration object has methods for setting the DNS server addresses and configuring a static IP.

Repository Structure

All of the data in WMI is stored in a central location called the repository.  The repository is made up of multiple namespaces that separate the data into different segments.  The most common namespace is named "root\cimv2" and is generally used for day-to-day management.  Within each namespace are classes, which represent a specific type of object and its available data.  Examples of classes include Win32_Process, Win32_UserAccount, and Win32_DiskDrive.  The class is simply the definition of the available data.  The actual information about the objects are stored in instances of the relevant class type.  For example, there is an instance of Win32_Process for each running process on the computer.  Similarly, there is an instance of Win32_DiskDrive for each of the physical disks attached to the machine.  Finally, it's possible to have no instances of a defined class.  For example, the Win32_POTSModem class represents a telephone modem attached to the computer.  You'd be hard pressed to find any instances of that nowadays.

The structure of data in WMI can be visualized like this, although there are many more namespaces, classes, and instances than are shown here:


How to Access Information in WMI

The data in WMI is primarily accessed by installed software to learn about the system that they're installed on.  For example, a data replication application may use the Win32_DiskDrive class to learn which disks exist and need to be replicated.  However, you can use WMI in your own scripts to automate functionality or discover information that may not be available in the GUI.  In addition to using scripts, you can manually browse the WMI repository using a UI tool called WbemTest.

To write your own PowerShell scripts to interact with WMI, you primarily use the Get-WmiObject command.  This command will return all instances of the given type from the WMI repository.  Here are some sample code snippets using Get-WmiObject:

Get-WmiObject -List                                                     #List all available WMI classes
Get-WmiObject -Class "Win32_UserAccount"                                #Get local user accounts on this serverGet-WmiObject -Class "Win32_PrintJob" -ComputerName "ABC-PRINT-01"      #Get the print jobs from ABC-PRINT-01

Notice how the last command is targeting another server.  One of the most convenient things about WMI is that it is readily available over the network.  As long as you open the required firewall port, you can query remote systems without any additional configuration.  Within PowerShell, you simply add the ComputerName parameter to retrieve the information from another device.

To browse the WMI repository through the UI, launch the WbemTest program by running wbemtest at a command prompt.  Once open, press the connect button on the top right, then press the Connect button again on the popup.


This will connect you to the default repository on the local system.  Once connected, use the "Enum Classes" button to list all of the classes available in the current namespace.  Switch the option to Recursive to ensure you get the complete list.  Then double click a class name in the result to open the details about it.  Finally, press the Instances button to open another window with a list of the instances of that class type.


Practical Use Cases

Now that we've learned about what WMI is, let's think about some real-world use cases.  Since it's so easy to connect to and retrieve data from remote machines with PowerShell, a very common use for WMI is to discover data about multiple systems at once.  For example, if you are decommissioning an AD Domain Controller, you might want to search all the servers in the environment to see if any are using it for DNS resolution.  The DNS client settings are available in the Win32_NetworkAdapterConfiguration class, making it easy to find them en masse.  Another example is searching the environment for an installed Windows service using the Win32_Service class, or the installation of a specific KB using the Win32_QuickFixEngineering class.  Here is a code sample that will find all servers that have the "MyService" service installed:

$ServersToSearch = @("SERVER01", "SERVER02", "SERVER03", "SERVER04", "SERVER05")
foreach($Server in $ServersToSearch) {
    $SearchResult = Get-WmiObject -Class "Win32_Service" -ComputerName $Server
    if($SearchResult | Where-Object {$_.Name -eq "MyService"}) {
        Write-Host "Server $($Server) has MyService installed"

Mitchell Grande

Systems Engineer

Tags in this Article