AD Sites, Part 2

In "AD Sites, Part 1," June 2000, I introduced Active Directory (AD) sites and explained how to create and configure them to control replication in your Windows 2000 forest. You're now ready to explore replication in depth and learn how to establish and maintain replication paths within a site and between sites. Let's put your knowledge about AD sites to work.

Directory Partitions
AD replication can be a complex process because AD has a multipartitioned architecture. In addition, each partition within AD can have several replication elements that affect one another. Microsoft collectively calls these partitions directory partitions, or naming contexts in the x.500 Directory Service (DS) standard. The most common partitioning method is to divide AD into domains. You find as many domain partitions as you have domains in a forest, and you replicate information among domain controllers within a given domain's boundaries.

AD also has other partitions in which you replicate information. The configuration partition contains information about the structure of the forest and its domains, which permits forestwide replication in the partition. The schema partition contains all class and attribute information (i.e., the AD database structure) for the forest; therefore, information replicates across the entire forest. You don't need to worry about configuration and schema partitions very often because their contents seldom change, so you typically don't have information to replicate. Also, the configuration and schema partitions replicate information forestwide, so you can group them in the same topology.

The Global Catalog (GC) is a replication element that you also need to become familiar with. AD's GC is the equivalent of a White Pages telephone directory. Similarly to how the White Pages indexes people and businesses, the GC indexes every object in the forest. The GC contains the most common information (e.g., user account, telephone number, email address) about an AD object and where you can locate it if you need more detail.

Although Microsoft doesn't list the GC as a directory partition, the GC has a replication topology that you must account for when you plan your site design and domain controller placement. The GC resides only on domain controllers that you flag as GC servers. For GC servers to be available throughout the forest, they must replicate their information to one another. GC servers contain only a few attributes, but they contain every AD object, which means they experience heavier replication traffic than other infrastructure servers. Whenever you add, change, or delete an object in the forest, the action ripples through all the GC servers. (For more information about the GC, see Zubair Ahmad, "An Overview of Active Directory," http://www.win2000mag.com/articles, InstantDoc ID 8178.)

Let's put this AD information into perspective. AD includes all the objects in the forest and all the objects' attributes. Unless you have only one domain, no one domain controller will contain all these objects. The portion of AD that resides on a domain controller is the domain partition's objects and attributes, a read-only configuration-partition replica, and a schema-partition replica. If you designate the domain controller as a GC server, the domain controller will contain every object in the forest (but only a few of the objects' attributes). A large company with large domains can have sizeable GC servers but not have one server that contains the entire AD content.

Replication Methods
Windows NT 4.0 uses a master-slave update model in which the master (i.e., the PDC) is the only copy of writeable domain information. The slaves (i.e., the BDCs) receive regular and frequent updates. Synchronization is necessary between only the PDC and BDCs. AD, however, uses a multiple-master update model in which all the domain controllers have writeable AD copies. Because all the domain controllers can create updates, they need a method to replicate their changes to one another. AD uses two replication methods—one for replication within a site (i.e., intrasite replication) and one for replication between sites (i.e., intersite replication).

Intrasite replication. When you make a change to a domain controller, the change must propagate through the domain controller's directory partition. With the exception of some special cases (e.g., account lockout, password changes), AD uses a loosely consistent replication model to propagate changes. Loosely consistent means that changes on a domain controller take a finite amount of time (5 minutes by default) to propagate to the domain controller's neighbor and across the domain controller's directory partition. For example, if users change their pager numbers, the time it takes for the changes to propagate across the domain depends on how many domain controllers the users' sites have, how many other sites the users' domains span, and the number of domain controllers in those other sites. Special cases cause urgent replication in which domain controllers don't wait the typical 5 minutes before triggering replication.

AD uses connection objects to support replication between domain controllers. A connection object is a one-way, remote procedure call (RPC)-based incoming replication route from a domain controller's neighboring domain controllers, which Microsoft calls replication partners. Similarly to how two one-way trusts form a two-way trust in NT 4.0, replication partners use two connection objects—one for each direction—to perform bidirectional replication, as Figure 1 shows.

You can observe a domain controller's connection objects in the Active Directory Sites and Services Microsoft Management Console (MMC) snap-in window. Double-click a site container to get a list of the site's domain controllers. Within a site, each domain controller has an NTDS object, which you can see when you double-click the domain controller. Double-click an NTDS object to see the connection objects that transport replication traffic from other domain controllers (i.e., inbound replication connection objects) to this domain controller. Right-click the inbound replication connection object and select the Replicate Now menu item to request an immediate update from a domain controller's replication partners.

Managing AD's connection objects is too labor-intensive to be a manual task. Fortunately, AD provides the Knowledge Consistency Checker (KCC), which dynamically configures and updates connection objects between domain controllers to create the replication pathways. The KCC is active on every domain controller and is the glue that holds AD together. You can't directly observe KCC as a service, but you can see its actions in the DS event log.

The KCC follows a specific algorithm to connect domain controllers within a site. The tool generates a list of the site's servers that hold a given directory partition (e.g., the domain partition) and uses connection objects to join the servers in a bidirectional ring, as Figure 2 shows. This ring topology ensures that if one server fails, the remaining servers can bypass the failed server to replicate with the other servers.

As you increase the number of domain controllers in a site, the KCC changes its algorithm to avoid the lengthy replication process of each domain controller passing the originating update to its neighbor. The KCC uses a three-hop rule in which no domain controller can be more than three replication hops from another domain controller. In this way, an update takes no more than three hops before it reaches another domain controller that has already received the update through another path.

To enforce the three-hop rule, the KCC creates optimizing connections (i.e., shortcuts) on the replication pathways between the domain controllers, as Figure 3 shows. The KCC creates the optimizing connections at random—not necessarily on every third domain controller. You can click each domain controller's NTDS containers in the Active Directory Sites and Services snap-in and draw lines between the domain controllers to manually draw out the replication topology. This task gets complicated, so you can use the Replmon tool to view the replication topology in more detail. (Replmon is a Win2K Support Tool that you can install from the \support\tools folder on the Win2K Advanced Server disk.) The KCC runs on every domain controller, and all KCCs use the same algorithm to create the site topology. Therefore, the domain controllers will replicate with one another until they all contain the same information.

A good site design can predict latency, which is how long an originating update on one domain controller in the forest will take to propagate to another point in the forest. For example, if an update originates on domain controller A in Figure 3, the maximum amount of time a change takes to replicate around a site (to domain controller B) is 15 minutes because AD's default replication interval is 5 minutes and KCC invokes the three-hop rule.

When you determine the amount of time an object or attribute will take to replicate through the forest, you must consider the type of object or attribute that you're replicating. For example, when users change their pager numbers, the changes replicate through only the users' domains. However, when users change their email addresses, those attributes replicate to all GC servers in the forest because email addresses are GC objects. Another change that takes more time to replicate through a forest is adding a new domain to the forest. When you add a domain in the configuration partition, you create a change that must replicate across all domain controllers in the forest.

   Previous  [1]  2  Next