Paessler's Guide to Troubleshooting WMI Problems

Every so often customers using our monitoring tools (e.g. PRTG Network Monitor) report issues when trying to monitor their systems using WMI (Windows Management Instrumentation) sensors. In most cases, these issues stem from a malfunctioning WMI configuration/installation. For example, we have noticed that many times when WMI issues arise one (or multiple) WMI components crucial for proper WMI monitoring are missing or have not been implemented properly.

Getting started

Important! Before going any deeper into troubleshooting, a good knowledge of the principles and functions of WMI is necessary. Please refer to the following Microsoft article "Secrets of Windows Management Instrumentation" for frequently asked questions about WMI:

http://technet.microsoft.com/en-us/library/ee692772.aspx

Testing the WMI Connection Using Our WMI Tester

In order to troubleshoot WMI connection issues, please test the connection using our WMI Tester, available at http://www.paessler.com/tools/wmitester.

In order to test the connectivity and availability of the desired WMI counters, either for local or remote testing, start the WMI Tester and provide the following configuration data:

Target computer name / IP address
Domain: the Windows domain containing the computer you want to test, or the computer name if not running inside of a domain.
User: the name of a user with login credentials for the target machine
Password: the user’s password

Note: If you are testing the local machine, leave the above fields empty.

Further configuration entries available (under “Advanced Usage” are):

Domain prefix: This can usually be left as NTLMDOMAIN:
Query: Choose between six predefined query sets (OS, process, disk space, memory, processor load, network adapter) or enter your own query (in WQL).

Note: By default, the WMI namespace used is CIMV2.

After defining these settings click the „Test!“ button. After a while, you will either see a result table or, in the event something went wrong or the WMI service is not available, an error message.

What the WMI Tester does

The WMI Tester will forward the defined query using the provided credentials to scan against the counter in case. Generally, and if the provided credentials allow to connect to the target machine in case, the WMI tester will receive a response from the WMI service, most often in the form of a table. If an error does occur, the WMI Tester utility will provide the error code or a text alarm referring to the issue in case (for example, if it was unable to connect to the defined target machine / domain). If a result set is returned, the WMI service and the credentials provided for the target machine are working properly, and as such, the same query should be possible from within PRTG 7.

The Most Common WMI Errors

Very often, PRTG is being obstructed from monitoring WMI counters. As these errors are on a very low communication level, no WMI sensor in the device will run and all will show one of the following errors:

Port Error 135: RPC Server Not Accessible

If you see this precise error message, the port which all DCOM communication protocols are routed over, is blocked. This is either by a local firewall, by domain policies, or the RPC service on the monitored machine is not running.

800706BA - RPC Server Is Unavailable

This is quite an ambiguous message, as there can be different causes to it, among which are:

The RPC service is not running on the monitored machine.
Sometimes, this error occurs when using an IP address to connect to a device. Try using hostname or FQDN (Fully Qualified Domain Name) instead. In PRTG, please enter this information in the device's settings (section "Credentials for Windows Systems").
The monitored machine is not able to connect to the Primary Domain Controller thus unable to verify the Windows credits provided for the WMI sensor. Check your Domain Controller settings.
Either the computer running the PRTG probe or the monitored machine are provided with wrong DNS entries. This might be the case when the machine has opened one or more VPN connections additionally to the normal network connection. You can test this with a simple ping to the machine in question. Do you see the correct IP?

Further Troubleshooting Using Microsoft’s WMI Diagnosis Tool

If the Tester returns an error code, please check the service status using the following WMI Diagnosis Utility:

http://www.microsoft.com/downloads/details.aspx?FamilyID=d7ba3cd6-18d1-4d05-b11e-4c64192ae97d&DisplayLang=en

Information about the WMI Diagnostics Tool provided by Microsoft:

Quote: ‘WMIDiag.vbs is a VBScript script designed to help you ascertain the current state of the WMI service on a computer. The download package includes the utility itself, a ReadMe file that discusses how the tool works (and how to best use it), and sample spreadsheets that provide information about the default WMI configuration on various versions of the Microsoft Windows operating system.’

After running the WMI Diagnosis Tool, three files are created:

a .LOG file containing all WMI Diagnosis Tool activity (and a WMI report)
a .TXT file containing the same WMI report as mentioned above
a .CSV file containing various statistics valuable for measuring trends and issues

