After decommissioning the old domain controllers, one final polish step can make your migration airtight: reassigning the IP addresses of your legacy DCs to the new ones. This isn’t required for Active Directory to function correctly, but it can eliminate surprises from hardcoded references to old DC IPs in firewalls, scripts, monitoring tools, or the memory of seasoned admins.

Planning IP Reassignment

Assume:

• DC2016-1 had IP 192.0.2.10
• DC2016-2 had IP 192.0.2.11
• DC2025-1 has IP 192.0.2.20
• DC2025-2 has IP 192.0.2.21

We now want to give DC2025-1 the 192.0.2.10 IP and DC2025-2 the 192.0.2.11 IP. Before doing so, ensure the old DCs are shut down to avoid IP conflicts.

Executing the IP Change

1. Prepare for Change

Downtime is usually unnecessary, especially with multiple DCs in place. Still, a maintenance window is helpful.

2. Change IP on DC2025-1

• Open network adapter settings.
• Set static IP to 192.0.2.10.
• Adjust DNS settings: use itself (127.0.0.1 or its IP) as primary, another DC as secondary.
• Test connectivity with a ping.

3. Update DNS Records

• Check the contoso.com zone for updated A record.
• Remove stale A record for DC2016-1.
• If hostname reuse is not involved, there is no need to alias the old name. If needed, use a CNAME or temporarily add a DNS alias.

4. Repeat for DC2025-2

• Assign 192.0.2.11.
• Update and validate DNS records.

5. Reverse DNS Update

• In the in-addr.arpa zone, update PTR records to reflect new hostnames or remove if not required.

6. Notify Network Team

• If firewall rules, ACLs, or monitoring tools reference the old IPs, verify everything aligns with new assignments.

Testing After Reassignment

Ping Domain and DNS Test

• ping contoso.com should return a new IP.
• Use nltest /dsgetdc:contoso.com to verify DC discovery.

Log Review

• Check Event Viewer on the DCs for DNS or NetLogon registration errors.
• Confirm A and SRV records were updated in _msdcs zone.

Admin Tip

Changing the IP triggers NetLogon and DNS updates. Clients querying DC info will receive new IPs quickly. Cached info clears naturally over time, providing graceful fallback for clients or services not yet updated.

Optional: Hostname Reuse (Not Recommended)

We avoided reusing hostnames. While technically possible, it introduces complexity:

• You must manage SPNs for Kerberos to work with CNAME aliases.
• Risk of conflicting servicePrincipalName attributes.

If necessary, add CNAME records and register old names as SPNs. Otherwise, focus on IP reuse.

Real-World Insight

In one case, IP reassignment solved a firewall routing issue. Remote clients were only allowed to reach the old DC IPs. When the new DCs took over those IPs, everything began functioning as expected.

Wrapping Up

Your new DCs are now indistinguishable from the old ones—they have the same roles, IPs, and cleaner environments. We’ve set the stage for a fully transitioned AD. Next, we configure proper NTP settings on the new PDC Emulator to ensure time sync stability.

Onward to Part 8: NTP Configuration and Time Service Alignment!

Cristal Kawula, Checkyourlogs.net