How to Configure Database Availability

Group for Exchange Server 2010

Overview
Because your end users rely so much on email not only for their day-to-day communications but
also ultimately for your company’s daily operations, you need to make sure the services for
Exchange are accessible and available practically all the time. In other words, they should exhibit
High Availability.

In this article, we’ll talk about how Exchange 2010 offers High Availability, which is basically
through Database Availability Groups. We’ll then come up with a sample scenario and then
show you how to configure Database Availability Groups using that scenario. In the video lesson
below you will learn about a real world scenario that will help you configure Exchange Server
2010 Database Availability Groups.

(Instructional video below provides a walkthrough of the steps contained in this article.)
If you’re already familiar with the concepts of Database Availability Groups and simply want to
know how to configure them, just scroll down directly to the section A sample scenario.

High Availability in Exchange 2010

First of all, High Availability (HA) does not just mean that an Exchange server should be up.
Rather, that server must also be available to serve. Simply put, users should be able to do all the
things they expect to do through an Exchange service, e.g., send and receive emails, all the time.

Exchange 2010 provides HA using a feature known as Continuous Replication. In Continuous

Replication, the database is copied first and then the log files are shipped and replayed constantly
to ensure that the database stays up to date.

Figure 1: Shows System 1 and System 2

Database Availability Group and its main features

In Microsoft Exchange Server 2010, the base component of its high availability and site
resilience framework is the Database Availability Group or DAG. DAG uses continuous
replication, supports up to 16 copies of the database on 16 different servers, and employs some
clustering features like heartbeats and a File Share Witness in order to make members of a DAG
work together effectively.

Heartbeats

A heartbeat is a mechanism that enables servers to verify whether other servers in the same DAG
are still alive. Let’s say you have two servers. One server has the active copy of the database,
while the other one has a replica copy. If the second server no longer detects a heartbeat coming
from the first server, it may have to take over and make its copy of the database the active copy.

File Share Witness

To help member servers of a DAG determine with certainty that a member has in fact gone
down, Exchange Server 2010 uses what is known as a File Share Witness. A File Share Witness
serves as the referee between DAG members whenever a server ceases to give off a heartbeat
and hence appears to have gone down.

Thus, when the second server fails to receive a heartbeat from the first server, it checks with the
File Share Witness to verify whether the first server has really gone down. Only after the File
Share Witness confirms that the first server has gone down will the second server make its
database the active copy.

This prevents an issue known as the “split-brain syndrome”, wherein two servers will be
simultaneously providing the same services to end users.

The File Share Witness is a Hub Transport (HT) Server on the same DAG that shouldn’t reside
on a Mailbox (MB) Server. That doesn’t mean that HT servers can’t be installed alongside MB
servers. The restriction only applies to those HT Servers that will be used as a File Share
Witness. All other HT Servers can reside on an MB Server.

Transport Dumpster

A typical DAG also employs what is known as a Transport Dumpster. It is a feature of the HT
Server that allows it to retain copies of all emails in databases that have replicas in the DAG and
provide an update to a replica copy whenever the need arises. An update to a replica copy of the
data may be needed when a server holding the active copy of the database goes down.

So when the server holding the active copy goes down, the server assigned to take over checks
with Transport Dumpster to see whether there are copies of mail that it doesn’t have. If there are
any, those copies are added to what it already has.

Here’s a sample Database Availability Group containing two members, Mailbox1 (MB1) and
Mailbox2 (MB2). MB1 holds the active copy of the data, while MB2 holds the passive copy.
Also present is a Hub Transport Server that serves as the File Share Witness and Transport
Dumpster.

Figure 2: Shows a Database Availability Group

What you need to know before creating a Database
Availability Group
Having multiple Mailbox Servers and a Hub Transport Server that serves as a File Share Witness
and a Transport Dumpster doesn’t automatically enable High Availability. You still need to carry
out the following steps:

Step 1. Create the Database Availability Group

Step 2. Add members to the DAG

