Windows Server Troubleshooting - Restore the AD

Click here to start saving with ING DIRECT!

Home | Up | Methodology | Architecture | Tools | Memory | Processor | Registry | File System | Network | Contents

Get the Book

Major Topics
File System
Active Directory
Other Topics
Garbage Collection
Distinguished Name
Restore the AD
Log Files
Global Catalog
More Detail

eXpert Genealogy

Memory from

2003-2006 Team Approach Limited
All rights reserved

Backup and Restore of the Active Directory

If a Domain Controller fails and cannot be restarted, you need to recover somehow. Before proceeding you will remove all references to the failed Domain Controller by using the Sites and Services Manager. One approach is simple

  • Reinstall Windows
  • Promote the server to a Domain Controller
  • Let replication for the other Domain Controllers update the Active Directory

If the replication is not practical because of the volume of data or the speed on the network connection, you may wish to restore the Active Directory from backup media. With NTBACKUP, you restore the System State which includes the Active Directory.

Warning! Don't restore the Active Directory with backups older than the tombstone lifetime. Subsequently deleted objects will not be removed after the tombstones have expired.

The diagram show the sequence of events to restore a crashed domain controller to make it up-to-date to the time of the last replication cycle. Backups are taken at a point in time where the USN has some value. As more transactions occur, they are replicated to other domain controllers. If the domain controller fails and cannot be restarted, a new installation is required which can be restored to the point of the last backup. Although the last backup is not completely up-to-date, the other servers will replicate the latest changes back to the recovered server. The only transaction that will be missing after the restore and replication, are those applied after the last 5 minute replication cycle. Backup of USN=5678
Replication to USN=9876
Server Crash
Restore USN=5678
Replication to USN=9876

Normally AD transactions are not replicated back to the originating server. The Active Directory database is identified on each server by a GUID Globally Unique Identifier. After a restoration from a backup, the AD database GUID is changed to make the server appear as a different server so that transactions that originated there get replicated back.

Authoritative Restore

Consider the case where the Active Directory is recently backed up. Let's say you need to delete 1000 users because the company department is becoming a separate entity. Woops! You deleted the wrong 1000 users!! How do you get them back. "Easy", you say, "They're backed up on the backup tape and can all be restored". Think about this some more. After a restore, replication continues. When you deleted the 1000 users, the tombstones were replicated to other servers. You can restore the users from the backup tape, but the tombstones will replicate back and delete them again!!

A special procedure called an Authoritative Restore is needed handle cases like this. The idea of an Authoritative Restore is to specify that the data being restored should be considered authoritative and other conflicting transactions on other domain controllers at the time of the restore should be ignored. This is accomplished by using NTDSUTIL in the Active Directory Restore Mode. An Administrator must use NTDSUTIL to identify the authoritative objects which have there version number incremented by 100,000 for each day since the backup to guarantee authority over other existing transactions.

The procedure to perform an Authoritative Restore is as follows.

  • Start the Domain Controller is Directory Services Restore Mode
  • Logon as a the local Administrator
  • Restore the System State with NTBACKUP
  • Restart the server in Directory Services Restore Mode
  • User NTDSUTIL to designate objects as authoritative
    • Objects are identified with their distinguished names
    • The version number is incremented by 100,000 for each day since the backup
  • Restart the server normally