An Exchange 2016 DAG recently encountered the problem that the mail.que, i.e. the Exchange queue, had grown to over 60 GB. If the mail.que had continued to grow, the hard disk would inevitably have filled up, in which case the Exchange server in question would no longer have been able to deliver mails. The growth could also be observed on the other Exchange servers within the DAG.
Here is a screenshot of the server in question:
The queue database (mail.que) is saved in the following directory by default:
| 1 | C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data\Queue
|
However, a check of the queues using the Exchange Management Shell revealed that there are only a few mails in the queues:
The reason for the growth of mail.que is the Exchange feature "Safety Net" has been set. In this case, the default setting of 2 days was increased to 14 days (maximum). In this case, a copy of all delivered messages was kept in the queue by Safety Net for 14 days.
Safety Net is certainly a helpful Exchange feature, but whether every mail has to be kept in the queue for 14 days just in case a database fails and has to be restored from the data backup is open to question. In the past, people have probably been a little overcautious here.
The default setting (2 days) was restored to prevent the queue database from reaching such sizes again. Here is the corresponding procedure:
The following command can be used to check whether SafetyNet is activated and how long the retention time is:
| 1 | Get-TransportConfig
| select ShadowRedundancyEnabled,SafetyNetHoldTime
|
To restore the default setting of 2 days, the following command can be used:
| 1 | Set-TransportConfig
-SafetyNetHoldTime
2:00:00:00
|
However, the queue database (mail.que) does not automatically become smaller. So if the mail.que is too large, the only thing that helps is to delete the database. This also deletes the mails that are in the Safety Net and mails that are in the queue at the time. You should therefore make sure that no mails from users in the "normal" queues are deleted by mistake.
The procedure for deleting mail.que is as follows:
First, the "Microsoft Exchange Transport" service is stopped
You can now delete the entire "Queue" directory (or rename it first to be on the safe side):
The "Microsoft Exchange Transport" service can now be restarted. The "Queue" directory and its contents are automatically created again.
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.