Monitoring Benefit
The Database Redundancy check reports how much protection each database still has — whether every database retains the number of healthy copies it is supposed to have.
This is the check that answers "if I lose another server right now, what happens?" A DAG can be entirely operational, with every database mounted and every user working, while sitting one failure away from an outage. Redundancy is what makes that visible before it costs you something.
How do we verify the monitoring test results?
1. Run Exchange's own redundancy check. From the Exchange Management Shell on one of the mailbox servers:
cd $exscripts
.\CheckDatabaseRedundancy.ps1The output will align with what the monitoring page presents.
2. Identify which copies are missing or unhealthy. Redundancy falls because a copy is failed, suspended, or lagging badly enough not to count as protection. Get-MailboxDatabaseCopyStatus shows the state of each copy and its queue lengths.
3. Check whether it is falling or recovering. A copy that is reseeding will show reduced redundancy and resolve itself. A copy that is failed will not. The distinction determines whether you need to act.
Common warning or error results, and potential solutions
| Result | Potential solution |
| Redundancy reduced for one database | Find the copy that is not healthy with Get-MailboxDatabaseCopyStatus. A failed copy usually needs reseeding; a suspended one may simply need resuming. |
| Redundancy reduced across many databases at once | Points at a whole server or its storage rather than at individual databases. Check whether one DAG member is down, unreachable, or has a disk problem. |
| Redundancy drops during a reseed | Expected while the copy catches up. Confirm the seed is progressing rather than stalled before treating it as a fault. |
| Redundancy reduced but everything looks mounted | That is exactly the condition this check exists for. Users are unaffected today; you have lost the protection that covers the next failure. Treat it as urgent even though nothing is broken yet. |
| 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/DAGDatabaseRedundancy.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.
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.