AD domain controller inventory: reconcile FSMO metadata

What an AD domain controller inventory establishes

An AD domain controller inventory should identify the DCs in scope and explain where each entry came from. Names, operating systems, sites, read-only flags, FSMO roles and configured replication partners help an operator understand the directory. They do not, by themselves, prove that a DC is reachable, that every expected DC was collected or that directory changes are replicating successfully.

The practical review is to reconcile the collector snapshot with independent directory reads, retaining the domain, queried server, naming contexts and collection errors. A blank FSMO list must remain distinguishable from a successful read showing that the particular DC holds no role. Likewise, a configured partner is topology information, not a successful replication result.

This guide was checked against Microsoft Learn and the etc-collector source on October 4, 2026. The commands are documented read-only inspection examples or adaptations of documented syntax. They were not executed against a customer directory. The workflow below is a proposed evidence review, not a report of an observed incident.

How scope and optional metadata affect the result

Start with the collection record rather than the display alone. Identify the requested domain, LDAP endpoint, BaseDN, account context, collection time and exclusions. Preserve the actual naming contexts involved in the reads, including the configuration context used for enrichment. A domain label without the server and search context is insufficient to explain why two exports differ.

In the inspected collector, DCs are derived from collected computer objects after exclusions. The metadata provider enriches that supplied list. This means a partner that cannot be mapped back to the supplied DC list may be omitted from the resulting partner field. An empty array can therefore describe an incomplete mapping rather than an absence of connection objects.

The provider also constructs its configuration search base by prefixing CN=Configuration, to BaseDN. When reviewing a child-domain collection, check that constructed context against the actual forest configuration context used by your independent directory inspection. The possible scope mismatch is a static inference from code, not a reproduced failure in a customer forest. Preserve the context and search result before deciding whether it explains a missing field.

A useful review record associates each DC identifier with its source and an explicit read state. Suggested states are read successfully, not collected, read failed and not yet verified. These are workflow labels, not values emitted by the detector. Do not silently convert any of the latter states into an empty list or a false flag.

Detection: reconcile DCs and FSMO holders independently

1. Enumerate the intended domain

Use a management host with the ActiveDirectory PowerShell module and an account authorized to read the relevant directory data. Microsoft's Get-ADDomainController reference documents the Filter parameter set and -Server. The following adaptation requests DCs from an explicitly named directory server; replace the illustrative hostname with the verified server for your domain:

Get-ADDomainController -Filter * -Server "dc01.contoso.com"

Record the server you actually queried alongside the returned objects and errors. Compare identifiers and domain membership with the collector entries before examining enrichment differences. Retain objects missing from either export as discrepancies to investigate, including any known exclusion that explains a difference.

The reference distinguishes Filter or Identity retrieval from discovery. A discovery call finds a DC meeting its criteria; it is not an enumeration of all DCs. For a forest-wide review, maintain separate domain results. The Get-ADForest reference includes enumeration across the forest's Domains collection. Do not relabel a successful single-domain export as complete forest coverage.

2. Read per-DC roles, then cross-check domain and forest ownership

Microsoft's FSMO management page provides this exact inspection example for the current domain:

$domainControllers = Get-ADDomainController -Filter *
foreach ($dc in $domainControllers) {
    Write-Output "Name: $($dc.Name)"
    Write-Output "OperationMasterRoles:"
    foreach ($role in $dc.OperationMasterRoles) {
        Write-Output "- $role"
    }
}

Because that example uses the default connection context, record it explicitly. Prefer the preceding server-scoped enumeration when preparing a controlled comparison. Keep the complete returned DC objects as well as the role summary so a formatting choice cannot hide the source identity.

The Get-ADDomain documentation exposes PDCEmulator, RIDMaster and InfrastructureMaster. The Get-ADForest output exposes SchemaMaster and DomainNamingMaster. These read-only adaptations use their documented Identity and Server parameters:

Get-ADDomain -Identity "contoso.com" -Server "dc01.contoso.com"
Get-ADForest -Identity "contoso.com" -Server "dc01.contoso.com"

