Hi,
We are getting the following error in the logs of our primary DC and the replication is failing between this DC and the other two DCs because of an inconsistency in the database...........
This event contains REPAIR PROCEDURES for the 1084 event which has previously been logged. This message indicates a specific issue with the consistency of the Active Directory Domain Services database on this replication destination. A database error occurred while applying replicated changes to the following object. The database had unexpected contents, preventing the change from being made.
Object:
CN=JamesHartland21,OU=2021,OU=Students,OU=CHS,OU=Establishments,DC=chschool,DC=internal
Object GUID:
e403519c-64ca-4500-be87-afb8293a5193
Source domain controller:
5cfc9ae7-f189-4275-bcf8-9f79f3e42031._msdcs.chschool.internal
User Action
Please consult KB article 837932, http://support.microsoft.com/?id=837932. A subset of its repair procedures are listed here.
1. Confirm that sufficient free disk space resides on the volumes hosting the Active Directory Domain Services database then retry the operation. Confirm that the physical drives hosting the NTDS.DIT and log files do not reside on drives where NTFS compression is enabled. Also check for anti-virus software accessing these volumes.
2. It may be of benefit to force the Security Descriptor Propagator to rebuild the object container ancestry in the database. This may be done by following the instructions in KB article 251343, http://support.microsoft.com/?id=251343.
3. The problem may be related to the object's parent on this domain controller. On the source domain controller, move the object to have a different parent.
4. If this machine is a global catalog and the error occurs in one of the read-only partitions, you should demote the machine as a global catalog using the Global Catalog checkbox in the Sites & Services user interface. If the error is occurring in an application partition, you can stop the application partition from being hosted on this replica. This may be changed using the ntdsutil.exe command.
5. Obtain the most recent ntdsutil.exe by installing the latest service pack for your operating system. Prior to booting into Directory Services Restore Mode (DSRM), verify that the DSRM password is known. Otherwise reset it prior to restarting the system.
6. In DSRM, run the NT CMD prompt, run "ntdsutil files integrity". If corruption is found and other replicas exist, then demote replica and check your hardware. If no replicas are present, restore a system state backup and repeat this verification.
7. Perform an offline defragmentation using the "ntdsutil files compact" function.
8. The "ntdsutil semantic database analysis" should also be performed. If errors are found, they may be corrected using the "go fixup" function. Note that this should not be confused with the database maintenance function called "ESE repair", which should not be used, since it causes data loss for Active Directory Domain Services Databases.
If none of these actions succeed and the replication error continues, you should demote this domain controller and promote it again.
Additional Data
Primary Error value:
8451 The replication operation encountered a database error.
Secondary Error value:
-1526 JET_errLVCorrupted, Corruption encountered in long-value tree
We have tried the following without success:
We have tried the following so far:
Stopped Active Directory Domain Services (note this service has dependences and stopping them has the knock on effect of slowing down any traffic going out through our Smoothwall to the internet)
Went to a command prompt and run:
ntdsutil
ac I ntds
semantic database analysis
go fixup
rebuild quota
Also tried:
ntdsutil
files
recover
integrity (came up with a message to say the database is CURRUPTED!!)
We are now looking at moving the FSMO roles to a second DC and then demoting and promoting the DC containing the errors.
Does anyone see any issues with doing this, or have a suggestions as to anything else we can try before demoting the DC? Also, if we were to hold off doing this to mid next week when it is a quieter time, does anyone foresee an issue this (as long as we don't make any directory changes directly on the DC containing the errors), or do we need to fix the issue urgently, say this weekend.
Gary