Rebuild an Entire Database Availability Group

Topic Last Modified: 2011-02-10

A database availability group (DAG), together with mailbox database copies, can provide automatic recovery from a variety of server, storage, network, and other hardware failures. A DAG can also provide a site resilience solution so that you can perform a datacenter switchover in the event of a site-level disaster. But even a comprehensive, intelligent, and robust solution such as a DAG can't protect you from all possible disasters, including disasters that affect an entire DAG.

For example, consider a two-member DAG deployed in a single datacenter. If the datacenter experiences a flood, fire, or other cataclysmic event that destroys the DAG, the entire DAG will need to be rebuilt from scratch. Rebuilding a DAG is a straightforward process that consists of nine primary steps:

In this article, you'll work with a two-member DAG named DAG1 that contains Mailbox servers named MBX1 and MBX2. MBX1 hosts the active copy of a database named DAG1-DB1, which is replicated to MBX2. In addition to hosting the passive copy of DAG1-DB1, MBX2 also hosts the active copy of DAG1-DB2, which is replicated to MBX1.

Microsoft Exchange Server 2010 derives security permissions based on the computer account for each server. To preserve these security permissions, the computer account for each DAG member needs to be reset and disabled using Active Directory Users and Computers.

Using Active Directory Users and Computers, locate the computer account for each DAG member.

Right-click the computer account for MBX1, point to All Tasks, and then select Reset Account.

Right-click the computer account for MBX1, point to All Tasks, and then select Disable Account. When the prompt appears, click Yes, and then click OK.

Repeat steps 2 and 3 for MBX2.

After Active Directory replication is complete, you can build new Windows servers using the names MBX1 and MBX2. If you've already built two replacement servers, you can rename them to MBX1 and MBX2 respectively.

Each DAG has an underlying Windows failover cluster. The name you give to a DAG becomes the name of the cluster, and a corresponding cluster name object (CNO) is created in Active Directory with this name. A CNO is the equivalent of a computer account for a cluster.

The names of the DAG and the CNO aren't used by end users or administrators. They're used by the system for internal communication and to secure the DAG. To preserve and reuse this name for the rebuilt DAG, the CNO for the DAG also needs to be reset and disabled using Active Directory Users and Computers.

Using Active Directory Users and Computers, locate the CNO for the DAG. In our example, the name of the CNO is DAG1.

Right-click the computer account for DAG1, point to All Tasks, and then select Reset Account.

Right-click the computer account for DAG1, point to All Tasks, and then select Disable Account. When the prompt appears, click Yes, and then click OK.

Allow time for Active Directory replication to complete before proceeding with the next step.

Before you can recover Mailbox servers that are members of a DAG, you must first remove all mailbox database copies from the server. When that is complete, you must then remove the server from the DAG. In our example environment, this process involves removing all passive database copies from the DAG. Specifically, you would use the Remove-MailboxDatabaseCopy cmdlet to remove the passive copy of DAG1-DB1 from MBX2 and the passive copy of DAG1-DB2 from MBX1.

Because the DAG members aren't operational, the commands will complete successfully but with several warning messages. You can verify that each mailbox database has a single copy by using the Get-MailboxDatabase cmdlet, as shown in the following examples.

Before you can recover a Mailbox server that is a member of a DAG, you must first use the Remove-DatabaseAvailabilityGroupServer cmdlet to remove the Mailbox server from the DAG. Because our example is a disaster recovery operation, we assume that MBX1 and MBX2 are either not operational or don't exist. As a result, the ConfigurationOnly parameter is used with the Remove-DatabaseAvailabilityGroupServer cmdlet. When this parameter is used, Remove-DatabaseAvailabilityGroupServer removes the Mailbox server from the DAG object in Active Directory.

The next step is to rebuild the servers you're recovering, using the same computer names as the original production servers (in this example, MBX1 and MBX2), and the same operating system version as the servers being recovered.

Note:

The server recovery process is based on the name of the computer on which Setup is run. You can use different IP addresses, but the name of the server must match the original Mailbox server name for server recovery to complete.

The rebuild process is effectively the same process used to build the original production Mailbox servers.

After the replacement servers are built and ready for Exchange server recovery, the next step is to run the Exchange 2010 unattended setup process in recovery mode. You don't need to complete this step on each DAG member before moving to the next step (restoring and/or mounting databases). However, you do need to perform this step for each DAG member on which you want to mount databases.

Open a Command Prompt window and navigate to the Exchange 2010 installation files.

Depending on the nature of the failure, the previously active copy of the databases hosted on these servers may not be available. If the files on disk are preserved and in their original location or copied to the original location, you should be able to use the Mount-Database cmdlet to mount the databases. Alternatively, you can restore your databases from backup to their original location, and then mount the databases.

After your mailbox databases are restored and/or mounted, service and data access should be restored for clients. The final steps are to reconfigure the Mailbox servers and databases for high availability by adding the recovered servers back to the DAG, and then creating mailbox database copies.

The final step is to add mailbox database copies back to the appropriate DAG member. Depending on the nature of the failure, the previously passive copies of the databases hosted on these servers may not be available. If the files on disk are preserved and in their original location or copied to the original location, the Microsoft Exchange Replication service may be able to perform an incremental resynchronization of the passive copies, thereby eliminating the need for a full reseed. However, if the original passive copies aren't available, you'll need to perform a full reseed.

To add the mailbox database copies back to the DAG, run the following commands.