March 10, 2011, 4:34 a.m.
posted by vdv
Backing Up the Directory
In the good old days of classic NT, you could capture the Registry hives on a single Emergency Repair Disk in a smallish domain and on the hard drive using RDISK -S if the Security Account Manager (SAM) was too big to fit on a floppy. Those days are long gone. In fact, RDISK is no longer even available.
Active Directory operations rely heavily on the Registry and many different system binaries, so you must back up and restore whole swatches of the system directory to retain integrity. Microsoft calls these files the System State. Figure shows the list of System State files as they are displayed in NT backup. They include the following:
Forcing you to back up all these files in one scoop does maintain consistency between the various data storehouses, but it means that if you make a minor mistake that affects a portion of the Registry out of reach of the Last Known Good Configuration rollback, you might be forced to restore all the System State files, including Active Directory.
This topic covers backing up and restoring the System State files using Ntbackup. This is a stripped-down version of Veritas Backup Exec. Third-party backup utilities are available that perform the same functions. This includes the full version of Backup Exec, Computer Associates ArcServe, Legato Networker, Tivoli Storage Manager, BEI Corporation UltraBac, CommVault Galaxy, and others. All of these vendors make backup utilities that are Windows Server 2003 compliant. Make sure you upgrade to the most current version, because a Windows 2000 backup utility may not be fully compatible with Windows Server 2003.
Why Active Directory Backups Are Necessary
You may be wondering why AD backups are required at all. After all, if you design your system correctly, you should always have at least three domain controllers in a domain. Each of these domain controllers has a full copy of Active Directory. If any of those servers crash, or even if two of them go down, you still have a third to fall back on. You can quickly promote another Windows member server to a domain controller and regain fault tolerance.
The most obvious answer to "why backup a domain controller" is that Mr. Murphy knows if you don't do backups and may arrange the universe so that all three of your domain controllers crash at the same time. Or, you may get a fire that takes your server room and you need a way to recover Active Directory at a remote site. You never want to be without a full backup in case the stars ever do align in a manner that is not in your best interests.
The more likely occurrence, though, is a mistake on the part of an administrator. I've done it. You'll do it. You get tired or distracted and you delete or modify the wrong object and well, needless to say, things can get a little ugly. If you accidentally delete an entire OU with thousands of user and computer and group objects in it, your mistake will merrily replicate to all the other domain controllers. The only way you'll get that information back is from tape.
You do not need to back up all your domain controllers. Select two or three from your domain and backup System State on those machines. Don't run applications on the domain controllers that would require them to be backed up by local administrators.
Performing a System State Backup
A System State backup is always performed with the machine online and operating normally. The Plug-and-Play Manager should find your tape drive and install the proper drivers for it. You may need to use the Removable Storage Manager to juggle your media pools. See Chapter 21, "Recovering from System Failures," for details.
To perform a System State backup using Ntbackup, follow Procedure 10.6.
Review the list of files in the log to see what is included. Note that the Active Directory files do not appear individually on the backup log. There is just a single line entry indicating that Active Directory was included in the backup.
The Registry files are first copied to a special folder called \Registry from their normal location in \WindowsWindows\System32\Config. The \Registry folder is a temporary, volatile folder used to capture a snapshot of the Registry for backup. This prevents a file lock during backup from blocking access to the Registry.
Restoring Active Directory
In the first scenario, the tape restore of the System State files (which includes Active Directory) is done in conjunction with the restore of the operating system. When the newly restored domain controller comes back online, its replication partners update it with the changes that have occurred since the tape backup was run. For this reason, you should be able to restore from a relatively old tape (three or four days, even a week old) just in case you have problems with your tape library that prevent you from using last night's backup.
Directory Services Restore Mode Password
When restoring Active Directory at a domain controller, you must be able to log on to the server using the Administrator account in the local SAM. You may not know the password for this account.
To remedy this problem, Microsoft included a new feature in the Ntdsutil utility for resetting the local Administrator password. This feature is called Reset DSRM Administrator Password. If you have administrator privileges on a domain controller, you can use this feature to change the Administrator account in the SAM of the domain controller.
Ordinarily, non-administrators are not permitted to log on locally at a domain controller. If a non-administrator does succeed in getting access to a domain controller console and attempts to reset the DSRM password, this is the result:
Reset DSRM Administrator Password: reset pas on ser dotnet-rc-es Please type password for DS Restore Mode Administrator Account: Setting password failed. WIN32 Error Code: 0x6ba Error Message: The RPC server is unavailable.
A standard System State restoration does "recover" objects you have deleted from Active Directory. When the newly restored domain controller replicates from its partners, any undeleted objects are promptly moved back to the Deleted Objects container and all your hard work goes for naught.
If you need to restore a portion of Active Directory (a single object, for instance, or an accidentally deleted OU), or the entire database in the event that it has become irresolutely corrupted, you must ensure that the objects and their properties on the tape replicate outward to the other domain controllers. This is accomplished with an authoritative restore.
An authoritative restore is not a restoration as such. It is performed after the actual tape restoration to mark the objects that will overwrite the replicas on other domain controllers. It does this by adding 100000 to the Property Version Number (PVN) of each property on the authoritatively restored objects.
The following is a REPADMIN listing showing how a sample object looks before and after an authoritative restore. The ObjectClass attribute is not touched by the authoritative restore because it is a special attribute used for indexing:
Loc.USN Originating DSA Org.USN Org.Time/Date Ver Attribute ======= =============== ======= ============= ====== ========= 2562 Houston\HOU-DC-01 2562 2001-10-23 21:21.29 1 objectClass 3112 Houston\HOU-DC-01 3112 2001-10-24 09:29.12 2 cn 3112 Houston\HOU-DC-01 3112 2001-10-24 09:29.12 2 sn 2562 Houston\HOU-DC-01 2562 2001-10-23 21:21.29 1 description 2562 Houston\HOU-DC-01 2562 2001-10-23 21:21.29 1 givenName 2562 Houston\HOU-DC-01 2562 2001-10-23 21:21.29 1 instanceType ...
Loc.USN Originating DSA Org.USN Org.Time/Date Ver Attribute ======= =============== ======= ============= ====== ========= 2562 Houston\HOU-DC-01 2562 2001-10-23 21:21.29 1 objectClass 28905 Houston\HOU-DC-01 28905 2001-10-29 19:59.32 100002 cn 28905 Houston\HOU-DC-01 28905 2001-10-29 19:59.32 100002 sn 28905 Houston\HOU-DC-01 28905 2001-10-29 19:59.32 100001 description 28905 Houston\HOU-DC-01 28905 2001-10-29 19:59.32 100001 givenName 28905 Houston\HOU-DC-01 28905 2001-10-29 19:59.32 100001 instanceType ...
Use great caution when doing an authoritative restore of the Configuration naming context or of the entire Active Directory database. Make sure you understand the consequences of overwriting any system configuration parameters. This is especially true if you are running Exchange 2000 or other Active Directory-dependent applications. It is not necessary to restore the entire database to get back a single OU. Be selective.
Who Can Restore Active Directory
If you have a distributed IT organization with administrators in many regions, you may wonder who can perform a Directory restore. You may want to make sure that only qualified individuals do a tape restore on a domain controller. You may also want to find out if you can recover from a mistake without calling up the central IT staffers at headquarters to pull you out of a jam.
Performing a System State restore (which includes the Active Directory database) requires having the local Administrator password in the SAM on the domain controller. This is called the Directory Service Recovery password. If you know this password, you can also perform an authoritative restore of any or all of the Active Directory database, regardless of whether you have rights to a particular portion of the Directory tree. This is because the Active Directory service is not running when you do the authoritative restore, so the system has no way of collecting or validating your credentials.
You should guard the local Administrator password on domain controllers closely and change it frequently, but be aware that utilities such as ERD Commander permit anyone with physical access to a domain controller to set the local Administrator password to get full access. You should take the following actions to guard your Active Directory database:
Time Limit for Using Backup Tapes
It happens in every IT organization at one time or another. You need to do a tape restore and last night's tapes are either unreadable or the backup didn't run. You go back into the library and find that some of the tapes are so old you can see daylight though the oxide layer. And some of the good tapes got jammed up in the library robot assembly and didn't actually get anything written to them. You will eventually find a mountable tape, but it might be a week or two old. You then wonder if you can safely restore Active Directory from that tape.
The good news is that you can restore System State from a somewhat older tape without compromising Active Directory. As soon as you finish the System State restoration and restart the domain controller, the restored copy of Active Directory will obtain updates from its replication partners and get caught up to date. If you perform an authoritative restore, on the other hand, you will lose any changes such as password resets, group membership changes, new domain trusts, and so forth that happened in the meantime. Be very careful when using an older tape for an authoritative restore.
This ability to use an older copy of Active Directory has two limits. The first limit is tied to the tombstone lifetime for deleted objects in Active Directory.
When an AD object is deleted, the ESE engine does a little Dante number on it. The object is stripped of all but a couple of attributes and hurled into the depths of the Deleted Objects container where it sits and rots for 60 days. At the end of 60 days—the standard tombstone lifetime—the object is removed completely from the database by the garbage collection process.
This means that you must not restore System State (and by inference, Active Directory) from a tape that is more than 60 days old. Let me give an example to show the risk.
Let's say you delete an object from AD and then perform a System State restore from last night's backup. As long as you do not do an authoritative restore of that object, it will be redeleted as soon as the domain controller pulls updates from its replication partners. The updates say, in effect, "This object is in my Deleted Objects container. Move your copy of the object to the Deleted Objects container, as well."
But, if you restore from a tape that is more than 60 days old, the replication partners will have removed some of the tombstoned objects from the Deleted Objects container. They then have no way to tell the newly restored domain controller to delete the old objects. The newly restored go into limbo. They are deleted on all replicas of the naming context except for the restored machine. This corrupts Active Directory.
Keep this 60-day window in mind if you have disaster recovery procedures that could potentially introduce an older copy of Active Directory into your system. For instance, do not make images of domain controllers for use in disaster recovery. The CD that holds the image stops being your best friend and starts being your worst nightmare on day 61 after it was burned. If you want to use imaging as a recovery strategy, take an image before you promote a server to a domain controller. Restore the image then promote the machine to a domain controller. This replicates a fresh copy of the Directory from another domain controller.
If you lose all copies of Active Directory during a catastrophe of some sort, your only alternative is to restore from the most recent tape you can find and deal with any changes that have been made in the interim, such as password changes or group membership changes.
Active Directory Restores and Trust Relationships
A second time limit also affects your ability to do System State restores from older tapes. If you have external trust relationships to other forests or NT domains, these trust relationships have passwords that change every 7 days. When a new password is negotiated, the old password is retained. For this reason, if you restore from a tape that is older than 14 days, you will need to verify the external trust relationships and force a renegotiation of the password. In the worst case, you must remove and re-install the trust.
Authoritative Restoration and Sysvol
The File Replication Service, or FRS, replicates the contents of Sysvol among all domain controllers in a domain. If you authoritatively restore the Group Policy Container (GPC) objects in Active Directory without returning Sysvol to the condition that existed when the System State backup was obtained, you risk a mismatch between the GPC objects in AD and the GPT files in Sysvol.
There is no such thing as an authoritative restore of Sysvol. Instead, you must restore a copy of the System State files, including the Sysvol files, to an alternative location and then copy them over the Sysvol files after you restart following an authoritative restore of the AD. To see how it works, take a look at Procedure 10.7.
Restoring System State
When you restore the System State files, you overwrite the existing files on the machine. Many of these files are databases that are normally locked when the server is operating. This includes the Active Directory database, the Registry hives, the Certificate database, and others.
To do a System State restoration, then, you must boot the machine into a configuration where these databases are not running. This is done using Directory Service Restore Mode, one of the safe mode options in Windows. Select this option from a menu by pressing F8 at the standard boot menu. If you do not see a boot menu, press F8 as soon as the machine completes POST. This puts the keystroke in the keyboard buffer where it will be seen when NTLDR is activated.
The Directory Service Restore Mode option loads the network drivers so you can do a tape restore across the network but does not start Active Directory and other critical databases. This mode also sets the environment variable SAFEBOOT_OPTION to DSREPAIR. This variable must be set or Ntdsutil will not perform an authoritative restore.
Because Active Directory is not available when booting to Directory Services Restore Mode, you must provide the password for the Administrator account in the local SAM. This is the password you entered when you promoted the server to be a domain controller.
When you have logged on to the Safe mode console, perform a System State restoration as shown in Procedure 10.8.
At this point, you have completed the System State restoration. If you do not need to restore individual objects or containers, you can restart the domain controller and let it replicate any changes that have occurred since the backup was run. If you want to restore individual components of the Directory, proceed to the next section.
Performing an Authoritative Directory Restoration
Because the authoritatively restored properties have higher PVNs than the replicas on other domain controllers, the properties replicate outward and overwrite other replicas. For this reason, an authoritative restore can result in lots of replication traffic. Schedule it for after hours and pay particular attention to domain controllers at the wrong end of slow WAN links. When you're ready to start, follow Procedure 10.9.