Replication Error (Child Domain)

Please double-check the network connections' tcp-ip settings, especially that the server itself (if it is running DNS) or the AD domain controller is set as the dns server.

Please ready my origional comment.  DNS name resolution is working fine.  I can ping all DCs from any DC using FQDN.

Are you showing any DCOM, COM+, Win32 Time, or RPC endpoint errors in your logs?

I checked error logs for the errors you listed.  There are no COM+, WIN32 Time or RPC errors.  I did find a few DCOM errors listed below:
<><><><><><><><><>
Event Type:      Error
Event Source:      DCOM
Event Category:      None
Event ID:      10009
Date:            7/21/2006
Time:            11:41:21 AM
User:            N/A
Computer:      PAYTON
Description:
DCOM was unable to communicate with the computer XX.XX.XX.XX using any protocols.
<><><><><><><><><>

The date is from the day I setup the child domain.  The IP I XXX'ed out is the IP of our main DNS server.  Our main DNS server is on a linux box.  I found other DCOM events that confirm after this error that it was able to establish communication with the main DNS server.

Thanks for the suggestion.

Just a while ago I had an issue like this, we found that the server had incorrect DNS setting (isp instead of domain dns) in its static network settings. The domain DNS was working fine all the time, since forwarders were configured correctly to our isp's dns server. Only the server failed at name resolution thus the error.

..but as you said it does not seem to apply here since all DCs successfully ping each other.

