How the Transport Dumpster works with a CCR cluster


Transport Dumpster is a new feature of Exchange Server 2007 Hub Transport servers through which the transport can defer the deletion of certain emails in their queues. The condition for an email to be retained in the transport dumpster is that at least one of the recipient’s mailboxes must resides on a CCR mailbox server. This retained email can later be re-delivered if necessary. The amount of mail retained in the queues is a Organization wide setting on the Transport Settings container.


This only works with mailboxes on CCR, with CCR the replication of mailbox data from the active node to the passive is asynchronous and will always lag slightly behind the active node. In the event of a failure which precludes the most recent logs from being replicated over, the transport dumpster can be used to re-deliver the recent mail as this should constitute the majority of the changes in the database. Transport Dumpster operates on the hub transports within an Active Directory Site. When a lossy CCR failover occurs, a request will be made to the Hub Transport server to redeliver the lost mail. Please note that the Transport Dumpster is holding the mail that has already been delivered, any pending mail will be held in the local submission.

The Transport Dumpster is configured by default. You can view the transport dumpster settings by running get-TransportConfig. There are two important setting when configuring the transport dumpster:


MaxDumpsterSizePerStorageGroup – 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.

MaxDumpsterTime – The amount of time an email will remain in the transport dumpster queue. This is the time a message will be retained if it is not forced out for space reasons (MaxDumpsterSizePerStorageGroup). It is recommended that this be set to 7 days.


If either of the above is set to 0, the Transport Dumpster will be disabled.

The default setting for the Transport Dumpster are:


MaxDumpsterSizePerStorageGroup: 18 MB

MaxDumpsterTime: 7 days (7.00:00:00)


If either the size limit or time limit is hit, mail will be removed from the queue by order of first in, first out.

You should take into account that the Transport Dumpster will require additional storage space on the Hub Transport server for the Transport Dumpster queue. The maximum size the queue is the MaxDumpsterSizePerStorageGroup times the number of CCR Storage Groups.

To configure the Transport dumpster, please see the sample commands below.


[PS] C:\>get-transportconfig

ClearCategories : True

GenerateCopyOfDSNFor : {}

InternalSMTPServers : {}

JournalingReportNdrTo : <>

MaxDumpsterSizePerStorageGroup : 0B

MaxDumpsterTime : 00:00:00

MaxReceiveSize : unlimited

MaxRecipientEnvelopeLimit : unlimited

MaxSendSize : unlimited

TLSReceiveDomainSecureList : {}

TLSSendDomainSecureList : {}

VerifySecureSubmitEnabled : False

VoicemailJournalingEnabled : True

Xexch50Enabled : True

[PS] C:\>Set-TransportConfig -MaxDumpsterTime 07.00:00:00 (This will set the max dumpster time to seven days)

[PS] C:\>Set-TransportConfig -MaxDumpsterSizePerStorageGroup 20MB (This will set the transport dumpster queue to 20 MB)

[PS] C:\>get-transportconfig

ClearCategories : True

GenerateCopyOfDSNFor : {}

InternalSMTPServers : {}

JournalingReportNdrTo : <>

MaxDumpsterSizePerStorageGroup : 20MB

MaxDumpsterTime : 7.00:00:00

MaxReceiveSize : unlimited

MaxRecipientEnvelopeLimit : unlimited

MaxSendSize : unlimited

TLSReceiveDomainSecureList : {}

TLSSendDomainSecureList : {}

VerifySecureSubmitEnabled : False

VoicemailJournalingEnabled : True

Xexch50Enabled : True


When a CCR has a lossy failover, you will see the following event generated,


Event Type: Information
Event Source: MSExchangeRepl
Event Category: (1)
Event ID: 2099
Description:
Replay service requested hub server <HUB Transport ServerName> to resubmit messages between time periods 11/2/2006 8:00:14 AM and 11/2/2006 9:09:03 PM.


Matt Richoux


