Exchange 2010: Why does AllowCrossSiteRPCClientAccess revert to false?

  • Article

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.