I’ve had two annoying PowerShell errors today, both for the same server:
Enter-PSSession : Connecting to remote server server-a.rcmtech.co.uk 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:
Enable-PSRemoting
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 0.0.0.0 like this:
TCP 0.0.0.0:5985 0.0.0.0:0 LISTENING 4
However on my problem server it was listening on 127.0.0.1. This can be confirmed using:
netsh http show iplisten
and you’ll only see 127.0.0.1 in the list.
On the problem server itself you’ll find that using:
Enter-PSSession -Computername localhost
works, whereas:
Enter-PSSession -Computername server-a.rcmtech.co.uk
does not.
localhost is the name for the loopback address 127.0.0.1 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 127.0.0.1.
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 server-a.rcmtech.co.uk 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.
Update
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.
Holy crap! Thank you. I was sick of hearing “turn it on”. The IPv6 issue was my issue.
LikeLike
OMG I have been working on WINRM and Exchange for 2 days and this worked Thank You so much
LikeLike
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
LikeLike
Thanks!!! Worked!
LikeLike
Thank you!
LikeLike
You are awesome! I’ve spent way too long trying to figure this out and this finally did it.
LikeLike
Would not have guessed IP6 was hanging me up on this. That update note got my issue resolved! Thanks!
LikeLike
we had the same issue, after opening a ticket with microsoft we solved the issue by disabling IPV6.
LikeLike
Thanks for this – * in ipv6 GPO solved this frustrating issue for us.
LikeLike
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
LikeLike
Thank You! Resolved my issue with cluster validation on storage disks due to WinRM issue.
LikeLike