We recently had a problem with one of our groups in that none of the five WMI sensors were gathering information (though

It turned out that Microsoft's Threat Gateway was configured to allow traffic on port 135 from the remote probe but the IP address of that probe within the gateway was incorrectly configured, so the connections from the actual probe were being dropped.

Now we fixed the IP address and three of the sensors started working again (cpu, uptime, memory) but the free disk and memory are both still reporting:

> Connection could not be established (800706BA: The RPC server is unavailable - Host: MACHINE, User: USERID, Password: PASSWORD, Domain: ntlmdomain:DOMAIN) (code: PE015)

They're all using the same credentials and I cannot figure out any differences between them that would explain the discrepancy.

Article Comments

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.


May, 2015 - Permalink

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.


Jun, 2015 - Permalink

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

Jun, 2015 - Permalink

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?


Nov, 2018 - Permalink

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


Nov, 2018 - Permalink