If you run a Windows 2000 network, you most likely use Active Directory. AD, like most other directory services, uses a database—in AD's case, a version of the Microsoft Extensible Storage Engine (ESE)—to store information. AD is the heart and soul of Win2K, so you need to take extra care to ensure its health. Periodically using the Ntdsutil utility (ntdsutil.exe) to perform an offline defragmentation can help you achieve this goal.
Get to Know AD and Your Defragmentation Options
Before you begin working with Ntdsutil, get to know the key AD database files—edb.log, ntds.dit, res1.log, res2.log, and edb.chk—all of which reside in \%systemroot%\ntds on a domain controller (DC) by default. During AD installation, Dcpromo lets you specify alternative locations for these log files and database files, as Figure 1, page 76, shows. The best practice for a Win2K DC is to install the OS files, transaction logs, and database files on separate spindles. The most common approach is to install the files on separate mirrored drives (i.e., RAID 1).
Any change to AD triggers a write operation, which causes ESE to write all changes to both the database file and the log file. AD periodically flushes the log file as the OS commits sets of database updates. System performance determines how fast the system writes data. At process termination, AD rolls back any open transactions. During AD installation, Win2K creates the blank log files res1.log and res2.log, each of which has an initial size of 10MB. Should the system run out of disk space to store changes, AD will rename res1.log and res2.log and begin using those files.
Two types of defragmentation—online and offline—take place. By default, online defragmentation automatically happens every 12 hours as part of AD's garbage-collection process. This process runs independently on each DC, releasing free space within the AD database file. (For more information about the process, see the Microsoft article "The Active Directory Database Garbage Collection Process" at http://support.microsoft.com/?kbid=198793.) The good news about online defragmentation is that it's automatic and the DC stays online. The bad news is that online defragmentation doesn't reduce the total size of ntds.dit; it only reclaims free space from within the file. To reduce the total size of the database on disk, you must perform an offline defragmentation, which compacts ntds.dit. The easiest way to determine when to run an offline defragmentation is to turn up garbage-collection logging to level 1. Doing so causes the directory service agent (DSA) to log an event that reports the database size and the estimated amount of internal free space.
You might never need to run an offline defragmentation of AD under typical operations. However, after a major object move or a migration to Win2K, such an exercise can prove beneficial. An example of an event that might prompt an offline defragmentation is using a third-party product that creates duplicate accounts in AD, merges those placeholder accounts with the original accounts, then deletes the placeholder accounts later during a cleanup process. This type of addition and deletion can fragment AD internally, but you can use Ntdsutil to defrag and compact the database and regain needed disk space. (Note that if under typical conditions a system volume's free disk space is so small that compacting the database will significantly increase the free space, Ntdsutil might not be able to solve the problem.)
Keep in mind that because DCs only replicate changes, performing an offline defragmentation on ntds.dit on one DC won't affect ntds.dit on other DCs. Hence, you must manually perform an offline defragmentation on each DC. Because of AD's design, ntds.dit's size will differ on each DC.