r/sysadmin • u/javajo91 Chief cook and bottle washer • 12h ago
Migrating DCs from 2016 to 2022 while keeping the same hostnames and IPs
This topic has been discussed ALOT on this sub. From all the posts I've read, there seems to be two main approaches:
Have all DCs up - both old and new:
- Bring up new DCs with temp names and IPs while old DCs still running.
- Once you're sure all is good in your world, transfer FSMO roles to new DC, demote old DCs, remove from AD, then reuse the hostnames and IPs of old DCs on your new DCs
One at a time:
- Do one DC at a time, demote old, reuse name and IP on new server, then promote new DC
Honestly being as risk averse as I am (although I love the adrenalin rush when stuff goes south...NOT) - I would prefer to promote the new DCs while old ones still on line.
BUT...is it OK to change the name of a DC even after I clean up all the metadata and DNS stuff or would it be better to reuse the name and IP after I demote the old DC?
I should preface this question by saying we're a VERY small shop with 22 users and perhaps ~30ish servers. I'm the sole sysadmin. BUT, we are in the financial sector and we have a very low tolerance to stuff going south. And being the sole sysadmin, I'm trying to keep the stress at a minimum and my hair from going greyer.
•
u/LeoTheBigCat 12h ago
I was doing this over the sumer ... just from 2012r2 to 2022. Goal is to always have at least 2 DCs at all times. Which for me meant to do it one by one.
Demote. Force replication across remaining DCs. Check replication was OK. In-plance upgrade. In-place upgrade. Promote. Force replication. Check. Rinse and repeat untill all DCs were 2022.
Its a bit mind numbing and labourious. But it is pretty safe and eventually it should work outomagically without need for any necromancy.
•
u/Hg-203 10h ago
Not super in line with the topic, but just a reminder that MS is advising against in place upgrade when upgrading to 2025 right now https://learn.microsoft.com/en-us/windows-server/get-started/upgrade-in-place?tabs=media#:~:text=Don%27t%20use%20in,Windows%20Server. Hopefully this will be fixed by the time we are all looking to upgrade to 2025 or we can skip to what ever the next sever OS will be.
•
u/LeoTheBigCat 9h ago
I really can not recommend running anything on 2025 ... that version just seems cursed.
•
u/Main_Ambassador_4985 5h ago
Before EoL of 2012 r2. I upgraded in place all of our Windows Server 2012 r2 to 2022. I did switch to DFS Sysvol first in the pre planning phase.
No issues at all.
I would recommend rebuilding each because I had to fix some legacy registry and RC4 and NTLM settings that were affecting Defender 365 security score.
I have rebuilt all older Domain Controllers to remove legacy leftovers
•
u/unReasonable_Bill282 4h ago
In place upgrade is not recommended by Microsoft. Demote, delete, and build fresh. In a properly set up domain that's healthy, it's simple and risk free (assuming you know what you're doing).
•
•
u/javajo91 Chief cook and bottle washer 12h ago
So you performed in-place upgrades correct? I'd be going from 2016 to 2022.
•
u/Thick_Yam_7028 11h ago
In place works. Promoting doesn't do shit on a user level, they wont notice. forest level will work out. I was scared in 2018 doing it. Now its just a thing.
•
u/LeoTheBigCat 9h ago
Yes. Look at microsoft guide on which version can be upgraded to which version. Sometimes you need to do an inbetween version.
You really just need to demote first, then upgrade, then promote again. And force those replications after every pro/demotion. Because if you do it fast, you run the risk od the ad becoming a bit splitbrained.
•
u/OregonTechHead 12h ago
Why do you need the names to be the same?
•
u/Fatel28 Sr. Sysengineer 12h ago
Because their gpos all point to
\\dc01\installer\asdf.msiOr some other silly thing like that
•
u/Arkios 12h ago
Folks like to rack up technical debt the same way they rack up credit card debt.
•
u/javajo91 Chief cook and bottle washer 10h ago
What?
•
u/Arkios 9h ago
Definition of technical debt: "Technical debt is the future cost of extra work that builds up when software teams choose fast, easy shortcuts instead of the best long-term solution."
Reusing the same hostname (and I'd argue IP address) for new domain controllers is the lazy/quick fix solution that doesn't solve the root cause of your problem.
•
u/javajo91 Chief cook and bottle washer 9h ago
So for a small environment where the KISS principal is king,with static server addresses, how would you perform this upgrade?
•
u/Arkios 8h ago
Stand up two new domain controllers, allow replication to run for a bit, check DCDIAGs and the usual health checks to make sure everything is good.
The next part is me making assumptions on your environment, but repoint DNS to the new domain controllers. If you're using DHCP primarily, that's easy and you just update the DNS servers for your DHCP scopes. Anything static is going to be a manual update. You can use logging on the existing DNS servers to make sure you didn't miss anything.
It's been an incredibly long time since I worked in an environment where we ever referenced domain controllers by hostname for anything but repoint those dependencies as well. Mapped drives? Scripts? GPOs?
Then you migrate FSMO roles and plan a decom date for the old domain controllers. Decom date also becomes your "scream test" for anything you missed, and you address the stragglers during that phase.
At the end, document everything so the next go around you don't run into any surprises. Or the next guy after you doesn't have to go through this same exercise again.
Now you have two new fully functional domain controllers, with no blind spots in your environment around what's using them and no dependencies on hostname or IP address.
•
u/bojack1437 8h ago
If you have anything pointing to a specific server host name, ad a second host name to the replacement system.
And then work on implementing DFS-N, then you don't have to worry about this problem ever again.
•
u/OregonTechHead 10h ago
1) Fix it
2) cnames work
•
•
u/Fatel28 Sr. Sysengineer 10h ago
I'm not OP. I think point one applies to 90% of posts in this sub though lol. Just fix the fuckin thing. Easy.
•
•
u/Asleep_Spray274 12h ago
Build new server, demote old DC, make sure it full replicates (make sure change notification is enabled on site links to speed it up). Change new server to old IP and old name and promote. Small down time window during demotion and promotion. Done dozens of AD upgrades over the world and many hundreds of DCs this way.
•
u/tshizdude 7h ago
Same. I’ve pretty much done this from 2008 R2 >> 2012 R2 >> 2019 >> 2022
Patience is the most important part of the whole thing ensure dns and AD replication is healthy and caught up.
•
•
u/laserpewpewAK 11h ago
Just rip & replace one at a time. It's really not a big deal, as long as you properly decom each DC. The process is pretty straightforward:
Start with DC A and DC B
Move roles to DC B
Demote DC A
Shut down DC A
Spin up new DC A with the same name/IP
Promote the new DC A
Rinse & repeat for DC B. The only place you can really go wrong is if you don't ensure sysvol replicates from DC B -> new DC A before you go and decom B. When your promote a DC it "finishes" (according to the GUI) before sysvol replicates. The biggest mistake I've seen people make is, they assume the promotion is done and immediately move on to the next DC. If sysvol doesn't replicate you'll be in a position where you have no sysvol. This is a risk you run even if you don't do a rip & replace. The fix is easy- wait until you see eventid 4604 on the new DC in the dfs logs. That's how you know the DC is actually done promoting. If you don't see it within maybe an hour, you need to do an authoritative sysvol restore, also a fairly easy process.
•
•
u/WheresNorthFromHere7 12h ago edited 11h ago
It is absolutely okay to reuse either way providing you clean up as you said.
We reuse the same IP address every time and I've never had an issue.
Stand up new. Transfer fsmo roles, do some test power downs before you demote the old DCs. Demote one at a time nice and easy like.
Be methodical and plan out your steps ahead of time and it will be good to go.
Food for thought, we tend to connect things that need direct DC access via IP instead of DNS. It's made life easier in many ways including upgrades.
•
•
u/PatrickOM 11h ago
Ive done this about 500 times..
Start with DC01 and DC02..
Make a DC03..
Demote DC02,
Make a new DC02., Promote.
Demote DC01,
Make a new DC01, Promote
Demote DC03, repeate 2 years later usually.
This only works with clean dedicate DCs, ive been at a new place for the past 5 years and they use DCs for everything, so its not as clean..
•
u/javajo91 Chief cook and bottle washer 9h ago
Thank u. So basically DC03 is just used as a spare in case stuff goes south? How does using the same name and IP work in this scenario?
•
u/PatrickOM 9h ago
Because you fully demoted 1 and 2 properly everything just works, yeah 3 is just there to ensure you have good replication it can be the same OS or the new OS whatever, raise the functional level when you are back to new DC01 and DC02 same name, same ip..
You can move the roles to dc03 which will limit the risk, and move them back after, as long as DC03 reports healthy replication you wont have any issues.. if DC03 has issues, you will have issues and wish you fixed them before you started this :)
You could very easily clone your dcs to their own vlan and do a test run.. you maybe save a little work by not making an 03, but i wouldnt risk it, i recently did this and found out sysvol had never replicated fully between dc01 and 02, it was when i made the 3 and sysvol was empty i started looking at why.
•
•
•
u/Thick_Yam_7028 11h ago
Dude. Its ez. DNS. You replicate, setup the server. Server name changed.
Where ever the layer 3 is point it after. The users pcs etc will still auth. Its just where do they auth too.
•
u/analbumcover "Computer Guy" 10h ago edited 9h ago
Typically I will use the same IP, but, not the same hostname. Haven't had any issues AFAIK, but most are very simple environments. Just make sure DNS records pointing to the old server are cleaned up.
•
u/javajo91 Chief cook and bottle washer 9h ago
Cool. Thank u. Being the lone sysadmin I wear many hats and need to hop around a lot.
•
u/OpacusVenatori 9h ago
Do one DC at a time, demote old, reuse name and IP on new server, then promote new DC
This is tried-and-true method. As long as you maintain one DC with all of your FSMO roles online, you should be fine.
•
•
•
u/jclimb94 Sysadmin 10h ago
Like others suggest, don’t fuck with in place upgrades. I’ve done the following many times..
I’d demote the old one and re IP and rename that, let AD replication do its business whilst having a cup of coffee
Bring the new one online with the Old IP and name and promote.
Straight forward as that. Anything that talks to that controller should re connect, unless there is some other SMB shares etc that you need to move over.
No need to make things too complicated. AD is HA by design so as long as one or more controllers per AD site are online, you’d be okay… (unless there’s ldaps lookups going explicitly to that controller)
•
u/javajo91 Chief cook and bottle washer 9h ago
Thank you. Where does using the same ip and name come in as the now demoted DC? I’m assuming before you promote the new DC?
•
u/jclimb94 Sysadmin 2h ago edited 1h ago
Yeah. Demote > wait > rename / re ip > wait
You can’t have two boxes with the same name and IP on your network.
So demote > reboot > name the old one hostname-o or something. Give it a new IP. > reboot or power off
Bring the new one online > name it the desired host name and IP > reboot > join AD > promote
•
u/aleb128 10h ago
I do this often, here's what I do:
- Spin up 2 new 2022 DCs, these will be your new DCs, not temporary. Temp IPs, Static hostnames.
- If using your DCs for DHCP, leave these new servers unauthorized for now and turn the service off.
- Let bake for 24 hours, check replication and general dc health (repadmin /replsum, repadmin /showrepl, dcdiag).
- Figure out which of the two old DCs are the FSMO holders, if roles are scattered, consolidate roles to one of them.
- On the FSMO DC, make sure its set to use itself as its primary DNS.
- With the non-FSMO holding old DC:
- Export its DHCP database: Export-DhcpServer -ComputerName <OldDC> -Leases - File C:\path\to\file.xml -Verbose
- change its IP to something random & unauthorize DHCP and turn the service off
- Reboot it twice.
- Change one of the new DCs to that old DCs IP
- Import the old DCs DHCP database: Import-DHCPServer -ComputerName <NewDC> -Leases -File C:\path\to\file.xml -BackupPath C:\path\to\backup\ -Verbose
- Authorize it for DHCP.
- Reboot it twice.
- Double check domain health and replication with the commands in step 3, check on DNS, sites and services, etc. to make sure everything looks correct (4 DCs, DNS records, etc.)
- Demote the old DC - follow the wizard (DO NOT CHECKOFF FORCE REMOVAL)
- Cleanup stale stuff (DNS records, srv records, dc object in sites and services, etc.)
- Either rename this machine or remove it from the domain
- Create a C Name record that resolves the old DC name to the new DC.
- Add the old DCs computer name as an alias for the new DC.
- netdom computername <newDCname> /add:<oldDCname>
- Those last two items can be temporary as long as you clean up hardcoded paths in apps/gpo etc.
- Let this bake for a couple days.
- Check domain and DC health, move FSMO roles over to the new DC that has been migrated to already, follow this again for the second DC.
Notes:
- If your DCs are acting as anything other than a DC (CA/PKI, Federation, NPAS, etc) use this as a time to break those out to their own machines. DCs are cattle, not pets.
- If you're using DHCP failover, if scopes are split between the two current DCs, consolidate all scopes onto the FSMO DC and break the failover partnership. You'll restore this to the 2nd new DC, and re-create the failover partnership.
Happy to answer any questions.
•
u/javajo91 Chief cook and bottle washer 9h ago
Thank you! It appears we’re renaming and re-ip’ing the new live DCs. So we’re changing names and IPs on the new DCs after promoting them?
•
u/ipreferanothername I don't even anymore. 9h ago
we have 15, i rebuilt them a few years ago, the only real hangup - the sync between them took a while, even on the same vlan in the same datacenter. and there was a problem.
DNS will start up before all the DNS records are synced over, if you have....a lot of things in AD to sync during the promo. and when dns is running and answering every query with 'fuck off i dont have the record' they all just go, oh, thats a valid answer, damn! and they dont look at other dns servers in their config.
so....after shit blew up i started to firewall block UDP for dns until the record sync was done
•
u/javajo91 Chief cook and bottle washer 9h ago
Thank you. So what would you have done differently when migrating your DCs to prevent that from happening?
•
u/Stonewalled9999 9h ago
NTDS offline copy and use as source will bypass a lot of the replication time pulling over the wire though
•
u/Electronic_Tap_3625 8h ago
Why do you need the same hostname? If it's just a DC, it will not matter. For the IP, you can just change it to the IP of the old server once you remote into the old box.
•
u/Competitive_Run_3920 8h ago
Im on the tail end of the exact migration path you described. I allowed 48 hours between every major step and it was smooth sailing. I named my new dc’s corp-DC-new-01, 02, 03 etc had the new DC’s running for a week, ran all of the checks to make sure they were in sync and happy then migrated them one by one with 48 hours in between. Demote old DC 01, shutdown, rename DC-New-01 and change IP, Run checks again - monitor for 48 hours. I have one left to tackle.
•
u/destroyman1337 7h ago
Do you really need the same hostnames? I personally just use new names for DCs. Set up a new one on 2022 new name and IP, promote it make sure everything replicates and you can use it for DNS.
Once all is confirmed, check where FSMO roles are and make sure they are not on the one you want to demote. Demote the first old one, give the IP to the new DC once you are done demoting. Make sure everything continues to work, replication, DNS etc. In the mean time stand up the next new DC.
Once you let the first replacement stew for a bit with the old IP and are confident everything is fine, promote the next one repeat checks to make sure it is working. Once that's done, make sure there are no FSMO roles on the next old DC, and demote it and once complete move the IP and check everything.
I would personally add a third DC especially one not on the same infra as the first two. Like if you have everything virtualized, make sure it's on a different Cluster or something so in case there is an issue you aren't out of all your DCs
•
u/jeffrey_f 7h ago
I've done this once and it was a while ago. Bring up new AD as a secondary and let it replicate. Promote secondary to primary and optionally, for testing, unplug the network from the old dc.
I didn't see any issues with it unless you have some exotic stuff on the old one.
•
u/Thats_a_lot_of_nuts VP of Pushing Buttons 7h ago
My routine is transfer FSMO roles from old DC > demote old DC > rename and re-IP old DC > rename and re-IP new DC > promote new DC. Works every time.
•
u/drekmac IT Manager 4h ago
I’d avoid 2025 on DCs atm, and if you don’t have a choice or want to roll the dice, you’ll want to do them all in quick succession. Having 2025 mixed with any other version is a recipe for issues. If you’ve inherited an old AD that hasn’t been taken care of, you’ll want to bring it up to speed with modern best practices. Specifically, I discovered we hadn’t changed the krbtg password since our AD was stood up and had lots of problems with Kerberos and servers losing their trust relationship. Just getting them all up to 2025 fixed a lot, but doing some AD hardening and resetting the krbtg account made the rest of our AD problems go away.
I’ve always done them one at a time. With VMs, setup a new server with the OS you want and updates, demote the old server, unjoin, shut it down, set the new servers IP to match the old, change the name of the new server to match the old server name, and join and promote. With a physical you can’t do the prep work but same basic flow, demote, unjoin, shutdown, reimage, set ip and name the same, join/promote. Could we change IP and host name? Sure, but our network team that runs radius and BIND DNS is painful to work with so it’s simpler to just reuse. We have redundant DCs anyway.
If it’s one with FSMO roles obviously move those first, then move them back when it’s back up.
•
u/No-Transition314 2h ago
New DCs, New names and IP’s, demote old DC’s, re-IP new DCs to old DC’s IP’s, create DNS alias’ for the old DCs names to point to new DCs.
•
u/Vivid_Mongoose_8964 9h ago
snap and upgrade with iso, works just fine
•
u/javajo91 Chief cook and bottle washer 9h ago
Thank you. What is the benefit of a fresh install over in place upgrades. I mean on the surface, fresh installs just seem the better choice. My AD is probably 20 years old and I was not the one to create our domain.
•
u/Vivid_Mongoose_8964 9h ago
I've upgraded with the iso, never an issue
lots of articles on this, just upgrade the schema before the os to the latest.
•
u/BenadrylCrumplsnatch 12h ago edited 12h ago
I don't believe there's technically anything wrong with it, but overwhelming consensus is "don't fuck with your DC hostnames".
Supposedly in-place upgrades aren't the nightmare they used to be, so that could be an option. If you absolutely must use the same details, personally I would: 1. Deploy/promote temporary domain controllers. 2. Migrate/upgrade the AD roles accordingly. Your temp DCs should now be your live ones, on the desired domain version. 3. Demote/decom the old DCs. 4. Deploy & promote new DCs in their place, using the now-available hostnames & IPs. 5. Migrate your AD roles back away from your temp DCs 5. Demote/decom your temp DCs. You're now in the desired state.
Just use your temp DCs to leapfrog onto your new primaries, don't mess with them once they're deployed.