Select the product you need help with

Lingering objects prevent Active Directory replication from occurring

Article ID: 317097

This article was previously published under Q317097

SYMPTOMS

If lingering objects are present, inbound changes are not replicated to objects that do not exist on the target, and the following event ID message is logged in the event log:

Event ID: 1084
Replication error: The directory replication agent (DRA) couldn't update object CN="jeffsmith",OU=Wood,OU=sales,DC=yourcompany,DC=com (GUID 063639e5-cfa6-40f3-951c-62a34f8dea71) on this system with changes which have been received from source server 2521a874-d379-4281-8744-4bd34c792026._msdcs.bc.com. An error occurred during the application of the changes to the directory database on this system.

You receive the following error message:

There is no such object on the server.

The directory will try to update the object later on the next replication cycle. Synchronization of this server with the source is effectively blocked until the update problem is corrected. If this condition appears to be related to a resource shortage, please stop and restart this Windows Domain Controller.

If this condition is an internal error, a database error, or an object relationship or constraint error, manual intervention will be required to correct the database and allow the update to proceed. It is valuable to note that the problem is caused by the fact that the change on the remote system cannot be applied locally. Manually updating the objects on the local system in not recommended. Instead, on the source system (which has the changes already), try to reverse or back out the change. Then, on the next replication cycle, observe whether the change can now be applied locally.

Additionally, if you run the repadmin /showreps command on the domain controller, you receive the following error message

HQSite\DC1 via RPC
objectGuid: 2521a874-d379-4281-8744-4bd34c792026
Last attempt @ 2002-01-21 16:10.54 failed, result 8240:
There is no such object on the server.
Last success @ (never).

The Last success value may be either "never" or the last time a successful replication occurred. Active Directory replication is stopped for the specified naming context and does not resume until you resolve this problem. Replication to the other naming contexts continues as expected.

Back to the top | Give Feedback

CAUSE

This problem occurs because the Strict Replication Consistency functionality is being enforced on the inbound domain controller. Typically, this problem occurs because the domain controller that has the extra (or lingering) object has been out of replication for more than one tombstone lifetime.

The Strict Replication Consistency functionality was added in Windows 2000 Service Pack 3 (SP3) and in some post-Service Pack 2 (SP2) hotfixes. If your domain controller is logging the error messages that are described in the "Symptoms" section of this article, it is running a post-SP2 hotfix or SP3. For additional information about post-SP2 hotfixes, click the following article number to view the article in the Microsoft Knowledge Base:

314282

(http://support.microsoft.com/kb/314282/ )

Lingering objects may remain after you bring an out-of-date global catalog server back online

Back to the top | Give Feedback

RESOLUTION

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756

(http://support.microsoft.com/kb/322756/ )

How to back up and restore the registry in Windows

Strict Replication Consistency was created to prevent unwanted replication of lingering objects. Before Strict Replication Consistency was created, the inbound partner requested the entire object if the object did not exist locally and eventually replicated the object to all partners by default.

If the naming context that is listed in the error message only exists on the inbound domain controller as a read-only global catalog, an object may be re-created that may be difficult to remove. This problem may occur if the object only exists on global catalog servers and it has been deleted from the domain naming context. In this situation, Microsoft recommends that you purge the object from all of the global catalogs on which this object exists. Do not purge the objects until you verify that the object is intended and still exists in the domain naming context.

For additional information about how to purge objects, click the following article numbers to view the articles in the Microsoft Knowledge Base:

314282

(http://support.microsoft.com/kb/314282/ )

Lingering objects may remain after you bring an out-of-date global catalog server back online

After you intentionally delete an object that you do not want to re-create, if you decide that you need this object and if it exists in the domain naming context, use either of the following methods to enable replication.

Method 1: Tombstone and Garbage Collect the Object
1. Delete the object, enable Loose Replication Consistency (see Method 2), and then enable replication again.
  
  NOTE: If you do not enable Loose Replication Consistency, the object is garbage collected when the tombstone lifetime expires. After the object is garbage collected, normal replication resumes.
2. After the deletion has been replicated, enable Strict Replication Consistency again if appropriate.
Method 2: Enable Loose Replication Consistency

After you enable Loose Replication Consistency, make sure to enable Strict Replication Consistency again after the object has been replicated. If you enable Loose Replication Consistency, the error only reports the first object that does not exist on the target. Additional objects may exist, including some that exist in the read-only naming context (global catalog).

To enable Loose Replication Consistency, follow these steps on the domain controller that reports the errors messages that are described in the "Symptoms" section of this article:
1. Locate and click the following registry key:
  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
2. Click Add Value on the Edit menu.
3. Add the following value:
  Value Name: Strict Replication Consistency
  Data type: REG_DWORD
  Value data: If the value is 1, change it to 0.

Back to the top | Give Feedback

STATUS

This behavior is by design.

Back to the top | Give Feedback

MORE INFORMATION

Lingering objects may be a problem in the following scenarios:

The lingering object is holding a value on a unique attribute, such as samAccountName, that another object wants to use.
The lingering object is a security risk, for example, it may represent a user that you should have deleted.
The lingering object only exists in the read-only naming context (global catalog). This behavior makes the object difficult to delete.

If you enable Strict Replication Consistency, a destination stops replicating and you receive the error message that is described in the "Symptoms" section of this article if the destination receives modifications for an object that it does not have. Typically, this problem occurs when a good domain controller that does not have the object replicates in a change to a lingering object from a bad source that has been out of contact.

If you enable Loose Replication Consistency, if a destination receives a change to an object that it does not have, the entire object is replicated to the target for the sake of replication consistency. This behavior causes a lingering object to be reapplied to all domain controllers in the replication topology.

Back to the top | Give Feedback