A New Way to Manage Win 2k

Windows Management Instrumentation (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