Windows Management Instrumentation Part 1 – The Basics
What is WMI and how does it work?
I recently developed an interest in WMI and I must be honest and say that it was quite challenging to understand it. I don’t pretend I fully know WMI now, but I know enough to feel comfortable accessing it through PowerShell.
WMI stands for Windows Management Instrumentation and it’s a core Windows technology for managing local and remote computers. WMI is Microsoft’s implementation of WBEM (Web-Based Enterprise Management) and uses the CIM (Common Information Model) standard to represent data.
WMI was first released during Windows NT 4.0 Service Pack 4 and was available as an install for Windows NT, Windows 95 and Windows 98. Starting Windows 2000 it comes pre-installed and part of the core operating system. WMI puts forth an interface that allows scripting languages to interact with it and through which computers are managed. Over time, multiple scripting and programming languages have implemented support for WMI. This post and all upcoming posts about WMI will deal with PowerShell as the scripting language of choice. PowerShell is highly integrated with WMI and offers a wide variety of commands to interact with it.
In short, WMI is a framework aimed at administering the Windows OS. The WMI architecture can be cumbersome but if you take the time to understand it, it’s not so bad. Below is the official WMI architecture from Microsoft’s website.
WMI is broken down into 3 main components:
- Providers and objects
WMI Providers and Objects
A WMI object is an instance (a concrete ‘thing’) of a specific software or hardware component (WMI classes). A few examples of WMI objects are network shares, processes, physical memory, users, etc.
WMI providers monitor WMI objects and facilitate the message exchange from WMI to said objects. Think of the WMI provider as a driver. It consists of a DLL and MOF files. The MOF files define all components and their properties for which a certain provider is responsible for. Both DLL and MOF files can be found under ‘$env:windr\system32\wbem’ path. MOF files are compiled at startup and stored into ‘$env:windr\system32\wbem\repository\objects.data’. This contains all component (classes) definitions for the WMI repository.
The WMI Infrastructure is represented by the system service ‘winmgmt’ (WMI service) and consists of the CIM Object Manager and WMI repository.
The CIM Object Manager (also known as WMI core) is responsible for handling the communication between WMI providers and the applications / scripts that interact with WMI.
The WMI repository is a storage area where all class definitions are stored. The repository has a structure like that of an object-oriented programming language. Meaning it’s organized into namespaces, each containing multiple classes. Each class may have zero, one or multiple instances.
Namespaces are created by providers and they correspond to a specific product / role / technology. For example, the Active Directory Provider is installed when you install the Active Directory Domain Services role and it creates a corresponding namespace.
A consumer is a management application or script that talks to WMI. PowerShell is my scripting language of choice for working with WMI.
Windows Management Infrastructure
The evolution of WMI is Windows Management Infrastructure (MI) and was introduced with Windows 8 and Windows 2012. MI is entirely based on the CIM standard and is compatible with older versions of WMI.
Moving on …
Now that we covered the basics we can go a bit further. So ‘Winmgmt’ is the glue (actually it’s a service, but … semantics 🙂 ) that holds WMI together.
Let’s learn more about this service on your running computer.
Get-Service WinMgmt | Format-List *
Can we learn more about this service? Well yes, but that involves using WMI to get that information. So, I’ll use WMI to find information about the WMI service. Easy, right?
Get-WmiObject -Class Win32_Service | Where-Object Name -eq 'Winmgmt' | Format-List *
Now, this is the kind of verbosity that I like. I’ll cover WMI classes, instances and how to use PowerShell with WMI in future posts. For now, just know that the above command retrieves all services with the name of ‘Winmgmt’.
Let’s talk more about providers. When an application wants to monitor data through WMI, it must load the provider for the info it needs. The ‘WmiPrvSE.exe’ process is the process that loads a needed provider and makes the corresponding namespace available. There are a few ways to find out what providers are currently loaded on your operating system. The fastest way would be to use Process Explorer from Sysinternals and check for the ‘WmiPrvSe.exe’ process. Under properties look for the WMI Providers tab.
That’s it for now. Be on the lookout for part 2.
Feel free to ping me if you have a question or if I got anything wrong in here.