Installing an Exchange Server 2013

Database Availability Group

JANUARY 30, 2013 BY PAUL CUNNINGHAM 117 COMMENTS

inShare3

The first article in this series on Exchange Server 2013 Database Availability Groupsprovided an
overview of Exchange 2013 DAG concepts.
In this article well go through the installation of a simple Exchange 2013 DAG with two
members. The DAG will have a MAPI network as well as one replication network. The file share
witness will be another member server in the domain that has no Exchange 2013 server roles
installed.

PREPARING TO DEPLOY AN EXCHANGE

SERVER 2013 DATABASE AVAILABILITY
GROUP
INSTALLING THE MAILBOX SERVERS
Database Availability Group members run the Mailbox server role. Although they can also run
the Client Access server role this is separate and not required for DAG operations. In some
situations the Client Access role should not be installed on the same server, for example:

if you plan to use Network Load Balancing for Client Access server high availability
(NLB is not supported to co-exist with the Failover Clustering that DAGs leverage)

if you have any reason to believe you might later remove the Client Access server role
(removal of a single server role is not possible in Exchange Server 2013)

Exchange Server 2013 can run on both Windows Server 2008 R2 and Windows Server 2012.
However, due to the dependency on Failover Clustering you should note the following
requirements:

Windows Server 2008 R2 must be Enterprise edition to support Failover Clustering

Windows Server 2012 can be either Standard or Datacenter edition

To install your Exchange Server 2013 DAG members:

Install the appropriate pre-requisites for Windows Server 2008 R2 or Windows Server
2012
Install Exchange Server 2013 on the servers

In my example scenario I have two servers E15MB1 and E15MB2 both running Windows Server
2012. Each server is installed with both the Client Access and Mailbox server roles. A third
server E15FSW exists for the file share witness.

Note: thanks to the concept of incremental deployment a DAG can be created using existing
mailbox servers that are already in production with active mailboxes on them. There is no hard
requirement to build brand new mailbox servers to be able to deploy a DAG.

CONFIGURING PERMISSIONS ON THE FILE SHARE

WITNESS
Because the file share witness server is not an Exchange server some additional permissions are
required. The Exchange Trusted Subsystem group in Active Directory must be added to the local
Administrators group on the server.

The file share witness also requires the File Server feature installed.
PS C:\> Add-WindowsFeature FS-FileServer

And you should verify that File and Printer Sharing is allowed through the firewall.

If the file share witness is another Exchange server, such as a Client Access server, it already has
the correct permissions configured.
For more information see:

Using a Non-Exchange Server as an Exchange 2013 DAG File Share Witness

CONFIGURING NETWORKING FOR EXCHANGE 2013

DATABASE AVAILABILITY GROUPS
In this example each server is connected to the 192.168.0.0/24 network, which is the clientfacing network. The two Exchange servers are also connected to the 10.1.100.0/24 network
which will be used for DAG replication traffic.

Dedicated replication networks are not a requirement for Database Availability Groups, however
if you do choose to deploy one or more replication networks you must ensure that DNS
registration is disabled the network interfaces connected to those networks.

The replication interfaces are also not configured with a default gateway. In the case where
replication interfaces for the same replication network are on separate IP subnets, static routes
are configured. However in this example that is not required.

The configuration of the network interfaces is important for DAG network auto-config to be
successful. For more information see Misconfigured Subnets Appear in Exchange Server 2013
DAG Network.

CONFIGURING EXISTING DATABASES

In my example the server E15MB1 and E15MB2 had databases that were automatically created
during Exchange 2013 setup. To prepare for database replication within the DAG I performed the
following tasks:

Mailbox Database 1 on E15MB1, which already contains active mailboxes, has

beenmoved from the default folder path onto storage volumes dedicated to databases and
transaction log files

Mailbox Database 2 on E15MB2, which contained no mailboxes, has been removed

from Exchange

Those steps may not be required in your environment depending on your existing databases.

PRE-STAGING THE CLUSTER NAME OBJECT

Depending on your environment the pre-staging of the Cluster Name Object (CNO) may be
required (it is a requirement if you are running Windows Server 2012 for the DAG members),
but in any case it is a recommended best practice.
The CNO is simply a computer account object in Active Directory. There are two methods you
can use to create the CNO.
The first is to manually create the CNO using Active Directory Users & Computers. Create a
new computer object with the name that you intend to give to your DAG. Then disable the
computer account.

Next, grant the computer account for the first DAG member Full Control permissions for the
CNO computer account. Note that you may need to click the View menu in AD Users &
Computers and enable Advanced Features before you can see the Security tab for the computer
object.

The other method for creating the CNO is to use Michel de Rooijs Cluster Name Object PreStaging script.

DEPLOYING AN EXCHANGE SERVER 2013

DATABASE AVAILABILITY GROUP
CREATING THE DATABASE AVAILABILITY GROUP
In the Exchange Admin Center navigate to Servers -> Database Availability Groups and click
the + icon to create a new DAG.

Enter the following details for the new Database Availability Group:

DAG name this should match the CNO you pre-staged earlier

Witness server this is required for all DAGs, even those that have an odd number of
members and hence run in node majority quorum mode

Witness directory this is optional. If you do not specify a directory Exchange will
choose one for you.

IP address the DAG requires an IP address on each IP subnet that is part of the MAPI
network. If you do not specify IP addresses the DAG will use DHCP instead.

Click Save when you have entered all of the required details.

ADDING DATABASE AVAILABILITY GROUP MEMBERS

After the DAG has been created it still does not contain any actual members. These need to be
added next.
Highlight the new Database Availability Group and click the icon to manage DAG membership.

Add the servers that you wish to join the DAG and then click Save. This process will install and
configure the Failover Clustering feature of Windows Server 2012 and add the new DAG
members to the cluster.

Note: if youre using a non-Exchange server for the file share witness, and you have correctly
configured the permissions on the FSW, you will still see a warning at this stage that the
Exchange Trusted Subsystem is not a member of the local administrators group on the FSW. This
is a bug that can be disregarded.

When the operation is complete the Database Availability Group will display the members you
added.

In the next part of this series we will look at configuring the database copies in the DAG.

inShare3