by Brien Posey

By now, you probably know that the Active Directory is basically the heart and soul of Windows 2000 domains. However, like any other database, the Active Directory database sometimes gets corrupted. In this series, I’ll introduce you to the components that make up the AD database, discuss how these components work, and explain why corruption sometimes occurs. I’ll then show you some methods you can use to fix Active Directory corruption.

 

The Active Directory Components

The Active Directory exists in a Jet database format, similar to that used by Microsoft Exchange Server. Like many formats, the AD database doesn’t exist within a single file, but rather relies on multiple files. The main database file is called NTDS.DIT. Its default location is at C:WINNTNTDS. The other related files are database support files such as EDB?????.LOG, EDB.CHK, RES1.LOG, and RES2.LOG. All support files are governed by a file called LSASS.EXE, whose purpose is to control database transactions.

 

 

The AD database seems complicated, but this complexity is designed to protect the database from corruption. To understand why, it’s first necessary to understand how these files work together.

 

Log files

The EDB?????.LOG filename actually represents a series of log files. The first log file in the series is EDB.LOG, followed by EDB00001.LOG, EDB00002.LOG, etc. These log files serve as a record of every AD transaction. Any time an update is made to the Active Directory, LSASS.EXE writes the update to memory and then to a log file. Each log file is 10 MB; when one log file is filled up, the next log file in the series is created. As you can imagine, keeping a record of every AD transaction would eat up a lot of hard disk space over time. However, Windows does a few things to prevent the server from running out of hard disk space.

 

One way to keep log files from getting out of hand is to use circular logging: when too many log files start accumulating, those that are no longer needed are overwritten. For example, suppose your highest numbered log file was EDB00010.LOG. If the server started running low on disk space, Windows might attempt to overwrite EDB00001.LOG, assuming it was no longer needed. If you’ve dealt with Exchange Server, you probably know that Microsoft doesn’t recommend using circular logging because doing so can make it difficult to recover from a crash. However, the Microsoft Knowledge Base (Q247715) indicates that Windows 2000 is optimized to take advantage of circular logging. In fact, according to that article, there’s no way to disable circular logging.

 

This raises several questions. First, as I mentioned, old transaction logs are only overwritten when Windows is done with them. What happens if Windows hasn’t finished processing the old transaction logs, and runs out of disk space while building new log files? Fortunately, Microsoft has planned for such a situation and, to compensate, Windows uses two files called RES1.LOG and RES2.LOG whose purpose, as strange as it may sound, is to eat up disk space. RES1.LOG and RES2.LOG are nothing more than empty databases that will never be used. If you run out of hard disk space because your log files have gotten out of hand, you can free up 20 MB of space by erasing these two files.

 

This brings up another question. If you reach the point where you have to delete RES1.LOG and RES2.LOG, what’s to keep the transaction logs from eating up the 20 MB that you just freed up? Keep in mind that Windows will only begin the circular logging process when it’s done with an earlier log file. Therefore, the trick is to make sure that Windows is done using an earlier log file. There are a few different ways of doing this.

 

The log files serve as temporary storage for database transactions until they have been committed to the AD database. Once the transactions have been committed, the log file that contains the transactions is no longer needed. Windows is designed to automatically commit database transactions during times of limited activity. However, if you find that log files are accumulating and you risk running out of hard disk space, there are at least two ways of manually forcing Windows to process the log files. Perhaps the easiest way is to simply shut down the server. During the shutdown process, Windows reads through the log files and commits the AD changes to the database. However, if your server is too busy to automatically process the log files, you probably don’t want to shut it down. Another way to force Windows to process the log files is to backup the Active Directory through the Windows Backup program or other Windows 2000-aware backup software. As the backup program backs up the Active Directory, it commits the contents of the log files.

 

The checkpoint file

If circular logging requires Windows to overwrite log files that have already been committed, you might be wondering how Windows knows which log files have and haven’t been committed without processing every entry in every log file. This is where the EDB.CHK file comes in. This file is known as the checkpoint file. Its job is to tell Windows the location of the last transaction that was committed. Therefore, when Windows is ready to commit more transactions, it simply looks at the checkpoint file to tell which transaction is next in line to be committed. Likewise, if Windows needs to overwrite an old log file, it looks to the checkpoint file to tell which log files have already been committed.

 

