Swapping Out Domain Controllers - Part 2

[Alan Coleman]

Thanks for previous answers. I was able to answer a lot of my additional
questions on my own. Now I know exactly what I want to do. I now have 3
existing domain controllers in my domain.

SJV-DC-1 (housing all 5 FSMO roles)
SJV-DC-2 (global catalog)
SJV-BRH (global catalog) (different site in AD)

All are using active directory integrated DNS now.

I'm replacing SJV-DC-1 and SJV-DC-2 and with two new servers and I want
these servers to take their predecessors names.

My plan is to do this.

1. Demote SJV-DC-2, and then remove it from the domain.
2. Name first new server SJV-DC-2
3. Promote NEW SJV-DC-2 to domain controller
4. Transfer all 5 FSMO roles to NEW SJV-DC-2
5. Demote SJV-DC-1, and then remove it from the domain
6. Name second new server SJV-DC-1
7. Promote NEW SJV-DC-1 to domain controller
8. Make NEW SJV-DC-1.global catalog

Will this plan work. It seems like it should. I haven't found any docs on
Microsoft about demoting a domain controller and then promoting another one
with the same name so I'm assuming it's possible. I just want to know if
there is something I should look out for as in, is there some other place
that the active directory might still remember the old servers with the same
names and somehow screw something up? Obviously I'm going to have to allow
for replication time between all of these steps because I still have 1
active DC in this domain plus the DCs in the other domains, but other than
that it seems like this should work.

Insight into anything I'm missing is much appreciated.

 

[Glenn L]

This is a valid plan.
Please make sure you allow adequate time for these changes in each step to
replicate to the remote office DC before proceding to the next step. You
could take advantage of replmon so you do not have to wait the 15 minutes or
whatever you ahev your site link replication interval set at.
You should actually check that the changes replicated before proceding to
the next step.

You should make sure the DC has a DNS entry (on the NIC) pointing to a valid
DNS server.
Remember, during the demotion, the DC will stop hosting the zone.
This is an important consideration for the rest of your client and server
base.
Make sure they have more than one DNS entry so they are not without name
resolution during the brief service interuption.


Also, since this is single domain forest, there is no valid reason not to
make all DCs also GCs.

 

[Alan Coleman]

Thanks,

Also it's not single domain, there are 3, 2 parents, 1 child... so to speak,
but thank you for the answer, just needed to know I wasn't barking up the
wrong tree.

 

[Ryan Hanisco]

This is certainly a valid plan if you had a single domain forest as was the
assumption...

You said that DC-1 had all five FSMO roles including the two Forest-wide
roles. You will probably want to consider moving the Infrastructure Master
and the Domain Naming Master to another server and verifying stability
before you start swapping things around. This will cover you in the case of
something catastrophic happening in this one domain.

Once, you remove that server, you will want to make sure that the DNS from
the parent and children do not reference it. This should just be a
verification, since moving the Forest-level roles should remove these.

You should also verify that the references to the server are completely gone
with ntdsutil if you really want to put another server there with the same
name. You would hate for some part of the forest to expect to see the old
server there, which could lead to wonky replication and trusts.

Finally you should consider the desire to keep the name. Are you doing this
for a technical reason or just because humans like to start with DC1 and
count up? Stability seems most important -- especially when dealing with
something that could impact your entire forest.

Of course, if the server just has the three domain roles, then you're cool.

 

[Alan Coleman]

Actually...

The names are irrelevant to us... the IP addresses are more important to us
than the names (we were just going to name the two new servers SJV-DOMAIN-1
and SJV-DOMAIN-2 so we don't have number issues at all). We do want to keep
the static IP addresses though because a good number of other services and
machines depend on them.