Why AD Replication Still Failed with 8524 When the Hostname Resolved

After power returned on August 14, 2026, both PVE domain controllers started, hostnames resolved, and some IPv4/IPv6 probes passed. Yet DC1’s latest attempt to pull Schema from DC2 showed error 8524.

Requesting DNS registration on DC2, restarting Netlogon, correcting remote command wrapping, and retrying the specific replication relationship restored it. When reviewing the record on September 15, the key correction was that recovery does not prove which original DNS record was missing.

Identify destination, source, and naming context

The error text is:

The DSA operation is unable to proceed because of a DNS lookup failure.

The failed relationship was:

DC1 (destination, initiates pull) ← Schema data ← DC2 (source)

Domain, Configuration, Schema, DomainDnsZones, and ForestDnsZones have separate replication state. Schema is an independent naming context despite its DN beneath Configuration. No schema edits or adprep operation occurred.

Time, August 14	Recorded observation
16:50:17	Last successful Schema pull from DC2 to DC1
19:12:21	Latest attempt in that direction failed, 8524
19:12:27	Reverse-direction Schema replication succeeded
19:13:53–19:17:46	Other four NCs succeeded in the affected direction
19:22:25	/syncall DC1 /AdeP finished without error; 8524 remained
After registration/Netlogon restart	Summary still 1 / 5
After targeted retry, 19:24:11	Source and destination summaries both 0 / 5

Largest delta means the maximum interval since successful replication, not outage duration. A reverse-direction or different-NC success cannot validate the failed relationship.

A host record is only half the lookup chain

Replication identifies the source DC through its current NTDS Settings DSA object GUID:

<DSA-GUID>._msdcs.<forest-root>  CNAME
                       ↓
                 Current source FQDN
                       ↓
                    A / AAAA
                       ↓
                  RPC and replication

Distinguish this from LDAP locator SRV records and SRV names containing a domain object GUID. Substituting a DSA GUID into the domain-GUID template does not test the replication CNAME.

Source availability, stale metadata, resolver configuration, registration failure, and inconsistent DNS replicas are all candidates. Error 8524 is not exclusively a boot-registration failure.Microsoft 8524 guidance

Begin with read-only evidence

These are reviewed examples, not commands executed during writing. Replace domain names, documentation addresses, and GUIDs:

Get-Date
Get-Service NTDS,DNS,Netlogon
Get-DnsClientServerAddress
repadmin /replsummary
repadmin /showrepl DC1 /verbose
repadmin /showrepl DC2 /verbose

Take the current DC2 DSA object GUID, not its invocationID, computer GUID, or VM UUID. On destination DC1, query each AD DNS server and the default path:

$ForestRoot = 'corp.example.com'
$SourceFqdn = 'DC2.corp.example.com'
$SourceDsaGuid = [guid]::Parse((Read-Host 'Current DC2 DSA object GUID'))
$GuidName = "$($SourceDsaGuid.ToString())._msdcs.$ForestRoot"

foreach ($Dns in '192.0.2.11','192.0.2.12') {
    Resolve-DnsName $GuidName -Type CNAME -Server $Dns -DnsOnly
    Resolve-DnsName $SourceFqdn -Type A -Server $Dns -DnsOnly
    Resolve-DnsName $SourceFqdn -Type AAAA -Server $Dns -DnsOnly
}
Resolve-DnsName $GuidName -Type CNAME -DnsOnly

Follow the actual CNAME target. AAAA is optional where IPv6 is not deployed, but published addresses need individual verification. NXDOMAIN, no record of that type, timeout, and SERVFAIL differ; recording only the resolver address is insufficient.

Check Directory Service 2087/2088 plus Netlogon/DNS logs. TCP 53 and 135 do not verify UDP DNS and all dynamic RPC. Public resolvers should not casually become AD-client fallback DNS; negative responses do not guarantee retry against another server. Do not default to disabling IPv6 or firewalls.

A successful syncall can cover the wrong direction

