Domain Controllers | AD Topology Warning — troubleshooting guide (Compass)

1. What the "AD Topology Event" checks

For each DC listed in the In-Site grid (for example DC1.mm-onprem.com), the AD Topology Event is effectively summarizing whether the core AD/DC building blocks are healthy:

• Network reachability to the DC (ICMP and ports)
• LDAP and Global Catalog connectivity
• Time service
• Critical AD and DNS services
• OS health and event status
• AD core (time, replication, LSASS, LDAP, partition backups)

A Warning state on the tile means one or more of those component tests are yellow/red for at least one DC.

When you see "AD Topology Event is in the warning state":

• Identify which DC is impacted in the In-Site list (look for 0 / low numbers under Reachability, Synchronized, Netlogon, etc.).

2. Step 1 – Check network connectivity to the DC

Purpose: Confirm the ENow Client can reach the DC and key ports.

From the ENow web server open the XML results file. At the bottom of the XML, validate:

• DNS ipaddr, pingtimemsecs, success for basic ICMP reachability.
• Port389, Port636, and BindTime for LDAP.
• GC Port3268, Port3269, BindTime for Global Catalog.

On the DC itself, open Agent2007.log and search for:

• DNS server
• LDAP
• GC bind

to see exact IP/port failures and errors.

If LDAP/GC port connectivity is suspected, from the ENow web server run PortQry:

portqry.exe -n DC1 -p udp -e 389     (LDAP)
portqry.exe -n DC1 -p tcp -e 3268    (GC)

Any result other than LISTENING is considered a failed test.

3. Step 2 – Validate time synchronization

Purpose: Rule out time skew, which will break Kerberos, LDAP, replication and thus overall topology.

• On the ENow web server, in the XML results, locate TimeService and Win32TimeSyncMode (may show HyperVHostTimeProvider or VMWareHostTimeProvider).
• On the DC, confirm the Windows Time service state with PowerShell:

Get-WmiObject -Class Win32_Service -Filter "Name='W32Time'"

Anything other than State = Running is a failed test.

If needed, review registry keys noted in AD Core – AD Time (SYSTEM\CurrentControlSet\Services\W32Time) to check Type and NtpServer.

4. Step 3 – Confirm AD and DNS-related services

Purpose: Ensure all critical topology-relevant services are running on the DC.

On the ENow web server, in the XML file, check the service states listed in the Services and AD Core sections (e.g. NTDS, ADWS, DFSR, DNS, Netlogon, Kdc, LanmanServer, LanmanWorkstation, EventLog, W32Time).

On the DC, run the following (one line at a time) for the affected DC:

Get-WmiObject Win32_Service -Filter "Name='NTDS'"      (AD DS)
Get-WmiObject Win32_Service -Filter "Name='ADWS'"      (AD Web Services)
Get-WmiObject Win32_Service -Filter "Name='DNS'"       (DNS Server)
Get-WmiObject Win32_Service -Filter "Name='Netlogon'"
Get-WmiObject Win32_Service -Filter "Name='Kdc'"

For each, State must be Running; any other state will drive yellow/red and surface as an AD Topology warning.

5. Step 4 – Check AD replication and SYSVOL

Purpose: Confirm directory partitions and SYSVOL are replicating, as broken replication changes the logical topology.

• On the ENow web server, in the XML, locate RepAdminInfo and ActiveDirectoryReplication under AD Core – AD Replication.
• On the DC, run repadmin /showrepl and look at each inbound neighbor for "Last attempt … was successful".
• If DFS/FRS monitoring is enabled, review the DFS replication XML files (DFSReplication.xml, DFSSYSVOLReplication.xml) and the SYSVOL probe file behavior.

Any persistent replication failures or SYSVOL lag should be treated as root cause candidates for AD Topology warnings.

6. Step 5 – Validate OS health (disk, CPU, memory, events)

Purpose: Ensure the DC is not resource-starved or logging critical errors that indirectly affect AD services.

On the ENow web server, in the XML, review the Operating System – Disk Space, Resources, and Events sections for the DC.

On the DC:

• Disk: Get-WmiObject -Class Win32_LogicalDisk to verify free space against thresholds configured in ENow.
• CPU: Get-WmiObject Win32_Processor | Select LoadPercentage and page file counters as documented under Operating System – Resources.
• Events: Check the daily event text files on the ENow web server and correlate with Agent.log on the DC.

7. Step 6 – Check AD LSASS and LDAP performance

Purpose: Catch expensive LDAP queries or LSASS CPU spikes that can degrade DC responsiveness.

On the ENow web server, in XML, look at ProcessInfo and AD LDAP performance indicators (searches/sec, client sessions, bind time).

On the DC:

LSASS CPU:

Get-Counter "\Process(lsass)\% Processor Time" -SampleInterval 2 -MaxSamples 4 | Select-Object Name, @{Name='CPUUsage';Expression={$_.CounterSamples[0].CookedValue}}

LDAP metrics:

Get-Counter -Counter "\DirectoryServices(*)\LDAP Searches/sec" -SampleInterval 2 -MaxSamples 4 | Select-Object @{Name='LdapSearchesPerSec';Expression={$_.CounterSamples[0].CookedValue}}

Get-Counter -Counter "\DirectoryServices(*)\LDAP Client Sessions" -SampleInterval 2 -MaxSamples 4 | Select-Object @{Name='LdapClientSessions';Expression={$_.CounterSamples[0].CookedValue}}

Get-Counter -Counter "\DirectoryServices(*)\LDAP Bind Time" -SampleInterval 2 -MaxSamples 4 | Select-Object @{Name='LdapBindTime';Expression={$_.CounterSamples[0].CookedValue}}

as per AD Core – AD LDAP.

If LDAP expensive queries are suspected, ensure diagnostic logging and "expensive search" thresholds are configured.

8. Quick decision table for an AD Topology warning