Client Behaviour During *over in Exchange Server 2010 - Part 1

Hi,

In this article I will mention the client behavior during *over process in Exchange Server 2010 world.

With  Exchange Server 2010 all mailbox related MAPI connectivity started going through the RPC Client Access service on the Client Access Server role. A new property (RPCClientAccessServer) been added to the Mailbox Database. If high availability is implemented this value should be the FQDN of the CAS the Array where Microsoft refers this as the RPC Client Access Server array.

In a *over scenario within the same site, under the assumption that CAS Array has been configured, the Outlook profile’s RPC endpoint will be the FQDN of the RPC Client Access Server array. When a mailbox database failure happens onto another mailbox server in the same site the Outlook profile continues pointing to the same RPC endpoint. So in this case there is NO change to the RPC endpoint service which is the expected scenario.

The second scenario is if the failure requires a switchover to another Datacentre meaning the primary datacentre is down, in this case you would need to Restore the services in the secondary datacentre also re-point the primary RPC Client Access Server array to the secondary site’s RPC Client Access Server array in DNS. With this configuration existing Outlook clients don’t need any reconfiguration for their RPC endpoint services.

The third scenario is if the failure happens onto a mailbox server in the DR site whilst the primary datacentre servers are online. RPC Client Access Server connectivity behaviour varies depending on the Exchange Server Service Pack and the Rollup package installed. The behaviour is different pre and after Update Rollup 3 for Exchange Server 2010 SP2.

The test infrastructure is depicted in the following picture.



*over Scenario 1 

All Exchange servers have been installed with Service Pack 2 only. No Rollup updates have been installed. In this scenario a *over happens onto another mailbox server within the same site. As stated previously; in this case no action is required (under the assumption that CAS Array has been configured) as the Outlook profile will continue to use the same RPC endpoint service which is the RPC Client Access Server array.



*over Scenario 2

In this scenario *over happens onto the mailbox server that is located in the DR site. All Exchange Servers have been patched with Service Pack 2.



As seen in the above figure the database HQMbx1 has been mounted on the DR site mailbox server (VTLExDRMBX01). When a user; who has the mailbox on this mailbox database, logs on to Outlook the connection is still established to the RPC Endpoint service of the primary site. See below figure:



I can hear the question WHY? The answer is simple. Even though the Autodiscover service detected the change the client still connects to the RPC endpoint service of the primary site because the RPC endpoint servers does not return ‘ecWrongServer’ message to the client. Bear in  mind that in this scenario the primary site RPC Client Access Array servers are still accessible.

RPC Client Access Log file

2013-01-13T00:04:46.900Z,8,1,/o=CKTESTLAB/ou=Exchange Administrative Group FYDIBOHF23SPDLT)/cn=Recipients/cn=username,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,0,00:00:00.5468715,”Logon: Owner, /o=CKTESTLAB/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=username in database HQMbx1 last mounted on VTLEXDRMBX01.cktestlab.com at 13/01/2013 00:02:04, currently Mounted; LogonId: 0″

In the next part of this article ( Client behaviour During *over in Exchange Server 2010 - Part 2 ) I will continue to discuss other possible *over scenarios.

 

ecsword