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.

Wbem.vbs, which Listing 1 shows, is a WSH Visual Basic Script (VBScript) routine that uses WBEM's automation interfaces to determine how much physical RAM the local machine or any remote WBEM-enabled machine has. Unlike ADSI, which is a set of client interfaces, WBEM must be running on both the target machine and the system running the script for a script to work. You must also have WSH installed on the system running wbem.vbs because wbem.vbs is a WSH script. To run wbem.vbs, type

C:\> wscript | cscript wbem.vbs \[\]

at a command prompt. If you want the script to query a remote machine, you include the machine's name on the command line that calls the script. If you don't include a machine name, the script queries the local machine.

Wbem.vbs begins by setting the Option Explicit and On Error Resume Next directives. Then, the script declares its variables. At callout A in Listing 1, wbem.vbs checks to see whether the user supplied any command-line arguments (i.e., machine names). If the script finds command-line arguments, it sets the value of strComputerName to the first command-line argument. Wbem.vbs then tests whether the argument contains a question mark (?) using VBScript's InStr function. If it finds a question mark in the string, the script calls the Usage subroutine, which echoes usage instructions to the user, then ends the script. If wbem.vbs doesn't find a command-line argument, the script sets strComputerName to the local computer name using the WSH Network object and the object's ComputerName property. Next, the script sets the strClassName and strPropertyName variables to the class name (Win32_LogicalMemoryConfiguration) and the property name (TotalPhysicalMemory) of the object in the CIM schema's Win32 namespace that the script needs to retrieve.

At callout B, wbem.vbs creates a reference to a WBEM automation object (objWbem) using the simple binding mechanism that the Winmgmts ProgId exposes. You can use more complex mechanisms that support authentication based on credentials the user supplies; I'll cover these WBEM scripting options in future columns.

After the script has a valid reference to a WBEM scripting object, it needs to use the object to access the target data. I could have used the standard dot notation and the Get and Put methods to retrieve the target computer's RAM information, much as I would use these methods in ADSI. However, I chose instead to use WBEM Query Language (WQL), a subset of SQL that can retrieve information from the CIM schema and WBEM providers. WQL is read-only; you can't use the language to make additions or changes to information you use the language to retrieve. I used WQL to query machines in wbem.vbs, because the RAM data I want the script to retrieve is read-only data.

At callout C, wbem.vbs invokes the ExecQuery method on the objWbem WBEM automation object, passing ExecQuery a WQL query statement. This code will look familiar if you've used SQL. The basic structure of a WQL query is

Select From \[Where \]

You enter the target object's class name (as the schema defines it) in the WQL statement's From clause. In the Select clause, you enter either a comma-delimited list of properties you want to query or an asterisk (*), which tells the script to query all the properties from the class you specify. The Where clause is an optional logical expression that you can use to describe conditions that the target properties must satisfy (e.g., =, <, <=, >=, >, <>). At callout C, wbem.vbs queries the CIMOM for the TotalPhysicalMemory property from the Win32_LogicalMemoryConfiguration class. The CIMOM requests specific provider and data structure information from the CIM object repository, then forwards the request to the target provider (the Win32 provider). The provider fetches the target data and returns it to the CIMOM. The CIMOM then returns to wbem.vbs a WBEM object set that contains the query results. The script stores this data in the objWbemObjectSet object reference.

Next, wbem.vbs traverses objWbemObjectSet. This approach might seem unnecessary because objWbemObjectSet contains only one piece of data—a system's amount of RAM—but scripts have to traverse object references because of the variety of WBEM data types that different WBEM methods return. Many WBEM classes contain multiple instances for each machine. If the script queried a system for information about its disks or processors, for example, the CIMOM might return multiple object instances. Therefore, WBEM scripts must include a little extra code to get to one instance of an object.

Wbem.vbs loops through objWbemObjectSet. Through wbem.vbs's one iteration of the loop, the script assigns objWbemObject to the object reference's one object instance and uses the Properties method and strPropertyName variable to echo the target data to the user. Finally, the script exits.

For More Information
Wbem.vbs hardly scratches the surface of WBEM's effect on scripting Win32 systems administration tasks. The CimWin32 schema extension provides more than 100 Win32-specific classes that describe almost every system component an administrator might want to interact with. You can use WBEM to list or kill processes, manage services, access realtime performance data, and manage events.

Microsoft has published quite a bit of information about WBEM, but very little of it relates to scripting. To begin experimenting with this technology, install the core WBEM components on a couple of systems in your lab or test environment. You can find WBEM on the SP4 CD-ROM (in the \WBEM directory), or you can download the software from the Microsoft Developer Network (MSDN) Web site (http://msdn.microsoft.com/developer/sdk/ wbemsdk/download.htm). The download includes the WBEM client components and a WBEM test application named wbemtest.exe (which installs in %systemroot%\system32\Wbem by default). You can use WbemTest to become familiar with the CIM schema, namespaces, classes, instances, properties, and methods.

You can also download the WBEM software development kit (SDK) from the previous URL. Microsoft geared the SDK toward application developers, but it includes good, in-depth documentation and an impressive Web-based CIM Studio application that you can use to delve deep into the structure of the CIM. Be sure to download the Learn WBEM tutorial, which is available at http://www.microsoft.com/msdownload/wbemsdk/tut.asp. Last, but certainly not least, I recommend that you visit the WBEM Initiative (http://wbem.freerange.com) and DMTF (http://www.dmtf.org) Web sites. These sites provide WBEM specifications, online demonstrations, white papers, and pointers to additional presentations and training material.

WBEM appears poised to change the face of applications, networks, and systems management. In fact, some systems management applications, such as HP's OpenView ManageX 4.0 and Microsoft's Systems Management Server (SMS) 2.0, are already leveraging the power of WBEM. As WBEM and WMI become standard components of the Win2K platform, chances are good that you'll be using WBEM in the future, whether or not you realize that you are using it.