Sites and Services Connection Not Generating Automatically As It Should

We are currently using a Windows 2003 GCS in a Windows 2008 R2 Enterprise Domain for LDAP Queries on a critical application (I know. I know.  Working with the Vendor to get that removed.).  Making matters more difficult, it's a Hyper-V Windows 2003 GCS on a Windows 2008 Standard Host Machine.  A while back, something corrupted on the Windows 2003 GCS of which required a roll-back in Hyper-V.  A known issue with Hyper-V is that sometimes when you do that to a GCS, it corrupts the AD Database over time.  Sure enough, that's exactly what happened.  Ultimately, the only thing I could do to resolve that issue was to completely rebuild AD on the Windows 2003 GCS.  I did have to force the DC Demotion as since the Windows 2003 GCS had a corrupted database, the other GCSs refused the updates that the Windows 2003 GCS tried to send before it got demoted.  This meant that I had to remove it manually from AD, DNS and Sites and Services on the Forest Domain Controller.  Rebuilding AD in the Windows 2003 GCS went very well but somehow the Windows 2003 GCS is not creating an automatic connection to our Windows 2008 R2 Enterprise Forest Domain Controller (FDC) and vice-versa.  On both of those Servers, replication is automatically generated with all other available GCS but not with each other.  However, it did before.  Not a critical issue as replication does occur but it would be nice if all replication could automatically happen at the FDC.  I double checked that the Windows 2003 GC is listed as a GC in Sites and Services and it is.  I also ran the following command where I put in my domain in place of "testenv" from the FDC and the response showed that the Windows 2003 GC is very much recognized as a DC:  "nltest /dclist:testenv.local".  Again, AD is working just fine on the Windows 2003 GCS and replication is occurring automatically between the Windows 2003 GCS and all of the other GCs of which are Windows 2008 R2 Enterprise or Windows R2 Standard or Windows 2008 Standard, just not with the FDC and vice-versa.  It's just weird.  Please help.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Will SzymkowskiSenior Solution ArchitectCommented:
Few questions...
- Are all of the DC's part of the same Default-Site-Link?
- Is there an actual network connection between these 2 servers (ping), that do not have a connection via sites and services?

When you are using the KCC (knowledge consistency checker) this mechanism creates the connections it requires and these connections are made based on a few elements..
- network latency
- resource load
- dc location (AD Site)

It is very possible that you had automatic connections to this DC before because the KCC (at that time) thought it was the best machine to make the connection to. When the KCC polling interval runs it analyzes the connections, resources etc and if it feels it needs to change the direct connections to be more efficient it will.

As long as your 2003 GC is getting replication updates from another DC within the same site replication is working as it should be.

The only other thing that I can think of is this server was the bridgehead server for the site that it was in. You only want to have 1 bridgehead server per AD site.

XailonAuthor Commented:
Hey Will,

(1) Yes.

(2) I'm going to say no as I can not only PING IP Address between the FDC and the Windows 2003 GC and vice-versa but I can get name resolution PING.

Although I tried to be as detailed as possible, I realized that I left out that the FDC works on a 10.12.3.x Network and the Windows 2003 GC (I'm working on this as well) as well as its Host Server works on a 10.11.1.x Network.  The only reason I didn't think that could be an issue before because another GC that works on the 10.12.3.x Network developed an automatic connection to the Windows 2003 GC.  Again, it just seems to be the FDC to the Windows GC and vice-versa that will not generate an automatic connection.  However, you did mention about "best paths" and when I think how we're converting our Switches, Routers and Servers to the 10.12.3.x Network Scope, the FDC and the Windows 2003 GC may have simply thought that the other two GCs, one of which is still on the 10.11.1.x Network, is just a more efficient path.
Will SzymkowskiSenior Solution ArchitectCommented:
That assumption would be correct.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2008

From novice to tech pro — start learning today.