3. Configuring the Transport Dumpster
When your organization has replicated mailbox databases, your Hub Transport servers use the transport
dumpster to maintain a queue of messages that were recently delivered
to recipients on a replicated mailbox database. During a database or
server failover, the Mailbox server on which replicated mailbox
databases become active requests redelivery of messages from the transport
dumpster for every Hub Transport server in the originating Active
Directory site. In addition, if the mailbox database copy becomes
active in a different Active Directory site, the Mailbox server makes
the same request to Hub Transport servers in the other site.
Exchange Server 2010 also supports transport
dumpster truncation based on log copy status. This feature ensures that
messages replicated successfully to all mailbox databases are removed
from the transport dumpster. Thus, the transport dumpster will contain only nonreplicated data.
You can view or change the transport dumpster configuration by completing the following steps:
-
In the Exchange Management Console, expand the Organization Configuration node, and then select the Hub Transport node.
-
In the main pane, select the Global Settings tab and then
double-click Transport Settings. This displays the Transport Settings
Properties dialog box with the General tab selected by default.
-
The Maximum Size Per Mailbox Database text box specifies the maximum
size of the transport dumpster for each replicated mailbox database.
Size this setting to accommodate all messages being sent in the
recovery period—the period of time from failure to failover and full
recovery (which could be calculated according to the formula
RecoveryWindowSizeInMinutes * MessagesPerMinute * AverageMessageSize).
The valid input range for this parameter is 0 to 2,147,483,647 KB. The
default value is 18 MB.
-
The Maximum Retention Time text box specifies how long an e-mail
message should remain in the transport dumpster. When continuous
replication is used, transport servers should retain messages in the
queue for a period of time that is long enough to allow messages to be
recovered. The default retention period is 7 days. The valid input
range is 0 to 24,855 days. If you set the retention period to 0 days,
you disable the transport dumpster completely.
-
Click OK to apply your settings.
In the Exchange Management Shell, you configure the transport dumpster using the Set-TransportConfig cmdlet, as shown in Example 2.
The –MaxDumpsterSizePerDatabase and –MaxDumpsterTime parameters set the
maximum size and maximum retention time for the transport dumpster,
respectively. When you use the –MaxDumpsterSizePerDatabase parameter,
you must specify the units for values using KB for kilobytes, MB for
megabytes, GB for gigabytes, or TB for terabytes. When you use the
–MaxDumpsterTime parameter, you set the time span in the following
format: DD.HH:MM:SS. The example sets the maximum dumpster time to 3
days, 12 hours.
Example 2. Setting transport dumpster options
Syntax
Set-TransportConfig [-Identity OrgId] [-DomainController DCName]
[-MaxDumpsterSizePerDatabase MaxSize] [-MaxDumpsterTime <TimeSpan>]
Usage
Set-TransportConfig -MaxDumpsterSizePerDatabase "5GB"
-MaxDumpsterTime "3.12:00:00"
4. Configuring Shadow Redundancy
Shadow
redundancy ensures that messages are protected from loss the entire
time they are in transit. It does this by delaying the deletion of a
message from a transport database until the transport server verifies
that the message has been successfully delivered to all of the next
hops in the delivery route. If any transport server along the route
fails to report a successful delivery, Exchange resubmits the message
for delivery, and this ensures the message continues through to its
destination.
Thanks to shadow
redundancy, as long as you have multiple Hub Transports and multiple
Edge Transports, you can remove any transport server that fails and not
have to worry about emptying its queues or losing messages. If you have
multiple Hub Transports and multiple Edge Transports, you also can
upgrade or replace a Hub Transport or Edge Transport server at any time
without the risk of losing messages. If you have a single Hub
Transport, you should drain all SMTP queues on the server before
performing maintenance. The same is true if you have a single Edge
Transport. This ensures that there is no risk of message loss, even
without shadow redundancy. Keep in mind that if you have a single
transport server, and it fails and must be replaced, you've likely lost
data if you can't restore the mail.que file.
When you work with shadow redundancy, a key concept to understand is
that the primary transport server has ownership of the messages in its
shadow queue. The first primary owner is always the server on which the
message originates. As the message travels through the transport
pipeline, different transport servers may become the primary owner of a
message. In addition, if a primary owner fails, another server can take
over as the primary.
In the Exchange Management Shell, you configure shadow redundancy using the Set-TransportConfig cmdlet, as shown in Example 3. The related parameters are used as follows:
-
ShadowHeartbeatRetryCount
Sets the number of timeouts a transport server waits for before
deciding that the primary server has failed and assuming ownership of
messages in the shadow queue for that server. The default value is 3.
Set this value according to the size of your Exchange implementation
and the relative amount of latency on the network. For example, a large
global organization might want to set a higher retry count, while the
default may suffice for a smaller organization.
-
ShadowHeartbeatTimeoutInterval
Sets the amount of time a transport server waits before establishing a
connection to the primary server to check the discard status of shadow
messages. The default value is 300 seconds. Set this value according to
the size of your Exchange implementation, the level of messaging
traffic, and the relative latency on the network. For example, in a
large global organization where transport servers handle an extremely
high volume of messages, you might want to set a longer timeout
interval, while the default may suffice for a smaller organization.
-
ShadowMessageAutoDiscardInterval
Sets the amount of time a server retains discard events for shadow
messages. Primary servers queue discard events until they are checked
by another server or until the discard interval has elapsed, whichever
comes first. The default value is 2 days. Set the value according to
the size of your Exchange implementation, the level of messaging
traffic, and the relative reliability of your network. For example, in
a large global organization where transport servers handle an extremely
high volume of messages on a highly reliable network, you might want to
set a shorter discard interval, while the default may suffice for a
smaller organization.
-
ShadowRedundancyEnabled Enables or disables shadow redundancy. If you don't use shadow
redundancy, you can use this parameter to disable the feature. Ideally,
you'd only disable the feature temporarily or in situations where you
are have a single Exchange server implementation and are experiencing
problems related to this feature.
Example 3. Setting shadow queue options
Syntax
Set-TransportConfig [-Identity OrgId] [-DomainController DCName]
[-ShadowHeartbeatRetryCount Count] [-ShadowHeartbeatTimeoutInterval
<TimeSpan>] [-ShadowMessageAutoDiscardInterval <TimeSpan>]
[-ShadowRedundancyEnabled <$true | $false>]
Usage
Set-TransportConfig -ShadowHeartbeatRetryCount 5
-ShadowHeartbeatTimeoutInterval "0.00:10:00"
-ShadowMessageAutoDiscardInterval "3.00:00:00"
