Leveraging Scripts for Improved System Management

The WMI scripting API can be used for the multiple purposes:

• Enumeration ” A WMI scripter can write scripts to enumerate processes running on a local system or settings on a device.

• Method execution ” A WMI scripter can create scripts to initiate or shut down a specific process or application on a remote computer.

• Queries ” Rather than enumerate, a WMI script could query a subsystem to determine if a specific process or device is running on a local or remote system.

• Event registration and reception ” A WMI script would watch for specific events from the Windows NT Event Log on a local computer.

• Instance modification ” WMI can be leveraged for modification of information. For example, workstations created with Sysprep could change their own names to their unique processor ID automatically via a WMI script upon their first boot.

• Local and remote access ” WMI scripts can be targeted to operate on local resources as well as remote resources. This can be especially powerful in allowing one machine to monitor and potentially fix another.

Through combinations of these functions, you have amazing flexibility in creating complex scripts that can react to a number of situations and trigger events, alerts, or even other scripts. By chaining these scripts one can create fairly advanced logic for determining how a system should deal with its own triggers.

Basic WMI Scripts

Here is an example of a basic script that will query a machine called Godzilla for its total physical memory:

 strServer = "Godzilla" Set wbemServices = GetObject(" winmgmts :\\" & strServer) Set wbemObjectSet = wbemServices.InstancesOf("Win32_LogicalMemoryConfiguration") For Each wbemObject In wbemObjectSet WScript.Echo "Physical Memory (kb): " & wbemObject.TotalPhysicalMemory Next 

By feeding this script a series of machine names, WMI could be used to perform a memory audit on a series of machines to see if they needed to be upgraded prior to an OS upgrade.

This script shows how to enable you to select targets for a script. This script queries the user for a target machine and a target application to terminate on the target machine:

[View full width]

 do SrvrName = inputbox("Enter the name of the system to kill an application on.", "Input") loop until SrvrName <> "" do target = inputbox("Enter the name of the program you wish to kill. ", "Kill a Process") loop until target <> "" for each process in GetObject("winmgmts:{impersonationLevel=impersonate}!\\"&SrvrName&"  \root\cimv2").ExecQuery ("select * from Win32_Process where Name='" & target & " ' ") process.terminate(0) Next wscript.echo "Program terminated ." 

A script like this could be handy for remote administration. If a user called the help desk and complained of a runaway process that they did not have rights to end, the help desk could run a script like this to end the process for the user. This would eliminate the need for a technician to be dispatched to the user's location.

Defaulting to the Local Machine

If a script uses a target [strServer =] of "." it is defaulting to the local machine. If a script is only dealing with a single remote system, the system name can be entered there.

Building Services

By combining C++ or Visual Basic with WMI calls, services can be written to use WMI functions. This enables you to effectively run a script continuously without the system overhead of a script running over and over. A service of this type is created with the Win32_BaseService.Create parameter. It is recommended to run WMI services of this type under the System context. This prevents users from being able to simply stop the service.

Use the AT Scheduler

To control services running under the system context it is necessary to access them via the system context. The easiest way to do this is to use the AT scheduler to launch a command window with an /interactive switch. Anything done from this command window will run under the SYSTEM context.

Building Temporary Event Consumers

A temporary event consumer is created by a consuming application and ends when the application ends. In this way the subscriptions are only active when the consuming application is running. This is one way to reduce the CPU load on a system that is using WMI.

Building Permanent Event Consumers

A permanent event consumer is a COM object that is able to receive a WMI event at all times. A permanent event consumer uses a set of persistent objects and filters to capture a WMI event. Not unlike with a temporary event consumer, a series of WMI objects and filters are set up that capture a WMI event. When an event occurs that matches a filter, WMI loads the permanent event consumer and notifies it about the event. Because a permanent consumer is implemented in the WMI repository and an executable file that is registered in WMI, delivery of an event also continues across reboot of the operating system while WMI is running.

A permanent event consumer continues to receive events until its registration is explicitly cancelled. A permanent event consumer is a combination of WMI classes, filters, and COM objects that reside on the system.

A logical event consumer is an instance of the permanent consumer class. The properties of a logical event consumer specify the actions to take when notified of an event, but do not define the event queries with which they are associated. When signaled, WMI automatically loads the COM object that represents the permanent event consumer into active memory. Typically, this occurs during startup or in response to a triggering event. After being activated, the permanent event consumer acts as a normal event consumer, but remains until specifically unloaded by the operating system.

Be Sure to Test the Service and Watch for Memory Leaks

When creating permanent event consumers, be sure to test the service and watch for memory leaks. Some WMI classes are known to have memory leaks. If the memory consumption of svchost .exe increases continuously, this is a common sign of a WMI memory leak.