In my current project I have an AD MA which is configured to provision for Exchange 2010. My customer has multiple Hub/CAS servers load balanced by a hardware solution. At first I provided a specific server in the Exchange 2010 RPS URI in the AD MA. Once the Exchange guys implemented the changes to Kerberos-enable the CAS array, I switched over to a virtual name. In our lab environment this worked just fine, however in the acceptance environment I kept receiving “ma-extension-error”:

This blocked all exports on the AD MA. In the  application event log the following error is show:

In text:

The most obvious thing to do at this time is to start googling. A very promising link is the Troubleshooting the Exchange Management Shell The above error could be caused by Release Candidate version PowerShell binaries. Well that’s definitely not the case. Using the following PowerShell commands I was able to reproduce the issue from the Synchronization Server:

• $user = Get-Credential
• $session = New-PSSession -configurationname microsoft.exchange -connectionuri http://virtualurl.demo.com/powershell -credential $user
• Enter-PSSession $session

Which gave me the following output:

Enter-PSSession : Starting a command on remote server failed with the following error message : The Windows Remote Shell cannot process the request; the selector value 962F626B-6492-493B-BF42-772C7C6BAFBD specified in the request was not found. For more information, see the about_Remote_Troubleshooting Help topic.

At line:1 char:16

+ Enter-PSSession <<<< $session
+ CategoryInfo : ResourceUnavailable: (:) [Enter-PSSession], PSRemotingTransportException
+ FullyQualifiedErrorId : System.Management.Automation.Remoting.PSRemotingDataStructureException,
Microsoft.PowerShell.Commands.EnterPSSessionCommand

So using netsh I started tracing and soon I saw the light, whereas we asked the networking guys to implement IP Affinity for the load balanced name, they seemed to have forgotten to actually do this… Hence the PowerShell session is being created with one server in the farm, whilst the actual command is probably being sent to another server… Not good!

Conclusion: Whenever you configure a load balancing solution for the Exchange 2010 CAS role, make sure you configure your solution to redirect sessions from the same IP to the same CAS node in the farm. This definitely seems to be a requirement for remote PowerShelling.