Exchange 2013 DAG recovery in a stretched AD site – Part 1

• Author
• Recent Posts

Krishna Kumar

Krishna Kumar specializes in PowerShell, Exchange and Active Directory. Follow his blog SMTP Port 25.

Latest posts by Krishna Kumar (see all)

• Review of Stellar Phoenix Mailbox Exchange Recovery - Wed, Jul 22 2015
• Configure Exchange 2013 Internet mail flow during migration - Fri, Dec 27 2013
• Exchange 2013 DAG recovery in a stretched AD site – Part 2 - Wed, Dec 25 2013

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 Blue.com domain with two Exchange 2013 DAG nodes. DAG01 is the stretched AD site “Default-first-site-Name” between the two data centers.

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:

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:

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.