Active Directory from a physicist’s perspective.

By now you understand that Microsoft Exchange 200x family can not live without Active Directory. And that is true because you as a human being also can not stand without your backbone. The backbone should be strong enough so that it can sustain shocks and heavy work done by your body. Unlike backbone in our body Active Directory Services are considered as the considered as the backbone for the network infrastructure.

Am I talking like a doctor? Yes, it’s a physicist’s language. Everybody talks about AD topology, namespace and all other stuff but I have seen very few people giving some credits to active directory database. Well, I am not even interested in this topic but can’t neglect it too. Imagine a situation when your one and only domain controller crashed and will not boot. If your boss is kind and soft hearted he would probably allow you to rebuild everything but mine one would simply kick me off the job. To troubleshoot the DS performance issues and server reboot problems you also need to understand the directory database as well. Let’s have a quick look.


If you can recall, AD database file name is ntds.dit and usually put at location WindowsNTDS but it is a good idea to put this file on a separate volume when you are designing a domain controller which will be hell busy once it will be ready to serve requests. This is one of the recommendations by Microsoft to improve the active directory performance.

This database is based on Microsoft Jet Database Technology and uses B-Tree file structure with transactional logging to ensure the recoverability from drive failures. Something like Exchange and SQL. To understand transactional logging you can read at

This database is a set of files. In a typical active directory installation if you browse to the location C:WindowsNTDS you will find some files in there. Below is the description of this set of files. Again, these files are your active directory database. So follow me and we will browse through the folder .WindowsNTDS



  • Ntds.dit. This is the main AD database. NTDS stands for NT Directory Services. The DIT stands for Directory Information Tree. The Ntds.dit file on a particular domain controller contains all naming contexts hosted by that domain controller, including the Configuration and Schema naming contexts. A Global Catalog server stores the partial naming context replicas in the Ntds.dit right along with the full Domain naming context for its domain.
  • Edb.log. This is a transaction log. Any changes made to objects in Active Directory are first saved to a transaction log. During lulls in CPU activity, the database engine commits the transactions into the main Ntds.dit database. This ensures that the database can be recovered in the event of a system crash. Entries that have not been committed to Ntds.dit are kept in memory to improve performance. Transaction log files used by the ESE engine are always 10MB.
  • Edbxxxxx.log. These are auxiliary transaction logs used to store changes if the main Edb. log file gets full before it can be flushed to Ntds.dit. The xxxxx stands for a sequential number in hex. When the Edb. log file fills up, an Edbtemp. log file is opened. The original Edb. log file is renamed to Edb00001. log, and Edbtemp. log is renamed to Edb. log file, and the process starts over again. ESENT uses circular logging. Excess log files are deleted after they have been committed. You may see more than one Edbxxxxx. log file if a busy domain controller has many updates pending.
  • Edb.chk. This is a checkpoint file. It is used by the transaction logging system to mark the point at which updates are transferred from the log files to Ntds.dit. As transactions are committed, the checkpoint moves forward in the Edb. chk file. If the system terminates abnormally, the pointer tells the system how far along a given set of commits had progressed before the termination.
  • Res1.log and Res2.log. These are reserve log files. If the hard drive fills to capacity just as the system is attempting to create an Edbxxxxx. log file, the space reserved by the Res log files is used. The system then puts a dire warning on the screen prompting you to take action to free up disk space quickly before Active Directory gets corrupted. You should never let a volume containing Active Directory files get even close to being full. File fragmentation is a big performance thief, and fragmentation increases exponentially as free space diminishes. Also, you may run into problems as you run out of drive space with online database defragmentation (compaction). This can cause Active Directory to stop working if the indexes cannot be rebuilt.
  • Temp.edb. This is a scratch pad used to store information about in-progress transactions and to hold pages pulled out of Ntds.dit during compaction.
  • Schema.ini. This file is used to initialize the Ntds.dit during the initial promotion of a domain controller. It is not used after that has been accomplished.

Doesn’t that look like a full proof fail safe plan? If anything above goes corrupt and your DC, GC wont boot you can actually play around these files and get them up and running within minutes. And the tools listed below will be your force to fight against the crash and problems with your directory database.



This utility is unlike a one man army soldier. So, if you identify that the problem is with directory database and nowhere else. What all you need to do is to reboot the box and start it in Directory Services restore mode. Once machine is booted launch this command line utility and you can fix the problems with database files. The table below explains what are the command line parameters and what they are used for.




Compact to %s
(where %s identifies an empty target directory)

Invokes Esentutl.exe to compact the existing data file and writes the compacted file to the specified directory. The directory can be remote, that is, mapped by means of the net use command or similar means. After compaction is complete, archive the old data file, and move the newly compacted file back to the original location of the data file.
ESENT supports online compaction, but this compaction only rearranges pages within the data file and does not release space back to the file system. (The directory service invokes online compaction regularly.)


Writes the header of the Ntds.dit data file to the screen. This command can help support personnel analyze database problems.


Analyzes and reports the free space for the disks that are installed in the system, reads the registry, and then reports the sizes of the data and log files. (The directory service maintains the registry, which identifies the location of the data files, log files, and directory service working directory.)


Invokes Esentutl.exe to perform an integrity check on the data file, which can detect any kind of low-level database corruption. It reads every byte of your data file; thus it can take a long time to process large databases.
Note that you should always run Recover before performing an integrity check.

Move DB to %s
(where %s identifies a target directory)

Moves the Ntds.dit data file to the new directory specified by % s and updates the registry so that, upon system restart, the directory service uses the new location.

Move logs to %s
(where %s identifies a target directory)

Moves the directory service log files to the new directory specified by % s and updates the registry so that, upon system restart, the directory service uses the new location.


Invokes Esentutl.exe to perform a soft recovery of the database. Soft recovery scans the log files and ensures all committed transactions therein are also reflected in the data file. The Windows 2000 Backup program truncates the log files appropriately.
Logs are used to ensure committed transactions are not lost if your system fails or if you have unexpected power loss. In essence, transaction data is written first to a log file and then to the data file. When you restart after failure, you can rerun the log to reproduce the transactions that were committed but hadn’t made it to the data file.


Invokes Esentutl.exe to perform a low-level repair of the data file. Use the repair command only on the advice of qualified service personnel, as it can cause data loss. Furthermore, this can only repair what ESENT knows about. This means that its notion of repair might eliminate some data that is key to the safe operation of the directory service.

Set path backup %s
(where %s identifies a target directory)

Sets the disk-to-disk backup target to the directory specified by % s . The directory service can be configured to perform an online disk-to-disk backup at scheduled intervals.

Set path DB %s
(where %s identifies a target directory)

Updates the part of the registry that identifies the location and file name of the data file. Use this command only to rebuild a domain controller that has lost its data file and that is not being restored by means of normal restoration procedures.

Set path logs %s
(where %s identifies a target directory)

Updates the part of the registry that identifies the location of the log files. Use this command only if you are rebuilding a domain controller that has lost its log files and is not being restored by means of normal restoration procedures.

Set path working dir %s
(where %s identifies a target directory)

Sets the part of the registry that identifies the directory service’s working directory to the directory specified by % s .