A lot of organizations that deploy multi-site database availability groups do so with the intention of using one site for normal production operations, and one for disaster recovery. This design usually leads to a desire to control where database copies can automatically activate, or failover to, when there is a problem with the active copy.
Consider a scenario in which four DAG members have been deployed, with two in the primary site and two in the disaster recovery site. I’ve illustrated a single database with four copies, but in reality there could be several more databases as well. Only one database is required to demonstrate this scenario though, so let’s keep it simple. By default, the database DB01 can failover to any of the available DAG members automatically, including the DR site.
If that is not desirable for the organization, then activation policies on the mailbox servers are commonly used to block automatic activation of the database copies in the DR site.
1 2 3 | [PS] C:\> Set–MailboxServer –Identity DR–EXCH01 –DatabaseCopyAutoActivationPolicy Blocked [PS] C:\> Set–MailboxServer –Identity DR–EXCH02 –DatabaseCopyAutoActivationPolicy Blocked |
This doesn’t prevent manual activation of course, so administrators can still make their own decision to “fail over to DR” when necessary.
The problem with the configuration above is that it greatly reduces the number of available database copies for automatic recovery of service in the event of a failure. If DB01 is active on PR-EXCH01 and needs to fail over, and PR-EXCH02 happens to be unhealthy for some reason or is down for planned maintenance, then there’s nowhere for the database to fail over to, and it will go offline instead. Furthermore, even if you do manually switchover to DR-EXCH02 for example, the database is still blocked from failing over to DR-EXCH02 if a second issue arises.
To combat that, some organizations set the DR site to use activation policies of IntrasiteOnly.
1 2 3 | [PS] C:\> Set–MailboxServer –Identity DR–EXCH01 –DatabaseCopyAutoActivationPolicy IntrasiteOnly [PS] C:\> Set–MailboxServer –Identity DR–EXCH02 –DatabaseCopyAutoActivationPolicy IntrasiteOnly |
That solves one of the two problems, but is still not ideal, in my opinion.
If you’re willing to accept database failing over to the DR site when necessary to maintain service availability, but you prefer the databases be active in the primary site, then you can leave the activation policies set to Unrestricted and set the DatabaseCopyActivationDisabledAndMoveNowproperty to $true instead. This allows databases to fail over, but they will automatically move back to a healthy database copy on a healthy server that has DatabaseCopyActivationDisabledAndMoveNow set to $false (and is also configured with an activation policy of Unrestricted) when one becomes available, usually within a few minutes.
1 2 3 | [PS] C:\>Set–MailboxServer DR–EXCH01 –DatabaseCopyActivationDisabledAndMoveNow $true –DatabaseCopyAutoActivationPolicy Unrestricted [PS] C:\>Set–MailboxServer DR–EXCH02 –DatabaseCopyActivationDisabledAndMoveNow $true –DatabaseCopyAutoActivationPolicy Unrestricted |
