In-Depth

The TaeBo Workout for Your Active Directory Database

ntds.dit can quickly grow flabby if you don’t work it out regularly. Let NTDSUtil be your coach.

• By Mark England
• 03/01/2002

If you’re using Windows 2000, then you’re probably using Active Directory. AD, like most other directory services, uses a database; in this case, the Microsoft JET database. As with any database, you should be concerned with keeping it healthy. When it comes to AD, extra care should be taken, as it’s the heart and soul of Win2K. Using both online and offline defragmentation can help you achieve this goal.

The Active Directory Logs
It’s good to know and understand the files that work with the AD database. The key files are:

• ntds.dit
• edb.log
• res1.log
• res2.log
• edb.chk

When a change is made to the Win2K database, triggering a write operation, Win2K records the transaction in the log file (edb.log). Once written to the log file, the change is then written to the AD database. System performance determines how fast the system writes the data to the AD database from the log file. Any time the system is shut down, all transactions are saved to the database.

During the installation of AD, Windows creates two files: res1.log and res2.log. The initial size of each is 10MB. These files are used to ensure that changes can be written to disk should the system run out of free disk space. The checkpoint file (edb.chk) records transactions committed to the AD database (ntds.dit). During shutdown, a “shutdown” statement is written to the edb.chk file. Then, during a reboot, AD determines that all transactions in the edb.log file have been committed to the AD database. If, for some reason, the edb.chk file doesn’t exist on reboot or the shutdown statement isn’t present, AD will use the edb.log file to update the AD database.

The last file in our list of files to know is the AD database itself, ntds.dit. By default, the file is located in %systemroot%\NTDS, along with the other files we’ve discussed. During the installation of AD (by running DCpromo), you can specify that the log files and database files be installed in different locations, as shown in Figure 1.

Figure 1. The default locations for the Active Directory database and log files.

Online vs. Offline Defrag
As I mentioned earlier, there are two types of defragmentation. The first is online, which happens automatically, by default, every 12 hours as part of the garbage collection process. (For more information on this, see Knowledge Base article Q198793, “The Active Directory Database Garbage Collection Process.”) The good news about online defrag is that it’s automatic, and the domain controller stays online. Unfortunately, online defrag doesn’t reduce the total size of the database file. It only reclaims free space from within the database file. Reducing the total size of the database can only be accomplished by performing an offline defrag.

To reduce the size of the AD database, you’ll need to reboot the server and use the F8 option, then choose Directory Services Restore Mode. This allows you to boot the server, but not start AD. You can now work with the AD files that are open when the server’s in normal operation. Once booted into Directory Services Restore Mode, you can use the NTDSUtil.exe utility to compact the database. When compacting ntds.dit, you need to have enough free disk space to hold a copy of the current ntds.dit file. Here are the steps to complete an offline defrag. These are adapted from Q232122, “Performing Offline Defragmentation of the Active Directory Database.” I added steps one and three as a safety measure to ensure that any mistakes made running the NTDSUtil.exe utility wouldn’t be catastrophic.

1. Using NTBackup, create a System State Backup.
2. Boot to Directory Services Restore Mode.
3. If you have the space, you can rename the old file as a backup until you’re sure that everything is working.
4. At the command prompt, run NTDSUtil.
5. Type files and press Enter.
6. Type info and press Enter. Note the path to the current active ntds.dit file.
7. Type compact to “c:\new” (this will create a new, compacted ntds.dit file in c:\new. The directory will be created if it doesn’t exist).
8. Type quit two times to exit NTDSUtil.
9. Replace the current ntds.dit file (using the path noted from step six) with the compacted ntds.dit file just created in the c:\new folder location
10. Delete all the log (*.log) files in the active AD database location, as instructed by NTDSUtil.
11. Restart the server and let it boot normally.

After completing an offline defrag, perform a backup immediately. Once you’re sure that AD is working and a backup has been completed, you can delete the backup copy of the ntds.dit file. Figure 2 shows the NTDSUtil utility after it’s finished running.

Figure 2. A command window shows the process of compacting the AD database. (Click image to view larger version.)

Hey, It Works!
As a test to see how much space could be reclaimed by NTDSUtil, I built a new Win2K Advanced Server and installed Service Pack 2. After running DCpromo and installing AD, I wrote a Visual Basic application that added 25,000 users and groups to AD.

After I added 50,000 objects, the ntds.dit file grew from the default 10.256MB to 221.1MB. I then ran NTDSUtil, which reduced ntds.dit from 221.1MB to 184.6MB.

For the last phase of my unofficial test, I deleted the 50,000 objects I had added previously. When an object in AD is deleted, the object doesn’t really disappear from AD; it’s simply marked for deletion at a later date. This is called the “Tombstone” process. When the date expires (tombstoneLifetime) on the object marked for deletion, AD then deletes the object. This whole process is part of the garbage collection process, which runs, as I mentioned, every 12 hours on every DC. All tombstone records are replicated to every other DC.

To speed up the garbage collection process, I used ADSIEdit (installed as part of the Win2K support tools found on the Win2K CD in the support | tools directory) to set the garbage collection attribute (garbageCollPeriod) to one hour, advanced the date on my test server ahead by 30 days, and rebooted. I left the server overnight so that AD would perform the online defragmentation. The next morning, I ran NTDSUtil again. The file size shrunk from 184.6MB to the default size of 10.256MB.

One important note: This test server was built as a standalone in an isolated network. In a production environment you shouldn’t advance the system time in order to force deletion of tombstoned objects in AD. Doing so may result in problems with such items as replication conflicts, Kerberos ticket lifetimes, and backup. For more information, see Q289668, “Advancing Time on Production Computers and the Effect on Active Directory and FRS.”

Online defrag runs on every DC automatically. Because DCs only replicate changes, performing the offline defrag on one DC won’t affect the ntds.dit size on another DC. Hence, you must perform the offline defrag on each DC manually. Also, the DC must be rebooted into Directory Services Restore Mode, so only one DC should be done at a time. Because of the design of AD, the file size of ntds.dit will differ on each DC.

Keep It Healthy To Keep You Happy
With all the day-to-day tasks involving AD (adding users, deleting users, modifying group membership and so on), it’s easy to see how AD can become fragmented within a short period of time. Needless to say, proper monitoring and maintenance of AD is important to the overall health of a Win2K network. Monitoring the state of your AD database, as well as performing preventive maintenance steps, will help ensure your AD functions at its optimum level.