Monitoring Benefit
The Network Health check reports the state of the networks a Database Availability Group uses — both the replication networks that carry log shipping and seeding between members, and the client-facing network.
DAG networks are easy to get wrong in a way that stays invisible until you need them. A replication network that has quietly stopped being used means log shipping is running over the client network instead, which works right up until the day it does not.
How do we verify the monitoring test results?
1. List the DAG networks and their state. From the Exchange Management Shell:
Get-DatabaseAvailabilityGroupNetworkThis returns each configured network, the subnets assigned to it, whether replication is enabled on it, and the state of each member's interface on that network.
2. Confirm the networks are the ones you intended. Check that replication is enabled on the networks you built for it, and disabled on the ones you did not — and that each network's subnets still match reality. Subnet changes made by the network team are a common cause of a DAG network going misconfigured without anyone touching Exchange.
3. Check the interfaces on every member. A network can be healthy overall while one member's interface on it is down. The output shows per-member state, which is where the fault usually is.
Common warning or error results, and potential solutions
| Result | Potential solution |
| One member's interface is down on a DAG network | A server-level network problem: the adapter, its configuration, or the switch port. Check the server before looking at the DAG. |
| A replication network shows as misconfigured | Usually the subnets no longer match what is actually on the servers. Compare the subnets assigned to the DAG network against the addresses configured on the interfaces. |
| Replication is running over the client network | Either the replication network is unavailable and Exchange has failed over to the client network, or replication was never enabled on it. Both are worth correcting — seeding a large database over the client network is disruptive. |
| Network health degrades after an infrastructure change | Correlate against network team changes. VLAN, subnet and routing changes affect DAG networks without any Exchange configuration being touched. |
| 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/DAGNetworkHealth.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.