Recovering domain controllers after a server disk failure

When recovering domain controllers after a system volume failure, it is important to remember that each domain controller in the domain shares a replicated copy of the Active Directory database. When you restore a backup of a domain controller, Windows will use a process called backfilling to bring the domain controller's Active Directory database back up to date. Essentially, this means looking at the most recent change that was made to the newly restored domain controller's copy of the Active Directory database and then replicating all subsequent changes from another domain controller. The backfilling process happens automatically, so you don't have to do anything except wait for it to complete. There are, however, a couple of situations in which a normal domain controller restoration is not an option. Learn special procedures for recovering domain controllers in this tip.

In the first part of this series, Recovering from a server disk failure: The shortcomings of NTBCKUP, I talked about how you could recover your server after a system volume failure. In this article, I want to turn my attention to some special procedures used for domain controllers.

Normally, when you are restoring a domain controller, you will follow the procedure outlined in the previous article. The Active Directory database is backed up as a part of a system state backup, so restoring the system state restores the server's copy of the Active Directory database.

It is important to remember that each domain controller in the domain shares a replicated copy of the Active Directory database. When you restore a backup of a domain controller, Windows will use a process called backfilling to bring the domain controller's Active Directory database back up to date. Essentially, this means looking at the most recent change that was made to the newly restored domain controller's copy of the Active Directory database and then replicating all subsequent changes from another domain controller. The backfilling process happens automatically, so you don't have to do anything except wait for it to complete.

More on recovering from a server disk failure and disaster recovery
Part 1: The shortcomings of NTBCKUP

Part 2: Recovering domain controllers after a server disk failure

Disaster recovery: A guide for network professionals

The IT Guy comic: Disaster recovery

There are, however, a couple of situations in which a normal domain controller restoration is not an option. In some situations, you may need to perform a primary restore instead. You would use a primary restore if you were restoring the only domain controller on the network. You would also use a primary restore if you were going to be restoring all of the domain controllers, but you would perform a primary restore only on the first domain controller that is being restored. You would use a normal restore on all subsequent domain controllers.

Primary restores

The procedure for performing a primary restore is identical to the one used for performing a normal restore, with one exception -- you can perform a primary restore only by using the Restore Wizard. When the Restore Wizard starts, you'll have to click the "Advanced" button to access the advanced restoration options.

The Wizard's first two screens are pretty basic, but on the third screen you will see the advanced restore options. Simply select the "When restoring replicated data sets mark the restored data as the primary data for all replicas" check box. You can see this option in Figure A, but it is grayed out in the figure.

Figure A
Windows restore wizard
Select the bottom check box if you want to perform a primary restoration.

Authoritative restores

Earlier, I explained the process of backfilling that occurs after you restore a domain controller. Sometimes, you may want the restore data to take precedence over the data that would normally be replicated from another domain controller. In such situations, it is necessary to perform an authoritative restore.

Begin by performing a normal restoration, then open a Command Prompt window. Now, enter the NTDSUTIL command, followed by the Authoritative Restore command, and the Restore Database command. When prompted, click OK, and then click Yes.

Although performing an authoritative restore is simple to do, it has some fairly deep implications. Before you attempt an authoritative restore, I strongly recommend reading Microsoft's knowledgebase article, How to perform an authoritative restore to a domain controller in Windows 2000. This article explains both the implications and limitations associated with performing an authoritative restore.

A word of caution

A lot of people don't realize it, but Windows imposes a backup age limit when you are restoring a domain controller. As you probably know, objects deleted from the Active Directory are not immediately removed from the database. When an object is deleted, Windows converts it to a tombstone and then replicates the tombstone to the other domain controllers as a way of informing them that the object has been deleted.

The problem with these tombstones is that if you restore a domain controller to a state prior to the deletion of an object, and a tombstone does not get replicated to the other domain controllers, then the tombstone will exist only on the domain controller that has been restored, leaving it in an inconsistent state. As a way of protecting the Active Directory against corruption resulting from inconsistencies, Windows prevents you from restoring backups that exceed the tombstone limit. The default lifespan of a tombstone is 60 days, which means that backups older than 60 days are rendered invalid.

Conclusion

These tips really cover only the basics. If you are interested in learning more about recovering domain controllers, check out the Active Directory backup and restore section on MicrosoftTechNet.

About the author:
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, Brien has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.


This was first published in April 2008
This Content Component encountered an error

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSDN

SearchEnterpriseWAN

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close