Bize Ulaşın / Contact Us

Exchange Server Logo

Client Behaviour During *over in Exchange Server 2010 – Part 2

23 / 02 / 2014 by Exchange Server, Exchange Server 2010, Microsoft Yorum yok / No Comments

Hi,

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:

CBF5

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.

CBF6CBF7

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.

CBF8

After the DNS cache gets updated; client fires up Outlook again and this time successfully gets connected. See below:

CBF9

The RPCClientAccessServer setting has not been changed either.

CBF10

* 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.

 

CBF11

CBF12

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:

CBF13

And the RPCClientAccessServer value changes automatically:

CBF14

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.

CBF15

When the mailbox database gets activated in the DR site the following box pops up.

CBF16

The user restarts Outlook and as you can see the RPC endpoint service on the client automatically gets updated. See below:

CBF17

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

CBF18

Hope this article helps you to have a better understanding of the client behaviour during the *over process.

Thank you.

ecsword

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

*

Kontrol / Control * Time limit is exhausted. Please reload CAPTCHA.