Cannot figure out why some WMI sensors work and some don't.

Deear Paxdiablo

Many WMI issues can be circumvented with a PRTG remote probe. The remote probe agent can be downloaded via the PRTG webinterface, Setup | Download Add-Ons | Remote Probe Installer.

If you move the WMI sensors to that probe, the WMI query is done locally, so WMI authentication is no longer an issue.

The other option is to use an SNMP agent instead, for example SNMP Informant. That software offers to monitor a range of performance metrics via SNMP. PRTG "SNMP Library" sensor comes with a library for the free SNMP Informant version.

We did a lot to get WMI queries as stable as possible: If a request fails, PRTG automatically repeats that request once. Many WMI sensors are in fact hybrid sensors which also use the Performance Counter interface and WMI as fall-back method.

If you constantly get false alarms or no data, please either use the Remote Probe agent of PRTG, or the SNMP Informant solution.

Arne, I'm not certain I understand your response. PRTG touts itself as not having to install software on thousands of PCs by virtue of the fact it uses standard methods for gathering the data (WMI, etc).

We already have a remote probe in the environment and it's happily getting some data from the boxes it's monitoring, boxes that are quite separate from the remote probe box itself. What I'm trying to discover is why some of the sensors work and some don't.

You appear to be saying I need to either install a remote probe on all the PCs we want to monitor, or install some other third-party product to do the work. First, that makes PRTG far less useful than your marketing material seems to suggest. Second, we cannot install arbitrary software on all the boxes, that's both a security and management nightmare.

I would like to find out what methods are used to gather the information in the sensors "Windows CPU Load Sensor", "Windows System Uptime sensor", "Windows Pagefile Sensor", "WMI Free Disk Space (Multi Disk) sensor", and "WMI Memory Sensor"? The first three of those work fine, the latter two do not. If the latter two use WMI and the others don't, that's where we'll have to concentrate our investigation.

Dear Paxdiablo

To debug WMI issues, please use the WMI tester.

You can find the WMI queries we use for our sensors in this article. This way you can see the data which PRTG gets.

However there can be a difference caused by the different credentials used: The PRTG probe usually runs with the local System user. The WMI tester runs with the current user credentials.

For example the Multidisk query is

SELECT DriveType,DeviceID,FreeSpace,Size,VolumeName 
FROM Win32_LogicalDisk 
WHERE DriveType=3

For WMI memory, the sensor uses several queries in succession if the previous one does not result in usable data:

SELECT FreePhysicalMemory,TotalVisibleMemorySize 
FROM Win32_OperatingSystem

SELECT AvailableKBytes 
FROM Win32_PerfFormattedData_PerfOS_Memory

Select TotalPhysicalMemory 
FROM Win32_LogicalMemoryConfiguration

what is your advice when the WMI tester tool returns an expected value from probe to remote machine. But the exact same route in the GUI is down with the code PE015?

Several things to check out:

• PRTG probe / service account - make sure WMI runs with those credentials
• PRTG internal device/sensor accounts - make sure those have access
• logon to the PRTG probe server with either the service or the device account you use - test WMI connection from this account
• probably do a winmgmt /verifyrepository on your target system - if it is fine, good.. if not.. try to salvage it (/salvagerepository) or fix it somehow ...

normally this solves the issue - especially if it was working before... I saw WMI going crazy for many reasons - normally it is not PRTG that is causing any issues, it actually is WMI itself, PRTG is just using it to it's limits and due to the monitoring that comes with it revealing the issues with it...

Hope this helps - if not - let me know what the results of the above tests have been, so we can dig deeper...

Regards

Florian Rossmark

www.it-admins.com