Backing Up and Restoring AD

Windows 2000 doesn't employ PDCs, BDCs, and the single master replication scheme that Windows NT 4.0 does. Instead, all domain controllers have a read-write copy of the directory and use multimaster replication to ensure that the changes you make on one domain controller copy to the other domain controllers in the domain. Although the Win2K model is more scalable and flexible, it can present some interesting challenges when you perform administrative tasks, such as restoring Active Directory (AD).

Backing Up AD
The good news is that the Win2K Backup and Recovery program is a great improvement over NT 4.0's. With Win2K, you can use an interface to schedule backups, eliminating the need to write a batch file and use the AT scheduler, and you can back up to a file instead of a tape drive. Win2K's solution isn't yet an enterprise backup solution, but it’s certainly an improvement.

To back up AD, run the Backup Wizard and select "Only back up the System State data," as Figure 1 shows. On a domain controller, System State data includes AD, the SYSVOL folder, the registry, system startup files, the class registration database, and, if the domain controller operates as a certificate server, the Certificate Services database. You can perform the backup without taking the domain controller offline, but you can only back up the System State data for the local machine with the Win2K Backup and Recovery program. To back up System State data on a network machine, you must use a third-party backup program.

Restoring AD
Because the AD database can't be running when you perform an AD restore, you must use a special boot mode called Directory Service Restore Mode, which you can enter by pressing F8 during the boot process. The only way to restore AD is to restore the entire System State data, which means that in addition to restoring an older copy of the directory, you also restore an older copy of the registry and therefore lose any configuration changes you made after performing the backup.

You can perform two different AD restores: nonauthoritative and authoritative. To perform a nonauthoritative restore, boot into the Directory Service Restore Mode, log on using the local administrator account, perform a System State restore, and reboot the system. When the system reboots, it contacts the domain controllers in the domain that are its replication partners to retrieve any updates to AD that have occurred since the backup, so you restore an AD that's a replica of the current AD on the network, not necessarily what the backup contains. The problem is that if you accidentally delete an organizational unit (OU) from AD and you perform a nonauthoritative restore, your domain controller contacts the other domain controllers on the network to retrieve any changes that have occurred, including the deletion of the OU. So how do you get your OU back? By performing an authoritative restore instead.

An authoritative restore is similar to a nonauthoritative restore, but with an additional step. After performing the System State data restore, you use the command-line utility ntdsutil.exe to mark specific objects within the AD as authoritative. Every AD object has a version number that changes incrementally when AD makes updates, and when you mark an AD object as authoritative, its version number increases by 100,000. When two domain controllers have different version numbers for the same object, the one with the highest version number is authoritative and replicates over the other copy of the object. To use ntdsutil.exe to mark an object as authoritative, type

ntdsutil 

at the command prompt, then type

authoritative restore 

at the ntdsutil prompt. To complete the restore, you need to know the distinguished name of the object or you can perform an authoritative restore of the entire directory. For example, to restore the OU that you deleted, you can use the restore subtree command and specify the OU’s distinguished name. As a final note, you can't mark the schema directory partition as authoritative, so you can't roll back schema modifications with an AD restore.