Missing site connector to parent DC

[Kevin]

I recently installed fix
http://support.microsoft.com/default.aspx?scid=kb;en-us;836534
because of some DNS record issues I was having on my 2003 domain. It
seemed I got into the problem situation after having a "split" domain
zone on some DCs. I had been 2003/2000 mix and made the mistake of
marking a domain to replicate to all DC's in the forest (MS should
possibly consider making this unavailable until in 2003 functional).
The 2000 servers maintained a "domain wide" partition, and the 2003
servers created a "forest wide". Updates applied to the domain wide
wouldn't reach the forest wide zone and vise versa. This was a
problem for both forward and reverse zones. When I upgraded the DC's,
this problem remained. The solution was to delete the domain wide
zone (which makes you grit your teeth a bit), then the server would
replicate the forest wide zone.

After that, I started getting errors referenced for the above hotfix.
Application of the hotfix seems to have repaired all but one DC. The
DC is in my child domain, and if you look at the connectors in
DSSite.msc, it only has a connector to the PDC. There is no connector
to the schema master in the parent domain (forest root domain). I
tried manually creating a connector and telling it to replicate, and I
get "The Naming Context is in the process of being removed or is not
replicated from the specified server".

DCDiag on the server doesn't complain about anything. Short of
demoting and repromoting the DC, I don't know how to fix this. I'd
appreciate any suggestions.

Kevin

 

[Ace Fekay [MVP]]

In

I recently installed fix
http://support.microsoft.com/default.aspx?scid=kb;en-us;836534
because of some DNS record issues I was having on my 2003 domain. It
seemed I got into the problem situation after having a "split" domain
zone on some DCs. I had been 2003/2000 mix and made the mistake of
marking a domain to replicate to all DC's in the forest (MS should
possibly consider making this unavailable until in 2003 functional).
The 2000 servers maintained a "domain wide" partition, and the 2003
servers created a "forest wide". Updates applied to the domain wide
wouldn't reach the forest wide zone and vise versa. This was a
problem for both forward and reverse zones. When I upgraded the DC's,
this problem remained. The solution was to delete the domain wide
zone (which makes you grit your teeth a bit), then the server would
replicate the forest wide zone.

After that, I started getting errors referenced for the above hotfix.
Application of the hotfix seems to have repaired all but one DC. The
DC is in my child domain, and if you look at the connectors in
DSSite.msc, it only has a connector to the PDC. There is no connector
to the schema master in the parent domain (forest root domain). I
tried manually creating a connector and telling it to replicate, and I
get "The Naming Context is in the process of being removed or is not
replicated from the specified server".

DCDiag on the server doesn't complain about anything. Short of
demoting and repromoting the DC, I don't know how to fix this. I'd
appreciate any suggestions.

Kevin

What sort of problems did you encounter from your split namespace? Was it
just accessing your external website? What solution did you use for that?
I'm not sure if any solution I've ever seen for a split zone would cause
this, but rather zone replication choice, DC versions, number of domains and
topology.

Keep in mind, with a mixed environment, the replication method needs to drop
to the least common denominator. The bottom AD replication scope selection
under the zone properties, is the one you will need to select if in a mixed
environment. THat stores the zone in the Domain NC container, which is where
2000 stores it. The second selection stores it in the DomainDnsZones
Application Partition, which is what 2003 uses, and therefore not compatible
with 2000 in a mixed zone.

For the _msdcs zone, which is forest wide, in some cases a secondary zone of
this zone needs to be created on a 2000 DC/DNS, so the Forest root is
resolvable, especially from a child domain, hence why I *believe* the KCC
couldn't create a connection object to the forest root.

So this depends on how the whole infrastructure replication solution was set
up.

Hope that helps in understanding what happens in a mixed environment and it
helps to come to a solution. Easiest solution? All DCs need to be 2003. I
know that's not the answer you want to hear, but just a comment. I've fixed
this sort of "mixup" (my terminology) for a few clients, and it takes some
time remoted into a system to establish what DCs are where and what
versions, and who has DNS on them, to clean it up.

I hope it helps you to resolve it. If you have further questions, please
post back.

--
Regards,
Ace

G O E A G L E S !!!
Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft Windows MVP - Windows Server - Directory Services

Security Is Like An Onion, It Has Layers
HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.

 

[kgould]

The problem I had from the split namespace was that clients with a DNS
configuration pointed to a Win2k server would update the DomainDNSZones
partition copy of the DNS zone, while ones pointing at the Win2k3
servers would update the ForestDNSZones copy of the DNS zone. Queries
across these zones don't work. Actually, I think it would be a good
idea for MS to disallow or warn on changing zones to forest wide when
the domain hosting the zone is not in 2003 functional mode.

I have installed fixes 823230, 836534, and 832851 to resolve errors
indicated in the eventlogs, and then manually created the missing
connection object and gave it time to replicate. I then deleted the
manually created object and forced a KCC cycle, and it is now creating
the connection itself.

I additionally had 1 DC that wasn't participating in SYSVOL sharing
properly - I resolved this by stopping ntfrs and netlogon, deleting
%SYSTEMROOT%\ntfrs\jet\ntfrs.jdb and %SYSTEMROOT%\ntfrs\log\edb.log,
res1.log, res2.log, then restarting ntfrs and netlogon. This was from
the jsiinc.com web site.

Thanks for your help!