Exchange 2016 DAG: Warteschlange wird zu groß (mail.que)

In einer Exchange 2016 DAG ist kürzlich das Problem aufgetreten, dass die mail.que, also die Exchange Warteschlange, auf über 60 GB gewachsen ist. Bei weiteren Wachstum der mail.que wäre unweigerlich die Festplatte vollgelaufen, in diesem Fall hätte der betreffende Exchange Server keine Mails mehr zustellen können. Auch auf den weiteren Exchange Servern innerhalb der DAG ließ sich das Wachstum beobachten.

Hier mal ein Screenshot eines betreffenden Servers:

Exchange 2016 DAG: Warteschlange wird zu groß (mail.que)

Die Warteschlangendatenbank (mail.que) wird in der Standardeinstellung in folgendem Verzeichnis gespeichert:

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

Die Prüfung der Queues mittels Exchange Management Shell ergab allerdings, dass sich nur wenige Mails in den Warteschlangen befinden:

Exchange 2016 DAG: mail.que wird zu groß (Warteschlange)

Als Ursache für das Wachstum der mail.que hat sich das Exchange Feature “Safety Net” rausgestellt. In diesem Fall wurde die Standardeinstellung von 2 Tagen auf 14 Tage (Maximum) angehoben. In diesem Fall wurde also eine Kopie aller zugestellten Nachrichten für 14 Tage innerhalb der Warteschlange durch Safety Net aufbewahrt.

Sicherlich ist Safety Net ein hilfreiches Exchange Feature, ob nun aber jede Mail 14 Tage lang innerhalb der Queue aufbewahrt werden muss, nur für den Fall das eine Datenbank ausfällt und aus der Datensicherung wiederhergestellt werden muss, sei mal dahin gestellt. Hier war man wohl in der Vergangenheit etwas übervorsichtig.

Damit die Warteschlangendatenbank nicht wieder derartige Größen erreicht, wurde die Standardeinstellung wiederhergestellt (2 Tage). Hier einmal das entsprechende Vorgehen:

Mit dem folgenden Befehl kann geprüft werden, ob SafetyNet aktiviert und wie lange die Aufbewahrungszeit ist:

1
Get-TransportConfig | select ShadowRedundancyEnabled,SafetyNetHoldTime

Exchange 2016 DAG: mail.que wird zu groß (Warteschlange)

Um die Standardeinstellung von 2 Tagen wiederherzustellen, kann der folgende Befehl verwendet werden:

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

Exchange 2016 DAG: mail.que wird zu groß (Warteschlange)

Die Warteschlangendatendank (mail.que) wird nun allerdings nicht automatisch kleiner. Wenn die mail.que also zu groß ist, hilt nur die Datenbank zu löschen. Damit werden auch die Mails gelöscht die sich im Safety Net befinden und Mails die sich zum Zeitpunkt in der Warteschlange befinden. Man sollte also darauf achten, dass aus Versehen keine Mails von Benutzern aus den “normalen” Warteschlangen gelöscht werden.

Die Vorgehensweise zum Löschen der mail.que ist wie folgt:

Zuerst wird der Dienst “Microsoft Exchange-Transport” gestoppt

Exchange 2016 DAG: mail.que wird zu groß (Warteschlange)

Nun kann das komplette Verzeichnis “Queue” gelöscht werden (oder zunächst zur Sicherheit umbenannt werden):

Exchange 2016 DAG: mail.que wird zu groß (Warteschlange)

Jetzt kann der Dienst “Microsoft Exchange-Transport” wieder gestartet werden. Das Verzeichnis “Queue” und dessen inhalt wird automatisch wieder angelegt.

4 Kommentare zu “Exchange 2016 DAG: Warteschlange wird zu groß (mail.que)”

  1. Kleiner Tipp. einfach Löschen ist möglich aber ich würde vorher die Queue „leerlaufen“ lassen. Dazu muss man einfach den Dienst auf „anhalten“ (nicht stoppen) stellen. Dann nimmt er nichts mehr an und man wartet, bis die Queue leer ist.

    Ein anderer Trick: Dienste beenden und die mail.que einfach defragmentieren. Das geht mit ESEUTIL genau wie mit einer EDB-Datei. Es ist nämlich auch nur eine verkappte EDB-Datei..

    1. Hi Fank C,
      den Dienst anzuhalten ist ein guter Tipp. Das Defragmentieren wird zumindest für Postfachdatenbanken nicht mehr supported, ich nehme an, dass für die mail.que dies ebenfalls gilt? Beim Defragmentieren dürften auch alle Mails des Safety Net in der Datenbank bleiben, daher dürfte die mail.que auch nach der Defragmentierung nicht nennenswert kleiner werden.

      Gruß, Frank Z.

  2. die alten Mails des SafetyNet sollten nach Ablauf (also wenn man von 14 Tage auf 2 Tage setzt beim nächsten Wartungslauf gelöscht sein. das gibt dann Whitespace in der Datenbank). Die werden dann beim Defrag entfernt.
    Mit dem Löschen entfernst du alle Mails im SafetyNet. also auch die, die jünger als die Haltezeit (2 Tage) sind.
    Wobei man schon löschen kann, wenn in der Zeit die Mails im Ziel schon zugestellt sind. Es heißt ja „SafetyNet“ und die Mails sind ja noch woanders. Man sollte das dann aber eben nicht auf allen Server zugleich tun, sondern vielleicht etwas Zeit (2 Tage ?) vergehen lassen :-)
    Letztlich ist alles irgendwie nicht falsch. Ich „pausiere“ den Dienst gerne damit er nicht mehr annimmt und schau mit Get-Queue nach, dass alle aktiven Mails weg sind. Dann „kann“ man den Dienst auch stoppen und die DB (und die Logfiles vielleicht auch) löschen.
    Es lohnt sicher aber auch ein Blick in der Eventlog, ob die OnlineDefragmentation überhaupt erfolgreich ist und sich z.B. nicht mit dem Backup überschneidet. Sonst passiert es vielleicht wieder

    1. Hi Frank C,
      stimmt, dann müsste man noch 2 Tage warten bis die „alten“ Mails aus der DB gelöscht werden. Wenn man noch ausreichend Speicher frei hat, wäre dies auch eine Lösung. Eine weitere Möglichkeit wäre die Component States zu verwenden und den Transport Dienst in den Wartungsmodus zu schalten.
      Beste Grüße,
      Frank Z

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.