Replication Process

Features such as multimaster replication and store-and-forward replication mean that a domain controller could receive AD DS updates from multiple domain controllers and that AD DS replication traffic could take more than one path between domain controllers. For example, if a change is made to AD DS on DC1, the change could be replicated directly to DC2 and DC3. Because of the store-and-forward replication model, DC2, after receiving the update from DC1, may try to replicate the same change to DC3. AD DS replication is designed to ensure that the replication process is efficient while still providing redundancy.

Update Types

Two types of changes can be made to the AD DS information on a particular domain controller. The first type of update is an originating update. An originating update is performed when an object is added, modified, or deleted on a domain controller. The second type of update is a replicated update. A replicated update is performed when a change made on another domain controller is replicated to the local domain controller. By definition, there can be only one originating update performed for any particular change, and this occurs on the domain controller where the change is made. This originating update is then replicated to all the domain controllers that have a replica of the affected AD DS partition.

Originating updates occur in AD DS under any of the following circumstances:

• A new object is added to AD DS Adding a new object to AD DS creates an object with a unique objectGUID attribute. As well, all values assigned to attributes that are configured for the object are assigned a version number of 1.

• An existing object is deleted from AD DS When an object is deleted from AD DS, it is marked as deleted, but not immediately removed from the AD DS data store. Only after the tombstone expires on the object is the object actually deleted. For more details, see the section “Replicating Object Deletions” later in this chapter.

• The attributes for an existing object are modified This modification can include adding a new value to an attribute, deleting a value for an attribute, or modifying an existing value. When you change an object, the modify request compares the new value for each attribute with the existing value. If the value for an attribute has not changed, the attribute is not updated. If the value has changed, the attribute is updated and the version number for each updated attribute is incremented by one.

• An object in AD DS is moved to a new parent container If the parent container is renamed, each object in the container is also moved to the renamed container. When an object is moved to another container in AD DS, the only attribute that changes for the object is the name attribute, which is changed to reflect the new location in the LDAP hierarchy.

All originating updates to AD DS are atomic operations, which means that when an update is committed to AD DS, either the entire transaction is committed and the change is made to the data store, or no part of the update will be committed. For more information on the process of committing changes to the AD DS data store, see Chapter 14, “Monitoring and Maintaining Active Directory.”

The Replication Process in Windows Server 2008 Windows Server 2003 introduced several important changes to the replication process that are also available in Windows Server 2008. One change is the linked value replication. In Windows 2000, the smallest unit of replication is an attribute. This means that in some cases, changing one value in a multivalued attribute can create a significant amount of replication traffic. The most common example of this is what happens with universal group membership. Because the entire membership list for the universal group is one attribute, adding a single user to the universal group results in significant replication, especially when the group already has several thousand members. In Windows Server 2003 Active Directory and Windows Server 2008 AD DS, multivalued attributes like group membership can be updated by replicating only the change to the attribute by using linked value replication. AD DS uses linked attributes to enable linked value replication. Linked attributes always include a forward link and backward link to create a link between two AD DS objects. The forward link is the linked attribute on the source object (for example, the member attribute on the group object), whereas the backward link is the linked attribute on the target object (for example, the memberOf attribute on the user object). A backward link value includes the distinguished names of all the objects that have the object’s distinguished name set in their corresponding forward link. The relationships between linked attributes are stored in a separate table in the directory database as link pairs. The matching pair of Link IDs ties the attributes together. For example, the member attribute has a link ID of 2 and the memberOf attribute has a link ID of 3. Because the member and the memberOf attributes are linked in the database and indexed for searching, the directory can be examined for all records in which the link pair is member/memberOf and the memberOf attribute identifies the group. Another important change in Windows Server 2003 Active Directory is the support for groups of more than 5,000 members. In Windows 2000, groups cannot contain more than 5,000 members because of the attribute-level updates and replication. The practical limit for committing a change to the directory database in one transaction is 5,000. This also defines the maximum number of updates that can be replicated in one update during replication. As a result, the maximum group size in Windows 2000 is 5,000 members. In Windows Server 2008 AD DS, support for modifications of only one value on a multivalued linked attribute removes these restrictions.

Replicating Changes

After an originating update has been committed to AD DS, the change must be replicated to other domain controllers that host a replica of that partition. Within a site, the domain controller where the originating update occurred waits 15 seconds before replicating the changes to its direct replication partners. The 15-second wait occurs so that if multiple updates are committed to the database, they can all be replicated at the same time. This increases the efficiency of the replication. Between sites, the originating update will be replicated to replication partners based on the schedule configured on the site link.

When replicating changes to the directory information, the domain controllers require a mechanism for managing the flow of replication. To optimize AD DS replication, only those changes that need to be replicated between two domain controllers should be sent. To accomplish this, the domain controllers should be able to determine which, if any, changes have not yet been replicated, and then replicate only those changes that are required. AD DS uses a combination of update sequence numbers (USNs), high-watermark values, up-to-dateness vectors, and change stamps to manage directory replication.

Update Sequence Numbers

