CIM Schema Extensions and Windows Platforms: Frequently Asked Questions
Microsoft Corporation
December 15, 1998
As more developers become familiar with the new Microsoft® Windows® management infrastructure, including the Windows implementations of Windows Management Instrumentation (WMI) and the Common Information Model (CIM), Microsoft is receiving many questions from people seeking to better understand the CIM schema extension capabilities and their use in the Windows platform. This article addresses some of the more frequently asked questions.
What is a "qualifier" in CIM? How are they used? What is Microsoft doing with qualifiers?
Qualifiers exist in CIM as versatile, user-definable metadata for the schemas. Creating new qualifiers is acceptable, with the assumption that these qualifiers will be understood by "something." Microsoft has added qualifiers used by the CIM Object Manager and the supporting frameworks. When the Managed Object Format (MOF) file is imported or exported, the CIM "Meta" and "Standard" qualifiers must be supported. Microsoft will do this.
Why is a "CIM-Key" qualifier defined in the CIM-Win32 MOF?
The Key qualifier in the CIM-Win32® MOF indicates that a property is both a CIM Object Manager and a Desktop Management Task Force (DMTF) CIM schema key. The CIM-Key qualifier indicates that the property is only a CIM schema key and is not used as a key in the CIM Object Manager and the supporting framework. As discussed in the previous question, new qualifiers can be defined. However, when the MOF is imported or exported, the Key qualifiers will be correct.
Where did the "read" qualifier come from? Is this a Microsoft-only qualifier?
The "read" qualifier is defined by CIM. However, many developers may not be aware of this, because it is not used in the Common and Core Models. This is because the "read" qualifier is, by default, TRUE.
Why is the CIM-Win32 MOF missing descriptions?
To conserve run-time space as much as possible, there are two versions of the CIM-Win32 MOF—one with descriptions, and one without. Descriptions are not required in the execution environment.
When I make comparisons of CIM classes in the CIM-Win32 MOF and the DMTF-supplied MOFs, why do I see new properties that are not present in the CIM schemas? Isn't this an invalid extension?
Schema-specific properties and methods can be added to CIM classes. That is the purpose of the schema qualifier as defined in the CIM specification. A management application can be aware of these properties and methods or not. This is a feature of CIM and WMI, not an incorrect or invalid usage. On this basis, these new properties are acceptable extensions to CIM.
Why did Microsoft change the standard MOFs instead of deriving from them?
Microsoft does derive from the standard MOFs; extensions are allowed by the CIM specification. However, issues occur with the rapidly changing MOF definition. As we identify problems in working with others in the industry, we also work to try to solve them as quickly and as reasonably as possible.
Will all of the Microsoft extensions become part of future DMTF standards?
Some of the Microsoft extensions, such as new classes and properties, will indeed be likely candidates for inclusion in a future schema release from the DMTF. However, some of the Microsoft extensions are specific to the Win32 environment, and therefore seem more likely to remain extensions to the standard MOFs.
How can I be sure that when I write an instance provider for something like CIM_NumericalSensor, which isn't currently in the CIM-Win32 implementation, that it won't break in future Microsoft implementations?
This particular case is an excellent example because it is a class which can be added to the CIM-Win32 MOF and then freely subclassed/instantiated. The Microsoft WMI Schema team is working on a white paper that discusses how the CIMV2 namespace can be extended.
See www.microsoft.com/hwdev/WMI/ for an announcement of the availability of this paper.
In any other namespace than CIMV2, you are not restricted in any way.
Table 1. CIMV2 Namespace Usage List
| Classes freely subclassed and instantiated (only for objects local to the machine). | Only Win32 associations and association instances |
| Product, FRU, SupportAccess | SystemComponent; SystemDevice is addressed separately. |
| Configuration, Setting, MonitorResolution | HostedService, HostedAccessPoint and subclasses (future) |
| PhysicalElement and all its subclasses | ServiceServiceDependency, ServiceSAPDependency, SAPSAPDependency, ServiceAccessBySAP (future) |
| RedundancyGroup and its subclasses | DeviceServiceImplementation and DeviceSAPImplementation (future) |
| CoolingDevice and its subclasses | HostedJobDestination and JobDestinationJobs (future) |
| Sensor and its subclasses | OSProcess and ProcessThread (future) |
| ManagemenController | FileStorage and DirectoryContainsFile (future) |
| Memory and its subclasses | OperatingSystemSoftwareFeature (future) |
| Statistics and its subclasses | HostedFileSystem and BootOSFrom FS (future) |
| StorageError | InstalledOS and RunningOS (future) |
| Associations freely subclassed and instantiated (only for relationships local to the machine). | ProcessExecutable |
| All Product, FRU, and SupportAccess associations | ControlledBy and its subclasses |
| All Configuration and Setting associations | AllocatedResource |
| All Statistics associations | ResidesOnExtent (future) |
| Realizes and all associations documented in Physical Model. | ComputerSystemResource |
| AssociatedMemory | All associations defined in the Application Model. |
| AssociatedSensor and its subclasses | Win32 subclasses/instances with specific meaning; other subclasses/instances allowed for objects local to the machine. |
| BIOSLoadedInNV | Battery—Win32 classes represent laptop or UPS batteries with COM port attached. |
| Redundancy Component and its subclasses | PowerSupply and UninterruptiblePowerSupply—Win32 class represents a COM-port-attached UPS. |
| ActAsSpare | StorageExtent and its subclasses—Win32 classes represent logical disks, a subclass of CIM_LogicalDisk, and partitions, a subclass of CIM_DiskPartition, only. |
| CollectionOfSensors | Processor—Win32 classes represent "a device capable of interpreting a sequence of machine instructions on a Win32 system." |
| Only Win32 subclasses and instances | Win32 associations/instances with specific meaning; other associations/instances allowed for relationships local to the machine. |
| UnitaryComputerSystem | SystemDevice—Subclassing and instantiation allowed for the following Devices: CoolingDevice, Sensor, ManagementController, Memory, and Battery/PowerSupply/UninterruptiblePowerSupply/StorageExtent/processor devices not already addressed by Win32. |
| OperatingSystem | AssociatedBattery and AssociatedCooling—Associations to instantiated devices only. |
| FileSystem and its subclasses (future) | DeviceSoftware—Allowed only for the following devices: CoolingDevice, Sensor, ManagementController, Memory, and Battery/PowerSupply/UninterruptiblePowerSupply/StorageExtent/processor devices not already addressed by Win32. |
| LogicalFile and its subclasses | DeviceConnection—Win32 classes are types of "ControlledBy" associations. |
| Process and Thread | BasedOn—Win32 classes reference LogicalDisks and Partitions only. |
| Printer | MediaPresent—(future) Win32 classes for LogicalDisks and Partitions only. |
| Scanner (future) | Association subclassing and instantiation not allowed (typically, high-level relationships). |
| NetworkAdapter and its subclasses | SystemComponent; SystemDevice addressed separately. |
| Controller and most of its subclasses (SCSI, Serial, Parallel, PCI—future, USB—future, Video—future). | ApplicationSystemSoftwareFeature |
| POTSModem | ComponentCS |
| MediaAccessDevice and its subclasses (DisketteDrive, WORMDrive, and MagnetoOpticalDrive—all future). | HostedClusterService, ClusterServiceAccessBySAP |
| UserDevice and its subclasses (Display—future) | Export and Mount |
| SystemResource and its subclasses | HostingCS and ParticipatingCS |
| Service, ServiceAccessPoint (future) and their subclassesServices represent executable components hosted by the System. Services and their executions are fundamental to the structure of the Win32 environment and are not open to the inclusion of new instances. Any case where new Service instances exist and are not known to the operating system should be defined in a separate namespace. | DeviceAccessedByFile; N/A for Win32 environment. |
| Job and JobDestination (future) | Applications |
| SoftwareFeature, SoftwareElement, Checks, Actions, and their subclasses represent the MSI view of the installed applications. Any case where new software instances exist and are not known to MSI should be defined in a separate namespace. | Each application is placed in its own "virtual namespace," with associations to CIMV2. |
| Subclassing and instantiation not allowed (typically, high-level objects). | |
| ManagedSystemElement and LogicalElement; Subclasses addressed separately. | |
| System and ComputerSystem; Subclasses addressed separately. | |
| VirtualComputerSystem | |
| Cluster, ClusteringService |
Some RAID controller manufacturers provide an interface to internal information which partly matches classes within the Win32 schema—there might be information about physical drives, controllers, and logical drives, RAID level for logical drives, and connections between the various elements. Should the developer put this into a separate namespace? Or would it be a better idea to provide objects in the CIM_RedundancyGroup area? The CIM System/Devices Group and Microsoft designed the CIM_StorageRedundancyGroup to describe RAID algorithms. In addition, you could define instances of lower-level StorageExtents (for example, CIM_PhysicalExtent or CIM_VolumeSet) that are "under" the Win32 logical disks. The BasedOn association between StorageExtents should allow the definition and "building up" of storage frameworks. The association describes a hierarchical relationship among the StorageExtents, for example, LogicalDisks built on top of VolumeSets, which are in turn built on top of lower-level PhysicalExtents.
Where would be the best place to put a "system is healthy" property? One suggestion would be the Status property, inherited from CIM_ManagedSystemElement, on the system or device whose health is described. The Status property has the following values: OK, Error, Degraded, Unknown, Pred Fail, Service, Starting, and Stopping. This property is used to indicate both operational and nonoperational statuses. Quoting from the DMTF CIM MOF:
Operational statuses are: OK, Degraded and Pred Fail. Pred Fail indicates that an Element may be functioning properly but predicting a failure in the near future. An example is a SMART-enabled hard drive. Non-operational statuses can also be specified. These are Error, Starting, Stopping and Service. The latter, Service, could apply during mirror-resilvering of a disk, reload of a user permissions list, or other administrative work. Not all such work is on-line, yet the Managed Element is neither OK nor in one of the other states.
Is there any information on how Intelligent Platform Management Interface (IPMI) error log data will be represented?
CIM does not address logs at the present time. In fact, there are really two types of logs, depending on the storage medium: storing data in files in a file system or in nonvolatile RAM (NVRAM). What these have in common is that they define a format for data content and syntax. Defining a "standard" log format is not within the CIM scope currently. However, you can describe that logs exist.
For example, describing the existence of a "file system"-based log could be handled as an instance of a CIM_LogicalFile. Defining that NVRAM exists (for the purpose of holding log data) can be described as an instance of CIM_NonVolatileStorage with an entry in the Purpose string property (inherited from CIM_StorageExtent).
Why does there seem to be some data missing from CIMWin32?
Examples of possible missing data are:
- "Status/Availability" under "Win32_SCSIController"
- "TriggerLevel/TriggerType" under "Win32_IRQResource"
- "AddressSize, BurstMode, ByteMode, ChannelTiming, MaxTransferSize"
- "TransferWidths, TypeCTiming, WordMode" under "Win32_DMAChannel"
At this point in time, Microsoft is primarily instrumenting data that is accessible using Win32 APIs and other operating system mechanisms. Some information that is not provided "for free" by way of these mechanisms may be available on the platform using other means—for example, by using instrumented drivers provided by the OEM or IHV. As Microsoft continues to enhance support and coverage of instrumented data that is automatically made available, more information will be provided in the schema and more properties will be found that are not Null.
Where is SMART information accessible in the schema, and do current Windows 2000 providers handle this?
The Self-Monitoring, Analysis and Reporting Technology (SMART) goal is to use low-level hardware data to predict a failure before it occurs. Various vendors use different indicators of failure. However, the common aspect is that failure is predicted in order to allow recovery of data, replacement of hardware, or other repair and alerting actions before the hardware loss is critical. Provider and driver writers should use the "Pred Fail" setting of the Status property, which is inherited by all devices from CIM's ManagedSystemElement class, to indicate predictive failure. In the future, we will be defining how additional SMART data can be captured and reported.
Can OEMs fill in null properties in the schema?
Currently, having more than one provider "own" an object is not allowed, so that more than one source cannot exist for the data in the object. This is an area currently under investigation.
How do I compile the DMTF CIM MOF with the Microsoft WBEM SDK tools?
Follow the steps to compile the standard DMTF CIM MOF using the MOF compiler provided in the Microsoft Web-Based Enterprise Management (WBEM) Software Developers Kit (SDK):
- Comment out the qualifier definitions from CIM_Core. The MOF compiler does not handle qualifiers in the general case. The compiler only "understands" some pre-programmed qualifiers that are implicitly defined, such as Association, Description, and so on. This will be corrected in a future release.
- Comment out all the #pragma locale entries.
- The #pragma include entries in CIM_Schema21 will not work. To work around this, you must manually combine the CIM MOFs into a single file, defined in the correct order: Core first, then Applications, Systems, Devices, and Physical.