Customers may have users with a security principal within their domain that do not have a mailbox hosted within their messaging solution.  In this event customers choose to mail enable the user accounts.  In an Exchange environment mail enabled users accounts appear in the address list as if a local mailbox exists but mail destined for these objects are sent to the external email address stamped on the object.

 

When using directory synchronization with Office 365 these objects are subsequently replicated into the MSOL directory as user accounts.  Exchange online then detects the presence of these mail enabled user accounts and subsequently creates a mail enabled user object in the Exchange Online directory.  This is what allows the user to appear in the Exchange Online address list.

 

Let’s take a look at an example.

 

In the on premises active directory a user account is provisioned.  This account is what allows for logon privileges to the domain.

 

[PS] C:>Get-User BlogTest

Name                                                        RecipientType
—-                                                        ————-
Blog Test                                                   User

 

The account is then mail enabled using the enable-mailUser commandlet.

 

[PS] C:>Enable-MailUser BlogTest -ExternalEmailAddress user@microsoft.com

Name                                     RecipientType
—-                                     ————-
Blog Test                                MailUser

 

Using the get-mailUser commandlet we can validate the settings of this user including the external email address set on the object.

 

[PS] C:>Get-MailUser BlogTest | fl externalemailaddress,userprincipalname,displayname,emailaddresses,primarysmtpaddress
,recipienttype

ExternalEmailAddress : SMTP:user@microsoft.com
UserPrincipalName    : BlogTest@domain.com
DisplayName          : Blog Test
EmailAddresses       : {smtp:BlogTest@domain1.domain2.com, smtp:BlogTest@serviceDomain.mail.onmicrosoft.com,
                       smtp:BlogTest@domain.com, SMTP:user@microsoft.com}
PrimarySmtpAddress   : user@microsoft.com
RecipientType        : MailUser

 

When directory synchronization occurs the object can be validated in the MSOL directory using get-MSOLUser.

 

PS C:> Get-MsolUser -UserPrincipalName BlogTest@Domain2 | fl DisplayName,ProxyAddresses

DisplayName    : Blog Test
ProxyAddresses : {smtp:BlogTest@ServiceDomain.onmicrosoft.com, smtp:BlogTest@Domain2,
                 smtp:BlogTest@DOMAIN1.Domain2, smtp:BlogTest@ServiceDomain.mail.onmicrosoft.com…}

 

When the provisioning process has had time to detect and operate on the object a mail user object is created in Exchange Online.  This can be validated with the get-MailUser command when connected to Exchange Online.

 

PS C:> Get-MailUser BlogTest | fl externalemailaddress,userprincipalname,displayname,emailaddresses,primarysmtpaddress,
recipientType

ExternalEmailAddress : SMTP:user@microsoft.com
UserPrincipalName    : BlogTest@domain.com
DisplayName          : Blog Test
EmailAddresses       : {SMTP:user@microsoft.com, smtp:BlogTest@servicedomain.mail.onmicrosoft.com,
                       smtp:BlogTest@domain1.domain2.com, smtp:BlogTest@domain.com…}
PrimarySmtpAddress   : user@microsoft.com
RecipientType        : MailUser

 

At this time the object is fully provisioned and will appear in the Exchange Online global address list.  Users who select this object from the global address list will successfully send email to the remote mailbox.

 

 

 

There may exist at some time a reason to remove the on premises Active Directory user account.  When this object is removed and directory synchronization is performed this should result in the removal of the MSOL user account as well as the mail user account within Exchange Online.  Let’s look at an example.

 

Using Active Directory Users and Computers the on premises AD object is deleted.  This can be validated with Get-User.

 

[PS] C:>Get-User BlogTest

The operation couldn't be performed because object 'BlogTest' couldn't be found on 'Server1.domain.domain.com'.
    + CategoryInfo          : NotSpecified: (:) [Get-User], ManagementObjectNotFoundException
    + FullyQualifiedErrorId : [Server=MAIL,RequestId=95b95c5e-03c2-406a-9400-c490c0d7cddb,TimeStamp=5/13/2014 1:34:34PM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] 4549B0D2,Microsoft.Exchange.Management.RecipientTasks.GetUser
    + PSComputerName        : mail.domain.domain.com

 

