An Introduction to WMI

Windows 2000 administration

Editor's Note: Each month, this column discusses various aspects of the advanced administration of e-business sites. This month's column examines WMI, a robust, scalable, and exciting technology to help you manage your enterprise systems, applications, and networks as they become larger and more complex.

A few weeks ago, I received an email message from a member of the Microsoft Visual Studio (VS) team. The team was working on the application service provider (ASP) software development kit (SDK). My mission for this SDK project was to write Windows Script Host (WSH) code that read the entire configuration of a local Web server then installed an identical version on a remote server. The idea was that this script would be both a valuable tool for IIS administrators to use in spinning up new servers in a Web farm and a perfect piece of code for the ASP SDK.

The aspect of this task that terrified me most was that the code might not read the configuration of a Web server. Using Active Directory Service Interfaces (ADSI), the system can easily read the configuration of a Web server and iterate the IIS metabase for the properties of the virtual directories, and so on. You can also easily write a WSH script that creates a Web server and all its virtual directories. What scared me was executing the WSH script code necessary for creating the Web servers remotely.

After some research, I learned that Windows Management Instrumentation (WMI) offered the best way to accomplish this task. I downloaded the WMI SDK from the Microsoft site; within 10 minutes of reading the documentation, not only did I learn that WMI could execute processes on remote servers, but I found a WSH script that uses the WMI technology to do the job.

Before I delve into the technical details of WMI, let me give you an example of its power. With WMI, you can

Now, before you say, "I don't need WMI to do all that," let me tell you that WMI lets you do everything I just identified and more on a remote machine. You need a security context under which to run (i.e., username and password), but with WMI you can execute a program (e.g., .exe, .vbs) remotely.

A Little Background on WMI
WMI contains several key features that are valuable for solving complex administrative tasks. Those features and capabilities include a Uniform Scripting API, discoverability and navigation, query capability, and powerful event publication and subscription. However, what I find most exciting about WMI is its remote-administration capabilities. Objects that you manage within WMI are, by definition, available to applications and scripts both locally and remotely. No additional work is necessary for managing remote objects.

WMI is the Microsoft implementation of Web-Based Enterprise Management (WBEM), which is an industry initiative to develop a standardized technology for accessing management information in an enterprise environment. Management information includes details about the state of system memory, inventories of currently installed client applications, and other information about client status. WMI can handle many tasks, ranging from simple workstation configuration to full-scale enterprise management across multiple platforms. When you implement WMI on Windows platforms, the technology enables the Common Information Model (CIM) designed by the Distributed Management Task Force (DMTF) to represent systems, applications, networks, and other managed components. CIM can model anything in the managed environment regardless of data source location. In addition to data modeling, WMI offers a powerful set of base services that include query-based information retrieval and event notification. One COM programming interface makes possible access to these services and to the management data, which means that you can use WSH scripts to exploit the technology. Microsoft supports the WMI OS core components on Windows 2000, Windows NT 4.0 with Service Pack 4 (SP4) or later, Windows 98, and Win95 OEM Service Release 2 (OSR2).

Remote Execution with Exec.vbs
Both the WMI SDK and the Microsoft Windows 2000 Resource Kit contain a WSH script called exec.vbs. The exec.vbs documentation available at the time of publication explains that you can use exec.vbs to

Very little documentation exists to explain the full functionality of exec.vbs. This lack of documentation is unfortunate because exec.vbs is a powerful script that I know you can put to work immediately to help you automate your job responsibilities.

You can download exec.vbs from the code library on the IIS Administrator Web site (http://www.iisadministrator.com/), or you can extract it from within the WMI SDK on the Microsoft Developer Network (MSDN) Web site (http://msdn.microsoft.com/developer/sdk/wmisdk/). You can place the script wherever you've accumulated your WSH administration scripts, but it can reside in any location.

Although exec.vbs has no documentation, like any good WSH script, its functionality includes brief usage documentation when you execute the script with Help parameters (i.e., /h, /?, or ­h). Figure 1 shows you how to execute the script with the Help parameter /h. Notice a few points about the usage Help in Figure 1. First, you must specify the username and password that have privileges on the remote machine. Obviously, you can't indiscriminately execute processes on any machine on your network under an Anonymous security context. In addition, if you want to execute processes on machines over the Internet, you need to do some firewall work. WMI's remote process execution operates on port 512, which every firewall blocks by default. Second, you can specify an output filename on the local machine that can capture any screen output and write it to a file for later diagnosis. You use this feature when executing exec.vbs in a scheduled environment (e.g., when the Win2K or NT Task Scheduler executes the script automatically). If you need help identifying a process ID, you can use another WSH script, ps.vbs, which is also available for download from the IIS Administrator Web site.

Now that I've told you about the incredible remote-execution capabilities of WMI, let's put those capabilities to work. Consider the following WSH script execution of exec.vbs and its parameters:

cscript exec.vbs /e _"C:Program Files _   Internet Explorer _Iexplore.exe" /s _   "TargetServer"  /u _"Administrator" /w _"Password"

The effect of this command is to run Microsoft Internet Explorer (IE) on a completely different computer called "TargetServer." Note that I've included the absolute path to IE: Execution takes place in the winntsystem32 folder on the remote machine, and because IE neither resides in that folder nor is mapped to it, an absolute path to IE's location is necessary. The winntsystem32 folder contains literally hundreds of programs. If you have access to an administrative account on a remote Win2K (or NT 4.0 with SP4 or later) server on your network and you know that that server isn't currently in use (either directly or indirectly), try the following code:

cscript exec.vbs /e sol.exe _/s TargetServer  /u _Administrator /w _password

Solitaire (sol.exe) resides in the winntsystem32 folder, so you don't need an absolute path to its location on the remote server. On the local machine on which you've executed the exec.vbs WSH script, you'll receive a message from the script about the success of remote execution and the process ID that resulted on the remote machine, as Figure 2 shows.

If you look at the remote server's screen, you'll see that Solitaire is running. You've executed it remotely. Now, before you go crazy over the practical-joke potential of this tool, be warned about the responsibility you need to exercise when playing with a tool that has this type of power.

For More Information
In this column, you've learned about WMI and its remote-execution capabilities. But remote execution is just a small fraction of what WMI can do for you. For more details about DMTF, CIM, WMI, and WBEM, visit http://www.msdn.microsoft.com/voices/news/wmisidebar2.asp. A full set of documentation about using WMI (and building software that leverages WMI) is available in the WMI SDK, which ships as part of the MSDN Win2K Platform SDK. You can download the core WMI components needed for NT 4.0 and Win9x systems from the MSDN site (http://msdn.microsoft.com/developer/sdk/wmisdk/).