<div>
After demoting the dc you also need to perform a metadata cleanup of the dc.<br><br><a href="https://www.manageengine.com/products/active-directory-audit/kb/how-to/how-to-remove-a-domain-controller-that-no-longer-exists.html" rel="ugc">https://www.manageengine.com/products/active-directory-audit/kb/how-to/how-to-remove-a-domain-controller-that-no-longer-exists.html</a>
</div>


RhoSysAdmin

<div>
You can remove DC connections and recreate them by hand. This is sometimes usual to create something like a redundant hierarchie. If you have more than one connection defined, AD can even replicate if one of the DCs is not available anymore. But if you have only one connection, it runs into an error if the related DC is removed.<br>And I guess this was the lack, that you removed the only DC the living one was connected with. <br><br>But even if you recreate them by hand, it makes sense to follow SAIF link to run ntdsutil to make sure your hierarchy is clean. Most issues come up due to tha fact, that nobody takes care about the AD as long as everything is working.&nbsp;<br><br><br>
</div>


<div>
After leaving it be for another two hours, it appears AD has self corrected. &nbsp;I did run through the ntdsutil steps and confirmed there's no lingering data left behind. &nbsp;The demoted server was not listed at all. &nbsp;So thanks for that tip!<br><br>On the redundant connection idea, I thought I read a few years back that with W2K12+ it was recommended to let AD figure out everything on it's own (or is that just with respect to bridgehead servers)? &nbsp;I do really like the idea of redundant connections. &nbsp;When our demotions are complete, we'll have two DC's in each site. <br><br>Is it reasonable to manually create connections like this?<br><br>SiteA-DC1 - SiteA-DC2<br>SiteA-DC1 - SiteB-DC1<br>SiteA-DC2 - SiteB-DC2<br>SiteB-DC1 - SiteB-DC2
</div>


<div>
The lack of manual settings is, that these connection doesn't change automatically. Means the self repair mechanism doesn't work for them. This includes removals.<br>As you can see, the newer DCs are able to reconnect as far as the information is available and as far as a physical connection exist and they can reach each other. So, in this direction you have a kind of redundancy as all DCs are in the AD and that means, each DC has the information which other DCs exist.<br>In this direction it is correct to leave the DCs decide, which connection they use because they even decide according their infrastructure. That means they prefer DCs with a faster connection (in easy words). <br>The distribution hierarchie may be sometimes different, what can have something to do how the infrastructure is constucted. This can be the case, if the automatic configuration will choose a connection chain, which is more in a line than in a star configuration, what would have the effect, that it can take longer to distribute AD changes to the end of the chain. <br>So, it is worth to see, how windows builds up the chain out of its own logic. And then you may have to decide, if this is what you wish to have.&nbsp;<br>The base idea of redundant connection was born in a time, when DCs didn't had this capability to make sure that replication works even when one DC is not available anymore. Also a reason in the past was to avoid replication issues due to line outages. So if there is a fallback line, (i.e. to a different location), it can make sense to add a second connection to a DC on this second location.<br><br>On the other hand, if a DC has an outage, a client can take any other available DC, and also with a line outage, a local DC continues to work. &nbsp;<br><br>&nbsp; <br>&nbsp;
</div>


<div>
<div class="content wysiwyg-content fr-view">
We demoted a (W2K12) DC this evening. &nbsp;The problem is that the (W2K12) DC in our remote site used that (demoted W2K12) DC as it's replication connection between the two sites. <br><br>All connections are automatically generated. &nbsp;The W2K12 DC was demoted more than 2 hours ago. &nbsp;I was hoping AD would self correct by now. &nbsp;Is that a mistaken assumption on my part? &nbsp;<br><br>[From ADSS] I tried a topology check from the W2K12 DC at the remote site in hopes it would pick one of the other (newer W2K19) DC's here at my main site. &nbsp;But nothing had changed yet.<br><br>When I run ADSS from a W2K19 DC in our main site, the connection with the demoted W2K12 DC is shown as "Invalid". &nbsp;At the remote site, the W2K12 DC there that's trying to talk to it doesn't realize it's invalid. &nbsp;<br><br>There's a newer W2K19 DC at the remote site that's talking to one of my newer W2K19 DC's here at the main site. &nbsp;So they're all connected. &nbsp;<br><br>Should I manually delete the "invalid" connection? Or should I wait a bit and see if AD deletes it?<br><br><br>
</div>
</div>



We demoted a (W2K12) DC this evening.  The problem is that the (W2K12) DC in our remote site used that (demoted W2K12) DC as it's replication connection between the two sites.
All connections are automatically generated.  The W2K12 DC was demoted more than 2 hours ago.  I was hoping AD would self correct by now.  Is that a mistaken assumption on my part?  
[From ADSS] I tried a topology check from the W2K12 DC at the remote site in hopes it would pick one of the other (newer W2K19) DC's here at my main site.  But nothing had changed yet.
When I run ADSS from a W2K19 DC in our main site, the connection with the demoted W2K12 DC is shown as "Invalid".  At the remote site, the W2K12 DC there that's trying to talk to it doesn't realize it's invalid.  
There's a newer W2K19 DC at the remote site that's talking to one of my newer W2K19 DC's here at the main site.  So they're all connected.  
Should I manually delete the "invalid" connection? Or should I wait a bit and see if AD deletes it?

Demoted DC left behind broken connection to DC in remote site.

Windows Server 2019

Windows Server 2012 is the server version of Windows 8 and the successor to Windows Server 2008 R2. Windows Server 2012 is the first version of Windows Server to have no support for Itanium-based computers since Windows NT 4.0. Windows Server 2012, now in its second release (Windows Server 2012 Release 2) includes Foundation, Essentials, Standard and Datacenter, and does not support IA-32 or IA-64 processors.

Windows Server 2012

Active Directory (AD) is a Microsoft brand for identity-related capabilities. In the on-premises world, Windows Server AD provides a set of identity capabilities and services, and is hugely popular (88% of Fortune 1000 and 95% of enterprises use AD). This topic includes all things Active Directory including DNS, Group Policy, DFS, troubleshooting, ADFS, and all other topics under the Microsoft AD and identity umbrella.