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:
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:
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 |
Um die Standardeinstellung von 2 Tagen wiederherzustellen, kann der folgende Befehl verwendet werden:
|
1
|
Set-TransportConfig -SafetyNetHoldTime 2:00:00:00 |
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
Nun kann das komplette Verzeichnis “Queue” gelöscht werden (oder zunächst zur Sicherheit umbenannt werden):
Jetzt kann der Dienst “Microsoft Exchange-Transport” wieder gestartet werden. Das Verzeichnis “Queue” und dessen inhalt wird automatisch wieder angelegt.
Ich administriere nunmehr unter anderem Exchangesysteme seit ca. 18 Jahren (bin alt..)! Irgendwann in dieser Zeit bin ich auf „Frankysweb.de“ aufmerksam geworden.
Ich wollte einfach mal „DANKE“ für die bereitgestellten Informationen sagen, welche mir schon mehrmals signifikant bei Problemstellungen weitergeholfen haben!
Braucht sich vor Authoritäten wie P. Cunningham und T. Redmond nicht zu verstecken. Punkt!
Mit besten Grüßen
Alex
Unsere „mail.que“ auf unseren neuen EX2016ern ist nun auch mal vollgelaufen :-)
Danke für die tolle Anleitung zur Bereinigung.
Eine Frage noch, wäre es möglich, auch mal das zugehörige Thema „ReplayLagTime“ der Datenbanken zu beleuchten.
Was macht Sinn, welche Bedeutung hat dies?
Im Standard scheint nichts eingestellt zu sein.
Bei uns steht „Replaylagtime 00:00:00“ bei den angelegten DBs.
Eine übersichtliche Abfrage ist ja wie folgt möglich:
Get-MailboxDatabase | %{$_.DatabaseCopies | ft Identity,ReplayLagTime }
Guten Morgen,
super toller Beitrag, dieser hat mir wirklich sehr geholfen.
Wo ich allerdings immer Bauchschmerzen bekomme ist bei dem Befehl Set-TransportConfig -SafetyNetHoldTime 2:00:00:00
Hier ist im Screenshot eine Warnung zu sehen, gleiche Warnung taucht auch bei mir auf.
Was ist denn das genau, was der Exchangeserver uns da mitteilen will? Welche Auswirkungen mag das haben? Der Exchange gibt solche Warnungen ja nie zum Spaß aus.
Hast du da ggf. nochmal Infos für uns?
Grüße
Marcus
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
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
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..
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.