Planning server replacement

[HCHTech]

I'm in the planning phase of a server refresh for a client. I would like to get everything setup in my shop before I take it onsite.

• I have a duplicate firewall I can load with their configuration so that the internal network will appear the same as the onsite setup to the new servers while they are here in the shop
• There are 2 host servers, one hosting the DC VM (plus others) and one hosting the Production/Application Server VM, backup DC, plus others.
• I'm replacing their switches as well, so I want to get those pre-configured at the shop, too (VLANs, etc.)

Normally, when replacing a DC, you do it onsite by adding it to the network, syncing AD, then moving the FSMO roles. To accomplish what I want to do, though, I would need to spinup and configure the DC before it gets onto the "real" network, so that the other VMs will use it for DNS, I can get the NICs all configured the way I want, get the VLANs setup, etc. If I do that and add AD, but only create the admin and a couple of test users, can I still later take it onsite and sync to their "real" AD and move the FSMO roles like normal?

I don't do enough of these - obviously. I think my idea is sound, but I don't want to accidentally lay any traps for myself that will cause problems when the equipment actually goes onsite.

 

[YeOldeStonecat]

You'll have to get the "new DC" talking to the "existing DC at the client site" before you can DCPROMO...so that it is replicating active directory, and your new member servers can talk to it. So you'll have to setup a good VPN tunnel and get name resolution working properly through the tunnel.

You cannot create an island of active directory.....when you bring it onsite they will not join/replicate.

I have done that before...but really find no advantage to that. I just build the hyper-v host, install Windows Server...update BIOS/drivers/firmware, update the host OS...copy the ISO's for the guest servers...enable my remote hardware management on the server (iDrac/iLO/etc)...and deliver it onsite. And then I "hatch" the guest OS's (you could do this back at your HQ too)....join the clients AD...and go from there.

 

[HCHTech]

Thanks. I was afraid of that. I'll try the VPN tunnel and see if I can proceed that way. I hope so because If that doesn't work, then I'll need do it the other way by taking everything onsite first -- and THAT means I'll need to replace the switches at the same time as I bring the new servers onsite, before I do final configurations. The new servers & switches all have SFP NICs, while the existing servers & switches are all copper. Fun times ahead!

 

[SAFCasper]

Surely the servers have at least a 1Gb copper port you could use temporarily? I don't think I've ever seen one without. Alternatively just uplink the new switches to the old ones via copper until you are ready to fully swap over. Again might limit you to 1Gb but it's temporary.

Or another thought - do the new servers have enough horsepower and storage to run the existing VM's alongside any new VM's? I'm thinking something like:

- Shutdown all the VM's and grab a backup
- Rip out the old server & switches
- Rack the new servers & switches
- Restore backups to the new servers

You now have a fully functional network and can setup the new VM's remotely at your own leisure.

Depends heavily on how much data they have and how good your backup system is.
- Veeam with 500GB to a good NAS? Easy job
- Windows Server Backup with 2TB to a crappy USB external drive? Hell no you will be there all day.

 

[YeOldeStonecat]

I've done that method also......brought over a new hyper-visor host. And then did a "V to V" or "P to V" migration of the old servers over to the new host, and then done the rest.

The new switches 'n all....shouldn't be any negative impact on the project. Can still pre-configure those at your office, along with the new hyper-V host. And then bring onsite...and begin the fun.

I like standing up new DC(s) along side the old DCs...and slowly switching over the roles. Once new DC is DC promo'd...make its IP the primary DNS that DHCP hands out, with IP of old/outgoing DC as secondary. Give a few days to settle in. And then switch over DHCP, and print server GPOs....demote old DC..but you can still leave DNS server role on it...eventually remote its IP from DHCP scope so that only new DC(s) IP is handed out.

What vintage is old DC, how big is your leap? You going to run into that FRS to DFSR dealio? Give yourself time for that. I'd want my new DC onsite for that introduction and change.

 

[putz]

The best way is to do basic prep of the VMs in office:

• Install Windows.
• Windows updates.
• Configure hostname and static IP
• Install RMM and security software.

But all the role configuration should be done when the servers are connected to the clients network. Creating a 'lab' environment of the clients systems and trying to deploy the servers meant for production into the lab, then later move them into production will not work at all, especially with active directory.

 

[HCHTech]

Ok, point taken. This is a bigger project for me, and I was hoping to minimize the onsite time and pressure that these jobs always have...doing all of the stuff that tends to have little time-sink problems along the way in my shop where time doesn't matter so much and downtime isn't risked or extended. It was a noble goal - haha.

 

[YeOldeStonecat]

... hoping to minimize the onsite time and pressure... It was a noble goal - haha.

Mission Impossible in this career!

 

[HCHTech]

What vintage is old DC, how big is your leap? You going to run into that FRS to DFSR dealio? Give yourself time for that. I'd want my new DC onsite for that introduction and change.

Existing servers are 2012R2, new servers are 2022. There's one bullet I dodged.