Exchange 2010 RTM DAG using Server 2008 R2 – Part 3

Welcome to Part 3 of this article series. In Part 1, we started off by discussing the goal of this lab. That goal is how to deploy a two-node Exchange 2010 RTM Database Availability Group (DAG) on Windows Server 2008 R2. We then prepared our Operating System with the Exchange 2010 Prerequisites which includes software prerequisites as well as modification to hardware configuration such as our Network Interface Cards (NIC)s.  In Part 2, we went over the installation of one of our Exchange 2010 Servers which included the Mailbox, Client Access, as well as Hub Transport Server Roles.

In this Part, I will go over the creation and configuration of our Database Availability Group (DAG).  We will then add our first Node to our DAG.

Part 1

Part 2

Part 3

Part 4

File Share Witness

We will be using a File Share Witness (FSW) on a non-Exchange Server.  This will go on our member server, SHUD-OCSFE01.

We will need to go onto our Member Server and add the “Exchange Trusted Subsystem” group to our Local Administrators Group.  If you do not do this, you will get an Access Denied error message. Unlike Exchange 2007, we do not have to pre-create the FSW.  We tell Exchange 2010 where the FSW will be located, and because the Exchange Trusted Subsystem is added to the non-Exchange box, it will have the permissions necessary to create, modify, and maintain the FSW.

It is still recommended to place the FSW on a Hub Transport Server.  In fact, if you don’t specify the FSW location (Witness Server and Witness Directory), Exchange 2010 will automatically go out and look for a Hub Transport Server and choose a location on its own.  Alternatively, you can specify the Witness Directory and not the Server; in which case Exchange 2010 will automatically choose an Exchange 2010 Server (non-DAG Hub Transport Server preferred) on its own but use the Directory you specified.

Creating the DAG using the EMC and assigning a Static IP

Open the Exchange Management Console (EMC) and go into Organization Management > Mailbox.  Click on Database Availability Group. As you can see, it’s currently empty.

Right-Click on the empty space and choose ” New Database Availability Group.”

Let’s give our DAG a name.  For purposes of this lab, I used the name ShudnowDAG.  As stated, we want SHUD-OCSFE01 to be our witness server and our directory will be C:\ShudnowDAG.  Click New to Create our DAG.

The DAG is successfully created.  At this time, an empty objecting representing the DAG with the name you specified and an object class of msExchMDBAvailabilityGroup is created in Active Directory. You can see the object in either ADSIEdit or LDP.  The DN for this object is:

The completion page will show a warning  informing you that the server that contains the FSW is not an Exchange Server.  We know this already as it was our intention to do this all along.

When the GUI is used to create a DAG, it uses DHCP for the Network Name cluster resource.  If we want to specify a static IP for our DAG, we need to use the Set-DatabaseAvailabilityGroup cmdlet.  The Set-DatabaseAvailabilityGroup cmdlet has a switch called -DatabaseAvailabilityGroupIpAddresseses.  This switch will and should never contain IP Addresses for your replication network.  This -DatabaseAvailabilityGroupIPAddresses switch is ONLY for your MAPI Network subnets so the Network Name resource can come online due to a dependency in the Failover Clustering Services among some other Exchange related functions.

Among some other Exchange related functions eh?  I knew you would ask! Read on…

The Network Name resource is what is used to update the password for the Cluster Name Object (CNO) which is the DAG$ computer account.  The Network Name resource does not have to necessarily be online for Exchange to operate properly, but if it’s not, the DAG$ computer account will expire.  Obviously this would not be a good thing and will cause bad things to happen.

There are also parts of the code that will attempt to connect to the Network Name resource (such as DAG member modifications), but if that fails, those pieces of code will fall back to the servername once the network timeout occurs.

Exchange also utilizes the Possible Owners of the Network Name resource for moving the Primary Active Manager (PAM) which is the server that has control of the default Cluster Group which essentially monitors database status and makes the decisions on what server mounts which database.  For more information about the Active Manager, click here.

So moving on… as you can see, our DAG is using DHCP which is denoted by the <> characters.

So taking a look at our first node, we see our MAPI Network is on the 192.168.1.0 subnet due to the IP Address being 192.168.1.152/24.  Our second node is on the same subnet.

We currently have 192.168.1.154 free so we will use that static IP for our DAG.  It’s not absolutely necessary to use a static IP, but if you feel the need to use a static, feel free.

Now that we have our static IP chosen, let’s run the following command:

We now see that our DAG has the following static IP configured.

Creating the DAG using the EMS and assigning a Static IP

Using the EMS is much faster.  Instead of doing all the above, all you need to do is run the following command:

See? Much faster than using the EMC.  This will definitely be the method I am going to be using in the future to create a DAG when using a static IP instead of DHCP.

Adding the first Node to our DAG

Well, let’s go ahead and add our first node to the DAG.  Go into the EMC > Organization Configuration > Mailbox > Database Availability Group > Right-Click our DAG > Manage Database availability Group Membership.

Add the first Node.  Click Manage to Continue.

Our first node has successfully been added.

But… what exactly was done during this behind the scenes when this first node was added to the DAG?  The following occurs (from Technet documentation):

• The Windows Failover Clustering component is installed, if it is not already installed.
• A failover cluster is created using the name of the DAG.
• A cluster network object (CNO) is created in default computers container.
• The name and IP address of the DAG is registered as a Host (A) record in DNS.
• The server is added to DAG object in Active Directory.
• The cluster database is updated with information on the databases that are mounted on the added server.

First of all,we can see the DAG has been registered in DNS.

Second of all, we can see the DAG’s Cluster Network Object (CNO) has been created in AD.

Third of all, we can see the cluster has been formed.  As you can see, there’s no CMS/Virtual Server in the Services and applications.  This is because Exchange 2010 is not a cluster aware application.  Exchange 2010 only utilizes Windows Failover Clustering Services for heartbeat information and cluster networks.

Finally, we can see that the cluster is currently set to Node Majority.  When we add our second node, the cluster will be switched to Node Majority with File Share Witness since we’ll have an even number of Exchange Nodes and will need a 3rd node/share to act as our witness.  Because of this, we won’t see any FSW data inside of FSW share until our second node is added to the DAG.

Summary

Well folks, that is all for Part 3 of this article. For Part 4, I will be adding the second node to the DAG and then create a  database which will then be synchronized to the second DAG node.