AD Not replicating with 2 sites

  • Thread starter Thread starter Jennie
  • Start date Start date
J

Jennie

Hi,

I have recently added 2 new dc's to our domain (taking
over from NT4's to make native). I have noticed that AD
is not replicating from our main site to these 2 sites
but it is replicating from the 2 sites to the main.

When i try to force replication i get

The following error occured during the attempt to
synchronize the domain controllers:
the naming context is in the process of being removed or
is not replicated from the specified server

I checked DNS to make sure all ok, all looked fine until
i checked the srv files and i found that on the main
server the srv files for these 2 servers was missing. I
stopped and started the netlogon services to see if this
would resolve but it did not. DNS seems to be
transferring ok as i added some test entries on 1 of the
servers and reloaded from the main and these entries were
there.

Please help!!

Jennie
 
Hi Karin,

Thanks for this. I had previously checked the dynamic
updates and it is set to allow. We are on service pack 4
on all our servers so i do not know where to go next.
Should i try manually adding an srv record for one of the
servers? If i do this then do i need to add the same as
all other srv's

i.e _kerberos _tcp
_ldp _tcp
etc....

I have checked event log and we have lots of event id's
1265.

Thanks again for your help

Jennie
 
Hi,

I checked out the articles but non were able to help!! ~I
ran repadmin /showreps (as advised in one of the
articles) and this was returned...not sure if it is
relevant:

Default-First-Site-Name\SECTA07 (deleted DSA) via RPC
objectGuid: 2dd22218-b83f-45c5-9ff2-65c9da96bff7

This is one of the servers that cannot replicate and has
no srv records on the main server. The other server
SECTA09 is not even mentioned when i run readmin /showreps

I ran dcdiag to test replications and this is what i got
for both servers:

SECTA07's server GUID DNS name could not be resolved to an
IP address. Check the DNS server, DHCP, server
name, etc
Although the Guid DNS name (b350bb9c-0036-4c17-
85d8-fea1999cf7f0._msdcs.Secta.co.uk) couldn't be
resolved, the
server name (secta07.Secta.co.uk) resolved to
the IP address (192.168.1.1) and was pingable. Check
that the IP
address is registered correctly with the DNS
server.
......................... SECTA07 failed test
Connectivity

Seems it is definitely related to DNS doesn't it????

I have a dns test using netdiag and it did not pass
saying that DNS was only registered correctly on some
servers.

Any more ideas???

Thanks

Jennie
 
Hi Jennie

How is your DNS configured? Do the site servers update to the DNS Server in
the Main Site? In not point them there to register their records and resolve
the other DC records for now, to see if this gets replication going.

It is definately a problem if they are not registering their _msdcs GUID
records as these are needed for all of the other servers to make connection
objects with them etc. Also these site servers need to be able to resolve
the _msdcs GUID records for all of the other servers that they need to
replicate with. In this case as replication appears to be working from the
site to the main site, it would appear that the main site servers are having
trouble resolving the remote site DC's GUIDs in the _MSDCS zone.

It sounds like this is definately DNS related, when DC's in the root Domain
reigster DNS records to themselves and point to themselves for registration
an issue can occur called the "Island issue", where the DC's effectivly
island themselves and you can get into a situation where you have no
replication or replication in only one direction. As replication relies on
DNS being up to date and in order for Intergrated DNS to be up to date it
relies on replication there can be a bit of a catch 22 situation that
develops, if things change. In order to get around this and also to ensure
local site resolution for child domain etc. often people will set up the
_msdcs zone as a separate DNS zone and pull it down as a secondary to the
other DNS Servers in other sites. This ensures that resolution of the _msdcs
zone is local but registration is always to somewhere else. However client
registrations etc are also local to the site.

Hope that this helps and makes sense, I have marked the thread so post back
if you still are having issues.

Thanks

Jody
 
Hi Jody,

The way in which the DNS is configured:

Server points to itself in NIC properties
In DNS forwarders enabled to the Main Site (which in turn
fowards to ISP DNS)
This is the setup on all of our sites that are working
too. I have double checked on the 2 new servers and this
is definitely what is going on.

I understood your explaination of what is happening but
did not understand the part about the _msdcs being setup
as another zone. Would i need to do this even though it
is setup the same as our other sites?

