The Event Log provider makes extensive use of inheritance. Screen 1 shows a view of the WMI CIM Studio, a class browser that ships with the WMI SDK. (Microsoft supplies the WMI SDK with Microsoft Developer Network—MSDN—software.) You can see where the Event Log provider relies on inheritance in the provider's Win32_NTEventlogFile class, which derives from CIM_DataFile. Event Log files are data files that have additional Event Log-specific attributes such as a log file name and a count of the number of records that the file contains. The tree that the class browser shows reveals that Win32_NTEventlogFile is based on several levels of inheritance, in which CIM_DataFile derives from CIM_LogicalElement, and CIM_LogicalElement derives from CIM_ManagedSystemElement.
As I stated earlier, WMI class-provider developers write their classes in MOF. Screen 2, page 78, shows the definition of the Event Log provider's Win32_NTEventlogFile, which is selected in Screen 1. Note the correlation between the first six properties that the right panel lists in Screen 1 and those properties' definitions in the MOF file in Screen 2. CIM Studio uses yellow arrows to tag those properties that a class inherits. Thus, you don't see those properties specified in Win32_NTEventlogFile's definition.
One term worth reviewing is dynamic, which is a descriptive designator for the Win32_NTEventlogFile class that the MOF file in Screen 2 shows. The term means that the WMI infrastructure asks the WMI provider for the values of properties associated with a class whenever a management application queries the properties. A static class is one for which the provider stores the properties in the WMI repository; the WMI infrastructure refers to the repository to obtain the values instead of asking the provider for the values. Because updating the repository is a relatively expensive operation, dynamic providers are more efficient for objects that have properties that change frequently.
After constructing classes in MOF, WMI developers can supply the class definitions to WMI in several ways. One way is for WMI developers to compile an MOF file into a binary MOF (BMF) file—a more compact binary representation than an MOF file—and give the BMF files to the WMI infrastructure. Another way is for the provider to compile the MOF and use WMI COM APIs to give the definitions to the WMI infrastructure. Finally, a provider can use the mofcomp tool to directly give the WMI infrastructure a classes-compiled representation.
The WMI Namespace
Classes define the properties of objects, and class instances represent objects on a system. WMI uses a namespace that contains several subnamespaces that WMI arranges hierarchically to organize object instances. A management appli-cation must connect to a namespace before the application can access objects within the namespace.
WMI names the namespace root directory root. All WMI installations have four predefined namespaces that reside beneath root: CIMV2, Default directory, Security, and WMI. Some of these namespaces have other namespaces within them. For example, CIMV2 includes the Applications and ms_409 namespaces as subnamespaces. Providers sometimes define their own namespaces; you can see the WMI namespace (which the Windows device driver WMI provider defines) beneath root on Win2K.
Unlike a file-system namespace, which comprises a hierarchy of directories and files, a WMI namespace is only one level deep. Instead of using names as a file system does, WMI uses object properties that it defines as keys to identify the objects. Management applications specify class names with key names to locate specific objects within a namespace. Thus, each instance of a class must be uniquely identifiable by its key values. For example, the Event Log provider uses the Win32_NTLogEvent class to represent records in an event log. This class has two keys, LogFile and RecordNumber, both of which are strings. A management application that queries WMI for instances of Event Log records obtains from the provider key pairs that identify records. The application refers to a record using the syntax that you see in this example object pathname: \\MARKLAPTOP\CIMV2:Win32_NTLogEvent.Logfile="Application",RecordNumber="1". The first component in the name identifies the computer on which the object is located, and the second component is the namespace in which the object resides. The class name follows the colon, and key names and their associated values follow the period. A comma separates the key values.
Class Association
Many object types are related to one another in some way. For example, a computer object has a processor, installed software, an OS, active processes, and so on. WMI lets providers construct an association class to represent a logical connection between two different classes. Association classes associate one class with another, so the classes have only two properties. Because the properties are references to classes, the properties consist of a class name and the Ref modifier. Screen 3 shows an association in which the Event Log provider's MOF file associates the Win32_NTLogEvent class with the Win32_ComputerSystem class. Given an object, a management application can query associated objects. In this way, a provider defines a hierarchy of objects.
Screen 4, page 80, shows the WMI Object Browser (another development tool that the WMI SDK includes) viewing the root of the CIMV2 namespace. Win32 system components typically place their objects within the CIMV2 namespace. Object Browser first locates the Win32_ComputerSystem object instance "MARKLAPTOP", which is the object that represents the computer. Then, Object Browser obtains the objects associated with Win32_ComputerSystem and displays them beneath "MARKLAPTOP". The Object Browser user interface (UI) displays association objects with a double-arrow folder icon. The associated class type's objects display beneath the folder.
You can see in Object Browser that the Event Log provider's association class Win32_NTLogEventComputer is beneath "MARKLAPTOP", and that numerous instances of the Win32_NTLogEvent class exist. Refer to Screen 3 to verify that the MOF file defines the Win32_NTLogEventComputer class to associate the Win32_ComputerSystem class with the Win32_NTLogEvent class. Selecting an instance of Win32_NTLogEvent in Object Browser reveals that class's properties in the right-hand pane. Microsoft intended Object Browser to help WMI developers examine their objects, but a management application would perform the same operations and display properties or collected information in a more intelligible manner.
WMI Implementation
The WMI infrastructure implements primarily in the \winnt\system32\wbem\winmgmt.exe executable file. This file runs as a Win32 service that the Win2K Service Control Manager starts the first time a management application or WMI provider tries to access WMI APIs. Most WMI components reside in \winnt\system32 and \winnt\system32\wbem, including Win32 MOF files, built-in provider DLLs, and management application WMI DLLs. Look in the \winnt\system32\wbem directory, and you'll find ntevt.mof, the Event Log provider MOF file. You'll also find ntevt.dll, the Event Log provider's DLL, which winmgmnt.exe loads.
Directories beneath \winnt\system32\wbem store the repository, log files, and third-party MOF files. WMI implements the repository—named the CIM Object Management (CIMOM) repository—as the file \winnt\system32\wbem\repository\cim.rep. WinMgmt honors numerous Registry settings related to the repository (including various internal performance parameters such as CIMOM backup locations and intervals) that the repository's HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM Registry key stores.
Microsoft wanted to extend management capabilities to all aspects of Win2K, so the company had to create a way for device drivers to interact with WMI. Device drivers use several new interfaces to provide data to and accept commands from WMI. Microsoft calls the WMI commands System Control commands. The company assigned the name Windows Driver Model (WDM) Provider to the device driver provider because the same WMI interfaces in Win2K drivers exist for Win98 drivers. Because the interfaces are cross-platform, they fall under WDM, the cross-platform device driver architecture. Win2K places WDM objects in the \root\wmi namespace.
WMI Security
WMI implements security at the namespace level. If a management application successfully connects to a namespace, the application can view and access the properties of all the objects in that namespace. An administrator can use the WMI Control application to control which users can access a namespace. To start the WMI control application, from the Start menu, select Administrative Tools, Computer Management. Next, open the Services and Applications branch. Right-click WMI Control, and select Properties to launch the WMI Control (Local) Properties dialog box, which Screen 5 shows. To configure security for namespaces on the Security tab, select the namespace and click Security. Other tabs in the dialog box let you modify the performance and backup settings that the Registry stores.
Enterprise Management Comes to NT
Although I've covered a lot of ground in a short space, I've only skimmed the surface of WMI's rich functionality. WMI's flexibility and universal application throughout Win2K make it a powerful middleware technology that you'll see enterprise tool vendors take advantage of to deliver powerful enterprise-management tools.
Register
sat April 06, 2004