Monitor Exchange database activation preference

In this blog post, I will be talking about one of my favorite tool when it comes to managing, maintaining the health of your Exchange deployments and to better monitor Exchange database activation preference. Most monitoring tools and scripts will give you an alert when something bad happen in your Exchange environment, like database not mounted, disk failures and more.

Exchange has built in high availability features like Database Availability Groups or DAG, in which multiple database copies exit to prevent single failures. If a database copy is down, database will get mounted automatically on another mailbox server. This can be intentional like when you want to reboot a mailbox server, and activate all mounted copies on that server to other mailbox servers.

The Exchange product group made a great work on providing the tools and Exchange calculator to help administrators know how to plan the distribution of database copies across mailbox servers in the DAG. Tools are so complicated and smart so that when they anticipate a failure on a server, copies are distributed equally between other mailbox server. Activation preference is what makes all this working as expected, and Exchange administrators shall spend time planning their database copy activation preference.

To monitor Exchange environment effectively, Exchange administrators shall not only monitor for disruptive facts, like database mount state and disk failure, but instead they should keep an eye on their database copy activation state. To better monitor Exchange, you should get an alert when a database is not mounted on the optimal mailbox server according to the activation preference settings in place.

Interesting fact

Suppose a database has an activation preference on Mailbox server SRV1 = 1, and another copy on mailbox server SRV2 with activation preference =2.

Normally, your database will be mounted on SRV1 and everyone is happy. Now, let us assume that the database copy on SRV1 fails, and the database gets automatically mounted on SRV2. Maybe it failed on SRV1 because the server restarted suddenly. But when SRV1 is back, guess what? the database will not go back to SRV1.

Well, we all love that it  automatically get mounted on SRV2 at least, but I guess we expect that when SRV1 gets up, that the database will return to SRV1. But Microsoft has a point here. Microsoft point of view is that SRV1 may come up but still experiencing problems. So if Microsoft configures our expected behavior (that the database shall mount back to SRV1), then the database will try to mount back, fail and then tries to mount again to SRV12, and then it will detect that SRV1 is up, and will try to get mounted there again…. A loop will happen simply. Got it ?!

Solution? I guess the best solution here is to schedule a script that will run every one hour for example, and it will scan your DAG databases, and alert you via email if a database is not mounted on the mailbox server with Activation Preference =1. This way, you can manually investigate the issue, maybe check event logs, and manually decide to take action (mount the database back to the server with activation preference =1 )

Script details

As stated before, to monitor Exchange database activation preference, it is recommended to run the script in a schedule. The Exchange monitor script is meant to be run on a schedule to alert you via email when something needs alert. The script is designed for this purpose and will only send email if something bad happens.

But if you want to download the Exchange monitor script and run it quickly to evaluate it, then open your Exchange PowerShell console using an account with Exchange View Only Admin, and run it without any switches.

If all is fine, you will get notified that no actions are detected and no email to be sent.

Monitor Exchange 2

To monitor Exchange database activation, the script will query all DAG databases in your environment using

Get-MailboxDatabase -STATUS | where {$_.MasterType -like "*DatabaseAvailabilityGroup*"}

Then the script will evaluate if there are any database not mounted on the Exchange mailbox server with activation preference = 1. If such database is found, an mail alert is sent. Else, nothing will happen. This is useful if you want to schedule the script so you will receive email only if something is not right.

Bonus

To better help you monitor Exchange databases, the script also has a variable called ($AlertonFailure) that is set to false by default. If you open the script and manually set this variable to true, then the script will perform another test. It will search all DAG databases (only DAG database) and will send alert also if any of those databases are not mounted.