Reconstructing Database Availability Groups In Exchange 2010

Database Availability Group is a very beneficial feature provided by Microsoft Exchange Server. It allows us to maintain high availability of data and serves as a reliable backup plan in case of disaster scenarios. Exchange Administrators used to face lot of trouble maintaining availability of a server when initiating the DAG feature. A Server with a huge database or high incoming traffic face hassles in case of a disaster or breakdown. Exchange Server database availability groups help maintain high availability of the data by splitting it amongst the servers in the availability group. To redesign a Database Availability Group you need to know about the concept of DAG and related terms; this will make you clear about your needs and how you are going to achieve them.

What Are Database Availability Groups?

A DAG is a collection of servers that can host replicated copies of each other’s mailbox database keeping the data available all the time in case of disaster. It helps reduce the downtime in case a server breakdowns; the mailbox database can be retrieved from other servers that are hosting the copy of the database.

 
Features That DAGs Exhibit:

•      Automatic Failover

•      Failover Clustering

•      Active Manager

•      Maintains High availability of Data without any complexity

•      Storage Area Network to maintain block level data storage

•      Maximizes Incremental Deployment

•      Allows upto 16 members in a DAG maintaining high availability.

•      Provides easy configuration to add or modify members and mailbox databases for replication.

What Is Automatic Failover In Database Mirroring?

It is the procedure of making the principal or main source of database available by switching availability to a mirrored copy of primary database. First, the data needs to be synchronized amongst mirror servers. If the session is running in high safety mode then as soon as the primary database becomes unavailable automatic failover procedure is initiated.

In case of an ongoing transaction performed by primary database, as soon as the mirrored database goes online, all the uncommitted transactions are rolled back and locks are applied to isolate those transactions ensuring protection from any possibility of false transactions. The databases and mirrored copies are refreshed and synchronized as changes made in the primary or mirrored server would be saved all around the servers storing mirrored data.

Failover Clustering:

In a Database Availability Group the servers are arranged and spread in form of clusters. Clustered servers or nodes provide a clustered shared volume, distributed namespace that clustered roles can use to access shared or physical storage space where replicated data is stored. With the help of failover clustering users in DAG face no issues in availability of the data.

 
Exchange Active manager:

In Exchange Database Availability Groups, Active Manager is considered as the core component.It is responsible for managing Switchovers and Failovers. The Active Manager executes on every server present in DAG; it runs inside the Microsoft Exchange replication service (MSREPL.exe).

Two roles are assigned to server’s member of the Availability group i.e. Primary Active manager (PAM) and Standby Active Manager (SAM). PAM reacts to the changes in topologies of the availability group and recent failures. The DAG member currently holding the PAM would be the one that owns the default cluster group. SAM keeps information about the server which is hosting replicated copy of the database, keeps tabs on recent failure and asks PAM to initiate failover procedure as soon as it maps failure on local databases and local Information Store.

The Active Manager keeps track of severs that are currently hosting the active copy of the specific database. The copies created across DAGs are subdivided into active and passive copies. The active copy is currently being accessed and passive copy is kept in case of failure. Whenever a failure occurs it performs the best copy selection method from the available passive copies of the failed database and activates them.
 

What Are Witness Servers And Why Do We Need Them?

A Witness Server is the additional server that acts as a spectator and ensures that the DAG arrangements maintain a quorum within the cluster. The Witness Server is always installed on a Hub transport server that does not have mailbox role installed and must be a member of the same Active Directory forest as the DAG.

For the websites having multiple active directories and datacenters configured to maintain high availability of the data, a witness server should always be installed on the primary or the main server in case we have an even number of datacenters installed for a DAG; then the witness server on either side stays put in case of failure.

During DAG Creation even if we fail to configure a witness server, the DAG searches for servers who don’t have mailbox role installed in them. The process automatically creates default directory and configures it as the Witness Server.

 
Understanding The Process:

Before jumping onto the configuration procedure, we need to list tasks that we will be implementing in this process. As we know that the old directories and settings would cause conflicts, resetting each setting and reinstalling/rebuilding the servers from scratch but keeping the IP addresses the same as before would be the best possible solution.

Here are the steps towards the DAG reconstruction process:

Removal of the Conflicting Settings and Mailbox Databases ->

Resetting The Active Directory:

Adding new servers would conflict with the existing ones hence they need to be reset. First we need to delete the current mailbox servers in the active directory and then, re-add them.

