- Windows Management Instrumentation
- Purpose
- Where applicable
- Developer audience
- Run-time requirements
- In this section
- About WMI
- Managing Remote Computer Systems with WMI
- Programming with WMI
- Starting and Stopping the WMI Service
- Starting Winmgmt Service
- Stopping Winmgmt Service
- Examples
- WMI Architecture
- Objects, Consumers, and Infrastructure of WMI
- WMI Components
- Using WMI
- Obtaining Data from WMI
- Providing Data to WMI
- Important Tasks for WMI
Windows Management Instrumentation
Purpose
Windows Management Instrumentation (WMI) is the infrastructure for management data and operations on Windows-based operating systems. You can write WMI scripts or applications to automate administrative tasks on remote computers but WMI also supplies management data to other parts of the operating system and products, for example System Center Operations Manager, formerly Microsoft Operations Manager (MOM), or Windows Remote Management (WinRM).
The following documentation is targeted for developers and IT administrators. If you are an end-user that has experienced an error message concerning WMI, you should go to Microsoft Support and search for the error code you see on the error message. For more information about troubleshooting problems with WMI scripts and the WMI service, see WMI Isn’t Working!
WMI is fully supported by Microsoft; however, the latest version of administrative scripting and control is available through the Windows Management Infrastructure (MI). MI is fully compatible with previous versions of WMI, and provides a host of features and benefits that make designing and developing providers and clients easier than ever. For more information, see Windows Management Infrastructure (MI).
Where applicable
WMI can be used in all Windows-based applications, and is most useful in enterprise applications and administrative scripts.
System administrators can find information about using WMI at the TechNet ScriptCenter, and in various books about WMI. For more information, see Further Information.
Developer audience
WMI is designed for programmers who use C/C++, the Microsoft Visual Basic application, or a scripting language that has an engine on Windows and handles Microsoft ActiveX objects. While some familiarity with COM programming is helpful, C++ developers who are writing applications can find good examples for getting started at Creating a WMI Application Using C++.
To develop managed code providers or applications in C# or Visual Basic .NET using the .NET Framework, see WMI in .NET Framework.
Many administrators and IT professionals access WMI through PowerShell. The Get-WMI cmdlet for PowerShell enables you to retrieve information for a local or remote WMI repository. As such, a number of topics and classes, especially in the Creating WMI Clients section, contain PowerShell examples. For additional information on using PowerShell, see Windows PowerShell and Scripting with Windows PowerShell.
Run-time requirements
For more information about which operating system is required to use a specific API element or WMI class, see the Requirements section of each topic in the WMI documentation.
If an expected component appears to be missing, see Operating System Availability of WMI Components.
You do not need to download or install a specific software development (SDK) in order to create scripts or applications for WMI. However, there are some WMI administrative tools that developers find useful. For more information, see the Downloads section in Further Information.
In this section
General information about WMI.
Information about how to develop applications to use WMI, which includes information about tools.
Documentation about the WMI classes, WMI C++ classes, WMI COM API, Scripting API, and other WMI reference material.
About WMI
Windows Management Instrumentation (WMI) is the Microsoft implementation of Web-Based Enterprise Management (WBEM), which is an industry initiative to develop a standard technology for accessing management information in an enterprise environment. WMI uses the Common Information Model (CIM) industry standard to represent systems, applications, networks, devices, and other managed components. CIM is developed and maintained by the Distributed Management Task Force (DMTF).
The next-generation of WMI, known as the Windows Management Infrastructure (MI), is currently available. MI is fully compatible with previous versions of WMI, and provides a host of features and benefits that make designing and developing providers and clients easier than ever. For example, many newer providers are written using the MI framework, but can be accessed using WMI scripts and applications. For more information about the differences between the two technologies, see Why Use MI?
Managing Remote Computer Systems with WMI
The ability to obtain management data from remote computers is what makes WMI useful. Remote WMI connections are made through DCOM. An alternative is to use Windows Remote Management (WinRM), which obtains remote WMI management data using the WS-Management SOAP-based protocol.
Programming with WMI
Management applications or scripts can get data or perform operations through WMI in a variety of languages. For more information, see the Developer Audience section at Windows Management Instrumentation.
Many Windows features have associated WMI providers, like the Boot Configuration Data (BCD) Provider or the Storage Volume Provider. WMI Providers implement the functionality described by WMI classes methods and properties to manage associated Windows features. For more information, see WMI Providers and WMI Classes.
For more information about how to write a provider to supply data from new hardware or applications, see Providing Data to WMI.
For more information about how to implement this technology, see Using WMI.
The following table lists topics included in this section.
Starting and Stopping the WMI Service
WMI runs as a service with the display name «Windows Management Instrumentation» and the service name «winmgmt». WMI runs automatically at system startup under the LocalSystem account. If WMI is not running, it automatically starts when the first management application or script requests connection to a WMI namespace.
Several other services are dependent upon the WMI service, depending on the operating system version that the system is running.
Starting Winmgmt Service
The following procedure describes how to start the WMI service.
To start Winmgmt Service
At a command prompt, enter net start winmgmt [/].
For more information about the switches that are available, see winmgmt. You use the built-in Administrator account or an account in the Administrators group running with elevated rights to start the WMI service. For more information, see User Account Control and WMI.
Other services that are dependent on the WMI service, such as SMS Agent Host or Windows Firewall, will not automatically be restarted.
Stopping Winmgmt Service
The following procedure describes how to stop the WMI Service.
To stop Winmgmt Service
At a command prompt, enter net stop winmgmt.
Other services that are dependent on the WMI service also halt, such as SMS Agent Host or Windows Firewall.
Examples
The TechNet Gallery contains the WMI service watchdog script, which describes how to programmatically shut down and restart the winmgmt service with PowerShell.
WMI Architecture
WMI provides a uniform interface for any local or remote applications or scripts that obtain management data from a computer system, a network, or an enterprise. The uniform interface is designed such that WMI client applications and scripts do not have to call a wide variety of operating system application programming interfaces (APIs). Many APIs cannot be called by automation clients like scripts or Visual Basic applications. Other APIs do not make calls to remote computers.
To obtain data from WMI, write a client script or application that accesses WMI Classes or provide data to WMI by writing a WMI provider. For more information, see Using WMI.
Objects, Consumers, and Infrastructure of WMI
The following diagram shows the relationship between the WMI infrastructure and the WMI providers and managed objects, and it also shows the relationship between the WMI infrastructure and the WMI consumers.
WMI Components
The following list describes the key WMI components:
Managed objects and WMI providers
A WMI provider is a COM object that monitors one or more managed objects for WMI. A managed object is a logical or physical enterprise component, such as a hard disk drive, network adapter, database system, operating system, process, or service.
Similar to a driver, a provider supplies WMI with data from a managed object and handles messages from WMI to the managed object. WMI providers consist of a DLL file and a Managed Object Format (MOF) file that defines the classes for which the provider returns data and performs operations. Providers, like WMI C++ applications, use the COM API for WMI. For more information, see Providing Data to WMI.
An example of a provider is the preinstalled Registry provider, which accesses data in the system registry. The Registry provider has one WMI class, StdRegProv, with many methods but no properties. Other preinstalled providers, such as the Win32 provider, usually have classes with many properties but few methods, such as Win32_Process or Win32_LogicalDisk. The Registry provider DLL file, Stdprov.dll, contains the code that dynamically returns data when requested by client scripts or applications.
WMI MOF and DLL files are located in %WINDIR%\System32\Wbem, along with the WMI Command-Line Tools, such as Winmgmt.exe and Mofcomp.exe. Provider classes, such as Win32_LogicalDisk, are defined in MOF files, and then compiled into the WMI repository at system startup.
The WMI infrastructure is a Microsoft Windows operating system component know as the WMI service(winmgmt). The WMI infrastructure has two components: the WMI Core, and the WMI repository.
The WMI repository is organized by WMI namespaces. The WMI service creates some namespaces such as root\default, root\cimv2, and root\subscription at system startup and preinstalls a default set of class definitions, including the Win32 Classes, the WMI System Classes, and others. The remaining namespaces found on your system are created by providers for other parts of the operating system or products. For more information and a list of WMI providers found in most operating system versions, see WMI Providers.
The WMI service acts as an intermediary between the providers, management applications, and the WMI repository. Only static data about objects is stored in the repository, such as the classes defined by providers. WMI obtains most data dynamically from the provider when a client requests it. You also can set up subscriptions to receive event notifications from a provider. For more information, see Monitoring Events.
A WMI consumer is a management application or script that interacts with the WMI infrastructure. A management application can query, enumerate data, run provider methods, or subscribe to events by calling either the COM API for WMI or the Scripting API for WMI. The only data or actions available for a managed object, such as a disk drive or a service, are those that a provider supplies.
Using WMI
You can use WMI from client applications and scripts. It provides an infrastructure that makes it easy to both discover and perform management tasks. In addition, you can add to the set of possible management tasks by creating your own WMI providers.
The next-generation version of WMI for writing applications and scripts is available through the Windows Management Infrastructure (MI). For more information, see MI Providers and Clients.
The following topics are discussed in this section:
Obtaining Data from WMI
The following procedure describes how to obtain data from WMI by writing a script or application.
To obtain data from WMI by writing a script or application
Decide which language to use. For more information about scripting, see Creating a WMI Script. For more information about C++, see Creating a WMI Application Using C++. For using more information about C# or WMI .NET, see WMI .NET Overview.
You can view or manipulate WMI data in many languages. The following table lists the topics that describe how to use the scripting and application languages to obtain data.
Application language | Topic | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Scripts written in Microsoft ActiveX script hosting, including Visual Basic Scripting Edition (VBScript) and Perl | Scripting API for WMI. Start with Creating a WMI Script. For script code examples, see WMI Tasks for Scripts and Applications and the TechNet ScriptCenter Script Repository. | ||||||||||||||||
Windows PowerShell | Getting Started with Windows PowerShell WMI PowerShell Cmdlets, such as Get-WmiObject. | ||||||||||||||||
Visual Basic applications | Scripting API for WMI. | ||||||||||||||||
Active Server Pages | Scripting API for WMI. Start with Creating Active Server Pages for WMI. | ||||||||||||||||
C++ applications | COM API for WMI. Start with Creating a WMI Application Using C++ and WMI C++ Application Examples (contains examples). | ||||||||||||||||
.NET Framework applications written in C#, Visual Basic .NET, or J# | Classes in the Microsoft.Management.Infrastructure namespace.
Ensure that your connections to remote computers work. Connecting to WMI on remote computers requires the correct security settings, as explained in Maintaining WMI Security. The following table lists the topics that describe how to configure security settings with the scripting and application languages.
After connecting to WMI, you can obtain data through queries and enumerations. Registry data is available through WMI and you can create new keys and values or modify existing ones. You can subscribe to event notifications through WMI, either temporarily between system reboots or permanently. Performance counter data for a system is available through WMI. The system performance library counters are converted to WMI classes. For more information, see Monitoring Performance Data. WMI Tasks for Scripts and Applications describes how to do many administrative tasks with WMI. Providing Data to WMIThe following procedure describes how to supply data to WMI by writing a provider. To supply data to WMI by writing a provider Decide on the type of provider to write. You cannot write a WMI provider in VBScript. However, you can take several other approaches to writing a WMI COM provider: Using the WMI ATL Wizard in Visual Studio. This approach creates an unmanaged COM provider. For more information, see Adding a WMI Instance Provider and Adding a WMI Event Provider. Using COM directly in any integrated development environment. This approach creates an unmanaged COM provider. Using WMI in the .NET Framework to create a managed code provider. This approach creates a managed code provider. Managed code providers can be written in any .NET Framework language, are simpler to write than WMI COM providers, and can obtain data from the WMI CIM-based classes such as Win32 Classes. However, the .NET Framework WMI provider has some limitations. For more information, see Managing Applications Using WMI. Using the provider framework classes is not recommended. The provider framework has been superseded by the WMI ATL wizards, using COM directly, or .NET Framework providers. Creating a WMI COM provider with the provider framework classes is no longer recommended. The following table lists the topics that describe how to use COM or .NET Framework providers.
Important Tasks for WMIThe following topics provide information about using WMI to monitor and control enterprise components. |