New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


What can I do about "Connection could not be established" errors on my WMI sensors?

Votes:

2

Your Vote:

Up

Down

Every now and then my WMI sensors go into the Down state and report a "Connection could not be established" error. Why is that and what can I do about it?

connection pe-code prtg wmi

Created on Jan 25, 2010 9:56:19 PM by  Dirk Paessler [Founder Paessler AG] (10,859) 3 4

Last change on Dec 14, 2010 9:52:02 AM by  Daniel Zobel [Paessler Support]



25 Replies

Accepted Answer

Votes:

2

Your Vote:

Up

Down

"Connection could not be established" (code: PE015) means that somehow the RPC server on either the host machine or the domain controller could not be accessed.

If these errors seem to appear sporadically there's something gone awry in your network/DCOM for a couple of minutes which PRTG dutifully reports as "sensor down".

PRTG tries to rebuild a faulty connection immediately, then again after 10 minutes, then after 20 etc.

If these errors vanish after a "Check now" you might prolongate the latency settings for those sensors, so you won't get notified too quickly.

Note: WMI being dependent on DCOM communication and Microsoft's update patches means an awfully complex breeding ground for all sorts of errors. We here at Paessler's are constantly working on improving PRTG in order to discover, identify, avoid, circumnavigate, and be as tolerant as possible about these errors (without compromising the main mission of PRTG, of course).

Created on Jan 25, 2010 9:56:39 PM by  Dirk Paessler [Founder Paessler AG] (10,859) 3 4

Last change on Apr 27, 2010 11:11:20 AM by  Daniel Zobel [Paessler Support]



Votes:

2

Your Vote:

Up

Down

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).

Created on Apr 5, 2010 8:15:44 PM by  Nick Russo (80) 1 1



Votes:

2

Your Vote:

Up

Down

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.

Created on May 6, 2010 6:25:01 PM by  Robert Neill (100) 1 1



Votes:

2

Your Vote:

Up

Down

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

Created on May 6, 2010 6:29:06 PM by  Robert Neill (100) 1 1

Last change on Jun 4, 2010 12:48:17 PM by  Daniel Zobel [Paessler Support]



Votes:

1

Your Vote:

Up

Down

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).

Created on Jun 4, 2010 12:58:52 PM by  Daniel Zobel [Paessler Support]



Votes:

1

Your Vote:

Up

Down

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.

Created on Jun 14, 2010 5:10:30 PM by  Jim Kirby (181) 2 1

