- The article explains how to troubleshoot and fix AD replication issues between two sites using the Knowledge Consistency Checker (KCC), which is a built-in process that generates the replication topology for the AD forest.
- The article provides a step-by-step guide on how to check the network connectivity, DNS configuration, site link configuration, connection objects, replication status, event logs, and error codes for AD replication between two sites, and how to resolve any errors or failures using various tools and solutions.
- The article also includes some frequently asked questions and answers related to AD replication issues between two sites, as well as a disclaimer that the information is for informational purposes only and does not constitute professional advice.
Active Directory (AD) is a directory service that allows you to manage users, computers, and other resources on a network. AD relies on replication to keep the data consistent and up-to-date across multiple domain controllers (DCs) in different locations. However, sometimes replication can fail due to various reasons, such as network problems, configuration errors, or security issues. In this article, we will show you how to troubleshoot and fix AD replication issues between two sites using the Knowledge Consistency Checker (KCC).
Table of Contents
- What is the Knowledge Consistency Checker?
- How to Identify AD Replication Issues Between Two Sites
- How to Fix AD Replication Issues Between Two Sites
- Frequently Asked Questions
- Question: How can I monitor AD replication across multiple sites?
- Question: How can I troubleshoot AD replication issues between two sites using PowerShell?
- Question: How can I optimize AD replication between two sites?
- Disclaimer
What is the Knowledge Consistency Checker?
The KCC is a built-in process that runs on every DC and generates the replication topology for the AD forest. The replication topology is the set of connections between DCs that determines how and when replication occurs. The KCC creates separate replication topologies depending on whether replication is occurring within a site (intrasite) or between sites (intersite).
The KCC also dynamically adjusts the topology to accommodate changes in the network, such as the addition or removal of DCs, the movement of DCs to and from sites, or the availability of DCs. The KCC ensures that replication is efficient and reliable by following these principles:
- Every DC has at least one inbound connection from another DC in the same site.
- Every DC in one site can reach every DC in another site through a chain of connections.
- The number of hops (intermediate DCs) between any two DCs is minimized.
- The replication frequency is higher within a site than between sites.
How to Identify AD Replication Issues Between Two Sites
One of the common symptoms of AD replication issues between two sites is that changes made on one DC are not reflected on another DC in a different site. For example, if you create a new user account on a DC in Site A, but it does not appear on a DC in Site B, then there is likely a problem with intersite replication.
To verify if there is a replication issue between two sites, you can use the following tools:
- Repadmin: This is a command-line tool that allows you to view the replication status, force replication, and diagnose replication errors. You can run Repadmin from any DC or from a member server or workstation that has the Remote Server Administration Tools (RSAT) installed.
- Active Directory Sites and Services: This is a graphical tool that allows you to view and manage the site topology, site links, and connection objects. You can access Active Directory Sites and Services from the Administrative Tools folder or by typing dssite.msc in the Run dialog box.
- Event Viewer: This is a graphical tool that allows you to view the system logs and application logs for any errors or warnings related to AD replication. You can access Event Viewer from the Administrative Tools folder or by typing eventvwr.msc in the Run dialog box.
How to Fix AD Replication Issues Between Two Sites
There are many possible causes and solutions for AD replication issues between two sites, but here are some general steps you can follow to troubleshoot and fix them:
- Check the network connectivity between the sites. Make sure that there are no firewalls, routers, switches, or other devices that are blocking the ports required for AD replication. The default ports are TCP 135, TCP 389, TCP 636, TCP 3268, TCP 3269, UDP 53, UDP 88, UDP 123, UDP 138, UDP 389, and UDP 464. You can use tools like Ping, Traceroute, Telnet, or PortQry to test the connectivity and port availability.
- Check the DNS configuration on both sites. Make sure that the DNS servers are reachable and authoritative for the AD domain. Make sure that the DNS records for all DCs are correct and up-to-date. You can use tools like Nslookup, Dcdiag, or Dnslint to test and verify the DNS configuration.
- Check the site link configuration in Active Directory Sites and Services. Make sure that there is a site link object that connects the two sites involved in replication. Make sure that the site link object has both sites as members and has a valid cost and schedule. You can use Active Directory Sites and Services to view and modify the site link configuration.
- Check the connection objects in Active Directory Sites and Services. Make sure that there are connection objects that represent inbound and outbound replication between the DCs in different sites. Make sure that the connection objects have valid source and destination DCs and have a valid schedule and transport type. You can use Active Directory Sites and Services to view and modify the connection objects.
- Check the replication status using Repadmin. Run repadmin /showrepl * /csv >repl.csv from any DC to generate a CSV file that contains the replication status for all DCs in the forest. Open the CSV file in Excel or another spreadsheet application and filter the results by the site name, the DC name, the replication partner, the partition, and the result. Look for any errors or failures in the replication status and note down the error codes and messages. You can use Repadmin to force replication, sync all DCs, or show the replication queue.
- Check the event logs using Event Viewer. Look for any errors or warnings in the Directory Service, DNS Server, or System logs that are related to AD replication. Note down the event IDs and messages and look for any common patterns or root causes. You can use Event Viewer to filter, sort, or export the event logs.
- Resolve any errors or failures using the appropriate solutions. Depending on the error code or message, you may need to perform different actions to fix the replication issue. Some common solutions are:
-
- Restarting the KCC on one or both DCs to regenerate the replication topology. You can do this by running repadmin /kcc from a command prompt on the DC.
- Forcing replication between two DCs to bypass the schedule and transport type. You can do this by running repadmin /replicate destDC sourceDC partition from a command prompt on either DC, where destDC is the destination DC, sourceDC is the source DC, and partition is the AD partition to replicate (e.g., dc=example,dc=com).
- Repairing or restoring a corrupted AD database on a DC using tools like Ntdsutil or Esentutl. You can do this by booting the DC into Directory Services Restore Mode (DSRM).
- Demoting and promoting a DC to rejoin it to the domain and reinitialize its AD database. You can do this by running dcpromo /forceremoval from a command prompt on the DC to demote it, and then running dcpromo again to promote it.
- Verify that the replication issue is resolved using Repadmin and Event Viewer. Run repadmin /showrepl * /csv >repl.csv again from any DC to generate a new CSV file that contains the replication status for all DCs in the forest. Open the CSV file in Excel or another spreadsheet application and filter the results by the site name, the DC name, the replication partner, the partition, and the result. Look for any errors or failures in the replication status and compare them with the previous results. If there are no errors or failures, then the replication issue is resolved. If there are still errors or failures, then repeat steps 5 to 7 until they are resolved.
Frequently Asked Questions
Here are some common questions and answers related to AD replication issues between two sites:
Question: How can I monitor AD replication across multiple sites?
Answer: You can use tools like Repadmin, Active Directory Replication Status Tool (ADREPLSTATUS), or Dcdiag to monitor AD replication across multiple sites. These tools can help you check the replication status, identify replication errors, and generate reports.
Question: How can I troubleshoot AD replication issues between two sites using PowerShell?
Answer: You can use PowerShell cmdlets like Get-ADReplicationPartnerMetadata, Get-ADReplicationFailure, Test-ReplicationHealth, Sync-ADObject, or Invoke-KCC to troubleshoot AD replication issues between two sites. These cmdlets can help you view the replication metadata, detect replication failures, test replication health, synchronize AD objects, or invoke KCC.
Question: How can I optimize AD replication between two sites?
Answer: You can optimize AD replication between two sites by following these best practices:
- Use a reliable and fast network connection between the sites.
- Use site link bridges to reduce hops between sites.
- Use site link transitivity to enable direct connections between sites.
- Use global catalog servers to reduce intersite referrals.
- Use universal group membership caching to reduce global catalog queries.
- Use compression and change notification to reduce bandwidth and latency.
Disclaimer
This article is for informational purposes only and does not constitute professional advice. The information contained herein is provided “as is” and without warranty of any kind. The author and publisher disclaim any liability for any direct, indirect, incidental, consequential, special, exemplary, punitive, or other damages arising from your use of this article. You should always consult a qualified professional before taking any action based on this article.