Would you consider installing a packet sniffer, such as Ethereal (http://www.ethereal.com) to see what goes wrong?

Have you defined the protocols for use in NTDS in Sites and Settings? If so, you have inadvertantly created bridgehead servers. Also, look at the time defined for replication. It should "never" be set below 180 minutes.

I have not gone in and defined what protocals to use in NTDS.  I did check.  The automatically generated ones are set to RPC.  Another admin tried to create some connection documents to see if we could get those to work and they are set to IP.  Replication time is set to 180 minutes.  

This is a DNS problem. Pinging with FQDN does not mean that you do not have problems with DNS server. This is a very common problem.

Cause : The DNS server in your child domain does not have the Domain Controller records.

The problem is with your DNS settings in you Child DC.

Try this first.

Method 1

Open the tcp/ip settings for the child DC and put the ip address of the DNS server in the child.domain.com (same domain, not the root domain).

and then go to command prompt and run a command: netdiag /fix

This would fix the records in the DNS server.

Scroll down the results. It will give you results showing : DNS test Passed/Failed. Try to figure out the errors. It will definitely show you that DC registration entries not found.


Try this first, if this does not help then please let me know your domain structure. I would like to know that are your DC's also the DNS servers or not. Give me the way you have configured the DNS settings on DC's.  And also how many DC's you have in your root dom ain and child domain.

You will definitely want to remove the IP listing from NTDS, that will define a bridgehead server, and could definitely keep replication from working correctly. You can leave them blank and set the replication time to 180 minutes (although yours' seems to be correct)

One other thing, is your child domain controller set as a global catalog server?

Yes the child domain DC is set as a blobal catalog.

We also need to verify that the child domain DNS server (DC) uses the parent domain controller as a forwarder in DNS. Since DNS is hierarchical, you should point to yourself as a DNS server, hosts (users) should point to you, and the forwarder should point to the main DNS server of the parent domain. The main parent DNS sever should also point to itself, and use your ISP as a forwarder. Verify these settings and let me know. We'll figure this one out... :-)

Child DNS server is the DNS server for the child domain.  It then has a forward to the parent DNS server.  The same can be said for the parent DNS server.  It has pointers to the child domain's DNS server to reslolve any child domain entries.  DNS seems to work ok.  I can ping all DCs from any DC using the FQDN.  The funky one with all the characters, d35393-81bb-4c1c-aba6-fd872caf7cc34._msdcs.ad.domain.com.  All DCs can retrieve the correct SVR records for the parent and child domain.

Just for more info here is another error message I am getting in relation to replication.

7/25/2006          12:19:20 PM      2          1          1926     NTDS KCC        NT AUTHORITY\ANONYMOUS LOGON              PAYTON           The attempt to establish a replication link to a read-only directory partition with the following parameters failed.        Directory partition:   DC=ad,DC=domain,DC=com    Source domain controller:   CN=NTDS Settings,CN=NOYCE,CN=Servers,CN=Pullman,CN=Sites,CN=Configuration,DC=ad,DC=domain,DC=com    Source domain controller address:   XXXXXXXXXXXmsdcs.ad.domain.com    Intersite transport (if any):   CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=ad,DC=domain,DC=com        Additional Data    Error value:   1908 Could not find the domain controller for this domain.  

Payton is the parent DC.  This error was found on the child DC.

I think it is time to up the points on this one ;).

Correction to above post:

Payton = child DC
Noyce = Parent DC

d35393-81bb-4c1c-aba6-fd872caf7cc34._msdcs.ad.domain.com is an orphaned name. You do not have to have a forwarder on the parent to the child, it will automatically make requests to the child DNS server and retrieve info from the GC.

It looks like you have an orphaned guid in AD. You may have to use ADSIEdit to fix this error.

Pmarguardt can you explain a little bit more about orphaned name and ADSIEdit?

Thanks.

d35393-81bb-4c1c-aba6-fd872caf7cc34 shows me the guid of the machine. That means that AD has propogated an orphaned name and shows me the GUID of the machine. In order to remove the GUID from AD, you have to use ADSIEdit to remove the GUID. The problem is what was changed in AD to leave and orphaned GUID? Have you removed a DC from the domain? Have you removed any server with a network service from AD? Have you remnamed a server with a network service?

I am a bit confused about how you know this is orphaned.  All of my DCs have DNS entries that look similar to that funky one.  The MS tech I have been working with actually had me ping every DC from every DC with entries that look like that one.

MS would know what orphaned guid correlates to, but you will need to delete that guid from AD. In order to delete it from AD you use ADSIEdit. Are you currently engaged with a MS tech? Also, you did not answer the questions I posed previously. Any additional information would be helpful to identify the cause of this issue.

Kriskb - Please read the following:

I HAVE WRITTEN THE STEPS WHICH YOU NEED TO PERFORM AT THE END BUT BEFORE THAT JUST READ THIS BECAUSE IT WILL MAKE THOSE STEPS CLEAR TO YOU AND YOU WILL KNOW WHAT EXACTELY YOU ARE DOING.

I AM AGAIN SAYING THAT THIS IS A DNS LOOKUP FAILURE. READ AND IMPLEMENT FOR THE SOLUTION.

This is a DNS problem at your child domain level. I faced the same problem and resolved it.

This is happening because KCC is not able to create a replication link from your Parent domain to child domain because of the DNS lookup Failure. Let me explain you the way you should configure your DNS servers in order to resolve this problem. It will go away, TRUST ME.


For example you have 4 Domain controllers at root domain and 2 DNS servers as well.
and at child level you have the same configuration.

Now see below how you will configure you DCs and DNS servers so that KCC works properly.

ROOT LEVEL CONFIGURATION:
=========================
Lets say your root domain name is USA.COM. You have 2 DNS servers.

1. USADNS1 - 192.168.3.1
   TCP/IP configuration - Preffered DNS server would be 192.168.3.2 and Alternate would be 192.168.3.1

2. USADNS2 - 192.168.3.2

   TCP/IP configuration - Preffered DNS server would be 192.168.3.1 and Alternate would be 192.168.3.2.

This configuration is important so that the DNS severs can replicate the zones easily.

You have 4 DC's

1. USADC1
2. USADC2
3. USADC3
4. USADC4

They all 4 DC's will have Preffered DNS servers as 192.168.3.1 and alternate DNS server as 192.168.3.2.

When you first install your root domain AD will automatically create a zone for you USA.COM.
YOU Also need 2 Create stub zone (Win 2003) or delegation (Win 2000) for you child domain.
You cannot put forwarding at root level.

CHILD LEVEL CONFIGURATION
=========================

Lets say your child domain name is BENSON.USA.COM. You have 2 DNS servers.

HERE IS THE PROBLEM ACTUALLY AND SOLUTION.

When you install your FIRST child domain, AD will automatically create a zone for you BENSON.USA.COM at root level USA.COM because we put the DNS addresses for the root domain dns server in the TCP/IP config.

Now in order to reduce the network traffic we change the configurtion. We delete the zone benson.usa.com from the root level DNS servers and create our own DNS servers in the child domain level. we change the TCP/IP configuration for the child level DNS server and put its own ip address in the preffered DNS server. Then we create a forward lookup zone named benson.usa.com. You must have noticed that when you create that zone it creates only three records, SOA, NS and host.

now what happens, you have created the zones but your child DC is not registered as a DC in the DNS server. it has those entries in the root Level DNS servers.  At that time we need to run netdiag /fix command to fix this. Netdiag /fix will automatically creates all other records. it also tell you whether you DNS server passes the test or not.


Before you run the command create a forwarder for usa.com (Root domain) at child level.


CONFIGURATION

1. BENSONDNS1 - 192.168.4.1
   TCP/IP configuration - Preffered DNS server would be 192.168.4.2 and Alternate would be 192.168.4.1

2. BENSONDNS2 - 192.168.4.2

   TCP/IP configuration - Preffered DNS server would be 192.168.4.1 and Alternate would be 192.168.4.2.

This configuration is important so that the DNS severs can replicate the zones easily.

You have 4 DC's

1. BENSONDC1
2. BENSONDC2
3. BENSONDC3
4. BENSONDC4

They all 4 DC's will have Preffered DNS servers as 192.168.4.1 and alternate DNS server as 192.168.4.2.



Before you perform these steps, creae stub zone or delegation for your child domain and put a forwarder from you child to root domain.

WHAT YOU NEED TO DO IS:

1. ON YOU CHILD LEVEL DNS SERVER PUT THE PREFFRERD DNS AS YOUR ROOT LEVEL DNS SERVER IP.WAIT FOR SOME TIME AND RUN NETDIAG /FIX, WAIT FOR SOME TIME.
2. GO TO SITES AND SERVICES AND DO A CHECK REPLICATION TOPOLOGY.
3. KCC WILL DO A CHECK AND CREATE A REPLICATION LINK OBJECT BETWEEN ROOT AND CHILD (IT WILL TAKE 20-30 MINS). AT THAT TIME YOUR CONFIGURATION, DNS, SCHEMA WILL ALSO REPLICATE. DO MANUAL REPLICATION ALSO TO BE IN A SECURE SIDE.
4. AFTER THE REPLICATION TAKES PLACE GO TO THE CHILD LEVEL DNS SERVER AND RUN NETDIAG /FIX. AND SEE THE DNS TEST RESULTS.
5. THEN CHANGE THE IP ADDRESS OF THE CHILD DNS SERVER BACK TO ITS OWN IP OR OTHER DNS IN THE CHILD DOMAIN.


YOU PROBLEM WILL BE SOLVED.

Will this work even if at the root level it is a non AD DNS server.  It is runnnig on a linux box, but it does support dynamic updates.

pmarquardt ,

Yes we had a DC crash about 4 weeks ago.  We brought up a new one but did not rename it with the old DC name.  I have seized its roles and have done some cleanup.  Thank you for the info on orphened GUID.  I will look into that more.  Yes I am engaged wtih an MS tech via email.  Although it is not too helpful.  At most he has had me give him MCP reports and tried a reg hack to get kerberos to use TCP instead of UDP.  Oh and asked me to reboot production servers that can't go down for reboots.

YES IT WILL.

i AM NOT SURE ABOUT THE REPLACE MENT OF NETDIAG /FIX IN LINUX. YOU NEED TO CHECK THAT OUT WITH SOMEONE.

I just got ADSIEdit installed and I am poking around.  Do you know where I can find the GUID?  I have been looking around and do not see any ghosts of my old DC in there.  I am also going to run the metadata cleanup tool as soon as I figure out the syntax for server name.  We are running BIND for our root DNS server.  I just spoke with the admin of that server and he is confident it plays nice with AD DCs because it is set to allow them to update the DNS server.  

Check the Domain Controller container, and the site it existed in. If you still do not see it, run the metadata cleanup tool to remove the GUID.

As for running BIND, it is not allowing dynamic AD updates unless they are running SAMBA and tricking the clients into believing they are talking to AD. Are you actually running AD, or running Linux LDAP?

We are running AD.  Only our DNS server is linux.  Do you mean using SAMBA to trick the AD clients into thinking they are talking to an AD DNS server?

I just wasn't sure how your environment was setup. If you are using AD then you need to verify that the clients point to the local DC for DNS, the local DC DNS points to itslef, and forwards to the rood DC. The root DC should point to itself for DNS and forward to the Linux DNS. This will get the records into synch. You just need to make sure that the DNS hierarchy is setup correctly.

Current Setup

Parent DNS is the BIND linux box.  It is set to allow dynamic updates from any DC.  
Child DC points at itself.  It forwards to Parent DNS.  

I just got done with metadata cleanup.  The old DC is not listed in AD anymore.  I did not have to clean it up.  Using NTDSutil I looked for any refrance to the DC and could not find any.  I looked in the containers you suggested and did not find any orphaned GUID.  Thanks for your help so far.  It is going to take a bit to try the DNS fix with DNS existing in AD instead of BIND.  Our enviernment is pretty complex and I can't just change the DNS structure at a moment's notice.  

Well, you're just changing the forwarding structure of DNS, not the functionality. Your BIND DNS will not correlate with the correct AD information as it does not manage the AD DNS structure. If you look at the forward lookup zones in AD on the root DNS server you will see the msdcs which corresponds to the forest zone for AD. You will not see that information in BIND, or it will not update the forest information as it is not AD compatible with LDAP/SAMBA.

Also, when you ran the cleanup did you search for the GUID and the DC you removed?

Yes I did search for the GUID and the DC I removed.  I could not find it.  I am not the DNS admin.  I will talk with him to see how he feels about trying the DNS fix.  Is there a way with SAMBA to trick a BIND DNS server to acting like a AD DNS server?

You have to have LDAP/SAMBA running and add all the windows machines to the SAMBA domain. I'm not aware of another way, but that is really a question for a Linux guru. I specialilze in Windows infrastructure. You could pose that question to the Linux queue and see if they have an answer. Other than that, we really just need to get the DNS structure setup hierarchically to the root. That will fix replication errors and a plethora of additional nuisances.

Ok after using metadata cleanup again on a diffent parent DC I did find a referance to the old DC.  Relication is now working.  Also I can now authenticate DHCP servers.  Very weird.  So Pmarquardt I will be accepting your answer.  Thank you for sticking this out with me.  :)

NP, that's why I'm here. Just trying to return the favor to others, when I have used this site to solve my problems in the past.