My Exchange 2013 DAG has gone commando…


Introduction

 

When running Exchange 2013 on Windows Server 2012 R2, administrators can create a DAG without an administrative access point (which we recommend, by the way). Windows 2012 R2 is the only product dependency for this configuration, making it available to the majority of deployments.  In this post I’d like to take a look at some of the common questions and scenarios that arise from the choice to use this configuration. 

 

What is a DAG without an administrative access point?

 

A DAG without an administrative access point is a DAG whose underlying cluster does not have a cluster name object or associated IP addresses. 

 

Why deploy a DAG without an administrative access point?

 

A DAG without an administrative access point reduces complexity:

 

  • There is no need to pre-stage a computer account object. DAGs without administrative access points do not have computer accounts and are not represented in the directory.
  • There is no need to provision permissions. This especially beneficial for customers with administration delegated to different groups, as provisioning permissions can be a complicated procedure.

 

DAGs without administrative access points also provide benefits in the long run, such as immunity from issues related to the accidental or other loss of the DAG’s computer account. When a traditional DAG is configured, its cluster name object (computer account) is actively in use and must be retained within the directory.  Based on years of experience working on customer support issues, I can tell you it is not uncommon to experience conditions where the computer account is lost.  I’ve had cases where the account has been accidentally deleted by the administrator, or when the DAG’s cluster network name resource was left in a failed state for too long, allowing the computer account to be reclaimed as unused.  When this happens, if the computer account cannot be restored from Active Directory’s dumpster or some form of backup, the DAG may have to be torn down and recreated (all server removed and re-added; data is not lost, but there is downtime).

 

Similarly, DAGs with administrative access points require multiple IP address(es) for the DAG’s cluster (one for each subnet on the MAPI network).  As the default cluster group moves between nodes the Cluster service will activate the appropriate IP address. A DAG with an administrative access point requires healthy and stable name resolution to allow the cluster group to change owners, which has been challenging in some customer environments (for example, dynamic DNS is not available).

 

Furthermore, there are operational benefits. A DAG without a cluster administrative access point has a cluster group with only one resource: the File Share Witness Resource. No cluster IP addresses, and no cluster Network Name resource. Few things in the cluster group means fewer things that can fail. Which in turn translates into fewer alerts, events, etc., and a reduction of information flowing into monitoring systems.

 

How does an administrator deploy a DAG without an administrative access point?

 

There are two ways to create a DAG without an administrative access point; using the Exchange Admin Center, or using the Exchange Management Shell. Below is an example of how to create a DAG without an administrative access point using the Shell (wrapped for readability):

 

New-DatabaseAvailabilityGroup -Name MyDAG -WitnessServer FSW1 -WitnessDirectory C:\MyDAG -DatabaseAvailabilityGroupIpAddresses ([System.Net.IPAddress])::None

 

For more information, see New-DatabaseAvailabilityGroup.

 

In the Exchange Admin Center, you give the DAG an IP address of 255.255.255.255 while creating the DAG. For more information, see Create a Database Availability Group.

 

How does an administrator manage the underling cluster of a DAG without an administrative access point?

 

You really shouldn’t. Really. In most cases, it is not necessary to manage or even look at the underlying Cluster service. The DAG’s integration with the Cluster service enables the Exchange cmdlets to provide the majority of information necessary.

 

When deploying a DAG without an administrative access point, the Failover Cluster Manager tool cannot be used to connect to or manage the cluster.  A logical side effect of not having a Network Name or IP addresses means that the DAG’s cluster is no longer a networked computer (or what we used to call a virtual server or virtual computer object). Even though you still give the DAG a name, that name is not used on the network.

 

image

 

Therefore, to manage the cluster for a DAG without an administrative access point, you must use PowerShell, and you must connect to and run cmdlets against individual nodes. The cluster PowerShell commands are available after importing the failover cluster module (after running Import-Module FailoverClusters)

 

Some commands that administrators may find helpful…

 

Determine cluster properties:

 

PS C:\> Get-Cluster -Name MBX-1 | select *