This also results in the removal of the on premises mail user object.  This can be validated with Get-MailUser.

 

[PS] C:>Get-MailUser BlogTest

The operation couldn't be performed because object 'BlogTest' couldn't be found on 'Server1.domain1.domain2.com'.
    + CategoryInfo          : NotSpecified: (:) [Get-MailUser], ManagementObjectNotFoundException
    + FullyQualifiedErrorId : [Server=MAIL,RequestId=0106f632-ad95-4f07-b054-4e749e437cfc,TimeStamp=5/13/2014 1:35:55PM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] 84EC86F5,Microsoft.Exchange.Management.RecipientTasks.GetMailUser
    + PSComputerName        : mail.domain1.domain2.com

 

When directory synchronization has completed we can validate the object no longer exists in the MSOL directory using get-MSOLUser.

 

PS C:> Get-MsolUser -UserPrincipalName BlogTest@domain2.com | fl DisplayName,ProxyAddresses

Get-MsolUser : User Not Found.  User: BlogTest@domain2.com.
At line:1 char:1
+ Get-MsolUser -UserPrincipalName BlogTest@domain2.com | fl DisplayName,Pro …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [Get-MsolUser], MicrosoftOnlineException
    + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.UserNotFoundException,Microsoft.Online.Administration.Automation.GetUser

 

When the provisioning process has detected the deletion the mail user object is removed from Exchange Online.  This can be validated with get-MailUser.

 

PS C:> Get-MailUser BlogTest

The operation couldn't be performed because object 'BlogTest' couldn't be found on 'CO1PR06A002DC02.NAMPR06A002.prod.outlook.com'.
    + CategoryInfo          : NotSpecified: (:) [Get-MailUser], ManagementObjectNotFoundException
    + FullyQualifiedErrorId : [Server=BN1PR06MB101,RequestId=c3cde9d7-e638-4808-8891-65d539689698,TimeStamp=5/13/2014 1:40:19 PM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] 782EAA9B,Microsoft.Exchange.Management.RecipientTasks.GetMailUser
    + PSComputerName        : pod51043psh.outlook.com

 

The object after deletion from the Exchange Online directory will no longer appear in the address list. 

 

 

End users who desire to email this object would have to address the message manually to the external email address.  For example:

 

 

This is where the issue arises.  In this instance the user has successfully addressed an email to the external email address but the mail is returned with a non-delivery report.

 

 

Delivery has failed to these recipients or groups:

Blog Test

The email address you entered couldn't be found. Check the recipient's email address then try to resend the message. For more tips to resolve this issue see DSN code 5.1.1 in Exchange Online. If the problem continues contact your help desk.

 

The diagnostic information states the following:

 

Diagnostic information for administrators:
Generating server: DM2PR0601MB0953.namprd06.prod.outlook.com
IMCEAEX-_o=ExchangeLabs_ou=Exchange+20Administrative+20Group+20+28FYDIBOHF23SPDLT+29_cn=Recipients_cn=0729272369574e7d945aeeecf1afd94c-Blog+20Test@namprd06.prod.outlook.com
Remote Server returned '550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found'
Original message headers:

Received: from DM2PR0601MB0953.namprd06.prod.outlook.com (25.160.25.145) by
DM2PR0601MB0953.namprd06.prod.outlook.com (25.160.25.145) with Microsoft SMTP
Server (TLS) id 15.0.944.11; Tue, 13 May 2014 13:43:53 +0000
Received: from DM2PR0601MB0953.namprd06.prod.outlook.com ([25.160.25.145]) by
DM2PR0601MB0953.namprd06.prod.outlook.com ([25.160.25.145]) with mapi id
15.00.0944.000; Tue, 13 May 2014 13:43:53 +0000
Content-Type: application/ms-tnef; name="winmail.dat"
Content-Transfer-Encoding: binary
From: Dev User <DevUser@servicedomain.onmicrosoft.com>
To: Blog Test <user@microsoft.com>
Subject: Test Message
Thread-Topic: Test Message
Thread-Index: AQHPbrFT/8JoaY496EePsUIz8dp/Tw==
Date: Tue, 13 May 2014 13:43:52 +0000
Message-ID: <1399988632393.9363@FortMillRescueSquad.onmicrosoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator: <1399988632393.9363@servicedomain.onmicrosoft.com>
MIME-Version: 1.0
X-Originating-IP: [167.220.151.116]
Return-Path: DevUser@serviceDomain.onmicrosoft.com

 

