Recovering Active Directory with Replay (117790)

  • Title

    Recovering Active Directory with Replay
  • Description

    This article describes the considerations for restoring Active Directory services on a Domain Controller using Replay.

    The following Solution provides information and considerations for protecting and recovering an Active Directory.

  • Resolution

    See the following sections for information about protecting and recovering an Active Directory on a Domain Controller using Replay.

    Fundamentals of Non-Authoritative Active Directory restore

    Microsoft offers two approaches for restoring Active Directory on Domain Controllers – authoritative and non‐authoritative. Replay uses non-authoritative restore to recover Active Directory on Domain Controllers. A non‐authoritative restore returns the Domain Controller to its state at the time of snapshot.

    Active Directory then allows normal replication to overwrite that state with any changes that occurred after the backup was taken. After the target Domain Controller is restored to its previous system state, the Domain Controller queries its replication partners. The replication partners replicate any changes to the restored Domain Controller, ensuring that the Domain Controller has an accurate and updated copy of the Active Directory database.

    A non-authoritative restore also allows the entire directory to be restored on a Domain Controller, without reintroducing or changing objects that have been modified since the backup. The most common use of a non-authoritative restore is to bring an entire Domain Controller back, often after catastrophic or debilitating hardware failures. It is uncommon for data corruption to drive a non-authoritative restore, unless the corruption is local and the database cannot be successfully loaded.

    Non-authoritative restore is the default method for restoring Active Directory, and it is used in most situations that result from Active Directory data loss or corruption. Replay performs backups and recoveries at the volume block layer, therefore, it is not necessary to start the Domain Controller in Directory Services Restore Mode.

    Considerations for fast Active Directory Domain Controller Recovery

    The Active Directory installation process creates three folders on the Domain Controller for the Active Directory database, the log files and the SYSVOL folder. For a detailed listing of the contents of the Active Directory database, refer to Appendix A. These folders must be on a fixed disk of the server formatted with NTFS file system and cannot be located on a shared resource on the network. In addition, the SYSVOL folder cannot be in the same path as the Database Path folder or Log Path folder.

    The following lists the three folders and their roles:

    Folder Description
    Database Path Contains Active Directory data, including the Ntds.dit file, which stores the database in use on the domain controller.
    Log Path Contains The Active Directory logging and recovery system log file. Database operations are recorded in this log file, which can be used to restore a database after a system has failed.
    SYSVOL Stores the server copy of the domain’s public files, such as the SYSVOL shared folder.

    Active Directory Folders

    For a faster recovery of an Active Directory Domain Controller, place the Operating System, Active Directory database and its Log files and the SYSVOL folders in separate volumes. Since Replay performs backups and recovery at the volume block layer, using separate volumes will ensure a faster recovery of the service.

    The following table depicts the proposed layout.

    Drive Letter Component RAID Configuration
    C: Operating System + Page File RAID 1 or RAID 0+1
    D: Active Directory Database and Log Files RAID 1 or RAID 0+1
    E: SYSVOL RAID 1 or RAID 0+1

    Proposed Folder Layout for Active Directory

    In addition to the approach shown above, always deploy two Domain Controllers to support the Active Directory and split the cores-wide and domain-wide FSMO roles between the two servers.

    Outage Scenarios

    • Complete Domain Controller Outage
    • Files deleted on the Windows system folder
    • Volume containing the Active Directory database and the log files fails
    • Volume containing the SYSVOL folder fails
    • Files deleted from the SYSVOL folder
    • Objects deleted from the Active Directory

    Contents of the Active Directory Database

    • Ntds.dit. This is the main AD database. NTDS stands for NT Directory Services. The DIT stands for Directory Information Tree. The Ntds.dit file on a particular domain controller contains all naming contexts hosted by that domain controller, including the Configuration and Schema naming contexts. A Global Catalog server stores the partial naming context replicas in the Ntds.dit right along with the full Domain naming context for its domain.
    • Edb.log. This is a transaction log. Any changes made to objects in Active Directory are first saved to a transaction log. During lulls in CPU activity, the database engine commits the transactions into the main Ntds.dit database. This ensures that the database can be recovered in the event of a system crash. Entries that have not been committed to Ntds.dit are kept in memory to improve performance. Transaction log files used by the ESE engine are always 10MB.
    • Edbxxxxx.log. These are auxiliary transaction logs used to store changes if the main Edb.log file gets full before it can be flushed to Ntds.dit. The xxxxx stands for a sequential number in hex. When the Edb.log file fills up, an Edbtemp.log file is opened. The original Edb.log file is renamed to Edb00001.log, and Edbtemp.log is renamed to Edb.log file, and the process starts over again. ESENT uses circular logging. Excess log files are deleted after they have been committed. You may see more than one Edbxxxxx.log file if a busy domain controller has many updates pending.
    • Edb.chk. This is a checkpoint file. It is used by the transaction logging system to mark the point at which updates are transferred from the log files to Ntds.dit. As transactions are committed, the checkpoint moves forward in the Edb.chk file. If the system terminates abnormally, the pointer tells the system how far along a given set of commits had progressed before the termination.
    • Res1.log and Res2.log. These are reserve log files. If the hard drive fills to capacity just as the system is attempting to create an Edbxxxxx.log file, the space reserved by the Res log files is used. The system then puts a dire warning on the screen prompting you to take action to free up disk space quickly before Active Directory gets corrupted. You should never let a volume containing Active Directory files get even close to being full. File fragmentation is a big performance thief, and fragmentation increases exponentially as free space diminishes. Also, you may run into problems as you run out of drive space with online database defragmentation (compaction). This can cause Active Directory to stop working if the indexes cannot be rebuilt.
    • Temp.edb. This is a scratch pad used to store information about in-progress transactions and to hold pages pulled out of Ntds.dit during compaction.
    • Schema.ini. This file is used to initialize the Ntds.dit during the initial promotion of a domain controller. It is not used after that has been accomplished.
    VN:F [1.9.20_1166]

Feedback submitted.

Did this article help?

[Select Rating]

Thank you for your rating!


Request or Create a KB Article »



Article History:
Created on: 12/19/2013
Last Update on: 2/21/2014