Wondering about features of Shadow Redundancy in Exchange Server 2016? We can help you!

Shadow redundancy was introduced in Exchange 2010 to provide redundant copies of messages before they are sent to mailboxes.

However, in Exchange 2010, shadow redundancy delays deleting a message from the queue database on a Hub Transport server until the server verifies that the next hop in the message delivery path completes the delivery.

Exchange 2016 has made improvements such that the Transport service on a Mailbox server now makes a redundant copy of any message it receives before acknowledging the receipt of the message to the sending server.

Here at Bobcares, we often get requests from our customers regarding shadow redundancy as a part of our Server Management Services.

Today, let’s check in detail about Shadow redundancy in Exchange Server 2016 along with its features.

Requirements of Shadow Redundancy Exchange Server 2016

Shadow redundancy requires multiple Mailbox servers:

1. If the Mailbox server is not a member of a DAG, the other Mailbox servers must be on the local Active Directory site.

2. And if the Mailbox server is a member of a DAG, the other Mailbox servers must belong to the same DAG. The other DAG members can be in the local Active Directory site, or in a remote site.

By default, if the DAG spans multiple Active Directory sites, shadow redundancy prefers creating a redundant copy of the message in a remote site for site resiliency.

Shadow redundancy helps to ensure that all messages in the transport pipeline are made redundant while they are in transit. If Exchange determines the original message was lost in transit, it will deliver the redundant copy of the message.

The Shadow queue is 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.

Situations where shadow redundancy cannot protect messages in transit:

The following are some of the instances where Shadow Redundancy Exchange Server 2016 cannot protect messages:

1. In single Exchange server environments.
2. In under-provisioned DAGs.
3. During the simultaneous failure of two or more Mailbox servers involved in the shadow redundancy of a message.

Is Shadow redundancy is enabled by default?

By default, shadow redundancy is enabled globally in the Transport service on all Mailbox servers.

How shadow messages are created in Shadow Redundancy Exchange Server 2016

The main goal of shadow redundancy is to always have two copies of a message within a transport high availability boundary while the message is in transit.

Where and when the redundant copy of the message is created depends on where the message came from, and where the message is going.

The following are the three determining factors for creating shadow messages:

1. Firstly, receiving a message from outside a transport high availability boundary (the DAG, or an Active Directory site in non-DAG environments).
2. Messages sent outside a transport high availability boundary.
3. Receiving a message from the Mailbox Transport Submission service from a Mailbox server within the transport high availability boundary.

Shadow redundancy with Exchange 2010 Hub Transport servers in the same Active Directory site

When an Exchange 2010 Hub Transport server transmits a message to an Exchange 2016 Mailbox server in the same Active Directory site the Exchange 2010 advertises support for shadow redundancy using the XSHADOW command. But the Mailbox server doesn’t advertise support for shadow redundancy.

However, this prevents the Exchange 2010 Hub Transport server from creating a shadow copy of the message on an Exchange 2016 Mailbox server.

When the Transport service on an Exchange 2016 Mailbox server transmits a message to an Exchange 2010 Hub Transport in the same Active Directory site, the Exchange 2016 Mailbox server shadows the message for the Exchange 2010 Hub Transport server.

SMTP timeouts

During the attempt to make a redundant copy of the message, the SMTP connection between servers could timeout.

The sending server will re-deliver the message that did not get an acknowledgment. However, the duplicate message detection will prevent Exchange mailbox users from seeing this.

When the sending server resubmits the message, the primary server will create another shadow copy of the message.

There will not be any relationship between the shadow messages during message resubmissions by the sending server.

Maintaining shadow messages in Shadow Redundancy Exchange Server 2016

After the successful creation of the shadow message, the work of shadow redundancy will begin.

The primary server and the shadow server have to stay in contact with each other to track the progress of the message.

When the primary server successfully transmits the message to the next hop, the next-hop acknowledges receipt of the message. The primary server updates the discard status of the message as delivery complete.

A success message is not usually kept in a shadow queue. The shadow server moves the shadow message from the shadow queue into Safety Net when it gets a success message.

The shadow server determines the discard status of the shadow messages in its shadow queues by querying the primary server.

After the shadow server opens an SMTP session with the primary server, the primary server responds with the discard notifications for messages that apply to the querying shadow server.

Disk stores the Discard notifications. So, if the Microsoft Exchange Transport service restarts, the discard notifications persist.

And the SMTP communication between the shadow server and the primary server is the heartbeat that determines the availability of the servers.

Shadow Redundancy Manager

It is the core component on a Mailbox server that manages redundancy. Shadow Redundancy Manager is responsible for maintaining the following information for all the primary messages that a server processes.

Responsibilities of Shadow Redundancy Manager

Shadow Redundancy Manager does the following actions for all the shadow messages that a shadow server has in its shadow queues:

1.  Maintaining the list of primary servers for each shadow message.
2. Comparing the original database ID and the current database ID of the queue database that stores the primary copy of the message.
3. Checking the availability of each primary server for a shadow message is in the queue.
4. Processing discard notifications from primary servers.
5. Removing the shadow messages from the shadow queues after receiving all possible discard notifications.
6. Deciding when the shadow server should take ownership of shadow messages, becoming a primary server.

[Need assistance? We are happy to help you]

Conclusion

To conclude, in today’s article we saw the features of Shadow Redundancy Exchange Server 2016.