Active Directory Replication Concepts

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Before designing site topology, become familiar with some Active Directory replication concepts.

Connection object

A connection object is an Active Directory object that represents a replication connection from one domain controller to another. A domain controller is a member of a single site and is represented in the site by a server object in Active Directory. Each server object has a child NTDS Settings object that represents the replicating domain controller in the site.

The connection object is a child of the NTDS Settings object on the destination server. For replication to occur between two domain controllers, the server object of one must have a connection object that represents inbound replication from the other. All replication connections for a domain controller are stored as connection objects under the NTDS Settings object. The connection object identifies the replication source server, contains a replication schedule, and specifies a replication transport.

The Knowledge Consistency Checker (KCC) creates connection objects automatically, but they can also be created manually. Connection objects created by the KCC appear in the Active Directory Sites and Services snap-in as <automatically generated> and are considered adequate under normal operating conditions. Connection objects created by an administrator are manually created connection objects. A manually created connection object is identified by the name assigned by the administrator when it was created. When you modify an <automatically generated> connection object, you convert it into an administratively modified connection object and the object appears in the form of a GUID. The KCC does not make changes to manual or modified connection objects.

KCC

The KCC is a built-in process that runs on all domain controllers and generates replication topology for the Active Directory forest. 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 new domain controllers, domain controllers moved to and from sites, changing costs and schedules, and domain controllers that are temporarily unavailable.

Within a site, the connections between domain controllers are always arranged in a bidirectional ring, with additional shortcut connections to reduce latency in large sites. On the other hand, the intersite topology is a layering of spanning trees, which means one intersite connection exists between any two sites for each directory partition and generally does not contain shortcut connections. For more information about spanning trees and Active Directory replication topology, see Active Directory Replication Topology Technical Reference in the Windows Server 2003 Technical Reference on the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkId=44137).

On each domain controller, the KCC creates replication routes by creating one-way inbound connection objects that define connections from other domain controllers. For domain controllers in the same site, the KCC creates connection objects automatically without administrative intervention. When you have more than one site, you configure site links between sites and a single KCC in each site automatically creates connections between sites as well.

Figure 3.3 shows two sites (Seattle and Los Angeles) with domain controllers that are all in the same domain. The arrows represent possible inbound connections that the KCC creates. Because all Active Directory updates are transferred in a ring within a site and redundant connections exist, all domain controllers can receive updates from all other domain controllers in the Seattle site, although domain controllers within a site do not necessarily replicate in both directions. For replication to occur between Seattle and Los Angeles, one domain controller in each site has a replication agreement with a domain controller in the other site. Between sites, these replication partners replicate in both directions according to configuration settings for a site link object that represents the physical WAN connecting the two sites. In Figure 3.3, domain controllers DC-3 and DC-4 are replication partners between the Seattle and Los Angeles sites.

Figure 3.3   Intersite and Intrasite Replication Connections

Failover functionality

Sites ensure that replication is routed around network failures and offline domain controllers. The KCC runs at specified intervals to adjust the replication topology for changes that occur in Active Directory, such as when new domain controllers are added and new sites are created. The KCC reviews the replication status of existing connections to determine if any connections are not working. If a connection is not working due to a failed domain controller, the KCC automatically builds temporary connections to other replication partners (if available) to ensure that replication occurs. If all the domain controllers in a site are unavailable, the KCC automatically creates replication connections between domain controllers from another site.

Subnet

A subnet is a segment of a TCP/IP network to which a set of logical IP addresses are assigned. Subnets group computers in a way that identifies their physical proximity on the network. Subnet objects in Active Directory identify the network addresses that are used to map computers to sites.

Site

Sites are Active Directory objects that represent one or more TCP/IP subnets with highly reliable and fast network connections. Site information allows administrators to configure Active Directory access and replication to optimize usage of the physical network. Site objects are associated with a set of subnets, and each domain controller in a forest is associated with an Active Directory site according to its IP address. Sites can host domain controllers from more than one domain, and a domain can be represented in more than one site.

Site link

Site links are Active Directory objects that represent logical paths that the KCC uses to establish a connection for Active Directory replication. A site link object represents a set of sites that can communicate at uniform cost through a specified intersite transport.

