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:
-
Remediate incorrect cluster quorum types. Running Set-DatabaseAvailabilityGroup with no other parameters will set the correct quorum type based on the number of nodes in the underlying cluster.
-
Correct issues with File Share Witness (FSW) folders and permissions. For example if the FSW share is manually removed this will re-create it.
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…..
Quick Batman, to the Lab…..
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.
Conclusion
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.
Update 28-7-2013
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.
Cheers,
Rhoderick
