Exchange 2013 DAG



Database Availability Group members run the Mailbox server role. Although they can also run the Client Access server role this is separate and not required for DAG operations. In some situations the Client Access role should not be installed on the same server, for example:

  • if you plan to use Network Load Balancing for Client Access server high availability (NLB is not supported to co-exist with the Failover Clustering that DAGs leverage)
  • if you have any reason to believe you might later remove the Client Access server role (removal of a single server role is not possible in Exchange Server 2013)

Exchange Server 2013 can run on both Windows Server 2008 R2 and Windows Server 2012. However, due to the dependency on Failover Clustering you should note the following requirements:

  • Windows Server 2008 R2 must be Enterprise edition to support Failover Clustering
  • Windows Server 2012 can be either Standard or Datacenter edition

To install your Exchange Server 2013 DAG members:

In my example scenario I have two servers E15MB1 and E15MB2 both running Windows Server 2012. Each server is installed with both the Client Access and Mailbox server roles. A third server E15FSW exists for the file share witness.

Note: thanks to the concept of “incremental deployment” a DAG can be created using existing mailbox servers that are already in production with active mailboxes on them. There is no hard requirement to build brand new mailbox servers to be able to deploy a DAG.


Because the file share witness server is not an Exchange server some additional permissions are required. The Exchange Trusted Subsystem group in Active Directory must be added to the local Administrators group on the server.

The file share witness also requires the File Server feature installed.

PS C:\> Add-WindowsFeature FS-FileServer

And you should verify that File and Printer Sharing is allowed through the firewall.

If the file share witness is another Exchange server, such as a Client Access server, it already has the correct permissions configured.

For more information see:


In this example each server is connected to the network, which is the client-facing network. The two Exchange servers are also connected to the network which will be used for DAG replication traffic.

Dedicated replication networks are not a requirement for Database Availability Groups, however if you do choose to deploy one or more replication networks you must ensure that DNS registration is disabled the network interfaces connected to those networks.

The replication interfaces are also not configured with a default gateway. In the case where replication interfaces for the same replication network are on separate IP subnets, static routes are configured. However in this example that is not required.

The configuration of the network interfaces is important for DAG network auto-config to be successful. For more information see Misconfigured Subnets Appear in Exchange Server 2013 DAG Network.


In my example the server E15MB1 and E15MB2 had databases that were automatically created during Exchange 2013 setup. To prepare for database replication within the DAG I performed the following tasks:

  • “Mailbox Database 1” on E15MB1, which already contains active mailboxes, has beenmoved from the default folder path onto storage volumes dedicated to databases and transaction log files
  • “Mailbox Database 2” on E15MB2, which contained no mailboxes, has been removed from Exchange

Those steps may not be required in your environment depending on your existing databases.


Depending on your environment the pre-staging of the Cluster Name Object (CNO) may be required (it is a requirement if you are running Windows Server 2012 for the DAG members), but in any case it is a recommended best practice.

The CNO is simply a computer account object in Active Directory. There are two methods you can use to create the CNO.

The first is to manually create the CNO using Active Directory Users & Computers. Create a new computer object with the name that you intend to give to your DAG. Then disable the computer account.

Next, grant the computer account for the first DAG member Full Control permissions for the CNO computer account. Note that you may need to click the View menu in AD Users & Computers and enable Advanced Features before you can see the Security tab for the computer object.

The other method for creating the CNO is to use Michel de Rooij’s Cluster Name Object Pre-Staging script.



In the Exchange Admin Center navigate to Servers -> Database Availability Groups and click the + icon to create a new DAG.

Enter the following details for the new Database Availability Group:

  • DAG name – this should match the CNO you pre-staged earlier
  • Witness server – this is required for all DAGs, even those that have an odd number of members and hence run in node majority quorum mode
  • Witness directory – this is optional. If you do not specify a directory Exchange will choose one for you.
  • IP address – the DAG requires an IP address on each IP subnet that is part of the MAPI network. If you do not specify IP addresses the DAG will use DHCP instead.

Click Save when you have entered all of the required details.


After the DAG has been created it still does not contain any actual members. These need to be added next.

Highlight the new Database Availability Group and click the icon to manage DAG membership.

Add the servers that you wish to join the DAG and then click Save. This process will install and configure the Failover Clustering feature of Windows Server 2012 and add the new DAG members to the cluster.

Note: if you’re using a non-Exchange server for the file share witness, and you have correctly configured the permissions on the FSW, you will still see a warning at this stage that the Exchange Trusted Subsystem is not a member of the local administrators group on the FSW. This is a bug that can be disregarded.

When the operation is complete the Database Availability Group will display the members you added.

In the next part of this series we will look at configuring the database copies in the DAG.

Configuring Database Copies in an Exchange Server 2013 Database Availability Group

At this stage we have a database availability group with two Mailbox servers and a single database.


What we want to do is configure that database so that is is replicated to the second DAG member. This is referred to as adding a database copy.

An important step before adding the database copy is verifying that the same storage path exists on the server we’re adding the database copy to. The folder paths for the database as are as follows:

[PS] C:\>Get-MailboxDatabase "Mailbox Database 1" | select edbfilepath,logfolderpath

EdbFilePath   : E:\Mailbox Database 1\Mailbox Database 1.edb
LogFolderPath : F:\Mailbox Database 1

E:\ and F:\ volumes have been configured on the second mailbox server already, so it is good to go.

In the Exchange Admin Center navigate to Servers -> Databases and select the database you wish to add a copy of. Click the “” icon and choose Add database copy.


Click Browse and choose the mailbox server to add a database copy to.


The Activation preference number will automatically increment to the next available number. E15MB1 already hosts the database with preference 1, so in this example the activation preference for the new database copy is 2.

Activation preference should generally reflect the order in which you’d like mailbox servers to host the active database copy, with 1 being the first preference, because it is used as a factor in automatic failover scenarios as well as when manually rebalancing the DAG.

If you click more options you’ll see additional settings for replay lag and for postponing the initial seed of the database copy. Neither of these are required for this particular scenario so I am not going to configure them at this stage.

Click Save to add the database copy.


If you look in the file paths on the server that you’re adding the database copy to you should see the seeding files as the database and transaction log files are copied across.


A small database over a fast network should not take more than a few minutes to finish seeding. Larger databases or slower networks will of course take longer.


When the operation is complete the second server will be hosting a passive database copy that is kept up to date through a process of continuous replication from the active database copy.


The Exchange Admin Center will now show that two servers have copies of the database.


To the right of the page you’ll also see some more information about the health of the database copies.


Or you can also use Get-MailboxDatabaseCopyStatus to check the database copy health.

[PS] C:\>Get-MailboxDatabaseCopyStatus "Mailbox Database 1" | ft -auto

Name                      Status  CopyQueueLength ReplayQueueLength LastInspectedLogTime  ContentIndexState
----                      ------  --------------- ----------------- --------------------  -----------------
Mailbox Database 1\E15MB1 Mounted 0               0                                       Healthy
Mailbox Database 1\E15MB2 Healthy 0               0                 6/02/2013 10:14:37 PM Healthy

In the next part of this article series we’ll look further at managing database switchovers for Exchange 2013 Database Availability Groups.

Managing Database Switchovers for Exchange Server 2013 Database Availability Groups

Databases that are being replicated within an Exchange Server 2013 database availability group can generally be considered to be either active or passive at any given time.

There are also other states that the database may be in, such as seeding, or due to health problems, but for the purposes of this article we’re going to be looking only at healthy database copies.

The active database copy is the one that is mounted on a DAG member and is being used to serve clients. The passive database copies (up to 15 of them) are those that reside on other mailbox servers within the DAG. Changes are replicated from the active database copy to the passive database copies.


The active database copy can be “moved” between DAG members that host a copy of that database. Although some people consider this to be an actual “move” of the data from one server to the other, in actual fact what is occurring is the active database copy is dismounted, and one of the passive database copies is then mounted.

There are two ways that the active database copy can be moved to another DAG member:

  • Failover – this is an unplanned event, such as a failure of the server hosting the active copy
  • Switchover – this is a deliberate, administrator-driven event, such as during server maintenance

In this article we’ll look specifically at the database switchover.

Consider a two-member DAG with two databases. Each server hosts one active and one passive database copy.


To move Mailbox Database 1 to E15MB2 we can simply highlight it and then review the status of the database copies. Note that in this case the passive copy on E15MB2 is healthy, with no copy queue length issues and a healthy content index state as well.

Under those conditions we can proceed with the switchover by clicking the link to Activate the database copy.


You’ll be prompted to confirm the action, and then a progress bar let’s you know when the operation is complete.


Click Close when it is finished. In this case we can see that the database is now active on server E15MB2.



Be the first to comment

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.