MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

EXO Selbsthilfe Diagnose

Die wenigsten Administratoren werden mit der Überschrift etwas anfangen können. Dabei ist diese Funktion sehr nützlich, wenn es beim Exchange Online Provisioning irgendwo stockt. Nebenbei lernen wir so, dass EntraID und Exchange Online Directory separate Verzeichnisdienste sind.

Beachte dazu auch Azure AD - Ein Verzeichnisdienst, oder zwei oder mehr

Fehlerbild

Der Kunde nutzt Exchange Hybrid und die Postfächer sind schon überwiegend in Exchange Online. Der MX-Record verweist auch schon zu Exchange Online und das Problempostfach ist sowohl aus dem Internet als auch von seinem anderen Exchange Online Kollegen problemlos erreichbar. Nur Mails vom lokalen Exchange Server werden nicht in das Exchange Online Postfach zugestellt, sondern laufen in einer Dauerschleife durch den Transport, bis es zu einem "Hop Count Exceeded" kommt.

Zusammenhänge

Das Routing von Exchange OnPremises zu Exchange Online erfolgt über die MOERA - Microsoft Online Email Routing Address. Der Benutzer ist im lokalen Active Directory eine "RemoteMailbox", bei der als Zieladresse im AD-Feld "TargetAddress" (Exchange: "RemoteRoutingAddress" eine Adresse in der Form "username@<tenantname>.mail.onmicrosoft.com" steht. Zudem ist diese Adresse auch im AD-Feld "ProxyAddresse" (Exchange: EMailAddresses. Der Inhalt der ProxyAddresses wird durch ADSync zu Entra ID und Exchange Online repliziert.

Eine Mail an den lokalen Exchange Server wird also über die RemoteRoutingAddress und den Connector an Exchange Online gesendet, welcher die Mail dann anhand der EmailAddresses ins Exchange Online Postfach zustellt. Den Weg der Mail durch die Server haben wir über das Message Tracking nachvollziehen können aber Exchange Online hat die Mail nicht zugestellt, sondern wieder zum lokalen Server zurückgesendet. Dazu gibt es nur folgende mögliche Fehler:

  • Umleitung durch den Benutzer
    Theoretisch könnte der Anwender eine Posteinfangsregel gebaut haben, die alle Mails an eine andere Adresse weiterleitet. Allerdings dürfte diese dann auch die Mails aus dem Internet oder anderen Exchange Online Postfächern des gleichen Tenants betreffen. Bei einer Kontrolle konnten wir Regeln finden aber keine, die hier passt.
  • Umleitung durch den Administrator
    Auch ein Exchange Administrator kann einen "alternativen Empfänger" bei einem Postfach konfigurieren. Das war aber auch nicht der Fall.
  • Unbekannte Mailadresse
    Eigentlich sollte dieser Fall nicht auftreten aber wir haben die ProxyAddresses in Exchange Online kontrolliert. Und hier fehlte die MOERA-Adresse, die ich im Bild rechts unten rot markiert hatte. Der Benutzer hatte dort nur seine primäre Adresse und den UPN und die Tenant-Adresse, welche Entra ID immer addiert, auch wenn diese nicht durch ADSync geschrieben werden.

Da Exchange Online keinen Empfänger mit der Adresse "user@msxfaq.mail.onmicrosoft.com" hatte, konnte es die Mail nicht zustellen und da der Kunde einen Outbound Connector für seine Domains "via OnPremises" konfiguriert hatte, lieft die Mail in der Schleife.

Troubleshooting

Damit stellte sich die Frage, warum eine Information aus dem lokalen Active Directory nicht in Exchange Online landet. Wir haben daher etwas genauer die verschiedenen Stellen kontrolliert:

  • OnPremises
    In der Eile kann man etwas übersehen. Daher haben wir explizit noch einmal genau die ProxyAddresses und das Feld "TargetAddress" beim lokalen AD-Objekt kontrolliert. Sehr leicht überliest man ja die Details und übersieht vielleicht einen Tippfehler o.ä. Es ist mir selbst schon passierte dass ich "user@msxfaq.mail.onmircosoft.com" geschrieben habe und Buchstabendreher gehen gerne mal unter aber werdenvom Tenant natürlich nicht akzeptiert. Damit fehlt dann die ProxyAddresse in der Cloud.
  • Entra ID Connect
    Wer mag, kann auf dem DirSync-Server ins Metaverse schauen und dort die Inhalte der Felder aus dem Active Directory und Entra ID kontrollieren. Sie können den Schritt aber auch erst einmal überspringen.
  • Entra ID
    Über das Entra-Portal https://entra.microsoft.com oder https://portal.azure.com können Sie die Daten des Benutzers kontrollieren. In den Eigenschaften findet sich der Link "Other emails" zur Anzeige der ProxyAddressen. Hier waren alle Adressen korrekt vorhanden. Damit war auch klar, dass der Verzeichnisabgleich mit ADSync/EntraID Connect/Entra Cloud Sync keinen Fehler hatte.
  • Exchange Admin Center
    Wir haben dann über https://admin.exchange.microsoft.com/ oder die Exchange Online PowerShell die Details zum Postfachs kontrolliert. Erst auf den zweiten Blick ist aufgefallen, dass die MOERA - Microsoft Online Email Routing Address user@msxfaq.mail.microsoft.com nicht vorhanden war.

Damit war klar, dass der Fehler im Exchange Online Provisioning steckt. Ehe Sie nun gleich ein Ticket eröffnen, können Sie noch eine "Selbstdiagnose" starten. Der Schlüssel die das "Fragezeichen" im Exchange Admin Center unter der folgende Suchbegriff:

Run Tests: EXO Recipient object failures

Alternativ können Sie einfach den folgenden Link im Browser eingeben: https://aka.ms/PillarEXORecipients: Danach verändert ich die pumpe Hilfe in einen Assistenten, welcher nach Eingabe des fraglichen Empfängers eine Analyse startet:

Es gibt übrigens noch weitere solche Assistenten, die auch nicht besonders geheim sind.

Die Fehlermeldung aber war ein eindeutiger Indikator, dass hier ein Objekt nicht durch das Provisioning verwaltet werden konnte:

 

 

Das lokale AD-Konto hatte kein Archiv und damit war die ArchiveGUID auf dem OnPremises-Server natürlich 00000000-0000-0000-0000-000000000000. Das zeigte auch ein "Get-RemoteMailbox" im lokalen Exchange:

Wenn ich mir das Postfach in der Exchange Online PowerShell mit "Get-Mailbox" anzeige, dann ist hier ein Cloud Archiv vorhanden. Interessant fand ich die Anzeige im Exchange Admin Center, als wir beim Benutzer das Archiv nachgeschaut haben. Hier erscheint die gleiche Warnung:

"Exchange: Failed to sync the ArchiveGuid 00000000-0000-0000-0000-000000000000 of Mailbox .., because one cloud archive already exists"

Die Warnung war vorher aber noch nicht sichtbar. Erst der Check mit "PillarEXORecipients" hat auch hier eine Anzeige aktiviert.

Ich finde es schade, dass Microsoft sehr wohl solche Probleme auch automatisch erkennen kann, aber es nirgends eine entsprechende Meldung gibt. Dabei gibt es viele Orte, z.B. der ADSync Status, den Entra ID DisyncStatus oder notfalls auch einen Report im Exchange Admin Center mit Verlinkung auf die Portalseite. Zu allerletzt könne Exchange ja eine Mail an die Gruppe der "Global Administrators" oder zumindest "Exchange Recipient Administratoren" oder "Exchange Administratoren" senden.

ArchiveGUID blockt ProxyAddresses

Interessant ist aber die Tatsache, dass der interne Provisoining-Lauf von Exchange Online sich an diesem Fehler aufhängt und das Provisioning für diesen Benutzer stoppt. Allerdings nur in Richtung Exchange Oneline Verzeichnisdienst aber nicht Richtung Entra ID.

Wer hier also "nur" in Entra ID nachschaut, wird keinen Fehler feststellen können. Erst der Blick ins Exchange Online Verzeichnis zeigt die fehlenden Einträge, wenn man denn genau hinschaut. Sie brauchen dazu das Exchange Admin Center oder der Exchange Online PowerShell.

Ich hätte mir erhofft, dass der Entra ID Provisioningservice dann die ArchivGUID erst einmal ignoriert und die anderen unstrittigen Felder dennoch überträgt. Ich kann mit nur vorstellen, dass der Fehler mit der ArchiveGUID schon länger existiert, als die Änderung der ProxyAddresses.

Auf der anderen Seite ist es ja gut, dass Microsoft hier eine Abfrage eingebaut hat. Stellen Sie sich mal vor, dass der Entra ID-Provisioning Prozess einfach die ArchiveGUID überschrieben hätte. Dann wäre das Archiv des Anwender plötzlich gelöscht. 

Heilung

In dem Fall ist Abhilfe natürlich sehr einfach. Der korrekte Weg einem Benutzer in Exchange Online ein Online Archiv einzurichten ist die lokale Exchange PowerShell. Dies gilt zumindest, solange Sie ADSync aktiv haben und die Exchange Objekte nicht durch IsExchangeCloudManaged direkt in der Cloud verwaltet werden. Wir holen uns die ArchiveGUID aus Exchange Online und schreiben diese direkt in die lokale RemoteMailbox. Die GUID können Sie natürlich auch aus der Fehlermeldung im Exchange Admin Center übernehmen.

# Befehl in der Exchange Online PowerShell
$ArchivGUID = (Get-EXOMailbox <mailadresse>).ArchiveGUID

# Befehl in der lokalen Exchange PowerShell
Set-RemoteMailbox <mailadresse> -ArchiveGUID $ArchiveGuid

Bei mir hast Set-RemoteMailbox eine gelbe Warnung geliefert, dass keine Änderungen zu schreiben waren. 

Die ArchivGUID wurde dennoch aktualisiert.

Damit "löst" sich zumindest diese Knoten hinsichtlich ArchivGUID. Das dies bei diesem Objekt das einzige Problem war, hat Entra ID nach dem Update durch ADSync auch die ProxyAddresses in das Exchange Online-Objekt übertragen und damit sind Mails an die MOERA-Adresse endlich auch zugestellt worden.

Troubleshooter Details

Natürlich habe ich mir auch noch im Fiddler die Anfragen des Exchange Admin Centers angeschaut. Vielleicht verrät Microsoft etwas mehr welche Checks im Hintergrund laufen. Der Startbefehl ist anscheinend nicht Teil des Exchange Admin Centers, sondern geht auf "admin.cloud.microsoft" und liefert ein "AffectedUser"-Property mit. Zurück kommt dann nur die Information, dass der Auftrag abgesendet wurde.

Einige Sekunden danach fragt ihr Browser dann die Ergebnisse anhand der vorher erhaltenen SessionID wieder ab.

Die Antwort liefert im Feld "Details" das Ergebnis als HTML-Text, der von der Webseite einfach zur Ausgabe eingebaut wird. Weitere Details uns insbesondere eine Debug-Ausgabe der im Backend ausgeführten Tests werden nicht verraten.

Einschätzung

Eigentlich waren es nur Mails, die von OnPremises an ein Exchange Online Postfach nicht zugstellt worden sind. Gefunden haben wir dann eine geblocktes Provisioning von Entra ID zum Exchange Online Verzeichnis, welches wir hier für das betroffene Objekte mittels "Selbstdiagnose" erklären und letztlich auch lösen konnten. Ob dies nun das einzige Objekt war oder es noch weitere Unstimmigkeiten gibt, können wir weder aus EntraID noch anderen Log in Erfahrung bringen. Ich könnte nur z.B. die Informationen der Exchange Online Empfänger mit den Eigenschaften im lokalen AD vergleichen, also indem ich Compare-GAL erweitere. 

Weitere Links