Exchange Online Queue Monitoring

Diese Seite beschreibt die Möglichkeiten, frühzeitig Probleme bei der Zustellung von Mails in Exchange Online zu analysieren.

OnPremises

Wer kennt ihn nicht vom lokalen Exchange Server. Mit dem Befehl "Get-Queue" konnten Sie alle Warteschlangen auf dem Server anzeigen lassen und mit einem Get-Message sogar die Nachrichten darin. So konnten Sie pro Server ermitteln, ob Mails schon länger in einer Warteschlange liegen. Wenn Sie mehrere Server hatten, mussten Sie die für jeden Server machen. Das ist aber alles so einfach, dass es direkt nach einer Integration in ihr Monitoring schreit. Denn wenn Sie dies nicht machen, dann versucht Exchange eine Mail immer wieder zuzustellen und nach Ablauf einer konfigurierbaren Zeit wurde dann eine Unzustellbarkeit an den Absender erstellt. Dann war ihr Anwender das Monitoring-System, der sich dann beim Administrator gemeldet hat.

Online

Diese Seite widmet sich aber Exchange Online und wie Sie auf EXO Mailboxserver Insights schon lesen konnten, gibt es in der Cloud deutlich mehr Server. Eine Mail, die von einem Benutzer den Tenant verlässt, wird von Exchange Online über einen verfügbaren Server weiter geroutet. Dabei werden Kopien auf anderen Server vorgehalten (Siehe Transport Cache), so dass bei einem Serverausfall die Mail einen anderen läuft. Das ist so sehr pfiffig und skalierbar aber für die Suche nach einer Mail ist es schwer, den Server zu finden. Alle Server können Sie nicht abfragen und die Server senden sicher keinen Echtzeitstatus an eine zentrale Instanz.

Das sehen Sie ja schon beim Messagetracking, welches OnPremises noch "pro Server" vorgehalten wird und abgefragt werden muss. Mit Exchange Online fragen sie nur noch "das Messagetracking" und die verschiedenen Transportserver senden Events an diese Instanz ihres Tenants. Das erfolgt leider nicht in Echtzeit sondern ebenfalls etwas verzögert. Wie eben eine Transport Rolle mit der Mail etwas gemacht hat, sendet er ein Update an das Reporting-Backend, welches dann die Daten einbucht und bei der Abfrage wieder ausgibt.

Gäbe es nun keine andere Option, dann haben wir die Wahl zwischen:

  • Eigenmonitoring
    Wir könnten mittels Exchange Online Messagtracking regelmäßig ermitteln, welche Mails auf die Reise geschickt wurden und wie deren letzter oder aktueller Status ist. Dabei müssten wir auch mit Bifurcation, d.h. eine Mail startet und wird dann an mehrere Empfänger "aufgefächert" und können daher unterschiedliche aktuelle Zustände haben.
  • Endanwender Monitoring
    Wir könnten die Aufgabe beim Anwender lassen. Exchange Online versucht es immer wieder eine Mail zu senden aber nach 24h (Siehe EXO Messageexpiration) gibt Exchange Online auf und generiert einen NDR: Allerdings sind 24h sehr lange, wenn ein Konfigurationsfehler vorliegt oder Ausfall beim Empfänger nicht vorher bemerkt wird. Es gibt keine Zwischenmeldungen.

Einen Echtzeitstatus über Mails, die für einen Tenant in einer Warteschlange stecken gibt es aktuell nicht. Aber es gibt schon noch die ein der anderen Funktionen, die Microsoft anbietet.

Mail Flow Reports

Exchange Online hat eine Reporting-Funktion unter der URL "https://admin.exchange.microsoft.com/#/reports/mailflowreportsmain". im Report-Center der Exchange Online Admin Console gibt es z.B. einen Report mit dem Namen ""Queues messages report", der genau die Lösung verspricht:

Um die Funktion zu zeigen, habe ich mir einen Connector für die Domain "netatwork.de" angelegt und auf eine IP-Adresse geroutet, die keine Mails annimmt. Dann konnte ich von meinem Developer Tenant eine Mail an mein Net at Work-Konto senden und warten. Ich hatte nach einiger Zeit vier Mails mit unterschiedlichem Alter in der Warteschlage. Die Momentaufnahme war vom 9. Nov 2023 um 14:35.

Die letzte Mail hat noch gar keinen Status, da das Messagetracking nur den Einwurf aber noch nicht die aktuelle Position kennt. Ich sollte nun also im Report etwas sehen können. Leider hat der Report aber immer nur folgendes angezeigt:

Leider kann ich nun nicht sagen, ob das ein temporäres Problem am 9. Nov 2023 ist oder ein unerkannter Bug, weil die Funktion eh nicht genutzt wird. Also habe ich das Exchange Admin Portal mit dem Chromium Debugger analysiert und folgende Abfrage gefunden. Die Anfrage habe ich am 9. Nov 2023 gegen 13:31 gestellt. Laut Messagetracking sind also mindestens drei Mails schon länger als 1 Stunde im Status "Pending"

POST https://admin.exchange.microsoft.com/beta/MailflowReport/ExchangeAdminCenter.TransportQueueMailflowReport()

Wir sehen, dass Microsoft hier nicht Graph o.ä. nutzt, sondern einen Service des Admin Centers selbst. Wenn ich mir aber die Parameter anschaue, dann scheint die API hier einen gib es Start und End-Wert, der genau eine Stunde Abstand hat. Sollte es sein, dass Microsoft hier dann nur Mails der letzten Stunde und nicht "älter als" abfragt? Aber selbst wenn dem so wäre, würde mindestens die eine Mail vom 13:03 genau in das Suchfenster passen. Selbst wenn wir nun noch UTC und eine Stunde Zeitverschiebung annehmen, sollte eine Mail gefunden werden.

