Welcome back. In the first part of the Client Behaviour During *over in Exchange Server 2010 article ( Client behaviour During *over in Exchange Server 2010 - Part 1 ), I mentioned about the new client connection type in Exchange Server 2010. Also mentioned about the client behavior in some *over scenarios. In this article I will continue to discuss the *over scenarios.
*over Scenario 3
In this scenario the active mailbox database is mounted on the DR site mailbox server. The primary site CAS servers are also down. The user fires up Outlook however Outlook cannot connect to the Exchange servers and throws the following error message:
The client is still trying to connect to the primary site Client Access Server array. Primary site mailbox database server mailbox has the lowest Activation Preference number hence the client is trying to connect to it. In this case a datacentre switchover is required. I am not going to discuss how to bring the DR site Exchange services online in another article. In a datacentre switchover scenario the primary site RPC Client Access Array service is required to be re-pointed to the standby Client Access Array in the secondary datacentre. This can be achieved by a simple DNS A Host record change. Autodiscover will still point the primary site servers hence existing Outlook clients do not need any configuration.
The TTL time of the CAS Array record in DNS and also DNS cache update time on the client is important. Set a recommend TTL value of 5 mins. In this test I run ipconfig /flushdns on the client which clears the DNS table cache, as you all know.
After the DNS cache gets updated; client fires up Outlook again and this time successfully gets connected. See below:
The RPCClientAccessServer setting has not been changed either.
* over Scenario 4
One very important thing to remember!! When the mailbox database gets activated in the DR site, the users will continue try connecting to the RPC Client Access Server array from the site where the lowest activation preference value resides.
I can hear you asking the question whether the RPCClientAccessServer value be changed or not? Yes it can be changed. To change the RPCClientAccessServer value of a mailbox database you either need to change the ActivationPreference number (the system will automatically update the value) or need to change it manually via EMS. See below:
And the RPCClientAccessServer value changes automatically:
However existing users will continue to use the old RPC endpoint server rather than the new enpoint server. Once again this is because the old RPC endpoint does not return the ecWrongServer response. If the old RPC endpoint becomes inaccessible the client will not be able to logon to Outlook.
*over Scenario 5
Microsoft has made significant change to this behaviour with Update Rollup 3 for Exchange Server 2010 SP2. For this scenario all Exchange Server in the infrastructure have been updated with Update Rollup 5-v2 for Exchange Server 2010 SP2.
The client is connected to the primary site RPC Client Access Server array.
When the mailbox database gets activated in the DR site the following box pops up.
The user restarts Outlook and as you can see the RPC endpoint service on the client automatically gets updated. See below:
So what has changed? With Update Rollup 3 for Exchange Server 2010 SP2 the RPC endpoint generates ecWrongServer message and the client receives it.
RPC Client Access log
2013-01-13T14:22:37.908Z,5,1,/o=CKTESTLAB/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=username,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00,”Logon: Owner, /o=CKTESTLAB/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=username in database HQMbx1 last mounted on VTLEXCH01.cktestlab.com at 13/01/2013 14:14:24, currently InTransitSameSite; Redirected: this server is not in a preferred site for the database, suggested new server: /o=CKTESTLAB/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=outlookHQ.cktestlab.com”,RopHandler: Logon:
Very Important point here. The above is the default behaviour when the DAG’s AllowCrossSiteRpcClientAccess value is set to false. Bear in mind this is the default value.
Get-DatabaseAvailabilityGroup
Hope this article helps you to have a better understanding of the client behaviour during the *over process.
Thank you.
ecsword
No comments:
Post a Comment