ukulele-7
Goto Top

Migration Exchange 2013 auf 2019 Sendconnector

Guten Morgen,

wir sind grade dabei in kleinen Schritten Exchange von 2013 auf 2019 (neuer Host) zu migrieren. Zunächst wurde jetzt im Produktivnetz eine neue VM (Windows 2022) aufgesetzt und Exchange 2019 installiert. Postfächer liegen noch auf exchangealt, DNS autodiscover und mail zeigen auf exchangealt, eingehende E-Mails werden an exchangealt weiter geleitet, das vorgeschaltete E-Mail Gateway kennt nur exchangealt. exchangeneu ist einfach nur da, soweit die Theorie.

Der einzige Sendconnector zeigt auf das Mailgateway und unter Bereichsdefinition \ Quellserver ist nur exchangealt gelistet. Nach meinem Verständnis ist es Blödsinn anzunehmen das exchangeneu versuchen könnte, E-Mails zu verschicken und niemand schickt ihm derzeit E-Mails.

Jetzt habe ich schon in zwei unterschiedlichen Fällen folgende E-Mail bekommen:
Diese Nachricht wurde noch nicht zugestellt. Es wird weiterhin versucht, die Nachricht zuzustellen.
Der Server wird noch 1 Tage, 21 Stunden und 42 Minuten versuchen, die Nachricht zuzustellen. Sie erhalten eine Benachrichtigung, falls die Nachricht bis dahin nicht übermittelt werden konnte.

Diagnoseinformationen für Administratoren:
Generierender Server: **exchangeneu**
Empfangender Server: exchangealt (x.x.x.x)

Server at exchangealt (x.x.x.x) returned '400 4.4.7 Message delayed'  
15.05.2023 19:22:12 - Server at exchangealt (x.x.x.x) returned '451 4.4.395 Target host responded with error. -> 421 4.3.2 Service not available'  
Ursprüngliche Nachrichtenköpfe:
Received: from **exchangeneu (x.x.x.x)** by
**exchangeneu (x.x.x.x)** with ShadowRedundancy id 15.2.1118.7;
 Mon, 15 May 2023 17:14:37 +0000
Received: from exchangealt (x.x.x.x) by
**exchangeneu (x.x.x.x)** with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id
 15.2.1118.26; Mon, 15 May 2023 17:31:19 +0200
Received: from exchangealt (x.x.x.x) by
 exchangealt (x.x.x.x) with mapi id
 15.00.1497.044; Mon, 15 May 2023 17:31:12 +0200
From: user_intern
To: extern
...
Die E-Mail in diesem Fall ist beim Empfänger definitiv eingegangen schon bevor diese Meldung bei unserem User kam.

[PS exchangeneu] C:\Windows\system32>Get-Queue

Identity             DeliveryType                      Status MessageCount Velocity RiskLevel OutboundIPPool NextHopDomain
--------             ------------                      ------ ------------ -------- --------- -------------- -------------
exchangeneu\9          SmtpRelayToConnectorSourceServers Retry  17           0        Normal    0              Name_des_Sendconnectors
exchangeneu\Submission Undefined                         Ready  0            0        Normal    0              Übermittlung
exchangeneu\Shadow\3   ShadowRedundancy                  Ready  10           0        Normal    0              exchangealt

Kann mir jemand helfen das zu verstehen? Sendet hier exchangealt and exchangeneu und der sagt, kein Mailconnector und sendet dann diese Meldung? Aber die E-Mail geht dennoch vorher schon raus? Ich würde das wirklich gerne verstehen und frage mich was jetzt passiert wenn ich den Sendconnector anpasse, gehen dann 17 E-Mails doppelt raus?



Zu allem Überfluss sehe ich in der Mail-Transfer-Log vom Gateway (das den exchangeneu gar nicht kennt, auf Linux basiert und nur SMTP zwischen den Servern macht) bei eingehenden! E-Mails mal exchangeneu und mal exchangealt aber nur als "Hostname", nicht wirklich als Zielserver:
May 16 09:44:27 ciphermail postfix/smtp[32634]: 7F13BCF: to=<user_intern>, relay=exchangealt[x.x.x.x]:25, delay=0.17, delays=0.04/0/0/0.12, dsn=2.6.0, status=sent (250 2.6.0 <202316050742.1lvxg7bq6djj@sending.at> [InternalId=253403070..., Hostname=exchangeneu] 82168 bytes in 0.107, 747,926 KB/sec Queued mail for delivery)

May 16 09:42:13 ciphermail postfix/smtp[32634]: A606BCF: to=<user_intern>, relay=exchangealt[x.x.x.x]:25, delay=0.2, delays=0.04/0/0/0.15, dsn=2.6.0, status=sent (250 2.6.0 <202316050742.1lvyipzq6djj@sending.at> [InternalId=296747880415..., Hostname=exchangealt] Queued mail for delivery)

Content-ID: 7173172064

Url: https://administrator.de/contentid/7173172064

Ausgedruckt am: 18.11.2024 um 17:11 Uhr

Dani
Dani 16.05.2023 um 13:15:13 Uhr
Goto Top
ukulele-7
ukulele-7 16.05.2023 um 13:56:22 Uhr
Goto Top
Wir sind im Teil 1 kurz vor Ende und haben den Send Connector noch nicht für exchangeneu konfiguriert. Das machen wir jetzt da viele neue E-Mails betroffen sind und gucken dann ob die betroffenen E-Mails ein zweites mal raus gehen.

Wir haben uns das Verhalten jetzt eine Weile in Ruhe angesehen aber werden nicht so recht schlau daraus. Ich würde verstehen wenn entweder exchangealt alles raus schickt weil exchangeneu ja nicht kann oder das E-Mails in exchangeneu in der Warteschlange bleiben und nicht raus gehen aber aktuell gehen sie raus und bleiben teilweise in der Warteschlange von exchangeneu, das erschließt sich mir so gar nicht.
ukulele-7
ukulele-7 16.05.2023 um 14:20:30 Uhr
Goto Top
Update:
exchangeneu ist jetzt auch im Send Connector hinterlegt und die Warteschlange leert sich. Die E-Mails werden nicht erneut / doppelt versandt.
ukulele-7
ukulele-7 16.05.2023 um 17:48:19 Uhr
Goto Top
Update #2:
Kleine Korrektur, es wurden nicht alle E-Mails in der Warteschlange abgearbeitet (nur etwa die Hälfte), wohl nur solche die tatsächlich vorher schon raus gegangen waren (ich hatte mehrere Bestätigungen über E-Mails die tatsächlich angekommen waren und habe 100% angenommen). Es gab aber tatsächlich auch einen kleinen Teil E-Mails die vorher nicht raus gegangen waren und auch nach wie vor nicht raus konnten.

Ursache hierfür war dann ein Routing Problem weil exchangeneu in einem anderen Subnetz steht als exchangealt + Mail Gateway, das haben wir gelöst.

Ich kann nur sagen das exchangeneu E-Mails verschicken wollte obwohl er nicht im Send Connector gesetzt war und das teilweise durch exchangealt erfolgt ist und teilweise nicht. In der Warteschlange von exchangeneu waren dann die E-Mails die gar nicht versandt wurden aber auch solche die über echangealt raus gegangen waren.

Da der Send Connector natürlich konfiguriert werden sollte und exchangeneu jetzt sendet mache ich mir da jetzt auch keinen Kopf mehr drum.