Domain                                  : domain.com
Name                                    : DAG
AddEvictDelay                           : 60
AdministrativeAccessPoint               : None
BackupInProgress                        : 0
ClusSvcHangTimeout                      : 60
ClusSvcRegroupOpeningTimeout            : 5
ClusSvcRegroupPruningTimeout            : 5
ClusSvcRegroupStageTimeout              : 5
ClusSvcRegroupTickInMilliseconds        : 300
ClusterGroupWaitDelay                   : 120
MinimumNeverPreemptPriority             : 3000
MinimumPreemptorPriority                : 1
ClusterEnforcedAntiAffinity             : 0
ClusterLogLevel                         : 3
ClusterLogSize                          : 300
CrossSubnetDelay                        : 1000
CrossSubnetThreshold                    : 5
DefaultNetworkRole                      : 2
Description                             :
FixQuorum                               : 0
WitnessDynamicWeight                    : 0
HangRecoveryAction                      : 3
IgnorePersistentStateOnStartup          : 0
LogResourceControls                     : 0
PlumbAllCrossSubnetRoutes               : 0
PreventQuorum                           : 0
QuorumArbitrationTimeMax                : 90
RequestReplyTimeout                     : 60
RootMemoryReserved                      : 4294967295
RouteHistoryLength                      : 10
SameSubnetDelay                         : 1000
SameSubnetThreshold                     : 5
SecurityLevel                           : 1
SharedVolumeCompatibleFilters           : {}
SharedVolumeIncompatibleFilters         : {}
SharedVolumesRoot                       : C:\ClusterStorage
SharedVolumeSecurityDescriptor          : {1, 0, 4, 128...}
ShutdownTimeoutInMinutes                : 20
DrainOnShutdown                         : 1
SharedVolumeVssWriterOperationTimeout   : 1800
NetftIPSecEnabled                       : 1
LowerQuorumPriorityNodeId               : 0
UseClientAccessNetworksForSharedVolumes : 0
BlockCacheSize                          : 0
WitnessDatabaseWriteTimeout             : 300
WitnessRestartInterval                  : 15
RecentEventsResetTime                   : 6/18/2014 5:07:16 PM
EnableSharedVolumes                     : Enabled
DynamicQuorum                           : 1
CsvBalancer                             : 1
DatabaseReadWriteMode                   : 0
MessageBufferLength                     : 50
Id                                      : 7a4613f4-67e7-406d-b528-5a1af207108a

 

Determine the nodes in the cluster and node state:

 

PS C:\> Get-ClusterNode -Cluster MBX-1

Name                 ID    State
----                 --    -----
MBX-1                2     Up
MBX-2                1     Up
MBX-3                3     Up
MBX-4                4     Up

 

Gather individual node properties:

 

PS C:\> Get-ClusterNode -Cluster MBX-1 -Name MBX-1 | select *

Cluster            : DAG
State              : Up
Id                 : 2
Name               : MBX-1
NodeName           : MBX-1
NodeHighestVersion : 533888
NodeLowestVersion  : 533888
MajorVersion       : 6
MinorVersion       : 3
BuildNumber        : 9600
CSDVersion         :
NodeInstanceID     : 00000002-0000-0000-0000-000000000002
Description        :
DrainStatus        : NotInitiated
DrainTarget        : 4294967295
DynamicWeight      : 1
NodeWeight         : 1
NeedsPreventQuorum : 0

 

Gather cluster network states:

 

PS C:\> Get-ClusterNetwork -Cluster MBX-1

Name                                                                                                              State
----                                                                                                              -----
Cluster Network 1                                                                                                    Up
Cluster Network 2                                                                                                    Up
Cluster Network 3                                                                                                    Up
Cluster Network 4                                                                                                    Up
Cluster Network 5                                                                                                    Up
Cluster Network 6                                                                                                    Up
Cluster Network 7                                                                                                    Up

 

Gather cluster network properties:

 

PS C:\> Get-ClusterNetwork -Name "Cluster Network 1" -Cluster MBX-1 | select *