Step 3. Add copies of databases.

We’ll show you how this is done step-by-step later but in the meantime, here’s a figure showing
a setup similar to what you may end up with after carrying out those steps:

Figure 3: Shows System 1, System 2, and System 3

In this setup, we have three Mailbox Servers (Systems 1, 2, and 3), each holding one database
(DB1 resides on System 1, DB2, on System 2, and so on). Notice that each database is being
replicated on the two other servers. So DB1 has a replica on System 2 and 3, DB2 has a replica
on System 1 and 3, and so on.

So even if we lose two systems, the remaining system can take over; thus ensuring high
availability. Note however, that it will be up to you to choose how many copies (and on which
servers those copies should be) a database should have.

It is not necessary for all systems to have replicas of each database. It’s all up to you. Of course,
the more copies your databases have, the greater your DAG’s capability of providing high
availability will be.

Similarly, it is also up to you to decide how many mailbox servers should host a database. In the
alternative design below, we again have three mailbox servers: EX2K10MB1, EX2K10MB2,
and EX2K10CHMB. But notice that, while EX2K10CHMB has replicas of the databases hosted
on EX2K10MB1 and EX2K10MB2 (DB1 and DB2 respectively), it is not hosting a database
itself.
Figure 4: Shows No DB3 on Chicago site

Now that we’ve got the basic concepts covered, you’re now ready to learn how to configure
DAGs.

A sample scenario
We’ll be using the following scenario as the basis for the configurations we’ll be setting later, so
you should read this section first. Refer to the following figure:

Figure 5: Shows two sites: Site 1 in New York and Site 2 in Chicago.

Note: Those little light bulbs with a green leaf indicate virtual servers. So the Chicago site’s
CHIDC1, EX2K10CHPRIME, and EX2K10CHMB are virtual servers running on a parent server
through Hyper-V. Same is true with NYDC2, EX2K10PRIME, and EX2K10MB2.

In Chicago, EX2K10CHMB serves as that site’s Exchange Mailbox Server. In New York, there
are two mailbox servers: EX2K10MB1 and EX2K10MB2. EX2K10PRIME is a Hub Transport
Server. Notice that it doesn’t reside on a Mailbox server, so we can use it later on as our File
Share Witness.

Our mailboxes are divided only between EX2K10MB1 and EX2K10MB2 (see the design on the
fourth image above). The main function of EX2K10MB2 is to provide high availability as well
as load balancing with EX2K10MB1, while the function of EX2K10CHMB (in Chicago) is to
provide site resiliency for the New York servers in addition to providing HA.

If you notice, EX2K10MB1 is on a physical server, while EX2K10MB2 is on a virtual server.

Had we placed EX2K10MB1 on another virtual server under the same parent server as
EX2K10MB2, we would have only achieved disk resiliency but not server resiliency.

Server resiliency can only be achieved for EX2K10MB1 and EX2K10MB2 if they reside on
separate physical boxes regardless whether they run on physical servers or virtual servers.

Moving forward, if all we want to achieve is server resiliency, then we would only need to add
the two New York mailbox servers to the Database Availability Group that we will soon be
creating. However, if we want to achieve site resiliency and high availability, the DAG should
include all three mailbox servers, which is what we’ll be doing shortly.

Configuring Database Availability Groups

We’re now ready to start configuring our Database Availability Group. Just to see what you
currently have, go to the Exchange Management Console, select the Mailbox node, and click
the Database Management tab.

Figure 6: Shows if you select a database, you’ll see the Mailbox Server on which it is
running off of.

Creating the Database Availability Group

Now let’s create our DAG. Go to the Database Availability Groups tab and, in the
Actions panel, click the New Database Availability Group Wizard.
Figure 7: Shows were to click for the New Database Availabillity Group Wizard.

In the New Database Availability Group window, assign a name for the DAG (e.g. GloboHA).
After assigning a name, you’re supposed to select a File Share Witness Server and Witness
Directory. If you don’t select any, Exchange will try to find a server that can qualify. In our case
we already have one that does: EX2K10PRIME.

