Monitoring Benefit
The Replication Health check verifies the replication pipeline between members of a Database Availability Group — that log shipping, replay, cluster services and the underlying infrastructure the DAG depends on are all working.
It is a broad health check rather than a single measurement. A failure here tells you the DAG cannot reliably protect your databases, even when every database copy currently looks mounted and healthy.
How do we verify the monitoring test results?
1. Run the same check Exchange runs. From the Exchange Management Shell on the affected server:
Test-ReplicationHealth -Identity <ServerName>2. Find out which check failed. The summary output tells you that something failed but not always what it means. To list every check with its description:
Test-ReplicationHealth | Format-List Check*That gives you the name and purpose of each individual check, which is where the investigation actually starts.
3. Compare across DAG members. Run the same command against each member. A failure on one server points at that server; the same failure on all of them points at something shared — the cluster, the network the DAG replicates over, or Active Directory.
Common warning or error results, and potential solutions
| Result | Potential solution |
| One or more checks failed on a single server | Run Test-ReplicationHealth | Format-List Check* on that server to identify the failing check and its description, then work from there. Most individual checks map to a specific service or cluster component. |
| The same check failing on every DAG member | Look at what they share rather than at any one server: cluster service health, the replication network, DNS, or Active Directory replication. |
| Failures that appear and clear on their own | Often transient cluster or network events. Correlate the timing against the System and Application event logs on the DAG members before treating it as a persistent fault. |
| Healthy here, but database copies are unhealthy | Replication Health and database copy status are different measurements. Check the Database Copy Health status as well — a copy can be failed while the replication infrastructure itself is sound. |
| Results are stale rather than failing | If several unrelated checks stopped updating at the same moment, look at the ENow SQL database connection rather than at the DAG. |
Monitoring page. The detail behind this indicator is served by the ENow web server at:
http://localhost:20080/MailscapeWeb/DAG/DAGReplication.aspx?server=<SERVER>Replace localhost with the web server's host name if you are browsing from elsewhere, 20080 with your own port if it was changed at installation, and <SERVER> with the monitored server you are investigating.
Reference. Test-ReplicationHealth and Monitoring database availability groups.
See also. Exchange Server - Namespace DAG Status for an overview of all the DAG checks and how they relate.
Comments
0 comments
Article is closed for comments.