windowswideopen.com

Ø When the local DC tries to establish a replication link with it’s replication partner and it fails.

In that case, repadmin/showreps shows no inbound neighbors, so it doesn’t tell this error. To see it, go to the “Directory Service” event log in which the following event is logged:

Event ID 1265

The attempt to establish a replication link with parameters

Partition: DC=domain,DC=enterprise,DC=com

Source DSA DN: CN=NTDS Settings,CN=HubDC,CN=Servers,CN=DMZ- Administration,CN=Sites,CN=Configuration,DC=enterprise,DC=com

Source DSA Address: 62d85225-76bf-4b46-b929-25a1bb295f51._msdcs.enterprise.com

Inter-site Transport (if any): CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=enterprise,DC=com

failed with the following status:

DNS Lookup Failure.

The record data is the status code. This operation will be retried.

This error means the local DC could not resolved the GUID based DNS name of it’s replication partner.

To repro the error, try to ping this name. In the example :

ping 62d85225-76bf-4b46-b929-25a1bb295f51._msdcs.enterprise.com

Pinging HubDC.domain.enterprise.com [1.1.1.10] with 32 bytes of data:

…

This should normally fail. If it works, replication should not get this error next time it’ll get scheduled. In that case, to find out what happened, check the DNS server the local DC is currently using :

nslookup (with no commands)

The currently used DNS server is then displayed. Check if it is the first one declared in the IP configuration of the local DC. If not, the local DC might have sent it’s initial name resolution request to the first one when it triggered replication and it failed to resolve it. Since then it might have failed over to a subsequent DNS server that is able to resolve it. In this case find the reason why previous declared DNS servers failed to resolve the name as described in the following.

If the PING fails, then do the following :

Ø Check the DNS server that owns the root of the forest contains the requested name. If the name is missing, look in the replication partner’s event log for failures on registering it’s DNS names.

Ø If the DNS server does not own the root of the forest, verify it’s forwarders list (go to the DNS MMC, select the properties of the DNS server, and go to the “Forwarders” tab). Verify that the DNS servers declared as forwarders are the proper ones (the ones that own the root zone for the forest).

Ø Once this problem is fixed, re-run the ping command on the local DC which should then work. Replication should then occur properly next time it will be triggered.

It ping still fails on the local DC, check whether the name’s been cached as a negative entry using :

ipconfig/displaydns

If it is, this means that the local DC received a “Name not found” response to the name resolution request it sent to it’s DNS server last time replication has been triggered.
Note the DNS server replies with a “Name not found” only in two cases :

· It is authoritative for the zone (it has a copy of the zone that should contain the name), but the name is missing from it.

· It is not authoritative for the zone AND it could not revolve the name recursively using root hints AND it could not revolve the name recursively using a his declared forwarders.

In the other cases (for example, if it is not authoritative for the zone and has no root hints or forwarder declared), it will answer “Server Failure” to the query, not “Name not found”. The client will then not cache the response.

Ø If the name has been cached as a negative entry, the flush the DNS cache on the local DC, using :

ipconfig/flushdns

Ø Then try to ping the GUID based DNS name again.
If the name can now be resolved, replication should then occur properly next time it will be triggered. To avoid this problem to occur in the future :

· Find out the reason why the DNS server has not been able to resolve the name when replication has last been triggered.

· Also check the value of the “NegativeCacheTime” entry located in HKEY_LOCALMACHINE/SYSTEM/CurrentControlSet/Services/Dnscache/Parameters. It is set to 0×12C (=300 seconds =5 minutes) by default.

A high value could prevent the DC from going to the DNS server to lookup the name next time replication will be triggered and, consequently, prevent it from happening correctly, even if the name could be resolved.

Ø If the ping command still doesn’t work, then stop and restart the “DNS client” service using :

Net stop “dns client”

Then try to ping the GUID based DNS name again. If this works, this means that when replication has been triggered, the DC could not reach it’s “preferred” DNS server (the one declared first in it’s IP configuration). It then failed back to another one (the second or next following ones declared in the list) and this DNS server could not resolve the name. Moreover, once the DNS client fails back to a alternate DNS server, it will never return to the initial one, so replication will fail with the same status each time it’ll be triggered.
Stopping and restarting the DNS client service on the DC makes it revert to it’s preferred DNS server. If this server is now responding and is able to resolve the name, replication should work properly next time it will be triggered.