Replication error 8524 The DSA operation is unable to proceed because of a DNS lookup failure
Updated: March 1, 2012
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2
This topic explains symptoms, causes and how to resolve Active Directory replication error 8524 The DSA operation is unable to proceed because of a DNS lookup failure.
Symptoms
Causes
Resolutions
Symptoms
DCDIAG reports that Active Directory Replications test has failed with status 8524:
Testing server: <sitename>\<destination DC> Starting test: Replications [Replications Check,<destination DC>] A recent replication attempt failed: From <source DC> to <destination dc> Naming Context: CN=<DN path for failing directory partition>,DC=Contoso,DC=Com The replication generated an error (8524):The DSA operation is unable to proceed because of a DNS lookup failure.REPADMIN reports that a replication attempt has failed with status 8524.
REPADMIN commands that commonly cite the 8524 status include but are not limited to:
REPADMIN /REPLSUM
REPADMIN /SHOWREPS
REPADMIN /SHOWREPL
Sample 8524 failures from REPADMIN /SHOWREPS is shown below:
Default-First-Site-Name\CONTOSO-DC1 DSA Options: IS_GC Site Options: (none) DSA object GUID: e15fc9a1-82f8-4a99-97f2-8e715f06e747 DSA invocationID: e15fc9a1-82f8-4a99-97f2-8e715f06e747 ==== INBOUND NEIGHBORS ====================================== DC=contoso,DC=com Default-First-Site-Name\CONTOSO-DC2 via RPC DSA object GUID: 8a7baee5-cd81-4c8c-9c0f-b10030574016 Last attempt @ YYYY-MM-DD HH:MM:SS failed, result 8524 (0x214c): The DSA operation is unable to proceed because of a DNS lookup failure. 1 consecutive failure(s). Last success @ YYYY-MM-DD HH:MM:SS. <Remainder of /showrepl output truncated>NTDS KCC, NTDS General or Microsoft-Windows-ActiveDirectory_DomainService events with the 8524 status are logged in the directory service event log.
Active Directory events that commonly cite the 8524 status include but are not limited to:
Event Source Event String 2023
Microsoft-Windows-ActiveDirectory_DomainService
This directory server was unable to replicate changes to the following remote directory server for the following directory partition.
1655
NTDS General
Active Directory attempted to communicate with the following global catalog and the attempts were unsuccessful.
1308
NTDS KCC
The Knowledge Consistency Checker (KCC) has detected that successive attempts to replicate with the following directory service has consistently failed.
1865
NTDS KCC
The Knowledge Consistency Checker (KCC) was unable to form a complete spanning tree network topology. As a result, the following list of sites cannot be reached from the local site.
1925
NTDS KCC
The attempt to establish a replication link for the following writable directory partition failed.
1926
NTDS KCC
The attempt to establish a replication link to a read-only directory partition with the following parameters failed.
Domain controllers log NTDS Replication event 2087 and/or NTDS Replication event 2088 in their Directory Service event log.
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: <date> <time>
Event ID: 2087
Task Category: DS RPC Client
Level: Error
Keywords: Classic
User: ANONYMOUS LOGON
Computer: <dc name>.<domain name>
Description:
Active Directory Domain Services could not resolve the following DNS host name of the source domain controller to an IP address. This error prevents additions, deletions and changes in Active Directory Domain Services from replicating between one or more domain controllers in the forest. Security groups, group policy, users and computers and their passwords will be inconsistent between domain controllers until this error is resolved, potentially affecting logon authentication and access to network resources.
<Remainder of event truncated, see MSKB 824449 for full text>
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: <date> <time>
Event ID: 2088
Task Category: DS RPC Client
Level: Warning
Keywords: Classic
User: ANONYMOUS LOGON
Computer: <dc name>.<domain name>
Description:
Active Directory Domain Services could not use DNS to resolve the IP address of the source domain controller listed below. To maintain the consistency of Security groups, group policy, users and computers and their passwords, Active Directory Domain Services successfully replicated using the NetBIOS or fully qualified computer name of the source domain controller.
Invalid DNS configuration may be affecting other essential operations on member computers, domain controllers or application servers in this Active Directory Domain Services forest, including logon authentication or access to network resources.
You should immediately resolve this DNS configuration error so that this domain controller can resolve the IP address of the source domain controller using DNS.
<Remainder of event truncated, see MSKB 824449 for full text>
Causes
Error Status 8524 maps to error string "The DSA operation is unable to proceed because of a DNS lookup failure." - a catch-all error for all possible DNS failures affecting Active Directory on post Windows Server 2003 SP1 domain controllers.
Microsoft-Windows-ActiveDirectory_DomainService event 2087 is a partner event to other Active Directory events that cite the 8524 status if an Active Directory domain controller is unable to resolve a remote DC by its fully qualified CNAME record (<object guid for source DCs NTDS Settings object>._msdcs.<forest root domain>) using DNS.
Microsoft-Windows-ActiveDirectory_DomainService event 2088 is logged when a source domain controller is successfully resolved by its NetBIOS name but such name resolution fallback only occurs when DNS name resolution fails.
The presence of the 8524 status and the Microsoft-Windows-ActiveDirectory_DomainService event 2088 or 2087 events all indicate that DNS name resolution is failing Active Directory.
In summary, the 8524 replication status is logged when a destination DC is unable to resolve the source DC by its CNAME and Host "A" or Host "AAAA" records using DNS. Specific root causes include:
The source DC is offline, or no longer exists but its NTDS Settings object still exist in the destination DCs copy of Active Directory.
The source DC failed to register the CNAME or host records on one or more DNS Servers either because the registration attempts failed or DNS client settings on the source do not point to DNS Servers that either host, forwarded or delegate its _msdcs.<forest root domain zone and / or primary DNS suffix domain zones.
DNS client settings on the destination DC do not point to DNS Servers that either host, forward or delegate the DNS zones containing the CNAME or host records for the source DC.
CNAME and host records registered by the source DC do not exist on DNS servers queried by the destination DC due to simple replication latency, a replication failure or a zone transfer failure.
Invalid forwarders or delegations are preventing the destination DC from resolving CNAME or Host records for DCs in other domains in the forest.
DNS Servers used by destination DC, source DC or intermediate DNS Servers are not functioning properly.
Resolutions
Verify whether the 8524 is caused by an offline DC or stale DC metadata.
If the 8524 error / event refers to a DC that is currently offline but still a valid DC in the forest, make it operational.
If the 8524 error / event refers to an inactive DC - a DC install that no longer exists on the network but whose NTDS Settings object still exists in the destination DCs copy of Active Directory - remove the stale metadata for that DC from the destination DCs copy of Active Directory.
Microsoft CSS regularly finds stale metadata for nonexistent DCs, or stale metadata from previous promotions of a DC with the same computer name that has not been removed from Active Directory.
Remove stale DC metadata if present.
GUI Metadata Cleanup using Active Directory Sites and Services (DSSITE.MSC)
Start the Windows 2008 or Windows Server 2008 R2 or W2K8 R2 Active Directory Sites and Services snap-in (DSSITE.MSC).
This can also be done by starting the Active Directory Sites and Services on a Windows Vista or Windows 7 computer that has been installed as part of the Remote Server Administration Tools (RSAT) package.
Focus the DSSITE.MSC snap-in on the destination DCs copy of Active Directory.
After starting DSSITE.MSC, right click on the Active Directory Sites and Services <DC Name>.
Select the destination DC that is logging the 8524 error / event from the list of DCs visible in the Change Domain Controller... list.
Delete the source DCs NTDS Settings object referenced in the 8524 errors and events. Active Directory Users and Computers (DSA.MSC) snap-in and delete either the source DCs NTDS Settings object.
A DCs NTDS Settings object appears below the Sites, Site Name, Servers container and %server name% container and above the inbound connection object displayed in in the right-hand pane of Active Directory Sites and Services.
Right click on the stale NTDS Settings object you want to remove then click Delete. Metadata cleanup can also be performed from the Windows Server 2008 or Windows Server 2008 R2 version of Active Directory Users and Computers snap-in as documented in Clean Up Server Metadata.
OR
Command line Metadata Cleanup using NTDSUTIL
- The legacy or command line method of deleting stale NTDS Settings objects using the NTDSUTIL metadata cleanup command is documented in MSKB 216498.
Run DCDIAG /TEST:DNS on the source DC + destination DC
DCDIAG /TEST:DNS performs 7 different tests to quickly vet the DNS health of a domain controller. This test is NOT run as part of the default execution of DCDIAG.
Log onto the console of the destination domain controllers logging the 8524 events with Enterprise Admin credentials.
Open an administrative privileged CMD prompt and run "DCDIAG /TEST:DNS /F on the DC logging the 8424 status AND the source DC that the destination DC is replicating from.
To run DCDIAG against all DCs in a forest, type "DCDIAG /TEST:DNS /V /E /F:<File name.txt>
To run DCDIAG TEST:DNS against a specific DC type "DCDIAG /TEST:DNS /V /S:<DC NAME> /F:<File name.txt>
Locate the summary table at the end of the DCDIAG /TEST:DNS output. Identify and reconcile warning or failure conditions on the relevant DCs of the report.
If DCDIAG does not identify the root cause, take "the long way around" using the steps below.
Check Active Directory Name Resolution using PING
Destination DCs resolve source DCs in DNS by their fully qualified CNAME records which are derived from the object GUID of the remote DCs NTDS Settings object (the parent object to connection objects visible in the Active Directory Sites and Services snap-in). You can test a given DCs ability to resolve a source DC fully qualified CNAME record using the PING command.
Locate the objectGUID of the source DCs NTDS Settings object in the source DCs copy of Active Directory.
From the console of the source DC logging the 8524 error / event, type:
c:\>repadmin /showreps <fully qualified hostname of source DC cited in the 8524 error / event >For example, if the DC referenced in the 8524 error/event is contoso-DC2 in the contoso.com domain type:
c:\>repadmin /showreps contoso-dc2.contoso.comThe "DSA Object GUID" field in the header of the /SHOWREPS command contains the objectGUID of the source DCs current NTDS settings object. Use the source DCs view of its NTDS Settings Object in case replication is slow or failing. The header of the repadmin output will look something like:
Default-First-Site-Name\CONTOSO-DC1 DSA Options: IS_GC Site Options: (none) DSA object GUID: 8a7baee5-cd81-4c8c-9c0f-b10030574016Right-click and copy the GUID and paste it into the PING command in step d of this list.
Locate the ObjectGUID of the source DC in the destination DCs copy of Active Directory.
From the console of the destination DC logging the 8524 error / event, type:
c:\>repadmin /showreps <fully qualified hostname of destination DC>>For example, if the DC logging 8524 error / event is contoso-DC1 in the contoso.com domain type:
c:\>repadmin /showreps contoso-dc1.contoso.comREPADMIN /SHOWREPS output is shown below. The "DSA Object GUID" field is listed for each source DC the destination DC inbound replicates from.
c:\>repadmin /showreps contoso-dc1.contoso.com Default-First-Site-Name\CONTOSO-DC1 DSA Options: IS_GC Site Options: (none) DSA object GUID: e15fc9a1-82f8-4a99-97f2-8e715f06e747 DSA invocationID: e15fc9a1-82f8-4a99-97f2-8e715f06e747 ==== INBOUND NEIGHBORS ====================================== DC=contoso,DC=com Default-First-Site-Name\CONTOSO-DC2 via RPC DSA object GUID: 8a7baee5-cd81-4c8c-9c0f-b10030574016 <- Object GUID for source DC derived from Last attempt @ 2010-03-24 15:45:15 failed, result 8524 (0x214c): \ destination DCs copy of Active Directory The DSA operation is unable to proceed because of a DNS lookup failure. 23 consecutive failure(s). Last success @ YYYY-MM-DD HH:MM:SS.Compare the object GUID from step a and step b.
If the object GUIDS are the same, then the source DC and destination DC know about the same instantiation (the same promotion) of the source DC. If they are different then figure who which one was created later. The NTDS setting object with the earlier create date is likely stale and should be removed.
PING the source DC by its fully qualified CNAME.
From the console of the destination DC, test Active Directory's name resolution with a PING of the source DCs fully qualified CNAME record:
c:\>ping <ObjectGUID from source DCs NTDS Settings object._msdcs.<DNS name for Active Directory forest root domain>Using our example of the 8a7baee5-cd81-4c8c-9c0f-b10030574016 objectGUID from the repadmin /showreps output above from the contoso-dc1 DC in the contoso.com domain, the PING syntax would be:
c:\>ping 8a7baee5-cd81-4c8c-9c0f-b10030574016._msdcs.contoso.comIf PING works, retry the failing operation in Active Directory. If PING fails, proceed to the "Resolve the 8524 DNS lookup failure" but retrying the PING test after each step until it resolves.
Resolve the 8524 DNS lookup failure: "The long way around"
If the 8524 error / events are not caused by stale DC metadata and the CNAME PING test fails, vet the DNS health of the source DC, the destination DC and the DNS Servers used by the source and destination DCs. In summary, verify that:
The source DC has registered the CNAME and host records with a valid DNS.
The destination DC points to valid DNS Servers.
That the records of interest registered by source DCs are resolvable by destination DCs.
The error message text in DS RPC Client event 2087 documents a user action for resolving the 8524 error. A more detailed action plan follows:
Verify that the source DC points to valid DNS Servers
On the source DC, verify that DNS Client settings point exclusively to operational DNS Severs that either host, forward or delegate the:
_msdcs.<forest root domain> zone (i.e. All DCs in the contoso.com forest register CNAME records in the _msdcs.contoso.com zone)
AND
The DNS zone for the Active Directory domain (i.e. a computer in the contoso.com domain would register host records in in contoso.com zone)
AND
The computers primary DNS suffix domain if different from the Active Directory domain name (see Disjoint Namespace).
Options to validate that a DNS Server hosts, forwards or delegates (i.e. "can resolve") such zones include:
- Start the DNS management tool for your DNS and verify that the DNS Servers that the source DC points to for name resolution host the zones in question.
OR
Use NSLOOKUP to verify that all of the DNS Servers that the source DC points to can resolve queries for the DNS zones in question.
Run IPCONFIG /ALL on the console of the source DC
c:\>ipconfig /all … DNS Servers . . . . . . . . . . . : 192.0.2.99 <- Primary DNS Server IP> 192.0.2.101<- Secondary DNS Server IP>Run the following NSLOOKUP queries:
c:\>nslookup -type=soa <Source DC DNS domain name> <source DCs primary DNS Server IP > c:\>nslookup -type=soa < Source DC DNS domain name > <source DCs secondary DNS Server IP > c:\>nslookup -type=soa <_msdcs.<forest root DNS domain> <source DCs primary DNS Server IP > c:\>nslookup -type=soa <_msdcs.<forest root DNS domain> <source DCs secondary DNS Server IP >For example, if a DC in the CHILD.CONTOSO.COM domain of the contoso.com forest is configured with the primary and secondary DNS Server IPs "192.0.2.99" and "192.0.2.101", the NSLOOKUP syntax would be
c:\>nslookup -type=soa child.contoso.com 192.0.2.99 c:\>nslookup -type=soa child.contoso.com 192.0.2.101 c:\>nslookup -type=soa _msdcs.contoso.com 192.0.2.99 c:\>nslookup -type=soa _msdcs.contoso.com 192.0.2.101
Note
2. Verify that the source DC has registered its CNAME record
Use step 1 from "Check Active Directory Name Resolution using PING" to locate the current CNAME of the source DC.
Run **ipconfig /all** on the console of the source DC to determine which DNS Servers the source DC points to name resolution.
c:\>ipconfig /all
…
DNS Servers . . . . . . . . . . . : 192.0.2.99 <- Primary DNS Server IP>
192.0.2.101<- Secondary DNS Server IP>
Use NSLOOKUP to query the current DNS Servers for the source DCs CNAME record (found by using the procedure in "Check Active Directory Name Resolution using PING").
c:\>nslookup -type=cname <fully qualified cname of source DC> <source DCs primary DNS Server IP >
c:\>nslookup -type=cname <fully qualified cname of source DC> <source DCs secondary DNS Server IP>
Continuing the example where the NTDS Settings objectGUID for contoso-dc2 in the contoso.com domain is 8a7baee5-cd81-4c8c-9c0f-b10030574016 and points to "192.0.2.99" as primary for DNS name resolution, the NSLOOKUP syntax would be:
c:\>nslookup -type=cname 8a7baee5-cd81-4c8c-9c0f-b10030574016._msdcs.contoso.com 192.0.2.99
c:\>nslookup -type=cname 8a7baee5-cd81-4c8c-9c0f-b10030574016._msdcs.contoso.com 192.0.2.101
If the source DC has not registered its CNAME record on the DNS Servers it points to for name resolution, run the following command from the command prompt of the source DC then recheck the registration of the CNAME record:
c:\>net stop netlogon & net start netlogon
Note
3. Verify that the source DC has registered its host records
From the console of the source DC, run **ipconfig /all** to determine which DNS Servers the source DC points to name resolution:
c:\>ipconfig /all
…
DNS Servers . . . . . . . . . . . : 192.0.2.99 <- Primary DNS Server IP>
192.0.2.101<- Secondary DNS Server IP>
Use NSLOOKUP to query the current DNS Servers for the host record:
c:\>nslookup -type=A+AAAA <fully qualified hostname of source DC> <source DCs primary DNS Server IP >
c:\>nslookup -type=A+AAAA <fully qualified hostname of source DC> <source DCs secondary DNS Server IP>
Continuing the example for the hostname for contoso-dc2 in the contoso.com domain is 8a7baee5-cd81-4c8c-9c0f-b10030574016 and points to self (127.0.0.1) as primary for DNS name resolution, the NSLOOKUP syntax would be:
c:\>nslookup -type=A+AAAA contoso-dc1.contoso.com 192.0.2.99
c:\>nslookup -type=A+AAAA contoso-dc1.contoso.com 192.0.2.101
Repeat the NSLOOKUP command against the source DCs secondary DNS Server IP address.
To dynamically register host "A" records, type the following from the console of the computer:
c:\>ipconfig /registerdns
Note
4. Verify that the destination DC points to valid DNS Servers
On the destination DC, verify that DNS Client settings point *exclusively* to operational DNS Severs that either host, forward or delegate the:
\_msdcs.\<forest root domain\> zone (i.e. All DCs in the contoso.com forest register CNAME records in the \_msdcs.contoso.com zone)
AND
The DNS zone for the Active Directory domain (i.e. a computer in the contoso.com domain would register host records in in contoso.com zone)
AND
The computers primary DNS suffix domain if different from the Active Directory domain name (see [Disjoint Namespace](cc731125\(v=ws.10\).md)).
Options to validate that a DNS Server hosts, forwards or delegates (i.e. "can resolve") such zones include:
1. Start the DNS management tool for your DNS and verify that the DNS Servers that the source DC points to for name resolution host the zones in question.
OR
1. Use NSLOOKUP to verify that all of the DNS Servers that the source DC points to can resolve queries for the DNS zones in question.
Run IPCONFIG /ALL on the console of the source DC
c:\>ipconfig /all
…
DNS Servers . . . . . . . . . . . : 192.0.2.99 <- Primary DNS Server IP>
192.0.2.101<- Secondary DNS Server IP>
Run the following NSLOOKUP queries:
c:\>nslookup -type=soa <Source DC DNS domain name> <source DCs primary DNS Server IP >
c:\>nslookup -type=soa < Source DC DNS domain name > <source DCs secondary DNS Server IP >
c:\>nslookup -type=soa <_msdcs.<forest root DNS domain> <source DCs primary DNS Server IP >
c:\>nslookup -type=soa <_msdcs.<forest root DNS domain> <source DCs secondary DNS Server IP >
For example, if a DC in the CHILD.CONTOSO.COM domain of the contoso.com forest is configured with the primary and secondary DNS Server IPs "192.0.2.99" and "192.0.2.101", the NSLOOKUP syntax would be
c:\>nslookup -type=soa child.contoso.com 192.0.2.99
c:\>nslookup -type=soa child.contoso.com 192.0.2.101
c:\>nslookup -type=soa _msdcs.contoso.com 192.0.2.99
c:\>nslookup -type=soa _msdcs.contoso.com 192.0.2.101
Note
5. Verify that the DNS Server used by the destination DC can resolve the source DCs CNAME and HOST records
From the console of the destination DC, run "ipconfig /all" to determine which DNS Servers that destination DC points to for name resolution:
c:\>ipconfig /all
…
DNS Servers . . . . . . . . . . . : 192.0.2.102 <- Primary DNS Server IP>
192.0.2.103<- Secondary DNS Server IP>
From the console of the destination DC, use NSLOOKUP to query the DNS Servers configured on the destination DC for the source DCs cname and host records:
c:\>nslookup -type=cname <fully qualified CNAME of source DC> <destination DCs primary DNS Server IP >
c:\>nslookup -type=cname <fully qualified CNAME of source DC> <destination DCs secondary DNS Server IP>
c:\>nslookup -type=host <fully qualified hostname of source DC> <destination DCs primary DNS Server IP >
c:\>nslookup -type=host <fully qualified hostname of source DC> <destination DCs secondary DNS Server IP>
Continuing the example where contoso-dc2 in the contoso.com domain with GUID 8a7baee5-cd81-4c8c-9c0f-b10030574016 in the Contoso.com forest root domain points to DNS Servers "192.0.2.102" and "192.0.2.103", the NSLOOKUP syntax would be:
c:\>nslookup -type=cname 8a7baee5-cd81-4c8c-9c0f-b10030574016._msdcs.contoso.com 192.0.2.102
c:\>nslookup -type=cname 8a7baee5-cd81-4c8c-9c0f-b10030574016._msdcs.contoso.com 192.0.2.103
c:\>nslookup -type=A+AAAA contoso-dc1.contoso.com 192.0.2.102
c:\>nslookup -type=A+AAAA contoso-dc1.contoso.com 192.0.2.102
6. Review the relationship between the DNS Servers used by the source and destination DCs
If the DNS Servers used by the source and destination host AD-integrated copies of the \_msdcs.\<forest root\> and \<primary DNS suffix\> zones, check for:
- Replication latency between the DNS where the record was registered and the DNS where the record is being queried.
- A replication failure between the DNS where the record is registered and the DNS being queried.
- The DNS zone hosting the record of interest resides in different replication scopes and therefore different contents, or is CNF / conflict-mangled on one or more DCs.
If the DNS zones used by the source and destination DC are stored in primary and secondary copies of DNS zones, check for:
- The **Allow zone transfers** checkbox is not enabled on the DNS that hosts the primary copy of the zone.
- The **Only the following servers** checkbox is enabled but the IP address of the secondary DNS has not been added to the allow list on the primary DNS.
- The DNS zone on the Windows Server 2008 DNS hosting the secondary copy of the zone is empty due to MSKB [953317](https://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b953317).
If the DNS servers used by the source and destination DC have parent / child relationships, check for:
- Invalid delegations on the DNS that owns the parent zone that is delegating to the subordinate zone.
- Invalid forwarder IP addresses on the DNS server trying to resolve the superior DNS zone (example: a DC in child.contoso.com trying to resolve host records in conto.com zone residing on DNS Servers in the root domain).