Troubleshooting Slow Network After Promoting Secondary Domain Controller and Deleting Old Primary Domain Controller

Network performance degradation following a domain controller transition is almost always caused by stale DNS records, improper site topology configuration, or clients still attempting to authenticate against the decommissioned server. When you promote a secondary Domain Controller (DC) and remove the primary, Active Directory replication must complete fully before network traffic can route efficiently. If clients are querying outdated DNS entries for LDAP, Kerberos, or Global Catalog services, they experience significant latency or authentication failures as requests time out waiting for a non-existent responder. The most common culprit in this scenario is that client machines have cached the IP address of the old primary DC. Even after the old server is powered off or removed from the network, Windows clients continue to send authentication packets to that dead endpoint. This results in delayed logins, slow file access, and intermittent connectivity issues across the domain. Additionally, if the new DC was promoted without proper site mapping, it may not be advertising itself correctly to nearby clients, forcing them to traverse unnecessary network hops to find directory services.

Verify Active Directory Replication Status

Before troubleshooting client-side symptoms, you must ensure the new DC has fully synchronized with any remaining infrastructure components. If other servers or backup DCs exist, they must replicate successfully with the new primary. Use the repadmin /showrepl command on the new DC to check the replication health. Look for any errors related to "Access Denied" or "RPC Server Unavailable," which indicate communication blocks between sites. If replication is failing, the new DC cannot serve accurate directory data, leading to slow lookups. Ensure that the firewall allows necessary RPC ports between subnets. Once replication is stable, proceed to check the DNS zones, as this is where the majority of performance bottlenecks occur after a DC swap.

Clean Up Stale DNS Records

Active Directory-Integrated DNS zones automatically register SRV records for domain controllers. When you remove an old DC, these records should theoretically disappear, but they often linger due to aging settings or manual overrides. Open the DNS Manager console on your new server and navigate to the forward lookup zone associated with your domain. Look for SRV records under the _msdcs subdomain. You will see entries like _ldap._tcp.dc._msdcs.YOURDOMAIN.COM. Verify that only the IP addresses of your current, healthy DCs are listed. If you see the IP of the old primary DC, delete those records manually. Also, check the A records for the hostname of the old DC; if they still point to its former IP, remove them to prevent clients from resolving to a dead host. It is also critical to verify that the new DC’s own A record points to its correct current IP address. Sometimes, during promotion, the network adapter changes, causing the DNS registration to fail or point to a previous interface. Right-click the zone, select Properties, and ensure "Dynamic Updates" is enabled and set to "Secure Only" if possible, though standard updates work for internal domains.

Configure AD Sites and Services Correctly

Active Directory uses a site topology to optimize replication and client authentication. If your new DC is in a different physical location or subnet than the old one, it must be mapped to the correct Site in Active Directory Sites and Services. Open the MMC snap-in and expand the Sites container. Check if your subnet is associated with a site that includes the new DC. If the subnet is missing or assigned to a remote site, clients in that subnet will attempt to contact a DC in another geographic region, causing massive latency. Create a new Subnet object if necessary and assign it to the appropriate Site. Then, ensure the new DC is listed in that Site's Servers list. This forces local clients to authenticate locally rather than crossing wide area network links.

Flush Client DNS Caches

After correcting server-side DNS and site configurations, you must force clients to refresh their local caches. Clients store DNS responses for a duration defined by the TTL (Time To Live). Until this expires, they will continue using the old, invalid records. On affected client machines, open Command Prompt as Administrator and run the following commands:

ipconfig /flushdns
ipconfig /registerdns

The first command clears the local resolver cache, while the second forces the client to re-register its own A record in DNS. For bulk remediation, you can use Group Policy Preferences or login scripts to execute these commands. However, immediate relief for individual users requires manual execution or a reboot, which also clears the Netlogon service cache.

Check Netlogon Service Behavior

The Netlogon service handles domain controller discovery. It maintains a database of available DCs based on DNS queries. If the service is stuck with old information, it will not pick up the corrected DNS records immediately. Restarting the Netlogon service on a client can sometimes accelerate the re-discovery process. Run net stop netlogon && net start netlogon in an elevated command prompt. This restarts the discovery mechanism, prompting the client to query DNS again for the _ldap._tcp SRV records. Monitor the event logs on the client for Event ID 5719 or 5774, which indicate successful or failed authentications against specific DCs. These logs help confirm whether the client is now talking to the new primary.

Validate Network Connectivity and Latency

Finally, test the actual network path to the new DC. Use ping to check round-trip times and nltest /dsgetdc:YOURDOMAIN to verify which DC the client selects for authentication. The output should show the new DC’s name and IP. If nltest returns the old DC, your DNS cleanup was incomplete. If it returns the new DC but performance is still slow, investigate underlying network issues such as switch port congestion or faulty cabling, which may have been masked by the previous DC’s presence.

Frequently Asked Questions

Why does my computer take longer to log in after the DC change?

Your machine is likely caching the IP address of the old, offline Domain Controller. Because the server is unreachable, the authentication request times out before falling back to the new DC. Flushing the DNS cache and restarting the Netlogon service forces the client to discover the new server immediately.

Can I keep the old DC running as a backup just in case?

No, keeping the old DC online while it is decommissioned causes severe network confusion. It will advertise itself as a valid DC, competing with the new primary for client connections. This leads to split-brain scenarios where some users authenticate to the old server and others to the new one, causing profile sync errors and security inconsistencies.

How do I know if my DNS records are truly updated?

Use the nslookup command pointing directly at your new DC’s IP address. Query for _ldap._tcp.dc._msdcs.YOURDOMAIN.COM. If the response lists only the new DC’s IP, your DNS is clean. If the old IP appears, you must manually delete the stale SRV and A records in the DNS Manager console.

What if clients are still finding the old DC after flushing DNS?

This usually indicates that the old DC is still physically connected to the network or its IP is hardcoded in static DNS entries. Ensure the old server is completely powered off or disconnected from the LAN. Additionally, check for any DHCP options or static IP assignments on servers that might be bypassing dynamic DNS updates.

Does promoting a new DC affect internet browsing speed?

Indirectly, yes. If your DNS server is also handling public resolution, a misconfigured DC can slow down all internet lookups. However, the primary slowdown comes from internal resource access like file shares and printers. Ensuring your new DC has fast, low-latency connectivity to both internal resources and upstream DNS servers mitigates this.