AD DS: Strict replication consistency should be enabled on all domain controllers in this forest
Updated: August 31, 2012
Applies To: Windows Server 2008 R2, Windows Server 2012
This topic is intended to address a specific issue identified by a Best Practices Analyzer scan. You should apply the information in this topic only to computers that have had the Active Directory Domain Services Best Practices Analyzer run against them and are experiencing the issue addressed by this topic. For more information about best practices and scans, see Best Practices Analyzer (https://go.microsoft.com/fwlink/?LinkId=122786).
Operating System |
Windows Server 2008 R2 Windows Server 2012 |
Product/Feature |
Active Directory Domain Services (AD DS) |
Severity |
Warning |
Category |
Configuration |
Issue
Strict replication consistency is not enabled on this domain controller.
Impact
If strict replication consistency on this domain controller is not enabled, lingering objects can be replicated to this domain controller.
When a domain controller in your Active Directory environment is disconnected from the replication topology for an extended period of time, all objects that are deleted from AD DS on all other domain controllers might remain on the disconnected domain controller. Such objects are called lingering objects. When this domain controller is reconnected to the replication topology, it acts as a source replication partner that has one or more objects that its destination replication partners no longer have. Problems occur when these lingering objects on the source domain controller are updated and these updates are sent by replication to the destination domain controllers. A destination domain controller can respond in one of two ways:
If the destination domain controller has strict replication consistency enabled, it recognizes that it cannot update the object (because the object does not exist), and it locally halts inbound replication of the directory partition from that source domain controller.
If the destination domain controller does not have strict replication consistency enabled, it requests the full replica of the updated object, which introduces a lingering object into the directory.
An outdated domain controller can store lingering objects with no noticeable effect as long as an administrator, application, or service does not update the lingering object or attempt to create an object with the same name in the domain or with the same user principal name (UPN) in the forest. However, the existence of lingering objects can cause problems, especially if the object is a security principal. The following symptoms indicate that a domain controller has lingering objects:
A deleted user or group account remains in the global address list (GAL) on computers running Microsoft Exchange Server. Therefore, although the account name appears in the GAL, attempts to send e-mail messages result in errors.
Multiple copies of an object appear in the object picker or GAL for an object that should be unique in the forest. Duplicate objects sometimes appear with altered names, causing confusion on directory searches. For example, if the relative distinguished name (also known as DN) of two objects cannot be resolved, conflict resolution appends "*CNF:GUID" to the name, where * represents a reserved character, CNF is a constant that indicates a conflict resolution, and GUID represents the objectGUID attribute value.
E-mail messages are not delivered to a user whose Active Directory account appears to be current. After an outdated domain controller or global catalog server becomes reconnected, both instances of the user object appear in the global catalog. Because both objects have the same e-mail address, e-mail messages cannot be delivered.
A universal group that no longer exists continues to appear in a user’s access token. Although the group no longer exists, if a user account still has the group in its security token, the user might have access to a resource that you intended to be unavailable to that user.
A new object or Exchange mailbox cannot be created, but you do not see the object in AD DS. An error message reports that the object already exists.
Searches that use attributes of an existing object incorrectly find multiple copies of an object of the same name. One object has been deleted from the domain, but it remains in an isolated global catalog server.
Resolution
Use Repadmin to detect and remove lingering objects and to enable strict replication consistency on this domain controller.
Enabling the strict replication consistency setting on each domain controller in your forest prohibits replication of outdated Active Directory objects. In other words, if you disconnect a domain controller from the replication topology for an extended period and then reconnect it, this setting ensures that no lingering (outdated) objects are reintroduced into your Active Directory environment.
If strict replication consistency setting is not enabled on your domain controller, lingering objects might already exist on this domain controller. You should first remove lingering objects from this domain controller and then enable strict replication consistency on it by completing the following tasks:
Use the repadmin /removelingeringobjects command to detect and remove lingering objects from your domain controller.
The repadmin /removelingeringobjects command does the following:
Compares the directory database objects on a reference domain controller with the objects on the target domain controller that contains (or is suspected to contain) lingering objects.
Either removes the lingering objects or logs the potential deletions to the Directory Service event log, as follows:
If you use the /advisory_mode parameter, events are logged in the Directory Service event log for the objects that are found.
If you do not use the /advisory_mode parameter, the found objects are deleted without replicating the deletions. That is, the deletions occur only on the target domain controller.
Use the repadmin or regedit commands to enable strict replication consistency.
For detailed instructions about using repadmin and regedit to detect and remove lingering objects and enable strict replication consistency, see the “Resolution” section in Event ID 1388 or 1988: A lingering object is detected (https://go.microsoft.com/fwlink/?LinkId=148220).
Additional references
For more information, see Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042) (https://go.microsoft.com/fwlink/?LinkId=148221).