Building an Exchange 2013 LAB Environment using Windows Server 2012 from scratch - Part 6 - Configuring a DAG

We last left off in Part 5 which covered the Directory, organization and Exchange preparation-and then went on to install the relevant Exchange servers using the unattended setup feature.

In this part I would like to cover the steps to setup a Database Availability Group within the LAB. Now before we begin it is probably a good idea to cover a couple of concepts about DAG’s and how this configuration (sic. the LAB configuration) differs from what you might expect to place into production.

Whistle stop tour of Database Availability Groups

Ok, I don’t intend to go into any large level of detail here about DAG architecture – I just want to cover enough to understand what we are implementing in our LAB and how this would differ in a production environment.

First off here is a definition from Microsoft about DAG’s which you can find, along with other interesting information here: technet.microsoft.com/

"A database availability group (DAG) is the base component of the high availability and site resilience framework built into Microsoft Exchange Server 2013. A DAG is a group of up to 16 Mailbox servers that hosts a set of databases and provides automatic database-level recovery from failures that affect individual servers or databases.

A DAG is a boundary for mailbox database replication, database and server switchovers, failovers, and an internal component called Active Manager. Active Manager, which runs on every server in a DAG, manages switchovers and failovers.

Any server in a DAG can host a copy of a mailbox database from any other server in the DAG. When a server is added to a DAG, it works with the other servers in the DAG to provide automatic recovery from failures that affect mailbox databases, such as a disk failure or server failure."

With that basic understanding of DAG’s it is now important to get to grips with the concept of Quorum Models within DAGs.

Underpinning each DAG configuration is the Windows Failover Cluster Service. As some of you will be aware, failover clusters make use of the Quorum concept which basically means that that the correct  (and correct number of) members of a cluster (or DAG) are participate to ensure availability. This can mean all of the nodes in the cluster, or a majority of them (more on this later).

All clusters (or DAG’s) must have and maintain quorum – if not, all DAG operations will cease – and therefore cause all databases to dismount, rending the LAB (or production environment)offline.

DAGs that have an even number of members (e.g 2,4,6 etc.) will use failover clustering’s Node and File Share Majority, whereas DAGs with an odd amount of members (e.g 3,5,7 etc.) will use Node Majority.

In the case of Node and File Share there is an external “Witness Server” which is used to provide one DAG member with a weighted “vote” (e.g. the selected node gets two votes instead of one).

In the case of Node Majority – each member of the cluster (DAG) get a vote and will require the majority of members to be online and functional in order to maintain quorum.

You might be thinking, ok this is all well and good – but what does this have to do with our LAB?

Well, in our configuration we have provisioned 3 Exchange servers – two of which are multi-role (running CAS and MBX services) and the remaining being a mailbox server only.

This allows for us to build a DAG within our lab that will adopt the Node majority model (as well as build a supported environment – as Microsoft recommends a minimum of 3 database copies of each DB in a DAG ~ therefore a minimum of three members).

However, when creating a DAG you still need to specify a File Share witness server and location, even if you expect to have an odd number DAG membership. The reason for this is that if for some reason you change the number of members of the DAG to an even count – the specified witness will then come into play to maintain quorum.

This leads us onto the obvious – we (I) have not provisioned for a server within the LAB to act as the File share witness (I made this choice for this series based on conservation of resources and Windows activations).

Members of a DAG cannot also act as a FSW – it needs to be on a separate server – this leaves us within only one option ~ the Domain Controller to act as the FSW.

Now, using a Domain Controller as an FSW is NOT recommended in production for a number of reasons – but most pertinent of which are that such a configuration requires some messing around with some highly privileged group membership within AD that you really, really do not want to do – but can be excused in a LAB (most of the time – if you are planning on making your LAB web facing, provision a separate server for the FSW or combine it with something else in the same domain).

Specifically, in order for the process of assigning the FSW to a DC to work – the following needs to be configured:

• he domain controller needs to be a member of the “Exchange Trusted Administrators” group

• The “Exchange Trusted Administrators” group needs to be a member of the domains “BUILTIN\Administrators” group

I must stress – this is not the case in production, you do not need to change the membership of these groups (nor should you) if you are using a separate, non-domain controller as the FSW.

DAG Configuration from CSV File Script

In order to use the DAG creation script in our DAG environment – you should build the CSV file that contains our desired DAG settings.

