What should you recommend changing?

You are evaluating the implementation of a Database Availability Group (DAG). You need to
recommend changes to the planned implementation to minimize the loss of large email messages if
a single DAG member fails. What should you recommend changing?

A.
The preference of the mail exchanger (MX) records

B.
The duration of single item recovery

C.
The intervals of shadow redundancy

D.
The size of the transport dumpster

Explanation:
A database availability group (DAG) is the base component of the high availability and site resilience
framework built into Microsoft Exchange Server 2013.
A DAG is a group of up to 16 Mailbox servers that hosts a set of databases and provides automatic
databaselevel recovery from failures that affect individual servers or databases.
A DAG is a boundary for mailbox database replication, database and server switchovers, failovers,
and an internal component called Active Manager. Active Manager, which runs on every server in a
DAG, manages switchovers and failovers.
NOT A
Not relevant to this scenario
NOT B

Not relevant to this scenario
Single item recovery provides an additional layer of protection so that you can recover items that
were accidentally deleted by a user or by automated processes such as the Managed Folder
Assistant.
Single item recovery simplifies recovery and reduces recovery time because you can recover items
without recovering an entire mailbox or mailbox database from backup media. To learn more, see
“Single item recovery” in Recoverable Items Folder.
NOT C
Relates to both Exchange 2010 and Exchange 2013
With the Exchange 2013, Microsoft replaced the transport dumpster with an improved and even
better – Safety
Net.
Safety Net can be considered to be having two parts- Shadow Redundancy and Safety Net
Redundancy.
Shadow redundancy keeps a redundant copy of the message while the message is in transit. Safety
Net keeps a redundant copy of a message after the message is successfully processed.
So, Safety Net begins where shadow redundancy ends. The same concepts about shadow
redundancy, including the transport high availability boundary, primary messages, primary servers,
shadow messages and shadow servers also apply to Safety Net.
The size of an email message is not one of the components of the shadow redundancy interval.
Shadow redundancy components The following table describes the components of shadow
redundancy. These terms are used throughout the topic.
Term Description
Transport server An Exchange server that has message queues and is responsible for routing
messages. In Exchange 2013, a transport server is a Mailbox server (the Transport service on the
Mailbox server).
Transport database The message queue database on an Exchange 2013 transport server. Shadow
queues and Safety Net are also stored in the transport database.
Transport high availability boundary A database availability group (DAG) in DAG environments, or an
Active Directory site in non-DAG environments. When a message arrives on a transport server in the
transport high availability boundary, Exchange tries to maintain 2 redundant copies of the message
on transport servers within the boundary. When a message leaves the transport high availability
boundary, Exchange stops maintaining redundant copies of the message.
Primary message The message submitted into the transport pipeline for delivery.
Shadow message The redundant copy of the message that the shadow server retains until it
confirms the primary message was successfully processed by the primary server.
Primary server The transport server that’s currently processing the primary message.
Shadow server The transport server that holds the shadow message for the primary server. A
transport server may be the primary server for some messages and the shadow server for other
messages simultaneously.
Shadow queue The delivery queue where the shadow server stores shadow messages. For messages
with multiple recipients, each next hop for the primary message requires separate shadow queues.
Discard status The information a transport server maintains for shadow messages that indicate the
primary message has been successfully processed.
Discard notification The response a shadow server receives from a primary server indicating a
shadow message is ready to be discarded.

Safety Net The Exchange 2013 improved version of the transport dumpster. Messages that are
successfully processed or delivered to a mailbox recipient by the Transport service on a Mailbox
server are moved into Safety Net. For more information, see Safety Net.
Shadow Redundancy Manager The transport component that manages shadow redundancy.
Heartbeat The process that allows primary servers and shadow servers to verify the availability of
each other.
D
Exchange 2013 Safety Net Vs Exchange 2010 Transport Dumpster
http://msexchangeguru.com/2013/04/15/safetynet/
Relates to Exchange 2010
With the Exchange 2013, Microsoft replaced the transport dumpster with an improved and even
better – Safety
Net.
Safety net and transport dumpster are two features of Exchange 2013 and 2010 respectively. In fact,
safety net is an improved version of transport dumpster.
Transport Dumpster
A feature that facilitates data recovery as well as provide for compliances in previous versions of
Exchange, namely 2010 and 2007, is the Hub transport. All incoming and outgoing messages must go
through the Hub transport before it reaches a mailbox.
Transport Dumpster is a feature of the Hub Transport of Exchange 2010 which limits the data losses
during a lossy failover occurrence while mail delivery to a DAG. Transport dumpster was first seen in
CCR and LCR mailboxes of exchange 2007.
One of the limitations of transport dumpster is that it can be used only for replicated mailboxes and
not public folders or mailboxes that aren’t a part of the DAG. All Hub transport servers in the active
directory sites of the DAG contains the transport dumpster queue for a particular mailbox and the
dumpster is stored inside the mail.
que file.
Exchange Server Transport Dumpster Settings
The lifetime of a message within the transport dumpster can be controlled using two attributes,
namely,
1. MaxDumpsterSizePerDatabase (E2010) and MaxDumpsterSizePerStorageGroup (E2K7)
2. MaxDumpsterTime
As the name suggests, MaxDumpsterSizePerDatabase is the property that determines the size each
storage group on the Hub Transport server can avail. (Default value=18 MB)
MaxDumpsterTime is obviously the duration of time for which the message is available within the
dumpster.(Default 7days)
There are two settings that control the life span of a message within the transport dumpster.
•MaxDumpsterSizePerDatabase Defines the size available for each storage group on the Hub
Transport server. The recommendation is that this be set to 1.5 times the maximum message size
limit within your environment. The default value for this setting is 18 MB.
•MaxDumpsterTime Defines the length of time that a message remains within the transport
dumpster if the dumpster size limit is not reached. The default is 7 days.
In Exchange 2010 the Transport Dumpster is controlled using the Set-TransportConfig cmdlet is
configured to 15MB per database per default. This means for every mailbox database the transport
dumpster will always hold the last 15MB of email delivered to the mailbox server.
Microsoft introduces Transport dumpster in Exchange 2007 and continues with Exchange 2010, All
email traffic (incoming/outgoing) must go through a Hub transport server before reaches to the
mailbox.

Transport dumpster is a feature of the HUB transport of the Exchange Server 2010/2007 all
messages which gets delivered to user’s mailboxes is routed through a HUB transport server and get
stored in the Transport Dumpster.
Even an email sent from one user to another user on the same mailbox server, the mailbox server
routes the email to a HUB transport server and back again through MAPI.
Transport dumpster designed to minimize data loss during the mail delivery either it is a DAG in a
lossy failover scenario or CCR and LCR mailboxes. Transport dumpster is used for replicated mailbox
databases only, it never defend messages sent to public folders, nor does it defend messages sent to
recipients on mailbox databases that are not replicated.
The entire HUB transport server in the active directory site of the DAG contains the transport
dumpster queue for a particular mailbox and the dumpster is stored inside the mail.que file.