WBEM simplifies the automation of many administrative tasks
Not long ago, automating administrative tasks for the Win32 platform was next to impossible. Today, Windows NT administrators face the opposite problem. New technologies and product upgrades that automate administration are appearing almost daily. Trying to keep up with all these new technologies—and determining which products you really need—can be overwhelming. But don't let the number of products on the market prevent you from investigating the exciting new Web-Based Enterprise Management (WBEM) technology. What is WBEM, and does it belong in your IS strategy? Let's take a look.
WBEM and WMI
Unless you've been in a deep sleep, you know that Microsoft released NT 4.0's Service Pack 4 (SP4) in October 1998. What you might not know is that SP4 includes a significant new technology—Windows Management Instrumentation (WMI)—that will probably change the way you manage NT and, eventually, Windows 2000 (Win2K) systems. WMI is Microsoft's implementation of the Desktop Management Task Force's (DMTF's) WBEM initiative. (For information about WBEM, see "Related Articles in Windows NT Magazine," page 182.)
WBEM is to systems management what Active Directory Service Interfaces (ADSI) is to directory services management. ADSI abstracts the complexity of disparate directories by providing a common set of interfaces that you can use to access the directories in a uniform way, regardless of the directories' underlying technology. Similarly, WBEM abstracts the complexity of disparate network and systems management technologies, such as Simple Network Management Protocol (SNMP), Desktop Management Interface (DMI), and Win32. WBEM's purpose is to provide a common data model and access methodology for network and systems management data, regardless of the data's source.
This common data model, which Microsoft developed and the DMTF subsequently adopted, is the Common Information Model (CIM)—the standard DMTF data definition for describing a managed environment. The CIM provides one extensible data definition for network and systems management data. This model, which uniformly describes various data sources within a managed environment, lets administrators access management data from multiple sources in a common way. The WBEM model is similar in concept to ADSI's provider-based architecture, but WBEM is an industrywide initiative (not a Microsoft-specific solution).
Figure 1, page 180, outlines the WBEM architecture, highlighting the initiative's primary components. The two components that make up the heart of WBEM are the CIM Object Manager (CIMOM) and the CIM object repository.
The CIMOM runs as an NT service. If you install SP4's WBEM components, you'll see the CIMOM service under the display name Windows Management. The CIMOM provides WBEM consumers (i.e., systems management and custom applications, Web browsers, and scripts) with transparent access to management data that originates from various sources (e.g., Win32, SNMP, Windows Driver Model—WDM). Providers work between the CIMOM and the disparate management methodologies that the CIMOM retrieves information from. On behalf of consumers, the CIMOM requests data from one or more providers. The providers fetch the data using the native access mechanism for the data source they fetch the data from and return the information to the CIMOM, which presents the data to the application that requested it. This fetch-and-retrieval system is common to and consistent among all consumers and providers, so WBEM management applications can manage any WBEM-compliant device or application.
The CIMOM is WBEM's interface to the CIM object repository; consumers and providers access the object repository via the CIMOM. The CIM object repository provides the schema—the definition of what information is available and that data's structure—for a managed environment. The schema contains the class definitions and instances of managed objects. Class definitions define the methods, properties, events, and data types that managed objects support. The CIM schema has two parts: the Core model and the Common model. The Core model represents a small set of classes that define the structure that applies to data from all areas of systems management. The Common model provides class definitions that are specific to a particular area of management. The Common model currently defines five areas of management: systems, devices, applications, networks, and physical. Developers can extend the CIM schema to include new classes that represent vendor-specific objects. For example, the Win32 portion of the schema represents the custom schema extension Microsoft defined to expose objects that are unique to the Win32 environment.
The CIM object repository divides the schema into namespaces that represent logical groupings of related objects. For example, the object repository groups the classes that make up the Win32 environment under the Win32 namespace. At the top of the CIM schema is the root namespace, as Figure 1 shows. The CIMv2 namespace is under the root namespace. Under several other standard WBEM namespaces come implementation-specific namespaces (e.g., Win32, Event Log, Registry). These implementation-specific namespaces represent extensions that a particular vendor or provider has made to the CIM schema.
Microsoft's WBEM software includes three NT-specific providers: Win32, Event Log, and Registry. These providers are .dll files in the %systemroot%\system32\Wbem directory. The CIM object repository resides in the %systemroot%\system32\Wbem\Repository directory.
WBEM Scripting
At this point, you're probably wondering what WBEM has to do with scripting. To answer this question, you simply need to look at one of WBEM designers' early goals for the initiative—Web-based enterprise management. WBEM includes automation interfaces via wbemdisp.dll that facilitate dynamic, runtime access to providers and managed objects that the CIM schema defines. Therefore, you can leverage the power of WBEM using any programming or scripting environment that supports automation, including Active Server Pages (ASP), Perl, Windows Scripting Host (WSH), Visual Basic (VB), and Visual C++ (VC++).
To demonstrate this functionality, I'll revisit an inquiry I received almost a year ago. A gentleman asked me how to remotely query his servers and workstations to determine the amount of memory each system had. At the time, I didn't have a solution other than using a remote execution environment, such as Telnet or the Microsoft Windows NT Server 4.0 Resource Kit's Remote command service. However, WBEM turns the task of determining how much RAM a system has into a matter of writing a script.