Microsoft Windows Management Instrumentation and Simple Network Management Protocol

Microsoft Corporation

September 1998

Summary: This paper presents an overview of the Microsoft Windows Management Instrumentation (WMI) technology, an implementation of the Desktop Management Force's (DMTF) Web-Based Enterprise Management (WBEM) initiative, and concentrates on WMI's support for Simple Network Management Protocol (SNMP). This information is intended for developers who are interested in creating SNMP applications that need to integrate with WMI. (10 printed pages)

The Microsoft® Windows® Management Instrumentation (WMI) technology is an implementation of the DMTF WBEM initiative for Microsoft Windows platforms that extends the DMTF Common Information Model (CIM) to represent management objects in Windows management environments. The CIM is an extensible data model for logically organizing management objects in a consistent and unified manner in a managed environment.

WBEM is an industry-wide DMTF initiative and technology that aims to provide a uniform, standardized way to access management information in an enterprise environment. WBEM enables the development of tools and technologies that reduce the complexity and costs of enterprise management. It is based on CIM, also a DMTF standard. By providing such standards, WBEM contributes to the industry-wide efforts to lower total cost of ownership (TCO). TCO refers to the administrative costs associated with computer hardware and software purchases, deployment and configuration, hardware and software updates, training, maintenance, and technical support.

The WBEM initiative results from the cooperative efforts of BMC Software Inc., Cisco Systems Inc., Compaq Computer Corp., Intel Corp., and Microsoft Corp., as well as many other companies active in the DMTF.

WBEM complements and extends existing management protocols and instrumentation such as SNMP, Desktop Management Interface (DMI), and Common Management Information Protocol (CMIP). It does so by providing a point of integration through which data from all of these sources can be accessed.

This paper presents brief overviews of Windows Management Instrumentation technology and Simple Network Management Protocol, and focuses on the SNMP supporting functionality in WMI. It is intended for SNMP application developers interested in understanding how SNMP integrates with WMI.

The Windows Management Instrumentation technology is a management infrastructure that supports the syntax of CIM, the Managed Object Format (MOF), and a common programming interface. The MOF is used to define the structure and contents of the CIM schema in human- and machine-readable form. Windows Management Instrumentation offers a powerful set of services, including query-based information retrieval and event notification. These services and the management data are accessed through a Component Object Model (COM) programming interface. Additionally, support for scripting is provided in the WMI scripting interface.

The goals of the WMI technology are to provide:

• Access to monitor, command, and control any entity through a common, unifying set of interfaces, irrespective of the underlying instrumentation mechanism. WMI is an access mechanism.
• A consistent model of Windows 2000 operation, configuration, and status.
• A COM Application Programming Interface (API) that supplies a single point of access for all management information.
• Interoperability with other Windows 2000 management services. This approach can simplify the process of creating integrated, well-architected management solutions.
• A flexible, extensible architecture. Developers can extend the information model to cover new devices, applications, and so on, by writing code modules called WMI providers, described later in this document.
• A powerful event architecture. This allows management information changes to be identified, aggregated, compared, and associated with other management information. These changes can also be forwarded to local or remote management applications.
• A rich query language. This enables detailed queries of the information model.
• A scriptable API which developers can use to create management applications. The scripting API supports several languages, including Microsoft Visual Basic® development system, Visual Basic for Applications, Visual Basic, Scripting Edition (VBScript), Microsoft JScript® development software, and Perl. Additionally, you can use the Windows Script Host or Internet Explorer to write scripts utilizing this interface. Windows Script Host, like Internet Explorer, serves as a controller engine of ActiveX® scripting engines. Windows Script Host supports scripts written in VBScript, JScript, and Perl.

The WMI technology architecture consists of the following:

• A management infrastructure. This includes the CIM Object Manager (CIMOM) which provides applications with uniform access to management data, and a central storage area for management data called the CIM Object Repository.
• WMI Providers. These function as intermediaries between CIMOM and managed objects. Using the CIMOM APIs, Providers supply CIMOM with data from managed objects, handle requests on behalf of management applications, and generate event notifications.

