My Exchange 2013 DAG has gone commando…

Article
04/29/2015

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.

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