Error: STOP: c00002e2 on Active Directory server restore or screenshot verification

Topic

This article describes troubleshooting a restored Active Directory machine or screenshot verification receiving the error: "STOP: c00002e2" or "0xc00002e2."

Environment

  • Datto SIRIS
  • Datto ALTO

Description

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.

mceclip0.png
Figure 1: Allow VNC

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:

C:\Windows\Ntds\ntds.dit

If a custom path was configured, Windows stores the location of the NTDS database, in this registry key:

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
  1. 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.


Figure 2: Try the virtualization with each storage controller

NTDS Writer Excluded

  1. In Configure Agent Settings > VSS Writer Exclusion, make sure NTDS is not checked.

vss3.png
Figure 3: VSS writer exclusion

  1. 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
  1. 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

  1. From this screen, select Directory Services Restore Mode.

Once you are booted into the server

NOTE  There is an event log that should log the specific cause of the 2e2 error, which is available when booted into DSRM mode and may speed up the troubleshooting process. To access the log, open the Windows Event Viewer and navigate to Application and Services Logs ? Directory Services.

Things to check

  1. After booting into the server, verify that all required drive letters for the VM are correctly assigned in Disk Management.


Figure 5: Assigned drives in Disk Management

  1. 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.


Figure 6: Assigned drives in Disk Management

  1. 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.


Figure 7: Mark Online

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.

Remove old log files

Old log files in C:\windows\ntds\ can sometimes cause boot issues. You can try renaming all of the .log files to .old and moving them to a different folder in order to retain them if needed. Once they’ve been renamed and moved, try a reboot.

Next Steps

If the VM is unable to boot after performing the above steps, try the following:

Checking AD Database Integrity Using esentutl

  1. Boot into DSRM and login as .\Administrator
  2. In an administrative command prompt run: esentutl /g c:\Windows\NTDS\ntds.dit
  3. 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:

  1. Force a differential merge for the protected system.
  2. When completed, force a screenshot for the resulting backup.
  3. If the issue persists, check the production system's filesystems from an administrator-level command prompt with chkdsk /r.
  4. Repeat Step 1 and Step 2 of this section.
  5. If the issue persists, proceed to the next section of this article.

Take a new full backup by destroying the live dataset:

  1. Destroy the live dataset for the protected system.
  2. Start a backup for the protected system.
  3. 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.
  2. Enter ntdsutil
  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.

Additional Resources