You may be wondering why Windows uses such a complicated method of updating the Active Directory rather than simply applying changes directly to the database itself. There are two main reasons for the design of the AD database and its support files. The first has to do with backing up the database. If updates were applied directly to the database, it would be impossible to update the Active Directory during a backup. Because changes are applied to log files rather than directly to the database, an administrator can make Active Directory changes even during a backup.

 

The other reason is that this process allows for some degree of fault tolerance. Suppose a power failure occurs. Obviously, there would probably be database entries in the log files that had not yet been committed to the Active Directory. The next time Windows starts, it does what’s known as a soft recovery. It looks at the checkpoint file to determine which changes haven’t been committed, and processes the log files and brings the database up to date.

 

As you can see, Windows 2000 is designed to try to keep the Active Directory healthy by interacting with log files instead of updating the AD database directly. Even so, it’s still possible for various types of AD problems to occur. These range from minor issues such as the checkpoint file being invalid to major issues such as database corruption. Fortunately, Windows provides tools for recovering from all but the most severe AD problems.

 

Locating the AD Database and Support Files

Before I begin discussing cures for AD-related problems, I’d like to explain how to locate the AD database and the corresponding support files. All of these files are involved in most of the repair operations, and in many cases, the operations require that you know the specific location of the various database files.

 

The AD database is usually located at C:WINNTNTDS. However, depending on the location chosen during a server’s DCPROMO operation, the database could be located practically anywhere. The directory that contains the NTDS.DIT file (the AD database) usually also contains the support files, although it is possible for these files to be in a different location.

 

There are two primary ways to locate the AD files. One method involves using the Search | For Files or Folders option on the Start menu. While this will locate the desired files, it isn’t the preferred method. It’s better to reboot the server into Active Directory Restore Mode. To do so, press the F8 key while on the screen that asks you to select your operating system. When you do, you’ll see the Advanced Options menu. Now, select the Directory Services Restore Mode option and press Enter twice to boot Windows.

 

When Windows loads, open a command prompt window and enter the NTDSUTIL command. This brings up the NTDSUTIL prompt, at which you’ll enter the FILES command. When you do, the prompt will change to FILE MAINTENANCE. At the File Maintenance prompt, enter the INFO command. When you do, you’ll see a summary of the AD files and their sizes. Here’s a sample of this information:

 

file maintenance: info

Drive Information:

C: NTFS (Fixed Drive ) free(5.5 Gb) total(7.8 Gb)

F: NTFS (Fixed Drive ) free(13.2 Mb) total(15.6 Mb)

Q: NTFS (Network Drive) free(60.5 Gb) total(63.5 Gb)

DS Path Information:

Database : C:WINNTNTDSntds.dit – 26.1 Mb

Backup dir : C:WINNTNTDSdsadata.bak

Working dir: C:WINNTNTDS

Log dir : C:WINNTNTDS – 50.0 Mb total

res2.log – 10.0 Mb

res1.log – 10.0 Mb

edb00003.log – 10.0 Mb

edb00002.log – 10.0 Mb

edb.log – 10.0 Mb

file maintenance:

 

Now that you know the basics of how the AD files work together and how to locate these files, it’s time to begin the repair process, which I’ll discuss in Part 2.

 

 

Repairing Active Directory corruption, part 2

 

21 May 2001 | SearchNetworking courtesy of 8wire 

 

by Brien Posey

When most people think of corruption, they tend to think of individual files being unreadable or invalid. As with just about any other type of file, the Active Directory files are prone to this type of corruption, as well as some other problems I’ll talk about later.

 

Testing File Integrity

If you’ve ever worked with Exchange 5.5, you’re probably familiar with the ESEUTIL tool. In earlier versions of Exchange, this tool was known as EDBUTIL. If you’ve ever worked with this tool, you know that figuring out which switches to use with the command can be confusing.

 

Fortunately, Windows 2000 makes it a little easier to use the ESEUTIL program. Windows contains a program called Integrity (part of NTDSUTIL) that invokes the ESEUTIL program for you and automatically tests the integrity of every file associated with AD. As with running ESEUTIL in an Exchange environment, this program can take some time to run, especially if you’ve got a big Active Directory or a lot of log files. The run time will also vary depending on the speed of your server, but 2 GB per hour is about the average speed you can expect.

 

Before you can use the Integrity command, you must be in Active Directory Restore Mode. To place Windows into this mode, reboot the system and press the F8 key while on the screen that asks you to select your operating system. When you do, you’ll see the Advanced Options menu. Now, select the Directory Services Restore Mode option and press Enter twice to boot Windows.

 

