Home > Articles > Certification > Microsoft Certification

Examining Replication and Trusts

  • Print
  • + Share This
Windows 2000 expert Curt Simmons discusses replication and trust relationships in the Active Directory.
Curt Simmons has written nearly a dozen technical books and training manuals. This article is excerpted from his book, CORE MCSE: Designing a Windows 2000 Directory Services Infrastructure (Prentice Hall PTR, 2000, 0-13-089683-7).
Like this article? We recommend

Replication is the process of sending and receiving directory update information. Because all Windows 2000 domain controllers maintain a copy of the Active Directory database, replication must frequently occur, or else each domain controller's database would soon become useless. Replication ensures that a domain controller's database is accurate and "in sync" with all other domain controllers.

Windows 2000 uses multi-master replication for the Active Directory. In multi-master environments, all domain controllers function as peers, and all replicate Active Directory database changes to each other. There is no single master replicator; all domain controllers are responsible for the replication tasks. Multi-master replication is effective because changes to the Active Directory can be made at any domain controller. For example, if an administrator adds a new object to the Active Directory on a particular domain controller, that domain controller is responsible for sending that change to all other domain controllers. Without effective replication, an Active Directory environment would quickly fall apart because each domain controller would be unaware of changes made by other domain controllers.

It is important to note the difference between directory replication and directory synchronization. Replication occurs between domain controllers in a Windows 2000 network. Directory synchronization occurs between different directories, such as Active Directory and Novell Directory Service (NDS). Because each directory uses a different schema, an agent is established that is considered a security principal for both directories. The agent replicates data between the two directory services by mappings between the two schemas. This process is known as synchronization.

How Replication Works

Active Directory replication is performed through multi-master replication, and only changes are replicated. In other words, changes to the Active Directory can be made at any domain controller, and only the change that is made will be replicated to all other domain controllers. The replication process is invisible to administrators and users. After a change has been made, a process occurs that ensures that the data is replicated to domain controllers, and that errors do not occur. The following sections outline the replication process.

The process first begins with a change notification, which is sent to all domain controllers so they know that there was a change in the Active Directory database, and the change is about to be replicated. After the change notification is sent, the process continues with an update request.

When a domain controller needs to replicate update data, an originating update is established, which determines the kind of change that needs to be made to the Active Directory database. There are four different kinds of originating updates: Add, Modify, ModifyDN, and Delete. The Add update adds an object to the Active Directory. For example, if you add a new shared folder, the Add update replicates the information to all domain controllers. The Modify update changes an attribute of an existing object. For example, if you change a user account's group membership, the Modify update replicates this change. Next, the ModifyDN update changes the name of an object or an object's parent. Finally, the Delete update deletes an object from the Active Directory.

By using originating updates, changes to the Active Directory can be replicated. The task of creating an originating update is performed at the domain controller where the change was made. When the change is replicated to the other domain controllers, the update is known as a replicated update on those domain controllers, shown in Figure 1. The replicated update occurs because of an originating update from another domain controller. When an originating update occurs, a stamp is attached to the updated attribute so it can be updated on all domain controllers.

Figure 1 Originating and replicated updates.

A major feature of the replication process are Update Sequence Numbers (USNs), which are assigned numbers that are stored in a USN table on each domain controller. The USN table is used to determine the updates that need to occur between domain controllers. In other words, when a change occurs in the Active Directory, the domain controller where the change was made updates the USN so that all other domain controllers have an outdated USN for that attribute. When replication occurs, the USN is updated on all domain controllers. The USN allows other domain controllers to know they have an outdated USN and that the replication update needs to be processed. Due to the use of USNs, timestamps on replication data are not necessary, although they are still maintained by the Active Directory and used in certain circumstances. For example, if an administrator at one domain controller makes a change to a user account phone number, and an administrator at another domain controller makes the same change, the timestamp is used to "break the tie" between the two updates.

Another issue that can potentially occur with Active Directory replication is unnecessary replication traffic. The Active Directory maintains a replication "loop" so that domain controllers have more than one path for sending and receiving replication traffic. However, the loop could allow updates to be sent to the same domain controller more than once. The Active Directory prevents this from happening through a process called propagation dampening, which allows domain controllers to detect when replication of data has already occurred on other domain controllers. When the domain controllers detect this, they do not send the same replication data where it has already been replicated. Figure 2 gives you a basic representation of propagation dampening. Because replication has already occurred at Server3, Server4 halts the replication to Server3 through propagation dampening. This prevents Server3 from receiving the same replication data twice.

Figure 2 Propagation dampening.

Propagation dampening occurs through the use of two vectors. Vectors are made up of pairs of data that combine a GUID (globally unique identifier) and a USN. The two vectors are called the Up-to-Date Vector and the High Watermark Vector. The Up-to-Date Vector contains server USN pairs, and represents the highest originating update. The High Watermark Vector holds the USN numbers for attributes that were added or modified in the directory and are stored in the replication metadata (which is simply "data about data") for that attribute. Through both vectors, propagation dampening can occur and unnecessary Active Directory updates can be avoided. Propagation dampening is an internal process that is invisible to administrators.