The historical command was:

repadmin /syncall DC1 /AdeP

/A covers all NCs on that DC, /d prints DNs, /e extends across sites, and uppercase /P coordinates outward changes. The recorded callback covered DC1 → DC2, while the failure was DC2 → DC1.Repadmin syncall parameters

A targeted request specifies destination, source, and NC:

$SchemaNc = 'CN=Schema,CN=Configuration,DC=corp,DC=example,DC=com'
& repadmin.exe /replicate DC1 DC2 $SchemaNc
$LASTEXITCODE

Read the NC from actual showrepl or ADRootDSE. Do not add /force or /full by default. The historical success included force, but that does not establish necessity; protective replication restrictions need investigation.Repadmin replicate parameters

Registration and command transport are separate issues

After confirming the source is valid and the DNS path appropriate, refresh host and DC locator registration:

# On the source DC; review impact before changes
ipconfig /registerdns
nltest /dsregdns

This is the recommended entry point; history used registerdns followed by stopping/starting Netlogon. A restart affects service and should not become a casual startup workaround. Registration is asynchronous; verify records and events afterward.

The initial targeted retry also returned 8440, an invalid naming context. It crossed shell, SSH, PVE, QGA, and Windows wrapper layers. Switching to PowerShell wrapping succeeded, supporting an argument-transport problem without proving which layer changed the final arguments.

This DN had no spaces. Claims about truncation at its first space or inevitable quote loss in cmd would be invented. Validate locally, then use a reviewed .ps1 -File where appropriate. Preserve QGA stdout, stderr, and exit code: SSH success is not replication success.

Preserve the full identity of the replication failure

Record destination, source, source DSA GUID, naming context, success/failure times, error code, and the destination's actual DNS configuration. Domain, Configuration, Schema, DomainDnsZones, and ForestDnsZones are separate observations even for one host pair.

Use the source NTDS Settings DSA identity for its GUID CNAME, not a target computer GUID or arbitrary directory object GUID. A resolving host FQDN tests only the latter half of the lookup chain. Check retirement state before removing stale records; do not clear _msdcs wholesale.

Result	Next investigation
Missing GUID CNAME	Source NTDS identity, registration, zone replication
CNAME exists, host resolution fails	A/AAAA, zone, forwarding/cache
Resolution returns unreachable address	Each address and network path
Resolution works, one NC still fails	Actual destination failure and directed replication

These are diagnostic branches. Missing pre-repair CNAME evidence prevents declaring the first branch as this case's proven root cause. Recovery after Netlogon restart cannot reconstruct the original DNS state.

Accept the intended direction and partition

repadmin /replicate takes destination first, source second. After success, verify the specific source/destination/NC success timestamp advances. A zero exit code alone is insufficient. /syncall options affect scope/direction; the recorded /P push did not substitute for the failing pull path.

Remote maintenance adds local shell, transport, PowerShell parsing, and AD-operation layers. Preserve their errors and actual arguments separately; wrapper failure does not automatically mean registration failed. Confirm identity with read-only queries before mutation.

Observe natural replication afterward, checking both directions, the affected NC, and new events. Retain old error history rather than clearing it for a green report. Power-loss reproduction and original-cause evidence would be a separate experiment not completed by the successful directed retry.

What the evidence establishes

Registration and targeted retry were followed by successful Schema replication and failure-free summaries. There is no complete pre/post comparison of the correct CNAME. It cannot identify whether the original problem was CNAME, A, AAAA, timing, or caching.

Further acceptance should cover both directions, every NC, DNS, SYSVOL, real authentication, and subsequent automatic replication. Fixed startup delays are not readiness checks, and forced synchronization scripts are not disaster recovery.

Related: DC replacement acceptance and IPv6 DNS during DC promotion.

---

The article date is the main KB’s first Git commit date, 2026-09-15 (UTC+8), commit a13b11a. Experiment dates are stated separately. No production systems were accessed or changed while preparing this article.