The Active Directory (AD) database is constantly changing, and over time, these changes can cause the database to respond to the system more slowly than necessary. To squeeze the best possible performance out of your servers, you should optimize your AD database. Here are a few techniques that you can use to increase the efficiency of your AD database and improve your overall system response time.

Database defragmentation
As the AD database is used, it becomes fragmented; the process of adding and removing database records leaves holes in the database, which causes the data to become scattered. You can help your server to perform better by defragmenting this database. The defragmentation process condenses the data within the database and reorganizes it in a logical fashion so that your system won’t have to waste time by jumping all over the database to get a piece of data here and a piece of data there.

Because database defragmentation is so important, Windows automatically defragments AD every 12 hours. However, there are times when it’s appropriate to manually defragment the database. For example, if you’ve just made a lot of changes to AD, you should defragment the database. Or if the AD database is somehow damaged, then the defragmentation cycle may not complete. So if you’ve had to repair AD, you might want to defragment it after the repair, because the database may not have been defragmented in a while.

There are two basic methods of defragmenting your AD database. You can perform an online defragmentation or an offline defragmentation. An online defragmentation is basically the automated process that Windows performs every 12 hours. To see how long ago the database was last defragmented, check the Directory Service event log. An online defragmentation writes an event number 700 when the process begins, as shown in Figure A.

Figure A
Event number 700 in the Directory Service Log indicates the defragmentation process has begun.

An event number 701 is written to the event log on the domain controller where the defragmentation took place, as shown in Figure B.

Figure B
Event number 701 in the Directory Service Log indicates the online defragmentation process has completed.

As I mentioned, an online defragmentation rearranges records within the AD database and fills in holes. It may seem strange, but an online defragmentation never decreases the size of the database. Instead, it simply organizes all of the empty space into one group.

An offline defragmentation would be performed as a maintenance chore. It’s referred to as offline because AD isn’t actually running during the defragmentation process. To initiate an offline defragmentation, reboot the server. During the early phase of the boot process, press [F5] to access the boot menu. When you see the boot menu, select the Directory Service Restore Mode option. Windows will then boot into what appears to be Safe Mode with network support. However, running in this Directory Service Restore mode is necessary because doing so takes AD offline.

Next, open a command prompt and create a temporary directory on your partition with the most available free space. This partition must have enough free space to accommodate a copy of your AD. If you’re in doubt as to the size of your AD, search your system for the AD database’s file name, Ntds.dit, and check its size. As you can see in Figure C, on my test system, the database was located in C:\WINNT\NTDS and was about 29 MB in size. The other copy that you see in the figure is an older copy that’s no longer in use.

Figure C

Enter the NTDSUTIL command in the command prompt window. When you see the NTDSUTIL prompt, enter the FILES command. Next, at the FILE MAINTENANCE prompt, enter the command COMPACT TO pathoftemporarydatabase, where you will enter the path to your database. Windows will then begin the defragmentation process, which could take some time, depending on the speed of your computer and the size of your AD database. When the process finishes, you’ll have a compacted copy of the database in your temporary directory. Enter the QUIT command twice to exit the NTDSUTIL program. Then, overwrite your original database with the compacted copy. When you’re done, erase all of the .log files from the original database location. Figure D shows the entire process step-by-step.

Figure D
This is an example of the steps you’ll perform to compact and defragment your AD database.

Be sure to clean up your work by erasing the temporary copy of your AD database. You can then return your system to normal operations by simply rebooting.

Moving AD
By default, Windows 2000 places the AD database in the \%systemroot%\NTDS directory, usually \WINNT\NTDS. The problem with this is that many times the system drive simply isn’t big enough to accommodate AD.

If you’ve ever worked with Windows NT, you may recall a popular setup technique that involved creating a 2-GB FAT partition and placing the system files into it. The idea was that if a severe system crash were to occur, you could at least get to the system files to fix the problem, because they were on a FAT partition. Unfortunately, if you upgraded a copy of Windows NT that was configured in this way to Windows 2000, you’d have very little space left over, and your AD could quickly outgrow the partition.

The solution in such a case is to move your AD. Moving AD could also be used as a performance-boosting technique if you were to move the databases off of a slow partition and on to a faster partition.

To move AD, boot the system into Active Directory Restore Mode. When the system boots, verify the location of all AD files by opening a command prompt and entering the NTDSUTIL command. At the NTDSUTIL prompt, enter the FILES command. Then, type INFO at the prompt, and you’ll see a summary of the size and locations of the various AD files as in Figure E.

Figure E

The next step in the process is to select a location to move the database to. Remember that the partition that you select should have ample speed and space to effectively host AD. Also, Windows requires that the partition containing AD must be running the NTFS file system.

Next, enter the QUIT command twice to exit the NTDSUTIL program. Then, decide which partition should be hosting AD, and create a directory on that partition called NTDS. For example, on my test system, I’m creating a directory called D:\NTDS.

Enter the NTDSUTIL command followed by the FILES command. Then, enter the MOVE DB TO PATH command, where PATH represents the path to your directory. For example, in my case, I’d enter MOVE DB TO D:\NTDS. Windows 2000 will then run a script that could take a while to complete.

When the moving process finishes, you’ll need to move the database’s log files. Enter the MOVE LOGS TO PATH command where PATH represents the path to your directory. This command would look something like MOVE LOGS TO D:\NTDS.

The last step of the process is to let Windows 2000 know about the changes that you’ve made by updating the database path. To do so, enter the command SET PATH DB PATH. For example, this command might look something like SET PATH DB D:\NTDS\NTDS.DIT. Next, enter the QUIT command twice and reboot your machine.

Because it’s impossible to fit the move process into a screen capture, I’ve included the text output from an actual move below. Note, however, that after you complete a move, you need to immediately back up the system, because you may not be able to restore your old system backups, since the backup will be looking for your AD in the wrong location. With that said, click here to view the text of the sample move.

As time goes on, your AD will become fragmented. When this happens, you can greatly boost performance by defragmenting the database. Although there are no handy GUI tools to accomplish this, once you get used to using the NTDSUTIL utility, you’ll be able to defragment AD with little trouble.