In Part 1 of this series, we went over the basic concepts of the Database Availability Group, or DAG, and then went into how to set up the Networking for the DAG. In this next section, we’ll cover how to create the DAG, and then add servers to that DAG.
The first thing we need to do, is actually create the DAG. In the Exchange Management Console, under the Organization Configuration-> Mailbox, navigate to the Database Availability Group tab:
Click on the “New Database Availability Group” Action. You’ll be presented with the following screen:
- Database Availability Group Name – This is just the name of the DAG.
- File Share Witness Share – This is the UNC patch of a file share witness, most likely on an HT server. This is used if there an even number of Servers in the DAG for a majority vote
- File Share Witness Directory – This is where the share is located on the server who is hosting it. It will be created for you automatically.
- Network Encryption and Network Compression we’ll leave at the default.
With a Hub Transport server installed on NYDC01, and wanting the share to be from a folder called “DAG01” on the C drive of that server, our screen will look like this:
After hitting next, you’ll see the powershell command that could have been run:
New-DatabaseAvailabilityGroup -Name ‘DAG01’ -FileShareWitnessShare ‘\NYDC01DAG01’ -FileShareWitnessDirectory ‘C:DAG01’
Now, you’ll have a DAG created, but with no member servers in it:
Now, lets add NYDAGNODE01 to it. A couple things that should be noted. First, DAG’s utilize the Windows Server Failover Cluster feature to be installed. If when you go to add a node to the DAG, if this isn’t installed, the command will run it for you, it will just take a little bit longer. The second issue is that we are using the Beta release of Exchange 2010. There seems to be an issue with the Exchange Console, being able to remotely initiate the installation. To get around this when using the Beta, just make sure to install the Windows Failover Clustering Feature from Server Manager yourself on all the nodes. This will also help to speed things up.
Okay, so on to adding the first Node to the DAG. When you add the first node to a DAG, the DAG get’s assigned an IP address. If you do this through the Exchange Management Console, the DAG will retrieve an address through DHCP. I’m not a huge fan of this, so I like to use the Exchange Management Shell, because you can statically assign an IP address to the DAG. I’ll show you both way’s though. For the Exchange Management Console, Navigate to Organization Configuration –> Mailbox and select the Database Availability Group tab. Here, you will see DAG01 listed, the DAG we created before. Right click it, and select “Manage Database Availability Group Membership”, you’ll be presented with this screen:
Now, select the green Add button, and then select NYDAGNODE1, and select OK.
You could now select manage. This would ensure the server had Failover Clustering installed, if it didn’t it would install it, and then add it to the DAG. It would also retrieve an IP address from a DHCP server. We won’t finish this, we’ll do it in the shell.
The command is really simple.
Add-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer NYDAGNODE1 -DatabaseAvailabilityGroupIpAddresses 10.1.1.3
This will add the server NYDAGNODE1, to the DAG, DAG01 and assign the DAG IP address 10.1.1.3.
We let the command run, and it can take some time, you’ll see a command similar to the below as it creates the cluster and adds the server to the DAG:
Once the command finishes, you’ll see NYDAGNODE1 listed as a member server:
If we now ping that IP, we see that we are getting a successful return:
Now, add the second node, LNDAGNODE1. It works the same way as above for the Console, or the shell. If you use the shell, you can now omit the –DatabaseAvailabilityGroupIPAddress command. (Remember to log on locally to LNDAGNODE1, as the Beta fails when trying to do it remotely. Also, it seems that you need to use the Exchange Management Shell (Local) icon to add the second node successfully) The end result should look like this:
If you note, there are now two Member Servers in the DAG, and in the bottom half of the screen, it notes the networks, and their status. Note, by default, ALL of the networks are configured for replication. We’ll configure this differently in the next part.
In this part, we created a DAG, and added two members to this DAG. In the third part of this series, we’ll configure the replication networks, and create some database’s and set them up for replication!