Summary: You may encounter the DatabaseCopyAutoActivationPolicy Blocked error in Exchange Server, when mounting the databases in a Database Availability Group setup. In this post, we’ve mentioned the solutions to fix this error. We’ve also mentioned an Exchange repair application that can help fix the issue if it has occurred due to corruption in the database.
In Exchange Server failover setups using the Database Availability Group (DAG), you would have two or more Exchange Servers synchronizing between each other. During the failover process, the databases will automatically mount on the secondary server.
The below diagram shows a typical Exchange Server setup with a Database Availability Group (DAG), consisting of two Exchange Servers and a file server to be used as a file share witness.
This is a typical scenario. But let?s say that the EX02 server, i.e. the secondary server, is at a remote site with a WAN connection, which is only used in case of a disaster and not normal maintenance jobs. This server is used in case the primary site is down and you only want the secondary server to have an offsite replication of the databases. In some cases, the business would require that the databases do not manually mount in case the primary site is not reachable or senses a failover. This could be due to an unstable connection or any other reason. Due to this, you would block the automatic database copy activation policy, which will refrain the databases from mounting in case there is a failover.
The process, when there is a failover of services, is to mount the databases manually through the Exchange Admin Center (EAC) or by using the PowerShell command Mount-MailboxDatabase in the Exchange Management Shell (EMS).
While mounting the databases, you may encounter an error, saying:
Server ‘server.local’ has database copy auto activation policy configuration of ?Blocked?
Solutions to Resolve the DatabaseCopyAutoActivationPolicy Blocked Error
You can follow the below solutions to resolve the error based on the scenario.
Scenario 1: Policy Applied on either the Whole Mailbox Server or on Specific Database
- If you run the command Test-ReplicationHealth, you will see that the Database Availability result is marked as *FAILED*. This means that something happened on the primary server and the databases need to be manually mounted. In such a case, you need to remove the policy accordingly.
- Next, you need to try to understand if the problem is on a specific database only or the entire server. If all the servers are affected, you need to use the Set-MailboxServer command in PowerShell as given below.
Set-MailboxServer -Identity <server name> -DatabaseCopyAutoActivationPolicy Unrestricted
- In case the policy is set manually on a specific database, you need to use the Set-MailboxDatabaseCopyStatus command as given below to remove the policy.
Resume-MailboxDatabaseCopy -Identity "<database name>\<database server>"
- If the policy is applied on both the entire server and on the databases, you will need to use both the above commands.
- Once this is complete, you should re-run the Test-ReplicationHealth command in PowerShell. It should now show that all the checks are marked as Passed, with no errors. In an ideal scenario, this would resolve the issue and the databases would replicate between the nodes without any issues.
Scenario 2: Corruption at Database or Transaction Log Level
If the problem of the blocking of the database auto-activation persists, the issue would be corruption at Exchange database or transaction log level. Corruption is one of the reasons why a database would not automatically activate. There could also be issues with your Exchange Server. If this happens, the database will not mount and you cannot activate the database if a failover occurs. Also, the users will not be able to access any emails or systems in that specific database or all the databases.
Instead of panicking in these situations, you can use applications, such as Stellar Repair for Exchange to recover from the issue, with no data loss and in the least possible time. With this Exchange database recovery software, you can open multiple EDB files from any version of the Exchange Server version without having a working Exchange Server. It can even open the EDB file if it is corrupted or has missing transaction logs. The application can be installed on Windows 8.1, 10, or 11, or on a Windows Server operating system.
After scanning the files, you will see all the structures of the database, mailboxes, and public folders. You can granularly export the recovered database to PST and other formats, such as EML, PDF, HTML, and MSG. In cases such as the above, you can create a new database in your Exchange Server and directly export to the live Exchange Server. You can also export the recovered database directly to an Office 365 tenant.
