Microsoft Exchange Server 2010 introduced a new high availability feature called the Database Availability Group (DAG). This tutorial describes how Database Availability Groups work in Exchange Server 2010, as well as demonstrating the steps for deploying a DAG using Exchange Server 2010 SP1 and Windows Server 2008 R2.
Exchange Server 2010 Database Availability Group Overview
A Database Availability Group is a group of up to 16 Exchange Server 2010 servers that are installed with the Mailbox server role. Each server that is a member of the DAG is capable of hosting active or passive copies of mailbox databases that reside on servers in the group.
For example, a Database Availability Group may consist of three Exchange Server 2010 Mailbox servers, each configured with a single Mailbox database. Each server that is a member of the DAG can host either an active or passive copy of each of the three total mailbox databases.
Exchange Server 2010 Database Availability Group Example
The foundation of an Exchange Server 2010 Database Availability Group is Windows Failover Clustering. However unlike traditional Exchange server clusters which existed in an active/passive state, and in which the entire cluster group needed to failover to an alternative node together, with Exchange 2010 DAGs each mailbox database can failover (or switchover, if it is a deliberate move) to another DAG member independent of the other mailbox databases in the DAG.
This means that any given Mailbox server in the DAG can host all, some or none of the active mailbox copies at any given time. This capability provides two immediate advantages over previous clustering models:
- All of the Mailbox servers within the Exchange 2010 DAG can be active and in use at all times to some capacity
- Each mailbox database can failover/switchover when necessary without impacting the mailbox users connected to other mailbox databases within the DAG, for example when installing updates on DAG members
Understanding Quorum for Exchange Server 2010 Database Availability Groups
Because the Database Availability Group utilizes an underlying Windows Failover Cluster the concept of quorum applies. If you are not familiar with quorum consider it as basically a voting process in which a majority of voting members must be present to make a decision.
For a cluster this means that an odd number of members must be involved in the voting process for a majority decision to be made. How this applies to an Exchange Server 2010 DAG is that if you deploy a DAG with just two Mailbox servers as members (or any even number up to 16), then neither server is able to determine by majority vote whether it should make its own copy of a given mailbox database active.
To achieve quorum for a DAG with an even number of member servers another server in the same site is designated as a File Share Witness for the cluster. This is typically a Hub Transport server though it can technically be any compatible Windows server.
Database Replication in Exchange Server 2010 Database Availability Groups
There are two ways that mailbox database replication occurs between Exchange Server 2010 DAG members.
In Exchange Server 2010 RTM “file mode” replication is used. With file mode replication as each transaction log is written and then closed off (once it reaches 1Mb in size) it is then copied to each member of the DAG that also holds a copy of that mailbox database. The other members receive the file into their replay queue, and then replay the transaction log file into their own passive copy of the database.
File mode replication works fine but has an obvious shortcoming in that any transaction logs that have not yet been shipped to other servers in the DAG can be lost if the Exchange server hosting the active database copy fails. In those cases one of the other DAG members is able to bring their copy of the mailbox database online and then request missing emails be resent from the transport dumpster of Hub Transport servers within the site.
In Exchange Server 2010 SP1 file mode replication is used to bring mailbox database copies into sync with each other (eg during the initial sync process when a new database copy is added). Once they are in sync the DAG members switch to “block mode” replication. In block mode replication each database transaction is written to the log buffer on the active server and also sent to the log buffer of DAG members hosting passive copies of the database.
When the log buffer becomes full each DAG member then builds their own transaction log files from their own log buffer. Block mode replication has an advantage over file mode replication in failure scenarios, because each DAG member is completely up to date with all changes to the active database.
Note that Public Folder databases can reside on Mailbox servers that are members of a Database Availability Group, however they are not replicated by the DAG itself. Instead you must use Public Folder replication to provide redundant copies of Public Folder databases.
Other Advantages of Exchange Server 2010 Database Availability Groups
Before we proceed with an example of how to install an Exchange Server 2010 DAG I will also mention some of the other advantages of Database Availability Groups.
- Unlike previous versions of Exchange Server (particularly Exchange Server 2007) Exchange Server 2010 has just one high availability feature for Mailbox servers for all high availability deployment scenarios
- When you create a Database Availability Group the underlying Windows Failover Cluster is automatically created and configured for you
- A Database Availability Group can be created at any time without requiring Exchange Server 2010 to be removed and reinstalled from the server, unlike previous versions that required that clusters be established first before Exchange was installed
- Exchange Server 2010 DAG members can host other server roles, unlike Exchange Server 2007 that prevented clustered Mailbox servers from hosting other roles
Exchange Server 2010 Installation Step by Step
In this tutorial I will demonstrate the installation of an Exchange Server 2010 Database Availability Group on Windows Server 2008 R2.
For this tutorial the following Exchange servers have already been installed.
- EX1 – Exchange Server 2010 SP1 Mailbox server
- Primary interface: 192.168.0.32/24
- Secondary interface: 10.0.5.1/30
- EX2 – Exchange Server 2010 SP1 Mailbox server
- Primary interface: 192.168.0.33/24
- Secondary interface: 10.0.5.2/30
- EX3 – Exchange Server 2010 SP1 Client Access and Hub Transport server
- Primary interface: 192.168.0.34/24
Note: for details of how to deploy these server roles see Installing Exchange Server 2010 Pre-requisites on Windows Server 2008 R2 and Installing Exchange Server 2010.
Exchange Server 2010 DAG Tutorial Setup
Each of the Mailbox servers has been configured with its own mailbox database.
- EX1 – Mailbox Database 01
- EX2 – Mailbox Database 02
Note: in Exchange Server 2010 each mailbox database must have a unique name within the organization.
Because the Mailbox servers are configured with dual interfaces it is important to make sure that the secondary interface is not configured to register itself in DNS. Open the TCP/IPv4 properties for the secondary interface one each server, click the Advanced button, navigate to the DNS tab and untick Register this connection’s address in DNS.
Open the Advanced TCP/IPv4 Properties
Disable DNS registration for the secondary interface
Creating the Database Availability Group
Log in to one of the Mailbox servers and launch the Exchange Management Console. Navigate to Organization Config/Mailbox and choose New Database Availability Group from the action pane.
Create a new Exchange Server 2010 Database Availability Group
When the New Database Availability Group wizard starts give the DAG a name, specify the Witness server, and also specify the file path for the Witness server to use.
New Database Availability Group Wizard - Basic Info
Click on the New button to create the new Database Availability Group, and then click Finish to close the wizard.
Adding Database Availability Group Members
Right-click the newly created Database Availability Group and choose Manage Database Availability Group Membership.
Manage Database Availability Group Members
Click the Add button and select the Mailbox servers that you wish to make members of the DAG.
Select Mailbox Servers to become Database Availability Group Members
Click the Manage button to commence adding the Mailbox servers to the DAG. This involves installation and configuration of Windows Failover Clustering on the servers, so it can take a few minutes to finish.
After it has finished the next step is to configure the DAG networking.
Configure Database Availability Group Networking
Right-click the newly created Database Availability Group and choose Properties.
Open the Properties of the Database Availability Group
Select the IP Addresses tab, click the Add button and add a static IP address for the Database Availability Group.
Adding IP addresses to an Exchange Server 2010 Database Availability Group
You will notice that the Database Availability Group has been automatically configured with DAG networks for the subnets that the DAG members have network interfaces connected to.
Exchange Server 2010 Database Availability Group Networks
Open the Properties of each DAG network and configure them with meaningful names. If you have configured your network to have a dedicated replication network for the DAG then you should disable replication on the DAG network that is intended for MAPI communications (ie client connections).
Exchange Server 2010 Database Availability Group Networks Configured
Adding Mailbox Database Copies to DAG Members
With the Database Availability Group established and the networking configured you can now add mailbox database copies to other DAG members.
In the Exchange Management Console navigate to Organization Config/Mailbox and choose the Database Management tab. Right-click a mailbox database and select Add Mailbox Database Copy.
Adding a Mailbox Database Copy in Exchange Server 2010
Click the Browse button and choose the Mailbox server to add the database copy to.
Add Mailbox Database Copies to an Exchange Server 2010 Mailbox Server
Click the Add button to add the mailbox database copy and then click Finish to close the wizard.
The Exchange servers will now commence seeding the replica servers with an up to date copy of the database and all of the current transaction log files. Depending on the amount of data to be replicated this may take some time.
Status of the Database Copies for Exchange Server 2010
Repeat the same process for any other mailbox databases you wish to add database copies for.
Configuration of the Exchange Server 2010 Database Availability Group is now complete.
About Paul Cunningham
Hi there,
Highly appreciated your DAG configuration article and your plain English explanation is very helpful.
Thanks and awaiting for more new articles
regards
Great Article Paul.Really Helpfull…Keep on going..We are here to hear from you again.
Thanks,
Really very effective presentaion shared.. to follow this , who is having less knowledge of DAG can also configured easily.
Thanks.. Buddy . keep it UP !!
Good Article.I just had a doubt , it the there is Clustering between the servers, how does the external world know the Exchange server name? What is EVS Name Here ? Which will be used to configure the outlook for end users if required ?
Hi Sam, when you create the new DAG you give it a name as one of the first steps, and later configure an IP address for it. That is the name that the DAG will be known by. There is a Failover Cluster underlying the DAG, but Exchange creates and configures that all itself when you create the DAG, so there is nothing for you to worry about there. The cluster service registers the DAG name and IP in DNS as well.
Clients don’t connect directly to the DAG, they connect to either a single Client Access server or a Client Access Server Array (CAS Array) instead. Here is a tutorial for creating CAS Arrays:
http://exchangeserverpro.com/how-to-install-an-exchange-server-2010-client-access-server-array
You can also see Exchange 2010 high availability in action in this video:
http://exchangeserverpro.com/exchange-server-2010-high-availability-demonstration-video
Hope that helps clear things up for you.
Paul,
need some advice, I have HP Blade Servers and running VM so creating servers is not an issue. So how would you setup exchange 2010 with high Availability with cluster failover.
any help would be great
love reading past post have learned alot from them.
Cecil, if you want to mix VM and DAG just make sure you read Microsoft’s support statement on that scenario. It is pretty straight forward.
Thanks dude.I am highly appreciate to you , it helps me so much.
Paul
When I go to add the database copy, it does not give me the option of the other mailbox role server to choose from, it only shows the the current mailbox server that the database is sitting on
After creating the DAG did you add the additional mailbox servers as members of the DAG first, before trying to add database copies?
It does not show up there as well, ( I probably should have started with that) I created the DAG on EX 2 when, and when I go to manage database database availability group membership to add EX1 it does not give me the option to EX 1 as well
Ok so lets step back a little and try to work this one out. First the basic stuff:
Is EX1 an Exchange 2010 server?
Is EX1 installed as a Mailbox server?
Is EX1 already a member of an NLB cluster?
Is EX1 installed on Enterprise version Windows Server?
Does EX1 appear as you’d expect in Get-ExchangeServer output?
Is the EX1 event log clear of errors?
Does EX1 have any other signs of being unhealthy?
383 >> Client Access/ Hub >> Enterprise >> 14.1
384 >> Client Access/Hub >> Enterprise >> 14.1
382 >> Mailbox >> Enterprise >>14.1
381 >> Mailbox >> Enterprise>>14.1
Yes, it is Exchange 2010
EX 381 and EX 382 are both mailbox role servers
383 and 384 are in NLB
I have to add that it is the other way around with 382 if I create a DAG on 382 and try to add 381 it will not show up – Thanks for your help !
Are both 381 and 382 Windows 2008 Enterprise?
yes they are
Hmmm. Well, a mailbox server can only be a member of one DAG at a time. I don’t suppose you’ve accidentally created two DAGs, and so the other server is already a member of a DAG and can’t be added to another one?
If you run Get-DatabaseAvailabilityGroup do you see one or two DAGs in the results?
Hi Paul, This is really helpful article for exchange administrator, to understanding DAG feature in depth for who wondering here and there..This really make me comfortable in case of DAG functionality.
Hope, you will keep posting such article in future also.
Regards
Rajnish
hi Paul,
very usefull and easy to understand with illustrations. i have a question. do we have to install the 2 mailbox-server-role servers from the begining and create the DAG, add the 2 MBX servers at the same time ? or we can create a DAG and add one MBX server then add the second MBX later ? as we know that the DAG can tolerate one MBX down for a short time (with the witness share evidently).
You can create the DAG and add members at any time you wish, even after you’ve already added mailboxes to the databases on those servers. Microsoft calls this “incremental deployment”.
Regarding the DAG and Replication network, we’ve been having issues setting these up and replicating across. I’ve seen several recommendations regarding certain protocols to disable for the Replication Adapters which did not change our results. Also some stating to put DHCP enabled for replication adapters? Following your guide was not sure on your experience with the specifics. But also to be clear when setting up the IP address of the DAG, it should be an IP on the Production Network, NOT replication?
This is really helpful article for Exchange Server Installation with Database Availability Groups. Simple way of create nods because this steps GUI based .
i made a VM of exchange server 2010 sp2 which is connected to a child domain i.e customer and nw i want to make another vm of exchange server in which i want to install DAG and this shoud also connected to that child domain(customer). plsssssss tell me, what to do?????? plssssssssss
HI thanks for above article we’ve successfully created DAG in Exchange 2010 SP1
Do u have any article how to install Exc 2010 SP2 in a Child domain controller
Please help me on this i’m new to this concepts
Thanks
Hi Paul,
Can I ask your advice on something – I’ve an existing DAG with 2 MBX servers but after installing Exchange SP2 parts of the underlying cluster are failing: When i look in Failover Cluster Manager (2008R2) i see that the Cluster Name (dagarray) is in a failed state and I think this is because there used to be an IP Address as a dependancy which has now vanished. I’ve tried removing and adding that IP address back in through EMC but it doesn’t solve the issue though EMC warns me that ‘dagarray’ is not online.
I’ve Googled a lot and am beginng to think that I need to create a new DAG so that Exchange resets everything nicely. I’m a little concerned about this as I have 700 mailboxes spread across 13 databases. If I switchover all the databases to one of the MBX servers and then create a new DAG, remove that server from the old DAG and put it in the NEW DAG will the mailboxes be okay? If I then move the 2nd MBX server out of the old DAG and put it in the new DAG and then delete the old DAG, will everything be happy?
Any advice you can offer woudl be much appreciated,
thanks.
I have no advice on that one other than to open a Microsoft support case
Paul,
Great wite up on DAG. I wanted to implement this feature in our datacenter and wanted to ask you some questions on setting up 2 Exchange 2010 server.
Office- Domain A- 2008R2 and Exchange 2010
1: Datacenter- Do I create a fresh domain without connecting to Office domain? Totally seperate domain name?
2: Where do I attach the 2nd datacenter Exchange server? the main office or 2nd new domain?
3: If for X reason 1st Domain / Exchange server goes down, how would you configuer to 1st repoint all outlook clients to datacenter AUTOMATICALLY?
Thanks for any insight on this.
Jerry
What you’re asking about is site resiliency, so what I always recommend is to read the most authoritative article series on the topic, starting here:
http://www.msexchange.org/articles_tutorials/exchange-server-2010/management-administration/planning-deploying-testing-exchange-2010-site-resilient-solution-sized-medium-organization-part1.html
Can you advise if it’s possible to set this up as a POC on VMs?
Also how much time would be required for the installation and testing on such a scenario?
Thanks for the detailed post.
Cheers,
Ozz.
Hi Paul, This is really helpful article for exchange administrator, to understanding DAG feature in depth.
Thanks a lot for this.
Regards,
Avishek
Hello
But i thing in ur example EX3 becomes a single point of failure
how can i avoid that???
The DAG provides HA for the Mailbox server role. If you also want HA for the Client Access and Hub Transport server roles you would deploy two or more of those, and in the case of the Client Access servers configure a load-balanced CAS Array.
For more info read:
http://exchangeserverpro.com/exchange-server-2010-cas-array
Thanks
but is it possible for the same servers (EX1 and EX2) to have Client Access and Hub Transport server roles installed with load-balanced CAS Array configured on them with DAG?? and EX3 acts as a normal file server???
Yes, but when the servers are DAG members you need to use hardware load balancers for the CAS Array, not Windows NLB.
why not NLB??
NLB is not supported when the server is also a DAG member because the DAG uses Failover Clustering, which is not supported to co-exist with NLB.
Basically NLB and Failover Clustering can’t be used on the same server, so an Exchange DAG member can’t also be an NLB member.
Thanks – this is very helpful, but a question about IP address segments. In your example you have the replication running in 10.0.5.0/30 and primary running in 192.168.0.0/24. Could I have replication running in the same subnet as the primary?
You could. Though one of the benefits of dedicated replication networks is to completely segregate them from the primary network in terms of performance, resilience, etc.
Thank you for the article. Quick question regarding the replication network. If I have a 2 node DAG, am I able to just connect the 2 servers directly via ethernet instead of the replication network going via a switch since the replication network don’t need to any other server?
I can’t think of any reason why not.
I have a situation where a previous admin setup a DAG and CAS array with the same name and IP, so the DAG is called DAG and CAS array is called DAG with the IP of the Database Availability Group. Surprisingly enough the users are having RPC connection issues to the Exchange servers. My thought is to just redo the actual DAG and leave the CAS array since clients are connecting to the CAS array name already. Have you run into this before or have any articles?
I would change the IP address of the DAG so they are no longer conflicting. You don’t need to completely rebuild the DAG though.
Will changing the IP have any outage on the users or databases? I do not have a multi server lab to test I am working through the single server on your bootcamp.
It shouldn’t impact service for users, though I’d still recommend doing it out of hours anyway.
Another great article, thanks.
I’ve inherited a pickle of a system, 2 x Win 2012 DCs, with Exchange 2010 SP1 installed on them both and configured in a DAG that appears to never of worked properly! I think I’m ok with removing one of the DAG members assuming it works ok.
What is the process of removing the last member of a DAG?
Hi Paul,
Very Nice documented article . Thanks for sharing .
Keep up your great work .
Regards
Harsh
I have a cross site two mailbox server configuration with DAG. Each MB primary network interface has a DHCP reservation. DAG has dynamic DHCP assigned. Is it normal for DAG to register its IP address for both DAG and MB Server name? e.g. Clients of one server are connecting via outlook to the IP of the DAG vs the IP of the MB Server name.
The server NICs should have static IP addresses, not DHCP reservations.
The DAG IP can be dynamic, though I prefer to assign a static IP to it (one per subnet that contains DAG members).
The DAG name itself will be registered in DNS and should update itself if the PAM role moves to a different subnet. However clients do not connect to the DAG name, they connect to the RPCClientAccessServer name.
So the only way I can think that you would see clients showing connections in Outlook to the DAG IP is if you’ve used the same name of the DAG itself as the RPCClientAccessServer on your mailbox databases, which is not a correct configuration.
If its possible to create DAG, in which 3 exchanges(2010) is present in different domains and all the servers roles is present in the exchange.
or is it possible to create DAG, in which 3 exchange(2010 sp1) is present in same domain and all the server roles is present in the exchange ?