Exchange Server - AD Topology Event

Overview

The AD Topology Event monitoring test appears in the Exchange Functionality section for Exchange servers.

Monitoring Benefit

Exchange 2013 and later reach Active Directory through the Microsoft Exchange Active Directory Topology service. The AD Topology Event test watches each Exchange server's own event log for the events that service raises, and reports when the server cannot reach its domain controllers.

It reads two events:

• MSExchange ADAccess event 2080 — logged when there is a problem during a service request to the Active Directory API. The event carries a table of the in-site and out-of-site domain controllers the server knows about, with a column per capability for each one.
• MSExchange ADTopology event 2142 — an error from the topology service itself.

This test exists because the alternative was worse. Running an Active Directory replication check against servers that are not domain controllers produced a steady stream of false positives — it depended on a local repadmin that is only present when RSAT is installed, so a perfectly healthy Exchange server could report replication failures purely because a tool was missing. Reading what Exchange itself logs about its own AD access is both more accurate and less fragile.

How the status is determined

Recovery does not always return the indicator to green. Where the server has only a single domain controller available, recovery moves it from critical to warning rather than clearing it — one reachable DC is better than none, but it is still a single point of failure for that server's AD access.

Event 2142 is used as the critical trigger rather than a 2080 with all-zero values, because a 2080 with every column zero for every domain controller does not occur in practice. Using 2142 also gives the alert time to fire properly, since DNS cache typically keeps things limping for around three minutes after AD access is genuinely lost.

Reading the 2080 table

Two columns in the event's table matter most:

• SACL right — the eighth column. A Boolean stating whether DSAccess has permission to read the SACL (part of nTSecurityDescriptor) against that directory service.
• Netlogon check — the tenth column. Whether AD Access successfully connected to that domain controller's Net Logon service. This uses RPC, so it can fail for reasons other than the server being down — a firewall blocking RPC will produce the same result. A value of 7 means the Net Logon check succeeded for each role: domain controller, configuration domain controller and global catalog.

Microsoft documents the full table layout under MSExchangeDSAccess Event ID 2080.

How do we verify the monitoring test results?

1. Read the event on the Exchange server. Open Event Viewer on the affected Exchange server and find the most recent MSExchange ADAccess 2080. The alert names the domain controllers whose SACL right is not 1; the event shows the full table those names came from.

2. Establish whether it is one domain controller or all of them. This is the branch that decides where to look next. A single DC failing is a problem with that DC or the path to it. Every DC failing points at the Exchange server, its network, or a policy affecting all of them.

3. Check the path from the Exchange server to the affected domain controller. LDAP is TCP/UDP 389, LDAPS 636, and the global catalog 3268 and 3269. From the Exchange server:

portqry.exe -n <domain controller> -p tcp -e 389
portqry.exe -n <domain controller> -p tcp -e 3268

Anything other than LISTENING is a failed test. Remember the Netlogon column depends on RPC, so a firewall rule can fail that check while LDAP itself is fine.

4. Check the domain controller's own health. Where a specific DC is implicated, the usual causes sit on that server: the Active Directory Domain Services, Net Logon, KDC or DNS Server services not running; time skew breaking Kerberos; AD replication failures; or the DC being resource-starved. The ENow Domain Controller monitoring for that server covers all of these, and is the faster route than checking by hand.

5. Confirm the SACL permission specifically. If connectivity is sound but the SACL right column is still 0, the issue is permissions rather than reachability — Exchange can talk to the domain controller but cannot read the security descriptor it needs.

Common warning or error results, and potential solutions

Related monitoring tests

• Exchange Server - Back Pressure and Exchange Server - Edge Synchronization — the other Exchange Functionality checks.
• The Domain Controller monitoring set — where an AD Topology Event points at a specific DC, that is where the root cause usually is.