Fix PowerShell WinRM remote connection errors

I’ve had two annoying PowerShell errors today, both for the same server:

Enter-PSSession : Connecting to remote server failed with the
following error message : The client cannot connect to the destination specified in
the request. Verify that the service on the destination is running and is accepting
requests. Consult the logs and documentation for the WS-Management service running
on the destination, most commonly IIS or WinRM. If the destination is the WinRM
service, run the following command on the destination to analyze and configure the
WinRM service: "winrm quickconfig". For more information, see the
about_Remote_Troubleshooting Help topic.

The standard “internet” response to this is to open an Administrator command prompt and run

winrm qc

(or winrm quickconfig). Or open an Administrator PowerShell prompt and run:


But these are quite annoying solutions if you know that it should be working, and indeed is working on all your other servers, because you’ve configured it via Group Policy! There’s no harm in running the commands anyway, but most likely they’ll just come back and say “already configured” or words to that effect.

So the fix (for me) for the above error was to check what IP addresses the listener was listening on using:

netstat -aon | find "5985"

where 5985 is the default port used by WinRM. You should see the system process (ID 4) listening on like this:


However on my problem server it was listening on This can be confirmed using:

netsh http show iplisten

and you’ll only see in the list.
On the problem server itself you’ll find that using:

Enter-PSSession -Computername localhost

works, whereas:

Enter-PSSession -Computername

does not.
localhost is the name for the loopback address whereas the fully qualified server name will give you the IP address of the server as seen from your network.
The fix for this is to delete the loopback address from the http listener, which then makes it listen on all valid addresses:

netsh http delete iplisten

Check what addresses it is now listening on (plus the port) by using:

winrm e winrm/config/listener

Problem solved. Or not, I then got this error:

Enter-PSSession : Connecting to remote server failed with
the following error message : The WinRM client sent a request to an HTTP server and 
got a response saying the requested HTTP URL was not available. This is usually
returned by a HTTP server that does not support the WS-Management protocol. For
more information, see the about_Remote_Troubleshooting Help topic.

Which it turns out can be caused by having IPv6 enabled on the server.
In the netstat output (see above) I also had some IPv6 addresses showing as listening on port 5985.
I don’t use IPv6 but it’s on by default in Windows and will auto-assign itself a link local address (starts with fe80:). So I disabled IPv6 and the error went away. There’s also a workaround using the hosts file if you don’t want to disable IPv6.


This might also be caused because you have the following group policy configured:

Computer Configuration\Policies\Administrative Templates\Windows Components\Windows Remote Management\WinRM Service\Allow remote server management through WinRM

And in the settings for that policy, you only have a * in the box for IPv4, and nothing in the box for IPv6. Add a * in the IPv6 box too.

This entry was posted in PowerShell, Windows and tagged , , , , , , , , , , , . Bookmark the permalink.

10 Responses to Fix PowerShell WinRM remote connection errors

  1. Scott says:

    Holy crap! Thank you. I was sick of hearing “turn it on”. The IPv6 issue was my issue.


  2. joshua says:

    OMG I have been working on WINRM and Exchange for 2 days and this worked Thank You so much


  3. Stephen says:

    Strange how a terrible issue that has been going on for Years Since 2012, and all any one ever said was “Disable ipv6” so you can Deploy this, user server manager. All along it was just allowing the IP’s in a GPO.
    UFB and Thank you


  4. Thanks!!! Worked!


  5. kmorris78 says:

    You are awesome! I’ve spent way too long trying to figure this out and this finally did it.


  6. MattC says:

    Would not have guessed IP6 was hanging me up on this. That update note got my issue resolved! Thanks!


  7. Os Naem says:

    we had the same issue, after opening a ticket with microsoft we solved the issue by disabling IPV6.


  8. Jon T says:

    Thanks for this – * in ipv6 GPO solved this frustrating issue for us.


  9. Karen Jones says:

    Thank you! Another victim of the missing IPv6 wildcard.
    You might want to add the PowerShell equivalent to ‘ netstat -aon | find “5985” ‘ is: Get-NetTCPConnection -LocalPort 5985


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.