• Topics
    • Office 365
    • Teams
    • SharePoint
    • Exchange 2019
    • Exchange 2016
    • Exchange 2013
    • Hybrid
    • Certificates
    • PowerShell
    • Migration
    • Security
    • Azure
  • Blog
  • The Practical 365 Podcast
  • Books
  • Community
  • About
  • Subscribe
    • Facebook
    • Twitter
    • RSS
    • YouTube

Practical 365

You are here: Home / Exchange Server / Exchange Best Practices: Datacenter Activation Coordination Mode

Exchange Best Practices: Datacenter Activation Coordination Mode

March 31, 2016 by Paul Cunningham 26 Comments

Datacenter Activation Coordination mode (DAC mode) is a feature of Exchange database availability groups that is designed to prevent split brain scenarios.

Within a database availability group (DAG) each database can have one active copy, and up to 15 passive copies at any given time. Changes that occur in the active database copy are replicated to the passive copies by a process of continuous replication. The active copy can be dismounted, and one of the passive copies mounted to become the active copy, when a switchover or failover occurs.

In a split brain scenario, two copies of a database would be active at the same time, mounted on DAG members that are unable to communicate with each other due to a network problem, causing the databases to diverge. This is a situation that must be avoided, because it creates a difficult recovery scenario and will likely result in data loss.

DAC mode enables a protocol called Datacenter Activation Coordination Protocol (DACP). You can read an example of how DAC mode and DACP work to avoid split brains in this article.

The recommended practice for Exchange Server DAGs is to enable DAC mode if:

  • The DAG has more than one member (DAGs start with zero members, and can have one member)
  • Third party replication mode is not enabled, or the third party replication vendor specifies that DAC mode can be used

In addition to preventing split brains, DAC mode enables the use of Exchange site-resilience cmdlets (Stop-DatabaseAvailabilityGroup, Restore-DatabaseAvailabilityGroup, and Start-DatabaseAvailabilityGroup). Those cmdlets are used perform datacenter switchovers.

To review the DAC mode configuration for a DAG, use the Get-DatabaseAvailabilityGroup cmdlet.

1
2
3
4
5
6
[PS] C:\>Get-DatabaseAvailabilityGroup | Select Name,Servers,Datace*
 
Name        Servers                  DatacenterActivationMode
----        -------                  ------------------------
EX2016DAG01 {EX2016SRV2, EX2016SRV1} Off
EX2010DAG   {EX2010SRV1}             Off

To enable DAC mode, use the Set-DatabaseAvailabilityGroup cmdlet.

1
2
3
4
5
6
7
8
[PS] C:\>Set-DatabaseAvailabilityGroup EX2016DAG01 -DatacenterActivationMode DagOnly
 
[PS] C:\>Get-DatabaseAvailabilityGroup | Select Name,Servers,Datace*
 
Name        Servers                  DatacenterActivationMode
----        -------                  ------------------------
EX2016DAG01 {EX2016SRV2, EX2016SRV1} DagOnly
EX2010DAG   {EX2010SRV1}             Off

DAC mode can be enabled for DAGs that exist within a single datacenter location. A multi-site DAG is not required. Although less likely, a split brain can still occur for DAGs within a single datacenter location under the right conditions.

Paul Cunningham

Paul is a Microsoft MVP for Office Apps and Services and a Pluralsight author. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server.

Exchange Server Best Practices, DAGs, Database Availability Group, Exchange 2010, Exchange 2013, Exchange 2016, HA, High Availability, Site Resilience

