250 Hello

Random Musings on Exchange and Virtualization

Exchange 2010 DAG AllowCrossSiteRPCClientAccess Reverts to False

Exchange 2010 DAG AllowCrossSiteRPCClientAccess Reverts to False

  • Comments 2
  • Likes

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.

Exchange 2010 DAG Starting Configuration - Exchange Build Is SP3

This is the DAG we shall look at:

 

Exchange 2010 3 Node DAG Starting Configuration

 

Initially DAG-01 does not have AllowCrossSiteRPCClientAccess set to $True

 

Exchange 2010 DAG - AllowCrossSiteRPCClientAccess Is Not Enabled

 

Then we set the AllowCrossSiteRPCClientAccess value to $True, and then verify

Exchange 2010 DAG - AllowCrossSiteRPCClientAccess Enabled & Verified

 

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

 

Exchange 2010 DAG - AllowCrossSiteRPCClientAccess Has Changed From Enabled to Disabled

 

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.

Exchange 2010 DAG - AllowCrossSiteRPCClientAccess  Has Changed From Enabled to Disabled

 

 

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.

Exchange 2010 - SP3 RU1 AllowCrossSiteRPCClientAccess  Preserved When Running Set-DatabaseAvailabilityGroup

 

 

Cheers,

Rhoderick

Technorati Tags: ,

 

Can You Help Us?  -- Yes !

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!

US

Canada

For all other areas please use the US contact point.





Comments
  • 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.

  • Hi Charles,

    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!  

    Cheers,

    Rhoderick

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
Post Comment Fixer