Join and Authentication Issues
Join and Authentication Issues |
|
If the domain controller cannot shut down in an orderly fashion (which usually means a power failure), the database is left out-of-date, because the most recent pages in memory were not written to the disk. Transaction logs are used to recover the database. Any change made to the database is also appended to the current log file, and its disk image is always kept up-to-date. The database change process is as follows:
If Active Directory halts, preventing the database from being successfully flushed to disk, the database performs a recovery on the next startup. Essentially, the database reads through the log files in order and reapplies changes until the database is made consistent and up-to-date.
The default log file name is Edb.log. The ESE can create a new log file when the current one fills up (noncircular logging). Or, it can overwrite the oldest file when the log reaches a specified number of files (circular logging). Noncircular logging consumes disk space until the administrator manually deletes old log files, following a backup or restart. It saves all database changes and never automatically deletes log files.
Note
The default setting for Windows 2000 is circular logging turned on.
That directory routinely contains the following files:
Each of the files that has a .log extension is going to be created at exactly the same size of 10 megabytes (MB). Edb.log is the "current" log file. If circular logging is turned off, when the Edb.log file is full of transactions, it is renamed to Edb00001.log. This naming convention continues to increment by using hexadecimal notation. Thus, if there is a question as to the condition of the log files, that can be determined by checking to see whether an unbroken series of log file names exist.
Res1.log and Res2.log are "placeholders" — designed to reserve (in this case) the last 20 MB of disk space on this drive or directory. This is designed to give the log files sufficient room for a graceful shutdown if all other disk space are consumed. Note that if circular logging is set to on, running out of space for log files is not an issue.
The checkpoint file, Edb.chk, is created by the Jet Database. Edb.chk stores the database checkpoint, so that it can replay logs starting with the generation containing the checkpoint, if needed. The Edb.chk file is a pointer in the log sequence that maintains the status between memory and the database file on disk. In the event of a failure, it indicates the point in the log file from which the information store needs to start the recovery. The Edb.chk file is essential for efficient recovery because if it didn't exist, the information store must attempt recovery by starting from the beginning of the oldest log file it found on disk and has to check every page in every log file to determine whether it had already been written to the database. This process, of course, is very time consuming, especially if the only goal is to make the database consistent.
Every time the database is opened, a check is performed to see if the database is up to date with the related checkpoint. For example, did the database fail before updating the checkpoint? If the database is not up to date, the log files are replayed from the point that the checkpoint file indicates. Jet logging and recovery can still recover a database without a checkpoint, but the checkpoint allows faster recovery by directing recovery to begin closer to logged operations that must be redone.
Edb.chk is updated automatically by Jet when Jet notices that it has a specific amount of changes in the log files that are not forwarded to the checkpoint. Also, it is updated at the end of a recovery process. Finally, it is updated when you successfully shut down the system, to close the database.
Note
The Directory Services Restore Mode–only restriction applies only to the functions that work directly on the database.
For more information about Active Directory Database operations, see "Active Directory Data Storage" in this book.
To ensure the integrity of the database files, you might need to perform preventive procedures such as integrity check, move, repair, recovery, and defragmentation.
By using the integrity command, you can detect low level (binary level) database corruption. The integrity command invokes the esentutl command-line tool, which reads every byte of the data file. Therefore, depending upon the size of your data file, the process might take a considerable amount of time.
The integrity command also makes sure that the correct headers exist in the database itself and that all of the tables are functioning and are consistent. In short, it checks the integrity of the directory service data files. This is used while in Directory Services Restore mode. If errors are encountered, they are recorded on the log files.
The length of time for the integrity command to complete its operation depends on the type of hardware you are using and the size of your directory database. (In testing environments, the speed of two gigabytes (GB) per hour was considered to be normal.) However, when you carry out the command, an online graph displays showing the percentage completed.
Important
To run the Ntdsutil tool and the subsequent integrity command, you must be in Directory Services Restore mode.
Following is a sample run of an integrity check by using the Ntdsutil tool:
:\>ntdsutil
ntdsutil: files
file maintenance: Integrity
Opening database .
Executing Command: C:\WINNT\System32\esentutl.exe /g "C:\WINNT\NTDS\ntds.dit" /!
10240 /8 /v /x /o
Initiating INTEGRITY mode...
Database: C:\WINNT\NTDS\ntds.dit
Temp. Database: INTEG.EDB
failed to get 515126 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 (24)
... checking index "PhantomIndex" (125)
. checking index "INDEX_000901FD" (122)
checking index "INDEX_000900DE" (121)
checking index "INDEX_00090089" (120)
checking index "INDEX_00090573" (119)
checking index "INDEX_00090073" (118)
checking index "INDEX_00090571" (117)
checking index "INDEX_0009056C" (116)
checking index "INDEX_00090553" (115)
checking index "INDEX_0009013A" (114)
checking index "INDEX_00090138" (113)
checking index "INDEX_00090330" (112)
checking index "INDEX_00090030" (111)
checking index "INDEX_00090013" (110)
checking index "INDEX_00000013" (109)
checking index "INDEX_0000000B" (108)
checking index "INDEX_00000007" (107)
checking index "INDEX_00000003" (106)
. checking index "INDEX_00150003" (105)
checking index "LCL_ABVIEW_index00000409" (104)
checking index "INDEX_00090363" (103)
checking index "INDEX_00090303" (102)
checking index "INDEX_00090290" (101)
checking index "INDEX_000901FF" (100)
checking index "INDEX_000900DD" (99)
checking index "INDEX_00090085" (98)
checking index "INDEX_00090057" (97)
checking index "INDEX_0009001C" (96)
checking index "INDEX_000201CC" (95)
. checking index "INDEX_000200D2" (94)
checking index "INDEX_0002000D" (93)
checking index "INDEX_0000002A" (92)
checking index "INDEX_00000004" (91)
checking index "NC_Acc_Type_Name" (90)
checking index "PDNT_index" (89)
.. checking index "INDEX_00090001" (88)
. checking index "INDEX_000901F6" (85)
checking index "INDEX_000902EE" (84)
checking index "INDEX_000904E1" (83)
checking index "INDEX_000201D5" (80)
checking index "INDEX_000902BB" (77)
checking index "INDEX_000903B4" (76)
checking index "INDEX_000200A9" (75)
checking index "INDEX_0009039D" (74)
checking index "INDEX_0009039A" (73)
checking index "INDEX_00090098" (72)
checking index "INDEX_00090395" (71)
checking index "INDEX_0009028F" (69)
checking index "INDEX_00090582" (66)
checking index "INDEX_00020078" (65)
. checking index "INDEX_00020073" (62)
checking index "INDEX_00090171" (60)
checking index "INDEX_00090167" (58)
checking index "INDEX_00090062" (56)
checking index "INDEX_00090261" (55)
checking index "INDEX_0009014E" (52)
checking index "INDEX_0009014D" (51)
checking index "INDEX_0009014C" (50)
checking index "INDEX_00090147" (49)
checking index "INDEX_00090141" (48)
checking index "INDEX_00090140" (47)
checking index "INDEX_0009012E" (42)
checking index "INDEX_00020013" (39)
. checking index "INDEX_0009030E" (36)
checking index "INDEX_00090008" (32)
checking index "INDEX_00090202" (25)
checking index "Ancestors_index" (13)
. checking index "DRA_USN_CREATED_index" (12)
checking index "DRA_USN_index" (11)
. checking index "del_index" (10)
checking index "INDEX_00090002" (9)
.. checking index "NC_Acc_Type_Sid" (8)
checking index "INDEX_00090092" (7)
rebuilding and comparing indexes
checking table "hiddentable" (16)
checking data
rebuilding and comparing indexes
checking table "link_table" (14)
checking data
checking index "backlink_index" (15)
rebuilding and comparing indexes
checking table "MSysDefrag1" (123)
checking data
checking index "TablesToDefrag" (124)
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 13.640 seconds.
Spawned Process Exit code 0x0(0)
If integrity was successful, it is recommended
you run semantic database analysis to insure
semantic database consistency as well.
To find out the location of the data files, log files, and working directory, you can use the info command, which is part of the ntdsutil command-line tool. This command does the following:
file maintenance: Info
Drive Information:
C:\ NTFS (Fixed Drive ) free(2.9 Gb) total(3.9 Gb)
DS Path Information:
Database : C:\WINNT\NTDS\ntds.dit - 12.1 Mb
Backup dir : C:\WINNT\NTDS\dsadata.bak
Working dir: C:\WINNT\NTDS
Log dir : C:\WINNT\NTDS - 40.0 Mb total
res2.log - 10.0 Mb
res1.log - 10.0 Mb
REPAIR.TXT - 0.0 Kb
edb00001.log - 10.0 Mb
edb.log - 10.0 Mb
When you move the database from one location to another location on the disk, you can use the Ntdsutil command-line tool in Directory Services Restore mode. For example, you might need to move a log file or the Ntds.dit file to another drive if corruption occurs on the previously assigned drive or directory. Specifically, the move db to %s command moves the Ntds.dit data file to the new directory specified by the "%s" and updates the registry keys so that the directory service restarts by using the new location.
To move the Active Directory database
move DB to <drive>:\<directory>
where <drive> and <directory> is the path to the location that you established in the previous step.
Note
You must specify a directory path. If the path contains any spaces, the entire path must be surrounded by quotation marks (for example, move DB to "c:\new folder").
The database named Ntds.dit is moved to the location that you specified.
Note
It is highly recommended that you make a backup immediately or else the restore operation does not retain the new file location.
You can also move the log files from location to another. Specifically, the Move logs to %s command moves the directory service log files to the new directory specified by %s and updates the registry keys so that the directory service restarts by using the new location.
Active Directory automatically performs online defragmentation of the database at certain intervals (by default, every 12 hours) as part of the Garbage Collection process. Online defragmentation does not reduce the size of the database file (Ntds.dit), but instead optimizes data storage in the database and reclaims space in the directory for new objects. It prevents data storage problems. Performing offline defragmentation creates a new, compacted version of the database file. Depending on how fragmented the original database file was, the new file might be considerably smaller.
To perform offline defragmentation of the Active Directory database
compact to <drive>:\<directory>
where <drive> and <directory> is the path to the location that you established in the previous step.
Note
You must specify a directory path. If the path contains any spaces, the entire path must be surrounded by quotation marks (for example, compact to "c:\new folder").
A new database named Ntds.dit is created in the path that you specified.
In the event that the power source failed unexpectedly, you can perform a "soft" recovery of the log files. Because transaction data is written to the log files before it is written to the data files, you can re-run the log files to reproduce the effects the transactions would have had if they were made to the data file. The Recover command in the Ntdsutil command line tool invokes the Esentutl command-line tool to perform this "soft" recovery. All of the log files are scanned to ensure that all committed transactions are made to the data file.
Note
Soft recovery is performed automatically when the DSA starts if the previous shutdown was not clean.
Following is sample output of running the Recover command:
File maintenance: Recover
Executing Command: C:\WINNT\System32\esentutl.exe /r /8 /o /l"C:\WINNT\NTDS" /s"
C:\WINNT\NTDS" /!10240
Initiating RECOVERY mode...
Log files: C:\WINNT\NTDS
System files: C:\WINNT\NTDS
Performing soft recovery...
Operation completed successfully in 4.717 seconds.
Spawned Process Exit code 0x0(0)
If recovery was successful, it is recommended
you run semantic database analysis to insure
semantic database consistency as well.
The database might need to be repaired due to a power outage. To repair the database, use the Ntdsutil command-line utility. Specifically, the repair command invokes the Esentutl tool, which performs a low level (binary level) of repair to the data file. This means that it repairs the database information of which the ESENT is aware.
Caution
Caution must be exercised when using the Repair command because you can experience the random loss of data. The exact type of data that can be lost is not known. This loss can occur when there is data necessary for the safe operation of Active Directory that is not identified in the ESE.
Because Active Directory is implemented on a transacted database system, the ESE historically called Jet, log files are used to support rollback semantics to ensure that transactions are committed to the database.
The Ntdsutil tool includes a semantics checker that can be invoked by selecting the Semantic database analysis option. The role of the semantic checker is to check the integrity of the contents of the Active Directory database.
The tool is run during Directory Service Restore mode. Errors are written into dsdit.dmp .xx log files. A progress indicator indicates the status of the check.
The following are examples of the functions that can be performed:
To perform Semantic database analysis
Note
To repair the errors encountered, select the Go Fixup option.
Following is a sample of running the Semantic database analysis option with verbose mode turned on:
ntdsutil: Semantic database analysis
semantic checker: Verbose on
Verbose mode enabled.
semantic checker: Go
Opening database .
....Done.
Getting record count...2371 records
Writing summary into log file dsdit.dmp.0
Records scanned: 2300
Processing records..Done.