When an object is updated in the database, an update sequence number (USN) is assigned to the update. The USN is specific to the domain controller where the update occurred. For example, if a telephone number update for one user was assigned USN 5555, the next change to the domain controller, regardless of which object was modified, would be USN 5556. One USN is assigned for each committed change. If multiple attributes are changed with one update (for example, a user’s address, telephone number, and office location are all modified at once), only one USN is assigned during the update.

There are three ways that the USN is used when an update is committed. First, the local USN value is stored with the attribute that was updated. The local USN value identifies the USN of the changed attribute. The second way the USN is used is for the object’s uSNChanged attribute. This attribute is stored with each object and identifies the highest USN for any attribute for the object. For example, suppose a user’s telephone number was changed and the USN applied to that change was 5556. Both the local USN and the uSNChanged attribute will be set to 5556. If the next update applied to the directory on that server were an address change for the same user, the local USN on the address attribute and the uSNChanged attribute for the user object would both be changed to 5557. However, the local USN for the telephone number attribute would remain at 5556, because that was the USN for the last update that changed that particular attribute.

The local USN and the uSNChanged attribute are applied for both originating and replicated updates. The last way the USN is used is as the originating USN for the attribute. This value is set only for originating updates and is replicated to all other domain controllers as part of the attribute replication. When the telephone number for a user is changed on a server, the USN for the change is assigned to the originating USN value. When the modified telephone number is replicated to another domain controller, the originating USN is sent along with the update, and this value is not modified on the destination domain controller. The local USN and the uSNChanged attribute will be modified on the destination domain controller (and will be specific to that domain controller), but the originating USN is not changed until the attribute itself is updated again. The originating USN is used for propagation dampening, which is described later in this chapter.

Viewing USN Information The USNs for any object can be viewed through different administrative tools included with Windows Server 2008. The easiest way to view the current and original USN values for an object is to use the Active Directory Users And Computers administrative tool. To view this information, turn on Advanced Features under the View menu and then access the Object tab in the object’s Properties sheet. Remember that the USN number is domain controller-specific, so that if you view the USN for an object on two different domain controllers, the USN will be different. One way to view the local USN, originating domain controller, originating USN, and time stamp for any attribute is by using the Repadmin command-line tool. Type repadmin /showobjmeta domaincontrollername objectdistinguishedname at a command prompt. Figure 4-1 shows the partial output from this command. Figure 4-1. Viewing replication metadata using Repadmin. [View full size image] In this output, you can see that the user was created on SEA-DC1, but then the description and telephoneNumber attributes were modified on SEA-DC2. The originating USNs for all of the attributes except these two are from SEA-DC1, but the originating USNs for the description and telephoneNumber attributes are from SEA-DC2. However, the local USN numbers are all from SEA-DC1, which is the domain controller where this information was captured. As well, the version number for these two attributes is 2, indicating that the attribute has been modified from the original version. You can also access the same replication information through the Ldp tool. To do this, connect and bind to a domain controller using Ldp, locate the object, and then right-click the object, select Advanced, and then select Replication Metadata. The replication metadata is the same information as is shown in the Repadmin tool, except that the originating DSA information is shown using the domain controller globally unique identifier (GUID) rather than the display name.

High-Watermark Values

The high-watermark values are used to manage what information is replicated between domain controllers. Each domain controller maintains its own set of high-watermark values for each of its direct replication partners. The high-watermark is just the latest uSNChanged value that the domain controller has received from a specific replication partner. When a domain controller sends an update to a replication partner, the uSNChanged value is sent along with the update. The destination domain controller retains this uSNChanged as the high-watermark value for the replication partner.

The high-watermark values are used during the process of replication. When one domain controller requests updates from another domain controller, the destination domain controller sends its high-watermark value for use by the source domain controller. In effect, the high-watermark is telling the source domain controller which updates the destination domain controller has already received. The source domain controller uses the destination domain controller’s high-watermark to filter all of the potential directory updates and sends only the changes with a higher uSNChanged value.

Up-to-Dateness Vectors and Propagation Dampening

The up-to-dateness vectors are also used to control what information is replicated between domain controllers. The up-to-dateness vectors are used to keep track of all of the originating updates that a domain controller has received from any domain controller. For example, suppose the telephone number for a user is changed on DC1 and the attribute is given the originating USN of 5556. When this attribute is replicated to DC2, the originating USN is replicated with the updated attribute. Also, the server GUID for DC1 is replicated with the attribute. When DC2 receives this update, it will modify its up-to-dateness vector to show that the latest originating update it received from DC1 is now 5556.

When a destination domain controller requests updates from a source domain controller, it includes its up-to-dateness vectors with the request. The source domain controller then uses this information to filter the list of all possible updates it could send to the destination domain controller. This option is important when there are more than two domain controllers for a directory partition. For example, if DC3 is added to the scenario described in the preceding paragraph, the telephone number change made on DC1 will be replicated to both DC2 and DC3. Now both DC3 and DC2 will have the updated telephone number, and they will modify their up-to-dateness vector to show that the latest update both of them received from DC1 had an originating USN of 5556. About 15 seconds after receiving this update, DC2 will notify DC3 that it has updated information. When DC3 requests the directory updates from DC2, it will include its up-to-dateness vector with the request. In this case, DC2 determines that DC3’s up-to-dateness vector for DC1 already has the most recent originating USN. If this telephone number update were the only change made to the directory during this time period, no information would be replicated between the DC2 and the DC3 domain controllers.

