Exchange 2013: Shell does not start, no connection possible

Here is another interesting Exchange 2013 problem that occurred after someone had "cleaned up".

Error situation

Outlook no longer connects, access to Exchange Shell and Exchange Administrative Center was also no longer possible. The error occurred after the Exchange Server had a completely incorrect date due to a faulty configuration. Even after the problem was fixed, Outlook would not connect to Exchange 2013, nor was access to the administration interfaces (shell and EAC) possible. The shell only returned this message:

EXECUTIVE: Connection to exchange.domain.local is established.
New-PSSession : [exchange.doamin.local] When connecting to the remote server "exchange.domain.local
the following error has occurred: [ClientAccessServer=EXCHANGE,BackEndServer=exchange.domain.local
d=c8d68f03-32d5-4c5a-affc-d9fd8fd4b413,TimeStamp=25.05.2016 18:44:58] Further information can be found in the H
"about_Remote_Troubleshooting".
In line:1 Character:1
+ New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession],
gTransportException
+ FullyQualifiedErrorId : -2144108477,PSSessionOpenFailed

However, it was not immediately recognized that it was only a time problem in the first step, so a lot was tried, optimized and tidied up... A little too much, perhaps...

Unfortunately, it is not always easy to read the relevant information from the error message, so here are the keywords that can give you a rough idea of what is causing the error:

• BackEndServer
• exchange.domain.local
• PSSessionOpenFailed

This could be interpreted to mean that opening a PowerShell session (PSSessionOpenFailed) to the Exchange Server (exchange.domain.local) did not work. Sounds logical, because the shell does not start... However, it is important at this point to point out where the error lies: BackEndServer.

Exchange 2013 is divided into two roles: FrontEnd (Client Access role) and BackEnd (Mailbox role), so it is obvious that this is a problem with the Mailbox role. Both roles each have their own website in IIS, nowadays almost only MultiRole servers are operated (FrontEnd and BackEnd on the same server), so both websites are also located on the same server:

The backend has a descriptive name, the front end (Default Web Site) unfortunately does not. With the knowledge from the error message and the background knowledge that the Exchange Shell wants to establish a connection to the Exchange Server via IIS (PowerShell vDir), the error can at least be narrowed down.

In some cases it is necessary to recreate the vDirs, for example if authorizations or similar have been lost.

In this case it was easier, only the certificate was missing in the IIS website binding:

The certificate with the name "Microsoft Exchange" is normally assigned here. If, as can be seen above, only "Not selected" is displayed, the certificate can be added again. This problem often occurs when someone carelessly "cleans up the certificates". If necessary, a new self-signed certificate can also be created via IIS Manager and assigned accordingly if the original certificate is no longer available.

The certificate can then be selected again in the website bindings. After an IIS restart (iisreset), access to Exchange also worked again in this case.

This also applies to Exchange 2016 Server.