Practice Proactive AD Maintenance

[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)

• a corrupted or invalid database schema (the schema defines the database structure—what type of data it contains and how it arranges that data)
• missing DNS records
• damaged or corrupted information
• accidental misconfiguration by an administrator

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.