For many administrators this NDR is recognizable.  The same NDR is generated when an object is deleted from the environment but the email is addressed using nickname or recipient cache.  In this instance though the email was not addressed using nickname or recipient cache but rather the SMTP address was fully typed in the TO: line.  (Note:  The email address was manually removed from the nickname cache prior to addressing the email to ensure that automatic resolution does not occur.)

 

Why is the mail NDRing.  When a user account is removed from the MSOL directory the account is placed into a soft deleted state.  This can be validated with get-MSOLUser –returnedDeletedUsers.

 

PS C:> Get-MsolUser -UserPrincipalName BlogTest@domain.com -ReturnDeletedUsers

UserPrincipalName                       DisplayName                             isLicensed
—————–                       ———–                             ———-
BlogTest@domain.com                     Blog Test                               False

 

While the user remains in a soft deleted state within the MSOL directory the corresponding mail user object remains in a soft deleted state within Exchange Online.  It is believed that the recipient resolvers within transport detect the presences of the soft deleted mail user object within the Exchange Online directory and subsequently produce a non-delivery report based on the state of this object.

 

This mail is legitimate though – how can the issue be resolved?

 

In order to remove the soft deleted mail user object from the Exchange Online directory the soft deleted user object must be removed from the MSOL directory.  This can be accomplished with remove-MSOLUser.

 

PS C:> Remove-MsolUser -UserPrincipalName BlogTest@domain.com -RemoveFromRecycleBin

Confirm
Continue with this operation?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): y

 

The results can be validated with Get-MSOLUser.

 

PS C:> Get-MsolUser -UserPrincipalName BlogTest@domain.com -ReturnDeletedUsers
Get-MsolUser : User Not Found.  User: BlogTest@fortmillrescue.com.
At line:1 char:1
+ Get-MsolUser -UserPrincipalName BlogTest@fortmillrescue.com -ReturnDeletedUsers
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [Get-MsolUser], MicrosoftOnlineException
    + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.UserNotFoundException,Microsoft.Online.Administration.Automation.GetUser

 

The provisioning process will eventually detect the deletion of the object from the MSOL directory.  This will cause the soft deleted mail user object to be purged from the Exchange Online directory.  After this object is purged mail should deliver successfully to the external account when the full external email address is utilized.

 

 

At this time anytime a mail user object is removed from the on premises directory the corresponding soft deleted MSOL object would need to also be removed in order to ensure that mail addressed to the external object will immediately function.  In many cases the soft deleted MSOL object will expire, resulting in the removal of the soft deleted mail user object from the Exchange Online directory, prior to this issue being noticed by the end user population.

 

Our development teams are aware of this behavior and are considering potential future service modifications.

In both Exchange 2010 and Exchange 2013, customers can deploy one or more replication networks in a database availability group (DAG).  There can be many reasons for using a replication network, but in most cases they are used to provide a dedicated log shipping channel between members of the same DAG.

 

As documented on TechNet, when a replication network fails, replication should automatically failover to the DAG’s MAPI network:

· http://technet.microsoft.com/en-us/library/dd638104(v=exchg.150).aspx (Exchange 2013)

· http://technet.microsoft.com/en-us/library/dd638104(v=exchg.141).aspx (Exchange 2010)

 

“In the event of a failure affecting the Replication network, if the MAPI network is unaffected by the failure, log shipping and seeding operations will revert to use the MAPI network, even if the MAPI network has it's ReplicationEnabled property set to False.”

 

Log shipping operations occur by connecting to the Microsoft Exchange Replication service on the server that hosts the active database copy, on TCP port 64327 using a random ephemeral port on the passive server.  Log files are then pushed from the active server to the passive server via this channel.  There can exist several issues that result in this log shipping channel being interrupted.  For example, a firewall may block port 64327, static routes may be missing on multi-subnet replication networks, or an intermediary network device may not route traffic correctly. 

 

