Update 28-7-2013: This issue is now resolved in Exchange 2010 SP3 RU1. See end for details.
When browsing a customer’s Disaster Recovery document I noticed that the Exchange admins had added a step at the end of the document when recovering the DAG back to the primary datacentre. This was to enable AllowCrossSiteRPCClientAccess in the DAG. This was curious as it had already been enabled when the DAG was first created. This environment has Exchange 2010 SP2 RU3 and higher installed so AllowCrossSiteRPCClientAccess is a supported capability.
The admins were running:
Set-DatabaseAvailabilityGroup –Identity DAG -AllowCrossSiteRPCClientAccess:$True
This was being done as they had noticed in testing (full marks for testing !!) that the AllowCrossSiteRPCClientAccess setting was being changed from $True to $False. To ensure that the DAG was configured as per the design they were running the Set-DAG command to again reset the value for AllowCrossSiteRPCClientAccess.
This was a concern as we assumed that the setting should not be getting changed.
Sometimes we want to use Set-DatabaseAvailabilityGroup with no additional parameters to:
What happens if Set-DatabaseAvailabilityGroup is run to change another aspect of the DAG – would the AllowCrossSiteRPCClientAccess be changed in that scenario? Let’s see…..
So Robin, here we are in an Exchange 2010 SP3 lab. We have a simple 3 node DAG, called “DAG-01”. All Exchange servers have the same build running on Windows 2008 R2 SP1 Enterprise Edition.
This is the DAG we shall look at:
Initially DAG-01 does not have AllowCrossSiteRPCClientAccess set to $True
Then we set the AllowCrossSiteRPCClientAccess value to $True, and then verify
So far so good! But let’s now run the following command and see what happens to the AllowCrossSiteRPCClientAccess value:
Set-DatabaseAvailabilityGroup –Identity DAG-01
You can see that as a result of running the Set-DatabaseAvailabilityGroup cmdlet the value for AllowCrossSiteRPCClientAccess has changed from $True to $False.
The same behaviour was also noted when running other parameters in Set-DatabaseAvailabilityGroup and again without specifying the AllowCrossSiteRPCClientAccess parameter.
The behaviour that we saw was the AllowCrossSiteRPCClientAccess was reverting back to it’s default value ($False) unless it was explicitly specified in the command.
If you have set AllowCrossSiteRPCClientAccess to $True for a DAG in your environment, please ensure that when running Set-DatabaseAvailabilityGroup cmdlet you specify the AllowCrossSiteRPCClientAccess. You can also run Get-DatabaseAvailabilityGroup to validate the configuration on a scheduled basis.
BONUS TIP: Some of the Exchange cmdlets do not retrieve all of their data by default as they are costly operations. To instruct the cmdlet to retrieve this additional data add the –Status parameter. Set-DatabaseAvailabilityGroup is a good example of this! Try it and see the difference when piping to Format-List.
This issue is resolved in Exchange 2010 SP3 RU1. To illustrate, the example below shows a DAG with AllowCrossSiteRPCClientAccess set to $True. When Set-DAG this then run, note that the $True does not revert to $False.
If you would like to have Microsoft Premier Field Engineering (PFE) visit your company and assist with the topic(s) presented in this blog post, then please contact your Microsoft Premier Technical Account Manager (TAM) for more information on scheduling and our varied offerings!
If you are not currently benefiting from Microsoft Premier support and you’d like more information about Premier, please email the appropriate contact below, and tell them you how you got introduced!
For all other areas please use the US contact point.
Thanks for this one - Point noted.
Recently I did DR testing @my friends place 3 DAG node between sites but we didn't had(modified) the AllowCrossSiteRPCClientAccess option True.
Hopefully can be taken as preventive measure in further case.
I guess running Restore-DatabaseAvailabilityGroup might also change the value as it also sets the alternate FSW configuration.
I did not see that behaviour when I tested a DR and failback process in the lab I mentioned above. I was able to run Start-DAG, Stop-DAG, Restore-DAG and I checked the AllowCrossSiteRPCClientAccess at every stage.
Please do let me know if you see something different!