0

A pretty much default Exchange 2013 on-premises installation, with two CAS and two MBX servers, all of them running Windows Server 2012R2, Exchange updated to CU13. Using the default Exchange Management Shell, it always reports WSMan error when connecting to the server it's launched on, then it selects a sibling server and successfully establishes the connection. The error is as follows:

New-PSSession : [cas01.xxxxxxxxx] Connecting to remote server cas01.xxxxxxxxx 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.

The most weird thing is that if I run EMS on cas01, it tried to connect to cas01, fails, then tries connecting to cas02 and succeeds. If I run it from cas02, I get the reverse. There is a NLB IP address that both servers share, however that IP address does not resolve to either cas01 or cas02 names. Test-WSMan cmdlet returns WSMan up and running. What else should I test to find out the source of this behavior?

Vesper
  • 794
  • 1
  • 9
  • 32
  • How many IPs did the server have you are running the management shell? Did they have some hostfile entries set? – BastianW Mar 07 '17 at 11:22
  • @BastianW Three, one is NLB CAS, one is NLB autodiscovery and one is unique. No hosts entries. – Vesper Mar 07 '17 at 11:24
  • ok, and inside the NIC Adapter and Bindings the network order is correct? means the expected nic is on the TOP (e.g. more infos [here](http://www.admin-enclave.com/en/articles/exchange/206-migrate-from-exchange-2010-to-exchange-2016.html))? – BastianW Mar 07 '17 at 11:28
  • One network adapter. Shouldn't be an issue. IPv6 is also disabled. – Vesper Mar 07 '17 at 11:30
  • I see, that was maybe to easy ;-). If you do a a nslookup for cas01.xxxxxxxxx on cas01.xxxxxxxxx and another nslookup for cas01.xxxxxxxxx on cas02.xxxxxxxxx did you got a different result? I think that you will get the wrong IP here which isn´t the "host IP". Maybe you get the NLB IP here. – BastianW Mar 07 '17 at 11:40
  • They use the same DNS server, and nslookup was tested with correct results. Well, I have managed to find the *partial* root cause of this behavior - IPv6! It was disabled on interfaces, but not everywhere with registry. I went with editing IP address prefix policies like here https://technet.microsoft.com/library/bb877985.aspx with `netsh int ipv6 set prefixpolicy ::ffff:0:0/96 60 4` since default preference value for ::1 was 50, now pings properly. – Vesper Mar 07 '17 at 12:03
  • Got however another pair of CASes that have separate (personal) addresses for autodiscovery and mail, this made ping respond on wrong IPv4 address (10.x.x.12 is bound on default web site, 10.x.x.14 for redirect site, since autodiscovery site is used by many names like `autodiscover.company.com`, and ping localhost by name resulted in pinging .14 address). Bindings were checked and .12 address NIC is listed first. – Vesper Mar 07 '17 at 12:07

1 Answers1

0

The resolution of this particular issue is that if you disable IPv6 on all interfaces, but do not disable IPv6 on the system, it still registers the ::1 IPv6 address for localhost. This one is the address used to connect to IIS server in order to establish a remote Powershell session. The IIS server, however, does not listen on IPv6 addresses in case there are only IPv4 addresses available. In my case the IPv6 binding was altogether absent. So, the issue can be resolved in two ways:

First, disable IPv6 on the system, then ensure IIS default web site is bound to 127.0.0.1:80 OR local_IP:80.

Second, change IPv6 prefix priority as explained here https://technet.microsoft.com/library/bb877985.aspx : netsh int ipv6 set prefixpolicy ::ffff:0:0/96 60 4. This command changes the IPv4 prefix priority to 60 (an arbitrary value should be higher than what's reported with netsh int ipv6 show prefixpolicies for ::1/128 prefix). This makes anything trying to connect to localhost to use IPv4 address of your localhost (not even 127.0.0.1!).

Vesper
  • 794
  • 1
  • 9
  • 32