On a periodic basis, such as a couple of times a year, you should check the health of the DIT file (ntds.dit) on your domain controllers. Using the ntdsutil utility, you can check the integrity and semantics of the Active Directory database and reclaim whitespace, which can dramatically reduce the size of the DIT. Also, just as you should rotate the password for the Administrator accounts in the forest, you should also change the DS Restore Mode Administrator password as well. You may even need to do this more frequently depending on whether you have people leave your team that should no longer know the password.
Unfortunately, to accomplish all these tasksexcept changing the DS Restore Mode Administrator passwordyou have to boot the domain controller into DS Restore Mode. That means you will have to have schedule downtime for the machine. Also, to use DS Restore Mode, you need console access either through being physically at the machine or with out-of-band access, such as with Compaq's Remote Insight Lights Out Board (RILOE). There is one other option using Terminal Services. You can modify the boot.ini file on the domain controller to automatically start up in DS Restore Mode. You can then use a Terminal Services connection to log in to the machine. For more information, check out MS Knowledge Base article 256588 from http://support.microsoft.com.
There are several checks you can perform against the DIT file to determine whether it is healthy. The first we'll show checks the integrity of the DIT file. The integrity check inspects the database at a low level to determine whether there is any binary corruption. It scans the entire file, so depending on the size of your DIT file, it can take a while to complete. We've seen some estimates that state it can check around 2 gigabytes per hour, so allocate your change notification accordingly.
To start the integrity check, run the ntdsutil command from within DS Restore Mode. The integrity subcommand can be found within the files menu.
C:\> ntdsutil ntdsutil: files file maintenance: integrity Opening database [Current]. Executing Command: C:\WINDOWS\system32\esentutl.exe /g"C:\WINDOWS\NTDS\ntds.dit" /o Initiating INTEGRITY mode... Database: C:\WINDOWS\NTDS\ntds.dit Temp. Database: TEMPINTEG1752.EDB Checking database integrity. Scanning Status (% complete) 0 10 20 30 40 50 60 70 80 90 100 |----|----|----|----|----|----|----|----|----|----| ................................................... Integrity check successful. Operation completed successfully in 11.766 seconds. Spawned Process Exit code 0x0(0) If integrity was successful, it is recommended you run semantic database analysis to ensure semantic database consistency as well. file maintenance: quit
The integrity check looks at the database headers to make sure they are correct and also checks all database tables to make sure they are working correctly. If the database integrity check fails or encounters errors, you may then want to run a repair command to try to fix the problem. Running an integrity check won't damage your Active Directory, but running a repair can, and that's why it is imperative you have a good backup before proceeding.
If the integrity check succeeds, you should then run a semantics check. Whereas the integrity check examines the database as a whole, the semantics check will examine the database to determine whether it is healthy as it pertains to Active Directory semantics. Some of the things the semantics check looks at include security descriptors, reference counts, distinguished name tag (DNT) consistency, and deleted objects.
To start a semantics check, run the go subcommand from the semantic database analysis menu.
ntdsutil: semantic database analysis semantic checker: ? ? - Show this help information Get %d - Get record info with given DNT Go - Start Semantic Checker With No Fixup Go Fixup - Start Semantic Checker with Fixup Help - Show this help information Quit - Return to the prior menu Verbose %s - Turn verbose mode on/off semantic checker: go Fixup mode is turned off Opening database [Current].......Done. Getting record count...3019 records Getting security descriptor count...85 security descriptors Writing summary into log file dsdit.dmp.0 SDs scanned: 85 Records scanned: 3019 Processing records..Done. semantic checker: quit
If any errors are reported, you can then run go fixup, which will attempt to repair any problems.
If you have to run the repair or go fixup commands, after you boot back into normal mode, you should perform a backup as soon as possible and be sure to indicate on the backup that a repair was performed. If for some reason you need to restore the domain controller at a later point, and if you restore from a backup prior to the repair, you'll need to perform the same commands to fix the database again. Alternatively, if you start experiencing problems immediately after the repair, you want to know where the last backup was before the repair occurred and restore that copy.
If your domain controllers are running low on disk space, or if you have deleted a lot of objects since you promoted your domain controllers, you may want to perform an offline defragmentation of the DIT file. You've probably seen the online defragmentation events that get logged to the Directory Service Event Log. This includes event 700, which states that an online defrag is about to begin, and event 701, which states that the online defrag completed. The online defrag process by default runs twice a day and reclaims space within the DIT file so it can be used for new objects. The online defrag process does not reclaim any disk space used by the DIT file. To do that, you must perform an offline defragmentation.
An offline defragmentation must be done while the domain controller is in Directory Service Restore Mode. You can then use the ntdsutil command to compact, that is defrag, the ntds.dit file. This process actually creates a copy of the ntds.dit file in an alternate location. You can then decide to overwrite the existing DIT file with the new compacted version.
The following shows how to perform an offline defragmentation using ntdsutil. After you enter the files menu, you'll need to issue the compact to directorypath command. The directorypath should be the directory the new compacted ntds.dit file would be created in. If the directory does not exist, it will be created automatically.
ntdsutil: files file maintenance: compact to c:\windows\ntds\compact Opening database [Current]. Creating dir: c:\windows\ntds\compact Executing Command: C:\WINDOWS\system32\esentutl.exe /d"C:\WINDOWS\NTDS\ntds.dit" /t"c:\windows\ntds\compact\ntds.dit" /p /o Initiating DEFRAGMENTATION mode... Database: C:\WINDOWS\NTDS\ntds.dit Temp. Database: c:\windows\ntds\compact\ntds.dit Defragmentation Status (% complete) 0 10 20 30 40 50 60 70 80 90 100 |----|----|----|----|----|----|----|----|----|----| ................................................... Note: It is recommended that you immediately perform a full backup of this database. If you restore a backup made before the defragmentation, the database will be rolled back to the state it was in at the time of that backup. Operation completed successfully in 20.961 seconds. Spawned Process Exit code 0x0(0) If compaction was successful you need to: copy "c:\windows\ntds\compact\ntds.dit" "C:\WINDOWS\NTDS\ntds.dit" and delete the old log files: del C:\WINDOWS\NTDS\*.log file maintenance: quit
After you've completed the compaction, you can then decide whether you want to overwrite your current ntds.dit file.
Performing an offline defrag of a machine affects only that machine. To reclaim space on your other domain controllers, you'll need to follow the same procedures for all other servers.
After you do an offline defrag, you should also make sure a backup is taken soon after. If for some reason you have to do a restore, and you have not done a backup since you did the offline defrag, the ntds.dit file on the domain controller will go right back to the size it was prior to the defrag.
It is a good practice to periodically change the password for your domain Administrator accounts. This should be done so that the password does not find its way to more people than it should, and so that you don't have former administrators trying to perform tasks they shouldn't if they are no longer in the AD group.
The domain Administrator account should not be the only one you are concerned about. The DS Restore Mode Administrator account is just as important and can be used to do very damaging things, such as directly modifying the contents of the Active Directory database. For this reason, you should also periodically rotate the DS Restore Mode Administrator password.
Unfortunately, with Windows 2000 the only way to change the DS Restore Mode Administrator password was by booting into DS Restore Mode. This was very problematic because there was no easy way to automate the process. With Windows Server 2003, a command was added to the ntdsutil utility to allow changing the password even when a domain controller is live. The set reset password on server %s subcommand can be used from the set dsrm password menu, where %s is the name of the server to target. Leave %s blank if you want to change the password on the local machine. In the following example, we set the password for the DC1 domain controller.
ntdsutil: set dsrm password Reset DSRM Administrator Password: reset password on server dc1 Please type password for DS Restore Mode Administrator Account: ********** Please confirm new password: ********** Password has been set successfully. Reset DSRM Administrator Password: quit