Understanding Active Directory operations: The Jet database

http://searchwindowsserver.techtarget.com/tip/0,289483,sid68_gci1518671,00.html?track=NL-1112&ad=780944&asrc=EM_NLT_12267782

In this two-part series, Microsoft MVP Gary Olsen walks through some basics of Active Directory maintenance with details on how certain operations work. Part one focuses on the AD Jet database with simple steps for database repair. Part two continues this discussion with a look at Jet sessions and their affect on Active Directory database performance.

In my day-to-day work with administrators, I've found that many lack a full understanding of Active Directory database operations and maintenance.

One such area involves how Jet database sessions function within Active Directory. I ran into a situation recently that gave me some insight these processes, and thought it would be helpful for a lot of folks to share that information and review some database basics for keeping AD happy.

While the Active Directory Jet database isn't the slickest database technology in the world, it has served AD pretty well over the years. It's the same database type that Exchange Server uses, but without nearly the same amount of maintenance. For example, you don't have to do recovery operations like replaying the transaction logs. In fact, Active Directory's database -- in my experience -- is pretty self-healing.

The AD Jet database is held in %systemroot%\NTDS and consists of the Ntds.dit (database) file and transaction log files, as shown in Figure 1 (Windows 2000 and 2003) and Figure 1A (Windows 2008). Like any other Jet database, the current database is the result of the uncommitted entries in the transaction log file and the Ntds.dit database file.

Figure 1. The AD Jet database for Windows 2000 and 2003

Figure 1A. The AD Jet database for Windows 2008

As shown in Figure 2, the Edb.chk file indicates which transaction log entries have been committed. It is updated each time data has been written to the .dit file. As a best practice, the database and log files should be stored on different partitions (spindles). Windows Server 2003 made a giant improvement in the efficiency and size of the Ntds.dit by using a single-instance store of security descriptors. If you are still running Windows 2000 Server domain controllers (DCs) -- and I know a lot of environments that are -- you can expect a big difference when you move to Windows Server 2003.

Figure 2. Transaction log entries written to the Jet database

It is important to note that like everything else, DC operations that depend on Ntds.dit (authentication, LDAP operations, etc.) will be faster if Ntds.dit is loaded into physical memory. The Ntds.dit resides in the memory allocated for the Local Security Authority Subsystem (LSASS) process, so it's easy to see if Ntds.dit fits in physical memory. It is highly recommended to use x64 domain controllers since the flat memory model allows configuration of sufficient physical memory to load Ntds.dit into RAM.

Note: For more info, see my previous article on the LSASS process for Active Directory.

Database defrag

In smaller, more stable environments, you'll probably be OK if database maintenance is completely ignored. Periodically there is an online defragmentation that runs and is recorded in the directory services log once a day. Event ID 700 indicates the start of the defragmentation and Event ID 701 indicates the completion.

While this is better than nothing, it doesn't get rid of the "whitespace" in the database. For instance, if you delete a large number of objects, you must do an online defrag to recover the space. Here are the steps to performing an offline defrag:

1. Boot the DC to Directory Services Restore mode (DSRM).
   
2. From a command prompt, open NTDSUtil.exe.
   a. In Windows Server 2008 and R2, execute:
   Ntdsutil>Activate Instance NTDS
   (This is not required for Windows 2000 or 2003)
3. Enter Files at the NTDSUtil prompt to open the File Maintenance menu.
4. In the File Maintenance menu, type a question mark (?) to see all the commands available. We will use the Compact option. This option requires the name of a temporary location for the compacted database.
5. Create a temporary location for the database such as C:\ESE-Backup.
6. From the File Maintenance prompt enter: Compact to c:\ESE-Backup.
7. When the compacting operation completes, you will see the response shown in Figure 3.
8. Following the instructions, copy the new compacted Ntds.dit in c:\ESE-Backup to c:\windows\ntds\ntds.dit (overwriting the old file), then delete the four logs. You will only have the Edb.chk, Temp.edb and Ntds.dit files left.

Figure 3. The completed compacting operation (click to enlarge)

Database repair

There are times when you will find events indicating NTDS database errors (they are pretty obvious in the event description). A general rule of thumb when you encounter errors like these is to use the Semantic Database Analysis option in the main menu of NTDSutil, as shown in Figure 4.

Figure 4. Semantic Database Analysis option (click to enlarge)

At the Semantic checker prompt, there are two options of interest: Go and Go Fixup. I've never had a negative experience in my years of running this command; it may or may not resolve the problem, but it won't hurt anything either. With that in mind, use the Go Fixup feature. I've never been able to tell if it found any problems (see Figure 5), so the only way to know if it helped is if the events quit or the behavior you are trying to repair goes away. Again -- run it when you see database errors in the event log and it won't hurt anything.

Figure 5. The Go Fixup feature

Continue to part two, Troubleshooting Jet session issues for Active Directory