Exchange 2010 DAG creation Part 2

7/30/2019 Exchange 2010 DAG creation Part 2

1/11

Exchange 2010 DAG Creation and Configuration, Part 220 October 2010

byNeil Hobson

Now that you've created your first DAG in Exchange 2010, you'll need to be sure it's correctlyconfigured for failovers and switchovers, and you know how to troubleshoot. Fear not, for Neil

Hobson tells you what you need to know.

This is the second and final article of a two-part series explaining the process of creating and configuring a

simple two-node Database Availability Group (DAG) in Exchange 2010. Inpart one of this article, we covered

topics such as the lab environment used throughout this discussion, the components that comprise a DAG, the

overall network configuration requirements, and the process to actually create the DAG object using the

Exchange Management Shell. If you havent read part one of this article, I strongly recommend that you do so

before reading part two.

In this second article we will initially be examining the log f iles that are generated during the DAG creation andconfiguration processes, as these become invaluable when you are troubleshooting. Although we wont really

see deep examples of how to use these log files, this is still information youll be glad we covered. We will then

move on to the more practical matters of adding the two mailbox servers (EX01 and EX02) to the DAG using

the Exchange Management Shell, and also cover important DAG configuration parameters that can be adjusted

after the DAG itself has been created. Towards the end of the article, once we have our DAG configured to our

taste, Ill talk a bit more about the Failover Cluster, show you how to add mailbox database copies to the two

mailbox servers, and how to perform a process known as a database switchover.

As you can see, there is a lot of information to cover in this article, so lets get started by examining the log files

which are generated during the DAG creation process.

DagTask Logs

On the Exchange 2010 server where the New-DatabaseAvailabilityGroup cmdlet was executed, navigate to

theC:\ExchangeSetupLogs\DagTasks folder, which will contain log files relevant to DAG creation and

configuration tasks. Each log file name will be in the following format:

dagtask_{date and time}_{cmdlet}

In this format, {date and time} refers to the date and time that the DAG cmdlet was executed,

while {cmdlet} refers to the name of the DAG cmdlet that was executed. For example, the log file name shown

in Figure 1 below isdagtask_2010-02-02_20-02-18.305_newdatabaseavailabilitygroup. After the first DAG

cmdlet, such as New-DatabaseAvailabilityGroup, has been executed, there will naturally only be a single

dagtask log file in theC:\ExchangeSetupLogs\DagTasks folder. As further DAG tasks are run, such as those

involving the Set-DatabaseAvailabilityGroup cmdlet, additional dagtask log files will be created in the same

folder.

With this in mind, its worth nothing that the setup log file that is created at the same time as the DAG itself (i.e.

as a result of running the New-DatabaseAvailabilityGroup cmdlet for the first time) is worth investigating, and

Figure 1 shows an example of this dagtask log files contents. In this particular log file, important configuration

information is shown, such as the WitnessServer and WitnessDirectory cmdlet parameters, together with a clear

indication that the DAG creation process was successful. Examining the contents of this log file will prove useful

when troubleshooting DAG creation failures.
http://www.simple-talk.com/author/neil-hobson/http://www.simple-talk.com/author/neil-hobson/http://www.simple-talk.com/author/neil-hobson/http://www.simple-talk.com/sysadmin/exchange/exchange-2010-dag-creation-and-configuration-part-1/http://www.simple-talk.com/sysadmin/exchange/exchange-2010-dag-creation-and-configuration-part-1/http://www.simple-talk.com/sysadmin/exchange/exchange-2010-dag-creation-and-configuration-part-1/http://www.simple-talk.com/sysadmin/exchange/exchange-2010-dag-creation-and-configuration-part-1/http://www.simple-talk.com/author/neil-hobson/


2/11

Figure 1: Contents of a Dagtask Log File

Adding Mailbox Servers to the DAG

Now, once the DAG has been created, the next step is to add the first mailbox server, EX01, to the DAG. To

accomplish this, the Add-DatabaseAvailabilityGroupServer cmdlet will be used, which requires two

parameters. They are the Identity parameter, which identifies which DAG is being configured, and the

MailboxServerparameter, which identifies which mailbox server is being added to the DAG. Therefore, the full

cmdlet to use is:

Add-DatabaseAvailabilityGroupServerIdentity HeadOffice MailboxServer EX01

The Add-DatabaseAvailabilityGroupServercmdlet performs the following tasks:

First, a check is performed to see if the server EX01 is already a member of a DAG, as a mailbox

server can only be a member of a single DAG.

