Exchange 2010 FAQ: Can You Automate Rebalancing a Database Availability Group?

Q: Is there a way to script Exchange 2010 Database Availability Groups so that mailbox databases automatically fail back to their preferred node?

A: In short, yes.

I’ve been asked whether there is a way to script or automate the failover (or more accurately, switchover) of the mailbox databases in an Exchange 2010 Database Availability Group.

The goal is to always return mailbox databases to their preferred node within the DAG after business hours, when something during the day has caused them to failover to different nodes.

Why would you want to do this? There could be several reasons:

• to balance out the performance of each server by ensuring no one server is handling more databases than others
• to return databases to the most well-connected locations relevant to the user population
• to return databases to the correct DAG nodes for backups to run successfully and in a supported manner

So in order to do this you can use the RedistributeActiveDatabases.ps1 script provided by Microsoft in Exchange 2010 SP1 (and later) to rebalance databases in a DAG. See a demonstration of that script here. All you would need to do is run that script as a scheduled task using an account with the required Exchange administrative privileges.

However, if you have that script running every night as a scheduled task you face the possible situation where rebalancing the DAG is not a desirable outcome.

Consider that databases in a DAG may failover due to server hardware failure, such as a disk or memory within a server. Even though the server is up again, doesn’t necessarily mean that the memory fault is resolved, or that the disk isn’t running in a degraded state.

So how do you prevent an unhealthy server from hosting active mailbox databases if the rebalancing of the DAG is automated?

The solution is to block activation on the unhealthy server. There are two ways you can do this.

The first method is to use Set-MailboxServer with the -DatabasecopyAutoActivationPolicy parameter. For example here is  server with an unrestricted activation policy, so it is capable of activating passive databases.

[PS] C:\>Get-MailboxServer HO-EX2010-MB2 | ft name,databasecopy* -auto

Name          DatabaseCopyAutoActivationPolicy
----          --------------------------------
HO-EX2010-MB2                     Unrestricted

By setting the activation policy to “Blocked” the server will not activate any databases when the DAG is rebalanced.

[PS] C:\>Set-MailboxServer ho-ex2010-mb2 -DatabaseCopyAutoActivationPolicy Blocked

The second method is actually the same underlying technique, but adds a few more steps that are worth performing. If a server is unhealthy then it probably shouldn’t be hosting any active databases, so you also want to move any other active databases off the server as well.

You can achieve this by running the StartDagServerMaintenance.ps1, the same script used to manage installation of updates on DAG members.

[PS] C:\>cd $exscripts
[PS] C:\...\>.\StartDagServerMaintenance.ps1 ho-ex2010-mb2

Either of those methods will prevent the DAG member from hosting active databases until you’ve had a chance to resolve the server health issue.

[adrotate banner=”49″]