The Exchange 2007 Transport Dumpster (Part 1)

If you would like to be read the first part in this article series please go to The Exchange 2007 Transport Dumpster (Part 2).

 

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.

 

Transport Dumpster Operation

 

Earlier in this article I discussed how the transport dumpster is effectively a rolling queue of email recently delivered to users whose mailboxes reside on either a CCR or LCR environment. Based on what we now know about the MaxDumpsterSizePerStorageGroup and MaxDumpsterTime parameters, let us see how the rolling queue of email looks based upon the configuration of these two parameters.

 

Let us assume that the maximum message size within the organization is 30MB, meaning that the transport dumpster MaxDumpsterSizePerStorageGroup parameter has been set at 45MB. The first two users on the CCR environment are Ann and Bob. Bob requests that Ann send him the 10 PowerPoint presentations that he is after, so Ann sends Bob 10 different email messages, each containing a different 5MB PowerPoint presentation. With the transport dumpster set at 45MB, you can clearly see that the transport dumpster will be able to store 9 email messages before it reaches capacity, since 45MB divided by 5MB is 9. Figure 3 below is a representation of what the transport dumpster would contain once Ann sent the first 9 of the 5MB email messages.

 


Figure 3: Transport Dumpster Size Queue

 

When Ann sends the 10th message, the 1st message sent will be removed from the transport dumpster since only a maximum of 45MB can be stored at any one time; the transport dumpster operates in a First In First Out (FIFO) manner. Therefore, the transport dumpster queue would then look like the representation shown in Figure 4, where you can see that message number one has been removed and message number 10 has been added to the queue.

 


Figure 4: Transport Dumpster Later Size Queue

 

A similar process occurs with the MaxDumpsterTime. Let us assume that the MaxDumpsterTime is left at its default setting of 7 days. Using the same example scenario involving Ann and Bob, let us assume, for clarity’s sake, that Ann chooses to send just one email per day to Bob and that these are the only messages being processed by the system. After 7 days, the transport dumpster would look like the representation shown in Figure 5. Note that I have added a ‘date’ column to emphasize the point here.

 


Figure 5: Transport Dumpster Time Queue

 

As you can see from Figure 5, a total of 7 day’s worth of email messages are stored in the transport dumpster. Since the MaxDumpsterTime is set to 7 days, it follows that on the 8th day the old message from 1st June 2009 will be removed from the queue. As a result, the transport dumpster would then look like the representation shown in Figure 6.

 


Figure 6: Transport Dumpster Later Time Queue

 

Summary

 

That concludes part one of this two-part article on the Exchange 2007 transport dumpster feature. In part one we have looked at what the transport dumpster is, how it is configured and how it might look when operational. In part two, we will look at sizing and monitoring the transport dumpster.

 

 

If you would like to be read the first part in this article series please go to The Exchange 2007 Transport Dumpster (Part 2).

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top