WMI stands for Windows Management Instrumentation. Designed by Microsoft, it is an infrastructure for the standardized management of data and information that is device independent. Since Windows 2000, WMI comes preinstalled with Windows operating systems.
WMI is the Microsoft implementation of the Web-Based Enterprise Management (WBEM), which is managed by the Distributed Management Task Force (DMTF). WBEM sets standards to allow access to data from non-uniform technologies and devices across a standardized architecture. WBEM uses the Common Information Model (CIM) as the schema for defining information about objects.
Although not directly a part of WMI, CIM is a vendor-neutral standard for representing management information of various devices. It is also maintained by the DMTF.
WMI uses this schema for storing information in the WMI repository. It is structured so that the managed environment can be seen as interrelated systems, each composed of discrete elements. A predefined set of classes and properties creates a framework that individual vendors build from.
To function as a server, a device must be configured to listen to requests from clients on a network connection. This functionality can exist as part of the operating system as an installed application, role, or a combination of the two.
For example, Microsoft’s Windows Server operating system provides the functionality to listen to and respond to client requests. Additionally installed roles or services increase which kinds of client requests the server can respond to. In another example, an Apache web server responds to Internet browser requests via an additional application, Apache, installed on top of an operating system.
When a client requires data or functionality from a server, it sends a request over the network. The server receives this request and responds with the appropriate information. This is the request and response model of client-server networking, also known as the call and response model.
A server will often perform numerous additional tasks as part of a single request and response, including verifying the identity of the requestor, ensuring that the client has permission to access the data or resources requested, and properly formatting or returning the required response in an expected way.
As devices on a network operate, various settings, parameters, and states can be measured and generated at any given time. For example, a hard disk drive has a total storage capacity, a used storage capacity, a free storage amount, or an internal temperature. These values are dynamic and change with system usage. At any given moment, the readings exist whether anyone notices them or not.
The WMI platform offers a uniform way to create and execute scripts that read, and in some cases, can change such settings without needing to install additional software agents or monitors. In the case of the hard drive, a WMI provider would be able to reply to a request for the hard drive’s temperature as well as send an alert to the WMI Object Manager should the temperature exceed a preset level.
In addition, for the management applications, the WMI platform offers an Application Programming Interface (API) at the WMI Object Manager level so that there is no need to understand the specifics of an individual WMI provider. The management application only needs to call the Object Manager and not directly query the hard drive itself, for example.
When a device is queried or an event is triggered, data travels through the standard architecture of the managed device via its WMI provider to the WMI Object Manager and on to the WMI consumer. This entire infrastructure is standardized across devices and platforms so that any WMI-enabled enterprise management software may access the data gathered on any WMI-enabled device without needing to know anything about the devices or the structure of the network between them. WMI is available on any current Windows computer and so can be managed via WMI.
WMI is an integrated part of the Windows operating system. The WMI infrastructure is implemented in Windows as the WMI service. The WMI service acts as an intermediary between WMI providers, the WMI repository, and managing applications. The WMI service runs with the display name Windows Management Instrumentation under the service name winmgmt. It runs automatically at startup, and if stopped, it will automatically start when a management application or script requests a connection to any WMI namespace.
A managed object is any logical or physical component or service that may be managed via WMI. This may include processors, network adapters, operating systems, services, applications, disk drives, memory, or any other network-attached equipment.
In general, if the parameter in question can be accessed via another Windows tool, such as a performance monitor, then the same information can be accessed via WMI.
A WMI provider is an object that monitors, reads, and collects whichever data it is programmed to monitor on a specific managed object. Like device drivers, some monitors are built into the operating system, while others are implemented by third-parties or programmatically, usually via C/C++, Visual Basic, VBScript, or PowerShell. The provider may also be accessed via the command line (Windows Management Interface Command-line, or WMIC).
Monitors may be general or device specific. The monitor itself does nothing but watch or monitor data as it is generated. Monitors do not log or store data, although they can be set up to write data to a logfile or to the Event Viewer if a certain condition is met.
There are numerous built-in WMI providers in Windows, including an Active Directory provider, Boot Configuration Data (BCD) WMI provider, Distributed File System (DFS) provider, Event Log provider, Hyper-V WMI provider, Win32 provider, Registry provider, and SNMP provider. The SNMP provider maps SNMP MIB objects to WMI CIM classes. This offers a way to use WMI even on non-Windows devices via their built-in SNMP.
WMI providers respond to direct queries from management applications or scripts as well as to programmed events. Configuring an event requires an event trigger and event subscribers. The trigger is set by defining when an event becomes reportable or triggered. For example, an event might be triggered when the amount of free disk space drops below a certain amount. As the WMI provider runs, it simply monitors the amount of free disk space. When the amount drops below the preset threshold, the WMI provider alerts the CIM Object Manager. The CIM Object Manager then forwards the alert to the predefined event consumers or subscribers, which are typically enterprise management applications or event logs.
Each WMI provider implements the functionality of its classes. Classes contain events and properties that allow for the actual capture and setting of data. WMI system classes are predefined classes that provide the basic functionality of WMI. These classes start with a double underscore, such as __SystemEvent, which represents a system event. There are also MSFT classes that are either policy provider classes or WMI troubleshooting classes. CIM classes can be used when building new classes. The new classes will inherit properties from their parent CIM class.
There are also standard consumer classes. These are used to run scripts or programs when a triggering event occurs. One commonly used standard consumer class is the ActiveScriptEventConsumer, which runs a script when it receives a response. This is a way to create an automatic response to a particular event or situation, such as sending a message, stopping or starting a service, or even rebooting and shutting down a system or component.
Some classes have methods that offer the specific data that may be monitored or altered. For example, the Win32_Service class has methods for stopping and starting services. These methods can be accessed via a scripting application or via a network management application.
The WMI repository is a database that stores static data relating to WMI. Dynamic data monitored by WMI providers is not stored in the repository. To retain dynamic data, it must be captured by a WMI provider and retrieved or reported by a WMI management application or logged via a WMI provider class. WMI uses a CIM-compliant object repository.
CIM Object Manager
The CIM Object Manager acts as an intermediary between a management application and the WMI providers. Accessed from the application-side by the WMI API, the Object Manager forwards requests for data to the WMI providers and receives the reply before forwarding the information back to the requesting management application.
The API provides access to the WMI infrastructure for applications that use WMI. These applications make API calls that are passed down into the CIM Object Manager and then sent to the providers. These respond via the classes and methods with data such as system uptime or the number of running processes.
The consumer is what sends queries and receives information from a WMI provider via the WMI Object Manager. Typically, a WMI consumer is either a monitoring application, such as PRTG Network Monitor, a management application, or a script, such as a PowerShell script, which queries values on a remote system before carrying out some action like updating software or writing a file.
For example, an administrator scripting an update can first use PowerShell to query a WMI provider to check the Windows version before sending the update. The consumer may query WMI providers for values that can be monitored or even altered by an administrator. Only certain values are writable in this way.
The ability to remotely access and modify device information and data must be secured. Windows provides several layers of security that protect remote systems. The Windows Defender Firewall has a specific setting for WMI traffic separate from the usual DCOM traffic setting. If WMI is blocked by the firewall, a connection cannot be established.
In addition, standard User Account Control (UAC) access token filtering affects WMI operations. Even when logged in as administrator, WMI-based programs or scripts will run with standard UAC access token filtering unless specifically run with elevated privileges (“Run as Administrator”). In many circumstances, methods and classes of WMI providers access privileged data and require higher access permissions to run properly.
At first glance, PowerShell seems to have little support for WMI. However, a single Get-WmiObject cmdlet actually allows access to most WMI parameters. The Get-WmiObject cmdlet can use the -ComputerName parameter to access a remote computer. For example, Get-WmiObject -Class Win32_service -ComputerName Accounting235 would get a list of services (and their current status) that are running on a remote computer named Accounting235.
Although WMI can be used via several scripting languages, including PowerShell, it does have its own command-line interface. The WMIC is compatible with existing shells, including the standard Windows command-line. To use, simply type wmic and the command.
- wmic os list FREE - Lists information about the free memory on the system
- wmic os list BRIEF - Lists the computer’s build number, serial number, and version number
The SET command can change or write to certain parameters. Using the /? switch brings up a list of writable properties. For example, it is possible to set the current time zone using the set os command.
- wmic os set CurrentTimeZone=600 - Sets the time zone to Sydney, Australia time. If it isn’t run as administrator, access will be denied.
Microsoft now offers Windows Management Infrastructure (MI), which is the latest version of WMI. According to Microsoft, MI is fully compatible with earlier versions of WMI and offers reduced development time and tighter integration with PowerShell.
- About WMI - Microsoft Developer Network
- MI providers and clients - Microsoft Developer Network
- Windows Management Instrumentation and the Common Information Model - Microsoft Developer Network
- Windows Management Instrumentation - Wikipedia
- Paessler WMI Monitoring
- Common Information Model (computing) - Wikipedia
- Why use MI - Microsoft Developer Network
- CIM tutorial