Exchange 2010 – DAG – Mapi network issue (MapiAccessEnabled, IgnoreNetwork)

One of our customers has ExRAAS ( Exchange health and remediation check service) every year to audit their environment for health, performance and MS best practices implementation. ExRAAS tools are developed every year and this years tool discovered very interesting issue about DAG networks.

Description:

Our customers DAG has 3 networks:

  • Production – meant to be client network, where only client traffic is enabled, replication traffic is disabled
  • Replication – not routable to MAPI network – custom 5Gbit bandwidth only for log replication
  • Backup – only for VSS backups, no MAPI nor replication traffic should flow there

Problem:

By design DAG is set, that Backup network should be ignored, however if I give Get-DatabaseAvailabilityGroupNetwork command, I can see MapiAccessEnabled parameter in $True, even though this network doesn´t have Clients for Windows Networks feature enabled and according to MS it is not supported network for clients. The magic starts when I set IgnoreNetwork to $false. Right after the change MapiAccessEnabled parameter is in correct value.

Get-DatabaseAvailabilityGroupNetwork DAG1\BACKUP | Set-DatabaseAvailabilityGroupNetwork -IgnoreNetwork $false
Get-DatabaseAvailabilityGroupNetwork | fl

RunspaceId         : 7d204cce-1dde-4e6f-9d52-cde8b238d2a9
Name               : BACKUP
Description        : VSS BACKUP Backup subnet - Ignored
Subnets            : {{172.24.188.0/24,Up}, {172.29.99.0/24,Up}}
Interfaces         : {{DC1MBX1,Up,172.24.188.108}, {DC1MBX2,Up,172.24.188.110}, {DC1MBX3,Up,172.24
                     .188.112}, {DC1PF1,Up,172.24.188.104}, {DC2MBX1,Up,172.29.99.109}, {DC2MBX2,U
                     p,172.29.99.111}, {DC2MBX3,Up,172.29.99.113}, {DC2PF1,Up,172.29.99.105}}
MapiAccessEnabled  : False
ReplicationEnabled : False
IgnoreNetwork      : False
Identity           : DAG1\BACKUP
IsValid            : True

RunspaceId         : 7d204cce-1dde-4e6f-9d52-cde8b238d2a9
Name               : MAPI
Description        : Production and possible replication
Subnets            : {{192.168.0.0/24,Up}}
Interfaces         : {{DC1MBX1,Up,192.168.0.108}, {DC1MBX2,Up,192.168.0.110}, {DC1MBX3,Up,192.168
                     .0.112}, {DC1PF1,Up,192.168.0.104}, {DC2MBX1,Up,192.168.0.109}, {DC2MBX2,
                     Up,192.168.0.111}, {DC2MBX3,Up,192.168.0.113}, {DC2PF1,Up,192.168.0.105}}
MapiAccessEnabled  : True
ReplicationEnabled : False
IgnoreNetwork      : False
Identity           : DAG1\MAPI
IsValid            : True

RunspaceId         : 7d204cce-1dde-4e6f-9d52-cde8b238d2a9
Name               : REPLICATION
Description        : Only replication
Subnets            : {{10.146.231.0/27,Up}}
Interfaces         : {{DC1MBX1,Up,10.146.231.24}, {DC1MBX2,Up,10.146.231.26}, {DC1MBX3,Up,10.146.2
                     31.28}, {DC1PF1,Up,10.146.231.20}, {DC2MBX1,Up,10.146.231.25}, {DC2MBX2,Up,10
                     .147.231.27}, {DC2MBX3,Up,10.146.231.29}, {DC2PF1,Up,10.146.231.21}}
MapiAccessEnabled  : False
ReplicationEnabled : True
IgnoreNetwork      : False
Identity           : DAG1\REPLICATION
IsValid            : True

When I change the Ignorenetwork back to $true, MapiAccessEnabled is set to $True as well.

Get-DatabaseAvailabilityGroupNetwork DAG1\BACKUP | Set-DatabaseAvailabilityGroupNetwork -IgnoreNetwork $true
Get-DatabaseAvailabilityGroupNetwork | fl

RunspaceId         : 7d204cce-1dde-4e6f-9d52-cde8b238d2a9
Name               : BACKUP
Description        : VSS BACKUP Backup subnet - Ignored
Subnets            : {{172.24.188.0/24,Up}, {172.29.99.0/24,Up}}
Interfaces         : {{DC1MBX1,Up,172.24.188.108}, {DC1MBX2,Up,172.24.188.110}, {DC1MBX3,Up,172.24
                     .188.112}, {DC1PF1,Up,172.24.188.104}, {DC2MBX1,Up,172.29.99.109}, {DC2MBX2,U
                     p,172.29.99.111}, {DC2MBX3,Up,172.29.99.113}, {DC2PF1,Up,172.29.99.105}}
MapiAccessEnabled  : True
ReplicationEnabled : False
IgnoreNetwork      : True
Identity           : DAG1\BACKUP
IsValid            : True

Conclusion:

This lead to errors in ExRAAS report and to question what is the right way. How should I behave to the network configuration? Better way is to set IgnorenNetwork parameter to $True and just ignore MapiAccessEnabled in $True. This article will be updated after I get info from MS for the resolution. It is also worth to mention, that last best practice says, that compression and encryption should be ENABLED on DAG replication network!

Links:

http://blogs.technet.com/b/schadinio/archive/2010/12/08/exchange-2010-mailbox-dag-based-practice-network-configurations.aspx

Exchange 2013 configuration part 1. – DAG

