An Active Directory site is stretched if it is spread across multiple sites. In this series of two posts, I will show you how to recover an Exchange 2013 Data Availability Group in a stretched AD site.

Many organizations have Active Directory and Exchange spread across multiple sites/data centers, and sometimes multiple data centers are configured as a single AD site. This kind of setup may exist in both small and medium-sized organizations, and it is a well-supported setup by Microsoft.

The following figure shows my lab setup of the domain with two Exchange 2013 DAG nodes. DAG01 is the stretched AD site “Default-first-site-Name” between the two data centers.

Stretched Active Directory site

The configuration of DAG01

Primary data center:

  • Exchange 2013 multirole server BlueExch01 is configured as a DAG member.
  • GreenDC01 is configured as a file share witness.
  • Three mailbox databases on BlueExch01 are created.

Secondary data center:

  • Exchange 2013 multirole server BlueExch02 is configured as a DAG member.
  • GreenDC02 is configured as an alternate file share witness.
  • Three created mailbox databases are copied to BlueExch02 of the active mailbox database.

DAG is configured in Data Center Activation Coordination (DAC) mode using the following cmdlet:

Set-DatabaseAvailabilityGroup -Identity <DAGname> -DatacenterActivationMode Dagonly

DAG Recovery when the primary data center fails

Exchange 2013 DAG is lost when the primary data center or the majority nodes are lost. In the above lab, when the primary data center is lost and the database is mounted on the primary server BlueExch01, the database copy status on BlueExch02 changes to “DisconnectedAndHealthy;” if the database is mounted on BlueExch02, the status will be “Dismounted.” In our case, our database is mounted on BlueExch01 during the failure. Hence, the database status on BlueExch02 changes to “DisconnectedAndHealthy.”

Get-MailboxDatabaseCopyStatus -Server blueexch02 | select name, status


To recover the DAG at the secondary data center, we first need to stop the cluster service on the DR node BlueExch02.

Once the cluster service is stopped on the server BlueExch02, we need to remove the failed node BlueExch01 from the cluster. This is done using the cmdlet Stop-DatabaseAvailabilityGroup. Since the node BlueExch01 is down, we need to execute the cmdlet using the Configuration Only parameter, as follows:

Stop-DatabaseAvailabilityGroup -Identity DAG01 -MailboxServer BlueExch01 -ConfigurationOnly


Once the cmdlet finishes, you should be able to see that the failed node BlueExch01 is evicted/removed from the cluster and the cluster is configured with a single node BlueExch02. Below is the snapshot of the failover cluster manager with node BlueExch02 only:

Failover Cluster Manager

Restore the DAG in the DR data center using the cmdlet Restore-DatabaseAvailabilityGroup. The following cmdlet restores the DAG on the single node BlueExch02 and also configures an alternative file share witness on GreenDC02:

Restore-DatabaseAvailabilityGroup -Identity DAG01 -AlternateWitnessServer GreenDc02 -AlternateWitnessDirectory C:\Afsw


Generally, the alternate file share witness server is configured during the initial creation of the DAG. Hence, these parameters are ignored if the DAG is already configured. Once the DAG is recovered, you should be able to see all the databases mounted on the single node BlueExch02. Below is the reference snapshot:

Get-MailboxDatabaseCopyStatus 2

In this part of the article, I discussed how to recover the DAG in the stretched AD site if the primary data center is lost. In the next part, we shall see how to fix the DAG once the primary data center Exchange Servers hard recovered from the disaster and then mount back the database on BlueExch01.

  1. Bruce 8 years ago

    This makes no sense to DAC mode if you only have 1 AD site? I guess I don’t understand. If you have a stretched dag and the A-fsw is also configured, it will be a db failover not a switchover. Tell me what I am missing here?


  2. Nikolay 6 years ago

    Thanks for your article!

    One question. Are both datacenters have to locate within one subnet (L2 layer) for this scenario?

Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account