Remote Administration with WMI

The remainder of Listing 3's script—after the WMI connection is established—is identical to Listings 1 and 2. Following is a portion of the output that Listing 3 produces.

ATL-LAB-01: Disabled,Stopped
ATL-DC-01: Manual,Stopped
ATL-WEB-01: Disabled,Stopped
192.168.0.4: Permission denied
192.168.0.5: Telnet not installed.
192.168.0.6: Telnet not installed.
192.168.0.7: Host unreachable

If you're curious, the node with the IP address 192.168.0.4 is a Windows XP Home Edition computer, which doesn't permit remote WMI connections.

To run Listing 3 on a range of IP addresses in your network, you'll need to change the value assigned to strIPSubnet and the starting and ending values assigned to strIPNode in the For statement. You'll also need to ensure that you're running WSH 5.6, the version that introduced the Shell object's Exec method.

Put It to Work
You're probably wondering how you would adapt Listing 3 to run one of the WMI scripts in the Script Center. The good news is that the answer is simpler than you might think.

Suppose you want to remotely run the "Restart a Computer" script (which you'll find at http://www.microsoft.com/technet/scriptcenter/compmgmt/scrcm38.asp) against all the computers in a specified IP address range. You would follow these steps:

1. Replace the code at callout A in Listing 3 with the GetObject call in Microsoft's script:

Set objWMIService = 
  GetObject("winmgmts:" & _
  "{impersonationLevel=impersonate," & _
  "(Shutdown)}!\\" & strComputer & _
  "\root\cimv2")

2. Replace the code at callout B in Listing 3 with the ExecQuery call in Microsoft's script:

Set colOperatingSystems = _
  objWMIService.ExecQuery _
  ("Select * from _
  Win32_OperatingSystem")

3. Replace the code at callout C in Listing 3 with the For Each loop in Microsoft's script:

For Each objOperatingSystem in _
  colOperatingSystems _
  ObjOperatingSystem.Reboot()
Next

Listing 4 shows the final script. A word of caution before you unleash Listing 4 on your network: The script will also restart the computer running the script if the computer is assigned an IP address in the range of the target subnet. If such is the case, you can add an additional decision statement (If...Then...Else) inside the body of the main For loop to force the script to skip the local computer. To turn a local computer script into an enterprise juggernaut, you can apply the previous steps to most of the WMI scripts in the Script Center.

What About Security?
WMI security is robust. Although I don't have the space to delve into the nitty-gritty details of WMI security, I'll try to put any immediate concerns to rest and follow up with details in a subsequent article.

Whenever you use WMI, you pass through several security checkpoints. I've already mentioned the first: the WMI permissions checkpoint. WMI permissions are implemented at the namespace level (e.g., \root\cimv2) and checked when you establish a connection to WMI on a local or remote computer. You use the Microsoft Management Console (MMC) WMI Control snap-in to configure WMI permissions. By default, administrators are the only trustees granted the Remote Enable WMI permission.

The second checkpoint is DCOM security. The default DCOM setting for WMI is to impersonate the caller, which is the person or process running the script. The third and final checkpoint is the OS's security subsystem. The basic rule is that WMI doesn't provide access to anything you don't already have access to.

Finally, what about your Web browser? The good news is that all the WMI scripting objects (e.g., SWbemServices, SWbemObject) in the WMI scripting library are marked as unsafe for scripting. So, providing your users haven't lowered their Web browser's security settings, you're safe. However, if your users have lowered their browsers' security settings, you might consider implementing a system policy to manage your organization's security settings.