So all we need to do is click on the New button and Exchange will do the rest. Do that now.

Figure 8: Click New.

Figure 9: Click Finish.

Navigate to the Database Availability Groups tab and scroll horizontally until you reach the
column named Witness Server. You should be able to find your new Witness Server and
Witness Directory in there.

Figure 10: Shows your new Witness Server and Witness Directory.

Since you now have a DAG, the next step is to add members to it.

Adding members to the Database Availability Group

On the same tab, scroll back to the left until you reach the column named Name. Under that
column, find and right-click the name of the DAG you just created. When the context menu
pops-up, click Manage Database Availability Group Membership.
Figure 11: Shows you where to click the Manage Database Availability Group
Membership.

In the Manage Database Availability Group Membership window, click the Add button.

Figure 12: Click Add.

Select the servers you’d like to add to the DAG. In our case, because we want to achieve site
resiliency and site High Availability, we would have to select all three servers (review the end of
the Scenario section if you’re still wondering why). Click OK.
Figure 13: Click OK.

In the Manage Database Availability Membership window, you should see the servers you
selected. Click the Manage button.

Figure 14: Click Manage.

Figure 15: Click Finish.

Back in the Database Availability Groups tab, you should now see a bunch of information under
Networks.

Figure 16: Shows you’ve succeeded in adding members to your DAG.

You’re now ready for the final step, which is adding copies of your databases.

Adding copies of your databases

To start adding copies of your mailbox databases, go to the Database Management tab. Next,
find a database you want to copy. In our example, the database is located in the EX2K10MB1
Mailbox Server.
Figure 17: Right-click on the database and, in the context menu, select Add Mailbox
Database Copy

In the Add Mailbox Database Copy window, you should see the name of the Mailbox database
you selected. Click the Browse button.

Figure 18: In the Add Mailbox Database Copy window click the Browse button.

Select a Mailbox Server you’d like to copy the database to. e.g. EX2K10MB2, then click OK.
Figure 19: You should see the Mailbox Server you just selected in the box labeled “Server
name:”

Below that box, you’ll also see an Activation preference number. This number will be used by
Exchange to determine when this particular copy should be activated. If the number is one, then
it has top preference. 2 is the next, and so on. So if the copy with Activation preference number 1
goes down, the one with number 2 is next in line to take over.

Pick a number by using the spinner. In our example, we have 2. So that would mean
EX2K10BM2 will only take over the reins once EX2K10MB1 goes down.

The moment we add a third copy and assign it a preference number of 3, that copy will only take
over once EX2K10BM2 goes down as well.

Figure 20: Click Add.

If the screen says the wizard completed successfully, click Finish.

Figure 21: You will now see the newly added copy in the list of Database Copies for that
particular database.

Figure 22: Click Finish.

You can do the same process all over again to create additional copies for the same database or
create copies for another database. Again, you start by right-clicking the database you want to
copy and then selecting Add Mailbox Database Copy in the context menu. In our case, we
created another copy of the same database on the Chicago mailbox server (EX2K10CHMB), so
this is what we have:
Figure 23: This is what it should look like so far.

If you scroll to the right, you’ll see the Activation preference numbers you assigned for those
database copies.

To see what would happen if an active server goes down, you can simply go and shutdown your
currently active mailbox server and monitor the entire event on one server’s Exchange
Management Console.

Here’s how it looked like when we had two copies of the database (EX2K10MB2 and
EX2K10CHMB) and we shut down EX2K10MB2, which initially had the active copy.

Figure 24: Shows how it looks when there are two copies of the database.

This happens so fast, that users would not experience any lack of availability. Well, that ends our
discussion on High Availability and Configuring Database Availability Groups.

Summary
I’m sure you found this article quite long. Still, I hope you found it all worth the read. Ensuring
High Availability for your Exchange Server is well worth the work.