After the WMI Diagnosis Tool terminates, an ERRORLEVEL variable will be set to one of the following:

0 = SUCCESS
1 = ERROR
2 = WARNING
3 = Command Line Parameter errors
4 = User Declined (Clicked the Cancel button)

If the WMI Diagnostics Tool does not offer a solution to the issue in case, check the error codes provided by our WMI Tester and the WMI Diagnosis Tool. For further troubleshooting information as regards these particular error codes, please consult the following Microsoft TechNet article (aptly entitled "WMI Isn't Working!"), listing multiple WMI configuration issues, providing the methodology necessary to repair such configurations:

http://msdn.microsoft.com/en-us/library/aa394603(VS.85).aspx

For quick reference, the error codes and issues in former MSDN articles were:

0x8004100E (“Invalid Namespace”)
0x80041010 (“Invalid Class”)
0x800A01B6 ("Property or method not supported")
0x80041013 (“Provider not found”) or 0x80041014 (“Component failed to initialize")
Script doesn't return any data
Cannot connect to a remote computer
Script not working even though namespace, class and property are correct
WMI service is running, all the .DLLs have been re-registered, script still not working
WMI repository rebuilt, script still not working

In most cases, if a corrupt WMI configuration is at fault for the issues at hand, the above process should allow to repair the configuration so that the WMI service in case is fully functional, allowing PRTG to access the relevant WMI counters on the target machine.

Please note most of these articles relate to actual WMI configuration issues, not necessarily errors that might be triggered due to software-specific issues. As such, if your PRTG sensors enter a "grey" state (status unknown), the articles above will most likely be of little use, seeing as this particular issue is not related to the actual WMI configuration. In the event of such issues, please try connecting with the WMI Tester to determine if you can connect at all (in which case the issue would not have to do with the actual WMI configuration) or if the situation stems from a software-specific issue. In the latter case (i.e. if the WMI Tester is able to connect but the PRTG software is not), please contact our support staff for individualized troubleshooting.

Microsoft Exchange Issues

Solving "8002801D : Library not registered" Error Messages

We have seen this error message on Exchange Server 2003, but it may also apply to other systems. We have found that simply restarting the WMI Service (using winmgmt.exe) once (sometimes even several times) can overcome this error message.

Open a cmd console and issue the following commands:

winmgmt /clearadap
winmgmt /kill
winmgmt /unregserver
winmgmt /regserver
winmgmt /resyncperf

Close the console and restart the PRTG7 Probe Service. Your sensors should now turn green and display values.

Missing WMI counters under Exchange 2003

If Exchange 2003 WMI Sensors do not return any results at all nor do they display precise error messages (like the above mentioned "8002801D: Library not registered"), the reason might be missing performance counters for Exchange Server 2003. Please have a look at the following Microsoft support article for a solution:
http://support.microsoft.com/?scid=kb;en-us;820847&x=12&y=10

If the above method did not work, we have found another batch script which might help to repair the respective performance counters by re-installing parts of the components. The steps are listed in the answer to the following MSDN-Forum request:
http://social.msdn.microsoft.com/Forums/en-US/os_exchangeprotocols/thread/35dbf170-645e-475a-8ffa-7e76bb20f2ee

Quick Fix for Exchange 2000 and 2003

Our customers also detected a quick fix for WMI issues regarding Microsoft Exchange which you might find helpful (no restart required). Please note: This fix involves deleting the repository, which can envoke a lot of other problems. Generally, it is not recommended to delete the repository! For more information see also: http://blogs.technet.com/configmgrteam/archive/2009/05/08/wmi-troubleshooting-tips.aspx

However, if you read the information linked above and still want to proceed, be careful with the following instructions!

Stop the WMI service (winmgmt.exe) on the problem server. This action usually also stops the Microsoft Exchange Management service. If not, stop that service.
On the problem server, rename the "%systemroot%\system32\wbem\Repository" folder to "%systemroot%\system32\wbem\Repository\Repository.bak".
Copy the "%systemroot%\system 32\wbem\Repository" folder from a known good Exchange 2003 or Exchange 2000 Server machine to the problem server.
Start the WMI and Microsoft Exchange Management services.
Test WMI by using WBEMTest to open the Win32_PerfRawData_SMTP SVC_SMTPServer class in the root\cimv2 namespace.