Email unzustellbar nach Postfachmigration auf neuen Server

[Hirnilein0815 3]

Ich löse gerade einen wegen einer Virenattacke halbwegs zerschossenen Exchange Server 2019 durch eine Neuinstallation ab. Die Migration ist weitgehend abgeschlossen, die Outlook-Clients können sich mit den neuen Server verbinden, die Firewall wurde auf den neuen Server umgebogen, Mailverkehr ein- und ausgehend funktioniert, Zertifikatprobleme sind gelöst. Der letzte Schritt will allerdings nicht klappen, nämlich die Migration der Postfächer auf den neuen Server.

 

Wenn ich ein Postfach mit New-MoveRequest vom alten auf den neuen Server übertrage (jeweils nur ein Postfachspeicher), kann der Benutzer anschliessend keine externen Emails mehr verschicken. Er erhält umgehend einen Unzustellbarkeitsbericht:

 

Diagnoseinformationen für Administratoren:

Generierender Server: Mail-vsv4.domain.local

xxx@bluewin.ch
Remote Server returned '550 5.1.1 Recipient unknown'

 

Wenn ich das Postfach wieder zurück in die alte Postfachdatenbank übertrage, dann funktioniert der Versand wieder. Die Konfiguration der beiden Postfachdatenbanken habe ich verglichen, ich sehe keine Unterschiede. Ich habe auf dem neuen Server bereits testhalber eine zweite Postfachdatenbank angelegt, aber auch hier klappt der Versand nach Extern nicht, sobald ich ein Postfach in diesen Speicher migriere. Hat jemand eine Erklärung dafür, dass der Mailversand nach extern mit dem Postfachspeicher auf dem neuen Server nicht funktioniert?

[tesso 375]

Ist das Recoveryinstallation oder wirklich ein neuer Server?

Darf der neue Server Mails verschicken? Evtl. fehlt eine Authentifizierung oder die IP muss noch irgendwo eingetragen werden. 

[NorbertFe 2.067]

Und wer ist „Mail-vsv4.domain.local“?

ich hätte gewettet, dass der vorhin noch anders hieß. ;)

alter oder neuer Server?

[XP-Fan 219]

Hallo und herzlich willkommen an Board,

 

ich war mal so frei und habe deine Domain aus der Fehlermeldung herausgeholt, nicht das der Chef noch mitliest. :)

 

@NorbertFe

Ja das war vorher wohl der realname.

[Hirnilein0815 3]

Hallo zusammen

 

Dankeschön :)

 

Das ist ein komplett neu aufgesetzter Windows Server 2019 mit neu installiertem Exchange Server 2019 CU10. Die Idee war, die Konfiguration vom bisherigen auf den neuen Mailserver herüber zu retten und den alten dann zu deinstallieren. Der Mailflow ging gestern bereits über den neuen Server, sprich: Ich habe den internen Hosteintrag im DNS und eingehende Protokolle in der Firewall auf den neuen Server umgebogen, Autodiscovery und URLs konfiguriert, Zertifikate installiert etc. Der neue Server hat den Mailverkehr dann auch gleich klaglos übernommen. Erst, wenn ich die Postfächer vom alten auf den neuen Server migriert habe, gab's Probleme mit dem Versand nach extern.

 

Wie dem auch sei: Über Nacht hat sich das Problem für das eine Postfach, das ich testhalber auf dem neuen Server habe liegen lassen (alle anderen habe ich wieder zurück migriert), von alleine gelöst, dieser User kann jetzt auch wieder Emails nach extern verschicken. Ich sage jetzt mal vorsichtig: Problem wahrscheinlich gelöst, es braucht wohl einfach alles seine Zeit.

 

Das ist, was ich gemacht habe:

 

-- Alle Mailboxen von Mail-vsv3 nach Mail-vsv4 verschieben
Get-Mailbox -Database "Mailbox Database 067xxxxxxxx" | New-MoveRequest -TargetDatabase "Mailbox Database 09xxxxxxxx" -BatchName "Mail-vsv3 -> Mail-vsv4 All Users"

 

Nachdem alle Postfächer migriert waren:

 

-- Alle abgeschlossenen MoveRequests löschen
Get-MoveRequest -movestatus completed | remove-moverequest 

 

Habe ich im Anschluss vielleicht noch etwas übersehen? Oder heisst es tatsächlich einfach warten?

 

[5 Minuten später]

 

Mist, zu früh gefreut. Der Versand an eine andere externe Domain schlägt weiterhin fehl. Grundsätzlich kann ich auf dem neuen Server zwar problemlos surfen und nslookup ausführen. Kann es dennoch sein, dass der neue Server ein Problem mit dem Zugriff auf den DNS hat?

bearbeitet 23. September 2021 von Hirnilein0815

[NorbertFe 2.067]

vor 41 Minuten schrieb Hirnilein0815:

Kann es dennoch sein, dass der neue Server ein Problem mit dem Zugriff auf den DNS hat?

Dann wäre die Fehlermeldung eine andere und die Mails würden erstmal nen paar Stunden in der Queue rumdümpeln.

Remote Server returned '550 5.1.1 Recipient unknown'

Sagt doch eigentlich genau, was dein Problem ist. ;)

 

Welche Fehlermeldung erhältst du denn bei anderen externen Domains? Sendet der Exchange direkt raus oder erst zu einem Smarthost/Firewall usw.?

 

Bye

Norbert

[Hirnilein0815 3]

Der Exchange Server sendet direkt. Es handelt sich um gültige Email-Adressen, die funktionieren, solange sich das Postfach des sendenden Benutzers auf dem alten Server befindet.

 

Noch eine seltsame Beobachtung: Nach der Migration des Postfaches vom alten auf den neuen Server hat jeweils der erste Versand funktioniert. Eine erste Mail an xxx@bluewin.ch ging raus und kam beim Empfänger an, eine zweite nicht mehr. Ab dann funktioniert auch keine andere Emailadresse mehr. Das spricht eigentlich dafür, dass die Konfiguration korrekt ist, aber nach dem Versand der ersten Mail etwas passiert, das den weiteren Versand verhindert.

 

Vielleicht eine Lizenzgeschichte? Der Windows Server ist noch nicht aktiviert und der neue Server hat den gleichen Lizenzschlüssel wie der alte (der ja abgebaut werden soll).

[Dukel 455]

Wieso installiert man nach einer Virenattacke einen neuen Exchange im selben AD und der selben Exchange Org?

[NorbertFe 2.067]

vor 3 Minuten schrieb Hirnilein0815:

Vielleicht eine Lizenzgeschichte?

LOL klar. Bitte keine Mutmaßungen, das wird sonst nicht zielführend. ;)

 

Man kann aber auch gern alle gestellten Fragen mal beantworten, anstatt neue aufzuwerfen.

bearbeitet 23. September 2021 von NorbertFe

[Hirnilein0815 3]

Der Virenscanner hat die Bedrohung zwar abgefangen und die betroffenen Dateien unter Quarantäne gestellt, dabei aber auf dem alten Server OWA und ECP zerschossen.

[tesso 375]

Owa und ecp könnte man auch reparieren, so man der Umgebung überhaupt noch vertraut. 
Wenn owa und ecp zerstört wurden muss mehr passiert sein in der Umgebung. 
 

bearbeitet 23. September 2021 von tesso

[Hirnilein0815 3]

vor 34 Minuten schrieb NorbertFe:

Welche Fehlermeldung erhältst du denn bei anderen externen Domains? Sendet der Exchange direkt raus oder erst zu einem Smarthost/Firewall usw.?

Immer die gleiche: Der sendende Benutzer erhält im Outlook einen Unzustellbarkeitsbericht angezeigt.

 

 

Ich habe zuerst versucht, den alten Server zu reparieren. Das Setup ist aber ausgerechnet bei der Konfiguration von OWA mit einer Exception abgestürzt. Inzwischen kann ich das Setup gar nicht mehr starten, wegen vorangegangener Installationsfehler. Deswegen habe ich einen neuen Server aufgesetzt.

[NorbertFe 2.067]

Gerade eben schrieb Hirnilein0815:

Der sendende Benutzer erhält im Outlook einen Unzustellbarkeitsbericht angezeigt.

In einem NDR kann durchaus unterschiedliches stehen.

Was passiert denn, wenn du vom neuen Server aus mal per Telnet eine Mail an einen externen Empfänger schickst?

[tesso 375]

vor 2 Minuten schrieb Hirnilein0815:

Ich habe zuerst versucht, den alten Server zu reparieren. Das Setup ist aber ausgerechnet bei der Konfiguration von OWA mit einer Exception abgestürzt. Inzwischen kann ich das Setup gar nicht mehr starten, wegen vorangegangener Installationsfehler. Deswegen habe ich einen neuen Server aufgesetzt.

Recoveryinstallation ist ein Begriff?

 

Ich habe bei deinen Beschreibungen so meine Zweifel, das die Umgebung nicht kompromittiert wurde.

[Hirnilein0815 3]

Oh Mann...

 

Es war mein selbst entwickelter Spamfilter. Der Spamfilter ist als Transport Agent direkt in den Mail Flow eingebunden und blockiert eingehende Emails auf SMTP Protokollebene. Neben vielen weiteren Prüfungen blockiert er Emails, wenn bei Inbound Mail die Empfängeradresse unbekannt ist (Active Directory Lookup). Der Transport Agent funktioniert bei uns seit 10 Jahren bestens, solange es nur einen Exchange Server gibt. Da es aber während der Migration zwei Server gibt, kommunizieren diese miteinander, womit es eine interne Kommunikation mit externen Email-Adressen gibt - die unser Active Directory natürlich nicht kennt - worauf die Kommunikation abgewürgt wird. Deaktivieren des Spamfilters brachte die Lösung.