I currently have two domain controllers, DC1 and DC2, running Windows Server 2019. My plan is to add a fresh Windows Server 2022 DC3, transfer the FSMO roles to it, verify replication and domain health, then decommission DC1 and rebuild it as Server 2022. I would repeat the process with DC2, move the FSMO roles from DC3 to the rebuilt DC1, and finally decommission DC3.
I would like to keep the existing DC names, DNS records, and IP addresses because various servers, services, and hardware may reference them directly. DHCP is hosted elsewhere. Before starting, I plan to take a Veeam application-aware backup and run tools such as repadmin /showrepl and dcdiag after adding each new domain controller.
I'm also aware that services relying on certificates issued by the old domain controllers may need attention, and that LDAP, RADIUS, DNS, DHCP settings, and other integrations could require updates. Are there any additional pitfalls, or would a different migration sequence be safer?
5 Answers
You probably only need one FSMO transfer. Add a new 2022 DC, transfer the roles, confirm replication and domain health, demote one old controller, add or promote the replacement, validate again, and then repeat for the remaining old controller. Keeping a temporary third DC is fine, but repeatedly moving the roles back and forth adds unnecessary work.
A fresh installation is generally preferable for a domain controller because it avoids carrying forward old drivers, configuration, unsupported software, and legacy boot settings. In-place upgrades can work, but they are more difficult to troubleshoot if the existing server has historical problems. Server Core is worth considering for new domain controllers because it reduces the attack surface and installed components.
The simplest approach is usually to add two new Server 2022 domain controllers, transfer the FSMO roles, verify replication and DNS, update DHCP scopes and client DNS settings if necessary, and then demote the old controllers one at a time. You can leave the old servers powered off for a short period as a “scream test” before formally removing them. That can reveal systems still using hard-coded hostnames or IP addresses.
This works well as long as services such as DHCP, RADIUS, synchronization tools, certificates, or applications aren’t also installed on the domain controllers. Hard-coded IP addresses and hostnames are the issues most likely to cause surprises.
I’m considering keeping the existing names and addresses because a lot of equipment and services already reference them. DHCP is hosted on a separate Windows server, so that part should be easier.
Make a dependency checklist before changing anything. Pay particular attention to certificate chains and auto-enrollment, LDAP and LDAPS bindings, RADIUS or network appliances, monitoring, backup agents, scheduled tasks, applications with hard-coded addresses, DNS forwarders, and any services that were accidentally installed on the domain controllers. After the migration, rotate the krbtgt password according to Microsoft’s recommended two-step process, allowing replication between changes.
Also confirm that DNS is healthy and that every domain controller is using internal AD DNS rather than an external resolver. Run dcdiag and repadmin /showrepl before and after each replacement, not just at the end.
I would avoid rebuilding new domain controllers with the same names. Use new names such as DC4 and DC5, or another clearly distinct naming scheme. Reusing names can leave behind stale Active Directory and DNS metadata, and it isn’t worth waiting for tombstone or replication cleanup just to preserve a hostname. A clean replacement also gives you a chance to discover and document hidden dependencies.
Aliases can help with applications that expect a role name, but they should not be treated as a universal replacement for correctly configuring LDAP, Kerberos, DNS, certificates, or domain-controller discovery.
Before each demotion, check DNS zones and delegations, SYSVOL and NETLOGON shares, replication status, event logs, time synchronization, and whether clients are receiving the correct DNS servers from DHCP.