Table of Contents
##
Expected knowledge level:
- Microsoft Exchange: Intermediate
Overview
The mail.que file temporarily stores all emails before it is delivered to the target. It is an Extensible Storage Engine (ESE) database (formerly known as a JET database), which means it is similar in architecture like an Exchange Mailbox Database, the edb file. A queue is a temporary holding location for messages that are waiting to enter the next stage of processing. Each queue represents a logical set of messages that a transport server processes in a specific order. Queues exist only on servers that have the Hub Transport server role or Edge Transport server role installed.
Let’s take a look at the other files residing in this location:
File | Description |
---|---|
Mail.que | This queue database file stores all the queued messages. |
Tmp.edb | This temporary database file is used to verify the queue database schema on startup. |
Trn*.log - Trntmp.log - Trnnnn.log |
This transaction log records all changes to the queue database. Changes to the database are first written to the transaction log and are then committed to the database. Trn.log is the current active transaction log file. Trntmp.log is the next provisioned transaction log file that is created in advance. If the existing Trn.log transaction log file reaches its maximum size, Trn.log is renamed to Trnnnnn.log, where nnnn is a sequence number. Trntmp.log is then renamed Trn.log and becomes the current active transaction log file. |
Trn.chk | This checkpoint file tracks the transaction log entries that have been committed to the database. This file is always in the same location as the mail.que file. |
Trnres00001.jrs Trnres00002.jrs |
These reserve transaction log files act as placeholders. They are only used when the hard disk drive that contains the transaction log runs out of space to stop the queue database cleanly. |
There is currently no build-in option to “shrink” the mail.que to a smaller file. The only way to get a smaller mail.que would be to rebuild it by geting rid of the old mail.que file and get a new one without any downtime, in multiple hub transport servers enviroment to process emails so, no emails will be processed at the time of this change.
Figure A: mail.que is 140 GB in Size.
Rebuilding the mail.que via the following steps:
- Run the following PowerShell command within your Exchange Management Shell and make note from the count of messages on the server:
1
Get-Queue
- Now goto services.msc and Pause (NOT STOP!!) the “Microsoft Exchange Transport” service or use PowerShell:
1
Suspend-Service -Name "Microsoft Exchange Transport"
- Run again the following Run the following PowerShell command within your Exchange Management Shell (Repeat till queues are empty):
1
Get-Queue
- If the queues are empty (double check that to avoid losing emails) stop the “Microsoft Exchange Transport” service
1
Stop-Service -Name "Microsoft Exchange Transport"
-
Move all files inside the C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data\Queue folder into a backup folder (e.g. on another HD)
- Start the “Microsoft Exchange Transport” service
1
Start-Service -Name "Microsoft Exchange Transport"
The Exchange Server will rebuild the files now we moved from the queue folder
- Run again following PowerShell command within your Exchange Management Shell make sure that the queues & mail flow are working as expected.
1
Get-Queue
Figure B: mail.que is 8 mb in Size.
You should see that the messages would have started getting delivered. Now you can backup or safely delete the old mail.que file.
In the example above, you can see that the mail.que is already 140 GB in size. Below are a couple settings you should check which might cause the issue.
- Check the SafetyNetHoldTime value. This parameter specifies how long a copy of a successfully processed message is retained in Safety Net. Unacknowledged shadow copies of messages auto-expire from Safety Net based on adding the values of the SafetyNetHoldTime parameter and the MessageExpirationTimeout parameter
Run the PowerShell command within your Exchange Management Shell
1
Get-TransportConfig | Select SafetyNetHoldTime
The default value here is “2.00:00:00” (2 days). If you wish to reset that back to the default value run:
1
Set-TransportConfig -SafetyNetHoldTime 2.00:00:00
- Check the ShadowMessageAutoDiscardInterval. This parameter specifies how long a server retains discard events for shadow messages. A primary server queues discard events until queried by the shadow server. However, if the shadow server doesn´t query the primary server for the duration specified in this parameter, the primary server deletes the queued discard events.
Run the PowerShell command within your Exchange Management Shell
1
Get-TransportConfig | select ShadowMessageAutoDiscardInterval
The default value here is “2.00:00:00” (2 days). If you wish to reset that back to the default value run:
1
Set-TransportConfig -ShadowMessageAutoDiscardInterval 2.00:00:00
- The PipelineTracingEnabled parameter specifies whether to enable pipeline tracing. Pipeline tracing captures message snapshot files that record the changes made to the message by each transport agent configured in the transport service on the server. Pipeline tracing creates verbose log files that accumulate quickly.
Run the PowerShell command within your Exchange Management Shell
1
Get-TransportServer | select Name,PipelineTracingEnabled
The default value here is “$false”. If you wish to reset that back to the default value run:
1
Set-TransportServer -Identity Exchange01 -PipelineTracingEnabled $false