Exchange 2013 Safety Net Vs Exchange 2010 Transport Dumpster
Safety net and transport dumpster are two features of Exchange 2013 and 2010 respectively. In fact, safety net is an improved version of transport dumpster.
In this article, we deal with both and find out why Safety Net is better compared to transport dumpster.
Transport Dumpster
A feature that facilitates data recovery as well as provide for compliances in previous versions of Exchange, namely 2010 and 2007, is the Hub transport. All incoming and outgoing messages must go through the Hub transport before it reaches a mailbox.
Transport Dumpster is a feature of the Hub Transport of Exchange 2010 which limits the data losses during a lossy failover occurrence while mail delivery to a DAG. Transport dumpster was first seen in CCR and LCR mailboxes of exchange 2007.
One of the limitations of transport dumpster is that it can be used only for replicated mailboxes and not public folders or mailboxes that aren’t a part of the DAG. All Hub transport servers in the active directory sites of the DAG contains the transport dumpster queue for a particular mailbox and the dumpster is stored inside the mail.que file.
Exchange Server Transport Dumpster Settings
The lifetime of a message within the transport dumpster can be controlled using two attributes, namely,
1. MaxDumpsterSizePerDatabase (E2010) and MaxDumpsterSizePerStorageGroup (E2K7)
2. MaxDumpsterTime
As the name suggests, MaxDumpsterSizePerDatabase is the property that determines the size each storage group on the Hub Transport server can avail. (Default value=18 MB)
MaxDumpsterTime is obviously the duration of time for which the message is available within the dumpster. (Default 7days)
Exchange 2007 simply used to honour the attribute value and retain messages in the mail.que file till the specified limit reached. With Exchange 2010 the transport dumpster now receives feedback from the replication pipeline to determine which messages have been delivered and replicated. As an email makes it way a replicated mailbox database in a DAG, a copy is kept in the transport queue (mail.que) until the replication pipeline has notified the Hub Transport server that the transaction logs representing the message have been successfully replicated to and inspected by all copies of the mailbox database. After the logs have been replicated to and inspected by all database copies, they are truncated from the transport dumpster. This keeps the transport dumpster queue smaller by maintaining only copies of messages whose transactions logs haven’t yet been replicated.
In the event of a lossy failover (where the server or database goes offline due to some reason), the “MSExchangeRepl” (MSExchange replication service) will set the “DumpsterRedeliveryRequired” Attribute to True for the database which just became Active after the failover. This is done with the help of the “LastLogInspected” marker which is set on every database. Hub servers will then redeliver the missing messages from the mail.que file depending upon the MaxDumpsterSizePerDatabase or MaxDumpsterTime whichever is latest.
Presently active settings can be viewed using the following command
Get-TransportConfig |fl *Dumpster*
Exchange 2013 Safety Net
With the Exchange 2013, Microsoft replaced the transport dumpster with an improved and even better – Safety Net.
How Safety Net Works
Safety Net can be considered to be having two parts- Shadow Redundancy and Safety Net Redundancy.
While the safety Net keeps a redundant copy of a message after it is successfully processed, shadow redundancy keeps a redundant copy of the message which is in transit. All features of shadow redundancy like transport high availability boundary, primary messages, primary servers, shadow messages and shadow servers will be applicable to Safety Net.
The Primary Safety Net is applicable for a Mailbox server that holds the primary message before the Transport service completely processes the message. Once the processing of the message is over, the primary server moves the message to the Primary Safety Net from the active queue on the same server.
The Shadow Safety Net is applicable to the Mailbox server which holds the shadow message. Once the shadow server receives the information that the primary server has successfully processed the primary message, the shadow message is moved to the shadow safety net from the shadow queue on the server. For the Shadow Safety Net operation, shadow redundancy should be enabled, and shadow redundancy is enabled by default in Exchange 2013.
Similarities between Safety Net and Transport Dumpster
- Just as in a transport dumpster, safety Net is also a queue that is related to the Transport service on a Mailbox server
- It stores copies of messages already processed by the mailbox
- The duration for which the messages remain in the queue can be specified as in a dumpster. The default is 2 days
Why Safety Net is better than Transport Dumpster
- Safety Net is not just applicable for DAGs but also for Public Folders and other Mailboxes which are not a part of DAGs unlike a transport dumpster
- Due to the redundant nature of Safety Net it is never a single point of failure. Because of the availability of the Primary Safety Net and the Shadow Safety Net, even if the Primary Safety Net is unavailable for more than 12 hours, resubmit requests are forwarded to shadow resubmit and act as shadow resubmit requests, and messages are re-delivered from the Shadow Safety Net thus ensuring message delivery even if one of the safety net fails
- Another advantage of safety net is that safety net do net limit the message storage based on size but only by duration. For example if you set 12 days as the duration limit, the messages will be deleted only after 12 days of being in the inbox
- Safety Net does not require manual resubmission of messages. Message resubmission is initiated by the Active Manager component of the Microsoft Exchange Replication service
TransportConfig on an Exchange 2013 server looks like this:
Ratish Nair
MVP Exchange
Team @MSExchangeGuru
Keywords: exchange 2013 transport dumpster, exchange 2013 safety net, exchange 2013 email recovery
April 16th, 2013 at 1:17 am
Simple and clear..Thanks for the article..
April 19th, 2013 at 7:59 am
Very Good Article
April 21st, 2013 at 9:32 pm
[…] Exchange 2013 Safety Net Vs Exchange 2010 Transport Dumpster – […]
April 22nd, 2013 at 2:14 pm
[…] Exchange 2013 Safety Net Vs Exchange 2010 Transport Dumpster: https://msexchangeguru.com/2013/04/15/safetynet/ […]
April 23rd, 2013 at 2:34 am
Good one…!
Exchange team should have been also(not only @TechNet) named Dumpster to Safety Net on Exchange Transport Config attribute…also need to know why it is still there with the default size limit configured 😛
& Again I wonder if they want to guarantee message recovery how once can control size limit for disk space issues if any..!
April 26th, 2013 at 12:19 am
[…] Exchange 2013 Safety Net Vs Exchange 2010 Transport Dumpster […]
April 26th, 2013 at 10:15 am
Good one
February 20th, 2014 at 10:40 am
Good one. so anything needs to configured or it will be configured by default. In 2010 it is by default.
Thanks
Muthu
February 20th, 2014 at 12:05 pm
@Muthu
There will be a default config but you can change it.
Run the command to check the current config.
Get-Transportconfig | fl
May 21st, 2014 at 1:44 pm
I have a very simple Exchange 2013 deployment that doesn’t employ DAGs. The MAIL.QUE file grows excessively (now 38GB) and fills the system partition. I don’t see how this is an improvement.
October 24th, 2014 at 2:03 am
I have had the same issue.. Daily my mail.que file grows to about 30GB and then I have to recreate the file by pausing the Transport service, delete the files and start the transport service. I am running a DAG with Exchange server 2013 CU6 and still the issue continues. Has anyone resolved the mail.que file growing issue?
December 1st, 2014 at 10:36 pm
I finally moved the mail.que file to its own partition (there are articles telling how to do this) and made that partition 100GB. The file grows to about 70-75GB but it’s yet to fill the partition.
July 28th, 2016 at 12:22 pm
Good one 🙂
October 4th, 2016 at 10:20 pm
Good article. i came across issue like. In message tracking
Event ID :HADIRCT , HADISCARD, HARECIVE for inbound Application email.Mai flow is Sender–> Lotus Notes –> Exchange 2013 CU9 –> SAP application (SAP has feature to accpet email).
Question : any reason for Event ID generates ? is mail work properly?
Anyone did such configuration