Bei einer Exchange Migration kann es zu dem Problem kommen, dass der “alte” Exchange Server keine Mails an den neuen Exchange Server zustellen kann. So geschehen bei einer Exchange 2013 zu Exchange 2019 Migration. Mails auf dem Exchange 2013 Server zu Postfächern welche schon auf den Exchange 2019 migriert waren, konnten nicht zugestellt werden. Die Warteschlange auf dem Exchange 2013 Server lieferte den folgenden Fehler:
[{LRT=30.08.2020 21:06:24};{LED=441 4.4.1 Error encountered while communicating
with primary target IP address: „421 4.4.2 Connection dropped due to SocketError.“
Attempted failover to alternate host, but that did not succeed. Either there are no
alternate hosts, or delivery failed to all alternate hosts. The last endpoint
attempted was 192.168.1.10:475};{FQDN=exchange2019.domain.local};{IP=192.168.1.10}]
Der Fehler “421 4.4.2 Connection dropped due to SocketError” kann zwar mehrere Ursachen haben, in Migrationsszenarien ist hier aber die fehlende Unterstützung für TLS 1.2 meist die Hauptursache. Die oben genannte Fehlermeldung ist auf einem Exchange 2013 Server aufgetreten, welcher auf Windows Server 2018 R2 installiert war. Der Exchange 2013 Server sollte zu Exchange 2019 auf Windows Server 2019 migriert werden.
Ursache des Fehlers, war die fehlende TLS 1.2 Unterstützung auf dem Exchange 2013 Server. Der Server wurde zwar für den Betrieb als TLS 1.2 Server konfiguriert, nicht aber als TLS 1.2 Client. Somit konnte der Exchange 2013 Server zwar TLS 1.2 Verbindungen annehmen, nicht aber selbst TLS 1.2 Verbindungen zum Exchange 2019 Server aufbauen. Exchange 2019 setzt TLS 1.2 allerdings voraus.
Um das Problem zu beheben und TLS 1.2 auf dem Exchange 2013 im Client Modus zu aktivieren, kann der folgende Registry Schlüssel erstellt werden:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client
Unter diesem Pfad können nun zwei DWORDs angelegt werden:
DWORD: DisabledByDefault
Wert: 0
DWORD: Enabled
Wert: 1
Falls auch der Schlüssel mit dem Namen “Server” fehlt, sollte dieser ebenfalls erzeugt werden und die gleichen DWORDs wie oben beschrieben erstellt werden.
Nach einem Neustart des Dienstes “MSExchangeTransport”, wurde die Queue auf dem Exchange 2013 Server abgearbeitet und die Zustellung der Mails klappt einwandfrei.
Hier findet sich alles Wissenswerte bezüglich TLS und Exchange Server:
Habe diesen Fehler heute zwischen Exchange Online und GMAIL. Da wirds natürlich schwierig mit den RegKeys. Hat da jemand eine Idee?
Heute das Problem gehabt, Danke für deine Beiträge!
Servus.
Vielen Dank für diesen Artikel. Hat mir grad (zwar nach einigem suchen) den Tag gerettet. Ob 2012 R2 oder Exchange 2013… Nur zur Info: Dieser hinweis vom Thread-Ersteler funktioneirt auch in der kombination Server 2008 R2 mit Exchange 2010 (UR29) bei einer Migration zu Server 2016 mit Exchange 2016 (CU15). Hatte ziemlich genau die gleichen Probleme, dass trotz deaktivierter Funktion beim Konnektor (TLS aus etc.) die untereinander (gem. der Logs) trotzdem an der TLS neogation scheiterten. Habe dann am 2008 R2 die Eitnräge wie im Thread beschriben erstellt und den Transportdienst neugestaqrtet und siehe da –> alle hängenden NMails sind raus. Es funktioniert nun relay in beide Richtungen und auch nach extern (für bereits igrierte Postfächer). Somit top Artikel und nicht schwer umzusetzen.
Thanks dafür.
MfG
Kleiner Tippfehler wie ich vermute: Windows Server 2018 R2? Glaube du meinst Windows Server 2012 R2. Ansonsten super Artikel.
Der Fehler “421 4.4.2 Connection dropped due to SocketError” kann zwar mehrere Ursachen haben, in Migrationsszenarien ist hier aber die fehlende Unterstützung für TLS 1.2 meist die Hauptursache. Die oben genannte Fehlermeldung ist auf einem Exchange 2013 Server aufgetreten, welcher auf Windows Server 2018 R2 installiert war
Ich verwende schon relativ lange IISCrypto (https://www.nartac.com/Products/IISCrypto/) zum Einstellen der unterstützten Protokolle. Das Tool ist sehr einfach zu bedienen und es gibt auch vorbereitete Templates für verschiedene Sicherheitsstandards. Kein manuelles Einstellen in der Registry mehr :)
Unter https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls?WT.mc_id steht man soll 0xFFFFFFFF für eingeschaltet verwenden. Bei ausgeschaltet bei Standard jedoch 0.