Next, the Windows Failover Cluster components are installed on that mailbox server (if they are not

already present); this second task is being performed in Figure 2. Of course, if it is known when an

operating system is being deployed that it will be for a mailbox server which will also be part of a DAG,

then it is still perfectly acceptable to pre-install the Windows Failover Cluster components prior to

running the Add-DatabaseAvailabilityGroupServercmdlet.

Figure 2: Installation of the Windows Failover Clustering Components

Once the Windows Failover Cluster components have been installed, the Add-

DatabaseAvailabilityGroupServercmdlet creates the Windows Failover Cluster itself, which takes

its name from the name given to the DAG. Therefore, in the lab environment, the failover cluster name

is HeadOffice, as this is the name given to the DAG.

Finally, the mailbox serverEX01 is added to the DAG.

After the running of the Add-DatabaseAvailabilityGroupServercmdlet, an additional dagtask log file will havebeen created in the DagTasks log folder mentioned earlier. This new log file contains plenty of useful


3/11

information, such as the progress of the cluster formation, and the progress of adding the mailbox server to the

DAG, as can be seen in Figure 3. Examining the contents of this log file will prove to be a useful exercise if you

have any issues when adding a mailbox server to the DAG.

Figure 3: Dagtask Log File for Add-DatabaseAvailabilityGroupServer

Now that the first mailbox server has been added to the DAG, the Add-

DatabaseAvailabilityGroupServer cmdlet needs to be repeated, specifying the second mailbox

serverEX02as the server to add to the DAG. Thus, the cmdlet to achieve this is:

Add-DatabaseAvailabilityGroupServerIdentity HeadOffice MailboxServer EX02

Once this cmdlet has completed, the properties of the DAG can be examined to confirm that both mailbox

servers are now members of the DAG. To do this, the Get-DatabaseAvailabilityGroup cmdlet can be used,

with the results of this cmdlet piped into the format-list (or fl for short) cmdlet. To reduce the amount of

information provided, we can filter the output to only show the serversparameter, and so the command toachieve all of this is:

Get-DatabaseAvailabilityGroup HeadOffice | fl servers

The result of running this cmdlet is shown in Figure 4, where it can be seen that both EX01 and EX02are

confirmed as members of this DAG:


4/11

Figure 4: Confirming DAG Membership

Additional DAG Parameters

Now that youve got your Mailbox databases added to the DAG, the Set-DatabaseAvailabilityGroup cmdlet

can be used to configure additional DAG parameters after said DAG has been created. For example, if the

server hosting the witness directory fails, it is possible to change the witness server and witness directory using

the Set-DatabaseAvailabilityGroup cmdlet. Other key parameters that can be specified include:

AlternateWitnessServer- Its possible to specify an alternate witness server for the DAG to use with

regards to site resilience scenarios.

AlternateWitnessDirectory - This parameter is used in conjunction with

theAlternateWitnessServerparameter to form the full alternate witness location.

ReplicationPort - By default, Exchange 2010 uses the single Transmission Control Protocol (TCP)

port 64327 to perform log shipping and database seeding operations. If this port number needs to be

changed, this can be achieved via the ReplicationPortparameter, but be aware that if this port number

is changed, the Windows Firewall exceptions will also need to be manually changed, since these are

initially configured by the Exchange 2010 setup process.

NetworkCompression - This parameter determines whether network compression is enabled or

disabled on the DAG networks. Microsoft states that enabling this feature can reduce network trafficby up to 30%, and so its likely that enabling compression is worthwhile in most deployments. This

parameter has four different settings:

o Disabled network compression is disabled on all networks.

o Enabled network compression is enabled on all networks, including those on different

subnets when considering site resilience scenarios.

o InterSubnetOnly network compression will be enabled only for networks on the same

subnet. This is the default setting.

o SeedOnly network compression will only be enabled for database seeding processes.

NetworkEncryption - This parameter controls whether encryption is used on the DAG networks. In

Exchange 2010, DAGs support the encryption features of the Windows operating system, which could

prove useful for those environments that require increased security. This parameter is similar to

theNetworkCompression parameter, in that it has the same four settings,

namely Enabled, Disabled,InterSubnetOnlyorSeedOnly, and the default setting is InterSubnetOnly.

As an example of modifying one of the key parameters listed above, suppose that there is a requirement to

change the network compression setting from the default value ofInterSubnetOnlyto Disabled. In this example,

the following Exchange Management Shell command will be required:

Set-DatabaseAvailabilityGroup HeadOffice NetworkCompression Disabled

