During an Exchange migration, the "old" Exchange server may not be able to deliver mails to the new Exchange server. This happened during an Exchange 2013 to Exchange 2019 migration. Mails on the Exchange 2013 server to mailboxes that had already been migrated to Exchange 2019 could not be delivered. The queue on the Exchange 2013 server returned the following error:
[{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}]
The error "421 4.4.2 Connection dropped due to SocketError" can have several causes, but in migration scenarios the lack of support for TLS 1.2 is usually the main cause. The above error message occurred on an Exchange 2013 server that was installed on Windows Server 2018 R2. The Exchange 2013 server should be migrated to Exchange 2019 on Windows Server 2019.
The cause of the error was the lack of TLS 1.2 support on the Exchange 2013 server. The server was configured to operate as a TLS 1.2 server, but not as a TLS 1.2 client. This meant that the Exchange 2013 server could accept TLS 1.2 connections, but could not establish TLS 1.2 connections to the Exchange 2019 server itself. However, Exchange 2019 requires TLS 1.2.
To resolve the issue and enable TLS 1.2 on Exchange 2013 in client mode, the following registry key can be created:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client
Two DWORDs can now be created under this path:
DWORD: DisabledByDefault
Value: 0
DWORD: Enabled
Value: 1
If the key with the name "Server" is also missing, this should also be created and the same DWORDs should be created as described above.
After restarting the "MSExchangeTransport" service, the queue was processed on the Exchange 2013 server and the delivery of the mails works perfectly.
Here you will find everything you need to know about TLS and 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.