Monitoring Benefit
The Database Copy Health check verifies that each mailbox database copy in the DAG is healthy — that the copy itself is in a good state, that its content index is usable, and that it is not falling behind on log replay.
It is the check that tells you a copy has quietly stopped being a viable failover target. A database can be mounted and serving users perfectly while one of its copies has been failed for a week. Nothing is wrong today; there is simply no longer anywhere to fail over to.
How do we verify the monitoring test results?
1. Get the copy status from the Exchange server. From the Exchange Management Shell:
Get-MailboxDatabaseCopyStatus -Server "<ServerName>" | Format-ListThis returns every copy hosted on that server with its status, its content index state, and both queue lengths. It is the single command behind everything on this page.
2. Read the values the check actually uses. Status drives the copy indicator, ContentIndexState is folded into it unless the database has been excluded in the Admin Console, and CopyQueueLength and ReplayQueueLength are each compared against their own configured thresholds.
3. Compare the queue lengths against your own thresholds. Both queue checks are threshold-driven, so a result outside normal means "above the number configured in this console", not "above a universal safe value". Confirm the thresholds in force before treating a result as unexpected.
For how each returned value maps to a dashboard indicator, and for the alerting rules, see the parent article linked at the end.
Common warning or error results, and potential solutions
| Result | Potential solution |
|---|---|
Content Index State is FailedAndSuspended
|
The search catalogue for that copy is unusable and must be rebuilt. The procedure differs depending on whether the server is a DAG member — both are given below. |
Content Index State begins with Crawling or Unknown
|
The index is rebuilding, or its state is not yet determined. This is expected after a reseed, after a database move, and after some updates. Give it time and re-check rather than intervening. |
Copy status is Failed or ServiceDown
|
Check that the Microsoft Exchange Replication service is running on the server hosting the copy, then look at the event log on that server. ServiceDown points at the service; Failed usually points at storage or the replication path. |
Copy status is Dismounted on the active copy |
The database is not serving users. This is an outage, not a redundancy warning — treat it ahead of anything else on this page. |
| Copy queue length is rising but replay queue is not | Logs are not reaching the passive copy. Look at the replication network between the two members rather than at the passive server's disk. |
| Replay queue length is rising but copy queue is not | Logs are arriving but not being played in. This is usually disk performance on the passive copy, or a reseed or backup in progress on it. |
| Both queues rise together after a failover | Expected while the DAG catches up. Re-check after the environment settles rather than raising it immediately. |
Status is Seeding or SeedingSource
|
A seed is in progress and the indicator is green by design. No action — but note that seeding a large database saturates whichever network it runs over. |
| 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. |
Rebuilding a failed content index
For Exchange servers that are DAG members, reseed the catalogue from another copy. This applies to a passive copy, and can be run from the Exchange Management Shell on any Exchange server — not only the affected one:
Update-MailboxDatabaseCopy -Identity "<DatabaseName>\<ExchangeServer>" -CatalogOnly -BeginSeed-CatalogOnly matters: it reseeds the search catalogue without reseeding the database itself. Leaving it off reseeds the whole database, which is a far larger operation than the problem calls for.
When the seed completes, check the copy status again and confirm the copy has resumed replication rather than remaining suspended.
For Exchange servers that are not DAG members, there is no second copy to seed from, so the index is deleted and allowed to rebuild locally. From the Exchange Management Shell on the affected server:
Stop-Service MSExchangeFastSearch
Stop-Service HostControllerServiceFind where the database files live:
Get-MailboxDatabase "<DatabaseName>" | select EdbFilePathThat path is the directory holding the live database file, so identify what you are deleting before you delete it. The content index is the folder in that directory whose name is a GUID — it may end in .single. The .edb file and the transaction logs are the database itself and must not be touched. With the search services stopped, the index folder is safe to delete and will be rebuilt; nothing else in that directory is.
Once the index folder is removed, start the search services again:
Start-Service HostControllerService
Start-Service MSExchangeFastSearchExpect the index to report Crawling for some time afterwards, and expect search on that database to be incomplete until it finishes. On a large mailbox database that is a period of hours, not minutes, so it is worth doing outside business hours where the database is active.
Monitoring page. The detail behind this indicator is served by the ENow web server at:
http://localhost:20080/MailscapeWeb/DAG/DAGDatabaseCopy.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 the indicator mappings, the alerting rules and an overview of how the DAG checks relate to each other.
Comments
0 comments
Please sign in to leave a comment.