Issues with Active Directory Domain Services database

[garybreeze]

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

[DJamesS]

The approach to resolving the issue, transfer roles, demote server, promote server seems sensible. What i would add is, make sure you do a System State backup of both the troubled server and a 'known good' server. This give you an option to get back to a good copy of Directory Services if things don't go to plan. Before attempting to do anything with Directory Services, also ensure that your Domain Controllers have a 'known good' DNS server specified in the IPv4 settings. Before and after the work, dcdiag, repadmin /replsummary and repadmin /showrepl are great command for checking general DC health and importantly, how well the replication is working. Be interested to hear how you get on.

[Archipelego1]

Hi there Gary,

 

Do you have an update on how you resolved this issue?

 

We're having exactly the same problem and just in the process of troubleshooting

[3s-gtech]

We used to get these replication issues with 2008 R2, I can't remember the exact problems but it was due to errors/inconsitencies in the JET database. This would results in GPs, scripts etc in the sysvol not being replicated between DCs. In 2008 R2 these had to be manually flushed through (which meant checking the logs if a problem was noticed - hardly a slick system) by running the commands in the error log. Server 2012 and 2012 R2 resolved this by doing it automatically, and we've had no issues with this since.

 

If you can get it fired up again with the commands and tools shown, I would recommend looking at moving to the newer OSs if possible. If you can't fix it, drop down to one DC (make sure that it's well backed up) and re-promote.

[Archipelego1]

Thanks.

 

We have 2 DC's and backups. Just started running USB backups of the DC that isn't reporting issue, just incase fixing the 'faulty' DC breaks the working one. That way, my thoughts are, we can bare metal the working domain controller if we needed to.

 

The replication errors started last tuesday. Therefore, we're a bit out of sync now between the two DC's. Would it be better to try an fix the issue using the methods supplied in the event log. Or, just try and DCPromo the failing DC off the network?

[3s-gtech]

Try fixing first, as you could lose anything that hasn't replicated. This may be minor, or may be important - depends how much has been done since. Demoting the one DC (usually not the FSMO role holder) is a bit of a last resort.

[Archipelego1]

Thanks. Can you advise on the steps you think would work? The OP stated their steps didn't work.

 

For additional info, if the DC's are called DC0 and DC1 for example. DC1 is reporting the AD errors in event log, DC0 has no errors. Any changes made to DC1 are replicated to DC0. However, changes to DC0 don't replicate to DC1.

 

Additionally, like the OP, the error event view relates to a specific user account. If we try to edit the properties of this account on DC0, everything works. However, if we try to make changes to the account on DC1, we receive an error.

 

Therefore, I don't think we'd lose any AD changes by DCpromo'ing DC1 off in terms of lost changes as every change made on DC1 is replicating to DC0.

 

Hope this makes sense.

 

Thanks

[3s-gtech]

If you're happy that nothing important will be lost, go ahead. Demoting is a common task and is usually trouble free, in this case it may just be the ticket. Might be worth switching DC1 off for a bit, to see how it all works. As I said, when you rebuild, see if you can purchase (or just use an entitlement) Server 2012 R2. It's a great OS, and solves some older issues with AD replication.

[forid200]

The issues in 2008 with AD replication is real, I had to pretty much go through the same process as 3s-gtech. As stated above, if you are able to, try upgrading to 2012. Let us know of any updates.