Whilst i was waiting for a reply on the MS Newsgroups i
ran netdiag /fix on one of the offending servers and
found:

the default spn registration
for 'HOST/Server.Domain.co.uk' is missing on DC 'ALL DC'S
ARE LISTED HERE'

I'm sure this will probably confirm your suspicions on
the DNS issues??

Sorry to be a pain but i am still no closer to resolving
this :o(

Thanks for all your help

Jennie
 
Hi Jennie

I would not reconfig. your set up of _msdcs at this point, but I would
temporarily change the Site DC's NIC DNS Settings to point to the DNS Server
in the Main Site, to simplify the setup and eliminate DNS as a possible
cause. Ie. if all servers concerned update and resolve from the same DNS
Server we do not have to worry about DNS inconsistancies between DNS
servers. Once the initial replication issue is resolved it may then be an
idea to review how DNS is configured to prevent it happening again.

Once this is done check that from the Main Site DC's you can ping
"<SiteDCsDCreplGUID>._msdcs.<domain>.co.uk"
Get the replication guid from the top of the output for a "repadmin
/showreps" run against the Site Server.

If this succeeds try pinging the Main site Servers repl. guid from the Site
DC's and ensure that this works.

If all this works hopefully the KCC will be able to make the relevant
connection objects and replication will work. However whilst we have srv
records missing in DNS we need to get this sorted.

On the SPN error, it would be a problem if the HOST SPN was missing on all
DC's but this may be a symptom of the replication issue rather than a
cause..... DNS really needs to be taken out of the equation first.

Cheers

Jody
 
Hi Jody,

I have changed DNS on the NIC on the 2 servers to that of
the server at the main site and all seems to work. Am i
now able to change the NIC pointing to itself and rely on
forwarders to forward to the main site?? or will we get
the island situation again??? Is there a reason why this
has only occured on these 2 servers and non of the others?

Also good news is SPN has now registered!! :o)

Thanks

Jennie
 
Good news!!! :-)

Take a look at
http://support.microsoft.com/default.aspx?scid=kb;EN-US;275278 which
explains the DNS Island issue.

This is an issue which can present itself on DC's in the Forest Root Domain,
child Domain DC's are not effected by this particular issue. (also this
issue is addressed in Windows 2003)

There are a couple of methods that you can use to avoid this issue in the
future in your Windows 2000 Domain.
If we think about what the basic issue is it hopefully makes more sense.
This issue is that a set of circumstances can lead to a situation where the
local DNS is out of date and replication fails, if it fails in both
directions the other DNS Servers cannot get changes that are made on the
Site DNS Servers. As replication is failing DNS cannot replicate in or
possibly out the records that are needed for replication to work in both
directions.

If the Site DC has a change to it's IP or cname record and as it is
authoritative for the root zone, it updates the records on itself. No other
DNS Server will know about this change until replication occurs, but for
replication to occur the other DC's need the up to date record, therefore if
other servers are not looking at the Site DNS Server they will attempt
replication with either an incorrect record or the record will not be
present on their DNS Server and it will fail. Generally this issue presents
itself in environments where changes are being made, ie. servers moved, new
servers added, or if there are already replication issues and together with
this DC's in the forest root register DNS with themselves. If the
environment is fairly static and established unless anything changes you
will probably not see this issue.

Here are some of the methods that can be used to avoid this issue:
Note: This only applies to DC's in the root domain that are DNS Servers and
register with themselves.

1. Set the DNS Server on the NIC to be another DNS Server and to themselves
as an alternate DNS Server.
2. Promote Servers but point them to alternate DNS Servers until you are
sure that replication has complteted in both directions. If the Servers IP
etc will remain static they can then point to themselves, but if anything
changes like IP on the Server it will need to be pointed to another DNS
Server to ensure that this update is replicated to all other DNS Servers.
3. Some people will also separate the _msdcs.domain.com to be a separate DNS
zone and then set up a secondary _msdcs zone on the Site servers, and use
Zone transfers to pull the information to the local DNS Server. The local
DNS Server can then point to itself. This ensures that any resolution of
_msdcs and the domain remain local but registration to the _msdcs zone is
done on the Server that has a writable copy.

HTH

Jody
 
Back
Top