Monday, May 31, 2010

On a multihomed CAS server you receive error “Connecting to remote server failed with the following error message: The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid. For more information, see the about_Remote_Troubleshooting Help topic.” after statically binding an IP address to the web site containing the PowerShell virtual directory.

Had an issue today at a clients site where they needed another OWA virtual directory for their SharePoint portal. So I created a new Web Site, added an additional IP address to the existing NIC. I then went into the bindings of the Default Web Site and set it to one of the addresses and then set the other site to the other address. Seems simple enough.

I then opened up the EMS and got this error

“Connecting to remote server failed with the following error message: The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid. For more information, see the about_Remote_Troubleshooting Help topic.”

 

After making sure time was all good between the CAS and the DC I figured out that setting the web site that contained the PowerShell virtual directory to use All Unassigned as it’s binding resolved the issue.

Routing messages between two Exchange 2007/2010 fails with “451 5.7.3 Cannot achieve Exchange Server authentication." Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts”

Here is something that came up at a client site today

EXC01 (2k7 CAS/HT) has an Internal Relay receive connector with allowed relay from x.x.x.0/24 – among others

EXC02 (2k10 CAS/HT) is getting errors when trying to route mail to the 2k7 server “451 4.4.0 Primary target IP address responded with: "451 5.7.3 Cannot achieve Exchange Server authentication." Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts”

What needs to be done is to take the new HT out of the relay list.

Why?

Well the way that I set up my relay connectors

AuthMechanism : Tls, ExternalAuthoritative

PermissionGroups : ExchangeServers

So the problem is the ExchangeServers Permission group that screws it all up. The relay connector see new HT as an Exchange server and so it used the relay connected not the default connector. This starts TLS but when the new HT initiates Integrated authenticated it fails because the relay connector does not have that as an Auth method.