NTDS.dit file corruption - every 2days

[mcrompton01]

Hi all,

 

I'm hoping someone might be able to give us some advice. Our second domain controller (server 2012) fails with the following message (approx.) every couple of days:

 

NTDS (700) NTDSA: The database page read from the file "C:\Windows\NTDS\ntds.dit" at offset 121454592 (0x00000000073d4000) (database page 14825 (0x39E9)) for 8192 (0x00002000) bytes failed verification due to a lost flush detection timestamp mismatch. The read operation will fail with error -1119 (0xfffffba1).  
If this condition persists, restore the database from a previous backup.  This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem.

 

We have tried NTDSUTIL etc. to no avail, ran a consistency check on disks so at the moment we demote the affected server then promote it again, the problem goes away for a couple of days then bang same or similar message. The other DC (server 2012 which owns all the FSMO roles) appears fine with no error or warning messages in the event log.

 

Anyone got any ideas why this might be happening as the current 'fix' well isn't a fix!

 

Cheers

Mark

[psydii]

"This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem."

 

That seems the most likely.

 

"NOTE:As mentioned earlier, mostly the corruption happens due to hardware problems. Please run appropriate diagnostics and ensure that there is no problem with the hardware. If the NTDS and Sysvol folders paths are modified (not on the local machine and stored on a remote machine/SAN/NAS,etc) then ensure that there are no access problems. If Anti-Virus software is running on the DC then ensure that it is up-to-date and the NTDS/Sysvol folders are excluded from the AV scan, you can refer to the following Microsoft Knowledge Base article (KB822158) for the virus scanning recommendations on Domain Controllers Click here for KB 822158 at Virus scanning recommendations for Enterprise computers that are running currently supported versions of Windows"

Source:Event ID 217 and Event ID 474 from NTDS ISAM and NTDS.dit File Corruption | HP® Support

Edited March 13, 2014 by psydii

[jricha34]

This message is indicative of a likely issue in your disk subsystem. This event comes from some new functionality built into the Windows 8 / Server 2012 and newer versions of ESENT to detect lost flushes during runtime (but not during boot, crash, power outage, etc - those are still completely undetected until you hit the corruption with applications or newer operating systems). Lost flushes are very bad and cause corruption in the Active Directory Database. This type of corruption is the most insidious type of corruption as it causes unknown divergence, index corruption, bad page links, and uninitialized AD/LDAP failures that may not show up for even months down the road and then suddenly jump out at you when implementing new functionality (new versions of Exchange are great for finding corruption) or bringing in newer OS Domain Controllers that prevent you from moving forward in your deployments. Translation, you could get corruption that isn't detected until AFTER all of your backups are compromised.

 

Anytime you make the path from the CPU to the bits on the storage medium more complex (such as virtualization, SANs, complex RAID configurations, complex caching hardware/software, data deduplication, etc) you raise the overall risk for corruption to occur. It is absolutely essential to the overall health of your Directory to catch these failures and remediate the underlying platform issues ASAP when encountered and hope that the corruption hasn't replicated to the rest of your environment.

 

Unfortunately at this time (and probably not anytime in the near future), it is not possible to authoritatively scan an Active Directory Database and find all forms of corruption. If you perform various ESENTUTL commands you may or may not find corruption that exists. You may or may not be able to repair it if you find it. Keep in mind corruption can range from high level unimportant stuff like a description being changed to odd characters that can be corrected with a simple LDAP update to deep table level corruption that cannot be corrected in any way.

 

joe

[telluride]

I have this same issue, it happens every couple days. I upgraded my domain from 2008R2 to 2012R2 over the past weekend. I have not attempted to disjoin and rejoin, but I will say they are both 2012 R2, virtualized on ESXi 5.1u1, I have a VNX 5300 running NFS. I have an Exchange 2012 R2 that has never reported any issues like this. I have 30 other VM's in my environment, no reported ESENT issues.

 

mcrompton01 - where have you gotten with this?