Share via

Understanding Shadow redundancy

  • Article

Shadow redundancy is a mechanism thorough which the exchange 2016 ensures that message dint get lost during the transmission and that the exchange maintains the redundant copies of the message before it is passed to the next hop. This is done by keeping the message on another mailbox server. There are couple of points to consider while discussing the redundant storage

1. The Shadow redundancy work when the message is in transit and not when it is delivered.

2. The boundary for which the shadow redundancy works depends upon weather you have a DAG or not. Obviously two mailbox servers are needed for shadow redundancy to work. If DAG is in place- the mailbox server will contact mailbox server in the DAG for holding the other mailbox server. If the DAG spans scross multiple sites- the remote site is preferred. this can be modified with powershell. If DAGs are not in picture then the boundary is the active directory site and services.

3. The copy is stored as long as the mail is in the boundaries. As long as the mail goes out- the shadow copy will be maintained.

How it happens:

When the incoming message arrives, as long as shadow redundancy is enabled, the Mailbox server that receives the message makes a redundant copy of the message on another Mailbox server within the transport high availability boundary before acknowledging receipt of the message back to the sending server. Very important commandlet to understand is "Set-TransportConfig" That allows many connection stuff.

During this entire process- the primary and secondary servers always maintain the heartbeat connection.

When the message is delivered to the mailbox or when it leaves the boundary- the primary server updates the diascard status and thus updates the secondary server that the message has successfully been delivered. Once this happens- the secondary server moves the message to the safety net.

If the outage happens:

Set-TransportConfig has a setting called as ShadowHeartbeatFrequency. It decides how much time should the shadow server takes before opening a connection to the primary server and taking over the roles and responsibilities. ShadowResubmitTimeSpan decides for how long the secondary server will process the message. After that the server will take over the primary copy.