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

Welcome to part 6 in my series of how you can build an Exchange 2013 LAB using Windows Server 2012. In the previous parts (should you wish to read them, refresh or catch up) can be found below:

Part 1

We established our domain design, covered how to provision the Domain Controller for the LAB in Hyper-V and then how to install Windows Server 2012 on the Domain Controller.

Part 2

We went through the process of installing Active Directory Domain Services on the LAB domain controller using PowerShell.

Part 3

We covered how you can install a very simple PKI infrastructure on the domain controller using Active Directory Certificate Services. These will be used in a later part to configure SSL for various parts of Exchange 2013.

Part 4

We covered how to use PowerShell to provision Exchange server VM’s in the lab, and went through the pre-requisite software installation.

Part 5

We covered the Directory, organisation 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.

And now for Part 6:

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:

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. I have covered quorum models and majorities in the following article

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:

  • The 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

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 – you have two options:

  1. Copy and paste it to a blank ps1 file located on the art-MBXCAS-01 server in the LAB (if you have been following the naming conventions).
  2. Download a copy of the script file from the downloads section next in this article.
    Exchange 2013 LAB - Create DAG Script from CSV
    Author: Andy Grogan
    Version: 0.1
    Windows Server 2012
    Powershell 3
    Exchange 2013
    Not Supported with any other versions of the software mentioned above.
        .\ConfigureDAG2013.ps1 -CSVFile <Path and Name to CSV file>
    .CSV File Headings (all required)
        Ensure that you comment out the prep_Security function!


$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{

    Write-Host "Creating the DAG" -foregroundColor Green
    New-DatabaseAvailabilityGroup -name $DAGName -WitnessServer $WitServerName -WitnessDirectory $WitnessDir -DatabaseAvailabilityGroupIPAddress $DAGIP

function add_Members{

    Write-Host "Adding DAG Member" $Server -ForeGroundColor Green
    Add-DatabaseAvailabilityGroupServer -id $DAGName -MailboxServer $Server


# Comment out prep_Security for Production Environments


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.


You can download the above script and a sample CSV file from the links below

[Configure Exchange 2013 DAG Script – 2.4KB ]

CSVIco [ Sample DAG Configuration CSV 0.9KB ]

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:


In the next part

In part 7 I will be covering the following:

  • Creating our LAB Databases and adding them to our DAG
  • Configuring Autodiscover, EWS, OWA and other IIS URI’s with the CA that we installed in Part 3


  1. Hello

    I have tried running this script and modified it to comment out the AD, configuration; for test prodution environment purposes. I am recieving errors stating that objects like New-DatabaseAvailabilityGroup is not a recognised as the name of cmdlet. Can you enlighten me on what I am doing wrong?

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.