As you may have already read in Ross Smith IV’s excellent article on the cross-site RPC client access changes associated with Exchange 2010 SP2 Update Rollup 3 (see here), the flexibility now exists to control whether cross-site RPC client access is allowed.
Prior to SP2 RU3, a mailbox database copy could be activated in any Active Directory (AD) site and there would be no impact to Outlook with regards to the RPC endpoint. In this scenario, Outlook would continue to connect to its existing RPC endpoint (the RPCClientAccessServer value for the mailbox database, either a CAS or CAS Array in the AD site that contained the mailbox database copy with an Activation Preference value of 1). If the original RPC endpoint became unavailable for any reason, Outlook connectivity would be severed. If a mailbox database copy was activated in a different AD site, Outlook would connect to a CAS (either directly or through a load balancer) in the original AD site and that CAS would connect directly to the Mailbox server in the AD site that now hosted the active mailbox database copy. Additionally, prior to SP2 RU3, a DNS change could be made to resolve a CAS Array namespace to a load balancer or a single CAS in an alternate AD site independently of activating a mailbox database copy in that AD site. This type of DNS change is an expected step in a normal data center activation process and, depending on the timing of DNS changes vs. mailbox database copy activations, DNS resolution to the alternate AD site might occur before a mailbox database copy activation. This type of DNS change might also occur as a result of a Global Server Load Balancing (GSLB) solution being in use or just normal troubleshooting/remediation of issues within an environment. Finally, prior to SP2 RU3, changing the AllowCrossSiteRPCClientAccess property of a Database Availability Group had absolutely no effect on an environment due to the fact that the code required to make it work was cut from the product. Regardless of whether this property was configured to $false or $true, the same result would occur – cross-site RPC client access was allowed as described above.
With SP2 RU3, as mentioned in Ross’ article, the AllowCrossSiteRPCClientAccess property now controls whether cross-site RPC client access is allowed. This property is configured to $false by default and, in this scenario, Outlook’s RPC endpoint will be updated to be the CAS Array namespace (or a single CAS) in the destination AD site when a mailbox database copy is activated in a different AD site. This is achieved via an ecWrongServer response from Exchange. The RPCClientAccessServer value on the mailbox database remains the same but, since Outlook’s RPC endpoint is updated, a “The Exchange administrator has made a change that requires you to quit and restart Outlook” prompt is issued to the end user and Outlook must be closed/restarted in order for the new RPC endpoint to take effect. To maintain the same functionality of allowing cross-site RPC client access as existed prior to SP2 RU3 or simply to avoid the Outlook prompt, AllowCrossSiteRPCClientAccess must be configured to $true via the following cmdlet syntax (note the colon that is required after the property):
Set-DatabaseAvailabilityGroup DAG_NAME -AllowCrossSiteRPCClientAccess: $true
Once AllowCrossSiteRPCClientAccess is configured to $true, activating a mailbox database copy in an alternate AD site will result in Outlook maintaining its existing RPC endpoint and, as a result, not cause the Outlook prompt to occur.
In the scenario described above about updating DNS for the CAS Array namespace independently of activating a mailbox database copy across AD sites, an additional step is required to make this work consistently with functionality prior to SP2 RU3. By default, with SP2 RU3, CAS will check to see if it is in the preferred AD site for the active mailbox database copy (i.e. the RPCClientAccessServer value for the mailbox database, either a CAS or CAS Array in the AD site that contained the mailbox database copy with an Activation Preference value of 1). If it is not, Exchange will issue an ecWrongServer response to redirect Outlook to the preferred location. This is actually how the new SP2 RU3 functionality of updating the Outlook RPC endpoint when a mailbox move occurs between AD sites is made possible. However, if this scenario occurs as the result of a DNS change independent of a mailbox database copy activation, access to the mailbox is prevented. Symptoms would be that Outlook in Cached Mode would be in a disconnected state and Outlook in Online Mode would present a Check Names dialog and then a “Cannot open your default e-mail folders” error.
To maintain the same functionality as existed prior to SP2 RU3 in this specific scenario, the following registry setting must be created on CAS. The change takes effect immediately and a restart of the Microsoft Exchange RPC Client Access service is not required.
This registry setting was discussed in Scott Schnoll’s “Exchange 2010 SP2 Tips & Tricks” slide deck from Microsoft NT konferenca 2012 (see here) as a way to disable the new SP2 RU3 functionality where the Outlook RPC endpoint is updated after a cross-site mailbox move. The reason this registry setting fixes the DNS change scenario is because the DNS change results in the same end state as a cross-site mailbox move: the Outlook RPC endpoint resolves to a CAS that is in a different AD site than the RPCClientAccessServer attribute value on the mailbox database that contains the mailbox. In the DNS change scenario, DNS resolution has forced that and, in the cross-site mailbox move scenario, the target mailbox database and associated RPCClientAccessServer attribute have changed due to mailbox move. The issue is that, in the DNS change scenario without the registry setting, CAS is expectedly issuing the ecWrongServer response to try and update Outlook’s RPC endpoint accordingly but is getting looped back to its own AD site again via DNS resolution.
Unfortunately, this means that one must choose between allowing the updating of DNS for the CAS Array namespace independently of activating a mailbox database copy across AD sites and having the new SP2 RU3 functionality properly update the Outlook RPC endpoint after a cross-site mailbox move. If your goal is to completely restore the same functionality that existed prior to SP2 RU3 with SP2 RU3 in place, you can do so with both AllowCrossSiteRPCClientAccess at $true *and* the above registry setting in place on all CAS.
Thanks to my client in Tampa, FL for helping to uncover the additional DNS change scenario!