Active Directory Replication: A Guide for IT Pros
Learn all there is to know about how Active Directory (AD) replication works. This guide covers the basics of how domain controllers (DCs) replicate all of your user accounts, passwords, computers, and other objects in your environment. Learn about how sites define the logical layout of your network and how the tools and features in Active Directory Domain Services work together to keep your directory running smoothly.
Table of Contents
- Active Directory replication
- Primary replication components
- Active Directory replication objects
- Replication management
- How to monitor AD replication: Commands and tools
Active Directory replication
Have you ever wondered what happens behind the scenes when you add a new user to Active Directory? Or change their password? Or join a new computer in your domain? If you add a new user on ‘DC01’, how and when does ‘DC05’ know about it? Active Directory replication, that’s how. This is the engine that pushes changes from domain controller to domain controller in your environment.
How does Microsoft Active Directory replication work?
The replication of updates between Active Directory objects means that data is sent between multiple domain controllers to keep replicas of directory partitions synchronized. Multiple domains are common in large organizations, as are multiple sites in disparate locations. Also, DCs for the same domain are generally placed in more than one site to accommodate compliance, mergers and acquisitions, etc. Each time a new domain controller is added to an existing domain or forest, new components are created, connection objects, site links, etc. And when you add a new DC on a new subnet, MAGIC! Yes, a new ‘subnet’ is created in Active Directory sites and services.
How often does Active Directory replication occur?
Well, that depends. By default, for domain controllers that are in the same site (intra-site replication), replication occurs every 15 seconds. As soon as you change an attribute of an AD object, for instance the job title of your newly promoted systems engineer, the DC will send out the update to its replication partner.
Inter-site replication is set to 180 minutes (three hours). There are a lot of variables, topologies, hardware, subnets, and overall network design that goes into the planning of inter-site replication. With separate offices in New York and Los Angeles, it may be acceptable to wait up to three hours for changes to take effect across the country. Again, there are many deployment methods you could use. You may have a root forest and child domains in each site (city). At that point, waiting three hours for someone’s password to update from New York to Los Angeles may work fine for your business needs.
Primary replication components
Let’s briefly go over the basic replication components in Active Directory replication and explain their purpose.
Knowledge Consistency Checker (KCC)
All domain controllers have a built-in process called the Knowledge Consistency Checker (KCC). This generates replication topology for the Active Directory forest. The KCC will automatically create separate replication topologies based on your intra-site and inter-site topologies. To accommodate the addition of new DCs, the removal of DCs, or the act of physically moving DCs from one geographic location to another, the KCC also dynamically adjusts the topology on a periodic schedule.
Within a site, the connections between writable domain controllers are always arranged in a bi-directional ring, with additional shortcut connections to reduce latency in large sites. On the other hand, the inter-site topology is a layering of spanning trees, which means one inter-site connection exists between any two sites for each directory partition and generally does not contain shortcut connections.
Directory System Agent (DSA)
In Active Directory Domain Services, the Directory System Agent (DSA) is part of the Local System Authority (LSA) subsystem. The DSA is a collection of services and processes that run on each domain controller and provides access to the data store. The data store is the physical store of directory data location on the server’s hard disk.
Extensible Storage Engine (ESE)
The Extensible Storage Engine (ESE) is a database engine utilized by Active Directory Domain Services that stores information in a logical sequence. Information can be retrieved by various methods, for example, sequentially or by accessing defined indices. Database updates are implemented with a transaction in order to ensure secure operations.
The ESE is a relatively scalable design, scalable to large or small applications. The ESE also provides consistent data access in the event of a system crash. This provides a lightweight, highly responsive engine to store the ‘raw contents’ of Active Directory.
Remote Procedure Call (RPC)
Within a site, Active Directory replication uses Remote Procedure Call (RPC) over IP for replication. RPC is an industry-standard protocol for client/server communications. It is highly compatible with a wide variety of network types.
For replication within a site, RPC provides uniform, high-speed connectivity. This efficiency provides the perfect backdrop for even complex layouts of network and multiple site Active Directory topologies.
Inter-Site Topology Generator (ISTG)
The Inter-Site Topology Generator is an Active Directory process that defines the replication between Active Directory sites on a network. A single domain controller in each site is automatically designated to be the Inter-Site Topology Generator. Because this action is automatic, you don’t need to complete any explicit steps during the installation of new DCs.
The domain controller that holds the Inter-Site Topology Generator role performs two functions:
- It automatically selects one or more domain controllers to become bridgehead servers, which are DCs that are mainly used for intersite replication. If a bridgehead server becomes unavailable, the Inter-Site Topology Generator automatically selects another bridgehead server.
- It runs the Knowledge Consistency Checker to determine the replication topology and resultant connection objects that the bridgehead servers can use to communicate with bridgehead servers of other sites.
Active Directory replication objects
Next, we’ll go over and explain the various types of objects you’ll come across in the design of your Active Directory topology.
What happens when one of your domain controllers is offline or down for maintenance? Will its replication partners simply be content with potentially stale information? Hardly.
Sites (and services) ensure that replication is routed around network failures and domain controllers unavailable due to maintenance. Remember, the Knowledge Consistency Checker runs automatically at specified intervals to keep track of the logical topology of your network and DCs. The KCC will periodically review the replication status of existing connections to find out if any connections are inoperable. If a connection is not working due to a failed domain controller, the KCC will automatically build temporary connections to other replication partners (if they’re available) to ensure that replication occurs. If all the DCs in a site are unavailable, the KCC will create replication connections between domain controllers from another site.
Now, I would imagine most IT Pros know what a Subnet is in TCP/IP arenas, but let’s be complete: A Subnet is a segment of a TCP/IP network that defines a set of logical IP addresses. Subnets group computers in a way that identifies their relative physical location on your network. Subnet objects in Active Directory Domain Services help to identify the network addresses that are used to map computers to sites.
If you do a search on this post for the word ‘site’, you’ll see quite a few hits (up to this point). Sites are a very large topic when it comes to the logical layout of your Active Directory topology. A site is an Active Directory object that represents one or more TCP/IP subnets with highly reliable and ‘fast’ network connections. Site information allows admins to configure AD access and replication to optimize usage of their physical network. Site objects are associated with a collection of subnets, and each domain controller in a forest is associated with an AD site according to its IP address.
When the Knowledge Consistency Checker creates a connection object for domain controllers between sites (setting up inter-site replication), site links are created. They are Active Directory objects that represent logical paths for Active Directory replication. A site link object represents a set of sites that can communicate at a uniform cost through a specified inter-site transport.
All sites contained within the site link are connected by means of the same (logical) network type. Sites must be manually linked to other sites by using site links so that domain controllers in one site can replicate directory changes from DCs in another site.
Do you remember when we previously learned about the Inter-Site Topology Generator and bridge servers? Well, that knowledge will help you understand this: When two sites are connected by a site link, the replication system automatically creates connections between specific domain controllers in each site that are called bridgehead servers. When the KCC creates replication connections, they are randomly distributed among all candidate bridgehead servers in a site to share the replication workload.
A site link bridge is an AD object that represents a set of site links. These ‘connected’ sites can communicate by using a common transport. Site link bridges enable domain controllers that are not directly connected via a communication link to replicate with each other. Typically, a site link bridge corresponds to a router (or a set of routers) on an IP network.
The Knowledge Consistency Checker forms a transitive route through all site links that have some sites in common. Each site link represents its own distinct and isolated network if this behavior is disabled. Containers of site links that can be treated as a single route are expressed through a site link bridge. Each bridge represents an isolated segment of the communication environment for network traffic.
Site link bridges are used to represent transitive physical connectivity accurately and logically between sites. A site link bridge offers the Knowledge Consistency Checker the ability to use any combination of the included site links to determine the least expensive route to interconnect directory partitions held in those sites. The site link bridge doesn’t actually provide connectivity to the domain controllers. If the site link bridge is removed, replication will continue until the Knowledge Consistency Checker removes the links.
By default, all site links are transitive, or “bridged.” When you bridge site links and the schedules overlap, the Knowledge Consistency Checker will create replication connections that determine domain controller replication partners between sites, where the sites are not connected directly by site links but are connected transitively through a set of common sites. This means that you can connect any site to any other site through a combination of site links.
Global Catalog server
A Global Catalog (GC) server is a domain controller that stores information about all objects in the forest so that users, applications, and other pieces of software can search Active Directory Domain Services without referring to specific DCs that store the requested data. Like all DCs, a Global Catalog server stores complete, updateable replicas of the configuration and schema directory partitions and a full, writable replica of the domain directory partition for the domain that it is hosting. In addition, a Global Catalog server stores a partial, read-only replica of every other domain in the forest. Partial, read-only domain replicas contain every object in the domain but only a subset of the attributes (those attributes that are most commonly used for searching the object).
Universal group membership caching
Universal group membership caching allows the domain controllers to cache the membership of universal groups info for users. You can enable domain controllers that are running Windows Server 2008 or higher to cache universal group memberships by using the Active Directory Sites and Services snap-in.
You can avoid installing a Global Catalog server at every site in a domain by enabling universal group membership caching. This will minimize network bandwidth usage because a domain controller does not need to replicate all of the objects located in the forest. It also reduces logon times because the authenticating domain controllers do not always need to access a global catalog to obtain universal group membership information.
There are various tools you can use to monitor and manage the Active Directory replication status in your environment: Active Directory Sites and Services, PowerShell, the trusty Command Line, and the Active Directory Replication Status Tool (I’ll show you this at the end of this post…). For now, let me show you how to use the ‘Repadmin’ command to discover the status and any potential replication errors present in your environment.
Check the replication health
To check the overall replication health of your domain controllers, run this command:
Check the inbound replication requests that are queued.
Check the replication status
Synchronize replication between replication partners
Force the Knowledge Consistency Checker to recalculate the topology
How to monitor AD replication: Commands and tools
Besides the RepAdmin.exe command-line tool, there’s also a Graphical User Interface (GUI) front-end called Active Directory Replication Status Tool.
The Active Directory Replication Status Tool (ADREPLSTATUS) does some analyzing of the replication status for domain controllers in an Active Directory domain or forest. ADREPLSTATUS is essentially a helpful, front-end GUI for the commands I showed you above. This is similar to REPADMIN /SHOWREPL * /CSV imported into Excel, but with significant enhancements.
Specific capabilities for this tool include:
- Expose Active Directory replication errors occurring in a domain or forest
- Prioritize errors that need to be resolved in order to avoid the creation of lingering objects in Active Directory forests
- Help administrators and support professionals resolve replication errors by linking to Active Directory replication troubleshooting content on Microsoft TechNet
- Allow replication data to be exported to source or destination domain administrators or support professionals for offline analysis
To download the Active Directory Replication Status Tool, click here.
Active Directory replication is quite a technical topic, but we hope this guide helped you to understand everything you need to know about primary replication components, Active Directory replication objects, and replication management.
More in Active Directory
Microsoft Releases Out-Of-Band Patches to Fix Windows AD Authentication Issues
May 20, 2022 | Rabia Noureen
Cloud Conversations – Ståle Hansen on Digital Wellbeing and Viva Explorers
May 19, 2022 | Laurent Giret
How to Access Active Directory
May 17, 2022 | Michael Reinders
Microsoft Rolls Out Azure AD Verifiable Credentials Service to More Customers
May 11, 2022 | Rabia Noureen
Active Directory vs. Azure AD (and Other Identity Providers)
May 9, 2022 | Michael Taschler
Apple Finally Discontinues Support for macOS Server App
Apr 25, 2022 | Rabia Noureen
Most popular on petri