Exchange Server AutoActivationPolicy

The title of the article seems a bit confusing, but if you have a DR structure in your environment, you may want to prevent the automatic activation of the databases in the DAG. If the database copy is in a passive data center, you may want to prevent automatic activation. You may implement this scenario not because it cannot do the job, but because you probably want to know when the database will be transferred to a different data center and you want to do it yourself.

What is Exchange Server AutoActivationPolicy?

On Exchange Server AutoActivationPolicy The feature is a tuning option that controls the automatic activation of database copies within a given Database Availability Group (DAG). This feature plays an important role in the management of the DAG, especially in high availability and fault tolerance scenarios.

AutoActivationPolicy Determines whether DAG member servers can automatically make active the passive database copies they host. This policy is used to control which servers automatically bring databases online, especially during maintenance work or in the event of hardware failures.

Exchange Server AutoActivationPolicy Options

  • blocked: This setting prevents the server from automatically activating passive database copies. This is typically used during maintenance or to manage the load on the server.
  • IntrasiteOnly: This setting allows the server to enable passive replicas only within the same site. This is preferred when there is latency or high cost in offsite data center connections.
  • Unrestricted: This setting allows the server to enable passive database copies without any restrictions. This is the most flexible option and allows the server to meet high availability requirements.

Configuring Exchange Server AutoActivationPolicy

In fact, Exchange Server makes the DAG structure more performant with each version, and I think DAG is a perfect scenario for these environments.

You can think of your Exchange environment as having the following topology.

We have an environment where four DAG members are hosted, two in the primary site and two in the DR site. I will explain my example as a single database DB001. (To simplify the explanation a bit more) By default, database DB001 can automatically perform active database migration to any of the available DAG members, including the DR site. The automatic active database migration topology is visualized below.

In our topology, the servers located on the primary site were classified as “Unrestricted” throughout the scenario.

In your building, there is a DR (Disaster Recovery) site DAY If you do not want members to automatically failover or just DAY If you want “1” of its members to do this, you can change the failover configuration with the following command.

It will automatically block the active database.

If we need to give a brief definition of the Blocked component;

Disables automatic activation on Mailbox servers.

In Exchange 2013, this setting would stop server locator requests to the specified server and block all client access to manually activated databases on the server if all DAG members were configured with the value Blocked. In Exchange Server 2013 CU7 or later versions of Exchange Server, server locator requests are sent to a blocked server if no other Mailbox servers are available, so client access is not affected.

Set-MailboxServer –Identity DR-EXC01 -DatabaseCopyAutoActivationPolicy Blocked
Set-MailboxServer –Identity DR-EXC02 -DatabaseCopyAutoActivationPolicy Blocked

This is actually a typical scenario. However, the DR server is positioned to be used only in the event of a disaster. This server should be used in the event that the primary site is down and you only want to replicate the databases of the secondary server offsite. In some cases, the databases may not be manually connected if the primary site is down or failover is detected. This may be due to an unstable connection or other reason.

Therefore, you need to disable the automatic database copy activation policy, which prevents databases from being mounted in case of a failover.

In fact, there is a general problem with the configuration we made above, this problem occurs during Failover. Primary Site PR-EXC01 needs to fail over, but PR-EXC02 is offline due to a problem or planned maintenance, but since it cannot switch to the DAGs in the DR site, the DB will go offline. Even if you manually switch to DR-EXC01, the second problem experienced here will not be reflected in DR-EXC02, so the DB will still go offline.

Note: Unless the DR Scenario for Exchange Server is designed professionally, such problems can always occur.

To prevent such problems,IntrasiteOnly“ You can use the principle. We can make a short definition for this principle as follows;

Database copy is just the same Active Directory This configuration prevents cross-site failover or activation (for example, making a passive copy an active copy).

Databases, another Active Directory For database copies that are active on the site, this Mailbox cannot be activated on the server.

Set-MailboxServer –Identity DR-EXC01 -DatabaseCopyAutoActivationPolicy IntrasiteOnly

Set-MailboxServer –Identity DR-EXC02 -DatabaseCopyAutoActivationPolicy IntrasiteOnly

With this configuration, we can solve part of the problem I first described, because we only allowed Failover between sites, but in case of a disaster, we have to manually switch sites.

As well as disaster recovery, ensuring business continuity is also very important. You can use a database that is failover to the DR site to maintain the availability of the service used. We can select the database that will perform failover from the Primary Site and we can automatically make this database failover to the DR site.

If you want to accept the database failing over to the DR site when necessary to maintain service availability, but prefer to have the databases active at the primary site, you can use the activation policies Unrestricted You can leave it as and instead use DatabaseCopyActivationDisabledAndMoveNow feature $ true This allows databases to fail over. Once the Primary Site is available again, it will redirect all load to the Primary Site within a few minutes.

DatabaseCopyActivationDisabledAndMoveNow If we need to briefly describe its feature;

The DatabaseCopyActivationDisabledAndMoveNow parameter specifies whether databases should be blocked from connecting to this Mailbox server if there are other healthy copies of databases on other Mailbox servers. Also, if the copy exists and is healthy, it can move the connected databases on the server to the servers within a few minutes.

Valid input for this parameter is $true or $false. The default value is $false.

Setting this parameter to $true will not cause databases to be moved to a server that has the DatabaseCopyAutoActivationPolicy parameter set to Blocked.

Set-MailboxServer DR-EXC01 -DatabaseCopyActivationDisabledAndMoveNow $true -DatabaseCopyAutoActivationPolicy Unrestricted

Set-MailboxServer DR-EXC02 -DatabaseCopyActivationDisabledAndMoveNow $true -DatabaseCopyAutoActivationPolicy Unrestricted

Thus, after the servers on the Primary Site side are marked as healthy, the databases on the DR side will become passive within a few minutes and the databases will become active in the Primary Site.

Comment