Creating a Database Availability Group using Exchange Management Shell

Database Availability Groups (DAGs) are the foundation of high availability and site resilience in Exchange Server 2010. Using DAGs, we can create a group of up to 16 mailbox servers that contain a set of database copies providing redundancy for mailbox databases. If a mailbox server in a DAG fails, its active database copies can be mounted on another server in the DAG.

DAGs can be designed in several ways. You can deploy a simple configuration, with just two DAG members in a single site. You can also do more advanced configurations, using multiple servers using separate physical sites.

In this post, I am going to create a simple two node DAG using mailbox servers located in a single site. The entire process will be done in Exchange Management Shell from start to finish – keep in mind you can also use EMC to create and manage DAGs, but using Exchange Management Shell gives us a little more control.

Considerations

Here are a few requirements and recommendations about DAGs that need to be taken into consideration before we get started:

• DAGs can run on Exchange 2010 Standard or Enterprise – your DAG members can be a mix of these Exchange versions.
• DAGs must run on an Enterprise OS – Since DAGs utilize Windows Failover Clustering, you need to use Either 2008 Enterprise or 2008 R2 Enterprise. All members of a DAG MUST run the same OS, don't try to mix 2008 and 2008 R2.
• Use at least two NICs in each DAG member – This is not a requirement, but a best practice. Use, one for the MAPI network and one or more for Replication. Using at least two networks enables the DAG members to distinguish between a server outage and a network outage.
• DAG networks must match – Make sure the network configuration is identical from one DAG member to the next. For example, if you are using three NICs on your first DAG member then you need the same amount on the remaining servers defined with the same networks.
• DAG NICs should be on seperate networks – Each NIC should be in its own network subnet \ VLAN.
• Use Gigabit Ethernet NICs – This almost goes without saying, but obviously is for the sake of performance.
• High Latency is bad – DAG members do not support round trip network latency greater than 250 milliseconds (ms).
• File Share Witness (FSW) can be hosted by any server in the domain – Just make sure that if your FSW is not an Exchange Server that the Exchange Trusted Subsystem group is in the local administrators group
• Each DAG needs an IP address – This can be statically assigned, if it is not, it will attempt to obtain an address via DHCP.

The Lab Setup

For this example, I am going to use a total of 4 servers within a single Active Directory site. One Active Directory Domain Controller, an Hub\CAS server and two mailbox servers. The relevant settings for the mailbox servers are as follows:

Server Names: MB1, MB2
MAPI Network: 172.16.23.0/24
Replication Network: 10.1.1.0/24

Create the DAG

The first thing we need to do is create the DAG. To do this, we use the New-DatabaseAvailabilityGroup cmdlet, specifying the name of the DAG, the name of the witness server, the local path to the witness directory on the witness server and the DAG IP address:

New-DatabaseAvailabilityGroup -Name DAG -WitnessServer HC1 -WitnessDirectory C:\FSW -DatabaseAvailabilityGroupIPAddresses 172.16.23.100

As you can see from the command, my witness server is named HC1 – this is the Hub\CAS server. I did not manually pre-create the C:\FSW directory, this will happen automatically in the next step when we add the mailbox servers to the DAG.

Adding Mailbox Servers to the DAG

Now that the DAG has been created, we can add the mailbox servers to the DAG. We use the Add-DatabaseAvailabilityGroupServer cmdlet to add servers MB1 and MB2 to the DAG:

Add-DatabaseAvailabilityGroupServer -Identity DAG -MailboxServer MB1

Now that MB1 has been added, we add MB2 to the DAG:

Add-DatabaseAvailabilityGroupServer -Identity DAG -MailboxServer MB2

Managing DAG Network Replication

The DAG networks we have configured on the DAG members are automatically added to the DAG when running the Add-DatabaseAvailabilityGroupServer as DAGNetwork01 and DAGNetwork02. We can confirm this by running the Get-DatabaseAvailabilityGroupNetwork cmdlet:

As you can see in the screenshot above, our MAPI network (172.16.23.0/24) has been assigned to DAGNetwork02, whereas the Replication network (10.1.1.0/24) has been assigned to DAGNetwork01 and both networks have replication enabled by default.

It's a good idea to have DAG replication enabled on multiple networks. Keep in mind, you could actually add a third replication network to this configuration for increased redundancy. If you need to disable DAG replication on a network, you can use Set-DatabaseAvailabilityGroupNetwork with the ReplicationEnabled parameter set to $false.

Adding Mailbox Database Copies

The final step is to add a mailbox database copy to the DAG. We currently have a database named DAGDB1 mounted on MB1. We'll use the Add-MailboxDatabaseCopy cmdlet to add a database copy to server MB2.

Add-MailboxDatabaseCopy -Identity DAGDB1 -MailboxServer MB2 -ActivationPreference 2

That's it, we now have a working DAG with a database copy. I will be posting a lot more about database availability groups in upcoming posts, that's all for now.

Related Posts

• Generating Delivery Reports and Tracking Messages from PowerShell (1)
• Managing Exchange 2010 and Lync 2010 from a Single PowerShell Session (0)
• How to Generate an Exchange 2010 Room List Report with PowerShell (3)
• How to Add Exchange Proxy Addresses from a CSV File with PowerShell (7)
• How to Manage Your Exchange 2010 Organization with PowerShell Implicit Remoting over the Internet (3)

Tagged as: DAG, EMS, Exchange, PowerShell