WMI Overview
Microsoft® Windows® 2000 Scripting Guide
Windows Management Instrumentation (WMI) makes managing Windows-based computers much more convenient than it has been in the past. WMI provides you with a consistent way to access comprehensive system management information and was designed, from the beginning, to work across networks. For system administrators managing Windows-based computers, understanding WMI is as important and useful as understanding the Active Directory® directory service.
WMI provides a consistent model of the managed environment. For each manageable resource, there is a corresponding WMI class. You can think of a WMI class as a succinct description of the properties of a managed resource and the actions that WMI can perform to manage that resource.
Note
- What is a managed resource? For the purposes of this chapter, a managed resource is any object computer hardware, computer software, a service, a user account, and so on that can be managed by using WMI.
Consider how you had to manage and monitor Windows-based workstations and servers in the past. You had to use a number of different administrative tools to administer various resources, including disk drives, event logs, files, folders, file systems, networking components, operating system settings, performance data, printers, processes, registry settings, security, services, shares, users, and groups.
With WMI, instead of learning how to use all of these different administrative tools, you need to learn only how to write scripts that use the WMI scripting library. The scripting library lets you work with WMI classes that correspond to managed resources. After you understand this model and how to make use of it, you can apply what you have learned to manage any resource that has a corresponding WMI class. This is one of the primary benefits of using WMI: You can use the same approach to manage resources as disparate as disk drives, event logs, and installed software.
WMI conforms to industry standards overseen by the Distributed Management Task Force (DMTF). The DMTF is an industry organization that works with key technology vendors, including Microsoft, as well as affiliated standards groups to define interoperable management solutions. The architecture of WMI is based on ideas described in the DMTF Web-Based Enterprise Management (WBEM) initiative.
WMI was originally released in 1998 as an add-on component with Microsoft® Windows NT® 4.0 with Service Pack 4. WMI is now an integral part of the Windows family of operating systems, including Microsoft Windows 2000 and Microsoft® Windows® XP.
Capabilities of WMI
Using Windows Script Host (WSH) and Microsoft® Visual Basic® Scripting Edition (VBScript), Microsoft® JScript®, or any scripting language that supports COM Automation (for example, ActivePerl from ActiveState Corporation), you can write WMI scripts that automate the management of the following aspects of your enterprise:
Computers based on Windows XP Professional and Windows 2000
You can write scripts to manage event logs, file systems, printers, processes, registry settings, scheduled tasks, security, services, shared folders, and numerous other operating system components and configuration settings.
Networks
You can create WMI-based scripts to manage network services such as Domain Name System (DNS), client-side network settings (for example, configuring a computer to use a static IP address or to obtain an IP address from a Dynamic Host Configuration Protocol [DHCP] server), and Simple Network Management Protocol (SNMP)-enabled devices.
Real-time health monitoring
You can write scripts that use WMI event subscriptions to monitor and respond to the creation of event log entries, modifications to the file system or the registry, and other real-time operating system changes. Conceptually, event subscriptions and notifications perform the same function in WMI as traps do in SNMP.
Microsoft Windows Server System applications
You can write scripts to manage Microsoft Application Center, Operations Manager, Systems Management Server, Exchange Server, and SQL Server.
In some cases, the capabilities found in WMI replicate capabilities found in command-line tools or GUI applications. In other cases, however, WMI provides management capabilities not readily available anywhere else. For example, before WMI the seemingly trivial task of retrieving the total amount of physical memory installed in a remote Windows-based computer could not be scripted, at least not without using a third-party tool. In fact, prior to WMI the only operating system tool that enabled you to determine the amount of memory installed in a computer was the System Properties dialog box. Although this approach works fine for manually retrieving the memory configuration on the local computer, it cannot be used to automatically retrieve the memory configuration, or to obtain memory information from a remote computer.
Using WMI, however, you can retrieve the amount of physical memory installed on any computer (or at least any computer you have administrator rights to) by using the simple WMI script in Listing 6.1.
Note
- Admittedly, the script might not look all that simple at first glance. As you will discover, however, much of the script is boilerplate code that can be used, unchanged, in any WMI script that retrieves information about a managed resource.
Listing 6.1 Retrieving and Displaying Total Physical Memory
1 2 3 4 5 6 7 8 9 10 |
|
If you run this script under CScript, you should see the number of kilobytes of physical memory installed on the target computer displayed in the command window. The following is typical output from the script:
Total Physical Memory (kb): 261676
So how did the script determine the amount of memory installed on the computer? If you look at the boldfaced items in the code, you will see that the script performed two tasks:
It connected to a WMI class named Win32_LogicalMemoryConfiguration.
WMI classes represent the managed resources on a computer. As the name implies, Win32_LogicalMemoryConfiguration allows you to retrieve information about the memory configuration on a computer.
It echoed the value of a property named TotalPhysicalMemory.
WMI classes which are typically virtual representations of real, live items have properties that mimic the properties of the real, live item. By looking at the memory configuration on a computer, you can determine the total amount of memory installed. Likewise, the Win32_LogicalMemoryConfiguration class has a property that can be used to determine the total amount of memory installed on a computer. The properties of a WMI class are typically the same as the properties of the actual item. Disk drives have properties such as heads, sectors, and cylinders. The Win32_DiskDrive class has properties such as TotalHeads, TotalSectors, and TotalCylinders.
In addition to physical memory, Windows-based computers also support the concept of virtual memory. Not too surprisingly, the Win32_LogicalMemoryConfiguration class also has a property that corresponds to the virtual memory on a computer: TotalVirtualMemory. If you want to know the total amount of virtual memory on a computer, you can use the script shown in Listing 6.2. The single item in boldface (the property name) is the only real difference between this script and the script that returned the total physical memory installed on a computer. (The script also echoes the phrase, "Total Virtual Memory (kb)" as opposed to "Total Physical Memory (kb).")
Listing 6.2 Retrieving and Displaying Total Virtual Memory
1 2 3 4 5 6 7 8 9 10 |
|
Of course, WMI can be used to do more than just return information about the memory configuration on a computer, For example, the script in Listing 6.3 retrieves and displays the name, state, and startup type for all of the services installed on a computer.
Listing 6.3 Retrieving and Displaying Information About Services
1 2 3 4 5 6 7 8 9 10 |
|
Running this script under CScript produces output similar to the following (only partial output is shown):
Display Name: MSSQLServerADHelper
State: Stopped
Start Mode: Manual
Display Name: Network DDE
State: Stopped
Start Mode: Disabled
Display Name: Network DDE DSDM
State: Stopped
Start Mode: Disabled
Display Name: Net Logon
State: Running
Start Mode: Auto
If you look closely at the script in Listing 6.3, you should notice two things:
Instead of using the class Win32_LogicalMemoryConfiguration, this script uses a class named Win32_Service. Why? Because it is returning information about services, not about memory configuration. If the script was returning information about a computer monitor, it would use the class Win32_DesktopMonitor. The class name will always change to reflect the managed resource.
The properties echoed in this script differ from the properties echoed in the previous scripts. Why? Because services have properties that differ from memory configuration properties. Services have properties such as display name and start mode; memory does not. The properties will always change to reflect the managed resource.
If you are beginning to detect a pattern here, you have already taken a big step toward learning how to write WMI scripts. WMI scripts that retrieve information about managed resources are almost identical; you can take a basic script template, type the appropriate class name and class properties, and retrieve information for nearly all managed resources. (In fact, a template that lets you do this is provided later in this chapter.)
As you will see throughout this chapter, WMI scripts typically involve three steps:
They connect to the WMI service.
They retrieve some information about WMI classes.
They do something with that information (for example, echo it to the screen).
To a large extent, all WMI scripts follow this same pattern. For example, suppose you want to write a script to retrieve and display records from the Windows event logs. Reusing some of the code from Listing 6.1, you can easily create a script that carries out this task, as demonstrated in Listing 6.4. In this listing, the starting point for each of the three steps of a typical WMI script is denoted by the boldfaced numerals 1, 2, and 3: 1) Connect to the WMI service; 2) retrieve information; 3) display that information.
Note
- Before you run Listing 6.4, be aware that this script can take a long time to run if your event logs contain thousands of records.
Listing 6.4 Retrieving and Displaying Windows Event Log Records
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|