The management infrastructure consists of the CIM Object Manager and the CIM Object Repository. Applications depend on the Object Manager to handle the interface between management applications and data Providers. The CIM Object Manager facilitates these communications by providing a common programming interface, using COM, to Windows Management Instrumentation. This COM API supplies event notification and query processing services, and is available in several programming languages such as C and C++. Windows Management Instrumentation also supports automation scripting in VBScript, JScript, and Perl, as well as other Windows-supported scripting languages. The CIM Object Repository holds the CIM and extension schemas, and data information or data source details. CIM Object Manager uses the schema data in this repository when servicing requests from management applications for managed objects.

Managed objects are either physical or logical enterprise components that are modeled using CIM. For example, a managed object can be hardware, such as a cable, or software, such as a database application. Management applications can access managed objects through CIM Object Manager.

Management applications are applications or Windows 2000 services that use or process information originating from managed objects. Management applications can access managed object information by making a request to CIM Object Manager through one of the methods in the WMI API.

Using WMI technology, you can create management applications that implement numerous features, such as displaying system information, generating an inventory of information on specific network elements, and processing and responding to events. WMI supports various strategies to create management applications. For example, applications can use the WMI API to access CIM Object Manager directly or they can access CIM Object Manager indirectly by using one of the following methods:

• Hypertext Markup Language (HTML). Web browsers can use HTML. An Internet Server API (ISAPI) layer provides support for HTML and communicates with CIM Object Manager.
• Microsoft Open Database Connectivity (ODBC) driver. Your database applications can use the ODBC driver to combine the ODBC database capabilities with the management capabilities of WMI. This driver enables an application to use various ODBC-based reporting packages and tools, including Microsoft Excel and Microsoft Access.

WMI Providers are standard COM and Distributed Component Object Model (DCOM) servers that function as mediators between managed objects and CIM Object Manager. If the CIM Object Manager receives a request from a management application for data that is not available from the CIM object repository, or for event notifications that are not supported by CIM Object Manager, it forwards the request to a WMI Provider. Providers supply data and event notifications for managed objects that are specific to their particular domain.

The WMI Software Development Kit (previously called the WBEM SDK) includes several built-in Providers. These built-in Providers (or standard providers) supply data from sources such as the system registry. The built-in Providers include:

• Performance Monitor Provider. Provides access to Windows 2000 Performance Monitor data.
• Registry Provider. Provides access to system registry data.
• Registry Event Provider. Sends events when changes occur to registry keys, values, or trees.
• SNMP Provider. Provides access to events and data from SNMP devices.
• Windows 2000 Event Log Provider. Provides access to data and event notifications from the Windows 2000 Event Log.
• Win32® Provider. Provides access to data from the Win32 subsystem.
• WDM Provider. Provides access to data and events from device drivers that conform to the Windows Management Instrumentation interface.

The WMI technology also provides support for third party-created custom Providers. Custom Providers can be used to service requests related to managed objects that are environment-specific. Providers typically use the MOF language to define and create classes. Providers use the WMI API to access the CIM object repository, and to respond to CIMOM requests made initially by applications.

The next section presents a brief overview of SNMP.

Simple Network Management Protocol (SNMP) is a network management standard that defines a strategy for managing TCP/IP and, more recently, Internet Packet Exchange (IPX) networks.

SNMP uses a distributed architecture that includes:

• Multiple managed nodes, each with an SNMP entity called an agent, which provides remote access to management instrumentation.
• At least one SNMP entity referred to as a manager, which runs management applications to monitor and control managed elements. Managed elements are devices such as hosts, routers, and so on; they are monitored and controlled by accessing their management information.
• A management protocol, SNMP, is used to convey management information between the management stations and agents. Management information refers to a collection of managed objects that reside in a virtual information store called a Management Information Base (MIB).

To communicate host information, management systems and agents use SNMP messages. These messages are sent using the User Datagram Protocol (UDP) and are routed between the management system and host by using the Internet Protocol (IP).

A Management Information Base contains the information requested by the management system. The MIB for a networked computer may include information on the configuration and performance of the network interface card, the available hard drive space, the version of drivers and applications, and so on.

When a management system requests information, the following sequence occurs:

• A management system sends a request to an agent using the agent's IP or IPX address.
• The agent forms an SNMP datagram that contains an SNMP message and the community name to which the management system belongs.
• The SNMP agent receives the datagram and confirms the community name. If the community name is valid, the SNMP agent retrieves the appropriate data. If the community name is invalid, the request is rejected. If the agent has been configured to send an authentication trap, a trap message is sent.
• The SNMP datagram is returned to the management system with the requested information.

The following SNMP message types are used:

• Get. This is a request message. SNMP management systems use Get ** messages to request information about a MIB entry on an SNMP agent.
• Getnext. A type of request message that can be used to browse an entire tree of managed objects.
• Getbulk. A type of request that specifies that the agent transfer as much data as possible, within the limits of message size.
• Set. This is used to send and assign an updated MIB value to an agent.
• Notify (or Trap). This is an unsolicited message that an agent sends to a SNMP management system when it detects a certain type of event has occurred locally on the managed host.

SNMP events (or traps) are sent unsolicited to a management station that filters the events; therefore, network traffic is involved. With WMI, the events are filtered locally and only those events passing the filter criteria are sent over the network, thus reducing the required bandwidth for events of interest.

The next sections highlight the WMI SDK SNMP supporting features.

To support SNMP, the WMI SDK provides the following components:

• Class, instance, and event Providers that integrate the SNMP information modeling and processing into WMI. These SNMP providers map collections of object values to property values of CIM class instances.
• An SNMP information module compiler that compiles native SNMP schema information into the format that CIM uses.

The following sections briefly discuss these components. Get detailed information on the WMI SDK.

The SNMP Providers return dynamic information. You can specify the set of classes that the instance Provider will operate against in one of two ways:

• Statically. By creating classes in the CIM object repository namespace associated with the proxy device.
• Dynamically. By using the SNMP class Provider, which returns the set of classes located within the SNMP Module Information Repository (SMIR) namespace.

Additionally, you can also specify whether or not to use correlation for the set of classes returned from the SMIR namespace. Correlated classes define the set of classes that a given SNMP agent is known to support at the time the enumeration occurs. Noncorrelated enumeration returns all classes present within the SMIR namespace, regardless of whether the agent device supports them or not.

The SNMP Providers include:

• SNMP class and instance Providers, which applications use to access and modify data pertaining to SNMP devices.
• SNMP event Providers, which generate events from SNMP traps and notifications. These report the same types of events, but in different formats: Encapsulated and Referent. Encapsulated means that the event class has simple properties describing the information mapped directly from the TRAP-TYPE and NOTIFICATION-TYPE macros, described in the next section. Referent classes abstract the information present within the macros so that properties which share the same class and instance are presented as embedded objects. This allows extraction of the __RELPATH so that the unique instance to which the trap is associated can be retrieved after the receipt of the event. To choose a format, consumers register for a particular class of events.

The SNMP Providers map device data to CIM classes by:

• Enumerating SNMP Class Definitions. To enumerate a set of class definitions, applications can call IWbemServices::CreateClassEnum or IWbemServices::CreateClassEnumAsync.

  MIB objects are mapped to SNMP CIM classes using the OBJECT-TYPE macro; events are mapped to classes using the TRAP-TYPE and NOTIFICATION-TYPE macros.

  The OBJECT-TYPE macro is used to describe the basic characteristics of a MIB object. The SNMPv1 TRAP-TYPE and SNMPv2C NOTIFICATION-TYPE macros describe the characteristics of an SNMP event.

• Instantiating SNMP Class Definitions. To instantiate a class definition, applications can call IWbemServices::GetObject or IWbemServices::GetObjectAsync.

• Enumerating SNMP Class Instances. The SNMP instance Provider services requests to enumerate instances associated with classes that represent device MIBs.

• Instantiating SNMP Class Instances. The SNMP instance Provider processes requests to instantiate instances of classes that represent MIB objects.

• Retrieving SNMP Class Instances. To retrieve a particular instance of an SNMP CIM class, applications can call IWbemServices::GetObject or IWbemServices::GetObjectAsync.

The schema that SNMP uses to define objects differs from that used in the WMI Common Information Model. The SNMPv1 and SNMPv2 schema is called the Structure of Management Information (SMI); it is packaged as MIB files. To define objects, the MIB files use Abstract Syntax Notation 1 (ASN.1), a standard language, and macro definitions that are used as templates for describing the objects. These macros supply information about the object, including its name, identifier, syntax, description, access rights, and so on.

