You need to boot the machine in "directory services restore mode", login with the local Administrator and the password you had to set when promoting the DC.
Move all the *.log files inside c:\windows\NTDS\ to a folder elsewhere.
Try to reboot in normal mode.
If it's not working go back in DSRM,
repeat the moving of any log files in c:\windows\NTDS\,
Open up a CMD (with Run as admin),
Enter the command "esentutl /p c:\windows\NTDS\ntds.dit",
Enter the command "ntdsutil",
In the ntdsutil prompt now enter the following commands (no quotes):
"activate instance ntds"
"Files"
"Compact to c:\temp\"
"quit"
"quit"
Now move the c:\windows\NTDS\ntds.dit file to a save folder elsewhere.
Copy the c:\temp\ntds.dit file to c:\windows\NTDS\
Again remove all the .LOG files inside c:\windows\NTDS
Reboot normally.
Make sure you have application-aware image processing enabled in the job settings. For further investigation, please contact our technical support directly.
I know this is an old thread but I came across it while trying to find a solution to my issue. After doing a Full Restore of the production server to a backup server, I also got the 0xc00002e2 error and found that the NTDS.dit file was trashed on the restored server.
I did a full restore several times, from more than one backup source, and always had the same issue. During the last restore processes I accidently chose to do an Instant Recovery and was pleasantly surprised to find that the server booted just fine and the NTDS.dit file wasn't corrupted.
I'm currently in the process of Migrating To Production so I don't know if that process was successful or not, but I wanted to post this info before I forgot to do it, in case someone else in my position is getting the 0xc00002e2 error - try doing an Instant Recovery!!
I'm using Veeam Backup & Replication 10 (10.0.0.4461 P2) Community Edition which I plan to upgrade soon, hoping that'll eliminate the issue.
I see only one possible explanation for different results of powering on a VM from bit-identical virtual disk: the production storage that was the target for full restore is misbehaving and corrupting the restored virtual disk data. While in case of instant recovery, the VM runs directly from backup storage.
One additional point.
For correct disaster recovery, you need to boot the domain controller WITH network enabled and don´t touch the console (have a look at the monitor and click or use any keyboard strokes) until it has booted multiple times in AD recovery mode.
If you enable the network, boot and do not touch the screen, then we automatically set the VM and AD in nonauthoritative restore mode (if you backed up with Guest Processing). If you interrupt the process by clicking into the console this process get´s interrupted at a maybe undefined state (not completed).
I wanted to add some more info... After the successful Instant Recovery I chose to do a Migrate To Production after which the server continued working just fine. I think this proves that my server HD system isn't corrupting anything.
To test what Andreas said I did another full restore, using the identical process to what I'd done in the past, except I chose the option to power on the VM after the restore finished and I waited 20-40 minutes before I connected to the server and attempted to logon to the console. It worked perfectly again, no 0xc00002e2 error.
I think my issue was caused by trying to connect to the console and attempting to logon too quickly after the restored VM was powered on, interrupting the AD restore process.
BLH wrote: ↑Jul 07, 2023 4:56 pm
I know this is an old thread but I came across it while trying to find a solution to my issue. After doing a Full Restore of the production server to a backup server, I also got the 0xc00002e2 error and found that the NTDS.dit file was trashed on the restored server.
1) How did you identify that the NTDS.dit file was trashed, if you immediately got a BSOD?
2) Thank you for the Instant Recovery / Migrate to Production option !!!
3) Did you ever find an actual solution to this problem? I enabled Application-Aware Processing. I am using Community Edition, v12.2.0.334
As shared above likely the restore process was interupted. The restore of an AD need to reboot multiple times (non-authoritative restore) and when you interupt it by logging in too early the restore process is stopped at an undefined state and the NTDS.dit recovery is interupted. The non-authoritative restore starts first with local logon file before replaced by the AD authentication one, and if you interupt this process at a specific time you run into this issue. See my comments above.
1) AD restore need to be done with Network enabled and with VM boot checkbox.
2) Restore will reboot the server multiple times and you must NOT touch the console, click with the mouse into the VM or do any keystrokes as it will interup the automatic recovery process that happens after Veeam Recovery. Basically wait for some time after restore before you logon (customer above waited 20min).
3) If your complete AD is gone, and you want to restore the first (!!!) AD server, you need to start a Authoritative Restore process as documented here: https://www.veeam.com/kb2119