Instead of typing in the user’s name in the To: field, click the To: button and select their Exchange address from the Global Address List. I suspect that I simply allowed auto-complete to fill in the user’s name when I typed the first few letters and it was not actually the Exchange account but another of the user’s email accounts that I had previously named with the same username.
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.
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 client-facing 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 been moved 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 Rooij’s Cluster Name Object Pre-Staging 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 you’re 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.
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.
Microsoft Exchange Server 2013 includes a component called Active Manager that manages the high availability platform that includes the database availability group (DAG) and mailbox database copies. Active Manager runs inside the Microsoft Exchange Replication service (MSExchangeRepl.exe) on all Mailbox servers. On Mailbox servers that aren’t members of a DAG, there is a single Active Manager role: Standalone Active Manager. On servers that are members of a DAG, there are two Active Manager roles: Primary Active Manager (PAM) and Standby Active Manager (SAM). PAM is the Active Manager role in a DAG that decides which copies will be active and passive. PAM is responsible for getting topology change notifications and reacting to server failures. The DAG member that holds the PAM role is always the member that currently owns the cluster quorum resource (default cluster group). If the server that owns the cluster quorum resource fails, the PAM role automatically moves to a surviving server that takes ownership of the cluster quorum resource. In addition, if you need to take the server that hosts the cluster quorum resource offline for maintenance or an upgrade, you must first move the PAM to another server in the DAG. The PAM controls all movement of the active designations between a database’s copies. (Only one copy can be active at any specified time, and that copy may be mounted or dismounted.) The PAM also performs the functions of the SAM role on the local system (detecting local database and local Information Store failures).
The SAM provides information on which server hosts the active copy of a mailbox database to other components of Exchange that are running an Active Manager client component (for example, Client Access or Transport services). The SAM detects failures of local databases and the local Information Store. It reacts to failures by asking the PAM to initiate a failover (if the database is replicated). A SAM doesn’t determine the target of failover, nor does it update a database’s location state in the PAM. It will access the active database copy location state to answer queries for the active copy of the database that it receives.
Microsoft Exchange Server 2010 includes a new component called Active Manager that provides functionality that replaces the resource model and failover management features provided by integration with the Cluster service in previous versions of Exchange. Exchange no longer uses the cluster resource model for high availability. All Exchange cluster resources provided by exres.dll no longer exist, including the construct known as a clustered mailbox server. A Windows Failover Cluster is used by Exchange, but there are no cluster groups for Exchange, and there are no storage resources in the cluster. Thus, if you examine the cluster using cluster management tools, you’ll see only the core cluster resources (IP Address and Network Name, and if needed, quorum resource). Cluster nodes and networks will also exist, but those are managed by Exchange and not cluster or cluster tools.
Active Manager runs as a role on all Mailbox servers. On Mailbox servers that are not configured for high availability, there is a single Active Manager role: Standalone Active Manager. On servers that are members of a database availability group (DAG), there are two Active Manager roles: Primary Active Manager (PAM) and Standby Active Manager (SAM). PAM is the Active Manager in a DAG that decides which copies will be active and passive. PAM is responsible for getting topology change notifications and reacting to server failures. The DAG member that holds the PAM role is always the member that currently owns the cluster quorum resource (default cluster group). If the server that owns the cluster quorum resource fails, the PAM role automatically moves to a surviving server that takes ownership of the cluster quorum resource. In addition, if you need to take the server that hosts the cluster quorum resource offline for maintenance or an upgrade, you must first move the PAM to another server in the DAG. The PAM controls all movement of the active designations between a database’s copies (only one copy can be active at any specified time, and that copy may be mounted or dismounted). The PAM also performs the functions of the SAM role on the local system (detecting local database and local Information Store failures).
The SAM provides information on which server hosts the active copy of a mailbox database to other components of Exchange that are running an Active Manager client component (for example, RPC Client Access service or Hub Transport server). The SAM detects failures of local databases and the local Information Store. It reacts to failures by asking the PAM to initiate a failover (if the database is replicated). A SAM doesn’t determine the target of failover, nor does it update a database’s location state in the PAM. It will access the active database copy location state to answer queries for the active copy of the database that it receives.