Consider making changes in a DAG Environment of two members MBX1 and MBX 2. The MBX1 hosts the active copy of the database and the MBX2 hosts the replicated copy of the same. We will be taking databases present in each member server hoisting an active and passive copy of the database i.e. DAG1DB1 and DAG1DB2.

•      Use the Active Directory manager to locate the computer account for each DAG member.

•      Select the computer account e.g. admin account for MBX1. Right click and select reset account.

•      Again select the account, right click and then select disable account.When the prompt appears, click yes and proceed further.

•      Repeat the steps for MBX2 to reset and disable the account.

Clear Existing CNO (Cluster Name Objects):

As soon as we create a DAG, it automatically becomes a part of the Windows Failover Cluster. Each Cluster assigns a Cluster Name Object, which gets created in the Active Directory.

CNOs are used for internal system communication; System Administrators have no such role in maintaining the DAG clusters Or Cluster Name Objects. This ensures that the DAGs remain secure and failovers are automatically managed.

•      Locate CNOs using Active Directory Users and Computers. HINT: THE DAG name is similar to the CNO name.

•      Select the computer account for the DAG1, select All Tasks and then choose Reset Account.

•      Again select the computer account for DAG1 ->All tasks and then select Disable Account.

•      Confirm the pop up dialog box to disable the account.

Remove All Present Database Replicas In The Current DAG

The next challenge that comes is to remove the database copies from the DAG; only then would it be feasible to remove the servers from the DAG.

We can use predefined CMDLET: Remove-MailboxDatabaseCopy to remove the passive copies of the database.
To manually execute the process run following commands in PowerShell:-

 
Now, we need to verify that there exists only one copy of the database that is the active copy. You can either use the CMDLETs such as Get-MailboxDatabase or use the following script:

Removal of Mailbox Servers Fromthe DAG:

Again, we have a predefined CMDLET that is Remove-DatabaseAvailablityGroupserver that is used to remove a mailbox server from the DAG. We can perform the similar using shell script:      
 
We can verify the removal of DAG member server using Get-DatabaseAvailabilityGroup CMDLET or
  Power Shell command.


Rebuilding the Mail Servers:

Now, the complete database and servers associated are dismounted. So, we can now proceed with the fresh installation of DAG.

Before initializing the process, the server machine needs to be Installed and configured. During this fresh installation you may use a different IP but the previous Mailbox Server Name should be exactly matched to the new ones.

•      Rename the machine using an appropriate name.

•      Join the appropriate Active Directory Domain

Executing Exchange Server in the Recovery Mode:

After preparing the replacement servers for Recovery procedure, we need to run Exchange setup in the recovery mode using /m:RecoverServer command. After a successful completion of the recovery process, restart the server.

Re-Mount the Databases:

If the active copy of the database is present on the servers then we can just provide the location of the server where it is stored. We can apply the Mount-Database CMDLET to mount the database from the current active copy of the database. If you have a backup then you can restore the backup to the default location and then mount the database. As soon as the database gets mounted, data access is restored for the clients.

Re-configuring The Mailbox Servers and Adding Them to DAG:

The final procedure is initiated with adding the configured mailboxes back to the DAG and creating mailbox database copies.

Adding Mailbox Servers to DAG:

Using cmdlet Add-DatabaseAvailablityGroupServer helps you to add Mailbox servers easily or you can use


Power Shell commands. If you need to verify if the members are added to the DAG or not use Get-DatabaseAvailabilityGroup CMDLET or Get-DatabaseAvailabilityGroup -Identity DAG1 | Format-List Servers

Attaching the Database copies to Appropriate Members

The final steps conclude with attaching the database copies to appropriate members present amongst the DAG. If the files are available on a backup then their original location or copied to the original location is used to fetch the data and spread them.

To add the mailbox database copies back to the DAG, run the following commands.  You can verify that each mailbox database copy was added successfully by using the Get-MailboxDatabase CMDLET or

 
You can also verify the health and status of all mailbox database copies in the DAG by using the Get-MailboxDatabaseCopyStatus CMDLET or:

 
Conclusion:

The redesigning procedure is meant for the users facing trouble maintaining high availability of the data in case of a disaster. To understand why we need DAG in the first place is the most important factor, and then redesigning process becomes much easier to understand. However, the procedure includes removal of attached servers, mailbox databases and members of the DAG from the Active Directory. A Database Availability Group provides highly efficient disaster recovery mechanism which helps large organizations to avoid facing a downtime.