Topology Concepts and Components

Although replication has the effect of synchronizing Active Directory information for an entire forest of domain controllers, the actual process of replication occurs between two domain controllers at a time. Creation of replication topology involves the determination of what domain controller replicates with what other domain controller or domain controllers. When this determination is made for the entire set of domain controllers in a specific site (taking into account that each domain controller must be able to receive changes from all domain controllers in the forest that store the same information), the result is the replication topology for replication within the site. When a forest has domain controllers in more than one site, some of the replication connections between computers must span sites, and a topology for replication between sites is also created.

The total topology is actually composed of several underlying topologies: one for each combination of directory partitions that must be replicated. Domain controllers that store the same domain directory partition must have connections to each other, and all domain controllers must be able to replicate the schema and configuration directory partitions. The schema and configuration directory partitions are replicated over a separate topology; however, where the connections for these directory partitions are identical between domain controllers — for example, two domain controllers store the same domain directory partition — a single connection can be used.

The routes for the following combinations of directory partitions are aggregated to arrive at the overall topology:

  • Configuration and schema within a site.

  • Each domain directory partition within a site.

  • Global Catalog read-only, partial directory partitions within a site.

  • Configuration and schema between sites.

  • Each domain directory partition between sites.

  • Global Catalog read-only, partial directory partitions between sites.

Active Directory uses information stored in the forest-wide configuration directory partition to establish and implement the replication topology. Several configuration objects define the components that are required by replication:

  • The sites and the domain controllers that are associated with them.

  • The connections that identify the routes that replication takes between domain controllers within sites.

  • The links that make replication connections between sites possible.

  • The transports that the links use to communicate between sites.

The KCC uses these and other objects and their properties to create and manage the connections by which directory updates are transferred and to specify one or more domain controllers from which a particular server requests changes. The domain controllers that replicate directly with each other are called replication partners . Each time the KCC runs (every 15 minutes, by default), these partnerships are added, removed, or modified automatically, as necessary, on the basis of what domain controllers are available and how close they are to each other on the network.

The KCC uses the following components to manage replication:

Connections    The KCC creates connections that enable domain controllers to replicate with each other. A connection defines a one-way, inbound route from one domain controller, the source, to another domain controller, the destination. The KCC reuses existing connections where it can, deletes unused connections, and creates new connections if none exist that meet the current need.

Servers    Each domain controller is represented by a server object. The server has a child object, NTDS Settings, which stores the inbound connections; that is, the connection objects for a server designate the connections from source domain controllers to the server object.

Sites    Sites define sets of domain controllers that are well connected in terms of speed and cost Domain controllers in the same site replicate on the basis of notification: when a domain controller has changes, it notifies its replication partners. Then the notified partner requests the changes, and replication takes place. Because there is no concern about replication speed or cost, replication within sites occurs as needed rather than as scheduled.



To allow for the possibility of network failure, which might cause one or more notifications to be missed, a default schedule of once per hour is applied to replication within a site, in addition to change notification.

Replication between sites occurs according to a schedule; you can use the schedule to determine the most beneficial time for replication to occur on the basis of network traffic and cost. A site is the equivalent of a set of one or more Internet Protocol (IP) subnets.



Under circumstances where connections cannot be initiated between both sites (for example, when one site requires a dial-up connection), reciprocal replication can be initiated on the basis of changes rather than a schedule. (For more information about reciprocal replication, see "Reciprocal Replication" later in this chapter.)

Subnets    Computers on TCP/IP networks are assigned to sites based on their location in a subnet or a set of subnets. Subnets group computers in a way that identifies their physical proximity on the network. Subnet information is used during the process of domain controller location to find a domain controller in the same site as the computer that is logging on. This information also is used during Active Directory replication to determine the best routes between domain controllers. For more information about subnets, see "Introduction to TCP/IP" in the Microsoft ® Windows ®  2000 Server Resource KitTCP/IP Core Networking Guide .

Site Links    For replication to occur between two sites, a link must be established between the sites. Site links are not generated automatically and can be created in Active Directory Sites and Services. Unless a site link is in place, the KCC cannot create connections automatically between computers in the two sites, and replication between the sites cannot take place. Each site link contains the schedule that determines when replication can occur between the sites that it connects. The Active Directory Sites and Services user interface guarantees that every site is placed in at least one site link. A site link can contain more than two sites, in which case all the sites are equally well connected.

Bridgehead Servers    To communicate across site links, the KCC automatically designates a single server, called the bridgehead server , in each site to perform site-to-site replication. Subsequent replication occurs by replication within a site. When you establish site links, you can designate the bridgehead servers that you want to receive replication between sites. By designating a specific server to receive replication between sites, rather than using any available server, you can specify the most beneficial conditions for the connection between sites. Bridgehead servers ensure that most replication occurs within sites rather than between sites.

Site Link Bridges    When more than two sites are linked for replication and use the same transport, all of the site links are "bridged" in terms of cost by default, assuming that the site links have common sites. When site links are bridged, they are transitive . That is, all site links for a specific transport implicitly belong to a single site link bridge for that transport. So in the common case of a fully routed IP network (in which all sites can communicate with each other by IP), you do not have to configure any site link bridges. If your IP network is not fully routed, you can turn off the transitive site link feature for the IP transport (the Bridge all site links option on the General tab in the IP transport object property sheet or SMTP transport object property sheet). In this case, all IP site links are considered intransitive, and you configure site link bridges. 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 the bridge.

Sites Container Hierarchy in Active Directory

Active Directory Sites and Services is the administrative tool that you use to view and manage the hierarchy of objects that are used by the KCC to effect the replication topology. The hierarchy is displayed as the contents of the Sites container, which is a child of the Configuration container. The distinguished name of the Sites container is cn=Sites,cn=Configuration,dc=< ForestRootDomain >. The Configuration container is the topmost object in the configuration directory partition and the Sites container is the topmost object in the hierarchy of objects that are used to manage and implement Active Directory replication. The Sites container hierarchy contains the following objects:

  • The Sites container, which contains an object for each site in the forest. In addition to site objects, Sites also contains the Subnets container, which contains subnet definitions in the form of subnet objects. Each subnet object has a siteObject attribute that links it to a site object.

  • Site objects, each of which contains two child objects:

    • The NTDS Site Settings object, which stores directory properties common to all domain controllers in the site, including the schedule for replication within the site.

    • The Servers container, which stores a server object for each domain controller in the site.

  • Server objects, each of which contains an NTDS Settings object.

  • NTDS Settings object, which represents an instantiation of Active Directory on that server. (When Active Directory is removed from a server, its NTDS Settings object is deleted from Active Directory, but its server object remains.) For a specific server object, the NTDS Settings object contains the individual connection objects that represent the inbound connections from other domain controllers in the forest that are currently available to send changes to this domain controller.

  • Connection objects, each of which represents a unidirectional replication agreement between two specific domain controllers, where the destination domain controller is the server object that is the parent object of the NTDS Settings object that stores the connection. Connection objects are created automatically by the KCC; they can also be created manually.

Figure 6.5 shows the expanded Sites container. The NTDS Settings object for one server is selected, and the related connection objects are displayed in the details pane. The From Server column displays the name of the domain controllers from which the selected domain controller receives replication (the names of its current replication partners).


Figure 6.5 Hierarchy of Objects in the Sites Container

For information about how to create and manage objects in the Sites container, see Windows 2000 Server Help.