Practice Proactive AD Maintenance

Techniques and tools for backing up and defragmenting your Win2K network's most crucial service

[Editor's Note: Portions of the following article were excerpted from The Definitive Guide to Active Directory Troubleshooting (Realtimepublishers.com)]

Anyone who's familiar with Windows 2000 shouldn't be surprised to learn that Active Directory (AD) is the most important service on any Win2K AD-based network. AD is a set of databases, services, and APIs that comprise the heart of a Win2K network. Because AD is the central repository for crucial network elements such as domains, organizational units (OUs), Group Policy, computers, printers, and users, you must protect AD appropriately. Although AD is a robust and fault-resilient enterprise directory service, it's far from error-proof. The very nature of a network-replicated database hosted on PC-based servers (with associated hardware and software vulnerabilities) means that entropy in AD is a fact of life. To guarantee maximum uptime and availability of your AD-based network, you must develop a two-pronged plan that consists of regular maintenance of your AD network environment and a recovery plan that's grounded in solid AD and Win2K server disaster-recovery skills. The first part of this plan—proper maintenance—involves proactive monitoring, backups, and defragmentation.

AD Care and Feeding
Regularly backing up and defragmenting your AD database are crucial tasks in maintaining your AD environment, and I go into these tasks in depth a little later. However, proactive monitoring of AD and related components is another important maintenance step that's often overlooked. Regular monitoring lets you identify and repair problems before they spin out of control. For a discussion of the components you should monitor and some of the tools available to help you with that job, see "Monitoring Your AD-Enabled Network," September 2000, InstantDoc ID 9645.

AD Backup
In the world of disaster recovery, preparation is everything. Therefore, understanding AD backup concerns and implementing a solid backup regimen are vital steps in any AD disaster-prevention plan.

Because AD is a replicated database, it's vulnerable to the problems that can plague any database. These problems include (but aren't limited to)

As a result, your disaster-preparation and -recovery plan must include provisions for backing up and restoring the AD database in case such an event occurs. Because the files that comprise AD (including ntds.dit and the transaction log files) are continually in use on an active Win2K domain controller (DC), you can't simply copy the AD database as you would a standard user data file. However, the Win2K Backup utility lets you perform an online AD backup and automatically backs up AD whenever you include system-state data as part of a Win2K DC backup. When you back up the system-state data on a DC, you're backing up all AD data that exists on the server, along with other system components such as the sysvol directory and the registry (for more information about system-state data, see the sidebar "System-State Components"). You can't choose to back up or restore individual components of the system-state data or of AD—it's an all-or-nothing proposition because of the dependencies among various system-state components, including AD.

Before you begin an AD defragmentation, I recommend that you use NT Backup or a third-party backup utility to perform a system-state backup. Although the Win2K Backup utility can handle the job of backing up AD, most IT shops prefer to use more robust third-party applications. Several excellent third-party Win2K backup utilities can back up and restore AD. For more information about third-party utilities, visit the IT Buyer's Network at http://www.itbuynet.com.

AD backups have special characteristics and constraints that you should be aware of. First, AD backups have the effective equivalent of a freshness date. When you delete an AD object, the DC from which the object was deleted creates a tombstone of the object to notify other DCs about the deletion. A tombstone is a representation of an object that has been marked as deleted but hasn't actually been removed from the directory. The DC will eventually remove the tombstoned object according to the global tombstone-lifetime setting, which defaults to 60 days.

Tombstones are of concern because if AD restores operation to a state before an object's deletion and doesn't replicate that object's tombstone to the restored DC before the tombstone expires, the object remains present only on the restored DC, resulting in an AD database inconsistency. Therefore, you need to be sure to restore the DC and ensure that inbound replication from a DC that contains the tombstone is completed before the tombstone expires.

To protect itself from this situation, Win2K denies restore operations involving AD backups that are older than the configured tombstone lifetime period. Make AD backups at least once during the tombstone lifetime and preferably more often.

