The WMI Hierarchy

One of the most complicated parts of WMI is the sheer number of acronyms that come with it: DMTF, CIM, Win32, and so forth. First, bear in mind that you don't really need to remember any of them to use WMI effectively. However, it can be helpful to understand what they all mean, because they help WMI make more sense.

The DMTF is the Desktop Management Task Force. It's an industry group primarily concerned with making desktop computers (they do care about servers, too) easier to manage. Microsoft pays close attention to the DMTF and is a contributing member. One of the things that the DMTF realized is that every hardware, software, and operating system vendor has different names for the same things. Windows, for example, has logical disks, partitions, volumes, and so forth; Novell NetWare uses these terms for slightly different things. To clear up the confusion, the DMTF created the Common Information Model, or CIM.

The CIM is essentially a generic way of describing everything associated with a computer, at both a hardware and a software level. The CIM defines many base classes to represent things like disks, processors, motherboards, and so forth. The CIM classes only include properties that are universal. For example, the CIM_DiskDrive class includes a property for Name, because all disk drives can be assigned a descriptive name. It also includes a property for MaxBlockSize, because all disk drives manufactured today have an associated maximum block size. The class doesn't include a property that indicates the file system used to format the disk, nor does it show whether a disk is basic or dynamic. Those are operating-system-specific features not addressed by the CIM.

The CIM is, however, extensible. When Microsoft created WMI, it created its own series of Win32 classes that are Windows-specific. The Win32 classes are based on, or inherited from, CIM classes. For example, there's a Win32_DiskDrive class. It includes all of the properties associated with the CIM_DiskDrive class, and includes additional properties-such as PNPDeviceID-that are specific to the Windows operating system.

The main part of WMI is understanding that it's composed of these classes, which represent the hardware and software in a computer. My laptop, for example, has once instance of the Win32_DiskDrive class, which simply means that the machine contains one disk drive. My desktop machine has two instances of Win32_DiskDrive, which means it contains two hard disks. Absolutely everything in WMI is set up to handle multiple instances of classes. Sometimes, that doesn't seem to make any sense. After all, how many computers do you know of that contain multiple instances of a class like Win32_MotherboardDevice? Not many! But WMI is designed to be forward looking. Who knows; we might someday be working with computers that do have multiple motherboards, and so WMI is set up to deal with it.

Multiple instances can make querying WMI information seem complex. For example, suppose you want to query the IP address of a workstation's network adapter. Unfortunately, you cannot just ask for the IP address from the first adapter WMI knows about. Windows computers all contain multiple network adapters, if you stop to consider virtual VPN adapters, the virtual loopback adapter, and so forth. So, when you write WMI queries, you have to take into account the fact that the computer probably contains multiple instances of whatever you're after, and write your script accordingly. As a quick example, try the script in Listing 17.1.

Listing 17.1. ShowNIC.vbs. Shows the IP address and MAC address of each network adapter you have.

Dim strComputer

Dim objWMIService

Dim colItems



strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" & _

 strComputer & "\root\cimv2")



Set colItems = objWMIService.ExecQuery( _

 "Select * from Win32_NetworkAdapterConfiguration",,48)



For Each objItem in colItems

     WScript.Echo "IPAddress: " & objItem.IPAddress

     WScript.Echo "MACAddress: " & objItem.MACAddress

     WScript.Echo "MTU: " & objItem.MTU

Next

Unbelievably, WMI isn't any more complicated than that. Don't worry for now about how this script works; you'll be seeing many more like it in this and the next two chapters, along with complete explanations.

Providers and Consumers

One pair of terms you'll run across in the WMI documentation is providers and consumers. A consumer is simply an application that utilizes WMI to retrieve or change system management information. Your WMI scripts, for example, are WMI consumers. A provider is a piece of software that makes WMI information available. Windows comes with a number of providers that make system hardware, software, and performance information available through WMI. Third-party applications can include WMI providers, which make those applications manageable through WMI.

The fact that these providers are buried within Windows disguises some of the power and flexibility of WMI. WMI isn't what I'd call an integral part of the Windows operating system; it's really an additional set of services that runs on Windows. You can even see the service on Windows 2000 and newer computers if you look in the Services control panel. I'm not suggesting that WMI isn't fully integrated with Windows; simply that Windows can run without WMI, and that WMI extends Windows' inherent capabilities. Why is this an important distinction?

First, Microsoft isn't really doing anything with WMI that you can't do in other ways. You already know how to set IP addresses, for example; you didn't need WMI to come along and give you that capability. WMI simply makes these administrative tasks available through scripts, meaning you can better automate administrative tasks than you could before. Second, Microsoft isn't doing anything with WMI that other companies can't do. WMI is completely open and extensible, and anyone can write a provider that opens up his application to your scripts.

WMI Versions

WMI has been available in the NT and 9x product lines since Windows NT 4.0, although WMI wasn't full-featured until Windows 2000. Windows XP and Windows Server 2003 have gradually added WMI features, making more and more of the operating system accessible through WMI.

WMI is installed by default in Windows 2000, Windows XP, Windows 2003, and Windows Me. You can install WMI on Windows 95 OSR2, all editions of Windows 98, and Windows NT 4.0. I'll discuss installation requirements later in this chapter.