Windows Server TechCenter >
Windows Server Forums
>
Directory Services
>
KCC creates invalid NTDS connection objects
KCC creates invalid NTDS connection objects
- I have been working on a problem with our multi-site single domain network for a couple of weeks now. Servers are currently all 2003 servers (one is 2003 R2) running in mixed mode. In preperation to add a 2008 domain controller, I changed the domain and forest to 2003 mode. I then ran adprep on the central site DC (which happened to be the gcc and, at the time, the FSMO) to prepare for 2008 server.
Initially, NTDS connection objects existed for all sites connecting back to the central site. However, after running adprep, two of the remote DC's generated NTDS connection objects for all sites, and they disappeared from the central server. The problem is, the network _is not_ fully routed, and these sites do not see all other sites. I have attempted to delete the objects, but they are always recreated quickly afterwards.
Most of the articles I've found deal with 1311 errors when servers do not replicate even though they should. I can't find anything useful for convincing the kcc that the connection objects it has created are just plain wrong.
I've tried everything in the following article:
http://technet.microsoft.com/en-us/library/cc740252%28WS.10%29.aspx
repadmin /showism on the problem server (the one which contains all the invalid NTDS connections) shows:
Site(2) CN=Site8,CN=Sites,CN=Configuration,DC=Domain,DC=tld
100:180:0, 100:180:0, 0:0:0, 100:180:0, 100:180:0, 100:180:0, 100:180:0, 100:180:0
All DCs in site CN=Site8,CN=Sites,CN=Configuration,DC=Domain,DC=tld (with trans & hosting NC) are bridgehead candidates.
The position of the 0:0:0 changes for each site, but is otherwise the same for all.
The server at the central site is designated as the preferred bridgehead server.
Site link objects are configured correctly to match the actual topology of the network. There are two sites which can see all other sites. One of these has 2 servers, the one I ran adprep on the other is the only DC running 2003 R2. An additional 3 sites which can all see each other, and 3 sites which can only see the 2 fully routed sites. The Inter-Site IP Transport had been set to bridge all site links, but this setting was changed over a week ago and has not helped.
I've also looked at the following article:
http://support.microsoft.com/kb/307593/en-us
I've checked most of the items in that article as well, however I'm stuck on the last suggestion:
Delete connections if KCC is in "Connection Keeping" mode.
I have no idea how to tell if KCC is in this mode, and as I've mentioned when the connections are deleted, they just come back.
I have tried demoting and repromoting the affected servers multiple times. I have manually created NTDS connections to all servers from the original central server. The incorrect NTDS connections will not go away, and I'm out of ideas. Any suggestions would be greatly appreciated.
Answers
Once again - your AD site/site link design should reflect your underlying physical network topology.
In particular, you stated that site F can communicate only with sites A and B. If so, there should be, at most, TWO site links, namely:
- site link between site A and F
- site link between site B and F
If these three sites are not using point to point connections, but instead rely on solutions such as MPLS, then it might make sense to create a single site link among three sites.
The same principle should apply to all other sites/site links.
hth
Marcin- Marked As Answer byMichael J McNally Sunday, November 08, 2009 2:37 PM
All Replies
- Make sure that BASL is disabled and that any manually created site link bridges reflect the routing arrangements you have between your sites. Ensure that this setting actually applies to all DCs - considering that your replication is likely affected by the issue you are describing, you might want to connect to at least one in each site and wait for intrasite replication to complete. Then trigger KCC (repadmin /kcc or Check Replication Topology from AD S&S) on each bridgehead server...
hth
Marcin - All servers currently have NTDS connections to the central site, so replication is occurring. I re-checked the BASL settings, and all are disabled. Each site, except the central site, has only a single server so there is no intrasite replication.
Deleting the incorrect automatically generated NTDS connections, and then triggering the KCC results in the connections reappearing immediately. I know they are newly created objects because the canonical name changes. Triggering the KCC results in 1311, 1865, and multiple 1925 errors. - What are the naming contexts replicated over these connections? Have you tried designating a different ISTG?
Marcin - The replicated naming contexts appear to be the same on all connections: ForestDNSZones.RootDomain, DomainDNSZones.RootDomain, RootDomain. When I manually create connections, these are the naming contexts listed, and I don't know of a way to specify or edit that field.
As I said, all but the central site have only a single server, and each site is a separate subnet. It is my understanding that there is an ISTG for each site, and consequently no other DC available to switch that role to.
I have tried changing the FSMO roles to the second server at the central site, but I'm not sure if I changed the ISTG for that site. I'll try looking into that, but the servers at that site do not get 1311 errors, so I'm not sure that will help. - Is the bridgehead server in the hub site configured as an AD-integrated DNS server?
hth
Marcin - Yes. All the DC's are configured as AD-integrated DNS servers, mainly to serve as the primary DNS for clients at each site.
Not sure if it matters, but there are also many other sites (1 or 2 computers apiece) which are connected to the hub sites by VPN (via Linksys RV042 router) with no server. When joining machines to the domain at these sites, DNS (being served by DC at hub site) would often return an address of a DC at an unreachable site, causing the join to fail. I would resort to ping domain , ipconfig /flushdns, repeat until DNS returns address of hub site, and join would go through fine. I was beginning to add subnets objects for each of these sites in hopes that AD DNS would figure out which subnets were reachable from those locations, but removed those subnets when this problem arose to keep things simple. - Can you describe your site link topology? The output of repadmin /showism seems to indicate that this does not reflect your network infrastructure (costs are identical for all remote sites).
hth
Marcin - There are 8 sites with a DC at each site, except for site A which has 2.
Site A and Site B have VPN connections from all other sites.
Site C, D, E have VPN connections to each other as well as to site A and B.
Site F, G, and H only connect to sites A and B.
The repadmin /showism above is from site F. I would agree this does not seem correct. On the site link object for that site, "Sites in this link" contains only sites A, B, and itself. Site link objects for A and B are the only site link objects which list site F under "Sites in this link".
It seems to me that the repadmin /showism does not agree with this. The real question is why, and what to do about it.
When creating the site links, I left all at default values, which is why I assume it shows identical costs.
The full results of repadmin /showism run from server at site F:
==== TRANSPORT CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=Domain,DC=com CONNECTIVITY INFORMATION FOR 8 SITES: ====
0, 1, 2, 3, 4, 5, 6, 7
Site(0) CN=SiteB,CN=Sites,CN=Configuration,DC=Domain,DC=com
0:0:0, 100:180:0, 100:180:0, 100:180:0, 100:180:0, 100:180:0, 100:180:0, 100:180:0
All DCs in site CN=SiteB,CN=Sites,CN=Configuration,DC=Domain,DC=com (with trans & hosting NC) are bridgehead candidates.
Site(1) CN=SiteC,CN=Sites,CN=Configuration,DC=Domain,DC=com
100:180:0, 0:0:0, 100:180:0, 100:180:0, 100:180:0, 100:180:0, 100:180:0, 100:180:0
All DCs in site CN=SiteC,CN=Sites,CN=Configuration,DC=Domain,DC=com (with trans & hosting NC) are bridgehead candidates.
Site(2) CN=SiteG,CN=Sites,CN=Configuration,DC=Domain,DC=com
100:180:0, 100:180:0, 0:0:0, 100:180:0, 100:180:0, 100:180:0, 100:180:0, 100:180:0
All DCs in site CN=SiteG,CN=Sites,CN=Configuration,DC=Domain,DC=com (with trans & hosting NC) are bridgehead candidates.
Site(3) CN=SiteF,CN=Sites,CN=Configuration,DC=Domain,DC=com
100:180:0, 100:180:0, 100:180:0, 0:0:0, 100:180:0, 100:180:0, 100:180:0, 100:180:0
All DCs in site CN=SiteF,CN=Sites,CN=Configuration,DC=Domain,DC=com (with trans & hosting NC) are bridgehead candidates.
Site(4) CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=Domain,DC=com
100:180:0, 100:180:0, 100:180:0, 100:180:0, 0:0:0, 100:180:0, 100:180:0, 100:180:0
1 server(s) are defined as bridgeheads for transport CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=Domain,DC=com & site CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=Domain,DC=com:
Server(0) CN=SiteAserver1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=Domain,DC=com
Site(5) CN=SiteE,CN=Sites,CN=Configuration,DC=Domain,DC=com
100:180:0, 100:180:0, 100:180:0, 100:180:0, 100:180:0, 0:0:0, 100:180:0, 100:180:0
All DCs in site CN=SiteE,CN=Sites,CN=Configuration,DC=Domain,DC=com (with trans & hosting NC) are bridgehead candidates.
Site(6) CN=SiteD,CN=Sites,CN=Configuration,DC=Domain,DC=com
100:180:0, 100:180:0, 100:180:0, 100:180:0, 100:180:0, 100:180:0, 0:0:0, 100:180:0
All DCs in site CN=SiteD,CN=Sites,CN=Configuration,DC=Domain,DC=com (with trans & hosting NC) are bridgehead candidates.
Site(7) CN=SiteH,CN=Sites,CN=Configuration,DC=Domain,DC=com
100:180:0, 100:180:0, 100:180:0, 100:180:0, 100:180:0, 100:180:0, 100:180:0, 0:0:0
All DCs in site CN=SiteH,CN=Sites,CN=Configuration,DC=Domain,DC=com (with trans & hosting NC) are bridgehead candidates.
==== TRANSPORT CN=SMTP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=Domain,DC=com CONNECTIVITY INFORMATION FOR 8 SITES: ====
Site CN=SiteB,CN=Sites,CN=Configuration,DC=Domain,DC=com is not connected by this transport.
Site CN=SiteC,CN=Sites,CN=Configuration,DC=Domain,DC=com is not connected by this transport.
Site CN=SiteG,CN=Sites,CN=Configuration,DC=Domain,DC=com is not connected by this transport.
Site CN=SiteF,CN=Sites,CN=Configuration,DC=Domain,DC=com is not connected by this transport.
Site CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=Domain,DC=com is not connected by this transport.
Site CN=SiteE,CN=Sites,CN=Configuration,DC=Domain,DC=com is not connected by this transport.
Site CN=SiteD,CN=Sites,CN=Configuration,DC=Domain,DC=com is not connected by this transport.
Site CN=SiteH,CN=Sites,CN=Configuration,DC=Domain,DC=com is not connected by this transport.
0, 1, 2, 3, 4, 5, 6, 7
Site(0) CN=SiteB,CN=Sites,CN=Configuration,DC=Domain,DC=com
0:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0
All DCs in site CN=SiteB,CN=Sites,CN=Configuration,DC=Domain,DC=com (with trans & hosting NC) are bridgehead candidates.
Site(1) CN=SiteC,CN=Sites,CN=Configuration,DC=Domain,DC=com
-1:0:0, 0:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0
All DCs in site CN=SiteC,CN=Sites,CN=Configuration,DC=Domain,DC=com (with trans & hosting NC) are bridgehead candidates.
Site(2) CN=SiteG,CN=Sites,CN=Configuration,DC=Domain,DC=com
-1:0:0, -1:0:0, 0:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0
All DCs in site CN=SiteG,CN=Sites,CN=Configuration,DC=Domain,DC=com (with trans & hosting NC) are bridgehead candidates.
Site(3) CN=SiteF,CN=Sites,CN=Configuration,DC=Domain,DC=com
-1:0:0, -1:0:0, -1:0:0, 0:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0
All DCs in site CN=SiteF,CN=Sites,CN=Configuration,DC=Domain,DC=com (with trans & hosting NC) are bridgehead candidates.
Site(4) CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=Domain,DC=com
-1:0:0, -1:0:0, -1:0:0, -1:0:0, 0:0:0, -1:0:0, -1:0:0, -1:0:0
All DCs in site CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=Domain,DC=com (with trans & hosting NC) are bridgehead candidates.
Site(5) CN=SiteE,CN=Sites,CN=Configuration,DC=Domain,DC=com
-1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, 0:0:0, -1:0:0, -1:0:0
All DCs in site CN=SiteE,CN=Sites,CN=Configuration,DC=Domain,DC=com (with trans & hosting NC) are bridgehead candidates.
Site(6) CN=SiteD,CN=Sites,CN=Configuration,DC=Domain,DC=com
-1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, 0:0:0, -1:0:0
All DCs in site CN=SiteD,CN=Sites,CN=Configuration,DC=Domain,DC=com (with trans & hosting NC) are bridgehead candidates.
Site(7) CN=SiteH,CN=Sites,CN=Configuration,DC=Domain,DC=com
-1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, 0:0:0
All DCs in site CN=SiteH,CN=Sites,CN=Configuration,DC=Domain,DC=com (with trans & hosting NC) are bridgehead candidates.
What's the output you're getting when running the following
adfind -config -f "(&(objectCategory=siteLink)(siteList=cn=SiteF,cn=Sites,cn=Configuration,dc=domain,dc=com))" name
on the DC in SiteF and the bridgehead in SiteA?hth
Marcin
adfind -config -f "(&(objectCategory=siteLink)(siteList=cn=SiteF,cn=Sites,cn=Configuration,dc=Domain,dc=com))" name
Using server: SiteAserver1.Domain.com:389
Directory: Windows Server 2003
Base DN: CN=Configuration,DC=Domain,DC=com
dn:CN=DEFAULTIPSITELINK,CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=Domain,DC=com
>name: DEFAULTIPSITELINK
dn:CN=SiteBIPSITELINK,CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=Domain,DC=com
>name: SiteBIPSITELINK
dn:CN=SiteFIPSITELINK,CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=Domain,DC=com
>name: SiteFIPSITELINK
3 Objects returned
The results are the same when run on the server at Site F.
Thanks for taking the time to look into this. While the manually created connection objects seem to be keeping the servers in sync, I'm concerned about the implications for the DFS I was planning to add, as well as the issues I mentioned earlier regarding logins from sites with no local server.You have three site links which SiteF belongs to - including DEFAULTIPSITELINK. Based on your description of the network topology, there should be only two. Revisit your AD site links and remove redundant one...
hth
Marcin- I'm not sure why there would only be two. As I stated above, there are two sites which can see all other sites. Site A (Which was never renamed from DefaultFirstSiteName) and Site B. Therefore, having Site F belong to the site links for those is correct.
Site F also belongs to the sitelink object for its own site. Is this the one that should be changed? This doesn't sound right to me. If I remove site F from "sites in this link" for SiteFIPSITELINK, how will that site link know that it is linking the other two sites to site F (since I could easily rename the object to SomeUnknownSiteIPSITELINK)
Perhaps I've misunderstood how site link objects should be configured (and the documentation I was using is at the office, so I won't have access to it until Monday or Tuesday). What I have now is a site link object for each site (which, to the best of my knowledge, were created automically by AD. I have only edited the site lists on each, as our topology was changed several months ago). Each of those site link objects has listed in "sites in this link" all sites which can communicate with that site and the site itself. If this is wrong?
Thinking about this a bit further, the site link objects for site C, D, and E contain somewhat redundant information, as these sites all link to the same set of sites. That is, SiteCIPSITELINK and SiteEIPSITELINK both contain the same list of "servers in this site". Would I be correct in thinking I only need a single site link object to cover those three sites?
Site F (and G and H) are unique, but would be covered by the site link objects for Sites A and B. Would that be the right way to do it? Once again - your AD site/site link design should reflect your underlying physical network topology.
In particular, you stated that site F can communicate only with sites A and B. If so, there should be, at most, TWO site links, namely:
- site link between site A and F
- site link between site B and F
If these three sites are not using point to point connections, but instead rely on solutions such as MPLS, then it might make sense to create a single site link among three sites.
The same principle should apply to all other sites/site links.
hth
Marcin- Marked As Answer byMichael J McNally Sunday, November 08, 2009 2:37 PM
- Everything is up and working now. Thanks for the assistance!
Your last post made me realize that the topology changes we implemented several months ago made several of the site link objects which had been auto-created redundant. I never looked at these connections until last month, but apparently the kcc was unable to autodetect the changes and delete the redundant objects. My changes to the existing site links made things worse.
I deleted them and rebuilt from scratch. I now have four site link objects rather than one for each site. I had it backwards when I said "Site F (and G and H) ... would be covered by the site link objects for Sites A and B." I created separate site link objects for F, G, and H, and fourth to cover the C, D, and E. SItes A and B are linked in each of the four.
Incorrect site connection objects are no longer being created, and the kcc added new working connections between C, D, and E. 1311 errors are no longer appearing. Thanks again for all your help.