However, if your only backup is older than the tombstone-lifetime interval, don't despair. In this situation, you can use the instructions in the Microsoft article "Backup of the Active Directory Has 60-Day Useful Life" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q216993) to perform the restore operation. In some situations, this procedure will include modifying the tombstone-lifetime value on the server.

Second, note that although your other backup procedures might use various backup types, including normal (full), full copy, differential, and incremental backups, the system-state concept means that a normal backup is the only type possible for AD. A normal backup creates a backup of the entire system state while the DC is online (with AD services running) and clears each file's archive attribute to mark the files as backed up.

Third, make sure that your DC backups include at least the system state, the system disk contents, and the sysvol folder (if it isn't located on the system disk). As I explained earlier, the system state includes many key files and settings for restoring a DC. Backing up the system disk and sysvol folder structure ensures that all the required system files and folders are in place to initiate a successful restoration. Furthermore, put AD log and database files on separate disk spindles (physical disks or disk sets if you use RAID volumes). When you configure your DCs in this manner, AD components will be spread out on multiple drives (e.g., your log files might be in C:winnttds and your ntds.dit database file in D:winnttds). Because the AD log files and database are automatically backed up whenever system-state information is included in a backup, you need to back up only the system disk and system state to ensure a good backup, even under this distributed installation.

Fourth, consider that you can use a DC backup to restore only that DC; you can't use a backup made from one DC to restore another. So to completely back up your environment, you need a backup of every DC in your enterprise. To begin backing up any AD-based network environment, back up all the Operations Master (OM) role holders, Global Catalog (GC) server DCs, and the first DC in the root domain. Consider additional DCs on a case-by-case basis according to factors such as the impact of server downtime and whether the server contains data that can't be restored from other sources (e.g., AD replication).

Fifth, be aware of a rather nasty bug in the AD backup and restore API in pre­Service Pack 2 (SP2) Win2K versions. For more information, see the sidebar, "The AD Backup Bug."

AD Defragmentation
In addition to proactive monitoring, troubleshooting, and change-analysis and management activities, consider performing occasional offline AD defragmentations to help ensure the availability of your directory services. Defragmentation can occur online or offline. By default, online defragmentation takes place automatically every 12 hours. This activity is part of AD's garbage-collection process, which the Microsoft article "The Active Directory Database Garbage Collection Process" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q198793) describes. If you're familiar with Microsoft Exchange Server, you'll recognize this process.

Although the automatic nature of online defragmentation makes it handy, the process does nothing to reduce the size of the ntds.dit AD database file on a DC. Instead, the process reclaims free space from within the file. To reduce the database file size, you need to perform an offline defragmentation of the directory. Before you start this process, verify that you have enough free disk space to hold a copy of the current ntds.dit file.

To perform the offline defragmentation, follow these steps: Use the F8 alternate boot menu at startup to boot the DC in Directory Services Restore Mode. Make a copy of the old ntds.dit file (its default location is C:winnttds) as a precautionary measure. At a command prompt, type

ntdsutilfiles

and

info

Note the directory path; it indicates the current location of the active version of the ntds.dit database file. You'll use this location in a later step. Type

compact to c:mydir

This command creates a new compacted copy of ntds.dit in the c:mydir folder; the system will create the folder if it doesn't already exist. Type

quit

two times to exit the Ntdsutil utility. Replace the current ntds.dit file (using the path you noted above) with the compact version you just created. Delete any log (*.log) files in the active AD database location, as the Ntdsutil utility instructs, and reboot the server.

Although it isn't necessary, regular defragmentation of the AD database on your DCs can help reduce the AD database file size, which in turn can improve directory performance and availability. Because performing an offline defragmentation also provides a degree of database verification (errors will occur during defragmentation if the database is corrupt), it can also serve as a "canary in the coal mine" to alert you to database problems. For additional information about AD defragmentation, see the Microsoft article "Performing Offline Defragmentation of the Active Directory Database" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q232122).

The final article in this series about recovering crucial network services will discuss the "break glass in case of emergency" aspect of AD maintenance: AD repair and recovery procedures and best practices. (For a list of the other articles in the series, see "AD Recovery Resources," page 20.)