A Connection To The Server Could Not Be Established Remote Play

A Connection To The Server Could Not Be Established Remote Player
A Connection To The Server Could Not Be Established Remote Play On Xbox One

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?

Head over to the Start menu and search for Defender. Generally an issue connecting online which may be due to temporary congestion with your Internet service or with the Internet connection. How to Fix PS4 Error, A Connection to the Server Could not Be Established. Feb 01, 2021 But in production environments, you can allow remote access to the MySQL server. In this aspect, you will have to configure the MySQL server to listen on a specific IP address or all IP addresses on the server. This article shows the steps to resolve connection issues to MySQL Server.

25 Replies

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

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

A connection to the server could not be established remote play on windows 10

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. Apple download software. 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: HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciessystem

Key: LocalAccountTokenFilterPolicy

Value: 1 (DWORD)

Offers on macbook. 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.

A Connection To The Server Could Not Be Established Remote Play

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

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.

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.

Some PS4 users have reported to us that they need help in fixing Remote Play feature on their console that won’t connect to their PC. In case you did not know, you can actually play your favorite PS4 game on either a smartphone or computer even when you’re not in front of your console. All you have to do is to set up Remote Play on your phone or computer.

If you encounter connection issues or Remote Play errors during setup, or after using it for some time, this article should help.

Things you need for PS4 Remote Play

If you plan on playing away from your PS4, you can make use of its Remote Play feature. Below are the things that you should have to successfully do that:

Updated PS4 console.
Internet connected computer.
Good working PS4 DUALSHOCK wireless controller
USB cable to connect the controller to your computer. Or, a compatible wireless adapter to allow PS4 wireless connection.
PlayStation Network account.
At least 15Mbps download and upload internet connection speeds (for both the PC and PS4)

Causes why your PS4 Remote Play won’t connect

There are several possible reasons why PS4 Remote Play stops or won’t connect. Mostly, the issue is network setup related so it’s important that you make sure to check the status of your own local network ahead of time.

At other times, PS4 Remote Play may encounter connection issues or errors due to problems with the PlayStation Network itself.

For first time users, some may find out that they are unable to use PS4 Remote Play due to their computer’s security software.

Below are some of the common causes for PS4 Remote Play issues.

Internet connection is slow or intermittent.

In order to avoid having latency or lag when using Remote Play, you want to make sure that you have a fast broadband connection. Sony recommends that your PS4 has a minimum of 15Mbps. Anything slower than that can be problematic although I’ve personally been able to use Remote Play normally even though my PS4 speed test result shows that it’s only getting less than 6Mbps of upload speed.

For best results though, try to only use Remote Play when you have a fast enough connection.

PS4 software is outdated.

Most PS4 games and features that uses online functionality usually won’t work when the console’s software is outdated. Make sure that you manually check for software updates if you encounter Remote Play errors. Mac laptop purchase.

NAT type is strict or restrictive.

Some users may encounter “A connection to the server could not be established” error due to NAT type issues on the PS4. You should strive to have NAT Type 1(open) on your console although NAT Type 2 (moderate) is also okay. If your PS4 has NAT type 3 (strict), you will not be able to play with others online, talk via voice chat, or run Remote Play on your computer.

Random console or computer OS bug.

Sometimes, electronic devices may develop flukes. Temporary bugs are usually fixed by simply rebooting the device so make sure to restart your PC and PS4.

Local network issue.

Issues with your local networking devices can cause Remote Play to cut off or not load. Make sure that your home network is fast enough and does not disconnect frequently. Intermittent connection issues can cause connection time outs, which can make Remote Play virtually unplayable.

Security software blocking the connection.

If you’re getting a 88010E0F error when setting up Remote Play for the first time, it’s more likely an antivirus or firewall issue. You can try to disable your antivirus or firewall temporarily to check if that’s the case.

Make sure to turn your security software back on after testing.

PlayStation Network is down.