A trend seems to be growing in Redmond. Microsoft is taking administrative tools and command-line utilities once shackled to run on the local computer and transforming them into remote administration juggernauts. The catalyst behind the change is Windows Management Instrumentation (WMI), the underlying instrumentation on which the tools are built.
An often-overlooked fact about WMI is that from the beginning, Microsoft designed WMI to support remote administration scenarios. Any task that you can perform locally with a WMI-enabled tool, you can also perform remotely. To demonstrate WMI's remote administration agility, I want to walk you through several scenarios. First, I present a simple WMI script that performs an administrative task on the local computer. Next, I show you how to easily transform the script into a remote-savvy script. Finally, I show you how to run the script against all the computers on a remote IP subnet.
To get the most from this article, you need a basic knowledge of WMI and WMI scripting. If you need to build some skills, I encourage you to read Microsoft's "WMI Scripting Primer: Part 1" at http://msdn.microsoft.com/library/en-us/dnclinic/html/scripting06112002.asp.
Pick a Task, Any Task
The administrative task that I want to perform on the local computer is to check the Telnet service's Startup Type and Status. Now, before you say, "Please, not another services script," let me stress that the task is largely irrelevant. You can easily substitute this task with any of the hundreds of WMI scripts available at the Microsoft TechNet Script Center (http://www.microsoft.com/technet/scriptcenter). My objective is to show you how to take a common WMI script and scale it to service hundreds or thousands of remote computers.
Listing 1, page 54, shows the local version of the Telnet Server script, appropriately named TelnetCheck.vbs. The script begins by initializing the strComputer variable with a string that consists of a single dot, or period. In WMI scripting, the dot represents the local computer. Because this script runs on the local computer, I could have omitted the strComputer variable, but isolating the target computer variable (as Listing 1 shows) makes adapting the script to support remote computers easier.
The script uses VBScript's GetObject function to connect to the WMI service on the target computer. The string that the script passes to the GetObject function is a WMI connection string (aka a moniker) that consists of three components:
- the mandatory WMI prefix, "winmgmts:"
- security settings that tell WMI to impersonate the caller (i.e., use the security context of the person or process running the script to establish the connection)
- a WMI object path that comprises the target computer name and the WMI namespace to connect to on the target computer
GetObject returns a reference to the WMI scripting library's SWbemServices object, which represents an authenticated connection to WMI on a local or remote computer. To learn more about the WMI connection string, see "WMI Monikers," May 2001, http://www.winnetmag.com, InstantDoc 20401.
After the connection is established, Listing 1 calls the SWbemServices ExecQuery method to retrieve the instance of the Win32_Service class that represents the Telnet service. ExecQuery returns a reference to an SWbemObjectSet collection—another automation object in the WMI scripting library. If Telnet is installed on the target computer, ExecQuery returns a collection containing exactly one item, which is assigned to the reference variable named colServices. If Telnet isn't installed, ExecQuery returns an empty collection. The script uses the SWbemObjectSet Count property to determine whether Telnet is installed on the target computer. If the Count property is equal to 0, the WScript Echo method echoes to the console a message stating that Telnet isn't installed. Otherwise, the Echo method echoes the Telnet service's Startup Type (the Win32_Service StartMode property) and Status (the Win32_Service State property).