Along with propagation dampening, the Active Directory replication also has the tasks of solving replication conflicts. Because the Active Directory uses multi-master replication, there can be conflicts in changes. For example, if two administrators working on two different domain controllers make changes to the same attribute on the same object, a "collision" will occur when the data is replicated. The Active Directory attempts to minimize collisions by replicating data changes at the attribute level instead of the object level. This way, two different administrators on two domain controllers can make changes to the same object. As long as they are not making changes to the same attribute of that object, a collision will not occur. However, even the strategy of attribute level replication does not stop all collisions. In this case, the Active Directory must resolve collisions that occur. Resolution is accomplished through the use of timestamps and version numbers that are recorded in the metadata for that attribute. In the case of a collision, the domain controller(s) where the collision occurs will examine the timestamp and version number of the attribute, and use the one that has the highest value. In the extreme case in which the version numbers and timestamps match, the highest Active Directory GUID is used to break the tie. In any case, this collision-resolution process ensures that the latest change to the object attribute always wins the resolution, and is updated in the database.

Replication Partitions

Replication in an Active Directory environment functions at three major levels, and you should have a firm understanding of how partition replication occurs because this may impact some decisions you make as you design your Active Directory infrastructure. The three partitions are Schema, Configuration, and Domain.

The Schema Partition contains objects and attributes definitions. In other words, the Schema Partition contains a list of definitions that define what objects and attributes for those objects can exist in the Active Directory. Schema information is Enterprise in nature—all domain controllers in a tree or forest share a common schema, and any schema modifications are replicated across the forest. Because the schema defines objects and attributes, an object that is created, along with the object's attributes must follow the definitions of the schema.

The Configuration Partition contains information about the physical structure of the Active Directory, such as the sites and domains and where domain controllers reside in the Enterprise. Configuration information is replicated to all domain controllers in the tree or forest.

The Domain Partition contains information about all Active Directory objects that are specific to that domain, such as users and groups, OUs, and other resources. All Domain Partition information is completely replicated to all domain controllers within the domain. For Global Catalog Servers in other domains, a read-only subset of the domain partition is replicated. This allows the Global Catalog Server to know what is available in each domain so that other domain users can access resources, but changes to the domain partition can only be made from within the domain.

Obviously, a single Active Directory domain is much easier to implement in terms of replication. If your environment will use multiple domains, it is important to consider how replication will occur in your environment, and how global catalog servers should be placed.

Replication Topology

Now that you have a conceptual understanding of Active Directory replication, we turn our attention to the two types of replication topology: intrasite and intersite. Intrasite replication occurs within a site, which is a grouping of computers or domains that have high bandwidth. Typically, a site exists in a physical geographical location, although sites can exist in multiple geographic locations. For example, suppose that a company has two sites: Houston and Portland. Each site contains one or more domains and exists in one geographic place where high bandwidth is available. In a site, the Active Directory automatically generates a site topology. You can manually adjust it, but this is normally unnecessary.

For intersite replication, replication occurs between two sites in which there is normally lower bandwidth, or bandwidth is more expensive. You manually establish intersite replication through the Active Directory Sites and Services tool because it is not automatically generated by the Active Directory.

To fully understand replication topology, you need to understand how it is automatically accomplished in intersite communication through connection objects and the Knowledge Consistency Checker (KCC). The replication topology is the pathways that domain controllers use to send and receive replication traffic.

Replication occurs through direct replication partners among domain controllers. The Active Directory determines whether a domain controller will function as a direct replication partner or whether it will receive replication data through transitive replication from other partners. This determination is made through the KCC, which determines how to establish the replication topology so that all domain controllers can receive replicated data.

A connection object is defined as a potential direct replication partner (not transitive). Connection objects directly replicate with one another, and transitive partners receive replication data indirectly. Connection objects are unidirectional and are established automatically by the Active Directory, or they can be established manually by an Active Directory administrator. The automatic topology generation, performed by the KCC, uses data you provide –about sites and subnets within the site, as well as the cost of connections. The KCC then uses this information to generate a replication topology in a bidirectional ring (by default). The ring is constructed so that the average number of hops a directory change will have to make is no more than three. When a change is made that needs to be replicated, the replication engine begins its job by waiting for an interval when replication can occur, which is every five minutes by default. When the interval arrives, the domain controller notifies its first replication partner. Then, all other partners are notified in a delay manner that you can configure, with the default being 30 seconds. So, in a typical site using the defaults, the propagation of the change to all domain controllers is 15 minutes or less.

NOTE

It is important to keep in mind that the 15 minutes or less for propagation is theoretical. Because the Active Directory is implemented in large distributed environments, the speed of replication and potential problems remain to be seen.

As stated earlier, the Active Directory configures all of this on its own by using the information you enter in the Active Directory Sites and Services. You can manually configure the topology by creating additional connection objects or removing connection objects. The KCC does not delete any manually created connection objects. In the event of replication failure, however, the KCC will create new connection objects so that replication can resume.

In intrasite replication, the Active Directory normally does a good job of automatically generating a replication topology. For intersite replication, you need to take a look at your exiting links and the bandwidth available.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020