Hier mal wieder ein interessantes Exchange 2013 Problem, welches aufgetreten ist, nachdem jemand „aufgeräumt“ hatte.
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] Beim Verbinden mit dem Remoteserver „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
Es wurde allerdings nicht direkt erkannt, das es sich im ersten Step nur um ein Zeitproblem handelte, also wurde viel probiert, optimiert und aufgeräumt… Etwas Zuviel, vielleicht…
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:
Normalerweise ist hier das Zertifikat mit dem Namen „Microsoft Exchange“ zugewiesen. Sollte wie oben zu sehen nur „Nicht ausgewählt“ angezeigt werden, kann das Zertifikat wieder hinzugefügt werden. Häufig tritt dieses Problem auf, wenn jemand unbedacht die „Zertifikate bereinigt“. Via IIS Manager kann zur Not auch ein neues Self Signed Zertifikat erstellt werden, und dieses entsprechend zugeordnet werden, sollte das Original Zertifikat nicht mehr vorhanden sein.
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.