Wednesday 1 August 2012

Transport Dumpster

Introduction

The transport dumpster feature of Exchange 2007 is specific to the Hub Transport server role. The idea behind the transport dumpster is simple: each Hub Transport server in an Active Directory site that contains a CCR environment maintains a rolling queue of email messages that have recently been delivered to users whose mailboxes are hosted on that CCR environment. Then, during the recovery process that results after a lossy failover of the CCR environment, all Hub Transport servers in the Active Directory site containing the CCR environment automatically redeliver those messages in the transport dumpster queue.
It is important to understand that the transport dumpster protects against the loss of some data, not all data. For example, a transient email that is being sent from the Mailbox server to the Hub Transport server at the time of the lossy failover may not be included in the transport dumpster, resulting in data loss. Other examples include calendar appointments and any email messages stored as draft items when Outlook is running in online (non-cached) mode.
The transport dumpster feature is optional and therefore can be turned off. However, it is enabled by default and is likely that most organizations will want to make use of this feature. That being said, it is important to note the requirements, such as increased disk I/O, when running the transport dumpster feature. We will be looking at this in part two of this article.
Throughout this two-part article I am going to be assuming that Exchange 2007 Service Pack 1 has been deployed as this service pack brought many enhancements to the transport dumpster feature. For example, with Exchange 2007 Service Pack 1, the transport dumpster supports the Local Continuous Replication (LCR) feature. Despite the fact that LCR is supported, I’m going to be focusing this article on the transport dumpster’s involvement within a Cluster Continuous Replication (CCR) environment.

Transport Dumpster Configuration

The transport dumpster is configured on a per-storage group basis. The two configurable parameters that control the length of time that messages remain in the transport dumpster are:
  • MaxDumpsterSizePerStorageGroup - As you can probably tell from the name, this is the amount of storage space allocated per storage group for messages within the dumpster. Microsoft makes clear recommendations on the value that you should give MaxDumpsterSizePerStorageGroup. If your organization has a maximum permissible message size configured, simply make the MaxDumpsterSizePerStorageGroup parameter 1.5 x the maximum message size. For example, if your maximum message size is 30MB, the MaxDumpsterSizePerStorageGroup parameter should be set to 45MB. If your organization does not have a maximum permissible message size, you should set the MaxDumpsterSizePerStorageGroup parameter to be 1.5 x the average message size within your organization. If you don’t know what your average message size is, you can use the Exchange Profile Analyzer tool which is available for free download from the Microsoft downloads site. Alternatively, other 3rd party tools will be able to provide this information. The default value of MaxDumpsterSizePerStorageGroup is 18MB, so unless your maximum or average message size within your organization is 12MB, you will need to alter this value.
  • MaxDumpsterTime - This parameter states for how many days, hours, minutes and seconds a message can remain in the transport dumpster. By default, this parameter has a value of 7.0:0:0 which translates to 7 days, 0 hours, 0 minutes and 0 seconds. Microsoft recommends that the MaxDumpsterTime is set to 7 days so, generally speaking; you should not have to alter the configuration of this parameter.
To alter these values you can either use the Exchange Management Console or the Exchange Management Shell. Let us take a look at the Exchange Management Shell first. These values are organization-wide transport values and therefore are not tied to a specific Exchange server. Therefore, you would not expect to use the Get-TransportServer or Set-TransportServer cmdlets to view and alter these values. Rather, you need to use the Get-TransportConfig and Set-TransportConfig cmdlets. Figure 1 shows you a sample output from the Get-TransportConfig cmdlet where you can clearly see that the MaxDumpsterSizePerStorageGroup and MaxDumpsterTime parameters are both set to their default values, namely 18MB and 7 days respectively.

Figure 1: Results of the Get-TransportConfig Cmdlet
If you were required to change the MaxDumpsterSizePerStorageGroup parameter to a value of 45MB, you would simply run the following cmdlet:
Set-TransportConfig –MaxDumpsterSizePerStorageGroup 45MB
Similarly, the following cmdlet can be used to change the MaxDumpsterTime to a sample value of 5 days and 5 hours, although I do not recommend changing this parameter as I have stated earlier in this article. This is based on the fact that Microsoft itself recommends leaving the default value of 7 days in place.
Set-TransportConfig –MaxDumpsterTime 5.5:0:0
To use the Exchange Management Console to alter these settings, navigate to the Organization Configuration node of the console tree and highlight the Hub Transport object beneath it. In the result pane, select the Global Settings tab and you will see the Transport Settings object. Right-click the Transport Settings object and choose Properties from the context menu. You will be presented with the screen shown in Figure 2 where you can see where to change the two transport dumpster values.

Figure 2: Transport Dumpster Settings in Exchange Management Console
Note:
If you wish to disable the transport dumpster for all storage groups across your Exchange 2007 organization, you can set either the MaxDumpsterSizePerStorageGroup or MaxDumpsterTime values to 0. There is therefore no use in setting one parameter, leaving the other set to 0 and expecting the transport dumpster to be operational.

2 comments:

  1. Copied from msexhange.org articles

    ReplyDelete
  2. This comment has been removed by the author.

    ReplyDelete