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.