The problem with the bleeding edge is that there’s not a huge amount of supporting knowledge that goes with it as not many people have experienced all of the corner cases that Google/Bing so helpfully index for us when we have a problem. Here’s one that hit me today.
After completing a migration to Exchange 2013, I wanted to install Remote Desktop Gateway and Remote Desktop Web roles onto the same server as Exchange 2013 was running on since this is only a small environment and it didn’t make sense to provision separate servers for what will only be used by a handful of people. After doing this, I couldn’t open the Exchange 2013 PowerShell console due to multiple occurrences of the following error:
VERBOSE: Connecting to CT-EXCH-01.corp.collective-tech.com.
New-PSSession : [ct-exch-01.corp.collective-tech.com] Connecting to remote server ct-exch-01.corp.collective-tech.com
failed with the following error message : The client cannot connect to the destination specified in the request.
Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation
for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM
service, run the following command on the destination to analyze and configure the WinRM service: “winrm quickconfig”.
For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ New-PSSession -ConnectionURI “$connectionUri” -ConfigurationName Microsoft.Excha …
+ CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
+ FullyQualifiedErrorId : CannotConnect,PSSessionOpenFailed
In addition, authentication on multiple virtual directories had been reset and the various services such as OWA were flaky at best.
Removing and recreating the PowerShell directory as per some suggestions didn’t help.
Exchange 2013 uses two web sites in IIS; one for production and one for back-end. The former uses the normal ports (80/443) and the latter normally uses incremented port numbers (81/444). For some reason, an additional binding on the back-end site had been added for port 443. This was causing all HTTPS traffic for the front-end to end up on the back-end site. To fix:
- Open up IIS Manager
- Navigate to the site “Exchange Back End”
- Click “Bindings…” under “Actions” on the right-hand pane
- Click the item with the values https/443 (not 444!)
- Click “Remove” and then “Close”
- Restart IIS
- Make sure that both sites are started
From this point you should be able to connect to the Exchange Shell as normal and reset the authentication settings on the various virtual directories as required.