Active Directory Replication
By Romeo Cavestany
In a Windows infrastructure, the Active Directory (AD) database is the heart and soul of the entire networking environment. Active Directory is where all of your schema, configuration and domain naming information about your users and computers are stored. All of your other applications depend on this information to operate properly. The way that these other applications find out about any changes in this vital metadata is through Active Directory Replication.
What is AD replication?
Active Directory replication is the mechanism that Active Directory uses to synchronize information across all of the domain controllers in the associated forests. When something changes in one of the partitions or tables within the AD database, that data is then propagated forest-wide—regardless of where the forest’s domain controllers are geographically located. Although replication has the effect of synchronizing information for the entire forest of domain controllers, the actual process occurs between domain controllers one at a time.
How does AD replication work?
In order to make this propagation happen, Active Directory uses a built-in process called Knowledge Consistency Checker (KCC). KCC runs on all domain controllers and creates a replication topology for the forest. By default, the KCC runs at 15-minute intervals and designates the routes between domain controllers. When there are more than one Active Directory sites, KCC can automatically create connections between them.
Each time the KCC runs, these connections are added, removed or modified automatically, as necessary. AD uses this connection information to properly propagate changes that are made on one domain controller to all other domain controllers in the forest that store copies of the same information.
How do you monitor AD replication?
To avoid problems in your network, the Active Directory replication process must remain healthy. The only way to proactively know if your AD replication is working properly is to monitor it.
Coyote Creek has extensive experience in this area! As part of our Remote Monitoring and Management services, AD replication is high on the list of things we monitor. There are various ways to check Active Directory status. You can use command-line tools as well as GUI tools to check the replication status for one or all domain controllers in an Active Directory forest.
For the purposes of this article, I will discuss a no-cost approach, meaning no third party software is involved. This approach involves running a PowerShell script that examines the health of the Active Directory replication process. The script is run as a scheduled task every few hours. We like to set it to run every six hours. Some administrators run this every 12 or 24 hours; the right frequency depends on your environment and level of paranoia! This script generates a report that is automatically emailed to us. The report shows the different naming contexts being propagated, and the number of failures for each. Ideally, this report will look like this:
Unfortunately, sometimes it looks like this:
|Source DSA||Naming Context||Destination DSA||Number of Failures||Last Failure Time||Last Success Time||Last Failure Status|
|DC1||DC=contoso,DC=com||DC2||10||2017-03-07 02:51:20||2017-02-24 11:20:45||1722|
|DC1||CN=Configuration,DC=contoso,DC=com||DC2||10||2017-03-07 03:04:56||2017-02-24 11:20:38||1722|
|DC1||CN=Schema,CN=Configuration,DC=contoso,DC=com||DC2||10||2017-03-07 03:05:41||2017-02-24 11:20:44||1722|
If failures are taking place, we find the root cause. When we get reports like the one above, we have two options for how to go about troubleshooting. The way we have things set up, attached to the initial report is a zip file of all of the data gathered by the PowerShell script. We can comb through that data, and see if there’s anything there to help us spot the problem.
Sometimes, though, the zip file contains a massive amount of data. Which is why our first troubleshooting step is usually to go to the affected server. Here is what we do…
- Start by using Repadmin. This is a command line utility that allows you to diagnose Active Directory replication problems between domain controllers. It shows if there are any failures in the communications between domain controllers. If you prefer a GUI tool to expose replication errors, you can download the AD Replication Status Tool from Microsoft.
- Review Windows Event Viewer logs – We then look for errors, informational events and warnings from the domain controller logs to corroborate the diagnostics data collected from Repadmin.
- Use Domain Controller Diagnostics (DCDiag) utility to dig deeper – The best way to verify the domain controller’s operation is to run this console utility to test different underlying Windows Server components such KCC, DNS or FRS. This command-line tool helps identify abnormal behavior in the system.
Fixing a replication problem
Once you have identified the problem server, the next step is to fix the problem. Typically what we see is one of two things: the AD server service was down or the server was having trouble with network communications. In this case the problem is often resolved by restarting the server or service.
To keep your AD replication processes working smoothly, proactive monitoring is key. This way you can catch problems early and resolve them before users even know anything is wrong. If you need help getting this set up properly, or want to hand off the entire monitoring process to a team of experts who do this 24/7, give us a call!