How to Use Test-ReplicationHealth Cmdlet to Monitor Database Availability Groups?

  • Article

When you have a Database Availability Group (DAG), you would need to ensure that the replication between nodes is healthy. You can use the Test-ReplicationHealth command in the Exchange Management Shell (EMS) to test all the aspects of replication and replay.

This command would be executed against the current server. To execute the command on a different node, you need to update the command (see below).

Test-ReplicationHealth -Identity <Server name>

This will show all the tests which are applicable to the server being tested. Depending on the server – be it standalone or in a Database Availability Group (DAG), the checks will vary. To get a list of the checks being performed, along with their respective description, use the below command.

Test-ReplicationHealth | Format-list Check*

If all goes well, you are in the clear. But if one of the checks fails, it is important to address the situation immediately to prevent any undesired repercussions.

There are several things that could go wrong in the Database Availability Group (DAG) as the mail server is dependent on Exchange Server, Active Directory Schema, DNS, Cluster Service, and Network. If any of these is not functioning well or the replication test results in a failure, the replication could be in jeopardy. In such a case, you can do the following:

  1. The first thing to do is check that all Exchange Server services are running, including the cluster services.
  2. The other thing to do is to keep a log of any changes done to the servers and infrastructure. This would make it easier to investigate as you could trace back any changes that were made that might have affected the performance and replication of your Exchange Server databases. 
  3. You can also check installation of third-party applications and Windows/Exchange Server updates that might break the integrity of the replications.
  4. Also, consider that any changes should be done after a successful backup is complete and during a maintenance window, accompanied by a Change Management Request (CMR) to ensure that any changes are vetted and reviewed.

When issues arise, your databases are at risk and immediate action is required.

**What to do if any issue arises?
**
In case you end up with no solution to the issue where databases would not mount, you cannot rely on the backups. Backups help you restore the Exchange Server to a workable state but you would end up with data loss. Unfortunately, by using the native tools like EseUtil, you cannot get a guarantee that the database will mount or the replication will be restored. Using the EseUtil with hard recovery will cause data loss as it purges any data which is deemed corrupted. To extract the data and import it on a new healthy database, you need the database to be mounted. If the database is not mounted, you will not be able to move or export data.

You need to also consider the number of resources and administrative effort required to do the recovery. Apart from that, you need to consider the impact on the business as this would take some time, depending on the server’s performance and size of the databases.

Alternatively, you can use the best third-party application that can assist in the quick recovery of the data and reduce the time of recovery to the minimum.