Installing Microsoft Exchange Server 2010 – Step by Step Guide (Part 3)


Introducing Database Availability Groups

Today we start talking about DAG or Database availability group, and to get a full picture about the enhancement that has been proven with the DAG concept coming out with Microsoft Exchange Server 2010 we need to compare it to the former high availability solutions for Mailbox servers that all depended on Microsoft Cluster Services MSCS which needed to be installed and configured first before installing your Mailbox servers while Exchange 2010 introduces the concept of Incremental Deployment which is the ability to deploy service and data availability for Mailbox Servers and Databases after installing Exchange server, that’s why i already Talked about Installing all Exchange 2010 roles in Part 2 of this series.

Exchange 2003 and earlier provided redundancy only at the Hardware level as the Cluster nodes would share the same storage working in an Active/passive model and that made the Storage a single point of failure. With the release of Exchange 2007 the Exchange server architecture was different, now that different roles are available, each for a specific job.. and so was the High availability and disaster recovery features in Exchange 2007 . Exchange 2007 introduced different High availability solutions each would target a specific organization category wither its small , medium or enterprise organization.

With Exchange 2010 all previous clustering scenarios like Local continuous Replication ( LCR ) ,  Cluster Continous replication ( CCR ) and others , no longer exist .. the only way to achieve High availability in Exchange 2010 is by using DAG.

So Basically with DAG you could have up to 16 mailbox member servers in each group, Each Mailbox server has it’s own Database Copy along with it’s log files. and you could even have Mailbox Servers in different active directory sites within the same Domain as members of the same DAG, and have them replicate together. With Exchange 2010 high availability using DAG is much more simple in my opinion.

So now we will start to prepare our two DAG nodes by configuring network communication between them. each node needs two network cards, one dedicated for MAPI connections and the other is dedicated for  replication between DAG members. It is possible to use a single NIC for both MAPI and replication, yet it is recommended to isolate them.


.once you have configured your IP Addresses on each NIC you need to go the the Network advanced settings and make sure the MAPI NIC is at the top of the list.


Now that we have configured our network cards , you should prepare your storage that will hosts Exchange Databases and Log files, a good design here would serve you well when it comes to overall performance. for example it is recommended that you isolate your Database edb file from the Log files and place them on a separate volume that is backed up by a different set of physical disks, also RAID considerations is very important like for example using a RAID 5 for your DB files and Raid 1/0 for your Log files. it always comes down to a performance VS capacity calculation.

once you have your storage in place, you should start with creating your DAG and perform the necessary configurations using Exchange console, from the organization level configuration.

So by default Exchange installation creates a database instance on each Mailbox server. the default path is on the default Exchange Server installation folder. typically we are going to need to move those database files to the newly configured storage volumes, or even delete those and create new ones, whatever suits you.

personally i will make use of the created Databases to take a change and show you how to move Database files between different locations. as shown below you can see a summary of the Databases in your environment in the upper section, when you select a database  from there all associated copies for this Database will show up in the lower section along with their location ( i.e. Mailbox Server )


So my first step would be to rename those default databases to a more convenient name for myself. you can do this simple by going to the Database properties and change the name.


Okay, now it is time to create our first Database availability group DAG in the environment.


Choose a name for your DAG. then you need to configure the file share witness, but when do you need to configure this ? if you noticed it is an optional configuration not mandatory . that is because it depends on your installation requirements.

and to understand this you need to have a background on how MS cluster services work , the concept of Quorum, Node majority and Voting Algorithm. i actually wrote about this before in an SQL Cluster implementation article, you can read it from here https://theadminsguide.net/2014/05/20/sql-server-2012-failover-cluster-installation-step-by-step-guide-part-1/ it would give you a good idea about what that is.

now considering that we have an even number of Mailbox nodes (2) then we are going to configure the File share witness settings, the file share witness should be a folder on any server other than the DAG members, the only requirement is , if it is not an Exchange server ( a HUB server for example ) then you need to make sure that the Exchange Trusted Subsystem group is added to the Local Administrators group of that server, so that Exchange could have full access on this share.


Assign the correct permissions on the Server hosting the Share Witness directory


Now it is time to add member to the created DAG 🙂


You can select multiple Mailbox servers in the same step. Click on Manage once done. and wait for the Wizard to finalize adding the select mailbox servers to the DAG.


in the process of adding the Mailbox nodes to your DAG cluster services is being installed and configured on both nodes automatically, you do not have control over this and you do not actually need to. if you go to your server manager you will find that Failover Clustering is installed.


If you open your Failover cluster console you will the details of your cluster, most noted is the Cluster Name DAG01 is offline, and this happens if you do not have a DHCP in place, so to solve this you are going to need to add a static IP Address for the Cluster name to bring it online. You will actually receive a warning about this once the Membership wizard finishes adding the Mailbox nodes to the cluster and you could safely ignore it


Unfortunately there is no way to do it from the console, and we are going to need to open the Exchange management shell and use it to assign a static ip for the Cluster name DAG01. so first run the below command to view the current DAG configuration.

Get-DatabaseAvailabilityGroup | fl

That would show the entire DAG configuratio, and you would observe that the IPv4Address value is Null


Now the following command will assign a new IP address to the you DAG Cluster

Set-DatabaseAvailabilityGroup -Identity DAG01 -DatabaseAvailabilityGroupIpAddresses “IP Address”


Now the Cluster resource should be online



Check the File share witness folder, make sure that Exchange was able to access and write to that folder


Now you have a new DAG with members configured, you should go to the DAG network settings and start configuring them, as you remember we had to NICs for each node, one used for client connections and the other is used for Database replication between DAG members, so as shown below i have renamed each network to reflect its purpose, and i have disabled replication on the MAPI network to fully dedicate it to client connections.


OK it is time we finalize our DAG implementation by creating Database copies on Mailbox nodes, this is pretty straight forward from the Exchange console.


Select the Mailbox nodes where you want a copy of this database, please note that the volume where you are going to host the Database and logs on must be identical in terms of drive letter and the size has to be at least as the source. if you get an error at the end of the following wizard do not worry this happens if the network communication is slow between mailbox nodes you can safely move on and later you can resume the replication process.


Okay with this this step we have finalized this article of installing Microsoft Exchange Server. Hope that was informative .


Good Luck 🙂

Related Articles

Installing Microsoft Exchange Server 2010 – Step by Step Guide (Part 1)

Installing Microsoft Exchange Server 2010 – Step by Step Guide (Part 2)

2 thoughts on “Installing Microsoft Exchange Server 2010 – Step by Step Guide (Part 3)

  1. Pingback: Installing Microsoft Exchange Server 2010 – Step by Step Guide (Part 2) | TAG

  2. Pingback: Installing Microsoft Exchange Server 2010 – Step by Step Guide (Part 1) | TAG

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s