Office365/Exchange: Nachricht konnte nicht zugestellt werden – LegacyExchangeDN und x500

Wer eine Exchange-Migration per Ex- und Import der PST-Datei oder durch das manuelle Verschieben oder Kopieren von E-Mails vornimmt, wird vermutlich irgendwann ein Problem feststellen. Unter Umständen wird sich irgendwann der erste Benutzer über Probleme beim Versenden von E-Mails beschweren (z. B. Fehlercode 550 5.1.11 oder 0x80070005-0x000004dc-0x00000524). Dies taucht dann auf, wenn irgendwelche alten E-Mails weitergeleitet oder als Vorlage für eine neue Nachricht genutzt werden sollen. Woran das liegt und wie man es behebt folgt in diesem Artikel.

Problem

Der Fehler äußerte sich auf verschiedene Arten. So konnte es passieren, dass beim Versenden an eine vorgeschlagene bekannte interne E-Mail-Adresse der Absender einen solchen Fehlerbericht bekommt. Die E-Mail schlägt dann wieder bei ihm auf:

Ihre Nachricht konnte nicht an mehrere Empfänger zugestellt werden.

Ihr E-Mail-Programm verwendet veraltete Adressinformationen für die Empfänger.

Statuscode: 550 5.1.11

Die E-Mail-Adresse des Empfängers ist eine LegacyExchangeDN-Adresse, die vom Office 365-Dienst nicht verwendet wird. Dieser Fehler wird möglicherweise angezeigt, wenn Sie die E-Mail Ihrer Organisation von einer lokalen Bereitstellung in die Cloud migriert haben oder wenn Ihre Organisation über eine Hybridkonfiguration verfügt und Sie Ihr lokales Verzeichnis mit Office 365 synchronisieren. Wenn sich das Problem nicht durch Löschen der AutoVervollständigen-Empfängerliste in Outlook oder Outlook im Web beheben lässt, versuchen Sie, die zugehörige LegacyExchangeDN-Adresse in Ihrem lokalen Active Directory zu löschen. Synchronisieren Sie dann das Verzeichnis noch mal.

Beim Versuch eine alte, vom Absender selbst verfasste, E-Mail weiterzuleiten oder als Vorlage für die Zustellung als neue E-Mail zu verwenden und z. B. nur den Empfänger zu verändern, kommt ein auf den ersten Blick völlig unpassender Fehlerbericht zurück:

Ihre Nachricht hat einige oder alle Empfänger nicht erreicht.

Betreff: xxxx
Gesendet am: xxxx

Folgende(r) Empfänger kann/können nicht erreicht werden:

xxxx xxxx am xxxx
Diese Nachricht konnte nicht gesendet werden. Sie besitzen nicht die Berechtigung, die Nachricht im Auftrag des angegebenen Benutzers zu senden.

Der Fehler lautet [0x80070005-0x000004dc-0x00000524].

Angeblich wird versucht von einem anderen E-Mail-Konto aus die Nachricht zu schicken. Hierfür würde normalerweise die „Senden Als“-Berechtigung benötigt. Allerdings hat der Benutzer nur versucht eine von ihm selbst verfasste E-Mail zu nutzen und ist dementsprechend auch als Absender hinterlegt. Die Fehlerbeschreibung ist also erst einmal etwas irreführend, macht aber nach der Erklärung unter dem nächsten Punkt „Ursache“ durchaus Sinn.

 

Urache

Auch wenn man es nicht sieht, so arbeitet der Exchange-Server für die internen E-Mail-Adressen nicht mit den eigentlichen E-Mail-Adressen der Benutzer. Stattdessen nutzt er das sogenannte „legcayExchangeDN“-Attribut der Benutzer. Dieses war mir bisher auch nicht wirklich ein Begriff. Diese haut der Exchange also anstatt der eigentlichen internen Mail-Adressen in die E-Mails rein und nutzt diese dann zur Zuordnung der Exchange-Mail-Konten zu den Absendern und Empfängern.

Nun scheint es, zwar nicht immer aber oft genug, beim manuellen Verschieben von E-Mails oder beim Import aus PST-Dateien das Problem zu geben, dass statt der richtigen E-Mail-Adressen die legcayExchangeDN übernommen wird. Dies ist schlecht, denn mit diesem Attribut kann der neue Exchange-Server bzw. Office365 dann nichts anfangen. Dieser Umstand erklärt dann auch die Bemängelung der fehlenden Rechte für die „Senden als“-Funktion, da es sich bei dem ursprünglichen Konto für die Erstellung der E-Mail aus Sicht des neuen Exchange-Servers tatsächlich um ein anderes Konto handelt.

In Outlook selber kann man die richtige legacyExchangeDN gar nicht sehen, dort steht trotzdem der Nutzer (z. B. Max Mustermann) wie man es gewohnt ist. Wenn man aber in Outlook Online im Browser nachschaut, bekommt man diese zumindest bei den gesendeten Mails (bei empfangenen habe ich nicht drauf geachtet) zu sehen:

In der Desktop-Version von Outlook kann man dieses Problem aber wie folgt identifizieren: Wenn man dort unter den gesendeten E-Mails nach sieht und dort auf sich selber als Absender klickt, dann werden einem normalerweise die Kontaktinformationen angezeigt. Bei den E-Mails mit der verwaisten legacyExchangeDN werden dort keine Kontaktinformationen angezeigt, weil für dieses Konto keine vorhanden sind.

 

Lösung

Für die fehlerhaften vorgeschlagenen „alten“ E-Mail-Adressen kann man die Nutzer anweisen diese beim Auftreten eines solchen Fehlers zu löschen und die betroffene Mail-Adresse manuell neu einzugeben. Das ist aber nicht sehr praktikabel und wird von den Benutzern auch immer wieder vergessen und wieder als neuer Fehler reklamiert.

Glücklicherweise kann man die alten x500-Adressen einfach in einer neuen Exchange- oder Office365-Umgebung manuell hinzufügen und damit die alten Verweise auf die, in der neuen Umgebung nicht existierenden, Konten wieder gültig machen.

Hierzu muss man sich erst einmal die ganzen x500-Adressen besorgen. Dies geht natürlich umständlich, in dem man bei jedem Benutzer nach solchen betroffenen E-Mails schaut. Oder man lässt sich diese einfach per Powershell auf dem alten Exchange-Server ausgeben, z. B. unter Exchange 2010:

 

Dann kann man diese auf dem neuen Exchange-Server bzw. in Office365 einfach manuell bei den einzelnen Benutzern als weitere E-Mail-Adresse hinterlegen:

Aus der oben im Beispiel angegebenen legacyExchangeDN wird dann als x500-Adresse z. B.:

/o=FIRST ORGANZIATION/ou=EXCHANGE ADMINISTRATIVE GROUP (ERTF9ADIBONTSLT)/cn=TEST NUTZER23S

Als E-Mail-Adresstyp muss man manuell „x500“ eintragen: (Warum eigentlich manuell und warum nicht mit Punkt, wie unter dem Texteingabefeld angegeben? Das weiß wohl nur Microsoft.)

Dies geht wohl auch einfacher per Azure-Powershell, die ich aber bisher nicht zum Laufen gebracht habe. Da es sich um eine einmalige Aktion handelt, habe ich die Adressen einfach wie beschrieben manuell hinzugefügt.

 

Fazit

Wenn man es weiß, kann man natürlich im Vorfeld reagieren und die entsprechenden x500-Mail-Adressen schon vor dem Beginn der Migration den neuen Konten in Office365 / Microsoft 365 zuordnen. Das erspart einem dann diese wahrscheinlich irgendwann auftretenden Probleme und ist auf jeden Fall zu empfehlen. Leider muss man wegen solcher Eigenheiten solchen alten „Schrott“ auch bei einem kompletten Neuanfang in einer neuen Exchange-Umgebung mitschleppen, wenn man den alten Datenbestand weiterhin benötigt.

Wer sich noch für eine detailliertere Beschreibung des „legacyExchangeDN“ und der „x500“-Adresse interessiert findet hier ganz gute Infos: https://www.msxfaq.de/server/legacyexchangedn.htm

 

Schreibe einen Kommentar