For those familiar with the changes associated with Exchange 2010 Service Pack 2 Update Rollup 3 or if you read my previous blog post here, please continue reading with the paragraph below. For those unfamiliar with this Database Availability Group attribute, AllowCrossSiteRPCClientAccess was designed to allow an administrator to control whether RPC connectivity from an Outlook client to Exchange would be allowed to occur via a Client Access Server (CAS) in a different Active Directory site than the Mailbox server (MBX) on which the user’s mailbox database was activated (AllowCrossSiteRPCClientAccess set to $true) or whether an ecWrongServer response and MAPI profile update would occur to reconfigure the Outlook client to communicate with a CAS in the same site as the MBX on which the user’s mailbox database was activated (AllowCrossSiteRPCClientAccess set to $false). The AllowCrossSiteRPCClientAccess attribute is $false by default but, prior to Exchange 2010 SP2 RU3, the actual behavior was as if the attribute was $true — cross-site RPC client access was allowed, regardless of whether the attribute was configured as $true or $false. Exchange 2010 SP2 RU3 introduced a welcome change to allow an administrator to control this behavior via this attribute. The caveat was that, in order to maintain the same behavior as before Exchange 2010 SP2 RU3, the default attribute value had to be modified.
In Exchange 2013, direct RPC communication between Outlook and Exchange does not occur and, in fact, RPC communication between server roles does not occur. For more information on the architecture changes associated with Exchange 2013, please refer to the Exchange Team Blog post here. Instead, Outlook clients connect via Outlook Anywhere both internally and externally, controllable via separate hostname values exposed in Exchange 2013. As a result, it is not expected for there to be any client dependency on legacy client RPC connectivity settings, including AllowCrossSiteRPCClientAccess. However, despite the architecture changes, I recently came across a client environment where it was revealed that there is, in fact, a dependency on this attribute that may impact client behavior in an unexpected way.
When a mailbox database is created in Exchange 2010, the RPCClientAccessServer attribute on that database is either a random CAS within the same site as the MBX on which the database was created or, preferably, an RPC Client Access Array created in the same site as the MBX on which the database was created. The latter is a strong best practice and links client-based RPC client access with a namespace that should resolve to a load balancer to ensure high availability and resiliency for client access. When a mailbox database is created in Exchange 2013, the RPCClientAccessServer attribute is stamped with a value representing a single MBX. This value does not change when database copies activate across site boundaries.
With this background, consider a case where an environment has two sites, SiteA and SiteB, and Outlook Anywhere internal hostname values of sitea.internal.client.com and siteb.internal.client.com, respectively. SiteA contains SITEAMBX01 and SiteB contains SITEBMBX01. Given this topology, the expected behavior is that AutoDiscover will return an Outlook Anywhere internal hostname value of sitea.internal.client.com when a user’s mailbox database is activated on SITEAMBX01 and return siteb.internal.client.com when that database is activated on SITEBMBX01. In Exchange 2013, when AllowCrossSiteRPCClientAccess is left at the default value of $false, this is the actual behavior. However, if AllowCrossSiteRPCClientAccess is modified to be $true, this is not what occurs. Instead, the RPCClientAccessServer attribute on the mailbox database containing the user’s mailbox is compared against the site in which the database is activated and, if the database is activated in another site, the “preferred” site for client access remains the site in which the RPCClientAccessServer value exists. Thus, if AllowCrossSiteRPCClientAccess is $true, a mailbox database had an RPCClientAccessServer value of SITEBMBX01.internal.client.com, and the database was activated in SiteA, the preferred site for client access would be SiteB. As a result AutoDiscover will return an Outlook Anywhere internal hostname of siteb.internal.client.com and connecting Outlook clients will connect to SiteB for CAS, only to have CAS in SiteB communicate across site boundaries to the MBX on which the database was activated in SiteA.
To ensure that client access occurs via the expected Outlook Anywhere internal hostname value in Exchange 2013, you should ensure that the AllowCrossSiteRPCClientAccess attribute is left at the default value of $false. Microsoft’s documentation for Set-DatabaseAvailabilityGroup in Exchange 2013 here indicates that the attribute is now reserved for internal Microsoft use but does not indicate whether it is used or not. This fact has been raised internally within Microsoft.
Many thanks to my colleague in Austria for helping track this down!!