Comments

  1. NELSON CORALES says

    March 23, 2018 at 2:09 pm

    Yes, I didn’t displayed it’s full name. This is a Win2008 R2 server in our domain running some apps. It’s not part of the Exch 2013 environment.

    Reply
    • NELSON CORALES says

      March 23, 2018 at 2:10 pm

      Sorry, didn’t display…. 🙁

      Reply
  2. NELSON CORALES says

    March 23, 2018 at 7:52 am

    Paul, we were trying to setup our DAC..
    “Set-DatabaseAvailabilityGroup -Identity EX-DAG01 -DatacenterActivationMode DagOnly”
    and got this warning…
    File share already exists, however directory is different from witness directory. Until this problem is corrected, the database availability group may have increased vulnerability to failures. To correct this problem, delete existing the file share and use the Set-DatabaseAvailabilityGroup cmdlet to retry the operation.
    Our file witness is at “\\mail\dagfsw\” not an Exch. server.
    Do we need to delete the contens of the dir above and re-run the cmdlet?
    Is that what they mean?
    Please let us know.
    Thx.

    NRC

    Reply
    • Paul Cunningham says

      March 23, 2018 at 9:19 am

      What is “mail”, is that a server name in your org?

      Reply
  3. Robert Y. says

    February 7, 2018 at 10:45 am

    Would like to know if there is a chance for fallout to enabling DAC mode on a production system?

    Reply
    • Paul Cunningham says

      February 7, 2018 at 4:44 pm

      All change carries risk. Plan accordingly. Test if necessary. Understand what change you’re making and how to roll it back if needed.

      Other than that, I consider it a safe change.

      Reply
      • Robert Y. says

        February 8, 2018 at 2:36 am

        Thank you for the input.

        Reply
  4. Oscar says

    November 28, 2017 at 5:40 am

    Hi Paul,

    We’ve been struggling with a DAG configuration, the members are in a primary datacenter with 2 servers in 1 network and a DR site in a different network.

    The FSW was configured in a 3rd location, however if I’m right, it should not be doing anything in this configuration, since we have quorum.

    We have the DAC configured as Dagonly in order to avoid splitbrain.

    We performed a DR Test and the problem was that when we cut over the network of the primary site (with 2 servers), the DR site would not come up and the databases went to unknown state which did not allow me to run any command on them.

    I ran this same test in a lab and it worked, the only difference is that I have only 1 network and I just shutdown the servers to replicate the issue.

    We are thinking it might be a clustering issue at OS level.

    Any advice on this?

    Thanks a lot.

    Reply
    • Paul Cunningham says

      November 28, 2017 at 1:18 pm

      How many members does this DAG have?

      Reply
  5. Kumar says

    November 27, 2017 at 2:35 pm

    Hello Paul,
    we have 2 exchange 2013 server in production site and also we are planing for 2 exchange server in DR site.

    Both production and DR exchange servers will be member of same DAG.

    in this scenario how many witness server required and how it will be configured . please note that we dont have any tertiary data center.

    we are looking for automatic failover . is there any workaround for achieving this solution without public cloud or third party data center . what about exchange 2016 ? if we use dynamic DAG, with single witness server will the automatic fail over work? .

    we are looking for fully automated process without any manual intervention.

    Reply
    • Paul Cunningham says

      November 27, 2017 at 3:53 pm

      The simple answer is, without a third datacenter you can’t have automatic site failover.

      Reply
      • Kumar says

        November 28, 2017 at 11:20 pm

        Thanks Paul,

        just wanted to know, we are planing to implement GEO load balance for the same purpose and keeping witness server in third location also. see in this scenario how the mx record pointing will be configured. currently we have 2 records mail.xxxx.com(pointing to primary site exch.) and mail2.xxxx.com(pointing to DR site exch.) once we implement GEO do we need to keep same record or single name will do the job?. if you could tell me the required DNS records and public IP for this scenario that would be great.

        Reply
        • Paul Cunningham says

          November 29, 2017 at 6:26 am

          Simplest option is just to have two separate MX records, one for each datacenter.

          Reply
  6. Hussain says

    November 10, 2017 at 4:16 pm

    Good work Paul appreciated, please let me know only one thing, what’s about datacenter failover? DAC will also work there? we should enable the DAC in case of switch datacenter or not?

    Reply
    • Paul Cunningham says

      November 10, 2017 at 8:33 pm

      DAC prevents split brain in scenarios where the two datacenters lose connectivity.

      If you want to do a datacenter switchover, search for the TechNet documentation that explains the steps. It is very well documented there.

      Reply
  7. MCE888 says

    November 3, 2017 at 10:51 am

    Hi Paul, great post. You stated that, although unlikely, a split brain can still occur for DAGs within a single datacenter location under the right conditions. Can you elaborate /share an example out of curiosity?

    Reply
    • Paul Cunningham says

      November 3, 2017 at 10:55 am

      All you need to do is imagine a scenario where a networking problem within a datacenter creates the same connectivity problem as a WAN failure would.

      Reply
  8. Robert says

    March 31, 2017 at 8:51 am

    Paul,

    When it comes to DAC mode and an even number of members, is the FSW required to be up and running in order to mount the databases assuming all DAG members go offline ?

    Studying your pluralsight videos.

    Reply
    • Paul Cunningham says

      March 31, 2017 at 10:16 am

      If all DAG members go offline there is nothing left to mount the databases. I suspect I am misunderstanding your question.

      Reply
      • Robert says

        April 1, 2017 at 1:45 am

        Sorry Paul let me be more clear. I am saying this:

        If you have a 4 member DAG and all servers go offline then once you bring them backup – is the FSW required to be online as well for Quorum to be attained ?

        Meaning in your 4 member dag, do you need all 4 dag members online and the FSW online at the same time for the DAG to get quorum and exchange to mount the databases?
        Robert

        Reply
  9. Hazem says

    May 28, 2016 at 7:02 pm

    Paul,

    I’m confused now in two datacenters on different geolocations. We should Enable DAC or not and why?
    And what about Alternate File Share Witness?

    I appreciate your reply.

    Thanks..

    Reply
    • Hazem says

      May 31, 2016 at 4:45 pm

      Paul, I appreciate your reply.

      Reply
      • Goofoff says

        August 9, 2016 at 10:50 am

        What did he tell you? i have a very similar situation.

        2 datacenters, 2 Ex2013’s in both, all in 1 dag.

        What is the best way to take care if one site was to go down.

        Reply
  10. MRCUR says

    April 6, 2016 at 7:27 am

    Paul,

    This is great info. Thanks very much.

    I think it’d be very helpful if you included a link to this post in your 2013 DAG setup/info posts. I did not know about DAC until today and would’ve caught it earlier through your DAG posts.

    Thanks again!

    Reply
  11. filip says

    April 2, 2016 at 4:02 pm

    So recommendation is use dac when going dag ? not by the fact if using two datacenter on different geolocations?
    We are going to build a 10 node dag over 2 high speed low latency datacenter with FSW in azure.
    Following your article we will configure dac

    Reply