Cluster           : DAG
State             : Up
Name              : Cluster Network 1
Ipv6Addresses     : {}
Ipv6PrefixLengths : {}
Ipv4Addresses     : {192.168.0.0}
Ipv4PrefixLengths : {24}
Address           : 192.168.0.0
AddressMask       : 255.255.255.0
Description       :
Role              : 3
AutoMetric        : True
Metric            : 70080
Id                : 74f02724-c877-409e-98e0-54aa48e7ac27

 

Gather cluster interface properties:

 

PS C:\> Get-ClusterNetworkInterface -Cluster MBX-1 -Node MBX-1

Name                          Node                          Network                                               State
----                          ----                          -------                                               -----
MBX-1 - LAN-CLUSTER-A         MBX-1                         Cluster Network 4                                        Up
MBX-1 - LAN-CLUSTER-B         MBX-1                         Cluster Network 2                                        Up
MBX-1 - LAN-iSCSI-A           MBX-1                         Cluster Network 7                                        Up
MBX-1 - LAN-iSCSI-B           MBX-1                         Cluster Network 6                                        Up
MBX-1 - LAN-REPL-A            MBX-1                         Cluster Network 5                                        Up
MBX-1 - LAN-REPL-B            MBX-1                         Cluster Network 3                                        Up
MBX-1 - LAN-TEAM              MBX-1                         Cluster Network 1                                        Up

 

Gather individual cluster network interface properties:

 

PS C:\> Get-ClusterNetworkInterface -Cluster MBX-1 -Name "MBX-1 - LAN-TEAM" | select *

Cluster       : DAG
Network       : Cluster Network 1
State         : Up
Name          : MBX-1 - LAN-TEAM
Node          : MBX-1
Adapter       : Microsoft Network Adapter Multiplexor Driver
AdapterId     : A4CDB166-4903-4BC7-9ADF-6C89BD157FF2
DhcpEnabled   : 0
Ipv6Addresses : {}
Ipv4Addresses : {192.168.0.13}
Address       : 192.168.0.13
Description   :
Id            : aee48b12-e414-424d-8997-fc0b21e0c05f

 

Gather the cluster quorum status configuration:

 

PS C:\> Get-ClusterQuorum -Cluster MBX-1 | fl

Cluster        : DAG
QuorumResource : File Share Witness (\\dc-0.domain.com\DAG.domain.com)
QuorumType     : NodeAndFileShareMajority

 

Gather the cluster group status:

 

PS C:\> Get-ClusterGroup -Cluster MBX-1

Name                                    OwnerNode                               State
----                                    ---------                               -----
Available Storage                       MBX-2                                   Offline
Cluster Group                           MBX-2                                   Online

 

Move the cluster group between nodes:

 

PS C:\> Move-ClusterGroup -Cluster MBX-1 -Name "Cluster Group" -Node MBX-2

Name                                    OwnerNode                               State
----                                    ---------                               -----
Cluster Group                           MBX-2                                   Online

 

Gather the cluster logs:

 

Get-ClusterLog –cluster MBX-1

 

Gather the cluster resource state:

 

PS C:\> Get-ClusterResource -Cluster MBX-1 | fl

Name         : File Share Witness (\\dc-0.domain.com\DAG.domain.com)
State        : Online
OwnerGroup   : Cluster Group
ResourceType : File Share Witness

 

 

How does a DAG without an administrative access point determine the primary active manager (PAM) of the DAG?

 

The same exact way as always. It is a common myth that the state of the cluster core resources – specifically the name and IP addresses – determined the state of the primary active manager. The node that owns the default cluster group holds the PAM role. DAGs without an administrative access point still have a default cluster group and this group still has an owner.

 

Cluster Group:

 

PS C:\> Get-ClusterGroup -Cluster MBX-1

Name                                    OwnerNode                               State
----                                    ---------                               -----
Available Storage                       MBX-2                                   Offline
Cluster Group                           MBX-2                                   Online

 

Primary Active Manager:

 

[PS] C:\>Get-DatabaseAvailabilityGroup -Identity DAG -status | fl name,primaryActiveManager

Name                 : DAG
PrimaryActiveManager : MBX-2

 