Ich habe aktuell keine Information, warum in meinem Developer Tenant diese Abfrage keine Daten liefert.

Alert Policies

Wenn der Report aber eine gültige Antwort liefern sollte, dann können Sie über die "Alert policies" auch eine Alarmierung konfigurieren. Bis zum Okt 2021 musste ich dazu noch ins Microsoft Defender Portal (https://security.microsoft.com/alertpolicies) wechseln. Dort gibt es die Einstellung aber immer noch:


Quelle: https://security.microsoft.com/alertpoliciesv2

In den Einstellungen sind 2000 wartende Nachrichten der Default und weniger als 200 Messages sind nicht konfigurierbar.

Allerdings wollte Microsoft diese Einstellung schon seit Okt 2021 ins neue Exchange Admin Center verlagern. Dort ist eine passende Richtlinie schon vordefiniert und sogar aktiv.


Quelle  https://admin.exchange.microsoft.com/#/alerts/alertpolicydetails

Auch hier sind 2000 wartende Elemente die Standardeinstellung.


https://admin.exchange.microsoft.com/#/alertpolicydetails

Sie können Sie aber zumindest auf 50 reduzieren, was schon mal deutlich besser ist, als der Grenzwert von 2000 Nachrichten.. Zudem bin ich nicht sicher, ob alle "TenantAdmins" eine gültige Mailadresse haben oder in ihr Postfach schauen. Zudem ist es nur ein globales Limit, welches nicht pro Connector oder Zieldomain unterscheidet. Die Aussagekraft ist nach meiner Einschätzung doch arg eingeschränkt.

Keine API

Daher habe ich mich auf den Weg gemacht und nach einer API gesucht, über die ich z.B. mit PRTG solche Daten abfragen könnte. Leider gibt es in Graph zwar eine "Reporting API", die aber keine Informationen zum Messagetracking oder Warteschlangen in Exchange Online oder Defender bereithält.

Es gibt zwar schon die ein oder anderen Reports zu Exchange und Outlook aber keine zu Messagetracking oder "Pending Mails".

Message Tracking Monitoring

Wenn es von Microsoft keine offizielle API zur Report-Datenbank gibt, dann können wir uns immer noch dem Messagetracking bedienen. Eine einfache Abfrage der Mails zeigt mir schon, das hier Nachrichten "Pending" sind.

In der Detailansicht sehen wir auch die verschiedenen Zustellversuche von ca. 15 Minuten.

Im Portal kann ich auch nach dem Status filtern.

Aber in der PowerShell geht schon mehr und auch die Zeit kann ich da schon besser angeben. Ich könnte also z.B. mit folgender Abfrage alle Mails auflisten, die seit 30 Minuten oder mehr im Status "Pending" verharren.

Connect-ExchangeOnline

Get-Messagetrace `
   -Status Pending `
   -StartDate (Get-Date).adddays(-1) `
   -EndDate (Get-Date).addminutes(-30)

Die Ausgabe liefert die wartenden Nachrichten:

Das Ergebnis nun mit "Count" zu zählen und an ein Monitoring zu übergeben, ist dann nicht mehr weiter schwer und kann auch als App automatisiert werden. (Siehe dazu EXO PowerShell Automation). Wer noch etwas mehr Daten haben möchte, könnte die Ausgabe nach nach der Empfängerdomain aufschlüsseln. Allerdings enthält der Trace hier keine Information, über welchen Connector die Mail nun versendet werden würde.

Aktives Monitoring

Wenn es um eine Verbindung zwischen Exchange Online und eine speziellen Gegenstelle geht und die andere Seite mitspielt, kann auch ein aktiver "SMTP-Roundtrip"-Sensor umgesetzt werden. Sie könnten also z.B. alle 10 Minuten eine Testmail zur Gegenseite senden die darauf automatisch antwortet. Bleibt die Rückmeldung innerhalb der geforderten Zeit aus, dann können Sie von einer Störung ausgehen. Dies ist durchaus ein legitimer Ansatz aber erfordert natürlich eine Mitarbeit auf der Gegenseite.

Wobei dieses Monitoring auch seine Schwächen hat. Es wird die grundlegende Funktion der aktuell gewählten Verbindung ermittelt aber nicht jede mögliche Kombination. Da heute quasi alles "hochverfügbar" ist, kann problemlos ein Server ausfallen und die Funktion dennoch vorhanden sind. Erst bei weiteren Ausfällen kommt es dann zu einer Störung. Die Verfügbarkeit von Servern sollten sie schon individuell pro Server prüfen. Das ist aber in der Cloud nicht möglich. Siehe auch EXO Mailboxserver Insights

Zwischenstand

Auch wenn es in Exchange Online kein "Get-Queue"-Commandlet mehr gibt und auch nicht geben wird, so gibt es mehrere Wege, um den Versand von Nachrichten in Exchange Online zu überwachen. Die in Exchange Online eingebauten Reports wären für Administratoren eine erste Anlaufstation, wenn Sie denn funktionieren würden. Schade ist auch, dass Sie im Exchange Admin Center im Messagetracking nicht gezielt nach "Pending"-Nachrichten suchen können. Aber dafür gibt es dann die PowerShell.

Wer mag, kann sich nun eine App für die Exchange Online PowerShell einrichten (Siehe EXO PowerShell Automation) und damit z.B. alle 15 Minuten die Anzahl und das Alter der Mails im Status "Pending" ermitteln und in das eigene Monitoring überführen. Einen passenden Sensor für PRTG o.ä. habe ich aber noch nicht entwickelt.

Weitere Links