Exchange 2010 : How to Deploy a Mailbox Database Availability Group (DAG)

In this article I’ll cover deployment of a two-node, multi-role Exchange 2010 Database Availability Group (DAG). The required steps from schema updates to post-installation configuration will be detailed in order to get you up and running… hopefully!

1. Lab Environment

I’ll be deploying a two-node Exchange 2010 mult-irole DAG environment into a single Windows 2008 R2 Active Directory Forest with a single Windows 2008 R2 Active Directory Domain (the forest root domain) named domlocal.net.

The lab contains only a single AD DS site, Default-First-Site-Name.

Domain Controller;

DC1 – 192.168.0.190/24

Exchange server names:

EXCH1 – 192.168.0.191/24
EXCH2 – 192.168.0.192/24

The servers have an additional NIC configured for private cluster communications:

EXCH1 – 192.168.168.1/30
EXCH2 – 192.168.168.2/30

Additional IP addresses, you’ll need these too:

Cluster – 192.168.0.100/24

Finally you’ll also need a witness server to act as a third vote in the cluster in order to avoid spliit-brain scenarios. Any Windows 2003+ server will do, as long as it is up 24/7. If you divide the CAS/HT and Mailbox roles then a CAS/HT server is the ideal candidate. For the lab I’ll use a DC named ‘DC1’ – this should not be replicated in production!

Remember that a DAG does not require any shared storage (i.e. iSCSI/Fibre Channel) – local direct attached storage is fine. You can still use fibre channel/iSCSI storage, but each server must have its own disks.

2. Important Design Considerations

Experiential learning in action…

When installing Exchange 2010 into an environment that already contains Exchange 2007 or newer remember that mail routing using AD DS site link costs. If you are deploying Exchange into a new site verify the likely changes you are about to put into effect by installing Exchange.

Another consideration is that it is possible to have only a single CAS Array per AD DS site. If this is not desirable you may have to sub-divide you sites. That said, there is no reason that a single CAS array cannot be used by multiple domains in the same AD DS site.

There are MANY more design considerations, such as sizing correctly for performance, anti-virus/malware, load balancing (covered later) etc. But these in my opinion are obvious; the ones I have mentioned in more detail are less so.

3. Active Directory Schema Updates

First, you must update the Forest Schema in order to support Exchange 2010, you cannot deploy any Exchange 2010 servers until this step has been completed, not even the management tools will install until this is done!

A word of warning…. I would always perform this change to the schema master when it is disconnected from the network, and once a backup has been completed of the system state.

Updating the Schema Execute the following command to prepare the Exchange Legacy Permissions (requires Enterprise Admins permirrions):

{code lang:ini showtitle:false lines:false hidden:false}setup /pl{/code}

Execute the following command to prepare the schema for Exchange 2010 (requires Schema Admins ermission):

{code lang:ini showtitle:false lines:false hidden:false}setup /ps{/code}

Execute the following command to create AD DS objects, create new Exchange universal security groups and the specified Exchange Organisation (if one does not exist) and prep the local domain for Exchange 2010 (requires Schema Admins permission).

{code lang:ini showtitle:false lines:false hidden:false}setup /p [/on:UMBRELLA-CORP]{/code}

Note: you don’t have to specify the Organisation Name if there is already an Organisation in your AD DS Forest.

Finally, if you have more than one domain in your AD DS forest execute the following command to prepare the domain in which you want to install Exchange 2010, this also creates the Exchange Install Domain Servers group (requires Enterprise Admins permissions)

{code lang:ini showtitle:false lines:false hidden:false}setup /pd:<domain name>{/code}

Before reconnecting the schema master back to the network verify that the logs under C:ExchangeSetupLogs are OK.

Once verified, reconnect the schema master to the domain and allow replication to take place (time will vary depending on your production environment and complexity of AD DS topology)

4. Installation of Exchange 2010

Before you go any furthr ensure that both of the to-be DAG members have the .NET 3.5 feature installed – this is essential as you will be unable to deploy Exchange 2010 to these servers without this! Install this using Server Manager:

Any additional requirement can be installed automatically using setup (its about time!) – this makes the whole installation very simple to be honest… as you will see.

Launch the autorun from the CD and select ‘Choose Exchange Language option’ – select the language you want to use. For this example I selected the ‘Install only languages from the DVD’ option:

Select Step 4, ‘Install Microsoft Exchange.’

Proceed through the installation by clicking Next on the first screen:

Agree to the license agreement (or don’t, but you wont get any further!):

Choose if you wish to participate in Error Reporting:

Tick the box at the bottom of the window ‘Automatically install Windows Server roles and features required for Exchange Server’ and then click the ‘Custom Exchange Server Installation’ option:

So, in Exchange 2007, using a CCR cluster, you couldn’t provide HA at a mailbox server level with other roles on the mailbox server. Exchange 2010 changes that and effectively allows you to decide how you want to dploy your roles. Commonly this would be divided up into seperate CAS/HT servers with dedicated Mailbox Servers and finally a public folder server… but it’s up to you.

If you are running clients previous to Outlook 2007 you require a public folder database for Outlok clients to function properly, decide accordingly:

Set an external name for Internet facing roles (if you are using services such as Outlook Web Access or Exchange Web Services):

Choose if you want to participate in the Customer Experience Improvement Program:

The installer will now perform ‘readiness checks’ to ensure you have updated the schema there is sufficient disk space etc. When finished, if there are no errors click ‘Install’ to being deployment:

Wait for setup to finish, then click ‘Finish’ to launch the Exchange Management Console.

5. Configuring the Mailbox Database Availability Group

As stated earlier, I’ll use a DC in this lab for the witness server, in production you should use a CAS/HT server or another Windows server.

5.1 Define the Database Availability Group

First, let’s define the DAG itself using the Exchange Management Shell:

{code lang:css showtitle:false lines:false hidden:false}New-DatabaseAvailabilityGroup -Name EXCHDAG -WitnessServer DC1 -WitnessDirectory C:FSW_EXCHDAG -DatabaseAvailabilityGroupIPAddresses 192.168.0.195{/code}

You’ll notice that the DAG does not contain any members at this stage.

5.2 Add Member Servers

You guessed it, now we’ll add the member servers; I stated the names of these servers at the beginning of the article, EXCH1 and EXCH2.

{code lang:css showtitle:false lines:false hidden:false}Add-DatabaseAvailabilityGroupServer -Identity EXCHDAG -MailboxServer EXCH1{/code}

The Failover Clustering feature is installed on the server and then it is added to the Exchange Database Availability Group. Note that there is no feedback from the shell to confirm completion.

Once finished perform the same for the second node:

{code lang:css showtitle:false lines:false hidden:false}Add-DatabaseAvailabilityGroupServer -Identity EXCHDAG -MailboxServer EXCH2{/code}

5.3 Verify the DAG in Exchange Management Console

Browse to Organization Configuration > Mailbox > Database Availability Groups and confirm the existence of your new DAG.

6. Create Database Availability Group Mailbox Database(s)

I have presented two drives to each server;

- D: for Mailbox Database EDB files
- L: for Mailbox Database Log files

These drives are formatted NTFS with a 64K Allocation Unit Size – this is best practice for any Exchange Data/Log drives (from the days of Exchange 2007).

Use the following command to create the first copy of a new Mailbox Databae named DAGDB01 on EXCH1:

{code lang:css showtitle:false lines:false hidden:false}Get-ExchangeServer EXCH1 | New-MailboxDatabase -Name “DAGDB01” -EdbFilePath D:DAGDB01DAGDB01.edb -LogFolderPath L:DAGDB01{/code}

Now add the second copy of this Mailbox Database to EXCH2:

{code lang:css showtitle:false lines:false hidden:false}Add-MailboxDatabaseCopy -Identity DAGDB01 -MailboxServer EXCH2 -ActivationPreference 2{/code}

7. Move System Maiboxes to DAG Mailbox Database

When you install Exchange 2010 each Mailbox Server will automatically get a Mailbox Database with a random name; this databse contains System mailboxes required by Exchange 2010.

As we don’t want to keep these random Exchange Mailbox Databases in our environment (for one they are not protected by the DAG) we must first move the system mailboxes into the DAG Database we creted in the previous section of this article.

On EXCH1, use the following command to identify all of the mailboxes contained in the local (non-DAG) Mailbox Database:

{code lang:css showtitle:false lines:false hidden:false}get-mailbox | ft{/code}

Note down each of the listed names, these are the mailboxes you need to move to DAGDB01.

For each name you have listed, execute the following command, replacing the name accordingly:

{code lang:css showtitle:false lines:false hidden:false}New-MoveRequest -Identity “Discovery Search Mailbox” -TargetDatabase “DAGDB01″{/code}

This will generate a new Move Request which will be handled in the background. By the time you have queued all of the moves most of them will have finished. Verify this using the command:

{code lang:css showtitle:false lines:false hidden:false}Get-MoveRequest | ft{/code}

All of the Move Requests should be in a ‘Completed’ state before you proceed.

Now we must cleanup the completed Move Requests otherwise the mailboxes will have restricted functionality (you wont be able to move them again). Use the following command to cleanup ALL completed move requests, note you will be prompted to confirm each action:

{code lang:css showtitle:false lines:false hidden:false}Get-MoveRequest -MoveStatus Completed | Remove-MoveRequest{/code}

Now perform these same actions on EXCH2.

8. Remove Installation Mailbox Databases

The databases that were automatically created now contain no user mailboxes so we can now remove them.

Use the following command to list the Mailbox Database names, note down the ones you want to remove (they will be named similar to ‘Mailbox Database 12345678’):

{code lang:css showtitle:false lines:false hidden:false}get-mailboxdatabase | ft{/code}

Next, use the following command to remove each of the unwanted Mailbox Databases’ from the server, changing the name accordingly:

{code lang:css showtitle:false lines:false hidden:false}Remove-MailboxDatabase “Mailbox Database 0051045371″{/code}

Finally for the cleanup to be complete, remove the Mailbox Database files on each of the Mailbox Servers, these files are located under C:Program FilesMicrosoftExchange Serverv14Mailbox

9. Test DAG Failover

Now it’s time to test our deployment; can we move the active copy of our DAG Mailbox Database to the secondary node, and then back again?

Use the following command to test the failover to EXCH2, you’ll be prompted to confirm the move action:

{code lang:css showtitle:false lines:false hidden:false}Move-ActiveMailboxDatabase DAGDB01 -ActivateOnServer EXCH2 -MountDialOverride:None{/code}

To move the active copy back to EXCH1 use the following command:

{code lang:css showtitle:false lines:false hidden:false}Move-ActiveMailboxDatabase DAGDB01 -ActivateOnServer EXCH1 -MountDialOverride:None{/code}

10. Confirming Mailbox Database Copy Health

It’s all very well that the failover worked the first time, long-term you need to be sure it’s going to work when you need it to. You can get a an idea of Mailbox Database copy health using the command below:

{code lang:css showtitle:false lines:false hidden:false}Get-MailboxDatabaseCopyStatus DAGDB01 | ft{/code}

In this example you can see EXCH2 is down as it’s status is ServiceDown. Note, if you don’t specify the Mailbox Database the command will only return the copies that are local to the server on which the Exchange Shell is being run on.

And that’s it, add additional storage and Mailbox Databases to suite your requirements, but essentially your off the starting blocks…

Contents