The WMI SNMP Providers convert these MIB macros:

• OBJECT-TYPE. Describes the basic characteristics of an object, such as the object name, syntax, access rights, and so forth. Pertains to SNMPv1 and SNMPv2C.
• TEXTUAL-CONVENTION. Assigns a name and, in some cases, a range of values to an existing datatype. Pertains to SNMPv2C only.
• TRAP-TYPE. Describes event messages (traps). Pertains to SNMPv1 only.
• NOTIFICATION-TYPE. Describes event messages (notifications). Pertains to SNMPv2C only.

The SNMP class Provider enumerates and instantiates a set of class definitions against a CIM namespace. It does so by using an MIB correlator and the SNMP Module Information Repository, an SNMP schema database. The SNMP class Provider supports correlated and noncorrelated modes. You designate one of these modes by setting a context value (IWbemContext) correlate of type Boolean and passing this into the IWbemServices method. The SNMP class provider supports both enumeration of class definitions and retrieval of a class definition.

The SNMP instance provider maps SNMP MIB objects to class instances.

To define a view of a network device, an SNMP namespace is used. You can create an SNMP namespace by using the WMI SDK's WMI CIM Studio application, compiling a MOF file, or programmatically with the WMI API.

The Namespace system class is used to represent an SNMP namespace. To generate a new namespace, you create an instance of this class. You must associate at least one descriptor (or qualifier) with the class instance. The qualifiers contain implementation-specific context information and transport properties that define how the SNMP Providers access an SNMP agent.

SNMP devices are represented within WMI by using a proxy namespace that contains a set of instance qualifiers. These qualifiers describe the transport characteristics pertaining to the device. WMI uses a MOF file, snmpreg.mof, to create the \\.\root\snmp\localhost namespace—this is a standard namespace that represents the local SNMP agent. For additional details, refer to the WMI SDK.

The SNMP information module compiler is used to compile native SNMP management information that is defined in an MIB into an equivalent CIM schema definition that can be used with the SNMP Providers. The CIM schema can exist as output in an MOF file or it can be loaded into an SNMP schema database (the SNMP Module Information Repository or SMIR). The SNMP dynamic class Provider uses the SNMP Module Information Repository to create and retrieve instances of class definitions.

The SNMP information module compiler runs in command-line mode as an executable file, using one SNMP information module as input, and any additional files that might be needed to resolve external references. SNMP information modules are collections of management information that typically consist of a combination of MIB modules and AGENT-CAPABILITIES and MODULE-COMPLIANCE statements. AGENT-CAPABILITIES statements describe an agent's compliance to the set of MIB modules it supports. MODULE-COMPLIANCE statements describe an agent's capabilities regarding object definitions.

The SNMP information module compiler also provides the following functionality:

• Performs checking operations on the information module. For example, it checks local syntax and external references against information in the subsidiary modules.
• Removes all previously loaded data from the SMIR, or removes data loaded from one information module.
• Returns either the ASN.1 module name of a specified file or the ASN.1 module names of all imported modules in a specified file.
• Returns the ASN.1 module names of all SNMP information modules currently loaded in the SMIR.
• Performs automatic resolution of imported modules instead of requiring users to manually specify the required modules.
• Performs a silent-loading mode of operation that does not generate output, but can be used to load data into the SMIR during an installation operation.

The WMI SDK SNMP-supporting components provide the following advantages:

• Seamless integration of the modeling and manipulation of SNMP management information into WMI. Using the class, instance, and event SNMP Providers, you can easily map MIB object values to property values in instances of CIM classes.
• The ability to compile native SNMP schema information into the format that CIM uses. Using the SNMP information module compiler you can compile native SNMP management information, defined in a MIB, into the equivalent CIM schema definitions that can be used with SNMP Providers.

For the latest information on Windows 2000 Server, check out our World Wide Web site at www.microsoft.com/ntserver/ and the Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS).

For more information on the WBEM initiative, check https://www.dmtf.org/.

More information on Windows Script Host is available at https://msdn.microsoft.com/library/en-us/script56/html/wsoriWindowsScriptHost.asp.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This article is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.