MSExchangeGuru.com

Learn Exchange the Guru way !!!

 

Exchange hub transport “Mail.que” file large in size

I had to deal with a “huge” mail.que file this morning and thought of letting you know how to handle similar issues.So, here is the scenario

  • Came to know about this issue only when SCOM alerted for a low disc space
  • On one of the hub transport servers, the mail.que file reached to 148GB (unbelievable)

A lil about the mail.que file:

The mail.que file temporarily stores all emails before it is delivered to the target. It is an ESE database which means it is similar in architecture like an Exchange mailbox database, the edb file.

As per a TechNet article

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:

Trn.chk – Checkpoint file like E0x.chk in exchange

Trn.log – The transaction log file which is getting committed now. Similar to E00.log in exchange

Trntmp.log – The next transaction log file which is created in advance.

Trnnnn.log – Next transaction log file created when Trn.log reaches its maximum size.

Trnres00001.jrs – First reserve log file. Only used when the hard disk drive that contains the transaction log runs out of space to stop the queue database cleanly

Trnres00002.jrs – Second Reserve log file.

Temp.edb – Temp database used to verify database schema on start-up.

Back to the issue:

You need to know 2 important terms before we proceed since this issue could have caused due to a combination of both:

  • PipelineTracingEnabled: This is used for troubleshooting purposes and is not enabled by default.
  • MaxDumpsterSizePerStorageGroup: This is for Exchange 2007. The maximum size of the transport dumpster queue per storage group. This is a universal setting for all storage groups; you can’t set variable sizes for each storage group. The recommended size is 1.5 times the maximum message size that can be sent. For example, if the maximum size for messages is 10 megabytes (MB), you should configure the MaxDumpsterSizePerStorageGroup parameter with a value of 15 MB. Read more here

You can use the cmdlet: Get-TransportServer | fl to get these details.

In my case, tracing was enabled and the dumpster was specified to be 50GB.

Enough talking and lets delete it now

This is the suggested way to get rid of the old mail.que file and get a new one without any downtime. I proceed under the assumption that you have multiple hub transport servers to process emails so, no emails will be processed at the time of this change. This
should take about less than a minute. I will call the Hub transport server HUB01. Remember that steps 6-8 are very important and will ensure none loses emails

  1. Login to HUB01
  2. Take a look at the size of the mail.que file


  3. Open exchange management shell and run “Get-TransportServer ” HUB01″ |fl
  4. Here, look for PipelineTracingEnabled. This should be set to False. If not, run

    Set-TransportServer HUB01 -PipelineTracingEnabled $False

  5. Now run “Get-TransportConfig” and ensure that

    MaxDumpsterSizePerStorageGroup is in MB’s and not GB’s

    MaxDumpsterTime : 7.00:00:00

    If not, run

    Set-TransportConfig -MaxDumpsterSizePerStorageGroup <size> -MaxDumpsterTime <timespan>

  6. Now run “Get-Queue” and take a look at the count of messages in HUB01
  7. Goto services.msc and Pause the Microsoft Exchange Transport service
  8. Again, run “Get-Queue” and ensure all pending messages are “zeroed” out
  9. Once messages pending becomes zero, stop the Transport service
  10. Move the mail.que file and all others to a new folder in the same location
  11. Start the Transport service
  12. Take a look at the queue again
  13. You should see that messages would have started getting delivered
  14. Now you can backup or safely delete the old mail.que file

Ratish Nair
MVP Exchange
Team@ MSExchangeGuru

Keywords: Delete mail.que file, delete large mail.que file, mail.que file large in size, huge mail.que file in exchange, exchange 2007 mail.que file, mail.que file too big

