When accessing WMI local or remote data in an application or script, you may encounter errors ranging from missing classes to access denied. The first step in most WMI-related cases is to test the ability to connect to the service on the local computer. Depending on the nature of the problem, you may also have to test the ability to connect to the WMI service on a remote computer.
If WMI returns error messages, be aware that they may not indicate problems in the WMI service or in WMI providers. Failures can originate in other parts of the operating system and emerge as errors through WMI. Despite what you may have heard or read elsewhere, deleting or rebuilding the WMI repository as the first step in troubleshooting is not recommended! Deleting the WMI repository could cause issues with the operating system or installed applications.
To obtain more information about the source of the problem, you can download and run the WMI Diagnosis Utility diagnostic command line tool. This tool produces a report that can usually isolate the source of the problem and provide instructions on how to fix it. After you have downloaded the utility, extract the files to C:\WMIDiag (for simplicity's sake) and run the WMIDiag.vbs file. By default the WMIDiag script will write the output to the user's temp folder, so I suggest defining where you want the log files written when you run the script - as follows: cscript c:\wmidiag\wmidiag.vbs LOGFILEPATH=c:\wmidiag . Once the script is finished, the log file will identify WMI issues. We'll look at WMIDiag in more detail in a future post.
Now let's take a quick look at some very simple troubleshooting steps that we could use to determine if the WMI Service is functioning.
Testing the Local WMI services
Oftentimes, the quickest way to test the if the WMI service is working at all is to just start the WMI Control snap-in.
- Click Start, click Run, type wmimgmt.msc, and then click OK.
- Right-click WMI Control (Local), and then click Properties.
If the WMI service is configured correctly, the WMI Control will connect to WMI and display the Properties dialog box. On the General tab, you should see information about the operating system and the version of WMI.
Starting with Microsoft Windows XP, the version of WMI should match the build version of the operating system. For example, in Windows XP, the WMI version is "2600.0000," and in Microsoft Windows Server 2003, the WMI version is "3790.000." The version of WMI in Microsoft Windows 2000 is "1085.0005." In versions of Windows earlier than Windows 2000, WMI was an installable component. The two most common distributions were v1.1 (build 698) and v1.5 (build 1085). On Windows XP and later operating systems, you can also use the WMIC utility to retrieve the OS build information - wmic OS get Caption,BuildNumber .
It is important to note that in the majority of instances, if you are able to pull up this information locally, then your WMI repository is in good shape (at least from a basic OS perspective).
Sometimes, you may have to test the ability to connect to the WMI service on a remote computer. The process is similar to the local test.
Testing the WMI Service on a Remote Machine
The process to perform a quick test of the WMI services on a remote machine is not much different than testing the local services.
- Click Start, click Run, type wmimgmt.msc, and then click OK.
- Right-click WMI Control (Local), and then click Connect to another computer.
- Click Another computer, and then enter the name of the remote computer.
- If you have to provide user credentials, click Change.
- Click OK.
- Right-click WMI Control (remote system name), and then click Properties.
In this example, I am connecting from my Windows Vista machine to my Windows Server 2003 machine which is named DARKSIDE. As you can see, I am able to retrieve the same information as if I ran the WMI test locally.
If you cannot connect to WMI on a remote computer, the first thing to do is test the WMI service locally on both of the computers (local and remote). If the WMI service looks good locally on both computers, then there may be a problem with COM permissions (which we'll look at in a future post).
Now let's take a look at testing WMI via a local script.
The Win32_WMISetting class was added in WMI v1.5 (Windows 2000, build 1085). Starting with this version, you can use the script that follows to gather the WMI settings data, including the build version. This script does not work on build 698, which is distributed with Microsoft Systems Management Server (SMS) for Microsoft Windows NT 4.0 clients and Microsoft Windows 9x clients). This script can be used as quick test of the WMI service (and scripting interface) on Windows 2000 and later versions of the Windows operating system.
Paste the following script into a text file, and then save the file with a .vbs extension (for example, Test.vbs):
set WMI = GetObject("WinMgmts:/root/cimv2")set obj = WMI.Get("Win32_WMISetting=@")
WScript.Echo obj.GetObjectText_(0)
When you run the script, the WMI Core Settings are returned, including a listing of all the MOF Files, the Build Version, the location of the WMI Repository and other settings. To test the provider host interface you could use a script similar to the one below:
set objs = WMI.InstancesOf("Win32_OperatingSystem")
for each obj in objs
WScript.Echo obj.GetObjectText_
next
If you recall our review of a basic script from our WMI Architecture post, this script parses the Win32_OperatingSystem WMI class and returns the values for each instance within the class.
And that brings us to the end of our post on Basic WMI Testing. In our future posts, we'll discuss Access Denied and Invalid Namespace issues, how to troubleshoot service startup failures, Data Gathering and more.
Additional Resources:
- Axel Rivera