All sites contained within the site link are considered to be connected by means of the same 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 domain controllers in another site. Because site links do not correspond to the actual path taken by network packets on the physical network during replication, you do not need to create redundant site links to improve Active Directory replication efficiency.

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. In Microsoft® Windows® 2000, intersite replication of the directory partitions (domain, configuration, and schema) between domain controllers in different sites is performed by the bridgehead servers (one per directory partition) in those sites. In Windows Server 2003, all domain controllers in a site that host the same directory partition are candidates for being selected as bridgehead servers. The replication connections created by the KCC are randomly distributed among all candidate bridgehead servers in a site to share the replication workload. By default, the randomized selection process takes place only once, when connection objects are first added to the site.

However, you can run the Active Directory Load Balancing tool (Adlb.exe) to rebalance the load each time a change occurs in the site topology or in the number of domain controllers the site. In addition, Adlb can stagger schedules so that the outbound replication load for each domain controller is spread out evenly across time. Consider using Adlb to balance replication traffic between the Windows Server 2003–based domain controllers when they are replicating to more than 20 other sites hosting the same domain. For more information about using Adlb.exe and managing environments that have 100 or more branch sites, see the Windows Server 2003 Active Directory Branch Office Guide on the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkId=28523).

Site link bridge

A site link bridge is an Active Directory object that represents a set of site links, all of whose sites can communicate by using a common transport. Site link bridges enable domain controllers that are not directly connected by means of 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.

By default, the KCC can form a transitive route through any and all site links that have some sites in common. If this behavior is disabled, each site link represents its own distinct and isolated network. Sets of site links that can be treated as a single route are expressed through a site link bridge. Each bridge represents an isolated communication environment for network traffic.

Site link bridges are a mechanism to logically represent transitive physical connectivity between sites. A site link bridge allows the KCC 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 does not provide actual connectivity to the domain controllers. If the site link bridge is removed, replication over the combined site links will continue until the KCC removes the links.

Site link bridges are only necessary if a site contains a domain controller hosting a directory partition that is not also hosted on a domain controller in an adjacent site, but a domain controller hosting that directory partition is located in one or more other sites in the forest. Adjacent sites are defined as any two or more sites included in a single site link.

A site link bridge creates a logical connection between two site links, providing a transitive path between two disconnected sites by using an interim site. For the purposes of the intersite topology generator (ISTG), the bridge implies physical connectivity by using the interim site. The bridge does not imply that a domain controller in the interim site will provide the replication path. However, this would be the case if the interim site contained a domain controller that hosted the directory partition to be replicated, in which case a site link bridge is not required.

The cost of each site link is added, creating a summed cost for the resulting path. The site link bridge would be used if the interim site did not contain a domain controller hosting the directory partition and a lower cost link does not exist. If the interim site contained a domain controller that hosts the directory partition, two disconnected sites would set up replication connections to the interim domain controller and not use the bridge.

Site link transitivity

By default all site links are transitive, or "bridged." When site links are bridged and the schedules overlap, the KCC creates replication connections that determine domain controller replication partners between sites, where the sites are not directly connected 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.

In general, for a fully routed network, you do not need to create any site link bridges unless you want to control the flow of replication changes. All site links for a specific transport implicitly belong to a single site link bridge for that transport. The default bridging for site links occurs automatically, and no Active Directory object represents that bridge. The Bridge all site links setting found in the properties of both the IP and Simple Mail Transfer Protocol (SMTP) intersite transport containers implements automatic site link bridging.

Global catalog server

A global catalog server is a domain controller that stores information about all objects in the forest so that applications can search Active Directory without referring to specific domain controllers that store the requested data. Like all domain controllers, a global catalog server stores full, writable replicas of the schema and configuration 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 controller to cache universal group membership information for users. You can enable domain controllers that are running Windows Server 2003 to cache universal group memberships by using the Active Directory Sites and Services snap-in.

Enabling universal group membership caching eliminates the need for a global catalog server at every site in a domain, which minimizes 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. For more information about when to use universal group membership caching, see "Planning Global Catalog Server Placement" later in this chapter.