Carbonite Support > How to Recover System State on...

How to Recover System State on an Active Directory Domain Controller

  • This article is for Windows only
  • Support cannot assist with this process however we have included the information in this article to help guide your troubleshooting efforts
    • If you require further assistance please see a Microsoft technician

A Windows Server running Active Directory Domain Services must be booted into Directory Service Restore Mode (DSRM) in order to restore the System State. DSRM is similar to Windows Safe mode and has no Active Directory services running.

DSRM mode behaves very differently from normal boot mode.

The sections below are collapsed. Please click the section title to open / close a particular section.

Requirements

There are many requirements for System State restore to an Active Directory Domain Controller, most of which are partially defined by the limitations of DSRM mode.

Active Directory restores cannot be performed if the backup is older than the tombstone lifetime set in Active Directory. This limitation is imposed by Microsoft. Please refer to the following article for more information: Useful shelf life of a system-state backup of Active Directory.

Enable the Built-in Administrator Account (applies only to Windows Small Business Server and Essentials Server family)

In normal boot mode, enable the built-in administrator account. This account is normally disabled by default.

  1. Assign a password. For all examples on this page, we will use dsrm-password as our password.
    1. Please refer to this Technet article for more details: What Username and Password Do I Need to Use for Directory Services Restore Mode (DSRM) in SBS 2008?
    2. The DSRM password can be reset using the following procedure: How To Reset the Directory Services Restore Mode Administrator Account Password

Boot into DSRM mode

  1. Restart the computer. Press F8 during the boot phase to display the system boot menu.
  2. Select DSRM mode from the boot menu.
    1. Please refer to the following Technet articles for more details:
      1. For Windows Server 2008, Windows Server 2008 R2 and up: Restart the Domain Controller in Directory Services Restore Mode Locally
      2. For Windows Server 2003, Windows Server 2003 R2: Restart the domain controller in Directory Services Restore Mode locally
  3. Log on to Windows using the following credentials:
    1. Username: .\Administrator
    2. Password: dsrm-password

Reconfigure the Log-on User For all CSSB Services

CSSB uses two services called Carbonite Safe Server Backup Controller and Carbonite Safe Server Cloud Controller to facilitate backup and restore functions. In a standard environment, these services are configured to run as the amandabackup / CarboniteUser user. The amandabackup / CarboniteUser user is not available in DSRM mode. All CSSB services must be reconfigured to run under the Local System account.

The Carbonite Safe Server Database service will also exist, but it runs as the Local System account by default.

To reconfigure the log-on user:

  1. Open Services.msc.
  2. Right click the Carbonite Safe Server Backup Controller and click Properties.
  3. Navigate to the Log On tab.
  4. Change the log-on user to the Local System account.
  5. Restart the service.
  6. Repeat these steps for Carbonite Safe Server Cloud Controller and, if necessary, for Carbonite Safe Server Database.

The Carbonite Safe Server Backup Controller and Carbonite Safe Server Cloud Controller log on settings will be reverted back to amandabackup / CarboniteUser as part of the restoration process. If you must perform multiple DSRM restores for some reason, please remember to change the log-on user for these services before you begin each time.

For 64-bit machines running a server OS (Windows 2008 R2, Windows 2012, or higher) that have a Hyper-V role installed, the Carbonite Safe Server Hyper-V Service will also be running.

Restore the System State

As shown above, the server must be in DSRM mode and the services reconfigured. Restoration can begin once these requirements are met.

The restoration process shown below can vary depending on where your backups are stored.

Scenario #1: Backup archives are stored on directly attached storage

  1. Open CSSB and begin a restore of the chosen System State backup to its Original Location.
  2. Use the Dashboard to observe the restore progress and result.

Scenario #2: Backup archives are in the Cloud

  1. Unless there are multiple Domain Controllers (DNS Servers) in your environment, the DNS server must be set manually.
    1. Change the DNS setting of your primary network interface to a public DNS server, such as OpenDNS: 208.67.222.222 or Google: 8.8.8.8.
    2. This setting will be reverted back by the restoration process.
    3. This step is required because the Preferred DNS Server setting of the local network adapter points to itself by default on a Domain Controller. However, the DNS service is not running in DSRM mode.
  2. Open CSSB and begin a Restore of the chosen System State backup run to its Original Location.
  3. Use the Dashboard to observe the restore progress and result.

Scenario #3: Backups are only on CIFS/NFS share

There are two options:

  1. Ensure that the local administrator user account on the domain controller can access the network device using the dsrm-password password.
    1. Map the share using different credentials.
    2. Test and confirm that correct security permissions to the network share exist before the restore begins.
  2. If you are not able to access the network share in DSRM mode, reboot to normal mode and copy the backup data from the network share to the local drive. This can be accomplished by using the Move Local Backups option in the Tools menu.

Once completed, open CSSB and begin a restore of the chosen System State backup run to its Original Location. Use the Dashboard to observe the restore progress and result.

Scenario #4: Backups are on a Windows Share

This scenario is a bit challenging when there is a single domain controller because it requires a connection to the network share when the domain controller is not available.

It is much easier to copy the backup archive from the network share to the local drive using the Move Local Backups option in the Tools menu. Once complete, open CSSB and begin a restore of the chosen System State backup run to its Original Location. Use the Dashboard to observe the restore progress and results.

