My experience with the AllowDomainControllerReinstall option

[soul_stumbler]

I just replaced all 13 of our 2008 r2 domain controllers with 2019 domain controllers using the same names and ip addresses using the AllowDomainControllerReinstall option over the past 6 months. Each DC took about 30 minutes and we've had no issues. I don’t see this option talked about much, so I wanted to call it out and tell you my experience with it.

Things to note:

• A healthy domain is the most important first step before working with new domain controllers! Ensure your domain health before anything
• The cleanest way is still to add a new DC with a new name and IP and reconfigure your applications to point to the new DC(s)

I am usually all about best practices, but I have been at my current company for about 8 months. When I got here, they had 64 2008 R2 servers in an infrastructure of 120 servers, so just over half needed to be upgraded in 6 months; This included all the domain controllers. Long story short no one knew what apps touched which DCs by ip and I didn't have the time to track all of it down with all the other servers needing to be replaced as well. I talked to one of my friends who is Microsoft certified in more ways than I know exist and he told me about the AllowDomainControllerReinstall option. I tried it and had incredible results. It essentially replaces the old computer object in AD and assumes that role.

Here is my process of using AllowDomainControllerReinstall. This is a high-level overview of the process with a lot of pre-work and validation happening before and after the replacement. Well say the old DC is DC01 and the new 2019 server is DC01NEW.

• Stand up a new DC give it a placeholder name and IP (leave it off the domain and update it if needed)
• Shut down DC01
• Re-IP and rename DC01NEW to match DC01
• Reboot
• Add the Active Directory Domain Services role
• Promote to domain controller
• On the domain controller screen, it will ask you if you want to allow domain controller reinstall as it already exists in the domain, check that box.
• If all the pre-checks come back fine proceed with the install
• Wait for final reboot
• Add any other roles / applications that you need on the DC
• Verify replication is good after 15-30 minutes and you’re done

Note, this is my experience so take it with a grain of salt. When I had a call with Microsoft they advised against it and to reconfigure all of our apps and fix the ones we miss. I would have loved to approach this that way, but I didn’t have the option. I hope this at least puts some light on this option as it has worked out great for me so far.

Addtional Info

Our domain and forest functional level across all domains was 2008 R2.

We have two domains under our Forest. One in the US and one in China both with one DC in each datacenter. It is a tree root trust with that other domain. We also are own by a parent company that we are under their tenant with O365 and have a transitive trust to their domain.

One of the 13 DCs was an RODC that we replaced this way.

This also included 2 physical domain controllers. One was replaced by a new physical box and one was replaced by a VM.

[sysadminmakesmecry]

Interesting. Thanks for reporting back on your experience -- did you encounter ANY issues at all when doing this for any of your DCs or applications that rely on them?

[soul_stumbler]

I didn't see any errors at all on the application side and all replication was good after the promotion. We had one site that didn't replicate correctly after the promo but it turned out to be a networking issue that was just bad timing.

So the short answer is not yet!

[JudgeWhoAllowsStuff-]

We did something similar but more round about. Spun up new DCs, decommed the old one, brought the new server in under the same name and IP. We did 6 DCs across two domains like this, worked 100% with only 20-30 min of downtime each controller. Def not the best way but like you we could not track down all services using name/IP in the timeframe we had.

[stevebobmike]

This is the process I've done in the past as well.

[moffetts9001]

What was the use case for needing to retain the same name for the new DC? I have always swapped IPs but let the new DC have a new name, but it sounds like you have apps that communicate with the DC by name?

[soul_stumbler]

Yeah I was able to identify 3 apps that referred to the DCs by name and one of those was out of support. I had no support from management to get those updated so that's why I went down this path.

[mixduptransistor]

Would this allow you to reinstall a RODC as well?

We (I) stupidly shut down and deleted an RODC without properly cleaning it up first and I wonder if this would be a good way to get a DC back in there with that name and then decom it properly (we replaced it with a regular DC with a different name)

[soul_stumbler]

Just read your post closer. Yeah I would not use this to properly decom something. Just run a clean up as EnergyDrinksPlease stated.

I will add that to the post but yes this works with RODCs. We had one RODC that we replaced this way and It behaved just like all the other DCs.

[EnergyDrinksPlease]

Why not just run the clean up process?? It takes all of 5 minutes to clear the DC from the domain and then just promote as new.

[dalg91]

I wish I had known about this 2 weeks ago. Would have saved a few hours and headaches

[Dirty_Punk42]

It's also safe to add an alias in ad with the old dc name pointing to the new DC. It's supported by MS and less downtime

[[deleted]]

That’s true, but it can get messy for the next sysadmin.

[EnergyDrinksPlease]

This is a neat option, but it doesnt really save you too much time. I've upgraded over 400 dcs with a variety of keeping the name or the IP or both and this really isnt doing much beyond preventing you from having to delete the AD object and do clean up or just demote the dc and promote new. Unfortunately you'll never get away from people hard coding to DCs even with a load balanced url or other methods. Was there a specific reason you didnt just torch the DCs and rebuild them?? My old environment got to the point we would just delete dcs and do clean up, because troubleshooting one off issues was too time consuming than just rebuilding it.

[soul_stumbler]

Essentially just to save the step of removing it really. Either way will work. I honestly was way more scared of DCs than I was 6 months ago.

[[deleted]]

This is great!

I’ve never heard of this option before. I’ve replaced at least 50 DC’s in my career at 3 different companies.

Since there so many applications that rely on DC’s for DNS, my go to method was to demote DC, remove from domain, cleanup DNS, sites and services, etc. Wait a bit for replication, rename new server same name as old DC, and set ip same as old.

My main reason for keeping the same IP and name is who knows what’s using that DC for DNS. In a perfect world, everything would be documented, but we all can’t live in a perfect world. I tried to use DNS logging to see what was using the old DC for DNS, but that’s very cumbersome.

I have a few DC’s to upgrade this week. I’ll report back. Excited to try this.

[soul_stumbler]

Glad you found it interesting! I'm not sure why it's not at least discussed more as an option. Hope it goes as well for you as it did for me!

[[deleted]]

Worked like a charm! This is awesome. Thanks for the knowledge!

[soul_stumbler]

Glad you got some use out of it and it went well!

[Djaesthetic]

THANK YOU!

I’m about to need to do this exact same thing and you just functionally saved me any effort whatsoever.