I haven't posted much in terms of Exchange 2010 articles in a while as usually there is already good guidance on the interwebs about how to fix niche problems. I try not to post the same stuff that you would find elsewhere and there are more and more great resources available from MSFT and other sources (including a few that I have worked on).
One issue that is continually problematic is PowerShell remoting. I have run into a lot of powershell remoting issues and have found that there are a lot of other people who have as well. There is a ton of guidance about how to troubleshoot PowerShell remoting problems:
These are definitely the place to start for troubleshooting the problems. Of course if you aren't familiar with powershell or how remoting works for Exchange 2010, Mike Pfeiffer's post Managing Exchange 2010 with Remote PowerShell is pretty good.
What I found is that despite the Exchange team putting out such great guidance, there is still a lot of room for issues when it comes to Exchange PowerShell remoting issues. One that I ran into that seems may exist for other people is one where I continually was receiving the following error:
[mbx-htcas-02.mssolutionstest.com] Connecting to remote server failed with the
following error message : The WinRM client cannot process the request. It canno
t 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_Re
mote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:Re
moteRunspace) , PSRemotingTransportException
+ FullyQualifiedErrorId : PSSessionOpenFailed
This was really annoying as I couldn't run any cmdlets locally and the Exchange Management Console failed to connect to the local server as well. Luckily there were other servers in the environment so I had the opportunity to still run commands and make configuration changes.
The problem of course is that some commands need to be run against the server in question and if no server can connect via remoting, no command can be run directly against the server. There are two things that are important to dealing with this issue. The first is getting around remoting. To do that simply open the built in windows powershell console, and run:
This will add the Exchange Management PowerShell cmdlets to the local instance and allow you to run cmdlets locally - bypassing the remoting capabilities.
The second component is of course troubleshooting the problem at hand. The links above will help you in your troubleshooting efforts. My case specifically had a hard coded path in the web.config file that was getting in the way as the path was invalid. Once the path was removed, remoting worked again with no problem. Luckily though I was able to get around having to fix this problem before I finished working on the server because I was able to get around the use of remoting.