If it isn't possible to move the backup data to the local drive, please continue with the directions below.

Please choose the option below that applies to your situation:

The Server is the Only Domain Controller on the Network

If the server is the the only domain controller on the network:

  1. Reconfigure the network share where your backup archives are stored to give Share and NTFS read permissions to a local administrator user on the member server.
    1. This is required because the member server has to query the Domain Controller to allow connection to its share, but the DC won't be available because it will be in DSRM mode.
  2. If the local administrator user password on the member server is dsrm-password, the connection to the network share will work.
  3. If the chosen password is not dsrm-password, map the network drive with the credentials of any local user account (but not administrator) who has appropriate permissions on the member server.
    1. Please refer to the following article for additional information: http://technet.microsoft.com/en-us/library/bb490717.aspx.
  4. Assign the same drive letter to the mapped network drive as in the original setup.
    1. Example: If the mapped drive was assigned to Z:\ in normal boot mode, it should also be assigned to Z:\ in DSRM mode.
  5. Open CSSB and begin a restore of the latest System State backup run to its Original Location.
  6. Use the Dashboard to observe the restore progress and results.

There are Other Domain Controllers on the Network

If there are other domain controllers on the network:

  1. If the local administrator user password on the member server is dsrm-password, the connection to the network share will work.
  2. If the chosen password is not dsrm-password, map the network drive with the credentials of any local user account(but not administrator) who has appropriate permissions on the member server.
    1. Please refer to the following article for additional information: http://technet.microsoft.com/en-us/library/bb490717.aspx.
  3. Assign the same drive letter to the mapped network drive as in the original setup.
    1. Example: If the mapped drive was assigned to Z:\ in normal boot mode, it should also be assigned to Z:\ in DSRM mode.
  4. Open CSSB and begin a restore of the latest System State backup run to Original Location.
  5. Use the Dashboard to observe the restore progress and results.

After the System State Restore

Determine if there are multiple domain controllers in your environment, then follow the appropriate steps below.

Scenario #1: Your server is the one and only domain controller in your environment

Restart the server after the System State restore is complete. No further steps are necessary.

Scenario #2: There are multiple domain controllers in your environment

The Active Directory database exists and is replicated to every domain controller in your environment. Every time any object in the database is updated, the database version number changes. These changes are synchronized by the replication process that takes place between all domain controllers.

By default, restoring System State on a Domain Controller is a non-authoritative Active Directory restore. The changes made by the restore will not be propagated out to other Domain Controllers.

When the system boots back into normal mode after the restore, Active Directory will be updated (synchronized) to the latest version from other Domain Controllers (DCs) in your environment. The other DCs will propagate Active Directory back to the system and overwrite the changes to Active Directory that were made by the restore.

For example:

  • You accidentally deleted an Organization Unit in Active Directory.
  • Synchronization between Domain Controllers took place and deletion of this object propagated to other Controllers.
  • You run a System State restore on one of the Domain Controllers. By default, this is a non-authoritative restore.
  • The restored Active Directory database contains deleted objects, but its version is older than the database present on the other Domain Controllers.
  • The Domain Controller with the restored Active Directory is rebooted into normal mode, and synchronization with other Domain Controllers will occur.
  • The deleted object that was restored will NOT appear in Active Directory because the synchronization process will once again propagate the deletion of this object.

If the goal of your System State restore is anything other than the restore of a deleted Active Directory object, the default non-authoritative restore is sufficient.

If the goal of your System State restore is to restore a deleted Active Directory object, you must mark this restore as an authoritative restore.

Option A (default): Non-authoritative Restore

System State restores are non-authoritative by default. If the goal of your System State restore is anything other than the restore of a deleted Active Directory object, no further steps are necessary. Simply reboot the system after the System State restore is complete.

Option B: Authoritative Restore

Authoritative restore is the process of marking Active Directory objects in the restored database as the authority for other domain controllers. After an authoritative restore, the synchronization process will propagate any changes caused by the restore to other domain controllers.

Follow these steps to perform an authoritative restore:

  1. After the System State restore is successful, but before you boot into normal mode, launch NTDSUTIL.
    1. Click Start.
    2. Click Run.
    3. Type ntdsutil, and then press ENTER.
  2. In Windows 2008 and up, type activate instance ntds at the ntdsutil prompt and then press ENTER.
    1. This step is not necessary for Windows 2003.
  3. Type authoritative restore at the ntdsutil prompt and then press ENTER.
  4. To restore a subtree or individual object, type the most appropriate command (out of the following) and then press ENTER:
    1. To restore a subtree (for example, an organizational unit and its child objects):
      restore subtree DistinguishedName
    2. To restore a single object:
      restore object DistinguishedName
      (DistinguishedName is the distinguished name of the subtree or object that is to be marked authoritative)
  5. For example, if you want to restore a deleted organizational unit named Marketing NorthAm in the corp.contoso.com domain, type:
    1. restore subtree “OU=Marketing NorthAm,DC=corp,DC=contoso,DC=com"
  6. Click Yes in the message box to confirm the command.
  7. At the authoritative restore and ntdsutil prompts, type quit and then press ENTER.
  8. Restart the domain controller in normal operating mode.

For more information, please refer to the following Microsoft Technet articles:

Feedback