In Exchange 2007, a message is normally stored in the transport database and is deleted as soon as it is sent to the next hop. Things are a bit different if you run a clustered mailbox server (CCR). Hub server maintains a queue of messages delivered recently to recipients whose mailboxes are on a clustered mailbox server. When a failover is experienced, the clustered mailbox server automatically requests every hub server in the active directory site to resubmit mail from the transport dumpster queue. This prevents mail from being lost during the time taken for the cluster to fail over. While this does provide a basic level of transport redundancy, it is only available for message delivery in a Cluster Continuous Replication environment and does not address potential message loss when messages are in transit between hub and edge servers.
With Shadow Redundancy in exchange 2010, the deletion of a message from the transport databases is delayed until the transport server verifies that all of the next hops for that message have completed delivery. If a successful delivery is not reported, the hub server will try to resend the message.
Shadow redundancy is implemented by extending the SMTP service. The service extensions allow SMTP hosts to negotiate shadow redundancy support. For more high availability messaging support, the messages stay in the transport dumpster on a hub transport server and are only deleted if they are successfully replicated to all database copies. Shadow Redundancy Manager (SRM) is the core component that is responsible for managing shadow redundancy.
It can be enabled or disabled for the entire organization using the “ShadowRedundancyEnabled” parameter of the Set-TransportConfig cmdlet. By default, the feature is enabled in 2010.
Run the command below to disable shadow redundancy. You can’t manage it using EMC.
Set-TransportConfig –ShadowRedundancyEnabled $false
This feature is only available in exchange 2010 and hence will only work in networks that have pure exchange 2010 transport servers.