Windows Management Instrumentation
Purpose
Windows Management Instrumentation (WMI) is the
Microsoft implementation of Web-Based
Where Applicable
WMI can be used in all Windows-based applications, and
is most useful in enterprise applications.
System administrators can find information about using
WMI on TechNet, and in various books about WMI. 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. C++ or C# developers need some familiarity with COM programming.
About WMI
Windows Management Instrumentation (WMI) is a component of the Windows
operating system that provides management information and control in an
enterprise environment. By using industry standards, managers can use WMI to
query and set information on desktop systems, applications, networks, and other
enterprise components. Developers can use WMI to create event monitoring
applications that alert users when important incidents occur.
WMI offers a variety of programming interfaces such as Microsoft Visual
Basic© Scripting Edition (VBScript), C++, open database connectivity (ODBC),
Visual Basic, or HTML that developers can use to customize management
applications. System administrators can use WMI by using scripts to automate
administration tasks. WMI can integrate with Windows components, such as the
Active Directory directory service to allow for a unified management
experience.
Managing with WMI
Windows Management Instrumentation (WMI) is based on the Web-Based
The purpose of WMI is to provide a standardized means for managing your
computer system, be it a local computer or all the computers in an enterprise.
In its simplest terms, management is little more than the collecting data about
the state of a managed object on the computer system and altering the state of
the managed object by changing the data stored about the object. A managed
object can be a hardware entity, such as a memory array, port, or disk drive.
It can also be a software entity, such as a service, user account, or page
file.
WMI can manage the many components of a computer system. In managing a
hard disk, you can use WMI to monitor the amount of free space remaining on the
disk. You could also use WMI to remotely alter the state of the drive by
deleting files, changing file security, or partitioning or formatting the
drive. Using the WMI framework, you can create a management application that
monitors an enterprise, provides event-based alerts, and allows a user to
control different aspects of an enterprise.
WMI Architecture
The purpose of WMI is to provide a uniform interface for any local or
remote applications or scripts that obtain management data from a computer
system, network, or enterprise. The uniform interface WMI layer means that
applications and scripts which are clients to WMI do not have to call a wide
variety of operating system application programming interfaces (APIs), many of
which cannot be called by automation clients like scripts or Visual Basic
applications. Many operating system APIs also do not make calls to remote
machines.
A management application communicates with WMI through a variety of
languages, such as Visual Basic, C++, ODBC, and ActiveX. All scripting
languages that can handle ActiveX objects can access WMI data. All WMI
interfaces are based on the Component Object Model (COM). After WMI retrieves
data, it stores the data using the Common Information Model (CIM), a public
standard.
The following diagram shows the WMI components.
" Managed objects
and providers
A managed object is a logical or physical enterprise component, such as
a hard drive, network adapter, database system, operating system, process, or
service. A managed object communicates with WMI through a WMI provider that
calls methods in the COM API for WMI.
A provider is a COM object that monitors one or more managed objects for
WMI. Similar to a driver, a provider supplies WMI with data from a managed
object. A provider also handles messages from WMI to the managed object.
For example, the Platform SDK ships with the Registry provider, which
accesses data in the system registry. WMI passes information from the providers
to the WMI infrastructure when client applications and scripts request registry
data. The Registry provider has one WMI class, StdRegProv, with many methods
but no properties. Other providers, such as the Win32 provider, usually have classes
with many properties but few methods, such as Win32_Process or
Win32_LogicalDisk.
" WMI infrastructure
The WMI infrastructure is a Microsoft Windows operating system
component. The WMI infrastructure is made of two components: the Windows
Management service, including the WMI Core, and the WMI repository. The Windows
Management 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.
Most provider classes, such as Win32_LogicalDisk, are defined in Managed
Object Format (MOF) files, then compiled into the WMI repository by mofcomp.exe.
A provider also has a DLL file which contains the code that implements the
classes.
" WMI management
applications and scripts
A management application or script is an application that interacts with
the WMI infrastructure. A management application can query or enumerate
management data data by calling either the COM API for WMI or the Scripting API
for WMI. Management applications can call methods in either API to send
instructions or reconfigure a managed object. The only data or actions available
for a managed object such as a disk drive or a service are those that a
provider supplies.
Managed Objects in WMI
A managed object is an operating system or hardware entity in Windows
Management Instrumentation (WMI) that creates a data representation of an
object. For example, the Win32_Service object monitors and controls a service,
which is an operating system entity. The Win32_Service object has methods that
start, stop, or modify a service. In the WMI repository you can find a
Win32_Service object that represents both a service and the class definition of
the Win32_Service.
The Win32 Provider keeps track of the Win32_Service objects, and
supplies current dynamic and configuration data for the services that
Win32_Service objects represent. For example, you can obtain data such as
whether a service is running from the State property.
Common Information Model
The Common Information Model (CIM) is an extensible, object-oriented
data model that contains information about different parts of an enterprise.
Through Windows Management Instrumentation (WMI), a developer can use the CIM
to create classes that represent hard drives, applications, network routers, or
even user-defined technologies such as a networked air conditioner. By viewing
and making changes to a CIM class, a manager can control different aspects of
the enterprise. For example, a manager could query a CIM class instance
representing a desktop workstation. The manager could then run a script to
modify the CIM workstation instance. WMI would translate any change to the
workstation CIM class instance into a change to the actual workstation.
The CIM is a language-independent programming model that uses
object-oriented techniques to describe an enterprise. Using three levels of
parent/child inheritance, the CIM can describe both general and specific
aspects of an enterprise. The CIM also uses a technique called association to
link different parts of the enterprise model together, and uses schemas to
distinguish different management environments.
The CIM is designed to present a consistent view of logical and physical
objects in a management environment. The CIM represents managed objects using
an object-oriented construct called a class. Like a C++ or COM class, a CIM
class can include properties to describe data and methods to describe behavior.
Like a set of COM classes, the CIM is not tied to any platform. However, WMI
includes an extension to the CIM that describes the Microsoft® Windows®
operating system platforms.
The CIM defines three levels of classes:
" Core
Core classes represent managed objects that apply to all areas of
management. These classes provide a basic vocabulary for analyzing and
describing managed systems. The __Parameters and __SystemSecurity classes are
examples of core classes.
" Common
Common classes represent managed objects that apply to specific
management areas. However, common classes are independent from a particular
implementation or technology. Common classes are an extension of the core
classes. The CIM_UnitaryComputerSystem class is an example of a common class.
" Extended
Extended classes represent managed objects that are technology-specific
additions to the common classes. An extended class typically applies to a
specific platform such as UNIX or the Microsoft® Win32® environment. The
Win32_ComputerSystem class is an example of an extended class.
A developer can derive a class from another class. A derived class
represents a special case of the parent class, and inherits all of the
properties and methods of the parent. For example, Win32_ComputerSystem
inherits from CIM_UnitaryComputerSystem. Inheritance relationships may be
determined using the system properties __Derivation, __Dynasty, and
__SuperClass. The __Derivation system property is an array of strings listing
the entire chain of inheritance up to and including the root class, which is
also included in __Dynasty. The __SuperClass system property shows the
immediate parent of the current class.
WMI also supports associations. An association is a relationship between
two or more different WMI classes. For example, a running workstation usually
has a processor. The WMI association class Win32_ComputerSystemProcessor
associates the workstation class Win32_ComputerSystem with the processor class
Win32_Processor. However, an association class does not have to tie two
dependent classes together. In fact, the primary purpose of an association
class is to show relationships between classes that are not necessarily
dependent on each other. For more information, see Declaring an Association
Class.
Finally, WMI supports the concept of schemas. In the context of WMI, a
schema is a group of classes that describe a particular management environment.
The Platform SDK uses two schemas: the CIM schema and the Win32 schema. The CIM
schema class names begin with CIM_, and the Win32 schema class names begin with
Win32_. The CIM schema contains the definitions for the core and common
classes, while the Win32 schema contains the definitions for the extended
classes that are common to the Win32 environment. However, third-party vendors
can create their own schemas to describe vendor-specific requirements. Because
schemas are designed to be infinitely extensible, a developer can always add
new classes to describe new managed objects in an existing environment. For
simplicity, however, most vendors choose to create schemas that inherit
properties from the CIM or Win32 schemas.
Managed Object Format
Microsoft implements the Common Information Model (CIM) in a variety of
ways. For creating and manipulating CIM classes and instances, Microsoft
provides methods for each of the supported programming languages and
interfaces. However, the most common means of creating a new CIM class is with
the Managed Object Format (MOF) language, which is based on the Interface
Definition Language (IDL), the language for describing COM interfaces.
The MOF language allows a developer to use a standard text editor or
development environment to describe a set of CIM classes that in turn describe
a specific technology. A developer can then use these new classes to model and
control new technologies on an enterprise. For example, a developer may write a
CIM class that describes a manufacturing robot arm or a new word processor
application.
After the developer completes the CIM class description, the MOF
compiler parses the MOF file into the respective CIM classes and adds the
classes to the WMI repository. From there, a provider or management application
can access the CIM classes through the standard COM interfaces. The MOF
compiler is part of the Windows Management Instrumentation core and is
installed by default on Microsoft® Windows® 2000, Windows Millennium Edition
(Me), and Windows XP.
The MOF language is a format for describing CIM classes that is separate
from the traditional C++ or scripting APIs. MOF code provides several
advantages over the traditional methods. MOF code is:
" Efficient.
A class that takes pages to create with a C++ interface requires only
paragraphs to create with MOF code, reducing development time.
" Human-readable.
Compared to Microsoft® Visual C++® or Microsoft® Visual Basic®, MOF code
is very easy to read, reducing future maintenance costs.
" Reusable.
Because a MOF file is not directly part of an application, a developer
can create and share a MOF file describing a specific technology, increasing
the ease of adapting new technologies to an enterprise.
WMI Infrastructure
In the WMI infrastructure, the Windows Management service is the
operating system component that contains the WMI repository. The Windows
Management service is a mediator for when a management application wishes to
send instructions to a provider, or when a provider wishes to send a
notification to a management application. The WMI repository is a storage area
for WMI-related static data.
Windows Management service is implemented as a service process within a
shared service host process SVCHOST.
Windows 2000: Windows Management
service runs as a separate service process.
Windows NT 4.0 and Windows Me/98/95:
Windows Management service runs as a standard executable file.
In all cases, the Windows Management service starts when the first
management application makes a call to connect. Depending on the setup, the
Windows Management service may shut down or go into a low memory profile when
not being called by a management application.
The Windows Management service interacts with management applications
through the COM interface. When an application makes a request through the
interface, the Windows Management service determines whether the request
involves static or dynamic data. If the request involves static data, such as
the name of a managed object, the Windows Management service retrieves the data
from the WMI repository. If the request involves dynamic data, such as the
amount of memory a managed object is currently using, the Windows Management
service always passes the request on to a provider.
The Windows Management service knows where to pass information because
providers register their location with the Windows Management service. A
provider also registers support for particular operations, such as data
retrieval, modification, deletion, enumeration, or query processing. The
Windows Management service uses the provider registration information to match
application requests with the appropriate provider. The Windows Management
service also uses the registration information to load and unload providers, as
necessary. When a provider finishes processing a request, the provider returns
the result back to the Windows Management service. In turn, the Windows
Management service forwards the result on to the application through the COM
interface. For more information, see Developing a WMI Provider.
The Windows Management service writes all
reported errors to the event log. For example, a provider registration failure
is written to the event log so that you know the provider was not registered
successfully.