| Downloads |
|---|
| 20376.zip |
Among the improvements that Windows 2000 includes are features to make the OS more manageable. One of these features is support for Remote Administration mode in Win2K Server Terminal Services, and another is Microsoft Management Console (MMC). Still another is Windows Management Instrumentation (WMI), an interface to the OS that lets you interact with parts of the OS that you'd otherwise have to address individually. You can use WMI for many purposes, one of which is scripting computer management.
Why Scripting?
One reason why Windows NT took off in the early 1990s was because the OS is relatively easy to use. If you could use Windows 3.1, you could probably learn to manage a simple NT-based network. (This sounds crazy today, perhaps, but recall that NT 3.1 had less functionality—and thus, was less complex—than Win2K is.) Just looking at the tools available in NT's Control Panel gave you some idea of what you could do with the OS.
The user-friendly interface has become friendlier as the OS has evolved. In Win2K, every procedure has a wizard, and every OS object has a tabbed Properties sheet. Several different paths lead to each dialog box, and MMC lets you snap the tools you use—even some third-party tools—into a customized toolkit.
Experienced administrators find the friendly GUI frustratingly slow. You can use the command line to perform some tasks, but the command-line tools can't do everything that the graphical tools can. Another way to streamline some Win2K tasks is to address the same management interfaces that the graphical tools use but through scripts instead of from the GUI. WMI lets you use one interface and scripting languages to write scripts that address almost any part of the OS. In contrast, you can't, for example, use VBScript to directly address the Win32 API.
What Is WMI?
WMI is a core part of Win2K's management system and a useful add-on to other Win32 OSs. WMI works with Common Information Model Object Manager (CIMOM), a database of objects representing OS elements, to provide a common interface to those elements for MMC tools and scripts to use. With WMI, tools and scripts don't need to use different API calls to query different OS parts. Instead, those parts plug into WMI, as Figure 1 shows, and tools and scripts can read and write to WMI.
Win2K and Windows 98 support WMI, and you can add WMI support to NT 4.0 with Service Pack 4 (SP4) and later and to Win95 computers. For more information about installing WMI on NT 4.0 and Win95 computers, see the sidebar "Adding WMI to NT 4.0 and Win95 Systems." Thus, you don't need a Win2K environment to use WMI for remote management. (Obviously, though, you can't query Win2K Performance Monitor on a remote PC if your WMI script is running on a Win9x computer that doesn't have Performance Monitor.)
As I mentioned, WMI lets you use one common interface to address multiple OS elements, so you don't have to query all the underlying interfaces, or providers, separately. Therefore, you can collect different types of information in one query and thus look for relationships among disparate data more easily than you could otherwise. You can use WMI to remotely manage computers, as long as the local and remote machines support WMI. Not all command-line utilities in Win2K have syntax to support using them on a remote computer.
WMI is an implementation of the Web-Based Enterprise Management (WBEM) model, which the Distributed Management Task Force (DMTF) created with the help of about a dozen vendors, including Compaq, Sun Microsystems, and Microsoft. WBEM's purpose was to develop a standard set of interfaces for managing enterprise environments. The WBEM model's important parts are its data model (or means of describing and defining objects), its encoding specification, and its transport model for passing data between client and server.
WBEM's data model is the Common Information Model (CIM). The CIM is a standard naming system, or schema, for a computer's physical and logical elements, such as a logical partition of a hard disk, an instance of a running application, or a cable. The schema is important because it lets everyone accessing elements in the CIM use the same words to describe and communicate with those elements.
The CIM is an object-oriented schema, so you use object-oriented terminology to describe its parts. The CIM contains classes, which are templates for managed elements. An object is an instance of a class that represents the underlying element on the system. A namespace is a collection of classes that target a specific area of management. Classes contain properties and methods.
The CIM has three layers. The core model contains class definitions common to all areas of management. The common model contains class definitions that are common to particular management areas but are independent of a particular OS or system design; this model provides the base for technology-specific schemas. Extension models contain class definitions specific to a single OS or other technology.
WMI is Microsoft's extension model for the Win32-specific parts of the platform and extends CIM 2.0. To refer to a WMI class and property, you use the format extensionprefix_classname.propertyname. So in the label Win32_ComputerSystem.Name, Win32 is the prefix for the WMI extension classes residing in the cimv2 namespace in the CIM schema. ComputerSystem is the class, and Name is the property.
Much of what you'll do with WMI scripts involves setting or reading property values. WMI currently has few methods, but both WMI and the CIM should get more methods over time. For more information about WMI, see the articles in "Related Articles in Previous Issues."
The WMI Software Development Kit
The WMI software development kit (SDK) lets you view the available CIM and Win32 classes. You can download the SDK from http://www.msdn.microsoft.com/downloads/sdks/wmi/download.asp. At more than 8MB, it's a big file.
The README file at http://msdn.microsoft.com/downloads/sdks/wmi/readme.asp has a complete list of system requirements, but here are a few basics. The OS must be Win2K or NT 4.0 SP4 or later. You can't install the SDK on Win9x systems, even though you can install support for WMI on that platform. You also must have Microsoft Internet Explorer (IE) 5.0 to support the ActiveX controls in the SDK. At a bare minimum, you need a Pentium processor, 32MB of RAM, 40MB of disk space, and support for at least 256 colors at 800 x 600. These system requirements shouldn't be a problem on a computer that's running Win2K. If the computer doesn't have a network card, CIMOM can't run as a service as it's supposed to, but you can run it as an application. Run winmgmt.exe (the CIMOM executable), which is in the WMI home directory, under \%systemroot%\system32\wbem.
You must be a member of the Administrators group to install the SDK. Installation is straightforward. Run wmisdk.exe to start the wizard. Specify the folder in which you want to install the files (the default is C:\program files\wmi). Choose the optional components to install. By default, all the components are installed except SNMP support. Click Finish on the final page of the wizard. You don't need to reboot. When the installation program has copied all the relevant files to your chosen folder, you'll see a new WMI SDK program group in the Programs folder.
After installation, click Start, select Programs and WMI SDK, and open WMI CIM Studio. When CIM Studio prompts you to connect to a namespace and shows the default option of root\cimv2, click OK. If you're logged on as the Administrator, click OK again to log on as the current user. If you're logged on under a different name, log on as the Administrator.
Now let's look on this computer for an object to manage: the C drive. I don't know the exact name of this element in CIM or WMI, so rather than browse the hundreds of classes that CIM Studio lists, I click the Find button (the binoculars at the top of the lefthand pane). In the resulting Search for Class dialog box, which Figure 2 shows, I type the name of a keyword that I think will likely be in the C-drive class name and click Go! Because I'm looking for a named partition and I know that Windows OSs call such partitions logical disks or logical drives, I search for the keyword logical. You could also search for disk, but you'd have to scroll through a lot more results.
Figure 2 shows the available classes. I select Win32_LogicalDisk and click OK, and the window in Figure 3 appears. (Why not CIM_LogicalDisk? As I mentioned previously, Win32 is the prefix for any object WMI manages. If you select CIM_LogicalDisk and try to display instances, you won't see any specific information about the available logical disks—you'll just see a Win32_LogicalDisk entry for each available logical drive.) The righthand pane now shows the available properties for the Win32_LogicalDisk class. Note that the property values are empty because we're looking at the class, not at a particular instance of the class. To display the instances of the Win32_LogicalDisk class, I click the Instances button at the top of the righthand pane (fourth button from the right).
The resulting window lists all the instances of logical disks on this particular machine, including network-accessible logical drives, in the righthand pane. I click the instance with device ID "C:". The resulting window, which Figure 4 shows, displays the properties and methods of the selected instance on tabs in the righthand pane. The name of the logical disk you selected appears at the top of the righthand pane.
You can use a script to change the properties or to apply the methods. If you have questions about the properties, select the Win32_LogicalDisk class or Win32_LogicalDisk.DeviceID="C:" instance and click the Help button. You'll see documentation for most of the object's available properties and methods.
Starting to Script
Now that you've had a look at the Win32_LogicalDisk class and its properties, I want to give you a feel for working with this information in a script. If the Microsoft Windows 2000 Resource Kit is installed on your computer, listfreespace.vbs is located by default in the \program files\resource kit folder. This script queries each object in the Win32_LogicalDisk class for the values of a couple of its properties: DeviceID (its drive letter) and FreeSpace (the number of bytes of free space it has). On a computer where A is the floppy disk drive and D is the CD-ROM drive, listfreespace.vbs's output might look something like this:
A: not available C: 8,243,381,248 bytes D: not available G: 4,776,943,616 bytes
You can use getfree.vbs, which Listing 1 shows, to obtain similar information with less code. I've heavily commented the script so that you can tell exactly how it works. You supply a drive letter when you invoke the script, and getfree.vbs tells you the free space and file system for the drive. For example, if I type
getfree.vbs c:
on my laptop, I see the window that Figure 5 shows.
Now you know what WMI is and how to find managed objects on your computer. You might not yet be an expert WMI "scripter," but you'll know what pieces to manipulate and where they are when you write scripts.
| Related Articles in Previous Issues |
|
You can obtain the following articles from Windows 2000 Magazine's Web site at http://www.win2000mag.com. DARREN MAR-ELIA "Leveraging Windows Management Instrumentation in Win2K Pro," Summer 2000, InstantDoc ID 8819 MARK RUSSINOVICH Internals, "Inside Windows Management Interface," February 2000, InstantDoc ID 7937 BOB WELLS Scripting Solutions, "WMI Monikers," May 2001, InstantDoc ID 20401 Scripting Solutions, "Windows Management Instrumentation: The Systems Administrator's Apprentice," August 2000, InstantDoc ID 9033 Scripting Solutions, "Windows Management Instrumentation: The Journey Begins," July 2000, InstantDoc ID 8959 |
