Exchange 2010 SP2 RU3 and later support the AllowCrossSiteRPCClientAccess capability, and our old Scottish-sounding but Canada-based friend* Rhoderick Milne ran across an interesting mention of it while reviewing disaster recovery operations with one of his customers:
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.
But why was the setting 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…..
I don’t want to spoil it for you, so I’ll let you read the conclusions yourself. (Hint: the guy dies at the end.)
Posted by Tristan Kington, MSPFE Editor, recovering from a bout of sausageitis.