Veeam Explorer for Microsoft Active Directory-JetError-1216

[nthelen]

Hello together,

i have a problem with Veeam Explorer for Microsoft Active Directory. When i restore the NTDS directory with logs and open the ntds.dit file, i got the following error:

Error: JetError -1216, JET_errAttachedDatabaseMismatch, An outstanding database attachment has been detected at the start or end of recovery, but database is missing or does not match attachment info

DC (NTDS.dit-Backup-File): Server 2008 SP2 32-bit
Veeam: Server 2008 SP2 64-bit
Exchange: 2007

Is it possible, that the Exchange-Version is the problem, or that the ntds.dit-file is recoverd from a 2008 SP2 32-bit DC and the Veeam Explore runs on an 64-bit server?

Thank you for your help!

Nico

[foggy]

Nico, I believe you can find the particular database that causes confusion in the Event Log. However it is always recommended to contact technical support with all technical issues like this one, so I encourage you to do so, if you want to keep this topic further.

[nthelen]

So i made a esentutl /mh with the restorede ntds.dit. The database is in dirty shutdown state. Logs and db are in the same folder (E:\NTDS). DC was backuped with application-aware processing and Guest File System indexing. So why is the db in dirty shutdown. Ich also controls the realtime ntds.dit. Its in clean shutdown. So veeam does not correctly backup the ntds.dit with logs.

[foggy]

Basically, backed up DB is always in a dirty shutdown state and you need logs to bring it to a clean state.

Please contact technical support for investigation of the original error and provide your case ID here, otherwise this topic will be removed by moderators according to the forum rules (available when you click New Topic).

[nthelen]

Case: 00688378

No its not basically, in vss-mode, that dbs with log truncation are in dirty shutdown!!! I made a case.

[Gostev]

So why is the db in dirty shutdown.

This is normal. We don't shut down VM during the backup, so from perspective of guest OS and applications, they experience "dirty shutdown". Even though they are properly quiesced with VSS at the moment when we take VM snapshot, both OS and applications keep running, and this is the state we capture in our backups. It is only when OS and applications physically shut down, they mark the shutdown as "clean" by setting up some flag in the registry, or in application's database.

As such, the only way to achieve "clean shutdown" state for applications and OS is to turn VMs off before you take a backup. However, there is really no point in achieving this state.

Anyway, judging on the error, your original issue is totally unrelated to this anyway.