DAG description

  • DAG is a forming block for site resilience and data loss prevention as it was in Exchange 2010
  • DAG can consist of 16 nodes forming a group, which protects data from DB, Server and site failures
  • Data protection is on database level (Multiple copies of the same database, where only one copy is active at the same time)
  • Database copy activation is maintained by “Active Manager” which runs on every Exchange server within DAG
  • Active Manager is a part of MS Exchange Replication service (MSExchangeRepl.exe)
  • Active Manager is repsonsible for switchover (moving active copy to another node hosting passive copy of DB) and failover (automatic move of all active DBs to another nodes in case of server failure)

How to manage DAG in Exchange 2013

We can use 2 ways of DAG management in Exchange 2013. Powershell and Exchange Administration Center (Exchange Management Console is not present anymore in Exchange 2013

DAG prerequisites

DAG is simple to be configured, however there are several things to consider before actual configuration:

  • Static IP addresses (If we are going to use static IP addresses, we should register DNS A record prior DAG configuration
  • File Share Witness location – FSW can be automatically configured (usually will be placed on HUB server if it doesnt have Mailbox role on it) or you can configure FSW on other domain server specified by you. FSW can be either placed on DC, which is not supported but possible configuration and it will be also my case, because on my LAB I have only 2xDC, 2x Exchange 2013 multirole server and 1x Exchange 2010 multirole server.
  • At least one replication network should be reserverd and it is recommended to have separate backup segment for mailbox database and system backup (in my case I will only have separate replication network and nodedicated backup network)

Creating DAG

  • DNS A record has been created witg E13DAG and pointing to DAG IP address 192.168.1.55
  • Replication network has been added to virtual machines 192.168.10.0/24 and basic configuration was made (no default GW is needed)
  • Networks priority has been changed to order Production -> Replication -> Backup (if applicable) Open the Network and Sharing center ->Change adapter settings ->  Hold Alt key  and select advanced settings:

  • Witness Directory has been created on DC1 and DC2 servers c:FSWEX13DAG
  • DAG has been created by issuing the following command
New-DatabaseAvailabilityGroup -Name E13DAG -WitnessServer DC1 -WitnessDirectory C:FSWE13DAG1 -DatabaseAvailabilityGroupIPAddress 192.168.1.55
  • Adding nodes to DAG (this task will automatically install Failover clistering to Windows server hodting mailbox role for DAG. Failover Clustering is essential component for creating Active Manager and “Quorum” for DAG)
Add-DatabaseAvailabilityGroupServer -Identity E13DAG -MailboxServer FrontEnd1
  • After second node is added, go to your witness server and check if data has been written to WitnessDirectory. If yes, your FSW is configured correctly. If you have ODD (1,3,5,7..) number of nodes in the DAG, FSW will not be used (will stay empty or with the directory with the last timestapm, when DAG had EVEN number of nodes).

DAG Network configuration

DAG is set to automatic network configuration as default option. This means that we are not able to change any network settings for the DAG. To set DAG to manual mode we will use the following command:

Set-DatabaseAvailabilityGroup E13DAG -ManualDAGNetworkConfiguration $true

After DAG Network configuration is set to manual mode, we can create new DAG networks, assign subnets to them and then remove automatically configured networks from DAG assignment. We can specify which network to use efor clients and which for replication or keep it as default (both enabled for clients and replication)

  • Adding production (client or “MAPI” network with disabled replication)
New-DatabaseAvailabilityGroupNetwork E13DAG -Name Production
Set-DatabaseAvailabilityGroupNetwork E13DAGProd -Name Production -Description Production -ReplicationEnabled $false -Subnets 192.168.1.0/24
  • Adding replication network with disabled client access
New-DatabaseAvailabilityGroupNetwork E13DAG -Name Replication

Set-DatabaseAvailabilityGroupNetwork E13DAGRepl -Name Replication -Description Replication -ReplicationEnabled $true -Subnets 192.168.10.0/24
  • checking network configuration
Get-DatabaseAvailabilityGroupNetwork E13DAG* | fl

DAC mode setting, alternate FSW

This also stays the same as it was in Exchange 2010.  To activate DAC mode DAG must have more than 2 nodes! Note: The directories on WitnessServer and AlternateWitnessServer must be the same (Path, name, share)

Get-DatabaseAvailabilityGroup E13DAG | Set-DatabaseAvailabilityGroup -DatacenterActivationMode DAGOnly -AlternateWitnessDirectory c:FSWE13DAG -AlternateWitnessServer DC2

Gathering Active Manager status

Gathering Active Manager status works as same way as in Exchange 2010: Article is https://exkb.wordpress.com/2012/09/02/exchange-2010-dag-active-manager-determinemove/

Gathering DAG status

This is regular command but it is very important. There are a list of active nodes, nodes under maintenance etc. To gather this info we need to use parameter -Status.

Get-DatabaseAvailabilityGroup E13DAG -Status | fl

In next article I will describe Store differences btween Exchange 2010 and Exchange 2013

Exchange 2010 / 2013 DAG – Active manager determine/move

In some cases it is needed to determine which server is Active manager for DAG and move it away.

  • Determine which server is active manager

We can use two ways. Powershell or command line cmdlets.

In PowerShell we can use cmdlet:

Get-DatabaseAvailabilityGroup -status | select PrimaryActiveManager 

and parameter -Status is needed to gather current state of DAG.

In CMDline we need to be logged on the server, which is part of DAG or has Windows clustering installed. Then the commad line is simple:

cluster group


Move active manager

easiest way is to use cluster command:

cluster group "cluster group" /move:TARGETMACHINE