Microsoft Corporation
April 1997
Effective management requires well-instrumented computer software and hardware components, so that subsystem components can be monitored and controlled. Microsoft® is committed to simplifying instrumentation of hardware and software for the Microsoft Windows® environment. Microsoft is also committed to providing consistent access to this instrumentation for both Windows-based management systems and legacy management systems hosted in other environments.
Windows Management Instrumentation (WMI) provides the basis for instrumentation in future Windows environments. Close coupling of WMI with services developed to conform to the Web-Based Enterprise Management (WBEM) initiative (see http://wbem.freerange.com/) will allow Microsoft to simplify instrumentation and provide consistent, open access to management data.
The Microsoft Windows NT® operating system version 5.0 and "Memphis" (the code name for the next version of Windows 95) are scheduled to include a structured set of instrumentation services within the OS. A key component of these services is Windows Management Instrumentation (WMI). WMI is a set of extensions to the Windows Driver Model (WDM) that provide an operating system interface through which instrumented components can provide information and notification.
WMI provides a bidirectional instrumentation access mechanism. WMI brings together the management data from the hardware platform, drivers, and applications and passes the consolidated data into a consistent management information store. This store, developed to conform to the requirements of the Web-Based Enterprise Management (WBEM) proposals, uses the Desktop Management Task Force (DMTF) Common Information Model (CIM) as the basis for exposing and interacting with this information. CIM and WMI are core enabling technologies. Together these core technologies provide a powerful and consistent mechanism enabling management applications, platforms, and consoles to perform the following types of management tasks on Windows-based hardware and software:
Windows Management Instrumentation/CIM Benefits
Feature | Benefit |
Simplifies instrumentation of drivers and applications written for the Windows operating system | Developers: reduces development effort required to create well-instrumented applications Administrators: well instrumented applications and drivers means more control, offering the potential to lower costs of ownership through having a better managed environment |
Provides detailed and extensible information consistent across different vendors' products | Developers: new device and application-specific features can be exposed as required Administrators: flexibility to create diverse multi-vendor solutions without sacrificing management integration |
Consistent access to management data from within Windows | Developers: easier association of management information between applications, drivers and hardware Administrators: management solutions that tie together information from many managed sources |
Consistent access to Windows instrumentation from non-Windows environments | Developers: single, environment-independent, open mechanism to access and associate all management data instrumented within Windows End users: ability to build heterogeneous management solutions hosted by Windows- and non-Windows–based management systems |
Windows Management Instrumentation Architecture Overview
The Windows Driver Model (WDM), an important low-level component, provides access between WMI and hardware devices. Each instrumented hardware device (for example, disk drive, network interface card, and so on) provides device-specific management access to WDM via its own WDM Mini Driver. The WDM Mini Driver (provided by the hardware vendor) passes specific information to standard interfaces in the WDM class driver (provided by Microsoft). The WDM class driver passes the device information to the WMI kernel mode subsystem.
Applications execute in user mode. Therefore, they can communicate directly to WMI via user mode entry points or can integrate directly with the WBEM Agent. Interface usage and guidelines will be made available in the Platform SDK.
WMI (represented as two components in the diagram: WMI user mode and WMI kernel mode) provides the communication between the management information store (described below) and the instrumented applications and devices. WMI is responsible for marshalling queries from management applications to devices and software. WMI is also responsible for negotiating and delivering events (for example, device status, application performance metrics, device errors) from devices and software to the management information store.
The WBEM Management Agent, comprising the management schema, object information store, and access mechanisms, provides a universally accessible, device/application extensible storage mechanism for statically and dynamically instrumented data. The schema is implemented according to the guidelines provided by the DMTF CIM effort to maximize interoperability between Systems and Network management systems.
Through the WBEM agent it is possible to integrate and unify existing instrumentation mechanisms, including SNMP, DMI, CMIP, and proprietary technologies. WBEM allows administrators to consolidate information from these many different instrumentation mechanisms, while leveraging the benefits of the coherent and extensible instrumentation of the Windows environment through WMI.
Example: Finding faulty hard drives before catastrophic failure
Situation: An NTFS-formatted SCSI drive has a worn spindle that is creating intermittent platter harmonics. On one particularly bad vibration, the disk head makes contact with the platter media, causing data loss (corrupted sector). Although NTFS can be set up to recover the lost data automatically, the underlying problem is masked. In this case, the disk has been instrumented through WDM and WMI. The disk is therefore able to alert the IT support group before the fault results in a catastrophic failure. Through use of unified instrumentation the system is also able to take pre-emptive management actions automatically, including the generating of a Priority 1 work order to schedule a maintenance call to replace the disk. Here's how:
As bad sectors occur on the disk they are mapped into the disk's "known bad sector" list. This is reported to the disk driver, which informs WMI (kernel mode) using a write event of the increment to the bad sector list. At the same time, the driver reports the error to NTFS, which recovers the block from parity information and performs an NTFS cluster remap.
WMI (kernel mode) fires an event to WMI (user mode). WMI checks its table to see who has registered for events on this disk and forwards the event to the CIM-compliant store in the management schema.
Unlike SNMP and DMI systems, where the low-level event is typically returned to a central management system for processing, CIM supports either local or remote processing. Distributed management, using local management processes, becomes an important option when managing large numbers of elements as network capacity can easily become swamped with management traffic when managing many thousands of desktops or devices.
In this example, the event that reports the new bad sector starts a local disk-check maintenance utility, preset with the corporation's service level requirements for hard disks. This utility could be stored on every desktop or at the local server to be downloaded as required. Note: Products such as Microsoft Systems Management Server can be used to maintain the integrity of such utilities in highly distributed environments. Systems Management Server can verify version levels and schedule overnight deployment of utility updates, or updated service level requirements from a central management point.
When run on the failing machine, the disk utility scans the CIM store evaluating new information, discovers a trend of bad blocks being reported, evaluates historical data and heuristics, performs a failure analysis, and calculates a Mean Time To Failure (MTTF) of one week. Checking this against the preset service level agreement, the utility finds this result unacceptable. To complete its task, the disk utility therefore queries the CIM schema for additional information on the device (such as install date and serial number and manufacturer ID). It then fires an event to the central change control system with a request to schedule a Priority 1 service call to replace the disk.
When the disk is replaced during a subsequent service call, WMI collects new asset information and updates the information in the CIM store.
The use of WMI and CIM to expose both low level instrumentation and applications provides a level of manageability with enormous potential. It is not just hardware support staff that would be interested in a failing disk. The same data may have importance to a database administrator monitoring database performance trends, to a systems administrator managing file servers or a Web site, to any power user needing local performance information on a machine. Through use of WMI and the WBEM agent all of these management requirements can be supported using a single, unified method of instrumentation.
For more details on Microsoft management technology, see http://www.microsoft.com/management/.