I'm planning to migrate three domain controllers from Windows Server 2016 to 2022. Two of the existing domain controllers also host DHCP in a failover load-balancing configuration. I'd like to move DHCP before starting the domain controller migration, while ultimately keeping the same hostnames and IP addresses for the replacement servers.
My proposed process is to break the existing DHCP failover relationship, export and import the DHCP configuration to a temporary server, complete the domain controller migration, then import the configuration onto the replacement first domain controller and recreate the failover relationship with the second one.
Does that sequence make sense? Would it be better to host DHCP on separate small servers, virtual machines, a firewall, or network switches instead? This is a relatively small environment with about 22 users and 30 servers.
3 Answers
For the long term, I’d avoid running DHCP on the domain controllers if practical. A pair of small Server Core VMs or lightweight servers would make future domain controller work simpler and keep the roles separated. In a small environment, two dedicated DHCP VMs may be more than you strictly need, but they’re inexpensive and make the migration much cleaner.
If your firewall or switching platform supports reliable DHCP and the required reservations, options, and failover behavior, hosting DHCP there is another good option. Just treat it as a network change: document the current configuration, make the change during a maintenance window, and test clients on each relevant subnet. Moving DHCP to a separate service is still preferable to keeping unrelated roles on domain controllers.
A firewall-based setup could work here. I’ll compare that with using small virtual machines before deciding, especially since the network is fairly small.
That migration sequence is reasonable: remove the existing failover relationship, move the configuration to a temporary server, replace the domain controllers, import the scopes and settings onto the first new server, and then configure failover with the second. Export the scopes, reservations, filters, and server options, and verify that a test client can renew successfully before retiring the temporary server. Also make sure the old and replacement servers never use the same IP address at the same time.
Thanks, that was my thinking as well. I’ll make sure to test lease renewal and avoid any overlap while reusing the addresses.
That’s what I’m considering now. Since the environment is small, I wasn’t sure whether two separate DHCP VMs were worth it, but moving DHCP off the domain controllers would simplify the next migration.