Exchange 2010 zu Exchange Online – Verbindung kann nicht hergestellt werden
Viele Unternehmen verschieben momentan Ihre On-Premises Exchange 2010 Organisation in Richtung Microsoft Exchange Online. Im Normalfall wählt man den Weg der Hybriden Bereitstellung. Das bedeutet, dass sowohl der On-Premises Exchange, als auch EOL zeitgleich über mehrere Monate hinweg existieren. In meinem Fall besteht die Konnektivität zwischen den zwei Umgebungen bereits mehrere Jahre. Nun wollte ich weitere Mailboxen in Richtung Cloud verschieben, habe aber folgende Fehlermeldung erhalten: „Die Verbindung mit Server mail.contoso.com konnte nicht hergestellt werden.“
Es gibt natürlich mehrere Gründe, warum keine Verbindung hergestellt werden kann. Daher möchte ich auch kurz auf ein allgemeines Troubleshooting eingehen:
- Für die Migrationsbatches ist lokal der MRS Proxy Endpunkt verantwortlich. Dahinter befindet sich der Mailbox Replication Service. Um die grundlegende Funktionalität und Erreichbarkeit zu prüfen, könnt ihr folgende URL aufrufen: „https://mail.contoso.com/EWS/mrsproxy.svc“. Ersetzt dabei das mail.contoso.com mit eurer Exchange URL. Sollte eine Passwortabfrage erscheinen, ist der Service soweit erreichbar. Versucht das auch außerhalb eures Netzwerkes, um die Firewall oder etwaige Loadbalancer auszuschließen.
- Verbindet euch mit der Powershell zum Exchange Online und führt einen Connectivity Test durch:
### Erstellt ein PSCredential Object und befüllt es mit den Anmeldedaten zum Exchange Online ECP $UserCredential = Get-Credential ### Erstellt ein Session-Object mit den zuvor eingegeben Anmeldedaten $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection ### Importiert die zuvor erstelle Session Import-PSSession $Session -DisableNameChecking
Habt ihr die oben genannten Befehle ausgeführt, seid ihr bereits mit dem Exchange Online verbunden. Von hier aus könnt ihr alle administrativen Tätigkeiten durchführen, wie man es auch von der lokalen Management Shell gewohnt ist. Wir möchten explizit die Verbindung zwischen den Exchanges prüfen:
### Erstellt erneut ein PSCredential Object, diesmal mit den Anmeldedaten des lokalen Exchange Administrators $localUserCredential = Get-Credential ### Testet die Verbindung zwischen EOL und dem On-Premise Exchange Test-MigrationServerAvailability -ExchangeRemoteMove -RemoteServer mail.contoso.com -Credentials $localUserCredential
Natürlich müsst ihr bei dem zweiten CMDLET den Remoteserver durch euren eigenen ersetzen. Je nachdem welchen Output ihr erhaltet, müssen weitere Maßnahmen gesetzt werden. In diesem Post wird nur die Fehlermeldung der SSL/TLS Verschlüsselung behandelt. Falls bei euch ein anderer Error erscheint, sollte Google oder dieser Microsoft Blogpost weiterhelfen können.
Could not create SSL/TLS secure channel
In meinem Fall bekam ich folgende Fehlermeldung zurück geliefert: „Could not establish secure channel for SSL/TLS with authority ‚mail.contoso.com. –> The request was aborted: Could not create SSL/TLS secure channel.. —>“. In erster Linie würde man bei dieser Ausgabe ein fehlerhaftes Zertifikat vermuten. Das konnte allerdings schnell ausgeschlossen werden, da es von einer vertrauenswürdigen Zertifizierungsstelle kommt und innerhalb des Gültigkeitsbereichs lag. Das Problem lag an dem veralteten Verschlüsselungsprotokoll. Am Exchange 2010 selbst war noch TLS 1.0 im Einsatz und Microsoft hat vor kurzem den Betrieb auf TLS 1.2 angehoben. Somit wurde die Verbindung einfach gekappt. Über das Tool SSL-Tester von SSLLabs könnt ihr übrigens sehr einfach herausfinden, welche Protokolle eure Website unterstützt.
Somit ist es an der Zeit, TLS 1.2 zu aktivieren. Dazu müsst ihr vorab alle Windows und .NET Framework Security Updates installieren und euren Server auf einen aktuellen Stand bringen. Anschließend müssen wir anhand eines Registry Keys festlegen, dass der Server auch TLS 1.2 verwenden darf:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
Kopiert diese Zeilen einfach in ein Textdokument, speichert es als „WindowsTLS12.reg“ ab und führt es am betroffenen Server aus. Zu guter Letzt konfigurieren wir das .NET Framework dahingehend, dass es die Systemwerte von Windows übernehmen soll. Je nachdem welches .NET Framework auf dem Exchange installiert ist, setzt ihr folgende Keys:
NET Framework 3.5:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727] "SystemDefaultTlsVersions"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727] "SystemDefaultTlsVersions"=dword:00000001
NET Framework 4.X:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001
Verpasst dem Server einen Neustart und führt den SSLLabs Security Check erneut aus. Jetzt sollte TLS 1.2 verfügbar sein und der Migrationbatch ohne Probleme durchlaufen. Weitere Details und Hintergrundwissen zu TLS 1.2 am Exchange gibt es übrigens auch direkt von Microsoft: Exchange Server TLS guidance, part 1: Getting Ready for TLS 1.2
Microsoft selbst behandelt auch noch weitere Fehlermeldungen in ihrem Blogpost „Troubleshooting Hybrid Migration Endpoints in Classic and Modern Hybrid„.
