Replication issue at remote site - Broken Secure Channel?

Hi All, I was recently asked to resolve a sporadic replication issue at one of our remote offices.  This office previously had a single domain controller, but it was having trouble so someone installed a second domain controller and later shut down the "original-DC".  Bringing the original-DC back up resolved replication for a few days, but it's broke again.  Automatic site-link bridging is enabled and intrasite replication appears to be using the original DC as the site bridgehead.  After quite a bit of troubleshooting, it appears to me that the original DC has a broken secure channel with the domain, which is likely causing the replication issue to/from this site (replication between all other sites works fine).  When I ran "nltest /server:Original-DC /sc_verify:our-domain", it failed.  Running the same against the new DC at that site or other DC's at other sites is successful.  The latest issue is that I can no longer login to Original-DC.  I think this occurred when a colleague recently attempted to demote the server and removed the DNS, DHCP and global catalog role (the remaining server is also enabled as a global catalog).  The demotion failed since replication is broken and although the server is up and running, we can no longer login to it.  At this point, there is no reason to keep this server as a DC, but I need to figure out how to cleanly demote it and ensure that replication is working properly via the surviving site DC.  I tried running "nltest /server:Original-DC /sc_reset:our-domain"" from the working DC, but it failed with "ERROR_NO_TRUST_SAM_ACCOUNT"
Any thoughts?  Thanks!!          
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.

Mike KlineCommented:
What you are going to have to do now on that DC is a metadata cleanup (you do that from a good DC)

If you could log in you could have used dcpromo /forceremoval which would force the demotion without attempting to replicate changes (and put it in a workgroup)

Since this is a remote office I assume the box didn't hold any FSMO roles.



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
dkrautAuthor Commented:
Hi Mike,  thanks for the info/link.  No FSMO roles on this box.   Since the other DC at that site is out of the loop with regards to replication, would you suggest doing the cleanup from a DC at our main site?  Also, since the orphaned DC at that site will likely believe that the "original-DC" bridgehead still exists after cleanup, how will replication to/from that site occur?  

dcpromo /forceremoval

check this link
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
Active Directory

From novice to tech pro — start learning today.