Overview
The Fail Over State monitoring test appears under Namespace DAG Status for Exchange servers in a Database Availability Group.
Monitoring Benefit
The Fail Over State test detects whether any server in the DAG, or any of the databases on that server, has failed over to a copy. It tells you that high availability has done its job — and, just as importantly, that you are now running somewhere other than where you expected to be.
This is the check that catches the failover nobody noticed. A DAG failing over is the system working correctly: users usually see a brief interruption at most, and often nothing at all. The risk is that the environment quietly stays that way. You are now running on a copy, redundancy is reduced, and the underlying fault that caused the failover has not been looked at.
This test reports a change of state, not a threshold. It fires when the failover state changes rather than when a measured value crosses a line, so there is no threshold to tune. The alert is "The DAG Failover state has changed", classified as critical or warning depending on the change.
How do we verify the monitoring test results?
1. Establish where the active copies are now. From an Exchange server, open the Exchange Management Shell and run:
cd $exscripts
.\RedistributeActiveDatabases.ps1 -DagName "<your DAG name>" -ShowDatabaseCurrentActivesThis shows which server is currently hosting each active database copy, which is the quickest way to see what has moved.
2. Check the health of the copies. Confirm the copy you are now running on is healthy and that its partners are keeping up:
Get-MailboxDatabaseCopyStatus3. Confirm redundancy is intact. A failover reduces the margin you have left, so check what remains:
cd $exscripts
.\CheckDatabaseRedundancy.ps14. Find out why it failed over. The failover is the symptom. Check the Application and System event logs on the server that lost the active copy, around the time of the state change — storage, network, or a service restart are the usual causes.
Common warning or error results, and potential solutions
| Result | Potential solution |
| The DAG Failover state has changed | Establish what moved and to where, using the current-actives script above. Then find the cause on the server that lost the copy — the failover itself is rarely the problem worth fixing. |
| Failover occurred during planned maintenance | Expected. A server put into maintenance mode moves its active copies deliberately. Confirm the timing matches the maintenance window. |
| Databases have not moved back after the cause was resolved | Exchange does not automatically return copies to their preferred server. Check the Active Preference indicator, and rebalance with RedistributeActiveDatabases.ps1 when you are ready. |
| Repeated failovers on the same server | The most serious pattern here. A server that repeatedly loses its active copies has an underlying fault — commonly storage latency, a flapping network interface, or a service that keeps restarting. |
| Failover followed by degraded copy health | Check Database Copy Health and the copy queue and replay queue lengths. A failover onto a copy that was already behind can leave replication struggling to catch up. |
| Looking for a threshold to tune | There isn't one. This test reports a state change, not a measured value. |
How this differs from Active Preference
The two are closely related and answer different questions:
- Fail Over State reports that a failover has happened — a server or its databases have moved to a copy.
- Active Preference reports whether the active copies are currently sitting where you intended them to sit.
Read together: Fail Over State tells you when something moved, Active Preference tells you it is still in the wrong place afterwards. A failover that is never rebalanced will clear from the first and persist in the second.
Related monitoring tests
- Database Copy Health Status — the health of individual database copies and their queue lengths.
- Active Preference — whether active copies are on their preferred servers.
- Database Redundancy — how much redundancy remains.
- Replication Health and Network Health.
Comments
0 comments
Please sign in to leave a comment.