How to move from a Single Server to High Availability with DAG


A lot of small or medium sized companies started with a single Exchange Server box without any thoughts on high availability. The reason for this was that, especially with Exchange Server 2007, the high availability features have been so complex, that they don’t want to talk about them or that they never thought they really needed a high available messaging solution.

With Exchange Server 2010 things have changed: the new Database Availability Feature (so called DAG) makes high availability easier than before. Indeed, they don’t need to buy the Enterprise Edition of Exchange Server to provide high availability, the Standard Edition is enough.

Within this article I will describe an easy and perfectly working solution to migrate from a single server Exchange Server 2010 solution to one with high availability using Database Availability Groups.

Definition of a Database Availability Group (DAG)

With Exchange Server 2010, all high availability solutions that came with Exchange Server 2007 (called LCR, CCR, SCR and SCC) are moved to one feature called “Database Availability Group” (or in short, DAG).

DAG is available on Exchange Server 2010 Standard and Enterprise Edition. It does however rely on Windows Server Clustering which is available on Windows Server 2008 Enterprise or higher, you need the Enterprise Edition on the underlying Windows Operating System but with Exchange you only need the Standard Edition.

With this new feature you have the possibility to create database copies from each Exchange mailbox database to 15 other Exchange Servers running the Mailbox Server role using log file shipping. So Windows Server 2008 can handle that number of Mailbox Servers using the Failover Clustering Feature because it supports up to 16 servers per cluster.

DAG provides automatic failover; in case of an error on the database running on one mailbox server there is an automatic switch to another server although hosting the same database. In addition you can configure a “self-healing” feature for the databases so that in the event of an error in one database you can re-replicate all data back to that database which is in error state.

Database Availability Group Deployment Plans

If you are thinking of moving to the new DAG feature, you should think of some more things that may come around during this migration project:

  1. Mailbox Server high availability is based on DAG and DAG is based on Windows Failover Clustering – You cannot provide high availability for Client Access or Hub Transport on the same machine because these roles can only be set to high availability using Network Load Balancing (NLB)
  2. You need to provide cluster functionality in your environment – This means you need to create a separate heartbeat LAN.

Based on the  facts above, providing real high availability means you should have to think of the following server structure:

  • 2 x Domain Controllers
  • 2 x Exchange Mailbox Servers for DAG
  • 2 x Exchange Servers with Client Access and Hub Transport within a Network Load Balancing Cluster

Deployment and Migration

So if you move from an all-in-one server solution to a DAG based high availability solutions, you just need to perform the steps described below. You should however make sure that you are running these tasks during non-business hours, because you will have to restart the existing server more than once. In addition you are moving the Hub Transport and Client Access role to other servers which may result in disconnections and the risk of dropping email connections since your internal Exchange environment will not hold the queues during the unavailability of these features. I suggest placing Exchange Edge Servers in front of your messaging environment in the DMZ (also called Perimeter Network).

  1. Make sure that Windows Server 2008 R2 Enterprise Edition or higher is installed (if not you need to run an in-place upgrade)
  2. Create a second dedicated Private LAN for the cluster heartbeat available to connect on both DAG servers
  3. Install the Windows Failover Clustering Role on the formerly single Exchange Server
  4. Configure the Failover Clustering feature on the server
  5. Configure the DAG feature on Exchange Server 2010
  6. Move all mailboxes from the old mailbox store to the new DAG based mailbox store
  7. Decommission the old non high available mailbox store

Now we have one Exchange Server running a DAG but not providing any high availability features at all.

We then need to prepare the new Exchange Servers for Client Access and Hub Transport as follows:

  1. Install Windows Server on both new servers (Standard Edition is enough, because it already provides Network Load Balancing)
  2. Configure Network Load Balancing on both servers
  3. Install the Exchange Server 2010 Client Access and Hub Transport role on both servers
  4. Configure Client Access and Hub Transport role to run in a network loading balancing environment
  5. Remove the Client Access and Hub Transport role from the formerly single Exchange Server

Afterwards we need to put the second mailbox server that will host the DAG in the future online, this will be done as follows:

  1. Install Windows Server Enterprise Edition on the new server
  2. Install Exchange Server 2010 Mailbox Server Role on the new server
  3. Configure this new Exchange Server to host the DAG-Dabase(s)

After having finished all these tasks your Exchange Server 2010 messaging environment will run a highly available Exchange infrastructure. You never need to think of single server failures anymore. There is one thing you should not forget; make sure to add all your Exchange Servers into your backup infrastructure. In addition, you should think of placing 50% of the servers (this means one for each Exchange role) into your backup datacenter in another building. Window Server 2008 R2 Failover Clustering is designed to support spread clusters even across subnets.


As you have seen in this article there is a supported solution with Exchange Server 2010 to move from a single server infrastructure to a new high available messaging solution without completely decommissioning the former single server totally. The migration path is smooth and easy to handle if you know what you are doing and you are running your “step-by-step” walkthrough discussed above.

For further questions please don’t hesitate to contact me.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

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

Scroll to Top