Exchange mail.que wird zu groß: Warteschlange löschen und auf anderes Laufwerk umziehen

    Exchange mail.queMail.que ist eine temporäre Warte­schlage für Nach­richten, welche auf die nächste Ver­arbeitungs­phase oder ihre Zu­stellung warten. Ab­hängig von ihrer Konfi­guration können sich dort größere Daten­mengen ansammeln, so dass man sie löschen oder auf ein anderes Lauf­werk um­ziehen muss.

    Die Warteschlange nutzt eine eigene Datenbank namens mail.que, welche sich per Default am Installationsort des Exchange-Servers befindet, beispielsweise unter

    C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data\Queue

    Speicherort für die Mail-Warteschlange von Exchange

    Ihr Inhalt kann unter anderem mit der Exchange-Toolbox eingesehen werden.

    Inhalt der Mail-Queue inspizieren mit der Exchange-Toolbox

    Da es sich in meinem Beispiel nur um ein Testsystem handelt, ist hier relativ wenig zu sehen.

    Es gibt verschiedene Arten von Warteschlagen, aber am häufigsten zu tun hat man als Admin mit Übermittlungs- und Schatten- bzw. Shadow-Warte­schlangen.

    Durch die Übermittlungs­warte­schlange geht jede Nachricht, welche gesendet oder empfangen wurde.

    Die Shadow-Warteschlange, auch Shadow-Redundanz genannt, wurde mit Exchange 2010 eingeführt. Sie hält Kopien der Nachrichten bereit, bis diese dem jeweiligen Postfach zugestellt wurden.

    Sie setzt mehrere Maibox-Server voraus, die entweder zur gleichen Database Availability Group (DAG) oder zum selben AD-Standort gehören müssen. Die Shadow-Redundanz ist für Standalone-Server somit nicht verfügbar. Weitere Informationen hierzu sind hier nachzulesen.

    Problem großer Datenmengen in der Warteschlange

    In einigen Fällen kann es vorkommen, dass die Mail.que stark wächst und mit der Zeit den Plattenplatz auf Laufwerk C vollständig beansprucht. Ein gutes Monitoring ist unerlässlich, um zu verhindern, dass die C-Partition vollläuft und der Exchange-Server seine Arbeit einstellt.

    Einer solchen Entwicklung kann man aber auch durch verschiedene Maßnahmen vorbeugen. Die einfachste Lösung in Zeiten der Virtualisierung ist es, die jeweilige Partition auf dem die Mail.que liegt, zu erweitern.

    Zusätzlich macht es aber Sinn, sich die Konfiguration, welche die Mail.que so anwachsen lässt, näher anzuschauen. Dabei sollte man folgende Einstellung kontrollieren:

    In der Exchange ECP klickt man unter Nachrichtenfluss => Empfangsconnectors in der Symbolleiste auf die 3 kleinen Punkte ganz rechts, um dort die Einstellungen für Organisationstransport auszuwählen.

    Einstellungen für Organisationstransport in der Exchange-Konsole öffnen

    Hier wechselt man dann zu Sicherheitsnetz.

    Die Aufbewahrungsfristen von Nachrichten in der Warteschlange lassen sich über die GUI anpassen

    Das Sicherheitsnetz bzw. der Schalter Aufbewahrungszeit für Sicherheitsnetz gibt an, wie viele Tage eine E-Mail aufbewahrt werden soll. Der Default-Wert liegt bei 2 Tagen. Aus verschiedenen Gründen kann dieser Wert auch höher sein und sorgt dann gerade bei stark wachsenden Umgebungen dafür, dass die Mail.que sehr groß wird. Zum Thema Sicherheitsnetz gibt es hier von Microsoft weitere Informationen.

    In unserem Fall wird also eine Kopie aller Nachrichten für 7 Tage in der Warteschlage vorgehalten, bevor sie gelöscht wird. Den Wert kann man nun entweder wie oben ersichtlich in der GUI oder per PowerShell ändern.

    Die aktuellen Einstellungen lassen sich mit diesem Befehl abrufen:

    Get-TransportConfig | select ShadowRedundancyEnabled, SafetyNetHoldTime

    Einstellungen für die Warteschlange über PowerShell abfragen

    Mit folgendem Aufruf setzt man den Wert wieder auf 2 Tage zurück:

    Set-TransportConfig -SafetyNetHoldTime 2:00:00:00

    Das Problem ist nun, dass diese Datenbank wie jede andere Exchange-Datenbank auch, nach dieser Aktion nicht von selbst kleiner wird. Das erreicht man nur, indem man sie löscht und neu anlegt. Dabei ist zu beachten, dass durch diese Aktion alle Mails in der Warteschlange verloren gehen.

    Damit sich die Mail.que löschen lässt, muss man zuerst den Exchange-Transportdienst stoppen, so dass es keinen Zugriff mehr auf diese Datenbank gibt. Danach kann man das Queue-Verzeichnis umbenennen (als letzte Sicherheit) oder löschen.

    Nach dem erneuten Start des Transport­dienstes sollte das Verzeichnis von selbst angelegt werden.

    Warteschlange auf anderes Laufwerk verschieben

    Beim Aufräumen der Warteschlange würde es sich eigentlich anbieten, die Mail.que auf ein anderes Laufwerk zu verlegen, um diese vom Betriebs­system zu lösen.

    Die Konfigurations­daten für den Speicherort der Datenbank sind in EdgeTransport.exe.config zu finden. Auch für Änderungen in dieser Datei muss man den Transportdienst beenden.

    Die Datei EdgeTransport.exe.config enthält unter anderem die Einstellungen für den Speicherort der Mail-Queue.

    Folgende Einträge müssen geändert werden:

    <add key="QueueDatabasePath" value="<LocalPath>" />
    <add key="QueueDatabaseLoggingPath" value="<LocalPath>" />

    Da ich ein eigenes Laufwerk für diesen Zweck angelegt habe, setze ich den Eintrag so, dass er dorthin zeigt.

    Einstellungen für QueueDatabasePath und QueueDatabaseLoggingPath auf ein anderes Laufwerk ändern.

    Nach dem Speichern und Schließen der Datei kann man den Transportdienst wieder starten.

    Hinweis: Wenn man zum Beispiel nur das Laufwerk E:\ ohne einen spezifischen Ordner angibt, dann mag Exchange dies überhaupt nicht. Der Transportdienst läuft dann nicht mehr korrekt und es werden keine Mails verschickt oder empfangen.

    Das Vorgehen war erfolgreich, wenn in dem Queue-Ordner die neue Mail.que inklusive Logs angelegt werden und das alte Queue-Verzeichnis sich ohne Problem löschen lässt.

    Nach dem Start des Transportdienstes legt Exchange die mail.que im neuen Verzeichnis an.

    Natürlich kann man bei diesem Vorgehen auch die alte Mail.que an den neuen Speicherort kopieren, es ist also nicht zwingend notwendig, eine neue Mail.que anlegen zu lassen.

    3 Kommentare

    Martin Feuerstein sagt:
    24. Juni 2020 - 18:28

    Wie verhält sich der Eintrag in der config/XML-Datei bei einem kumulativen Update? Wird diese, wie andere XML-Dateien, bei CUs zurückgesetzt (da war mal was mit Mailgröße bei ActiveSync)?

    Roland sagt:
    26. Juni 2020 - 14:23

    Hallo Herr Feuerstein,
    nein die Daten werden nicht nach einem CU Update überschrieben.
    Habe es am Ex2019ner CU6 getestet, da passte alles.
    Grüße
    Roland Eich

    Patrick A. sagt:
    28. Juni 2020 - 10:22

    Ich verstehe nicht, warum Microsoft, aber auch hier im Beitrag nicht auf das $ExScripts / Move-TransportDatabase.ps1 eingegangen wird. Damit lässt sich das gewünschte Ergebnis ohne viel Aufwand und Datenverlust in wenigen Sekunden automatisiert erzielen.
    Beste Grüße
    Patrick