Substitute the intended domain and forest independently; they need not have the same DNS name. Save the full output, including the returned domain identity and forest membership. Compare each holder with the per-DC role properties and with the collector's metadata. A forest role holder outside a child-domain collection is a scope question, not evidence of a missing role.

3. Preserve disagreement and unread data

For each discrepancy, attach both outputs, their collection times, server identities and read outcomes. A successful independent read identifying another holder can explain why one DC has no role. A failed read cannot. If server-scoped reads disagree, preserve both rather than selecting whichever makes the inventory look complete.

Assign an owner to investigate the collection context and any directory inconsistency. The immediate evidence question is whether the missing value reflects scope, an exclusion, unread metadata or a verified directory state. That question should be answered before planning a change to AD.

Remediation: correct the evidence before changing the directory

1. Resolve collection gaps and repeat the comparison

Review the recorded endpoint, domain BaseDN, configuration context, exclusions and permissions with the directory owner. Correct a confirmed collection-context problem through the collector's supported configuration process. Keep the original snapshot, the reason for the correction and the new read results together.

Repeat the scoped DC enumeration and the domain/forest inspection commands above. Compare the same identifiers and role properties again. If metadata remains unread, leave that state visible and assign the unresolved investigation; filling the report field manually would destroy the distinction between a directory read and an operator assumption.

An acceptance record should state which domain was reconciled, which DCs remain unexplained, which role holders were independently read and which fields remain unknown. Treat an excluded DC as excluded, rather than reporting it as absent from the directory. Repeating a collection successfully is useful evidence, but does not expand its scope beyond the domains and contexts actually queried.

2. Check replication as a distinct control

Microsoft's replication troubleshooting guide documents this exact command from an elevated Command Prompt:

repadmin /showrepl * /csv > showrepl.csv

The documented procedure requires Enterprise Admins membership or equivalent. Follow the organization's authorized diagnostic process. Preserve the CSV and command errors. Review source partners, naming contexts, last-success information and failures separately from the inventory's configuration partner list.

The same guide identifies the Directory Service event log and Repadmin output as troubleshooting evidence. Use the actual error text to investigate a failed diagnostic result. A connection listed in an inventory does not answer those health questions, and an unreachable diagnostic target remains unresolved even if other DCs returned output.

Record the replication check's scope and result in its own evidence record. Do not replace the configured-partner field with a health verdict or label all connections healthy because one query succeeded. This inventory article does not prescribe topology changes or recovery operations from a metadata gap.

3. Connect qualified inventory to topology and recovery planning

Use the verified site information alongside client DC selection and subnet-to-site mapping. That review reconciles directory topology with real client networks and discovery observations. An inventoried site name alone proves neither appropriate client selection nor replication health.

Provide the reconciled DC and role-holder record as an input to forest recovery planning and backup validation. Recovery preparation needs known DCs and roles, but also backup selection, restoration evidence and an environment-specific runbook. An inventory export does not validate a restore or establish that recovered directory state is trustworthy.

How EtcSec Detects This

EtcSec's etc-collector emits INFO_DOMAIN_CONTROLLER as an inventory finding. The inspected dc-inventory.go implementation produces one Info finding with Count 1 per collected DC. It returns no findings when the supplied DC list is empty. That behavior is not a vulnerability verdict and does not prove that a directory with no returned entries has no DCs.

Detailed affected entities are attached only with IncludeDetails. They contain the basic computer identity and OS fields, with optional FSMO roles, RODC status, site and replication partners. Missing enrichment leaves empty arrays or default values. Consumers must qualify those values before treating them as successful negative observations.

The LDAP provider's GetDCMetadata reads role-owner objects and NTDS/connection configuration. FSMO search errors or empty results are skipped. An NTDS search error leaves site and partner fields unfilled, while the RODC flag and any roles already read remain available; connection-search errors are ignored. Partner identifiers are mapped back to the supplied DC list. The engine also assigns DCInfo only when the metadata call succeeds.

These are limits observed in the source at commit afca1b9f7bba6f076d6a6493371486071001452b, not reproduced customer failures. The check performs no replication-health test, measures no successful exchange of changes and makes no recovery-readiness decision. Use it to expose collected DC assets, then qualify coverage and optional metadata with the independent reads described above.