Last change on Aug 23, 2013 11:32:29 AM by  Konstantin Wolff [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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.

Created on Jul 15, 2010 1:20:42 PM by  Thomas Blühmann (0) 1

Last change on Jul 15, 2010 2:58:10 PM by  Daniel Zobel [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Created on Aug 8, 2010 6:17:03 PM by  John Homer (0) 2

Last change on Dec 8, 2010 9:43:51 AM by  Daniel Zobel [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Created on Oct 7, 2010 5:33:37 AM by  David Kindermann (0) 1



Votes:

0

Your Vote:

Up

Down

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.

Created on Nov 23, 2010 12:24:55 PM by  Bruno Ruy (2) 2



Votes:

0

Your Vote:

Up

Down

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

Created on Dec 16, 2010 1:17:56 PM by  Enrico Keil (0)

Last change on Dec 16, 2010 3:41:05 PM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

We have a Server with wmi and other sensors. Suddenly all WMI Sensors had following error: Connection could not be established (Can not initiate WMI connections to host xy. Please reboot target device. )

reboot server xy did not help.

Solution: restart the Service PRTGProbeService on the Probe Server. Other hosts on this Probe Server were not affected.

Created on Oct 16, 2014 8:48:56 AM by  64Bit (0)



Votes:

0

Your Vote:

Up

Down

Hi All, tried everything from the above tips but still having the same issue. Any other ideas please? Thanks

Created on Jan 15, 2015 9:29:51 AM by  geordie (0)



Votes:

0

Your Vote:

Up

Down

If nothing helps, even restarting the target and repairing the WMI on it did not help, please consider installing a Remote Probe directly on the target. This will enable local WMI Access which usually does not face this error.

Created on Jan 15, 2015 3:53:57 PM by  Torsten Lindner [Paessler Support]



Votes:

5

Your Vote:

Up

Down

Easy way to check WMI on the target machine for errors.

cmd prompt from your Windows machine.

type: wmic

wmic:root\cli>/node:<IP-Address or machine name> computersystem list brief /format:list

Created on Dec 29, 2015 7:52:03 AM by  Sander van den Brom (50)



Votes:

0

Your Vote:

Up

Down

Hey everyone,

I gave done as Sander suggested : Easy way to check WMI on the target machine for errors. cmd prompt from your Windows machine. type: wmic wmic:root\cli>/node:<IP-Address or machine name> computersystem list brief /format:list

running this code from the machine on the network that has the probe installed returns what seems to be the correct info. So it looks like the probe can access the WMI on the target machine but the sensor still says : Connection could not be established (Can not initiate WMI connections to host exchange01.client-domain.local. Please reboot target device exchange01.matthews-goodman.local to recover from this situation.) (code: PE015)

anybody have nay idea's on what could be causing this ?

Created on Jul 20, 2016 6:42:41 AM by  tyron (0)



Votes:

0

Your Vote:

Up

Down

Please use our WMI Tester, run it on the PRTG Host (or host of the Remote Probe) and scan against this particular target, usually the "OS-Query" from the "Advanced" Tab of the Tool works best, please send us the Results. Please also see our extensive WMI Troubleshooting Guide.

Created on Jul 20, 2016 9:30:34 AM by  Torsten Lindner [Paessler Support]



Votes:

1

Your Vote:

Up

Down

Hi, I had a PE015 error on just two WMI based sensors on a single device. Other WMI sensors on the same device were working correctly. The two with the error were Memory and Disk Space. I went as far as creating new sensors of the same type on the same device but the new ones likewise reported the same PE015 errors. Still lots of other sensors on the same device, all using WMI all worked correctly.

Doing the reverse of what some of the others here suggested, I changed my windows credentials on this device. They had been defined at the group level. I changed this and defined the windows credentials at the device level and that allowed the sensors to check without error. Same account, same password, and it's once again working correctly.

I did try re-setting the Windows credentials to be re-inherited from the group level and the same two sensors fell immediately back into error mode PE015. What's curious is that there are dozens of other devices in that group, all using the exact same windows credentials inherited from the group level all working without any problem whatsoever.

Hope this is helpful to others.

Kind Regards, Adam

Created on Nov 19, 2016 10:16:18 AM by  amikolajczyk (110) 1



Votes:

0

Your Vote:

Up

Down

Two possible fixes that worked for me:

1. Rebooting the physical PRTG server. 2. I also was low on disk space (5gb free) so I expanded the VHD to make more room.

I am unsure which of these two fixed the problem. I'm leaning towards the reboot, but since I also was in fact low on disk space I wanted to go ahead and mention it.

Created on Apr 17, 2017 11:13:25 AM by  dreniarb (10) 1



Votes:

6

Your Vote:

Up

Down

I've had the same connection failures, our server is an Amazon AWS. This article - http://mooneyblog.mmdbsolutions.com/index.php/2013/11/01/accessing-an-amazon-vm-through-wmi/comment-page-1/#comment-98965 fixed it for me. Note the firewall ranges 1024-65535 are TCP and not UDP as some are saying. Make sure you change both the Amazon Security group settings & Windows firewalls.

Created on Jun 14, 2017 1:14:04 PM by  davederrick (60) 1



Votes:

0

Your Vote:

Up

Down

Thanks for sharing this, Dave!

Kind regards,

Erhard

Created on Jun 16, 2017 10:14:43 AM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Wanted to share my 'fix'. All of my devices are monitored via FQDN. I had one that was not working. Did the opposite of some of the above suggestions and changed FQDN to the IP address, and it fixed that one. I would prefer it to run via FQDN as the ips are dynamic. Anyway there you go.

Created on Nov 4, 2017 5:22:13 PM by  DarrenE (30) 1



Votes:

0

Your Vote:

Up

Down

Rebooting the prtg server fixed my problem.

Created on Mar 24, 2018 10:00:41 AM by  Many (0)



Votes:

0

Your Vote:

Up

Down

Wanted to add to this. The ip/fqdn switch occasionally worked for me, but not every time. If it gets bad enough I had started rebooting the prtg server itself, which would resolve it. I've now narrowed it down to just restarting the 'PRTG Probe Service' resolves it as well. I guess its not as jarring as a full reboot, and you can do it pretty quickly with usually no ill effects, or notifications.

thanks

Created on Aug 19, 2018 1:47:18 PM by  DarrenE (30) 1



Votes:

0

Your Vote:

Up

Down

We here at Paessler's are constantly working on improving PRTG in order to discover, identify, avoid, circumnavigate, and be as tolerant as possible about these errors (without compromising the main mission of PRTG, of course).

WSMAN/CIM are much less error prone than DCOM/WMI

Created on Oct 15, 2018 5:03:43 PM by  NonSecwitter (0) 1



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.