Category Archives: DAG

Configure an Exchange 2013 DAG on Windows Server 2012 R2 With No Administrative Access Point

DAG, Exchange 2013, High Availability

Exchange 2013 SP1 introduced support for Windows Server 2012 R2, and also introduced support for a new feature in Windows Server 2012 R2, Failover Clusters without an Administrative Access Point.  You can now create a DAG, that does not need separate IP’s on each subnet for the DAG itself.  It also no longer creates the CNO which is seen as the computer account in Active Directory.  The benefit of this feature is that you reduce complexity, no longer need to manage the computer account for the DAG, and no longer need to assign IP addresses for each subnet on which the cluster operates.  There are some downsides, but it shouldn’t affect Exchange admins much.  Mainly, since there is no ip address and no CNO, you cannot leverage Windows Failover Cluster admin tools to connect to it.  You need to leverage local PowerShell against a cluster node directly.  With Exchange, this shouldn’t be too much of a problem as almost all of the management of the cluster is handled with Exchange tools through management of the DAG itself.

In our example, we have two servers in separate AD sites that we are going to configure in our DAG:



We will create a DAG named SOA-DAG-2013.  Now, previously this would be the name of the CNO that Exchange would create underneath.  This is changed to essentially be a label that is stamped on all the nodes for management, but will no longer create the CNO.

If we login to EAC and navigate to Servers->Database Availability Groups, we can create the DAG by click on the plus sign:


Enter in the information for the DAG, and remember to specify your Witness Server.  It should be another Exchange 2013 Server in your primary datacenter location that is not also a member of the DAG.  We will specify one IP address of


If we are doing this in PowerShell, the syntax is different:

New-DatabaseAvailabilityGroup –Name SOA-DAG-2013 –DatabaseAvailabilityGroupIPAddresses ([System.Net.IPAddress]::None) –WitnessServer NYDC-SOAE13CAS1.soa.corp –WitnessDirectory c:\WitnessDirectory\SOA-DAG-2013




Now, from here, building the DAG should have the same steps.  Lets add the mailbox servers to the DAG.  If you don’t already have Windows Failover Clustering installed, these steps will install it for you.

From the EAC:, under Database Availability Groups select the DAG name, and click on the Server with the gearbox icon:












Add your servers to the DAG and click Save:



From the Exchange Management Shell:

Add-DatabaseAvailabilityGroupServer -Identity SOA-DAG-2013 -MailboxServer SFDC-SOAE13MBX2


And your all set.  The DAG has been configured with no Administrative Access. 

If we check the properties of the DAG in the EAC we can see the IP address is listed as



And even though we had that string in the PowerShell command, if we check the IP address in PowerShell, we only have listed as an IP address:



Exchange 2010 Archive Mailbox and Retention Policies–Part 2

DAG, Exchange 2010

We’ll really long time in the making, but one of my most popular articles.  With 2013 out there, I figured I would finish this off, and then add a part 3 that shows a quick rundown of how to do the same thing with 2010. 

So, we have our Archive Mailbox created.  Now, we want to assign a policy so that we perform some automated action, and give users the ability to also make some changes.  There are a ton of posts out there over the mechanics of how the Exchange Archive system works.  I wont revisit it.  Ill try to do so with a more real world example.  So for this example, we want to assign our users with a policy that performs the following:


  1. Users should have the ability to tag emails to move to archive ASAP
  2. Users should have the ability to tag emails to move to archive if they are older than 30 days
  3. Users should have the ability to tag emails to be deleted older than one week
  4. Users should have the ability to mark emails to never be archived
  5. All Emails in the sent items are deleted after 30 days
  6. All Emails older than 90 days are automatically moved to archive if another policy doesn’t apply

It should be noted, that the delete actions and never delete actions work on any mailbox, and the Archive options require an archive mailbox to be enabled for the user.  If an archive mailbox is not enabled, the archive policies have no effect.

Now, if you look at the above, a common question that pops up is around the Never Archive option.  If they have this ability, won’t they be able to completely override the archive setup and store everything in their mailbox?  The answer is technically yes, but if you combine your archive mailbox’s with mailbox limit’s, then the user will hit a point where they can no longer send and/or receive messages, and are forced to archive messages. 

