Advice on reinstalling Domain Controller

Hi All,

We have a number of servers which currently boot from SAN, we need to basically reinstall the OS onto local disc rather than using the SAN...

I could do with confirmation on how to do this with the domain controller. We have 2 DC's so that's not an issue.. The way I see it I would need to:

1. confirm replication works between the 2 DC's (the plan for this is to just shut down the DC and ensure everything still works using the other DC)
2. move FSMO roles to the other DC
3. Demote the DC
4. Would the DC object need deleting from AD?
5. Install OS on local storage
6. Install AD and add as a domain controller (to the same domain)

Not sure if number 3 needs to be done or if the DC can be added to the same AD object? Anything I have missed?

Thanks

Find more posts tagged with

Comments

Abi4IT

Is this all virtualized environment?
How do you back up the current infrastructure?

joeswfc

Abi4IT wrote: »

Is this all virtualized environment?
How do you back up the current infrastructure?

No it's physical, we take monthly backups using dell netvault.

poolmanjim

I'd start by deploying the new DCs. You can promote them to be domain controllers while your others are still running. Then you could gracefully transfer the roles to them and demote the original servers.

If you are wanting to recycle the existing DC names, make sure you have a really good reason. If the reason is because you host files on your DCs, get the files off the DCs. Otherwise if it is because specific services point towards your DCs, configure CNAME records to fake the names.

My overall process
1. Make sure you have a system state backup of everything. Everything.
2. Verify Replication Between existing DCs (dcdiag /q)
3. Promote DC3 and DC4 as domain controllers. Modify your DHCP configurations to use these servers as your DNS servers. You may want to wait a day or two depending on your lease times for the leases to clear out.
4. Move FSMO roles to DC3/DC4
5. Check domain health (dcdiag /q)
6. Wait 24 Hours.
7. Demote DCs.

There are some optional steps of creating a second AD Site, placing the to-be-retired DCs in that site so clients don't auth to them and make sure you don't have any connections to them.

joeswfc

poolmanjim wrote: »

I'd start by deploying the new DCs. You can promote them to be domain controllers while your others are still running. Then you could gracefully transfer the roles to them and demote the original servers.

If you are wanting to recycle the existing DC names, make sure you have a really good reason. If the reason is because you host files on your DCs, get the files off the DCs. Otherwise if it is because specific services point towards your DCs, configure CNAME records to fake the names.

My overall process
1. Make sure you have a system state backup of everything. Everything.
2. Verify Replication Between existing DCs (dcdiag /q)
3. Promote DC3 and DC4 as domain controllers. Modify your DHCP configurations to use these servers as your DNS servers. You may want to wait a day or two depending on your lease times for the leases to clear out.
4. Move FSMO roles to DC3/DC4
5. Check domain health (dcdiag /q)
6. Wait 24 Hours.
7. Demote DCs.

There are some optional steps of creating a second AD Site, placing the to-be-retired DCs in that site so clients don't auth to them and make sure you don't have any connections to them.

Hi poolmanjim!

I only actually need to rebuild 1 domain controller... Basically we have a live site and a DR site, the live site is physical and DR is virtual. So I only need to rebuild the live one, as DR cannot have local storage to move to.
For this reason, I don't actually need to put 2 new DC's into the environment, as 1 DC will not be getting touched.
I just need to rebuild the live domain controller (on the same hardware).
The way I see it, it should just be as simple as:
Demote the domain controller (The rebuilt DC will have the same name as it currently has, so do I need to remove the object from AD or is it best to connect it up to the same object?)
Rebuild the domain controller, install AD and promote it to be a DC in the existing domain (linking it up to the DC in DR)
Along with running dcdiag/repadmin, I am also planning on turning the live DC off for a couple of days to be double sure that replication is working as expected.
Any more advice would be great

poolmanjim

Just a couple of preliminary -- please do these things -- thoughts. First, make sure EVERYTHING is backed up. I mean everything. System States of all your DCs. Second, if you don't have an on-site MS rep, make sure that you are ready to fork out some cash to Microsoft if something goes south. Whenever doing anything with DCs other than daily tasks, I suggest being ready to reach out to Microsoft for help.

I'm not really fond of reusing names, especially for DCs. It may be because I have lots and lots of servers and just see them as numbers on a spreadsheet anymore. I suppose you probably have a good reason for wanting to keep it so I'm not going to press that point.

I do advise making sure that if something/someone is directly pointing to that DC that should be undone and made so they point to the domain as a whole (instead of pointing services to dc.contoso.com, point them to just contoso.com it works the same and has a level of HA).

When you demote the DC, its computer account will remain -- it will just be demoted and made to be any old computer object. I suppose its okay to reset the computer account, format the server, reinstall and promote but my fear would be that that SID may linger somewhere. It may be a good idea to delete the computer object (thus destroying the SID).

I originally considered suggesting taking the DC offline for awhile to see if anything used it directly. However, I floundered on it because of replication. Inside a site, DCs are replicating constantly and devices are querying DNS for those DCs. If you simply shutdown the domain control, clients may still try to authenticate to it which will create latency as it will take time for that connection to fail and for them to find a new DC. Additionally, it will throw off your replication topology and cause countless replication errors until this happens. This will make it hard to identify any real problems come time for the demotion as you're going to have hundreds of errors about that DC being unreachable to sift through for the actual errors.

I don't know your environment so my recommendations are based on my understanding and how I tend to work. I work in a large enterprise (400+ DCs) so I have a much different perspective than someone who may work in an SMB where they can't just spin up a new VM or order a new server to replace one.

Good luck.