To do this open up a text file and type in the following headings – each separated with a comma:

• DAGName

• WitServerName

• WitnessDir

• DAGIP

Underneath each of the headings you should provide a value (relevant to your environment) separated again by a comma – see the example below.

When you are done save the file as DagData.csv in a location where you intend to create the ConfigureDAG2013.ps1 file.

Below is the source code to the script:

<# Exchange 2013 LAB - Create DAG Script from CSV http://www.telnetport25.com Author: Andy Grogan Version: 0.1 .Compatibility Windows Server 2012 Powershell 3 Exchange 2013 Not Supported with any other versions of the software mentioned above. .Parameters -CSVFile .Example .\ConfigureDAG2013.ps1 -CSVFile <Path and Name to CSV file> .CSV File Headings (all required) DAGName,WitServerName,WitnessDir,DAGIP .Notes DO NOT USE THIS SCRIPT AS IS IN PRODUCTION Ensure that you comment out the prep_Security function! #> [CmdletBinding()]Param( [Parameter(Mandatory=$True)] [string]$CSVFile ) $DAGInfo = Import-Csv $CSVFile function prep_Security{ Write-Host "Prepping Security Permissions - Don't do this in PRODUCTION!" -Foregroundcolor Cyan # Add the domain controller to the Ex Trusted SS group # Not a good thing to do - only doing this as its a LAB Write-Host"Adding Domain Controller to Exchange Trusted Subsystem" -foregroundcolor Green $LABDomainDN = (Get-ADDomain).DistinguishedName $LABDC = (Get-ADComputer -Filter * -SearchBase "OU=Domain Controllers,$LABDomainDN").DistinguishedName Add-ADGroupMember "Exchange Trusted Subsystem" $LABDC # Add Ex Trusted SS to Builtin\Administrators Write-Host "Exchange Trusted Subsystem to Builtin\Administrators" -foregroundcolor Green Add-ADGroupMember "Administrators" "Exchange Trusted Subsystem" } function new_Dag{ param( $DAGName,$WitServerName,$WitnessDir,$DAGIP ) Write-Host "Creating the DAG" -foregroundColor Green New-DatabaseAvailabilityGroup -name $DAGName -WitnessServer $WitServerName -WitnessDirectory $WitnessDir -DatabaseAvailabilityGroupIPAddress $DAGIP } function add_Members{ param( $DAGName,$Server ) Write-Host "Adding DAG Member" $Server -ForeGroundColor Green Add-DatabaseAvailabilityGroupServer -id $DAGName -MailboxServer $Server } # Comment out prep_Security for Production Environments prep_Security new_Dag $DAGInfo.DAGName $DAGInfo.WitServerName $DAGInfo.WitnessDir $DAGInfo.DAGIP $Members = Get-MailboxServer | Select -expandProperty Name foreach($SVR in $Members){ add_members $DAGInfo.DAGName $SVR } $DAGSummary = Get-DatabaseAvailabilityGroup | Select Name,DatabaseAvailabilityGroupIpAddresses,Servers Write-Host $DAGSummary -foregroundcolor Cyan Write-Host "Script Completed..."

The script performs the following actions:

1. Sets up the relevant permissions to allow for the domain controller to act as the FSW for the DAG.

2. Takes the data from the DAG configuration CSV file and parses it to the relevant functions in the script.

3. The relevant functions will: Create the DAG, Add the Mailbox Servers as members of the DAG.

When a member server is added to the DAG – the Add-DatabaseAvailabilityGroupServer cmdlet will automatically install the Failover Clustering Service on each node.

Using the Script

On art-MBXCAS-01 open an Exchange Management Shell. Navigate to the location where you either created the script file, or downloaded it and type in:

.\ConfigureDAG2013.ps1 –CSVFile .\NameOfDAGCSVFile

If you downloaded the file you will need to ensure that the PowerShell execution policy is set to “RemoteSigned” – see here for further information.

When you hit the <Enter> key the script will begin the process of querying the CSV file and creating the DAG. All of the Servers within our LAB (as they are hold the Mailbox server role) will be added as members – see below.

When the script has completed you will be presented with a summary of the configuration. During execution you might see warning messages which suggest that access has been denied to the FSW – these can be ignored.

When the script has completed you can review the configuration via the Exchange Administrative Centre or from the Management Shell – see below:

Or in the EAC: