Just wanted to add a troubleshooting step to this error. I get this every so often when I use an IP address to define a device in the "IP-Address/DNS Name" field. The solution that I've found is to replace the IP address with the FQDN of the device.

So for instance, instead of using 192.168.1.20 in the "IP-Address/DNS Name", try using the name of the server (ex: servername.domain.local).

I've had a troublesome WMI connection also and I used Nick's Name-not-IP method and it worked.

The target server in question (WF1) is identical in every way to another one (WF3). WF3 has worked from the local subnet's probe (MON1) all along and it's being addressed by IP from the probe MON1. WF1 would not accept a connection. I moved that WF1 device+sensors to the root probe (MON2) here in my home office and the device and all sensors worked via IP. In all cases I also tried various authentications to no avail including a device configured authentication (no inheritance).

I then tried a bit of WMI code VBS script via cscript from the WF1's probe machine MON1. Using the machine name the script connected and using the IP it would not. So this is not a PRTG implementation issue but purely some oddity with WMI. I've checked both DNS and WINS lookups and they resolve fine to all machines involved but then I'd expect that since it's the names that actually work in this WMI connection.

Maybe unrelated but I know in the past I've also seen issues with connecting to shares around windows networks where sometimes a name won't work but an IP will and sometimes the IP won't but the name will.

In case anyone needs to do a similar test here's code from Microsoft that I used to compare the use of IP vs Name. It just asks for credentials then uses that to list the running processes on the target machine.

strComputer = "YourComputer or IP Here" 
strDomain = "YourDomain" 
Wscript.StdOut.Write "Please enter your user name:"
strUser = Wscript.StdIn.ReadLine 
Set objPassword = CreateObject("ScriptPW.Password")
Wscript.StdOut.Write "Please enter your password:"
strPassword = objPassword.GetPassword()
 
Set objSWbemLocator = CreateObject("WbemScripting.SWbemLocator")
Set objSWbemServices = objSWbemLocator.ConnectServer(strComputer, _
    "root\cimv2", _
     strUser, _
     strPassword, _
     "MS_409", _
     "ntlmdomain:" + strDomain)
Set colSwbemObjectSet = _
    objSWbemServices.ExecQuery("Select * From Win32_Process")
For Each objProcess in colSWbemObjectSet
    Wscript.Echo "Process Name: " & objProcess.Name 
Next

Access Denied (PE 015) Error After PRTG Update

If your WMI sensors do not work any more after installing an update of PRTG (seen with an update v7.2—v7.3.5) please re-enter the "Credentials for Windows Systems" in your sensors' settings (or further up in the device tree if the sensors' settings are inherited).

I have to add my "Likewise" to this thread. We had a machine that's worked normally using IP based querying since January. Last Friday it stopped responding to WMI for no known reason. We followed all the instructions in this thread but nothing worked. DNS/WINS is not used in this setup so I added the device name/IP to the probe's hosts file and changed the Name/IP field to name in the PRTG device settings. Lo and Behold, the WMI sensors started working again.

What's weird is that nothing at all changed on the probe or the monitored machine. This problem just arrived all on its own.

Glad to have it fixed though. Thanks to all who figured it out.

Post translated by Paessler Support Team

One comment for version 7.3.5

I had a group of two non-domain PCs (Windows 2000) for which I had defined the credentials on group level without entering a PC/domain name.

After the update to version 7.3.5, the WMI sensors of the two PCs showed the WMI error described above. Only after I had entered the credentials including the PC name directly in the devices' settings, the WMI sensors began working correctly again.

So my advice is to avoid defining credentials on group level for devices when entering no data in the "Domain or computer name" field, but in this case enter the credentials for each device individually, including the computer name.

Original post:

Zur Version 7.3.5 habe ich auch noch eine Anmerkung:

Ich hatte eine Gruppe von 2 nicht Domain PCs (Windows 2000) für die ich das Passwort über die Gruppe ohne Angabe eines PC/Domain Namen definiert hatte.

Die WMI Sensoren der beiden PCs lieferten nach dem Update auf 7.3.5 den oben beschriebenen WMI Fehler. Erst nachdem ich die Credentials inklusive dem PC Namen in den Credentials der Device erfasst hatte, fingen die WMI Sensoren wieder an korrekt zu arbeiten.

"Sammelcredentials" für mehrere nicht Domainmitglieder ohne Wert im Feld "Domäne oder Computername" sollte man lieber mal sein lassen.

Attempting to monitor WMI disk free space (C: drive) on a Windows Server 2008 SP2 host. The server is in a workgroup (no domain) and has UAC enabled. I discovered UAC limits remote security tokens, including access to the root folder (C:\). This blocks WMI from gathering free space information with an "access denied" error even though administrator credentials are used. You can add the following registry key to disable this feature of UAC.

Path: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system

Key: LocalAccountTokenFilterPolicy

Value: 1 (DWORD)

Please be warned that this disables some of the protection provided by UAC. Specifically, any remote access to the server using an administrator security token is automatically elevated with full administrator rights, including access to the root folder.

More information can be found here: http://support.microsoft.com/kb/951016

Hi,

the tipp with Domain names instead of the IP worked really great.

Thanks a lot for this tipp, this WMI "Bug" was driving me mad.

David

Hi,

I have this problem ("Connection could not be established" (code: PE015)) with a server that is not on domain. I have tried a WMI troubleshooting and everything is ok.

Something like "RPC server is unavailable" appears. I have tested a telnet on port 135, I have checked if the RPC service was running, I have teste "
dest device\c$" and all of this is ok.

Do you have any idea what would be the problem?

Thanks in advance.

Hi, we also had this problem coming up and disappearing again. We looked at the server where the probe is running and there were a lot of Kerberos errors in system log, all related to the PCs which were suddenly not reachable. Turns out that the time differed throughout the network and the computer running the probe was > 5 mins away from the computers which the sensors run against. Bringing all PCs back to correct time solved the problem.

So besides the already mentioned ideas:

• check system log of computer where probe is running for kerberos errors
• check if time is correct on all PCs