Monitoring Benefit
The Forest Records test verifies that each DC or RODC can resolve the forest-scoped global catalog records from its configured network interface, against each DNS server that interface is configured to use.
The global catalog is how anything looks across domain boundaries. When these records cannot be resolved the catalog is still there, but nothing can find it — and the symptoms are distinctive: UPN logons fail while DOMAIN\user logons still work, Exchange address book lookups return nothing, and universal group membership stops being evaluated so people quietly lose access they should have.
What it checks
| Record | What depends on it |
|---|---|
| GCCSRV | The global catalog service locator — how clients find a GC to query |
| GCIP | The global catalog host record — resolving that GC to an address |
The results page shows Interface, Record, DNS Server and Status. You will see two rows per configured DNS server — the pair repeats for each one, so a DC with two DNS servers shows four rows.
This is the forest-scoped counterpart to Domain Records Status, which checks the domain's own service locator records. The distinction matters when you are triaging: domain records failing breaks logon to this domain; forest records failing breaks anything that crosses domains. Both can be red at once, and they have different causes.
A failure here is not always a fault
Not every domain controller is a global catalog. If this test is red on a DC that was never intended to hold the GC role, the records are correctly absent and the finding is a monitoring configuration question rather than an AD one. Establish whether the server is meant to be a global catalog before investigating DNS.
How do we verify the results?
The ENow agent runs a WMI query periodically to collect the DNS records. This information is not logged, but the results are cached on the monitored server:
\Program Files (x86)\ENow\Mailscape Agent\Cache\NetworkAgentMessage.xml
To reproduce the check by hand, run the following on the DC or RODC, substituting your own DNS zone:
Get-DnsServerResourceRecord -ZoneName "yourdomain.com"That returns the whole zone and the output can be very long. To test the global catalog records the way the monitoring does — against one named DNS server at a time — query them directly instead, using your forest root domain rather than the local domain:
Resolve-DnsName -Type SRV _ldap._tcp.gc._msdcs.forestroot.com -Server <dns server>
Resolve-DnsName -Type A gc._msdcs.forestroot.com -Server <dns server>Using the local domain instead of the forest root is the most common reason a manual check appears to contradict the monitoring. In a single-domain forest the two are the same; in a multi-domain forest they are not.
Run each against every DNS server the interface is configured with. A record that resolves from one server and not another is exactly what this test exists to catch.
Common warning or error results, and potential solutions
| Result | Potential solution |
|---|---|
| Red on a DC that is not a global catalog | Expected. Confirm the intended GC placement and exclude the check on servers that should not hold the role. |
| Both records fail against one DNS server only | That server's copy of the _msdcs zone. Check replication, and that the zone is AD-integrated and forest-wide in scope. |
| GCCSRV resolves but GCIP does not | The service is advertised but the host record is missing. Restarting Netlogon on the GC re-registers it. |
| Fails after a GC was demoted or moved | Stale records can persist, or the new GC may not have registered. Check which servers currently hold the role. |
| Forest records fail, domain records pass | Points specifically at the _msdcs forest zone rather than DNS generally. That zone replicates forest-wide and is a common casualty of partial replication. |
Users report UPN logons failing but DOMAIN\user works |
Classic global catalog symptom. Check this test before looking at authentication. |
Comments
0 comments
Article is closed for comments.