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