Say your exchange server that is a node in a Windows cluster services CCR environment takes a dive. how can you ensure that the messages that were in the process of being delivered or have been added to the current transaction log, but not shipped to the passive node are retrieved???
 

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.

 

This was shamelessly stolen from ..

 

http://msexchangeteam.com/archive/2007/01/17/432237.aspx

 

Advertisements