Back to Blog

New DAG Activation Feature in Exchange 2016 CU2

Image of Nathan O'Bryan MCSM
Nathan O'Bryan MCSM
DB settings box

Microsoft recently announced a new DAG copy activation feature that will be available in Exchange 2016 CU2, but before we talk about that, I’d like to do a quick refresher on how database copy activation works currently and will continue to work for Exchange 2013 and 2010.

The whole point of a Database Availability Group (DAG) is to have multiple copies of a database that are ready to activate in the event of a problem with the server hosting the primary copy. The suggested number of copies for a database is 4, but that depends on your backup strategy and high availability requirements. For the purpose of this article, we’ll use an organization that has four databases each with four copies on four different servers located in two sites. For the sake of the illustration, our databases will be names 1 through 4, and the copies of each database will be designated with a -1 through -4. The primary copy of database 1 will be 1-1, the quaternary (that’s the fancy word for fourth) copy of database 4 will be 4-4. Our database layout is going to look like this

Dag1.png

Now it’s important to note that when you create a database, or a database copy, the default activation precedence for that new database is always going to be 1. If you have 16 copies of a database, and never change the default activation preference, then you’ll have 16 copies of a database with the same activation precedence. In that case, Managed Availability and the Primary Active Manager (PAM) will be responsible for deciding which copy of a database gets activated. When you set an activation precedence, your preference will be taken into account.

In this scenario, if Server 1 were to go down unexpectedly, then database 1-1 would activate on Server 2 (assuming that server was deemed healthy by MA). If Server 1 were to come back online, and Server 2 were then to go down, database 1 would activate on Server 1 and database 2 would activate on Server 3. Unless actively managed, over time databases will become active on all different servers. Usually this happens in a less than totally efficient way.

In setting up your database copies, you can specify settings like MaxActiveCopies to ensure that each server only tries to activate a specific number of database copies. In our example above, I would probably size the environment for each server to have a maximum of two active copies. There is also a setting that will ensure that database copies can only activate on another server in the same site automatically.

In addition, there is a feature called Database Activation Coordination (DAC) that is intended to protect your Exchange databases against a split brain scenario. That is a situation where a network failure between two different datacenter causes two different copies of the same database to be active at the same time. I don’t have space in this post to go into the details of DAC, but that is definitely something you should look into when configuring a multi-site DAG.

Anyway, back to the issue at hand. Over time multiple copies of a database tend to become active in places you’d generally prefer they were not active if all your servers are up and working. In Exchange 2010 SP1 Microsoft introduced a script called RedistributeActiveDatabases.ps1. Running this script would activate the primary copy of each database, putting everything back on the servers you expect them to be on.

I have set up several customers with a scheduled task to run this script daily. That is a functional way to ensure your databases are running on the servers you expect them to be on, but now there is a new way.

What’s New in Exchange 2016 CU2

With that brief background for DAG copy activation, let’s take a look at what’s new in CU2.

Microsoft made an announcement that CU2 will contain a new feature called Preference Move Frequency. This new feature will attempt to automatically activate the highest preference copy of a database at an interval you specify. Microsoft’s documentation says the default interval for this is one hour, but my testing on a pre-release version of CU2 shows the default interval is 0. This discrepancy has been pointed out to the Exchange team, so hopefully it will be fixed before release.

You can control this feature via the Set-DatabaseAvailabilityGroup -PreferenceMoveFrequency cmdlet. If you want to disable this feature, set the time frame to 00:00:00 [Day:Hour:Minute].

From my limited testing in the lab, this looks like a pretty handy new feature. It’s not all that often I get to write about new on-premises Exchange features, so this is a nice treat for me.

CORRECTION:

In the above article, I stated that if you don’t change the activation precedence for database copies within a DAG, you can end up with up to 16 copies of the database with the same AP. It’s been pointed out to me that this is not strictly true, so let me correct that bit… 

It boils down to, there are circumstances in which you will see multiple copies of the same database with the same activation preference. The reason for this, as explained by Microsoft, is “It’s not querying the authoritative version, but the server that hosts that copy. That server’s opinion isn’t important for activation preference in failover decisions. It will get updated on the next database move or if replication is restarted on that server.”

Paul Cunningham of exchangeserverpro.com has an article on his site that talks about this behavior (although he likes to spell that word with an unnecessary “u”). Check out his article for more information.


Microsoft Exchange Security Updates February 2023 feature image

February 2023 Exchange Security Updates

Image of Jaap Wesselius
Jaap Wesselius

On February 14, 2023, Microsoft released new security updates rated ‘Important’ for:

  • Exchange 2019...
Read more
Microsoft Exchange Security Updates banner image

January 2023 Exchange Security Updates

Image of Jaap Wesselius
Jaap Wesselius

On January 10, 2023, Microsoft released new Security Updates for Exchange 2013 CU23, Exchange 2016...

Read more