When Windows boots, open a command prompt window and enter the NTDSUTIL command. This brings up the NTDSUTIL prompt. Now, enter the Files command. At this point, the NTDSUTIL prompt will change to the FILE MAINTENANCE prompt. Finally, enter the Integrity command and Windows will begin analyzing the databases. Here’s an abbreviated sample of the process:

 

C:Documents and SettingsAdministrator.POSEY>ntdsutil

ntdsutil: files

file maintenance: integrity

Opening database [Current].

Executing Command: C:WINNTsystem32esentutl.exe

    /g “C:WINNTNTDSntds.dit” /

10240 /8 /v /x /o

Initiating INTEGRITY mode…

        Database: C:WINNTNTDSntds.dit

  Temp. Database: INTEG.EDB

got 16043 buffers

checking database header

checking database integrity

            Scanning Status  ( % complete )

 0    10   20   30   40   50   60   70   80   90  100

 |—-|—-|—-|—-|—-|—-|—-|—-|—-|—-|

            checking SystemRoot

            SystemRoot (OE)

            SystemRoot (AE)

    checking system table

            MSysObjectsShadow

            MSysObjects

.           Name

            RootObjects

            rebuilding and comparing indexes

    checking table “datatable” (6)

            checking data

………………….. checking long value tree (48)

…….         checking index “INDEX_00020160″ (110)

                checking index “INDEX_00020107″ (109)

                checking index “INDEX_548E0065″ (108)

                checking index “NC_Acc_Type_Sid” (8)

                checking index “INDEX_00090092″ (7)

                rebuilding and comparing indexes

        checking table “sdproptable” (17)

                checking data

.               checking index “clientid_index” (19)

                checking index “trim_index” (18)

                rebuilding and comparing indexes

…..

integrity check completed.

Operation completed successfully in 30.994 seconds.

Spawned Process Exit code 0×0(0)

If integrity was successful, it is recommended

 you run semantic database analysis to insure

 semantic database consistency as well.

file maintenance:

 

Performing a Semantic Database Analysis

As you can see, following the Integrity operation, the utility suggested that I run a semantic database analysis to ensure integrity. While the Integrity operation tested file integrity, running a semantic database analysis checks the integrity of the AD database contents by comparing them to the log files.

 

The semantic database analysis process looks for several things. First, it runs a reference count check. The utility counts all references in the link and data tables and makes sure the actual counts match the listed counts. It also makes sure every AD object has a GUID, a distinguished name, and a non-zero reference count. If an object was supposed to have been deleted, the process verifies that the object has a date and time stamp for the deletion, and that it doesn’t have a distinguished name or a GUID.

 

 

The semantic database analysis also checks objects for valid security descriptors and makes sure the access control lists aren’t empty.

 

Running the semantic database analysis is important for getting your Active Directory back up to speed. As with the file integrity test, the semantic database integrity check can take a while to run. When the process completes, any errors that occur are written to a log file called DSDIT.DMP.xx.

 

To run the semantic database analysis, you must be in Directory Service Restore Mode. Once again, open a command prompt window and enter the NTDSSUTIL command. When you do, you’ll see the NTDSUTIL prompt. Now, enter SEMANTIC DATABASE ANALYSIS. When you do, you’ll see the prompt change to SEMANTIC CHECKER. Enter the command VERBOSE ON. This will allow you to see what’s going on. Finally, enter the GO command to start the process. Here’s an abbreviated sample output:

 

ntdsutil: semantic database analysis

semantic checker: verbose on

Verbose mode enabled.

semantic checker: go

Fixup mode is turned off

Opening database [Current]…..Done.

Getting record count…7397 records

Writing summary into log file dsdit.dmp.0

Records scanned:       7300

Processing records..Done.

 

It’s important to point out that this process is only designed to analyze the database semantics and report the errors. By itself, it won’t fix any errors. If errors occur, go back to the SEMANTIC CHECKER prompt and enter the GO FIXUP command. You shouldn’t use this option unless there are actually repairs to be made.

 

Soft Recovery

In Part 1, I mentioned that if Windows is powered off abruptly, it will detect at the next boot that the shutdown wasn’t clean and will automatically run a soft recovery process. This process examines all log files and commits any uncommitted transactions.

 

If you’re having database problems, you might try to manually perform a soft recovery. To do so, boot Windows into Directory Services Restore Mode. Then open a command prompt window and enter the NTDSUTIL command. At the NTDSUTIL prompt, enter the FILES command, and you’ll see the FILE MAINTENANCE prompt. Now, enter the RECOVER command to initiate the recovery process. You can see a sample output below:

 