In the following example, we have a 4-member DAG running Exchange 2013.  There is a single active database that is replicated to three other servers.

 

 

The DAG has two networks that each has two subnets.  These networks represent the MAPI and Replication networks for the DAG.  Automatic network detection in Exchange 2013 was disabled for this example.

 

RunspaceId         : 60e6ae0f-e69d-4ae6-9fcb-8c99ea9fd21f
Name               : MapiDagNetwork
Description        :
Subnets            : {{192.168.0.0/24,Up}, {192.168.1.0/24,Up}}
Interfaces         : {{MBX-1,Up,192.168.0.11}, {MBX-2,Up,192.168.0.12}, {MBX-3,Up,192.168.1.11},
                     {MBX-4,Up,192.168.1.12}}
MapiAccessEnabled  : True
ReplicationEnabled : True
IgnoreNetwork      : False
Identity           : DAGMapiDagNetwork
IsValid            : True
ObjectState        : New

RunspaceId         : 60e6ae0f-e69d-4ae6-9fcb-8c99ea9fd21f
Name               : ReplicationDagNetwork01
Description        :
Subnets            : {{10.0.1.0/24,Up}, {10.0.0.0/24,Up}}
Interfaces         : {{MBX-1,Up,10.0.0.1}, {MBX-2,Up,10.0.0.2}, {MBX-3,Up,10.0.1.1}, {MBX-4,Up,10.0.1.2}}
MapiAccessEnabled  : False
ReplicationEnabled : True
IgnoreNetwork      : False
Identity           : DAGReplicationDagNetwork01
IsValid            : True
ObjectState        : New

 

Using Get-MailboxDatabaseCopyStatus with the –ConnectionStatus switch, we can verify that the Replication network is currently in use:

 

[PS] C:>Get-MailboxDatabaseCopyStatus * -connectionStatus | fl name,incominglogcopyingnetwork,outgoingconnections

Name                      : DAG-DB0MBX-1
IncomingLogCopyingNetwork :
OutgoingConnections       : {}

Name                      : DAG-DB0MBX-2
IncomingLogCopyingNetwork : {MBX-1,ReplicationDagNetwork01}
OutgoingConnections       :

Name                      : DAG-DB0MBX-3
IncomingLogCopyingNetwork : {MBX-1,ReplicationDagNetwork01}
OutgoingConnections       :

Name                      : DAG-DB0MBX-4
IncomingLogCopyingNetwork : {MBX-1,ReplicationDagNetwork01}
OutgoingConnections       :

 

The router servicing the network link between the two subnets of the Replication network is shutdown.  This will block replication from succeeding over the Replication network.  What happens to the database copies?

 

[PS] C:>Get-MailboxDatabaseCopyStatus * | fl name,status

Name   : DAG-DB0MBX-1
Status : Mounted

Name   : DAG-DB0MBX-2
Status : Healthy

Name   : DAG-DB0MBX-3
Status : DisconnectedAndHealthy

Name   : DAG-DB0MBX-4
Status : DisconnectedAndHealthy

 

In this example, the database copies enter a DisconnectedAndHealthy state.  Reviewing the connection status, we note that the connection has timed out between the servers; this is expected since the route is down.

 

[PS] C:>Get-MailboxDatabaseCopyStatus * -ConnectionStatus | fl name,incominglogcopyingnetwork,outgoingconnections

Name                      : DAG-DB0MBX-1
IncomingLogCopyingNetwork :
OutgoingConnections       : {{MBX-2,ReplicationDagNetwork01}}

Name                      : DAG-DB0MBX-2
IncomingLogCopyingNetwork : {MBX-1,ReplicationDagNetwork01}
OutgoingConnections       :