Comments (21)
  1. Anonymous says:

    Matt Richoux has explained to us how the Transport Dumpster configuration works in a Exchange Server

  2. Anonymous says:

    Apple iPhone for now ignoring synch to Exchange, other e-mail platforms Configuring, validating and monitoring

  3. jack says:

    how can you manually trigger the transport dumpster? what AD attributes does he look for? can you do this for non-ccr servers as well?

    i can see this being a handy feature!

  4. Matt Richoux says:

    Hi Jack,

    It is not possible to trigger the transport dumpster service, the replication service sends a request to the transport via RPC, this interface is not exposed externally via API or cmdlet.  CCR clusters keep a list of Hub Transport (HT) Servers in the AD site, they issue a RPC redelivery request to these HTs once they come back online.  The Transport Dumpster only works for CCR.

  5. jack says:

    thanks for the reply matt.

    any plans to implement any API or cmdlet for this in future service packs?

  6. Nima says:

    Hi

    If a Passive Cluster comes online and fails to send an RPC redelivery

    request ( for whatever reason ) is there anyway to manually redeliver these emails? Can we export them from the HT Queue database?

    Also, do you recommend the Queue database on HT server that

    is holding the dumpster to be backed up in case of a failure or

    corruption in the HT Queue database?

    Thanks

  7. Matt Richoux says:

    Hi Jack,

    I don’t believe there are any plans to expose the API or add a cmdlet.

  8. Matt Richoux says:

    Hi Nima,

    If a Passive Cluster comes online and fails to send an RPC redelivery

    request ( for whatever reason ) is there anyway to manually redeliver these emails?

    MattRich – The RPC request will be tried serveral times for 7 days, so there is no need to trigger in manually.  You will only lose this data if the it goes over 7 days.

    Can we export them from the HT Queue database?

    MattRich – No, there isn’t anyway to export.

    Also, do you recommend the Queue database on HT server that

    is holding the dumpster to be backed up in case of a failure or

    corruption in the HT Queue database?

    MattRich – The queue database can’t be backed up, it really wouldn’t make any sense to as soon as you back it up, it would be outdated.  Even if you could back it up, you couldn’t replay it.

  9. jack says:

    why wouldn’t you be able to replay it? wouldn’t deleting the checkpoint file just re-send all messages in the replayed logs?

  10. David says:

    Scenario:

    Site A has one hub server, 3 active nodes of MBX cluster, CAS server

    Site B Has one hub server, 3 passive nodes of MBX cluster, CAS server

    Site A is lost in a disaster.

    Site B mailbox servers take over. How do they get mail that was on the Site A transport dumpster? Is it lost?

    Is there any redundancy or failover for the transport dumpster?

  11. Matt Richoux says:

    Hi Jack,

    I really don’t understand the question, why would deleting the check point file re-send the messages, their has to be an RPC redelivery request.  The mail is stored in the transport dumpster in the mail.que database.

  12. Matt Richoux says:

    Hi David,

    Once Site A goes down you will have 7 days to retrieve the information in the transport dumpster on the HT servers.  The CCR cluster will make the RPC redelivery request for 7 days.  After seven days the mail would be lost.  There isn’t any redundancy or failover for the transport dumpster.  You could move the HT server in Site A to Site B if it is under 7 days.

  13. Lily Cui says:

    Hi Matt,

    I have a question related to David scenario: if site A is lost in a disaster, which means Hub server in  site A is also lost, the CCR cluster RDC request to Hub server in site A will faile, so there are data loss.  Am I right?   Is it possible that dumperster of Hub server in site A can replicate the data to Hub server in site B?

    Thanks,

    -Lily

  14. Henry says:

    I am looking for information on CCR with three nodes capable of hosting the Exchange CMS. I am looking to install two in my production site and one in a DR site. This buys me high availability and disaster recovery. Currently there is no information I can find regarding this. Is what I am trying to do possible? If not, why not? It seems like a prudent method of ensuring highly available Exchange services. Thanks!

  15. Matt Richoux says:

    Hi Lily,

    No there isn’t a way to replicate the transport dumpster from Site A to Site B.  If you don’t get the site A or at least the HTs up within seven days you will lost the data.

  16. Matt Richoux says:

    Hi Lily,

    No there isn’t a way to replicate the transport dumpster from Site A to Site B.  If you don’t get the site A or at least the HTs up within seven days you will lost the data.

  17. Matt Richoux says:

    Hi Henry,

    There is no way to have the CMS on a 3rd Node.   Log Shipping for Exchange is new to Exchange 2007, replicating to a 3rd node adds a lot more complexity and issues (failovers).  There will be SCR with Exchange 2007 SP1:

    http://msexchangeteam.com/archive/2007/02/23/435699.aspx

  18. Arshad says:

    Hi,

    I am looking to size network for CCR where both Nodes are geographically isolated in two different datacenters, User who will have mailboxes are Microsoft Light Profile on this CCR, with 5 sent 20 receive approximately I will host 4000 user on this server, uptill now the log shipping will use Public Interface, and at the same time clients will access the server from the same interface.

    My question:-

    Is there any base line from MS can i use to size my MAN connection link, I have fiber base connectivity between these two data centers. How can i calculate network for log shipping and seeding operation and at the same time client connectivity.

    Second Just want to know the sizing for transport dumspter in case of loosy failover if I have RPO of 5 minutes for the same amount of user and server.

    Thanks

Comments are closed.