• Teamviewer Connection Not Ready
• Teamviewer Mac Connection Could Not Established To Control
• Teamviewer Cannot Establish Connection

Oct 21, 2018  Re: A connection could not be established. Teamviewer not running on partner computer. I have the exact same problem. When he is 50 miles away in the Atlanta metro area, I can connect to him. When he travels to Michigan I cannot connect to him but he can connect to me. We use the same computers with the same OS. Dec 19, 2009  A connection to the requested partner could not be established. Please check TeamViewer and the Internet connection to your partner's computer.' First I phoned my neighbor and asked her to shut down and restart my computer.

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?

Votes:

2

Your Vote:

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

Teamviewer Connection Not Ready

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

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.

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.

Teamviewer Mac Connection Could Not Established To Control

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: HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciessystem

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 devicec$' 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

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.

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

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.

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

cmd prompt from your Windows machine.

type: wmic

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

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: wmicwmic:rootcli>/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 ?

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.

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

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.

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-98965fixed 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.

Thanks for sharing this, Dave!

Kind regards,

Erhard

Teamviewer Cannot Establish Connection

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.

Rebooting the prtg server fixed my problem.

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

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

Please log in or register to enter your reply.