Your network has been running smoothly for weeks, maybe months. Then one morning, you notice something off. User accounts aren’t updating properly, and group policies seem stuck in time. After some checking, you find out your domain controllers stopped talking to each other.
This sync failure can mess up your entire network if left unchecked. Users might not be able to log in properly, passwords could fail to update across the system, and security policies might not apply uniformly. These issues create real headaches for your IT operations and can leave parts of your infrastructure vulnerable.
In this piece, you’ll learn why domain controllers stop syncing, what causes these failures, and practical steps you can take to get everything back on track. You’ll walk away with clear fixes you can try right away.
What Happens When Domain Controllers Stop Syncing
Active Directory relies on domain controllers to share information across your network. Each controller keeps a copy of your directory database, and they constantly update each other about any changes. This process, called replication, keeps everything consistent.
When two domain controllers lose sync, they stop sharing updates. One controller might know about a new user account while the other has no idea that account exists. Password changes on one server won’t reach the other. Your group policies might work on some computers but fail on others because different controllers are giving out different information.
The technical term for this is a replication failure. It happens when the controllers can’t communicate properly or when errors in the replication process pile up. Sometimes it’s quick and easy to spot. Other times, the failure sits quietly in your system for days before you notice anything wrong.
If you leave this problem unfixed, your network starts acting unpredictably. Users report strange errors that seem random. Authentication might work at one moment and fail the next. Your backup domain controller, which should step in if the primary fails, might have outdated information that causes even more problems during an emergency.
Two Domain Controllers Not Syncing: Likely Causes
Several issues can stop your domain controllers from syncing properly. Some are simple network hiccups, while others involve deeper configuration problems. Let’s look at what typically breaks this critical connection.
1. Network Connectivity Problems
Your domain controllers need a stable network connection to talk to each other. If something blocks that connection, replication stops cold.
This could be a firewall rule that accidentally blocks replication traffic. Maybe someone changed a switch configuration and created a network segment that cuts off one controller. Physical issues matter too, like a loose cable or a failing network card.
Sometimes the connection works but it’s too slow or drops packets frequently. Your controllers try to sync but the conversation keeps breaking down. They might eventually give up and mark the replication as failed. Testing basic network connectivity between your controllers should be your first step.
2. DNS Resolution Failures
Active Directory depends heavily on DNS to find domain controllers. Each controller needs to locate its replication partners using DNS queries.
If your DNS settings are wrong or if DNS servers aren’t responding, controllers can’t find each other. Even small DNS issues can break replication. Your controller might try to reach another server using a hostname that doesn’t resolve or points to the wrong IP address.
3. Authentication and Permission Issues
Domain controllers authenticate with each other before they can share information. This process uses Kerberos tickets and requires proper permissions.
If the computer account for one domain controller is corrupted or has wrong permissions, authentication fails. The controllers can see each other on the network but can’t establish a trusted connection. Password mismatches between the controller’s computer account and what’s stored in Active Directory cause this problem frequently.
Trust relationships between domains can break too. When that happens, controllers from different domains can’t replicate even though everything looks fine on the surface. This often follows password resets or changes to domain trust configurations that weren’t completed properly.
4. Replication Topology Problems
Active Directory uses a replication topology that defines which controllers sync with which others. The Knowledge Consistency Checker service maintains this topology automatically.
But sometimes this topology gets messed up. A controller might think it should replicate with a server that doesn’t exist anymore. Or the topology might have loops and conflicts that confuse the replication process. Manual changes to replication connections can create these problems if they’re not done carefully.
You might have lingering metadata from a decommissioned domain controller that never got cleaned up properly. Your active controllers keep trying to reach this ghost server, and those failed attempts clog up the replication process. This happens more often than you’d think, especially in networks where controllers get added and removed frequently.
5. Time Synchronization Issues
Kerberos authentication has strict time requirements. If your domain controllers have clocks that differ by more than five minutes, authentication fails and replication stops.
Each controller should sync its time with a reliable source. The primary domain controller typically syncs with an external time server, and other controllers sync with it. When this chain breaks, time drift happens. Maybe a controller lost its connection to the time source, or someone disabled the time sync service by mistake. As time differences grow, replication errors start appearing.
Two Domain Controllers Not Syncing: DIY Fixes
Getting your controllers syncing again often requires working through several potential fixes. Start with the simplest solutions before moving to more complex repairs. These steps work for most replication failures.
1. Verify Network Connectivity
Start by checking if your controllers can actually reach each other over the network. Open Command Prompt on one controller and ping the other controller by both IP address and hostname.
If the ping fails, you have a network issue to fix first. Check your network cables, switch ports, and firewall rules. Look for any recent network changes that might have broken connectivity.
Next, test the specific ports that replication uses. Domain controllers communicate over several ports including TCP 135, TCP 389, and the dynamic RPC port range. Use tools like PortQry or Test-NetConnection in PowerShell to verify these ports are open and responding. If certain ports are blocked, you’ll need to adjust your firewall rules to allow replication traffic.
2. Check and Fix DNS Settings
Your DNS configuration needs to be correct for replication to work. Log into each domain controller and verify that it’s pointing to the right DNS servers. These should typically be other domain controllers in your domain.
Run ipconfig /all to see what DNS servers are configured. Then test DNS resolution by running nslookup for each domain controller’s hostname and FQDN. The results should return the correct IP addresses. If DNS lookups fail or return wrong addresses, you need to fix your DNS records. Go into your DNS management console and verify that A records for each controller are present and accurate. Check that the appropriate SRV records exist too, as Active Directory uses these for service location.
3. Force Replication and Check for Errors
Sometimes replication just needs a push to get going again. You can force a sync between controllers using the Active Directory Sites and Services tool.
Open the tool and expand Sites, then find your site and the Servers folder beneath it. Locate one of your domain controllers, expand it, and click on NTDS Settings. Right-click on the connection object to the other controller and select “Replicate Now.” Watch for any error messages that pop up. These errors often point directly to what’s blocking replication.
You can also use the repadmin command-line tool for more detailed control. Running repadmin /replsummary shows you the current replication status across all controllers. The command repadmin /syncall /AdeP forces a complete sync of all directory partitions. Look carefully at any error codes you get back. These codes correspond to specific problems that you can look up and fix.
4. Reset the Secure Channel
The secure channel between domain controllers can get corrupted. Resetting it often fixes authentication-related replication problems.
On one of the controllers that won’t sync, open PowerShell as an administrator. Run the command Test-ComputerSecureChannel -Repair. This resets the computer account password and re-establishes the secure channel. The controller will authenticate again with the domain, which often clears up permission issues that block replication.
After running this command, wait a few minutes and then try forcing replication again. The secure channel reset might need time to propagate through your authentication systems.
5. Synchronize Time Between Controllers
If your controllers have drifted apart time-wise, getting them back in sync is essential. Check the current time on each controller and compare them.
On your primary domain controller, verify it’s syncing with a reliable external time source. Run w32tm /query /status to see the current time configuration. If it’s not set up correctly, use w32tm /config /manualpeerlist:"time.windows.com" /syncfromflags:manual /reliable:YES /update to configure it.
On your other domain controllers, make sure they’re syncing with the PDC emulator. Use w32tm /config /syncfromflags:domhier /update to set this up. Then force an immediate sync with w32tm /resync /rediscover. Give it a few minutes, check the time on both controllers again, and verify they’re now within seconds of each other.
6. Clean Up Replication Metadata
Leftover metadata from old domain controllers often causes ongoing replication problems. Cleaning this up requires careful steps but can resolve persistent sync failures.
Open Active Directory Sites and Services on a working domain controller. Check your replication topology for any references to servers that no longer exist. If you find ghost entries, you’ll need to remove them manually using the ntdsutil tool.
Run ntdsutil from an elevated command prompt, then type metadata cleanup and press Enter. Use the commands within this tool to connect to your domain and remove the outdated server objects. Be very careful here because removing the wrong objects can cause serious problems. After cleanup, force the Knowledge Consistency Checker to rebuild your replication topology by running repadmin /kcc.
7. Contact a Domain Administrator or IT Professional
If you’ve tried these fixes and your controllers still won’t sync, you need expert help. Replication problems can sometimes indicate deeper issues with your Active Directory database or forest configuration. A qualified domain administrator or IT professional can perform advanced diagnostics, check database integrity, and handle complex repairs that go beyond basic troubleshooting. They have specialized tools and experience with rare replication scenarios that might be affecting your system.
Wrapping Up
Getting your domain controllers to sync again protects your network from authentication failures and policy inconsistencies. Most sync problems come from network issues, DNS troubles, or authentication hiccups that you can fix yourself using the steps above.
Start with the basics like network connectivity and DNS, then work through forced replication and time synchronization. These straightforward fixes resolve the majority of replication failures. If your controllers still refuse to sync after trying everything, bringing in an experienced administrator ensures you don’t accidentally make things worse while trying to repair your Active Directory infrastructure.