How To: Exchange 2013 SP1 and Active Directory-Detached Clusters: #MSExchange #iammec

Working in the Technology industry for 16 years has afforded me many opportunities to serve as the celebrated, distinguished, and illustrious ‘on-call’ contact. During the 10 years or so working at various levels and stages of a system administrator, there seemed to be a very consistent theme with being on-call. If I did not plan anything on the weekend – the phone did not ring. However, if I planned on a nice dinner with my wife on Friday night – the phone would ring. Most of the time the calls were not critical situations, but rather something relatively minor. About once a year though, a true critsit would come my way. Nothing was more infuriating as when these outages were a result of another engineer (or myself) shooting themselves in the foot. In my experience though – most outages were revealed to be self-inflicted during post-mortem exercises. This scenario plays out in most organizations and is something that the Microsoft support organization is well aware of. After all, they are the ones that receive the critsit calls from grumpy and embarrassed engineers. As a result, Microsoft has been preaching simplicity.

Since the release of Microsoft Exchange 2010, the Database Availability Group (DAG) has become the crowning jewel around the high availability and site resilience story, and the technology continues to evolve. This of course is my opinion after working with many third-party products that claimed to provide the same level of protection for Exchange 2003 and 2007, but seemed to cause too many sleepless nights.

The addition of a DAG into a messaging design allows a perimeter to be created for database replication, failovers and switchovers. It is important to note that a best practice DAG design also leverages the concept of incremental deployment. This means that we first create an empty Active Directory (AD) object that contains important information about our DAG. Then, we build upon the AD object by adding Mailbox servers to participate in the DAG. This step uses the Windows Failover Clustering components to create a cluster (CNO, IP Address etc.) that is unique to the DAG and manages database mount status, continuous replication and Active Manager duties. The final building block is to create and add database copies into the DAG.

The high availability story for Exchange 2013 SP1 (with Windows Server 2012 R2) has evolved into an even stronger story. Now, (using 2013 SP1 and 2012 R2) Mailbox servers configured with a DAG do not require the creation of a cluster administrative access point or IP address.

Screen Shot 2014-05-01 at 7.39.39 PM

This means that the Windows Failover Clustering Manager can no longer be used to manage the DAG (specific PowerShell cmdlets are used against each individual cluster member instead) as the IP Address and cluster Network Name resources are not present.

Screen Shot 2014-05-01 at 7.33.50 PM

With this configuration, PowerShell cmdlets are used to manage all aspects of the DAG (much like a non-Exchange Active Directory-detached cluster). It is also important to note that the CNO and cluster A record within DNS are also missing. The DAG-name is no longer required to be resolvable within your companies internal DNS. The removal of the CNO, IP Address and Network Name dependencies are a result of changes introduced with the release of Windows 2012 R2. Now, Exchange can leverage an Active Directory-detached cluster. The removal of these legacy dependences helps to simplify both deployment and administration.

Regarding deployment, we no longer require AD permissions to create objects or to pre stage cluster computer accounts. Administrators can now rest easy that an over-eager employee can no longer delete the CNO because they did not recognize the name. Microsoft’s effort for simplicity in design, implementation and administration is evident.

Let’s delve into how we leverage all these new enhancements with a step-by-step tutorial.

For the purpose of this walkthrough, we will utilize a box called SRV1 to house the FSW, SRV3 and SRV4 to run the Exchange 2013 SP1 Mailbox role.  Each of these servers have Windows 2012 R2 installed. While there will certainly be other servers/roles within the Exchange/AD architecture, these are the relevant boxes for this walkthrough.

We need to determine what server is going to host the file share witness for our two server DAG. Once the server has been determined, the Exchange Trusted Subsystem needs to be added to the local admin group on the server.

Next, we issue the PowerShell command from SRV3 to create the DAG. The server srv1.contoso.local will be used for our example. Notice in the syntax below the IP Address is set to None.

New-DatabaseAvailabilityGroup -Name DAG01 –DatabaseAvailabilityGroupIPAddresses ([System.Net.IPAddress]::None) -WitnessServer srv1.contoso.local –WitnessDirectory “c:\fsw“

If you did not add the Exchange Trusted Subsystem to the local administrators group, on the computer configured to host the file share witness, the following error will be displayed:

Screen Shot 2014-04-24 at 11.29.55 AM

Once the DAG is created successfully, the first Mailbox server can be added. Exchange will first check within AD to verify that the Mailbox server is not already part of an existing  DAG. To add the first Mailbox server to our newly created DAG (DAG01) the following PowerShell command from SRV3 is issued:

Add-DatabaseAvailabilityGroupServer -identity DAG01 –MailboxServer srv3

Screen Shot 2014-04-24 at 11.44.18 AM

Once the Mailbox server has been identified as not part of an existing DAG, the Windows Failover Clustering components are installed.

Screen Shot 2014-04-24 at 11.44.25 AM

Screen Shot 2014-04-24 at 11.49.15 AM

Once our first Mailbox server (SRV03) has been added to the DAG (DAG01) we can then add the second Mailbox server from SRV3.

Add-DatabaseAvailabilityGroupServer -identity DAG01 –MailboxServer srv4

Now that both our Mailbox servers (SRV03, SRV04) have been added to the DAG, we need to verify our work thus far. We will use PowerShell from SRV3 to show the two Mailbox servers we just added.


Screen Shot 2014-04-24 at 12.01.48 PM

In order to show how the DAG IP address is reported when no cluster administrative access point or IP address is configured, the PowerShell command below is used. We will want to take note of the DatabaseAvailabilityGroupIpv4Addresses and DatabaseAvailabilityGroupIpAddresses values.

Get-DatabaseAvailabilityGroup | fl

Screen Shot 2014-04-24 at 12.03.39 PM

When we created the DAG and specified the FSW (server) location, you may of noticed that this folder was not immediately created. The FSW folder is actually not created until the second Mailbox server is added to our DAG. Once the second Mailbox server is added into the DAG, thus requiring quorum,  the FSW folder is created on SRV1 as you see below.

Screen Shot 2014-04-24 at 12.01.16 PM

At this point, we are ready to create a new DAG-protected  database on SRV3. For our example we are going to add the database called mbx01 to SRV3.

The following PowerShell command from SRV3 is used to add a DAG protected database:

New-Mailboxdatabase -server srv3 -name mbx01 -Edbfilepath “C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\mbx01.edb” –logFolderPath “C:\Program Files\Microsoft\Exchange Server\V15\Mailbox”

Screen Shot 2014-04-24 at 12.07.57 PM

After the new database has been added, a warning to restart the Information Store service on SRV03 is provided. The following command from SRV3 will be used restart the service:

Restart-Service MSExchangeIS

Screen Shot 2014-04-24 at 12.09.47 PM

In order to verify that mbx01 is mounted we need to run the PowerShell command from SRV3 below:

Get-MailboxDatabaseCopyStatus -Identity mbx01\srv3 | ft name,Status,ContentIndexState,ReplayQueueLength,CopyQueueLength

Screen Shot 2014-04-24 at 12.17.41 PM

At this point we have SRV3 and SRV4 participating as members in our DAG. However, only SRV3 has a copy of the database (mbx01) that we want to make highly available. On our second server Mailbox server (SRV4) we want to add a copy of the mbx01 database. To accomplish this, we will need to issue the following PowerShell command from SRV4:

Add-MailboxDatabaseCopy mbx01 -MailboxServer srv4

Screen Shot 2014-04-24 at 12.22.08 PM

After adding a copy of mbx01 to SRV4, a warning that the Information Store needs to be restarted is presented. From an Exchange PowerShell window on SRV4 we will need to restart this service.

Restart-Service MSExchangeIS

Now that we have created a highly available cluster of Mailbox Servers, and added a second copy of the mbx01 database on both servers, we need to verify database health. In the example below, we can see that MBX01\SRV3 is showing as mounted. Also, MBX01\SRV4 is showing healthy as the status. The CopyQueueLength and ReplayQueueLength are both set at zero and the ContentIndexState is healthy. From either Mailbox server we can issue the following command

(Get-DatabaseAvailabilityGroup) | ForEach {$_.Servers | ForEach {Get-MailboxDatabaseCopyStatus -Server $_}}

Screen Shot 2014-04-24 at 12.32.00 PM

As you can see from our example of setting up a new DAG with a highly available mailbox database, Microsoft has both simplified and streamlined the process. The overarching theme when combining Windows Server 2012 R2 with Exchange 2013 SP1 is ‘Simplicity.’

Personally, I look forward to not receiving a call during the middle of the night that “the Exchange mailbox databases on the cluster wont mount and Systems Center is complaining about missing a CNO or something like that.” While we may not be able to get out of on call duty, we may be able to make our systems a bit more resilient thanks to Microsoft’s latest chapter in the Exchange high availability story.


Leave a Reply

Your email address will not be published. Required fields are marked *