Name                      : DAG-DB0MBX-3
IncomingLogCopyingNetwork : {MBX-1,,A timeout occurred while communicating with server 'MBX-1'. Error: "A connection
                            could not be completed within 15 seconds."}
OutgoingConnections       :

Name                      : DAG-DB0MBX-4
IncomingLogCopyingNetwork : {MBX-1,,A timeout occurred while communicating with server 'MBX-1'. Error: "A connection
                            could not be completed within 15 seconds."}
OutgoingConnections       :

 

Why didn’t the Replication network failover to the MAPI network in this case?  For one thing, the ability to establish a log shipping channel is not one of the criteria that the Replication service uses to determine the health of a given network.  The Replication service relies on feedback from the Cluster service regarding individual network interface status in order to determine the health of a log shipping channel.

 

For each subnet that exists on a DAG member, an associated cluster network is created.  In this example, there are 4 subnets and therefore there are 4 cluster networks.

 

[PS] C:>Get-ClusterNetwork | fl

Name  : Cluster Network 1
State : Up

Name  : Cluster Network 2
State : Up

Name  : Cluster Network 3
State : Up

Name  : Cluster Network 4
State : Up

 

 

The interface associated with each of these subnets is included in the appropriate cluster network.  Each of these interfaces has a status based on status reporting in Windows Failover Clustering.

 

[PS] C:>Get-ClusterNetworkInterface | fl

Name    : MBX-1 – LAN-A
Node    : MBX-1
Network : Cluster Network 1
State   : Up

Name    : MBX-2 – LAN-A
Node    : MBX-2
Network : Cluster Network 1
State   : Up

Name    : MBX-1 – REPL-A
Node    : MBX-1
Network : Cluster Network 2
State   : Up

Name    : MBX-2 – REPL-A
Node    : MBX-2
Network : Cluster Network 2
State   : Up

Name    : MBX-3 – REPL-B
Node    : MBX-3
Network : Cluster Network 3
State   : Up

Name    : MBX-4 – REPL-B
Node    : MBX-4
Network : Cluster Network 3
State   : Up

Name    : MBX-3 – LAN-B
Node    : MBX-3
Network : Cluster Network 4
State   : Up

Name    : MBX-4 – LAN-B
Node    : MBX-4
Network : Cluster Network 4
State   : Up

 

 

In this scenario, the Cluster service considers all of the interfaces as “UP.”  Since the interfaces are UP, the Replication service does not failover to the MAPI network even though replication cannot occur over the replication network. 

 

If the Cluster service reports a network as “FAILED” the behavior is different.  On a server hosting a passive database copy, the network cable was removed from the Replication network interface, causing the cluster to mark that interfaces as failed:

 

[PS] C:>Get-ClusterNetworkInterface | fl

Name    : MBX-1 – LAN-A
Node    : MBX-1
Network : Cluster Network 1
State   : Up

Name    : MBX-2 – LAN-A
Node    : MBX-2
Network : Cluster Network 1
State   : Up

Name    : MBX-1 – REPL-A
Node    : MBX-1
Network : Cluster Network 2
State   : Up

Name    : MBX-2 – REPL-A
Node    : MBX-2
Network : Cluster Network 2
State   : Up

Name    : MBX-3 – REPL-B
Node    : MBX-3
Network : Cluster Network 3
State   : Up

Name    : MBX-4 – REPL-B
Node    : MBX-4
Network : Cluster Network 3
State   : Failed

Name    : MBX-3 – LAN-B
Node    : MBX-3
Network : Cluster Network 4
State   : Up

Name    : MBX-4 – LAN-B
Node    : MBX-4
Network : Cluster Network 4
State   : Up

 

The copy status for the databases hosted on MBX-4 is healthy.

 

[PS] C:>Get-MailboxDatabaseCopyStatus *

Name                                          Status          CopyQueue ReplayQueue LastInspectedLogTime   ContentIndex
                                                              Length    Length                             State
—-                                          ——          ——— ———– ——————–   ————
DAG-DB0MBX-1                                 Mounted         0         0                                  Healthy
DAG-DB0MBX-2                                 Healthy         0         0           4/29/2014 2:11:47 PM   Healthy
DAG-DB0MBX-3                                 Healthy         0         0           4/29/2014 2:11:47 PM   Healthy
DAG-DB0MBX-4                                 Healthy         0         0           4/29/2014 2:11:47 PM   Healthy

 

When reviewing the connection status for the databases on MBX-4, we see that the Replication service is using the MAPI network for log shipping.  Servers that have no issues with the Replication interface continue to use that interface.

 

[PS] C:>Get-MailboxDatabaseCopyStatus * -ConnectionStatus | fl name,incominglogcopyingnetwork,outgoingconnections

Name                      : DAG-DB0MBX-1
IncomingLogCopyingNetwork :
OutgoingConnections       : {}

Name                      : DAG-DB0MBX-2
IncomingLogCopyingNetwork : {MBX-1,ReplicationDagNetwork01}
OutgoingConnections       :

Name                      : DAG-DB0MBX-3
IncomingLogCopyingNetwork : {MBX-1,ReplicationDagNetwork01}
OutgoingConnections       :

Name                      : DAG-DB0MBX-4
IncomingLogCopyingNetwork : {MBX-1,MapiDagNetwork}
OutgoingConnections       :

 

When the interface was marked as failed, the Replication service successfully failed over to the MAPI network.

 

But what happens if the interface is not FAILED, but the interface configuration is invalid?   In this event, the Cluster service cannot pass cluster traffic between these two interfaces and the associated network is marked as partitioned.

 

[PS] C:>Get-ClusterNetwork | fl

Name  : Cluster Network 1
State : Up

Name  : Cluster Network 2
State : Up

Name  : Cluster Network 3
State : Partitioned

Name  : Cluster Network 4
State : Up

 

The interfaces within the partitioned network are marked as unreachable.

 

[PS] C:>Get-ClusterNetworkInterface | fl

Name    : MBX-1 – LAN-A
Node    : MBX-1
Network : Cluster Network 1
State   : Up

Name    : MBX-2 – LAN-A
Node    : MBX-2
Network : Cluster Network 1
State   : Up

Name    : MBX-1 – REPL-A
Node    : MBX-1
Network : Cluster Network 2
State   : Up

Name    : MBX-2 – REPL-A
Node    : MBX-2
Network : Cluster Network 2
State   : Up

Name    : MBX-3 – REPL-B
Node    : MBX-3
Network : Cluster Network 3
State   : Unreachable

Name    : MBX-4 – REPL-B
Node    : MBX-4
Network : Cluster Network 3
State   : Unreachable

Name    : MBX-3 – LAN-B
Node    : MBX-3
Network : Cluster Network 4
State   : Up

Name    : MBX-4 – LAN-B
Node    : MBX-4
Network : Cluster Network 4
State   : Up

 

 

What happens to the copies that are hosted on the servers with an unreachable interface status?

 

[PS] C:>Get-MailboxDatabaseCopyStatus * | fl name,status

Name   : DAG-DB0MBX-1
Status : Mounted

Name   : DAG-DB0MBX-2
Status : Healthy

Name   : DAG-DB0MBX-3
Status : DisconnectedAndHealthy

Name   : DAG-DB0MBX-4
Status : DisconnectedAndHealthy

 

An unreachable interface is not the same as a failed interface.  This resulted in the databases entering a disconnected state and replication not failing over to the MAPI network.  The connection status confirms this failure.

 

[PS] C:>Get-MailboxDatabaseCopyStatus * -ConnectionStatus | fl name,incominglogcopyingnetwork,outgoingconnections

Name                      : DAG-DB0MBX-1
IncomingLogCopyingNetwork :
OutgoingConnections       : {}

Name                      : DAG-DB0MBX-2
IncomingLogCopyingNetwork : {MBX-1,ReplicationDagNetwork01}
OutgoingConnections       :

Name                      : DAG-DB0MBX-3
IncomingLogCopyingNetwork : {MBX-1,,A timeout occurred while communicating with server 'MBX-1'. Error: "A connection
                            could not be completed within 15 seconds."}
OutgoingConnections       :

Name                      : DAG-DB0MBX-4
IncomingLogCopyingNetwork : {MBX-1,,A timeout occurred while communicating with server 'MBX-1'. Error: "A connection
                            could not be completed within 15 seconds."}
OutgoingConnections       :

 

The network failure detection mechanism is the same in both Exchange 2010 and Exchange 2013, as well as the same in Windows 2008 R2, Windows 2012, and Windows 2012 R2 failover clusters.  In order for the Replication service to detect a failure of a Replication network, the operating system and Cluster service must report the underlying interface as failed.  If the Cluster service reports any other status for the interface, the Replication service will consider the network to be valid and replication will not failover to another network.