This process of limiting the updates sent during replication by using the up-to-dateness vector is called propagation dampening. This is an important feature because AD DS is designed to create redundant replication connections between domain controllers. One of the problems with creating the redundant links is that the same updates might be sent to a domain controller from multiple replication partners. This could create a significant amount of unnecessary replication traffic, as well as potentially leading to a situation where the same update is sent repeatedly to all domain controllers (resulting in a replication loop). Propagation dampening using the up-to-dateness vector eliminates this possibility.

The high-watermark and up-to-dateness vector are used together to limit replication traffic. The high-watermark identifies the latest change that a domain controller received from another specific domain controller, so the source domain controller does not need to resend changes. The up-to-dateness vector identifies the most recent changes that have been received from all other domain controllers that contain a replica of the partition, so that the source domain controller does not have to send any directory updates that the destination domain controller has received from another replication partner.

Change Stamps and Conflict Resolution

The last property that is used to manage the replication between domain controllers is a change stamp. Whenever an attribute is updated, this modification is marked with the change stamp. The change stamp is then sent with the update when it is replicated to other domain controllers. The change stamp is used to determine which change will be accepted in the case of a replication conflict. The change stamp consists of three components:

• Version number This is used to track the number of changes that have been made to an attribute on an object. When an object is created, the version number on all attributes is set to 0 if the attribute is left blank. When a blank attribute is assigned a value, the version number is incremented to 1. Whenever the attribute is updated, the version number increments by one each time.

• Last write time This is used to track when the last write occurred to the attribute. The time value is recorded on the server where the attribute is updated and is replicated with the object to other domain controllers.

• Originating server This is the GUID for the server where the last originating update to the attribute was applied.

These three components form the change stamp for every modification to an attribute. When the attribute is replicated to another domain controller, this change stamp information is replicated with the attribute. If an attribute is changed on one domain controller and the same attribute is changed on another domain controller before the update is replicated to the second domain controller, this change stamp is used to determine which attribute is accepted as the final change. If a conflict arises, the decision as to which is the final change is made in the following order:

The AD DS replication process is able to resolve conflicts that are created when the same attribute on an object is modified on two domain controllers at the same time. However, there are at least two other types of conflicts that can arise:

• Adding an object or modifying an object on one domain controller at the same time that the container object for the object is deleted on another domain controller: Take an example in which on one domain controller a new user is added to the Accounting organizational unit (OU). At the same time, on another domain controller, another administrator deletes the Accounting OU. In this case, the container will be deleted on all domain controllers through replication, and the object that was added to the deleted container will be moved to the LostAndFound container in AD DS.

• Adding objects with the same relative distinguished name into the same container: An example of this conflict is when an administrator on one domain controller creates a user object with a relative distinguished name of Bill in the Accounting OU, and at the same time, on another domain controller, a user with the same relative distinguished name is moved into the same OU or created in the same OU. In this case, the conflict resolution model will use the GUID assigned to the directory updated to determine which object is kept and which object is renamed. The object with the higher GUID is retained, and the object with the lower GUID is renamed to Bill*CNF:userGUID, where the number sign (*) is a reserved character. If the second user object is required, it can be renamed.

Replicating Object Deletions

The replication of object deletions is handled differently in AD DS than other directory updates. When an object like a user account is deleted, the object is not immediately deleted. Rather, a tombstone object is created. The tombstone object is the original object where the isDeleted attribute has been set to true, and most of the other attributes for the object are removed from it. Only a few attributes that are required to identify the object, such as the GUID, SID, SIDHistory, and distinguished name, are retained. Deleted objects are stored in the Deleted Objects hidden container. Every directory partition has a Deleted Objects container.

This tombstone is then replicated to other domain controllers in the domain. As each domain controller receives the update, the modifications that were made on the originating domain controller are applied to each domain controller. The tombstone objects remain in the domain database for a specified period of time, called the tombstone lifetime. At the end of the tombstone lifetime, set to 180 days by default, each domain controller removes the tombstone from its copy of the database. This process of removing the tombstones from the database is called garbage collection. By default, the garbage collection interval for the forest is set at every 12 hours. This means that every 12 hours, the garbage collection process runs and deletes any tombstones that have passed the tombstone lifetime value.

Linked attributes can result in special cases when deleting objects. When an object is deleted, the following changes are made to the linked attributes:

• All of the forward links on the deleted object are removed. For example, if a group object is deleted, all of the member links on the group object are removed. This means that the group is removed from the memberOf back-link attribute on each user that was a member of the group.

• All the back-links on the deleted object are removed. For example, if a user is deleted, the user’s distinguished name value is removed from the member attributes of each group object that is named in the memberOf attribute of the deleted user.

After the linked attribute has been modified on one domain controller, the updates are replicated to other domain controllers just like any other updates.