Demoted DC left behind broken connection to DC in remote site.
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?
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?
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.
And I guess this was the lack, that you removed the only DC the living one was connected with.
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.
And I guess this was the lack, that you removed the only DC the living one was connected with.
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.
ASKER
After leaving it be for another two hours, it appears AD has self corrected. I did run through the ntdsutil steps and confirmed there's no lingering data left behind. The demoted server was not listed at all. So thanks for that tip!
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)? I do really like the idea of redundant connections. When our demotions are complete, we'll have two DC's in each site.
Is it reasonable to manually create connections like this?
SiteA-DC1 - SiteA-DC2
SiteA-DC1 - SiteB-DC1
SiteA-DC2 - SiteB-DC2
SiteB-DC1 - SiteB-DC2
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)? I do really like the idea of redundant connections. When our demotions are complete, we'll have two DC's in each site.
Is it reasonable to manually create connections like this?
SiteA-DC1 - SiteA-DC2
SiteA-DC1 - SiteB-DC1
SiteA-DC2 - SiteB-DC2
SiteB-DC1 - SiteB-DC2
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.
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.
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).
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
https://www.manageengine.com/products/active-directory-audit/kb/how-to/how-to-remove-a-domain-controller-that-no-longer-exists.html