Original author(s) | Microsoft |
---|---|
Developer(s) | Microsoft |
Operating system | Microsoft Windows |
Platform | IA-32, x86-64, and ARM (historically Itanium, DEC Alpha, MIPS, and PowerPC) |
Type | Systems management |
License | Proprietary |
Website | learn |
Windows Management Instrumentation (WMI) consists of a set of extensions to the Windows Driver Model that provides an operating system interface through which instrumented components provide information and notification. WMI is Microsoft's implementation of the Web-Based Enterprise Management (WBEM) and Common Information Model (CIM) standards from the Distributed Management Task Force (DMTF).
WMI allows scripting languages (such as VBScript or Windows' PowerShell) to manage Microsoft Windows personal computers and servers, both locally and remotely. WMI comes preinstalled in Windows 2000 through Windows 11 OSes. It is available as a download for Windows NT and[1] Windows 95 to Windows 98.[2]
Microsoft also provides a command-line interface to WMI called Windows Management Instrumentation Command-line (WMIC).[3] However, WMIC is deprecated starting with Windows 10, version 21H1, Windows 11 and Windows Server 2022.[4]
The purpose of WMI is to define a proprietary set of environment-independent specifications which allow management information to be shared between management applications. WMI prescribes enterprise management standards and related technologies for Windows that work with existing management standards, such as Desktop Management Interface (DMI) and SNMP. WMI complements these other standards by providing a uniform model. This model represents the managed environment through which management data from any source can be accessed in a common way.
Because WMI abstracts the manageable entities with CIM and a collection of providers, the development of a provider implies several steps. The major steps can be summarized as follows:
Since the release of the first WMI implementation during the Windows NT 4.0 SP4 era (as an out-of-band download), Microsoft has consistently added WMI providers to Windows:
Many customers[which?] have interpreted the growth in numbers of providers as a sign that WMI has become at Microsoft the "ubiquitous" management layer of Windows, even if Microsoft has never made this commitment explicit.
Because of a constant increasing exposure of management data through WMI in Windows, people in the IT systems management field started to develop scripts and automation procedures based on WMI.[citation needed] Beyond the scripting needs, most leading management-software packages, such as MOM, SCCM, ADS, HP OpenView for Windows (HPOV), BMC Software, and CA, Inc. are WMI-enabled and capable of consuming and providing WMI information through various user interfaces. This enables administrators and operators not capable of scripting or programming on top of WMI to enjoy the benefits of WMI without even learning about it. However, if they want to, because WMI is scriptable, it gives them the opportunity to consume WMI information from scripts or from any WMI-aware enterprise-management software.
For someone willing to develop one or many WMI providers, WMI offers many features out of the box. Here are the most important advantages:
System.Management
namespace [7] relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all .NET applications independently of the language used (e.g. C#, VB.NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the .NET Framework as this support is already available from WMI for free.Some WMI tools can also be useful during the design and development phases. These tools are:
MOFComp.exe
is included in every WMI installation. Every definition existing in the CIM repository is initially defined in an MOF file. MOF files are located in %SystemRoot%\System32\WBEM
. During the WMI setup, they are loaded in the CIM repository.WinMgmt.exe
is not a tool; it is the executable that implements the WMI Core service. Under the Windows NT family of operating systems, WMI runs as a service. On computers running Windows 98, Windows 95, or Windows Me, WMI runs as an application. Under the Windows NT family of operating systems, it is also possible to run this executable as an application, in which case, the executable runs in the current user context. For this, the WMI service must be stopped first. The executable supports some switches that can be useful when starting WMI as a service or as an application. WMI provider developers who may want to debug their providers essentially need to run the WMI service as an application.[9]WBEMTest.exe
is a WMI tester tool, which is delivered with WMI. This tool allows an administrator or a developer to perform most of the tasks from a graphical interface that WMI provides at the API level. Although available under all Windows NT-based operating systems, this tool is not officially supported by Microsoft. WBEMTest provides the ability to:
Developer(s) | Microsoft |
---|---|
Operating system | Microsoft Windows |
Type | Command |
License | Proprietary commercial software |
Website | docs |
wmic /?
at the command-line displays a complete list of the switches and keywords. (In Windows 11, wmic /?
displays "WMIC is deprecated.", followed by the help text.)
WBEMDump.exe
requires more specific knowledge about WMI, as it doesn't abstract WMI as WMIC. However, it runs under Windows NT 4.0 and Windows 2000. It is also possible to execute methods exposed by classes or instances. Even if it is not a standard WMI tool delivered with the system installation, this tool can be quite useful for exploring the CIM repository and WMI features.In the .NET Framework, the ManagementClass class represents a Common Information Model (CIM) management class. A WMI class can be a Win32_LogicalDisk
in the case of a disk drive, or a Win32_Process
, such as a running program like Notepad.exe
.
This example shows how MSNdis_80211_ServiceSetIdentifier
WMI class is used to find the SSID of the Wi-Fi network that the system is currently connected to in the language C#:
ManagementClass mc = new ManagementClass("root\\WMI", "MSNdis_80211_ServiceSetIdentifier", null);
ManagementObjectCollection moc = mc.GetInstances();
foreach (ManagementObject mo in moc)
{
string wlanCard = (string)mo["InstanceName"];
bool active;
if (!bool.TryParse((string)mo["Active"], out active))
{
active = false;
}
byte[] ssid = (byte[])mo["Ndis80211SsId"];
}
The MSNdis_80211_ServiceSetIdentifier
WMI class is only supported on Windows XP and Windows Server 2003.
The WMI extensions to WDM provide kernel-level instrumentation such as publishing information, configuring device settings, supplying event notification from device drivers, and allowing administrators to set data security through a WMI provider known as the WDM provider. The extensions are part of the WDM architecture; however, they have broad utility and can be used with other types of drivers as well (such as SCSI and NDIS).
The WMI Driver Extensions service monitors all drivers and event trace providers that are configured to publish WMI or event trace information. Instrumented hardware data is provided by way of drivers instrumented for WMI extensions for WDM. WMI extensions for WDM offer a set of Windows device driver interfaces for instrumenting data within the driver models native to Windows, so OEMs and IHVs can easily extend the instrumented data set and add value to a hardware/software solution. The WMI Driver Extensions, however, are not supported by Windows Vista and later operating systems.[11]