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
- March 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:
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
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
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.
- Using NTBackup, create a System State Backup.
- Boot to Directory Services Restore Mode.
- If you have the space, you can rename the old file as a backup until
you’re sure that everything is working.
- At the command prompt, run NTDSUtil.
- Type files and press Enter.
- Type info and press Enter. Note the path to the current active ntds.dit
- 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
- Type quit two times to exit NTDSUtil.
- 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
- Delete all the log (*.log) files in the active AD database location,
as instructed by NTDSUtil.
- 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
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,
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.