A New Way to Manage Win 2k

Windows Management Instru-mentation (WMI) is an

implementation of a standard for structuring, sharing, and operating management

services or information using Windows 2000. It’s derived from the Web-Based

Enterprise Management (WBEM) standard as specified by the Distributed Management

Task Force (DMTF).

WBEM lays down guidelines on how to set up a network

infrastructure that can be easily managed. Items like software deployment,

naming conventions, services that run on the network, manage a remote

workstation, etc, all come under this. It extends itself to work with existing

network tools, components, and management protocols like SNMP (Simple Network

Management Protocol), DMI (Desktop Management Interface), etc. The management

information structure modeling and how it’s queried is described in a

specification known as the Common Information Model. It has a particular schema

that serves as a repository of all management information.

WMI is an implementation of WBEM in Windows 2000. A quick way

to see WMI in action is to right-click "My Computer" and select

Manage. The MMC console pops up and everything you see is a part of what WMI

does. Click on any of the sections on the left-pane. If you have a slightly slow

computer, you might even catch a glimpse of a system message that says

"Connecting to WMI Service". The message differs for different

sections. For example, even the message "Refreshing system

information" that appears when viewing the System Summary (under System

Information) is WMI at work.

WMI has a rich set of interfaces (API, not GUI) and COM

objects that can be queried and manipulated using any language that supports

COM. In this discussion, I’ll use VBScript for this.

The basic concepts

The WMI model consists of three basic components–The Object

repository, Object Manager, and WMI Providers. The Object repository stores all

management information. The Object Manager gathers and manipulates information

like attributes and values of managed objects from this repository. It provides

this information to management applications like the MMC. The third component,

called WMI providers actually go and retrieve information from managed objects.

The Object Manager sits between management applications, object repository, and

the WMI providers. For example, if a query comes to the Object Manager, which it

can’t find in the repository, it passes it on to the corresponding WMI

provider, which then retrieves this information for it.

Windows 2000 ships with a lot of WMI providers by default.

The interesting ones are Win 32 provider, which can be used to list the OS

version, computer, file system, security, etc, and the WDM provider, which uses

devices, ports, etc.

Scripting for WMI

WMI scripting can be very useful, if you want to set up small

management specific job modules, to quickly let you access certain

system-related data. You can manage everything from computers, system services,

file systems, network related data, and system monitoring tools, to name a few.

It can be even more powerful if combined with ADSI (see page 110 in this issue).

Scripts generally access different pre-defined objects and

use their properties and methods to query the repository to access values. These

values can then be modified (in case the attribute allows read/write options).

Take a look at the following code segment:

for each Process in

GetObject ("winmgmts: {impersona tion Level=

impersonate}"). Instances Of ("Win32_ process")

WScript.Echo Process.Name

Next

The code is very simple. When run, it shows a list of all

currently running processes. The GetObject line does all the work. It connects

to the winmgmts service (Windows Management) and sets something called an

impersonation level. This is basically a Kerberos authentication mechanism that

allows a server to impersonate to other servers or services, say the currently

logged-in user. Once impersonated to WMI, the script looks for all items that

are of the type Win32_ process, and outputs their names in a loop.

Now by slightly modifying the code, think of what you can

actually create, a task manager equivalent to kill misbehaving programs, even on

remote machines. All you need to do is change the GetObject line to:

GetObject("winmgmts:{impers onation Level=impersonate}!//myremotemachinename").

InstancesOf ("Win32_ process")

Just change the myremote machine name to the name of the

machine you are trying to connect to.

The object also has another very powerful method–ExecQuery–which

lets you specify queries in an SQL like language called WQL–the WMI query

Language. For example, to see all instances of, say, Word running on my machine,

I’d change the above line to read:

for each Process in GetObject ("winm mts:{impersona

tionLevel=i mper sonate}").ExecQuery("select * from Win32_process

where Name= ’Win Word.EXE’")

WScript.Echo Process.Name

Next

This does nothing exciting. It just shows me a single

Winword.Exe instance running. But to make things more exciting, replace the

Wscript.Echo line with the following line:

Process.Terminate(0).

Before you run the script, remember to save your work. The

script will kill the process without any warning. Now think of an administrator

who has this power for a remote machine. He can simply enter the name of a

misbehaving process and the machine name that’s affected, and presto his job

for the day’s done. It can save a lot of time in large networks.

I mentioned WQL briefly earlier. Let me elaborate on it a

little. WQL uses a SQL-like syntax to query the repository for different values

as those for hardware, software, network and resource management sections. The

only difference here is that instead of querying tables, you query objects in

repository. The number of tables or objects in this repository is very large.

Take for instance, objects that deal with hardware and the operating system

itself. You have win32_processes, win32_videosettings, win32_network adapter,

win32_operating systembuild, and a lot of others. We could fill up pages if we

were to simply list the names of these objects. So instead of that, we’ll end

this article with a small tip. You can use the above WQL-based code snippet with

minor modifications to quickly enumerate all the different types of objects,

their attributes and the current values, just like the Windows 2000 Management

interface, and even adapt it to view these for a remote machine.

Vinod Unny is a technology consultant at with iSquare Technologies