Article ID: 253644 - View products that this article applies to.
This article was previously published under Q253644
This article has been archived. It is offered "as is" and will no longer be updated.
Under certain circumstances, inbound replication to Global Catalog (GC) servers can halt due to a database error. This database error is not database damage, but is caused by a scenario that is characterized by the following:
Event Type: Error Event Source: NTDS Replication Event Category: Replication Event ID: 1084 Date: 1/6/2000 Time: 10:27:05 AM User: Everyone Computer: MYGC Description: Replication error: The directory replication agent (DRA) couldn't update object CN=TestUG,CN=Users,DC=TestDomain,DC=com (GUID 8e5bf454-5940-4671-a253-d6ee93903a62) on this system with changes which have been received from source server f82ab77e-140e-4779-bd71-4b2166076488._msdcs.testdomain.com. An error occurred during the application of the changes to the directory database on this system. The error message is: The replication operation encountered a database error. 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. The record data is the status code. Data: 0000: 03 21 00 00 .!..
This problem can occur in the preceding example, because MYGC's local copy of the Active Directory indicates that "CN=TestUG,CN=Users,DC=TestDomain,DC=com" is a Universal group with no members and the source Domain Controller (known as Source Server in the event detail) is forwarding a change to TestUG that its group type has been modified to something other than Universal. Note that TestUG may or may not currently have members on the source Domain Controller.
To resolve this problem, obtain the latest service pack for Windows 2000. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
260910Note: For Datacenter Server, you need to obtain any service packs or hotfixes from the OEM vendor from which you purchased Datacenter.
(http://support.microsoft.com/kb/260910/EN-US/ )How to Obtain the Latest Windows 2000 Service Pack
To work around this problem, use either of the following methods:
Method 1Delete the group, and then recreate it with the newly desired group type. Although this is the simplest solution, it may be undesirable if TestUG is referenced in existing ACLs or has many members.
Method 2Ensure the group has at least one member, change the group type back to Universal, and then permit this change to replicate to all Global Catalog servers. After this replication is complete, the group may be changed from Universal to another group type.
Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article. This problem was first corrected in Windows 2000 Service Pack 1.