Previous Page
Next Page

Testing the Local WMI Service

The first thing that must be done when troubleshooting WMI is to test the local WMI service to see if it is in fact responding to requests. In fact, many problems that at first appear to be WMI-related are not WMI problems at all. It is important to see if WMI is actually working, or if it is corrupt, or the service is hung. The application that is using WMI could have a problem, or the script you are trying to run could have an issue. Two utilities can be used to easily, reliably, and effectively test WMI. These two utilities will not tell you specifically where you have a problem with WMI, but they will let you know whether WMI appears to be working. If these two tools do not work, you really do have a problem that bears further investigation. The first utility is the WMI Control tool. The second tool we may want to use to test WMI is the Windows Management Instrumentation Tester.

Using the WMI Control Tool

The most basic check you can make to see if WMI is working properly is to open the WMI Control tool and see if it will connect. If it will not connect to the local instance of WMI running on your machine, you have a symptom of some more serious problems with WMI. If it does connect, it does not mean no problem exists; rather, at least some things are working correctly. This is the easiest check to make, and it should be the first step in troubleshooting. If the WMI service does not have the appropriate configuration, the connection will fail.

If the connection with the WMI Control tool succeeds, the panel seen in Figure 21-1 will appear. On the General tab, you will see the operating system (OS) version build number, service pack version, and the WMI version. In Windows XP and in Windows Server 2003, the OS version number and the WMI version number should match. In Windows 2000, the version of WMI is 1085.0005. The other information that is important from this tab is the WMI location, which should be in %systemroot%\system32\WBEM (in most cases, %systemroot% will be reported as C:\WINDOWS, as seen in Figure 21-1).

Figure 21-1. WMI general troubleshooting information


Paying Attention to Dependencies

By examining service dependencies, we can also obtain an indicator as to the health of the WMI service. This is important to the troubleshooting process. I have seen cases when someone thought they had a WMI problem and uninstalled the WMI service, or deleted the WMI database to rebuild it, and these actions did not solve the "WMI problem." Although not definitive, the state of a dependant service can provide a clue to the health of WMI.

If the WMI service is not running, several other services will not function either. The Security Center, System Management Software (SMS) Agent Host, and Windows Firewall are some of the services that depend on WMI. These service dependencies can be found in the Services tool, as seen in Figure 21-2. This means several errors should be in the Windows system event log, which indicates service failures.


Figure 21-2. Many services depend on WMI


Using the Scriptomatic

The Scriptomatic is a tool created by the Microsoft Scripting Guys. It can be useful from a troubleshooting perspective. The Scriptomatic will connect to any WMI namespace and list all the classes in the namespace. (The Scriptomatic is available from \My Documents\Microsoft Press\VBScriptSBS\Resources\ScriptomaticV2.hta.) When you choose the class, it will generate a Microsoft Visual Basic, Scripting Edition (VBScript) file listing all the properties of the class. You can then run the script from inside the ScriptoMatic. If properties are listed or if the script that is generated does not produce any output when run, you may have a problem with WMI.

Examining the Status of the WMI Service

If the WMI Control tool cannot make a local connection, you should check to see if the WMI service is running. The easy way to do this is:

1.
Start a new instance of the command interpreter, Cmd.exe.

2.
Type net start.

3.
Near the bottom of the list, look for Windows Management Instrumentation.

If Windows Management Instrumentation appears in the list, it is started. If it does not appear, it is not running. This would be rather strange, because the WMI service should restart itself if it stops or is stopped. The recovery setting for WMI is set to restart the service on the first and on subsequent failures. The recovery interval is set to one minute. If the WMI service fails, Service Recover will attempt a restart of the service every minute.

The next step in looking at the WMI service is to examine the service settings. To do this, we will use the Services tool. The following steps will walk you through using this tool:

1.
Click Start and then click Run.

2.
In the Run dialog box, type Services.msc and press OK.

3.
Scroll down the list until you find Windows Management Instrumentation. Double-click it.

4.
Select the Log On tab. Under Log On As, Local System Account should be checked. Allow Service To Interact With Desktop should be unchecked.

5.
Select the Recovery tab. Under Select The Computer's Response If This Service Fails, the first failure, second failure, and subsequent failures should all read Restart The Service. Reset Fail Count After should read 1 Days, and Restart Service After should read 1 Minutes. This is illustrated in Figure 21-3.

Figure 21-3. Use the Services tool to inspect and correct recovery settings


Using WBEMtest.exe

The Windows Management Instrumentation Tester can be used to troubleshoot WMI. In addition to just checking to see if WMI is actually running and accepting connections (as the WMI Control tool does), WBEMtest can be used to test the functionality of nearly every aspect of WMI, including security. One thing to keep in mind when using WBEMtest is that it cannot be used to specify alternate credentials for a local connection. To test alternate credentials, you must make a remote connection. In effect, WBEMtest is using the SWbemLocator method to supply alternate credentials, and SwbemLocator does not permit supplying alternate credentials for a local connection.

Quick Check

Q.

What is the easiest way to see if WMI is really broken?

A.

The easiest way to see if WMI is really broken is to open the WMI Control tool. If it makes a connection to WMI, then WMI is not totally brokenthere may be other problems, but WMI is not completely broken. On the other hand, if the WMI Control tool is not able to connect, you have a problem.

Q.

Why is WBEMtest unable to permit you to make a local connection into WMI using alternative credentials?

A.

The reason WBEMtest will not permit you to make a local connection into WMI using alternative credentials is that WMI itself does not permit it.



Previous Page
Next Page