When trying to open EMS on all CAS Servers, an error is received -

"The WinRM Shell client cannot process the request. The shell handle passed to the WSMan Shell function is not valid. The shell handle is valid only when WSManCreateShell function completes successfully. Change the request including a valid shell handle and try again."

Most people have solved this by going into the bindings of the Exchange Back End site in IIS and assigning a certificate. There is already a certificate assigned, so that is not the problem. We are using a wildcard certificate, but I don't think that is the problem because I have reassigned the default self signed cert as well as creating a new certificate with the FQDN of the server as the CN and it produces the same results.

I am able to "fix" the error by changing the path of "PowerShell" under the Default Web Site in IIS from "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\PowerShell" to "C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\PowerShell", but that is not a good solution as I am sure it can cause other problems.

We are running Exchange 2013 CU5. We have four CAS servers spanning two sites (two in each site) and they are all running Server 2008 R2 Standard. All four CAS servers are having the problem. This is an environment I inherited, so I can't say when the error started happening (after initial installation, applying an update, etc.).

Any help is greatly appreciated!

Hi,

From your description, I recommend you do IISReset after adding the certificate back to the Exchange Back End Website and binding it to the Exchange Back End Website. And then reopen Exchange Management Shell to check the result.

Besides, you have multiple CAS/Mailbox servers, you need to do the above setting on all the servers.

Hope this can be helpful to you.

Best regards,

If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

Yes, we have already done that. Thanks for the response though.

Others seems to be happy for the solution you found, replace the PowersHell path.

My (RTM version) E2013 the path is:
"C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\PowerShell-Proxy"

On the folder level I have all of these folders:
C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\PowerShell
C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\PowerShell-Proxy
C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\powershell

As soon as I get the CU7 updated I can tell what folders I have after that :)

Hi,

I would suggest we check the following:

1. On the Exchange back End site->Bindings..., besides checking the certificate on port 444, also make sure the this port is not assigned to an specific IP address. We should set it to "All Unassigned". Then run IISRESET and check again.

2. Check if there is entry missing in Default Web Site->Bindings... for example, we should have:

http 127.0.0.1  port 80

https  127.0.0.1 port 443

Also remember to check the certificate. Heres a screenshot for the default web site bindings in my lab for your reference:

3. If this still doesn't resolve the issue, we may consider upgrading the server to CU7 to see if it works.

Thanks.

Hi, is there any update on this issue?

Thanks for the feedback and sorry for the delay. All of the settings in question appear correct. On the backend, it is set to All Unassigned, and on the default website, I have the entries for 127.0.0.1. We have been planning on upgrading to CU7, but haven't had the time to do so. I will try to get that scheduled. Still open to any other suggestions in the mean time!

Same issue after applying CU7.