Backing up Active Directory is easy. To back up Active Directory, all you need to do is back up the System State on a domain controller. However, recovery of Active Directory is different from recovery for other types of network services. A key reason for this involves the way Active Directory data is replicated and restored. Because of this, let's look at backup and recovery strategies for Active Directory, and then look at various restore techniques.
Domain controllers have replication partners with whom they share information. When you have multiple domain controllers in a domain and one fails, the other domain controllers automatically detect the failure and change their replication topology accordingly. You can repair or replace the failed domain controller from backup. However, the restore doesn't recover Active Directory information stored on the domain controller.
To restore Active Directory on the failed domain controller, you use either a nonauthoritative or authoritative approach. A nonauthoritative restore allows the domain controller to come back on line, and then get replication updates from other domain controllers. An authoritative restore makes the restored domain controller the authority in the domain, and its data is replicated to other domain controllers.
In most cases, you'll have multiple domain controllers in a domain, giving you flexibility in your disaster recovery plan. If one of the domain controllers fails, you can install a new domain controller or promote an existing member server so that it can be a domain controller. In either case, the directory on the new domain controller is updated automatically through replication. You could also recover the failed domain controller, and then perform a nonauthoritative restore. In this case, you would restore Active Directory on the domain controller and obtain directory updates from other domain controllers in the domain.
In some cases, you may need to perform an authoritative restore of Active Directory. For example, if a large number of objects were deleted from Active Directory, the only way to recover those objects would be to use an authoritative restore. In this case, you would restore Active Directory on a domain controller and use the recovered data as the master copy of the directory database. This data is then replicated to all other domain controllers.
The disaster recovery strategy you choose for Active Directory may depend on whether you have dedicated or nondedicated domain controllers, for the following reasons:
When you have dedicated domain controllers that perform no other domain services, you can implement a very simple disaster recovery procedure for domain controllers. As long as you have multiple domain controllers in each domain, you can restore a failed domain controller by installing a new domain controller and then populating the directory on the new domain controller through replication or by recovering the domain controller using a nonauthoritative restore. You should always back up one or more of the domain controllers and their System State as well, so that you always have a current snapshot of Active Directory in the backup archives. If you need to recover from a disaster that has caused all your domain controllers to fail or Active Directory has been corrupted, you can recover using an authoritative restore in the Directory Services restore mode.
When you have nondedicated domain controllers, you should back up the System State whenever you perform a full backup of a domain controller. This stores a snapshot of Active Directory along with the other pertinent system information that can be used to fully recover the domain controller. If a domain controller fails, you can recover the server the way you recover any server. You then have the option of restoring the system state data and Active Directory to allow the server to resume operating as a domain controller, by using a nonauthoritative restore in the Directory Services restore mode. If you need to recover from a disaster that has caused all your domain controllers to fail or Active Directory has been corrupted, you also have the option of using an authoritative restore in the Directory Services restore mode.
When planning backups of Active Directory, you should also remember the tombstone lifetime. As you may recall from Chapter 33, Active Directory doesn't actually delete objects when you remove them from the directory. Instead, objects are tombstoned (marked for deletion) and the tombstone is replicated to all the other domain controllers. By default, the tombstone lifetime is 60 days, meaning that a tombstone will remain in the directory for 60 days and then be deleted. To ensure that you don't accidentally restore objects that have actually been removed from Active Directory, you are prevented from restoring Active Directory if the backup archive is older than the tombstone lifetime. This means that, by default, you cannot restore a backup of Active Directory that is older than 60 days.
Other system information is contained in the System State besides Active Directory. So, any restore of Active Directory includes all that information, and that information will be restored to its previous state as well. If a server's configuration changed since the backup, the configuration changes will be lost.
When a domain controller fails, you can restore it the way you restore any other server except when it comes to Active Directory. With this in mind, first fix the problem that caused the server to fail. You can use a boot disk, Automated System Recovery, or the Recovery Console as discussed in Chapter 40. Once you've restored the server, you can then work to restore Active Directory.
You recover Active Directory by restoring the System State on the domain controller, using a special recovery mode called Directory Services Restore Mode. If you have made changes to Active Directory since the backup, the System State backup will not contain those changes. However, other domain controllers in the domain will have the most recent changes, and the domain controller will be able to obtain those changes through the normal replication process.
When you want to restore Active Directory on a domain controller and have the domain controller get directory updates from other domain controllers, you perform a nonauthoritative restore. A nonauthoritative restore allows the domain controller to come back on line and then get replication updates from other domain controllers.
You can perform a nonauthoritative restore by completing the following steps:
Repair the failed domain controller or rebuild the domain controller by reinstalling Windows Server 2003. Once you've repaired or rebuilt the server, restart the server and press F8 during startup to access the Windows Advanced Options menu. You must press F8 before the Windows splash screen appears.
On the Windows Advanced Options menu, select Directory Services Restore Mode (Windows Domain Controllers Only). Windows will then restart in Safe Mode without loading Active Directory components.
You will next need to choose the operating system you want to start. 4 Log on to the server using the Administrator account with the Directory Services Restore password that was configured on the domain controller when Active Directory was installed.
The Desktop prompt warns you that you are running in Safe Mode, which allows you to fix problems with the server but makes some of your devices unavailable. Click OK. 6 Start the Backup utility and use it to restore the system state information on the server to its original location (see Figure 41-8).
After the data is restored, restart the computer as instructed. Once the server restarts, it can act as a domain controller and it has a directory database that is current as of the date of the backup. The domain controller then connects to its replication partners and begins updating the database so that any changes since the backup are reflected.
An authoritative restore is used when you need to recover Active Directory to a specific point in time and then replicate the restored data to all other domain controllers. Consider the following example: John accidentally deleted the Marketing organizational unit (OU) and all the objects it contained. Because the changes have already been replicated to all domain controllers in the domain, the only way to restore the OU and the related objects would be to use an authoritative restore. Similarly, if Active Directory were somehow corrupted, the only way to recover Active Directory fully would be to use an authoritative restore.
When performing authoritative restores, there are several significant issues that you should consider. The first and most important issue has to do with passwords used for computers and Windows NT LAN Manager (NTLM) trusts. These passwords are changed automatically every seven days. If you perform an authoritative restore of Active Directory, the restored data will contain the passwords that were in use when the backup archive was made. If you monitor the event logs after the restore, you may see related events or you may hear from users who are experiencing problems accessing resources in the domain.
Computer account passwords allow computers to authenticate themselves in a domain using a computer trust. If a computer password has changed, the computer may not be able to reauthenticate itself in the domain. In this case, you may need to reset the computer account password by right-clicking on the computer account in Active Directory Users And Computers, and then selecting Reset Account. If the reset of the password doesn't work, you may need to remove the computer account from the domain, and then add it back.
NTLM trusts are trusts between Active Directory domains and Microsoft Windows NT domains. If a trust password has changed, the trust between the domains may fail. In this case, you may need to delete the trust, and then recreate it as discussed in the section entitled "Establishing External, Shortcut, Realm, and Cross-Forest Trusts".
Another significant issue when performing an authoritative restore has to do with group membership. Problems with group membership can occur after an authoritative restore for several reasons.
In the first case, an administrator has updated a group object's membership on a domain controller that has not yet received the restored data. In this case, the domain controller may replicate the changes to other domain controllers, causing a temporary inconsistency. The changes shouldn't be permanent, however, because when you perform an authoritative restore, the update sequence number (USN) of all restored objects is incremented by 100,000. This ensures that the restored data is authoritative and overwrites any existing data.
Another problem with group membership can occur if group objects contain user accounts that do not currently exist in the domain. In this case, if group objects are replicated before these user objects are, the user accounts that do not currently exist in the domain will be seen as invalid user accounts. As a result, the user accounts will be deleted as group members. When the user accounts are later replicated, the user accounts will not be added back to the groups.
Although there is no way to control which objects are replicated first, there is a way to correct this problem. You must force the domain controller to replicate the group membership list with the group object. You can do this by creating a temporary user account and adding it to each group that contains user accounts that are currently not valid in the domain. Here's how this would work: You authoritatively restore and then restart the domain controller. The domain controller begins replicating its data to other domain controllers. When this initial replication process finishes, you create a temporary user account and add it to the requisite groups. The group membership list will then be replicated. If any domain controller has removed previously invalid user accounts as members of these groups, the domain controller will then return the user accounts to the group.
You can perform an authoritative restore by completing the following steps:
Follow steps 1 through 6 in the section entitled "Performing a Nonauthoritative Restore of Active Directory," but do not restart the computer when the restore is complete.
Click Start, click Run, type cmd in the Open field, and then click OK.
At the command prompt, type ntdsutil. This starts the Directory Services Management Tool.
At the Ntdsutil prompt, type authoritative restore. You should now be at the Authoritative Restore prompt, where you have the following options:
You can authoritatively restore the entire Active Directory database by typing restore database. If you restore the entire Active Directory database, there will be a significant amount of replication traffic generated throughout the domain and the forest. You should restore the entire database only if Active Directory has been corrupted or there is some other significant reason for doing so.
You can authoritatively restore a container and all its related objects (referred to as a subtree) by typing restore subtree ObjectDN where ObjectDN is the distinguished name of the container to restore. For example, if someone accidentally deleted the Marketing OU in the cpandl.com domain, you could restore the OU and all the objects it contained by typing the command restore subtree ou=marketing,dc=cpandl,dc=com.
You can authoritatively restore an individual object by typing restore object ObjectDN where ObjectDN is the distinguished name of the object to restore. For example, if someone accidentally deleted the Sales group from the default container for users and groups (cn=users) in the cpandl.com domain, you could restore the group by typing the command restore object cn=sales,cn=users,dc=cpandl,dc=com.
When you type a restore command and press Enter, the Authoritative Restore Confirmation dialog box appears, which prompts you to click Yes if you're sure you want to perform the restore action. Click Yes to perform the restore operation.
Type quit twice to exit Ntdsutil, and then restart the server.
Note
Every object that is restored will have its USN incremented by 100,000. When you are restoring the entire database, you cannot override this behavior, which is necessary to ensure that the data is properly replicated. For subtree and object restores, you can override this behavior by setting a different version increment value using the Verinc option. For example, if you wanted to restore the Sales group in the cpandl.com domain and increment the USN by 500 rather than 100,000, you could do this by typing the command restore object cn=sales,cn=users,dc=cpandl,dc=com verinc 500.
The Sysvol folder is backed up as part of the system state information and contains critical domain information including GPOs, group policy templates, and scripts used for startup, shutdown, logging on and logging off. If you restore a domain controller, the Sysvol data will be replicated from other domain controllers. Unlike Active Directory data, Sysvol data is replicated using the File Replication Service (FRS).
You restore Sysvol data using a primary restore. A primary restore reestablishes the Sysvol folder and the File Replication Service, and sets the restored data as authoritative. This means that the restored Sysvol would be replicated to all other domain controllers. For example, if someone were to delete several scripts used for startup or logon and there were no backups of these scripts, you could restore them using a primary restore.
To perform a primary restore, you use Backup to restore the System State using either an authoritative or a nonauthoritative restore. During the restore, you do not accept the default restore settings. Instead, you access the advanced restore options shown in Figure 41-9, and then select the When Restoring Replicated Data Sets, Mark The Restored Data As The Primary Data For All Replicas option. This marks the Sysvol data as the primary data so that it is replicated to other servers. The Restore Security, Restore Juncture Points And Restore File And Folder Data Under Junction Points To The Original Location, and Preserve Existing Volume Mount Points options should all be selected by default. These options should remain selected to ensure proper recovery of the Sysvol data.
Sometimes you won't be able to or won't want to repair a failed domain controller and may instead elect to install a new domain controller. You can install a new domain controller by promoting an existing member server so that it is a domain controller or by installing a new computer, and then promoting it. Either way, the domain controller will get its directory information from another domain controller.
Installing a new domain controller is the easy part. When you've finished that, you need to clean up references to the old domain controller so that other computers in the domain don't try to connect to it anymore. You need to remove references to the server in DNS, and you need to examine any roles that the failed server played. If the failed server was a global catalog server, you should designate another domain controller as a global catalog server. If the failed server held an operations master role, you will need to seize the role and give it to another domain controller. Let's start with DNS and roles.
To clean up DNS, you need to remove all records for the server in DNS. This includes SRV records that designate the computer as domain controller and any additional records that designate the computer as a global catalog server or PDC emulator if applicable.
To designate another server as a global catalog server, see the section entitled "Designating Global Catalog Servers".
To transfer operations master roles, see the section entitled "Changing Operations Masters".
To clean up references to the failed domain controller in Active Directory, you are going to need to use Ntdsutil. You must use an account with Administrator privileges in the domain. You can, however, run Ntdsutil from any computer running Microsoft Windows 2000 or later. The cleanup process is as follows:
Click Start, click Run, type cmd in the Open field, and then click OK.
At the command prompt, type ntdsutil. This starts the Directory Services Management Tool.
At the Ntdsutil prompt, type metadata cleanup. You should now be at the Metadata Cleanup prompt.
Access the Server Connections prompt so that you can connect to a domain controller. To do this, type connections and then type connect to server DCName where DCName is the name of a working domain controller in the same domain as the failed domain controller.
Exit the Server Connections prompt by typing quit. You should now be back at the Metadata Cleanup prompt.
Access the Select Operation Target prompt so that you can work your way through Active Directory from a target domain to a target site to the actual domain controller you want to remove. Type select operation target.
List all the sites in the forest by typing list sites and then type select site Number, where Number is the number of the site containing the failed domain controller.
List all the domains in the site by typing list domains in site and then type select domain Number, where Number is the number of the domain containing the failed domain controller.
List all the domain controllers in the selected domain and site by typing list servers in site and then type select server Number, where Number is the number of the server that failed.
Exit the Select Operation Target prompt by typing quit. You should now be back at the Metadata Cleanup prompt.
Remove the selected server from the directory by typing remove selected server. When prompted, confirm that you want to remove the selected server.
Type quit twice to exit Ntdsutil. Next, remove the related computer object from the Domain Controllers OU in Active Directory Users And Computers. Finally, remove the computer object from the Servers container for the site in which the domain controller was located, using Active Directory Sites And Services.