The result of running this command is shown in Figure 5:


5/11

Figure 5: Enabling DAG Network Compression

The Failover Cluster

Now that you have your DAG customized to your taste, lets take a look at how we can manage it. Earlier in thisarticle, we saw that the Windows Failover Cluster components were installed onto each mailbox server when

theAdd-DatabaseAvailabilityGroup cmdlet was run. There are some worthwhile observations to make

regarding the role of the failover cluster in Exchange 2010, when compared to its counterpart in Exchange 2007.

For example, the red highlight box in Figure 6 shows the Failover Cluster Manager snap-in expanded out to

reveal that the name of the cluster is derived from the name of the DAG. From examining the blue highlight

boxes, it can also be seen that there are no Exchange-related cluster resources in the Services and

applications node, such as those seen in Exchange 2007.

Figure 6: The Failover Cluster Manager Snap-in


6/11

What have been created, though, are cluster core resources for the DAG name, the DAG IP address and the

file share witness, as shown in Figure 7:

Figure 7: Cluster Core Resources

One ofMicrosofts design goals in Exchange 2010 was to ensure that an Exchange administrator can control a

DAG and its Windows Failover Cluster requirements equally well from within the Exchange Management

Console or the Exchange Management Shell, negating the need to perform any administrative duties within the

Failover Cluster Manager snap-in. To highlight this, Figure 8 shows the DAG networks presented within the

Exchange Management Console, whereas such objects were controlled within the Failover Cluster Manager

snap-in in Exchange 2007.

In fact, in Figure 8, you can see that two networks have been created with their default names set

to DAGNetwork01and DAGNetwork02respectively. The subnet information is also displayed and, as a result,

you can see that DAGNetwork01 is actually the MAPI network, since it represents the 192.168.50.0 network,

and that DAGNetwork02 is the Replication network, as it represents the 10.0.0.0 network.


7/11

Figure 8: DAG Networks in the Exchange Management Console

If you have taken the time to rename your network connections on each mailbox server to differentiate between

the MAPI and Replication network interfaces, it makes sense to rename the networks that you can see in Figure

8 as well so that they match, if only to make troubleshooting easier.

With that in mind, to change the display name of DAGNetwork01 to MAPI Network, the command below can

be used. The same process can obviously be used to rename DAGNetwork02 to Replication Network:

Set-DatabaseAvailabilityGroupNetwork Identity HeadOffice\DAGNetwork01 Name MAPI

Network

Mailbox Database Copies

Before creating the DAG and adding the mailbox servers to it, the Exchange 2010 mailbox server role had

already been installed on both servers before the start of this demonstration. As a result, a default mailbox

database had already been created on each mailbox server and given the default name, which now has a format

of Mailbox Database n, where nis a random 10-digit number; for example, the default mailbox database on

server EX02 is called Mailbox Database 1796634876.

The reason for this default naming standard is that, in Exchange 2010, the mailbox database is now an

organization object and not tied to any particular mailbox server. As a result, database names must be unique

across the Exchange organization. As can be seen from the screen shots later in this article, the default

databases have already been renamed to Mailbox Database 001 and Mailbox Database 002 on

servers EX01 and EX02respectively.

Now, even though a DAG has been created and both mailbox servers are members of this DAG, there stillexists only a single copy of each mailbox database by default. To create a highly available mailbox database


8/11

configuration, it is now necessary to ensure that a copy ofMailbox Database 001 exists on serverEX02and a

copy ofMailbox Database 002exists on serverEX01. In this configuration, each mailbox server will initially host

a single active database as well as a single passive copy of the active database hosted on the other server. To

create this configuration, the Add-MailboxDatabaseCopy cmdlet can be used and, in the lab environment, the

first command used is:

