Pro-Exchange,Lync & Office 365
Belgian Microsoft Unified Communications Professionals
Microsoft Exchange Server, Microsoft Lync Server & Office 365
A closer look at Multi-site data replication support for Exchange Server

Yesterday, I stumbled upon a tweet from Johan Veldhuis pointing to the following KB-article:

The article provides more information on the supported configurations for multi-site data replication for Exchange Server. Even though Exchange Server 2010 has its own built-in replication mechanism (DAG) to ensure data consistency and high availability. Because it’s not always clear what type of configurations are and are not supported, I’ll try to capture the essence of the KB-article below.

There are two “types” of replication:

  • Synchronous Replication    the host (Exchange Server) receives a write-completed response only when both ends (local and remote) have successfully completed the transaction



  • Asynchronous Replication    the host will receive a “write-completed” response as soon as the write operation is committed to the local storage device


You can also have host-based replication. This is where the replications relies on a piece of software instead of hardware. Although I’m sure there is some pretty nifty software out there, I have yet to see this implemented on an Exchange Server (especially Exchange Server 2010). With the latter, I would rather use the built-in capabilities of the DAG which is – in fact – also a host-based (software) replication mechanism.

The support that Microsoft offers is – based on the two types of replication I mentioned earlier – divided into two categories:

  1. Geographically dispersed solutions
  2. Non-Geographically dispersed solutions

Note   a geographically dispersed solution is one where the remote end (storage) is not within the same geographical location of the local (storage) end: e.g. a remote geographical site. In such deployments, synchronization usually happens over WAN links.

Asynchronous replication (storage- or host-based)

Microsoft does not support asynchronous replication for Exchange Servers. This is solely supported by the storage vendor. Additionally, Microsoft makes the following statements about the level of support if you are running such a configuration:

  • They will only troubleshoot Exchange-specific issues up to the point where the sources of the problem can be attributed to the replication mechanism
  • You do not have to remove the asynchronous replication feature in order to be eligible for support. However; it might become a requirement if troubleshooting demands (especially if the problem cannot be solved by either your storage vendor or Microsoft, you might have to revert to a fully supported configuration)

Synchronous replications (Geographical Dispersed storage-based, host-based)

Microsoft fully supports a synchronous geographical configuration, for as long as the hardware that is used in the configuration is certified and is fully supported by your (storage) vendor. To verify whether your storage solutions is on the WHQL list, do the following:

  1. Visit the following Microsoft Web site: (

  2. Click Cluster Solutions.
  3. In the left panel, click Geographically Dispersed Cluster Solution under Product category.

If your solutions is not WHQL qualified, Microsoft will revert to the same support policy as for asynchronous replication.

Synchronous Replications (Non-Geographical Dispersed storage-based, host-based)

The same support policy applies as for geographical dispersed solutions: fully supported, for as long as the hardware that is used in the configuration is certified and is fully supported by your (storage) vendor.

For more information on the support policy, I invite you to take a look at the KB-article here.


In my opinion (and when we’re talking about Exchange Server 2010), you should stick with the built-in capabilities of a DAG. DAGs have proven their value and offer some distinct benefits over 3rd-party replication mechanisms. On the other hand, if you rely heavily on an underlying form of replication (e.g. storage-based replication in a virtual environment), you should – at all times – stick with a certified hardware solution, replicating synchronously.

Also, don’t forget to take a look at the Disk Timeout Values for your Exchange Servers. Relying on a 3rd party replication mechanism might require you to change some of the recommended values. More information can be found here:



Posted 04-30-2012 12:10 by Michael Van Horenbeeck