Section 4.6: Active Directory Replication
Active Directory directory service replication involves transferring and maintaining Active Directory data between domain controllers in a network. This replication is managed by the system administrator on a site-by-site basis. As domain controllers are added, a replication path must be established. This is done by the Knowledge Consistency Checker (KCC) coupled with Active Directory replication components. The KCC is a dynamic process that runs on all domain controllers to create and modify the replication topology. If a domain controller fails, the KCC automatically creates new paths to the remaining domain controllers. Manual intervention with the KCC will also force a new path.
When a user or administrator performs an action that initiates an update to Active Directory, an appropriate domain controller is automatically chosen to perform the update. This change is made transparently at one of the domain controllers. Active Directory provides multimaster replication with loose convergence. In Active Directory, multimaster replication provides two advantages:
• there is no domain controller that will prevent replication if it is offline
• more than one domain controller provides a level of fault tolerance against hardware failure
Active Directory replication can occur within sites where it occurs between domain controllers in the same site and is designed to work with fast, reliable connections. Active Directory replication can also occur between sites. Active Directory replication uses the Remote Procedure Call (RPC) over IP to conduct replication within a site. Replication between sites can use either RPC or the Simple Mail Transfer Protocol (SMTP) for data transmission. The default intersite replication protocol is RPC.
4.6.1: Replication Within Sites
Replication within sites occurs between domain controllers in the same site. Because a site assumes fast, highly reliable network links, replication traffic within a site is uncompressed. This reduces the processing load on the domain controllers but increases the network bandwidth that is used for replication.
4.6.2: Replication Between Sites
Replication between sites assumes that the network links between sites are unreliable and have limited bandwidth. Replication between sites occurs automatically when you schedule replication or define and a replication interval. By default, changes are replicated between sites according to a schedule and not when changes occur in Active Directory. The schedule determines which times replication is allowed to occur, and the interval specifies how often domain controllers check for changes during the time that replication is allowed to occur. Replication traffic between sites is compressed to optimize the bandwidth required for replication traffic between sites. Although compression optimizes network bandwidth, it increases the processing load on domain controllers as the replication data must be uncompressed on the destination Domain Controller.
When replication occurs between sites, one or more replicas in each site act as bridgeheads to another site in the topology. Bridgehead servers are the contact point for the exchange of directory information between sites. A server is automatically designated as a bridgehead server by using the Intersite Topology Generator (ISTG) in each site to perform replication between sites. After replication between sites is completed by using the bridgehead server, the bridgehead servers communicate all updates to all domain controllers within their sites by using the normal replication process.
4.6.2.1: Site Link Attributes
You should provide the site link cost, replication frequency, and replication availability for all site links as part of the process of configuring inter-site replication.
When Site Link Costs are configured, a value for the cost of each available connection used for inter-site replication is assigned. If you have multiple redundant network connections, you can establish site links for each connection and assign site link costs to these links that reflect their relative bandwidth. Windows Server 2003 then chooses the link with the lowest cost for the transfer of replication traffic.
To configure site link cost, do the following:
• Click on the START button
• Point to PROGRAMS
• Point to ADMINISTRATIVE TOOLS
• Click ACTIVE DIRECTORY SITES AND SERVICES
• Open the Inter-Site Transports folder and either the IP or SMTP folder
• Right-click on the site link which you want to assign a cost to
• Click proprties to open the Properties dialog box
• In the Properties dialog box, enter the cost value that you want to assign to the site link
• Then click OK
Note: The lower the site link cost value is, the higher the priority Windows Server 2003 associates with the link. The default site link cost in Windows Server 2003 assigns a link is 100.
4.6.2.2: Site Link Bridges
When more than two sites are linked for replication and use the same transport protocol, all of the site links are "bridged" in terms of cost and are transitive, i.e., all site links for a specific transport implicitly belong to a single site link bridge for that transport. A site link bridge is the equivalent of a disjoint network; all site links within the bridge can route transitively, but they do not route outside of the bridge.
To create a site link bridge, do the following:
• Click on the START button
• Point to PROGRAMS
• Point to ADMINISTRATIVE TOOLS
• Click ACTIVE DIRECTORY SITES AND SERVICES
• Open the Inter-Site Transports folder
• Right-click either the IP or SMTP folder
• Click NEW site link bridge to open the New Object-Site Link Bridge dialog box
• In the New Object-Site Link Bridge dialog box, enter a name for the site link bridge
• Click on the sites you want to connect
• Click ADD
• Then click OK
By default, all domain controllers are used to exchange information between sites, but you can specify a bridgehead server for inter-site replication. This will provide a criterion for choosing which domain controller should be preferred as the recipient for inter-site replication. This bridgehead server then subsequently distributes the directory information via intra-site replication. Other domain controllers could still exchange directory information if a need arises, but under normal conditions, the bridgehead server will be used as the first choice to receive and send all directory traffic. You can specify a preferred bridgehead server if you have a computer with appropriate bandwidth to transmit and receive information. If there's typically a high level of directory information exchange, a computer with more bandwidth can ensure these exchanges are handled promptly. You can also specify multiple preferred bridgehead servers, but only one will be the active preferred bridgehead server. However, if the active preferred bridgehead server fails, Active Directory will select another preferred bridgehead server to be the active preferred bridgehead server. If there are no other preferred bridgehead servers available for Active Directory to select, it will select another domain controller in the site to be the preferred bridgehead server. This can be a problem if the domain controller Active Directory selects does not have the bandwidth to efficiently handle the increased requirements posed by being a preferred bridgehead server.
You must specify a preferred bridgehead server if your deployment uses a firewall to protect a site. Establish your firewall proxy server as the preferred bridgehead server, making it the contact point for exchanging information with servers outside the firewall. If you do not do this, directory information may not be successfully exchanged.
To designate a preferred bridgehead server, do the following:
• Click on the START button
• Point to PROGRAMS
• Point to ADMINISTRATIVE TOOLS
• Click ACTIVE DIRECTORY SITES AND SERVICES
• Right-click on the Domain Controller that you want to designate as the preferred bridgehead server
• Click proprties to open the Properties dialog box
• In the Properties dialog box, click the inter-site transport or transports for which this computer will be a preferred bridgehead server
• Click ADD
• Then click OK
4.6.3: Replication Latency
Replication latency is the time that is required for a change made on one domain controller to be received by another domain controller. When an update is applied to a given replica, the replication engine is triggered.
Note: Replication within a site occurs through a change notification process. When an update occurs on a domain controller, replication waits for a configurable time period, which is five minutes by default, before it notifies the first replication partner of the change. Each additional direct partner is notified after a configurable delay, which is 30 seconds by default. Therefore, the propagation delay for a single change to be replicated through a domain, based on the default configuration and the three-hop limit (hops means moving data from one domain controller to another domain controller), is 15 minutes, which may include the 30-second configurable delay.
4.6.4: Resolving Replication Conflicts
Because replication in Active Directory is based on a multimaster model, all computers that provide multimaster updates must handle potential conflicts that may arise when concurrent updates that originate on two separate master replicas are inconsistent. When the updates are replicated, these concurrent updates cause a conflict. Active Directory both minimizes and resolves conflicts. There are three types of replication conflicts:
• Attribute value, which occurs when an object's attribute is set concurrently to one value at one replica and to another value at a second replica.
• Add or move under a deleted container object or the deletion of a container object. This occurs when one replica records the deletion of a container object, while another replica records the placement of an object in the deleted container object.
• Sibling name, which occurs when one replica attempts to move an object into a container in which another replica has concurrently moved another object with the same relative distinguished name.
4.6.5: Single Master Operations
Active Directory supports multimaster replication of directory changes among all domain controllers in a forest. During multimaster replication, a replication conflict can occur if concurrent originating updates are performed on the same data on two different domain controllers. To avoid these conflicts, some single master operations are performed by making a single domain controller responsible for the operation. These operations are grouped together into specific roles within the forest or within a domain. These roles are called operations master roles. For each operations master role, only the domain controller holding that role can make the associated directory changes.