Tuesday, March 20, 2012

Changing the RPCClientAccessServer - How Outlook Behaves

When an Outlook client goes to connect to an Exchange 2010 database, it looks at an attribute associated with the mailbox database called RPCClientAccess to determine which client access server/client access server array to use for connectivity.

There may be a time in where you need to change which RPCClientAccess server your clients use for connectivity on the Exchange mailbox database. The problem is, if you change the RPCClientAccess on a mailbox database to a different Exchange 2010 client access server/client access server array without "moving" the mailbox, Outlook 2007 and Outlook 2010 clients do not pickup this change automatically.

Further more, if you perform an Outlook Profile repair process, it will update with the new RPC endpoint for the users mailbox database defined under the RPCClientAccess attribute. But guess what, Outlook reverts to a Working Offline mode. Creating a new outlook profile will resolve the issue, however if you remove the Host A record for the old client access server in DNS, Outlook will resume working as normal again.

Outlook only updates to a new RPCClientAccess value smoothly when moving users to the mailbox database. If you want to transition users smoothly to another client access server or client access server array, you can create another database, set the RPCClientAccess as desired, then move users to the database. This will allow the outlook profiles to update without issues.

Other then moving mailboxes there is one other thing you can do to get Outlook to update to the new RPCClientAccess value. If you remove the "Host A" record from the old client access server in DNS, this will cause Outlook to forcefully repair itself and update its profile.

Lets hope Microsoft makes it easier in the next release of Microsoft Outlook.

For additional reading about this problem, please look at the following links:

http://www.outlookforums.com/threads/84315-Outlook-goes-offline-after-changing-RPCClientAccessServer-parameter-on-mailbox-database

http://www.shudnow.net/2010/04/18/creating-databases-and-the-rpcclientaccessserver-database-parameter/

http://www.scottfeltmann.com/blog/2010/06/28/outlook-profile-not-updating-after-creating-cas-array/

http://technet.microsoft.com/en-us/magazine/ff626260.aspx

10 comments:

  1. Thanks for posting a great blog here..

    ReplyDelete
  2. Just FYI - If you create the CAS Array when you deploy your first Exchange 2010 CAS server, you won't have to deal with this issue. Unfortunately, I learned this the hard way (after the fact). Even if you don't think you will deploy more than one CAS server, I recommend setting up a CAS Array to make it easier to add or migrate to a new one in the future.

    ReplyDelete
  3. Great blog.

    Into a current Exchange 2010 SP2 environment with no CAS Array (I didn't build environment), I created the CAS Array and installed a net new MBX server. All the DB's on the new MBX server picked up the Array name but even when I moved mailboxes from old to new MBX server Outlook will not pick up the Array name for Type: Mail. It will for Type: Directory though. I get the same issue with fixing the Profile, Outlook then defaults to 'Working Offline' which is even worse IMO.

    What am I missing?


    ReplyDelete
  4. This issue described above has been addressed in Exchange 2010 SP2 UR3. Please read the following blog post by Ross Smith IV.

    http://blogs.technet.com/b/exchange/archive/2012/05/30/rpc-client-access-cross-site-connectivity-changes.aspx

    Regards,
    Clint

    ReplyDelete
  5. Well not entirely...

    SP2 UR3 resolves one issue when performing a DAG failover to another site, Outlook profiles automatically update to the new CAS Array in the remote site provided AllowCrossSiteRPCClientAccess is set to $false. However what happens if I provision a new CAS server in the same AD Site then manually update the RPCClientAccess attribute on the database? Exchange will not automatically send the ecWrongServer RPC call to the Outlook client forcing it to update its profile. Outlook clients will continue accessing the old RPCClientAccess endpoint and will ignore Autodiscover requests to talk to the new endpoint. Only newly created Outlook Profiles will use the new RPCClientAccess endpoint.

    In the event the old Client Access server is turned off, Outlook clients will revert to a disconnected state and repair themselves automatically upon the next Autodiscover attempt however this failover for end users is not a clean experience.

    ReplyDelete
  6. So with 'SP2 UR3' the easiest way to change RPCClientAccess on the outlook profiles is

    1. Activating(switchover) the databases on another site
    2. Changing RPCClientAccess attribute on the main site
    3. After that failback the databases.

    isn't it?

    ReplyDelete
  7. "There may be a time in where you need to change which RPCClientAccess server your clients use for connectivity on the Exchange mailbox database. The problem is, if you change the RPCClientAccess on a mailbox database to a different Exchange 2010 client access server/client access server array without "moving" the mailbox, Outlook 2007 and Outlook 2010 clients do not pickup this change automatically. "

    This may be true if CAS servers sit in the same site, I haven't tried this. I tested how Outlook 2010 behaves in case of a disaster in order to provide instructions for L1-2 guys with potential Outlook issues in Exchange 2010 SP2 environment with 2 sites, the main and the DR one. I only had to restart Outlook to pick up the new CAS in the DR site, I didn't have to repair the profile. When moving between MBX servers, whether using the main site CAS or the DR one, Outlook picked it up without my intervention in 10 seconds.

    I documented it here: http://sysadminops.blogspot.com.au/2012/03/virtualised-exchange-2010-sp2-configure.html

    Cheers

    Zoran

    ReplyDelete
  8. Get-MailboxDatabase | Set-MailboxDatabase -RpcClientAccessServer "new server exchange name fqdn"

    ReplyDelete
  9. This comment has been removed by the author.

    ReplyDelete
  10. Thanks Clint, the trick deleting the A Record saved me today.!

    ReplyDelete