This article describes troubleshooting a restored Active Directory machine or screenshot verification receiving the error: "STOP: c00002e2"
- Datto SIRIS
- Datto ALTO
Connecting via VNC
To perform the troubleshooting steps in this article on a local virtualization, you must allow the VNC window popup in the browser you are using to connect to the Datto device. Once you bring up the VM with the steps below, it will be necessary to connect to it with VNC.
Figure 1: Allow VNC (click to enlarge)
Troubleshooting common causes
1. Verify that the Datto appliance is backing up all volumes holding Active Directory data. Missing database files can cause a STOP: c00002e2 error. The database file ntds.dit commonly causes this. If you discover that a volume holding Active Directory data was excluded from the backup, include the volume, and then start a backup from the Protect tab of the appliance GUI.
The default path to the database is as follows:
If a custom path was configured, Windows stores the location of the NTDS database, in this registry key:
2. Try to virtualize with each storage controller. In some instances, if the VM is using an incorrect storage controller, the restore will boot to a 2e2 error.
NTDS Writer Excluded
3. In Configure Agent Settings → VSS Writer Exclusion, make sure NTDS is not checked.
Figure 3: VSS writer exclusion (click to enlarge)
4. Ensure you are not receiving vss failures in the backup agent logs, and check the state of vss writers on the server during a backup.
vssadmin list writers
5. If you are experiencing a 2e2 error message during an offsite virtualization, boot into DSRM mode (on the domain controller) and change the system date to the date of the restored point.
For example, if the backup is from July 10th at 2:00 pm EST, and you are booting on July 22nd, boot into DSRM and change the date back to July 10th at any point before 2:00 pm EST.
If none of the above resolves, proceed to the next section.
Booting up the Virtual Machine on the Datto in Directory Services Restore Mode
The general steps for booting into DSRM mode are the same for all restore types
1. Start a local virtualization with networking enabled. If the production machine is still live on the network, use the Firewalled on a private subnet or the Firewalled on a private subnet, with no Internet access option.
2. While the VM is booting, use the connect to VNC option by clicking on the preview window.
3. When the VNC connection is up, click restart in the Datto UI to restart the virtualization.
4. The virtual machine will start to boot on the screen. Immediately press F8 to get to the Advanced Boot Options screen. If access fails, power down the VM and repeat the previous step.
Figure 4: The Advanced Boot Options screen in safe mode on a Windows 7 VM (click to enlarge)
5. From this screen, select Directory Services Restore Mode.
Once you are booted into the server
Things to check
1. After booting into the server, verify that all required drive letters for the VM are correctly assigned in Disk Management.
2. You can change the assigned drive letter of any disk shown by right-clicking the drive's entry and selecting Change Drive Letter and Paths.
3. For each offline disk, mark it online. This step is especially important for servers where the AD database lives on a separate drive from the OS.
Make sure that the virtual machine time is close to the snapshot time you're booting from. Once booted normally, the time can be changed back to the present.
If the VM is unable to boot after performing the above steps, try the following:
Checking AD Database Integrity Using esentutl
- Boot into DSRM and login as .\Administrator
- In an administrative command prompt run:
esentutl /g c:\Windows\NTDS\ntds.dit
- It will warn you about AD logs, but this message can be ignored.
If the database passes integrity checks, something else is causing the system not to boot. Event logs may shed light on the reason for the boot failure.
If integrity checks mark the database corrupt or failed, you can attempt to repair using
esentutl /p c:\windows\ntds\ntds.dit.
Note that this is a repair attempt and is potentially damaging to the database. Any other utilities such as chkdsk and sfc scan can be utilized at this point as well at your discretion.
Should maintenance tools fail to bring the database online in a healthy state, attempt restoration from earlier recovery points.
Outside of a live DR, screenshots may be corrected by a new full backup or differential merge:
Attempt differential merge:
- Force a differential merge for the protected system.
- When completed, force a screenshot for the resulting backup.
- If the issue persists, check the production system's filesystems from an administrator-level command prompt with chkdsk /r.
- Repeat Step 1 and Step 2 of this section.
- If the issue persists, proceed to the next section of this article.
Take a new full backup by destroying the live dataset:
- Destroy the live dataset for the protected system.
- Start a backup for the protected system.
- When the backup completes, force a screenshot for the newly-created point and observe the results.
If you do not know your DSRM password:
If the production machine is still working, it can be reset:
On the production machine.
1. Open an administrative command prompt.
3. Set the dsrm password
4. Reset the password on server null
5. Enter a new password twice.
Datto Support can assist with attaching partner provided recovery ISOs to virtualizations to facilitate password resets. Partner responsibilities in these cases are:
- Obtain the recovery disk / ISO.
- Create a public share on the Datto device to house the ISO
- Syncing the public share to the cloud if the ISO is needed offsite
- Booting to said recovery disk and making the necessary registry changes.