So, next we need to create the Archive Policy and the Archive Tag’s.  Real quick, each email or folder can only have one “tag” assigned to them.  Email’s and folders inherit their parent folder’s tag, but it can be overridden.  The process that handles processing the tags on items is the Managed Folder Assistant. The Assistant checks each item for tags.  If the item doesn’t have a tag explicitly set on it, then the assistant check’s the parent folder for the appropriate tag.  Once it finds a tag, it takes that action on it according to that tag.  So, lets create the needed tag’s for our example above.  Navigate to Organization Configuration->Mailbox->Retention Policy Tags.  Click New Retention Policy Tag and you’ll be presented with the following screen:


So, let’s create the first tag of move items to archive ASAP.  Since there is no ASAP, we will set the Age Limit to 1 day, and change the action to be Move to Archive. The next thing to change is the Tag Type.  If you are giving the users the options to set the tag themselves, it should always be a Personal Tag.  The other tag’s are scoped to a specific folder type.  We will cover this later.  So our configuration looks like the following:


Create the rest of the tags, which should be the same settings, just a different name and age limit.  The only one that is different is the Never Archive.  Here is the config for that:



This will set to tag to never take action. 

So, next are the specific folder actions.  The Sent Items, delete after 30 days for example.  The different here, is that we change the Tag Type to be Sent Items



And for the last step, which is the if another policy doesn’t apply and the emails older than ninety days, move it to archive:


Here, we change the Tag Type to All Other Folders in the Mailbox.

Something to note, there can only ever be 1 specific folder tag’s within a particular policy.  In the next step, we will create our policy and assign it to the users.  We can only include one tag per specific folder.  Meaning if we had two tags that targeted sent items, we cannot include them in the same policy.

So, lets create the policy.  Navigate to Organization Configuration –> Mailbox –> Retention Policies

Create a New Retention Policy, and give it a descriptive name.  Add the tags we just created:


On the next screen, you can select mailbox’s to assign this policy to:


Then create the policy.

We can also assign a policy specifically to a user by going to the Mailbox –> Properties->Mailbox Settings->Message Records Management, and selecting and applying a Retention Policy:


So then you can wait for the Exchange Server to apply the policies.  Remember, Exchange 2010 does it on a work cycle base.  This means Exchange is told to complete a the task of tagging and moving to archive at least x times in y days.  You can check your server by running the command:

Get-MailboxServer –Identity SERVERNAME | Select *ManagedFolderWork*


This should get you a completed run, at least once per day.  You can also run it manually yourself against the mailbox by running the command Start-ManagedFolder usersaccount:


Note, that it can take more than one run for this to work, as it needs to go through first, tag the items, and then the second run will take action on those items.  Now lets look at what the client sees.  Keep in mind you can see it both from Outlook 2010 and later and OWA:

In Outlook, if the user right clicks on a folder and goes to the policy tab.  Here the user will see two drop downs, one for Retention and one for Online Archive:


The default policies for say sent items and all items move to archive over ninety days, the user will never see.  They will only see Personal Tags.  So let’s say I want to set this folder to Never Archive


I change the Online Archive policy to Never.  If I want the policy to delete everything in the folder and subfolders after one week, I change the Retention Policy to be One Week Delete:


Look for my Exchange 2013 one, hopefully in a shorter time frame than it took for Part 2!

Setting Up a Database Availability Group in Exchange 2013

DAG, Exchange 2013, High Availability

We’ll walk through the steps of setting up a Database Availability Group or DAG for short in Exchange 2013.  Our setup is we have two mailbox servers:

PHDC-SOAE13MBX1 – IP Address of

SFDC-SOAE13MBX1 – IP Address of

There are a couple of requirements that we need to ensure are met before we can set up the DAG, and that things run well once we do. 

Requirement #1 – Windows Failover Clustering

For starters, Exchange DAG’s use windows failover clustering as the means to setup the foundation of the DAG.  This means that you will need to install Windows Failover Clustering on each of the mailbox servers that will be a member of the DAG.  The Exchange 2013 DAG setup will perform the install for you, so there is no need to do it ahead of time.  What you do need to know though, is that the underlying Windows operating system needs to be able to install it.  Meaning your Windows OS must be one of the following:

  • Windows Server 2008 R2 Enterprise
  • Windows Server 2012 Standard
  • Windows Server 2012 Enterprise