ntdsutil: files

file maintenance: recover

Executing Command: C:WINNTsystem32esentutl.exe

    /r /8 /o /l”C:WINNTNTDS” /

C:WINNTNTDS” /!10240

Initiating RECOVERY mode…

       Log files: C:WINNTNTDS

    System files: C:WINNTNTDS

Performing soft recovery…

Operation completed successfully in 3.625 seconds.

Spawned Process Exit code 0×0(0)

If integrity was successful, it is recommended

 you run semantic database analysis to insure

 semantic database consistency as well.

file maintenance:

 

Database Defragmentation

Sometimes when an Active Directory isn’t working correctly, it’s best to start with a new database. As you may know, databases become fragmented and need to be defragmented, just like hard drives. Windows actually performs what’s known as an online defragmentation every 12 hours as a part of the trash collection process. When Windows does an online database defragmentation, it merely optimizes the database; it never reduces its size.

 

You can, however, do what’s known as an offline defragmentation, which creates a brand new database and copies all AD records to it. This removes fragmentation and empty space to create a clean, compact database.

 

To defragment an Active Directory, boot the system into Directory Service Restore Mode. Then open a command prompt window and enter the NTDSUTIL command. Now, find the location of the database files by entering the FILES and INFO commands I showed you in Part 1. Once you know the location of your databases, enter the command COMPACT TO drive:directory. You’ll have to compact the database to a different location than its current location. Here’s what this process looks like:

 

C:Documents and SettingsAdministrator.POSEY>ntdsutil

ntdsutil: files

file maintenance: info

Drive Information:

 C: NTFS (Fixed Drive  ) free(5.4 Gb) total(7.8 Gb)

 F: NTFS (Fixed Drive  ) free(13.2 Mb) total(15.6 Mb)

 Q: NTFS (Network Drive) free(60.4 Gb) total(63.5 Gb)

DS Path Information:

 Database   : C:WINNTNTDSntds.dit – 26.1 Mb

 Backup dir : C:WINNTNTDSdsadata.bak

 Working dir: C:WINNTNTDS

 Log dir    : C:WINNTNTDS – 50.0 Mb total

                 res2.log – 10.0 Mb

                 res1.log – 10.0 Mb

                 REPAIR.TXT – 0.0 Kb

                 edb00003.log – 10.0 Mb

                 edb00002.log – 10.0 Mb

                 edb.log – 10.0 Mb

file maintenance: compact to f:

Opening database [Current].

Using Temporary Path: C:

Executing Command: C:WINNTsystem32esentutl.exe

 /d “C:WINNTNTDSntds.dit” /8

 /o /l”C:WINNTNTDS” /s”C:WINNTNTDS”

 /t”f:ntds.dit” /!10240 /p

Initiating DEFRAGMENTATION mode…

  Database: C:WINNTNTDSntds.dit

  Log files: C:WINNTNTDS

  System files: C:WINNTNTDS

  Temp. Database: f:ntds.dit

      Defragmentation Status  ( % complete )

0    10   20   30   40   50   60   70   80   90  100

|—-|—-|—-|—-|—-|—-|—-|—-|—-|—-|

……………………………………………

Spawned Process Exit code 0xfffff8f0

If compaction was successful you need to:

   copy “f:ntds.dit” to “C:WINNTNTDSntds.dit”

  and delete the old log files:

   del C:WINNTNTDS*.log

file maintenance:

 

When the process completes, rename your original AD database file and move the newly created database file to the directory where the original file existed. Once you’ve booted Windows and confirmed that everything worked successfully, you can erase the renamed original database file.

 

The Last Resort

If you still haven’t been able to repair your Active Directory, and restoring a backup isn’t an option, there’s one last thing you can try: a binary level repair. This process works by deleting anything that it doesn’t understand. When you run this process, you’ll almost always lose some data, so don’t run it unless you have no options left.

 

To repair the database, boot Windows into Directory Services Restore Mode. When Windows boots, open a command prompt window and enter the NTDSUTIL command. At the NTDSUTIL prompt, enter the FILES command, and you’ll see the FILE MAINTENANCE prompt. Now, enter the REPAIR command and start praying….

 

Brien M. Posey is an MCSE who works as a freelance technology writer. His past experience includes working as the director of information systems for a national chain of health care facilities and as a network engineer for the U.S. Department of Defense.