Arbitrating the cluster group between nodes will demote the current owner to a standby active manager ( SAM ) while promoting the server receiving the group to a primary active manager ( PAM ).

 

PS C:\> Move-ClusterGroup -Name "Cluster Group" -Node MBX-1 -Cluster MBX-1

Name                                    OwnerNode                               State
----                                    ---------                               -----
Cluster Group                           MBX-1                                   Online

 

[PS] C:\>Get-DatabaseAvailabilityGroup -Identity DAG -status | fl name,primaryActiveManager

Name                 : DAG
PrimaryActiveManager : MBX-1

 

Are there any considerations when deploying a DAG without an administrative access point?

 

As part of Exchange’s preferred architecture, it is preferred that DAGs be deployed without an administrative access points. Exchange has no dependencies on the cluster name or cluster IP addresses. There are some third party products that integrate with Exchange 2013 that don’t support this configuration, though.  So check with your application vendor to see if it is supported and if not consider switching applications


Comments (11)

  1. TIMMCMIC says:

    @John...

    @Jetze:

    As Jetze points out it's in the last paragraph.

    Like I said - at somepoint demand to support the 'default' will hopefully trump not supporting it. There are several ways to make it work - for example - a customer worked with their vendor to create a host file entry on the backup server for the "dagname"
    that just pointed to a single node. Obviously backups failed if the single node was down...but at least they could support a less complicated solution overall.

    Plus - you could just consider not backing up at all....

    TIMMCMIC

  2. TIMMCMIC says:

    @TurboMCP

    HI!

    TIMMCMIC

  3. TIMMCMIC says:

    @Jetze:

    So not to necessarily turn this into a debate about backups - but one thing to keep in mind with the preferred architecture is that it's not designed to cherry pick the pieces that fit. For example, backups are not part of the preferred but rather Exchange
    Native Data Protection is...so in theory if the preferred architecture was being deployed (with this recommendation for dags without administrative access points) we wouldn't be having the backup conversation.

    TIMMCMIC

  4. @Jon: It's there, hidden in the last paragraph. I only read it while already typing my comment.

  5. "There are several ways to make it work - for example - a customer worked with their vendor to create a host file entry on the backup server for the "dagname" that just pointed to a single node. Obviously backups failed if the single node was down...but
    at least they could support a less complicated solution overall. "

    The workaround you mentioned happens to work for Symantec Netbackup, not for Symantec BackupExec just to name some products. So I'm not sure about the "several ways to make it work", in reality your options are very limited. At least, that's my experience with
    some customers.

    One of my customers considered the workaround with the HOSTS file to force a connection to a static server but decided this was not acceptable for their standards. And I agree with that thinking. What's the point of following the advice in the Preferred Architecture
    when that means you have to cripple other essential parts of the infrastructure?

    Anyway, Symantec has announced they will add support for AAPless DAGs in the V.next of BackupExec and I expect other vendors to follow. Then again, it took some of them multiple major releases to properly adapt to the Exchange 2010 DAG model so it may take
    a while...

  6. I had to roll back an DAG without AAP and replace with a traditional DAG cluster once because customer's backup software was not compatible with this feature. My understanding is that very vendors yet do support a DAG without an AAP. Heard of other organizations
    running into similar issues.

    So until the major 3rd party vendors offer support for this new DAG, I'm afraid we will be deploying traditional DAGs for some time. That's a shame because this is a great feature to eliminate some complexity.

  7. Jon says:

    No mention of the primary issue customers face - that the majority of backup software would need to be updated or install the latest version in order to back up the DAG without an administrative access point?!

  8. turbomcp says:

    Thanks tim
    always interesting
    btw we can call the cow by its name "Symantec" 🙂 "netbackup and sons" 🙂

  9. Does DPM 2012 support Exchange 2013 DAG without cluster AAP?

  10. TIMMCMIC says:

    @Martijn...

    Yes

    TIMMCMIC

  11. Customer runs DPM 2012 SP1 (not R2). So, Exchange 2013 DAG without cluster AAP is supported with DPM 2012. Where can I find an explicit statement about this? Thanks!

Skip to main content