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 die AutoComplete-Funktion für die Auswahl Empfängers genutzt wird oder irgendwelche alten E-Mails weitergeleitet oder als Vorlage für eine neue Nachricht genutzt werden sollen. Woran das liegt und wie man es wieder behebt folgt in diesem Artikel.

Problem: Nachricht konnte nicht zugestellt werden

Der Fehler äußerte sich auf verschiedene Arten. So konnte es passieren, dass beim Versenden an eine vorgeschlagene interne E-Mail-Adresse der Absender einen solchen Fehlerbericht zurückbekommt. 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 nach dem Absenden 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: LegacyExchangeDN und x500-Adresse

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. Bei den fehlerhaften AutoComplete-Einträgen scheint dies ebenfalls so geschehen zu sein und ist deshalb auch für den Anwender nicht ersichtlich. Bei den betroffenen Einträgen handelte es sich meist um Postfächer bei denen der Nutzer im Active Directory mal umbenannt worden ist.

Dies ist schlecht, denn mit diesem Attribut kann der neue Exchange-Server bzw. Microsoft 365 / 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: x500-Adressen anlegen

Für die fehlerhaften vorgeschlagenen „alten“ E-Mail-Adressen kann man als Workaround die Nutzer anweisen diese AutoComplete-Einträge 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.

Ein aufmerksamer Leser hat noch folgende Möglichkeit gefunden, die x500-Adressen manuell zu ermitteln. Wenn man die Empfängeradresse im NDR-Format hat, dann muss man diese wie folgt abändern:

• alle Unterstriche („_“) durch Schrägstriche („/“) ersetzen
• alle „+20“ durch Leerzeichen ersetzen
• alle „+28“ durch öffnende Klammern ersetzen („(„)
• alle „+29“ durch schließende Klammern ersetzen („)“)
• den „IMCEAX“-String löschen
• den „@mgd.domain.com“-String löschen
• am Anfang ein „X500:“ einfügen

Fazit zur legacyExchangeDN-Problematik

Wenn man es weiß, kann man natürlich im Vorfeld agieren 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