3

I am in the process of changing servers in the system from Server 2012 R2 to Server 2016. For the DC's, I presume the best plan is to:

create a `new 2016 DC`
replicate from the `current primary 2012 R2 DC`
transfer the primary roles to the `new 2016 DC`
then decommission the `2012 R2 DC` that is being replaced.
then create a new 'backup 2016 DC'

However, as I start this process my current backup 2012 R2 DC has so many problems I want to simply remove it from the domain since it is going to be replaced anyway.

I have seen many guides for removing a DC but it's not clear to me what is actually happening. Am I to assume the DC being removed in these guides is by necessity speaking about a backup DC? I assume this since removing the last DC ends the domain, right?

The reason I'm asking this question is that I initially want to get rid of the messed up backup DC so that I can get the primary DC back into good health and ready to replicate to my new 2016 DC. I am concerned I won't be able to repair the current primary DC if it retains any artifacts of its relationship with the currently messed up backup DC. I have noticed when I run dcdiag on the current PDC, it hangs up if the BDC is not at least online. That causes my concern that the primary DC won't be able to be fixed if I don't remove all connections to the messed up BDC.

Hence my question, how do I make sure the backup DC is decommissioned completely and the remaining primary DC is once again 'stand alone', i.e. all remnants of its relationship to the BDC are removed.

My DC's run everything: ADDS, DNS, DHCP

(This is kind of a follow-on post from here)

Improve this question
3
  • Just for clarification purposes, outside of the FSMO roles which, out of necessity, only ever reside on one DC (though usually not all on the one DC), there is no such thing as a primary or backup DC (that terminology died with NT4). AD has always been multi-master where they're all authoritative.
    – Greg W
    Aug 5, 2017 at 8:23
  • Thanks for that clarification; I guess I actually understand the concept behind your comment, I just don't know the proper terminology to use to describe the relationship between 2 domain controllers when there are only 2. When I look into the data held in what I guess is the FSMO holder, I see references to the other DC. If I simply decommission the other DC, will references to it be automatically removed from the first DC, or will I be stuck trying to 'clean out' the FSMO folder before I can add my new DC for replication to it?
    – Alan
    Aug 6, 2017 at 13:52
  • It's best to transfer the FSMO roles off the DC to be demoted prior to demotion rather than demoting it and forcefully seizing the roles. (To be honest, I'm not sure if a graceful demotion does that automatically or if you're prevented from going through the process until they're transferred either)
    – Greg W
    Aug 6, 2017 at 20:45

1 Answer 1

Reset to default
3

This question is very broad and lacks focus - so it's hard to answer. But I'll try, by breaking it down into small pieces.

How do I 'disconnect' a backup DC from the primary DC?

This process is known as "Demotion." You demote the domain controller to get rid of it. In the past, this was done with dcpromo.exe. Today, you do it either with PowerShell Uninstall-ADDSDomainController or with the Server Manager GUI.

You always want to prefer a "graceful" demotion. That is, a demotion where all the required network connectivity and AD replication is working so that the secondary domain controller can inform the other domain controllers in the domain that it is being demoted.

But sometimes, if network connectivity is disrupted or if replication is broken such that the domain controller that you wish to demote cannot communicate with the other DCs, then you'll have to "forcefully" or "ungracefully" demote the DC. This was done with dcpromo.exe /forceremoval in the past, but in newer OSes you use the -Force parameter with the aforementioned PowerShell cmdlet, or check the "Force removal" option in the Server Manager GUI.

The downside to a "forced" or "ungraceful" DC demotion is that it leaves metadata in Active Directory on the rest of the DCs that must be cleaned up manually. This is because the other DCs did not know that the decommissioned DC was demoted -- it just "disappeared." But that's OK -- cleaning up old domain controller metadata is a well-documented process that you needn't be afraid of.

I presume the best plan is to:

create anew 2016 DC replicate from thecurrent primary 2012 R2 DC transfer the primary roles to thenew 2016 DC then decommission the2012 R2 DCthat is being replaced. then create a new 'backup 2016 DC'

I'm not sure this is the best plan. It sounds to me like after executing this plan, you're going to have to manually reconfigure all the clients on your network to use the new IP addresses of the new domain controllers as DNS resolvers. Maybe not a big deal if you have 10 clients. But a much bigger deal if you have 1000+.

However, as I start this process my current backup 2012 R2 DC has so many problems I want to simply remove it from the domain since it is going to be replaced anyway.

What kind of problems? This kind of statement scares me, because it demonstrates that we don't understand our environment well enough to be able to describe the state it's in. And without that knowledge, it's hard to know what actions to take and what actions to avoid.

I have seen many guides for removing a DC but it's not clear to me what is actually happening. Am I to assume the DC being removed in these guides is by necessity speaking about a backup DC? I assume this since removing the last DC ends the domain, right?

As I described earlier, when you demote a domain controller, it removes the DCs metadata from Active Directory. Things like replication connection objects, DNS records, ntDSDSA (NTDS Settings) objects, etc. This happens automatically in a graceful demotion. In a forced removal, you have to clean it up yourself.

Yes, removing the last domain controller from a domain eliminates the domain from existence.

In a multi-domain forest, this also requires the same connectivity from the child domain to the parent domain. You have to inform the parent domain that the child domain is going bye-bye.

I am concerned I won't be able to repair the current primary DC if it retains any artifacts of its relationship with the currently messed up backup DC.

Again, I'm worried you may be putting the cart before the horse. We don't know what these "problems" you speak of are, but it's probably a better idea that you get your AD domain back into working order first before you set out re-architecting it.

Hence my question, how do I make sure the backup DC is decommissioned completely and the remaining primary DC is once again 'stand alone', i.e. all remnants of its relationship to the BDC are removed.

I would first attempt to demote your secondary domain controller gracefully, and then verify on your extant domain controller that the NTDS Settings object from the decommissioned DC is gone and that you've no egregious errors from dcdiag or in your Directory Services log.

If the DC can't be demoted gracefully, then force it, and cleanup the metadata yourself using the procedure I linked to earlier. If you have more than 1 DC left after the demotion, make sure replication is healthy and complete before proceeding to re-promote any new DCs. (If you've only 1 DC left, then there is no replication.)

Be quick about it, but not so hasty that you make a mistake. Running with just a single domain controller is risky so you want to get that secondary back up and running.

HTH

Improve this answer
2
  • Was unable to fix & gracefully demote secondary DC so forced it & your checklist link worked perfectly. Thx! The lone remaining DC ADDS/DHCP/DNS works correctly. Initially, dcdiag had a few test failures but they cleared on their own except for failed DFSREvent. I'm a little unclear on this error as it seems indirect, pointing me to the events log. I don't see anything significant there but may later post those errors in a different post & will link from here to perhaps get your view of those errors. For now I am moving on to add a secondary DC.
    – Alan
    Aug 7, 2017 at 22:06
  • WRT your comment about having to reconfigure all the clients, I thought I would ask about this: If I bring up the new secondary DC (say DC02), transfer the FSMO roles from the extant primary DC (DC01), then demote that DC (DC01), could I then change the IP address of the new FSMO role holder (DC02) and eliminate the need to change any IP settings in the clients? Or am I missing a key issue here? As an aside, in my system I really do have fewer the 10 clients, but that's not really the point when it comes to understanding this issue in case it comes up later in a larger network.
    – Alan
    Aug 7, 2017 at 22:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .