Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 7)

If you would like to read the other parts of this article series please go to:

Introduction

In part 6 of this multi-part article, we started out by configuring the internal and external URL for the CAS services on each Exchange 2010 server in both Active Directory sites. Then we moved on to creating a database availability group (DAG) and performed the basic configuration for the DAG.

In this part 7, we will continue where we left of in part 6. We will add the 4 Exchange 2010 multi-role servers to the DAG, collapse the DAG networks, enable database availability coordination (DAC) for the DAG and redistribute the active database copies.

Adding Members to the Database Availability Group

Now that we have created the DAG we can move on and add the four Mailbox servers as member servers. To do so, right-click on the newly created DAG and select Manage Database Availability Group Membership in the context menu as shown in Figure 1 below.


Figure 1: Selecting Manage Database Availability Group Membership

This opens the Manage Database Availability Group Membership wizard. Click Add.


Figure 2: Manage Database Availability Group Membership wizard

Select the four servers and click OK.


Figure 3: Adding member servers to the Database Availability Group

Click Manage.


Figure 4: Member servers added to the Database Availability Group

The failover clustering component will now be installed on each server. Then the DAG will be created and configured accordingly. This can take several minutes so have patience.


Figure 5: Waiting for the Manage Database Availability Group Membership wizard to complete

When the servers have been added to the DAG, click Finish to exit the “Manage Database Availability Group Membership” wizard.

Collapsing & Renaming Database Availability Group Networks

When you add servers to a DAG, the cluster service enumerates all networks that are found. When you have DAG member servers with two network interfaces located in two datacenters with different subnets associated a total of four DAG networks will be created. By default the DAG networks will be named DAGNetwork02, DAGNetwork02 and so on (Figure 6).


Figure 6: DAG Networks

A good best practice is to both rename and collapse the DAG networks. Not only because it will result in a less complex visual representation, but also because of another important behavior. If you do not collapse the DAG networks in a scenario like this one, the replication always occurs over the MAPI network. This is the case even when you disable replication on the MAPI network.


Figure 7: Replication is enabled by default for the MAPI network

The reason for this behavior is related to how the “Microsoft Exchange replication” service works. Going into the details is however outside the scope of this multi-part article.

In order to collapse the MAPI networks, we need to open the property page for “DAGNetwork01” and then add the subnet of the MAPI network used in the other datacenter (in this case 192.168.2.0/24).


Figure 8: Collapsing the MAPI Networks

When we have done so, we can click “OK” to exit the property page for “DAGNetwork01”.

We will then repeat the above steps for the replication networks. That is open the property page for “DAGNetwork02” and add the subnet of the replication network in the other datacenter (Figure 9).


Figure 9: Collapsing the Replication Networks

The above steps will remove the subnets from “DAGNetwork03” and “DAGNetwork04” automatically and you will see a visual representation as shown in Figure 10.


Figure 10: Non-used DAG Networks

Since “DAGNetwork03” and “DAGNetwork04” no longer are in use, we can delete them by right-clicking each of them and selecting “Delete” in the context menu (Figure 11).


Figure 11: Removing Non-used DAG Networks

Now let’s rename each of the two remaining DAG networks so that it’s easier to differentiate the MAPI and replication networks from each other. To rename a DAG network, simply open the property page and enter the new name for the network followed clicking “OK”.

Personally I like to use the following naming standard for the DAG networks:

MAPI network: DAG_name – MAPI Network

Replication network: DAG_name – Replication Network

This means that the DAG networks will be named “DAG01 – MAPI Network” and “DAG01 – Replication Network” respectively as shown in Figure 12 and Figure 13.


Figure 12: Renaming the MAPI Network


Figure 13: Renaming the Replication Network

As you can see in Figure 14 this gives us a less complex representation of the DAG networks.


Figure 14: Collapsed & Renamed DAG Networks

Adding Mailbox Database Copies

Okay it is time to add database copies to the four mailbox databases as a DAG otherwise doesn’t really make any sense. In this specific scenario all four Exchange 2010 server should store a copy of each mailbox database.

We could use the Exchange Management Console to do so, but since we have four DAG member servers and twelve mailbox databases, it’s much quicker to use the Exchange Management Shell. So currently we have a copy of each mailbox database stored on EX01. To add a database copy for each database to EX02, EX03 and EX04, we’ll use the Add-MailboxDatabaseCopy cmdlet.

Mailbox Database 1-6:

To add a copy of mailbox database 1 through 6 to server “EX03”, we can use the following command:

Add-MailboxDatabaseCopy DAG01-MDB001 -MailboxServer EX03 –ActivationPreference 2


Figure 15: Adding Mailbox Database Copies

For server “EX02” use this command:

Add-MailboxDatabaseCopy DAG01-MDB001 -MailboxServer EX02 –ActivationPreference 3

And for server “EX04” use:

Add-MailboxDatabaseCopy DAG01-MDB001 -MailboxServer EX04 –ActivationPreference 4

Mailbox Database 7-12:

For mailbox database 7-12, we want to set “EX03” with activation preference “1” and “EX01” as preference “2” so that active database copies can be redistributed across the two Exchange 2010 servers in the primary datacenter. We’ll do this in the next section.

When finished, the database copy list should look like the following for mailbox database 1-6:


Figure 16: Activation Preference list for Mailbox Database 1 through 6

For mailbox database 7-12, they should look like Figure x below:


Figure 17: Activation Preference list for Mailbox Database 7 through 12

Notice the activation preference for each database copy. The database copies in the primary datacenter has activation preference 1 and 2. The two database copies in the failover datacenter has activation preference 3 and 4.

The activation preference number is used when the active manager’s best copy selection process is initiated. Number 1 is highest on the list. Because we want the active manager to consider activating one of the two database copies in the primary datacenter, these are configured with preference 1 and 2.

When the active manager determines which database copy to activate, it doesn’t look solely at the activation preference number but also several other things such as the activation policy for a database copy, the copy queue and replay queue length and the state of the content index. A detailed explanation of the copy selection process is outside the scope of the multi-part article, but fear not as this topic is covered extensivelyin the Exchange 2010 documentation on TechNet.

Redistributing Active Database Copies

Currently all active database copies are stored on server “EX01” in the primary datacenter. Since we have two servers in the primary datacenter, we want to redistribute active database copies, so that 50% (database 1-6) are stored on server “EX01” and 50% (database 7-12) are stored on server “EX02”. One of the additions included with Exchange 2010 SP1 is a new script named “RedistributeActiveDatabases.ps1” script, which can help us redistribute the databases across DAG member servers based on the activation preference number configured for each DAG member.

To run the script use the following command from within the Exchange scripts directory (C:\Program Files\Microsoft\Exchange Server\V14\Scripts):

RedistributeActiveDatabases.ps1 -DagName DAG01 -BalanceDbsByActivationPreference –ShowFinalDatabaseDistribution –Confim:$false

When running the command, we will first get an overview of the existing AD sites and where the active database copies currently are stored. Then the script begins moving active database copies based on the activation preference numbers configured for each mailbox database (Figure 18).


Figure 18: redistributing Active Database Copies using the RedistributeActiveDatabases.ps1 script

When the active database copies have been moved, the script will provide us with an overview of the new active database copy distribution.


Figure 19: Active Database Copy Distribution Report

Enabling Database Activation Coordination Mode (DAC)

When configuring multi-datacenter DAGs it’s generally a good best practice to enable database activation (DAC) coordination mode for the DAG. DAC is a special DAG property that protects a DAG against so called split brain syndrome. If or should I say when a catastrophic failure occurs in the primary datacenter and takes down the two Exchange 2010 servers and the witness server we have here, we will need to go through a set of recovery steps to restore service in the backup datacenter. One of the steps is to re-configure the DAG in order to mount databases in the backup datacenter as we must obtain quorum here. In this particular scenario at the time of failure, the primary datacenter has quorum as we have two DAG members and the witness server located here (versus two DAG members in the backup datacenter).

Note:
We will go through the recovery steps in upcoming parts of this multi-part article.

Let’s imagine that we got the databases mounted in the backup datacenter and now are bringing the servers in the primary datacenter back online. Typically the servers are brought back online before network connectivity between the datacenters is re-established. In such a situation the active manager in the primary datacenter still think that it has quorum and will try to mount local databases. This means that we end up in a situation where the databases may be mounted in both datacenters (split brain syndrome) and thereby cause divergence, which we of course want to avoid at all cost.

This is where DAC comes into the picture. By enabling DAC mode, when the active manager service starts on a DAG member it expects to be able to communicate (heartbeat) with all other DAG members via a protocol known as the Datacenter Activation Coordination protocol (DACP). Now the details behind the logic used for DAC is outside the scope of this multi-part article as its explained pretty well in the Exchange 2010 TechNet documentation, but basically when DAC is enabled for a DAG, the active manager on each DAG member will store a bit/flag in memory which is used to allow or permit local databases assigned as active to mount on the server. The bit/flag can be set to either “0” or “1” and will always be set to “0” when the active manager starts. If the active manager on the DAG member can communicate with all other DAG members and one of them says its bit/flag is set to “1”, the DAG member on which active manager starts are allowed to mount local databases. If connectivity between the datacenters hasn’t been re-established, the DAG members restored in the primary datacenter won’t be able to communicate with the DAG members in the backup datacenter and hence not mount local databases. Split brain syndrome solved!

By default DAC is set to “off”. We can see this by using the following command:

Get-DatabaseAvailabiltyGroup DAG01 | fl


Figure 20: DAC is disabled for a DAG by default

Enabling DAC is a straightforward process. You simply use the following command:

Set-DatabaseAvailabilityGroup DAG01 –DatacenterActivationMode DagOnly


Figure 21: Enabling Database Activation Coordination

Configuring Cross Site RPC Client Access for a DAG

Some of you might have read about a new DAG property named “AllowCrossSiteRpcClientAccess” introduced with Exchange 2010 SP1. This intention with it was to allow an Exchange admin to configure cross site RPC Client Access behavior.

So let me stress out that although you can see the property when issuing the “Get-DatabaseAvailabilityGroup” command and even change the default setting of “False” to “True” it has no effect on the overall behaviour of the DAG. This is because the Exchange team decided to cut this feature just before Exchange 2010 SP1 RTM’d.


Figure 22: AllowCrossSiteRpcClientAccess Property

Said in another way don’t waste time on this property.

This ends part 7 of this multi-part article. In the next part, we will take a closer look at how the Hub Transport server role should be configured so that we achieve full redundancy at the transport layer.

If you would like to read the other parts of this article series please go to:

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top