Add-MailboxDatabaseCopyIdentity Mailbox Database 001 MailboxServer EX02`

ActivationPreference 2

With this command, we can see that a copy ofMailbox Database 001 is being added to the mailbox serverEX02.

The ActivationPreference parameter is used to determine which database to activate if there are multiple

databases available that meet the activation criteria used by the Active Manager process. The Active Manager

process runs on each mailbox server in a DAG, and essentially decides which database copy to activate when

the need arises. If multiple databases meet all the criteria, the activation preference is consulted and the

database with the lowest value is activated. Since the primary copy of the database has an activation preference

of 1, a value of 2 has been chosen for the second copy of this database.

The results of running the Add-MailboxDatabaseCopy cmdlet are shown in Figure 9:

Figure 9: Adding a Mailbox Database Copy

To confirm that copies ofMailbox Database 001 now exist on both EX01 and EX02, it is possible to use the Get-

MailboxDatabase cmdlet to consult the DatabaseCopies and Servers parameters, as shown in Figure 10. Then

its just a question of re-running the Add-MailboxDatabaseCopy cmdlet for Mailbox Database 002, but this

time specifying a target server ofEX01. Once this cmdlet has completed, both databases have a copy that exist

on the alternate mailbox server:

Figure 10: Checking Mailbox Database 001 Database Copies

Database Failovers

Now that our 2-node DAG is essentially built and configured, all that remains is to prove that the databases can

be moved between the two mailbox server nodes. Before we do that though, lets briefly cover some key

terminology that Microsoft uses in this area: switchovers and failovers, collectively known as *overs (pronounced

star-overs).


9/11

A switchoveris an action performed by an administrator to move either a single database or all the databases

on a mailbox server to an alternative mailbox server within the DAG. If the administrator moves all databases

from one server to another, then this process is known as a server switchover. The most obvious example of

when you might need to perform a server switchover is when applying an update rollup or service pack to an

Exchange 2010 mailbox server. On the other hand, in the example I will present shortly, we will be performing

a switchover of just a single database from server EX01 to serverEX02 - a process known as a database

switchover.

A failoveris an automatic action performed by the system in response to a problem with either a single database

or the entire mailbox server. Like switchovers, failovers can also apply to either a single mailbox database

(adatabase failover) or the entire server (a server failover). I wont be demonstrating a failover here, but I will

perform a database switchover using the Exchange Management Console, although the Exchange

Management Shell can also be used if you prefer.

Demonstrating a Switchover

The first thing to do is to obtain the status of the database copies. In Figure 11, you can see that the active copy

of the database named Mailbox Database 001 is currently residing on server EX01, since the Copy

Status column shows a value of Mounted for server EX01. Server EX02 contains a healthy copy of this

database, which you can tell by virtue of the fact that the Copy Status column shows a value of Healthy for

serverEX02. Likewise, Mailbox Database 002 is active on serverEX02and has a healthy database copy on

serverEX01.

Figure 11: The Database Copy Status

To make the copy ofMailbox Database 001 on serverEX02the active copy, the following process is used:


10/11

1. In the bottom pane shown in Figure 11, right-click the healthy copy ofMailbox Database 001 located

on serverEX02, and choose the Activate Database Copy option from the context menu (as shown

in Figure 12):

Figure 12: Activating a Database Copy

2. Next, a window is presented that allows you to override theAutoDatabaseMountDialsetting for this

mailbox server. Shown in Figure 13, this setting essentially allows you to control whether or not the

database will mount, depending on how many transaction log files may be missing. More information

on theAutoDatabaseMountDialparameter can be found in the Exchange 2010 productdocumentation

on the Set-Mailbox cmdlet.

Figure 13: AutoDatabaseMountDial Override

3. The database copy on serverEX02is then activated and, if the procedure is successful, the Exchange

Management Console will now reflect this, as shown in Figure 14, where you can see that the Copy

Status column now indicates that the copy of the database on serverEX02is Mounted.

Figure 14: New Active Database Copy

To perform a complete server switchover, where all databases are moved from one mailbox server to another,

theSwitchover Server option can be selected from the action pane when the relevant mailbox server is

highlighted in the EMCsServer Configuration -> Mailboxview. I will leave you, the reader, to discover and test

out these processes in your own time.
http://technet.microsoft.com/en-us/library/aa998651.aspxhttp://technet.microsoft.com/en-us/library/aa998651.aspxhttp://technet.microsoft.com/en-us/library/aa998651.aspxhttp://technet.microsoft.com/en-us/library/aa998651.aspxhttp://technet.microsoft.com/en-us/library/aa998651.aspxhttp://technet.microsoft.com/en-us/library/aa998651.aspx


11/11

Summary

That concludes the final article of this two-part series on creating and configuring a two-node DAG solution

using Exchange 2010. If you have followed both parts of this article, you will now have a solid understanding of

the steps required to construct a simple two-node DAG, as well as how to configure and use it.

Whilst there is no doubt that Microsoft has produced a compelling mailbox database high availability feature in

Exchange 2010, you should be fully aware that the DAG is only one aspect of a truly highly available messaging

infrastructure. Other key components, such as the Client Access Server role, the Hub Transport server role,

Active Directory, DNS, and so on, all have to be planned and implemented with Exchange 2010 high availability

in mind.

Documents

Exchange 2010 DAG creation Part 2