Tags: Exchange, Troubleshooting, E-Mail
Mail.que ist eine temporäre Warteschlage für Nachrichten, welche auf die nächste Verarbeitungsphase oder ihre Zustellung warten. Abhängig von ihrer Konfiguration können sich dort größere Datenmengen ansammeln, so dass man sie löschen oder auf ein anderes Laufwerk umziehen 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
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-Warteschlangen.
Durch die Übermittlungswarteschlange 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 Transportdienstes 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 Betriebssystem zu lösen.
Die Konfigurationsdaten 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.
Täglich Know-how für IT-Pros mit unserem Newsletter
Roland Eich ist gelernter Fachinformatiker für Systemintegration und in der IT seit über 14 Jahren zu Hause. Roland deckt aufgrund seiner Erfahrungen ein breites Spektrum der Microsoft-Produktpalette ab.Zudem besitzt er verschiedene Zertifizierungen (MCITP, MCSA und MCSE, ITIL, PRINCE2).
// Kontakt: E-Mail //
Verwandte Beiträge
- Vermisste E-Mails in Microsoft Exchange nachverfolgen
- Outlook kann Mail-Adresse nicht finden: legacyExchangeDN als X.500-Adresse in Exchange hinzufügen
- Nachrichtenfluss von Exchange Online verfolgen im Security & Compliance Center
- Outlook: Aus freigegebenem Postfach versandte Mails landen nicht im Ordner "Gesendete Elemente"
- Outlook: Ordner-Reihenfolge in einer Shared Mailbox ändert sich willkürlich
Weitere Links
3 Kommentare
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)?
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
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