Requirement #2 – Same Operating System

Since Windows Failover Clustering has this requirement, so does Exchange 2013 DAG’s.  All members of the DAG need to run the same OS level.  Meaning you cannot have one DAG member running 2008 R2 Enterprise and another running 2012 Standard.

Requirement #3 – One DAG per Server

Each mailbox server can only be a member of one DAG at a time. 

Requirement #4 – You Need an IP address for the DAG in each subnet there is a mailbox server

Since the DAG is a cluster, that cluster needs an IP address in each subnet that there is a mailbox server.  This is separate from the mailbox server’s IP address.  In our example, we have two subnets we are spread across:

This means we need an extra IP address for each subnet to assign to the DAG.  In our case we will use:

Requirement #5 – Name of DAG

The name of the DAG needs to fit the NETBIOS requirements, meaning 15 characters or less.

In our example, we will use SOA-DAG-13.

Requirement #6 – Witness Server

We need a Witness Server that will be used in the event that we have an even number of members in the DAG, and there needs to be a tie breaking vote.  Best practice is to use an Exchange 2013 CAS server.  Realistically ANY windows server will do, but you need to add the Exchange Trusted Subsystem as an administrator to that local PC before you can use it.

In our example we will use PHDC-SOAE13CAS1 and use the directory of C:\Witness\SOA-DAG-E13.soa.corp

Optional Requirement – Replication Networks

While it is not required, it is certainly best practice to create a replication network.  With that, you would have an extra NIC on each DAG member that would be dedicated for replication traffic only.  In bigger installations this is certainly recommended as seeding and replication can easily use a significant portion of the bandwidth.

So let’s get started. 

Pre-Stage the DAG CNO

The first thing we need to do is pre-stage the computer name for the DAG. Open up AD Users and Computers.  Navigate to an OU that contains both your Mailbox servers in it.  Right click and create a new computer object.  Fill in the details as necessary:


Next, right click the account you just created and select Disable Account


Now, we need to assign permissions to this account so that the mailbox servers are allowed to manipulate the object, as well as the group Exchange Trusted Subsystem.

In AD Users and Computers, go to View->Advanced Features


Right click the account you created and go to Properties->Security tab.

Add the following objects to the computer account with Full Control

  • Exchange Trusted Subsystem
  • Each mailbox server

(You only really need to the add the first mailbox server that you are using to create the DAG, but just to make things uniform you can add both)




Ensure that AD replication has finished before moving on.

Creating the DAG

First, lets log into the Exchange Control Panel on either of the servers.  You can get there by going to https://servername/ecp .

Navigate to Servers->Database Availability Groups.  In our example, you can see my pre-existing Exchange 2010 DAG:


Click on the + symbol at top to create a new DAG, and enter in the information:


Not that we have added the Name of the DAG, the Witness Server, and the Witness Directory.  Then we add the IP’s we have assigned to the DAG itself underneath.  Click Save to create the DAG.

Now, if we double click and open the DAG, we will note there is nothing in it.  We need to add mailbox servers to it:


Back on the DAG screen, select your DAG object, then select the little server with the gear on it.  This will allow us to manage the membership of the DAG.


Select your mailbox servers:



And click save to begin adding them to the DAG:


If you didn’t install Windows Failover Clustering before hand, this will install it on each node for you.  It can take about five minutes for each server for the entire process.

Eventually the DAG will be complete:


Setting DAC Mode on the DAG

Once your DAG is done, there is one last item you should follow.  On an Exchange 2013 server, open the exchange management shell. run the following command to enable DAC mode:

Set-DatabaseAvailabilityGroup –Identity SOA-DAG-13 –DatacenterActivationMode DAGOnly


The purpose of DAC mode is to help prevent split brain, and also allow you to use to Stop-DatabaseAvailabilityGroup and Start-DatabaseAvailabilityGroup commands for failover.

Now your all set, the last thing to do is to add copies of the database on each DAG member.