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

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

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

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.

Hier wechselt man dann zu Sicherheitsnetz.

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

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.

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.

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.

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.