Leave a Reply Cancel reply

You have to agree to the comment policy.

Recent Articles

  • The Practical 365 Podcast Ep 3: New Data Centers, Teams and more
  • Build your own custom SharePoint document library bulk provisioning system using the PowerPlatform – Part 1
  • Build your own custom SharePoint document library bulk provisioning system using the PowerPlatform – Part 2
  • The Practical 365 Podcast Ep 2: Azure AD, Message Center Updates, and Roadmap
  • The Practical 365 Podcast: Episode 01 – Exchange Updates and Roadmap
Practical 365

Related Posts

Using Activation Policies to Prevent Database Copies Mounting in Other Sites
How to use activation policies for Exchange Server database availability groups to control where database
Installing an Exchange Server 2016 Database Availability Group
A step by step tutorial for installing a new Exchange Server 2016 database availability group
Introduction to Exchange Server 2016 Database Availability Groups
Getting started with Exchange Server 2016 high availability by learning the fundamental concepts of database

Training Courses

  • Configuring and Managing Office 365 Security
  • Office 365 Admin Playbook
  • Exchange 2016 Exam 70-345
  • Managing Exchange Mailboxes and Distribution Groups in PowerShell
  • More Training Courses...

Recommended Resources

  • Office 365 Security Resources
  • Office 365 Books
  • Exchange Server Books
  • Exchange Server Migrations
  • Exchange Analyzer
  • Digicert SSL Certificates

About This Site

Practical 365 is a leading site for Office 365 and Exchange Server news, tips and tutorials. Read more...

Find out more about advertising with us.

Contact us


Subscribe to our newsletter
  • Facebook
  • Twitter
  • RSS
  • YouTube

Copyright © 2019 Quadrotech Solutions AG · Disclosure · Privacy Policy
Alpenstrasse 15, 6304 Zug, Switzerland