21 Responses to “Exchange hub transport “Mail.que” file large in size”

  1. Richard Mills Says:

    Once you do that (In my case I made a copy of the Queue folder) is there any way to open the mail.que offline, to see what messages got deleted when I recreated the queue?

    Thanks

  2. Ratish Sekhar Says:

    Once you pause the service and run Get-queue, you should see no messages are pending and thats when you delete stop the Transport service and delete the file. The size increase for mail.que file is because of the extra work done by the servers like tracing etc.

  3. Richard Mills Says:

    Thank you for your kind response.

    I do have everything working again, but management wants to know if I can tell them what exact messages were deleted when I recreated the queue. In retrospect, I maybe should have taken screen shots of the queues in exchange before I recreated the queues, but we are a good sized law firm with 1000 users and mail was complete stopped and the objective was to get it running again as soon as possible.

    I thought maybe some sort of utility could possibly open the mail.que file I saved, so I could see what messages were there.

    Richard

  4. Ratish Sekhar Says:

    Well… I will get back to you on this…sure..

  5. Sai Prasad Says:

    Richard,
    Transport database is similar to that of an exchange database file as both use Extensible Storage Engine (ese) mechanism. Difference between the 2 is, former saves all messages in every queue in mail.que file and latter saves all mailbox information of that store in .edb file.

    so when you want to see a sent items of a particular user from a .edb file, you go about restoring the database and then exmerge the sent items of that partucular user from the .edb file. Same theory applies to transport database as well with a little difference.

    Good God, you saved a copy of the mail.que file before renaming 🙂
    Take that copy of transport database to another TEST HUB server or even in the same Exchange Org if you have another HUB server and recover the database using eseutil. The Test HUB or the 2nd HUB in your Org will be the target HUB server acting to recover the old mail.que.

    Let’s say you do it in a TEST HUB server where the email address policy is richard.org but the actual domain of your Org is lawfirm.Org.
    After you perform the recovery using eseutil /r, and /d, replace the mail.que from the Target HUB with this recovered mail.que transport database(while doing this Transport service should be in stopped state)..Now start the transport service.

    You will now see mails queueing up in Unreachable destination or a few may be in Remote Delivery queue.
    Suspend the Queues and export the messages using the command as below.,
    Get-Message -Queue “Unreachable” | Export-Message -Path “”
    Get-Message -Queue “Remote Delivery Queue” | Export-Message -Path “”

    Above commands will export the message in .eml file which will enable you to see “what exact messages were deleted when I recreated the queue” which your management wants to know.

  6. Igor T Says:

    Ratish,
    As it is already asked, what is the destiny of those messages that were in retry state in initial database when Tranport Service was paused?
    It seems to me that the best solution is to export those messages to file system before stopping the service with suspend-message, export-message (and assembly commands in case of Exchange 2010) and then resubmit them in Replay directory as soon as service started and new database is created. In this case, you will not loose any messages and it is up to Exchange to deliver or expire them if they are targeted to unreachable destination.

  7. Kanta Prasad Says:

    Hi Igor,

    AS Per the comment by”Sai Prasad” as <<>>”

    YOu can export these emails to PST as well.

  8. Oleg Says:

    Thank you for you article! I have the same issue with my Exchange 2010. Mail.que file is very big (about 90 GB) on all of my transport servers. I have checked PipelineTracingEnabled option, it’s set false. And there is no MaxDumpsterSizePerStorageGroup option for Exchange 2010.

    What is else can cause growing of queue database file? I will be very appreciate you for answer.

  9. Jawahar Says:

    We are facing same issue. We followed same steps and got enough free space. But again after 3 days mail.que file size starts growing.

  10. Ehtisham Qadir Says:

    Ratish – I recently migrated our client Exchange 2003 to Exchange 2010. Now I am migrating public folders that are about 320GB. It’s been 2 days and only 45 GB has been transfered so far but, I noticed mail.que size is about 88GB. Is this because of PublicFolder migration? If so deleting this file would cause any issue with Public Folders? I haven’t seen any mail issues since mailbox migration.
    I would really appreciate for your reply.

  11. Prabhat Nigam Says:

    Hi Oleg,

    How did your PF migration go?
    Let me know if any PF migration issue on PF migration blog.
    http://msexchangeguru.com/2013/04/18/exchange2013-public-folders/

  12. Exchange 2007: Eventi 490 e 17019 | DevAdmin Says:

    […] Exchange hub transport “Mail.que” file large in size […]

  13. Exchange 2007: Eventi 490 e 17019 | DevAdmin Blog Says:

    […] Exchange hub transport “Mail.que” file large in size […]

  14. David Burkhart Says:

    I have followed these instructions and learned that my MaxDumpsterSizePerStorageGroup is set appropriately (max message size 25MB; Dumpster 35MB and 7 days), and there is no Pipeline Tracing enabled. However, my mail.que file keeps filling the 40GM partition I have just for this purpose. I have no DAGs; just a single CAS and a single, virtual MBX/UM/HUB server. This mail.que file “working as designed” has become a HUGE maintenance issue, causing mail interruptions when the volume fills (working on alerts) and downtime when I have to proactively clean it.

    What is the solution?! Thank you for your time and assistance!

    David

  15. Asif Says:

    Do we need to move or delete all file including .edb file as well before we restart the transport service? or only mail.que file

    Thanks
    Asif

  16. Prabhat Nigam Says:

    You have to move all files from queue folder.

  17. Don Says:

    Great post!
    worked awesome for me

  18. Chrisc Says:

    Hi Guys, I have 4 Exchange 2013 servers separated on two countries (2 per country)
    A couple of them are increasing size of mail.que file (in the same country too)
    I’m deleting mail.que file one time for week, they reach 80GB…
    On the others two servers stil on 15GB.
    Checking the configuration of the TransportServer (Get-TransportConfig) I receive this output.

    MaxDumpsterSizePerDatabase : 18 MB (18,874,368 bytes)
    MaxDumpsterTime : 7.00:00:00

    Note: we have not DAG configured.

    Is there a way to disabled this tracking to prevent mail.que reaches incredible sizes?

    Thanks a lot!
    Chrisc

  19. Prabhat Nigam Says:

    @Chrisc,

    If your message size is 12MB then your MaxDumpsterSizePerDatabase is fine.

    safetynet might be holding some emails in Exchange 2013.

    Question:
    Do you have a DAG?
    Did you configure lag copy?
    Did you stretch the AD site to the 2nd country or it is 2 AD sites.

  20. Chrisc Says:

    @Prabhat Hi!
    thx a lot for answer.
    DAG is not configured.
    lag copy is not configured
    we have 2 AD site, and issue is only with CL servers.
    MaxDumpsterSizePerDatabase is 18MB
    I just change -SafetyNetHoldTime 1.00:00:00 -MaxDumpsterTime 3.00:00:00 with Set-TransportConfig but mail.que after 3 days is at 62GB each.
    i’m thinking to change to 1 day MaxDumpsterTime and reduce MaxDumpsterSizePerDatabase to 15MB

    Any idea?
    many thx again

  21. Exchange Transport Service won't start Says:

    […] There are a few possible resolutions to this problem.  Through some Google searches one solution I found is that you can attempt to repair the corruption in the queue databases by running the database through ESE util.  There is no guarantee this will work and it can potentially take a lot of time, depending on the size of your queue database. There is some good information here about the mail queue and how it works. […]

Leave a Reply

ad

Categories

Archives