70-240 in 15 minutes a week: Operations Masters, AD Database Maintenance, and RIS

By ServerWatch Staff (Send Email)
Posted Jul 26, 2001


by Dan DiNicolo
http://www.2000trainers.com

Welcome to article number 19 in my 70-240 in 15 minutes a week series. This week's article covers Active Directory database maintenance, Operations Masters management, and Remote Installation Services. This includes a look at the different files relating to the Active Directory database, the tools used to change or seize control of Operations Masters, and a deeper look at RIS than what has been taken in previous articles. This is the last article in the Active Directory portion of the series. The next article will begin the final leg of the series, which will explore Windows 2000 Networking Infrastructure. You can expect the last portion of the series to run approximately 8 articles or so.

The material to be covered in this article includes:

- Active Directory Database Maintenance
- Operations Masters Management
- Remote Installation Services


Active Directory Database Management

The Active Directory database is where all information relating to the directory is stored, including domain objects and attributes, schema, configuration, and global catalog information if applicable. As such, you must have an awareness of how the database works, as well as how it can be maintained. This includes knowing how to do a backup/restore, defragmentation, as well as how to move the database.

The Active Directory database is referred to as a transactional database, which means that every change to the database is treated as an individual transaction. The transactional nature of the database helps maintain integrity in the event of a failure. The Active Directory database is actually made up of a number of files that you need to be aware of:

Article 19 in Dan DiNicolo's 70-240 in 15 minutes a week series covers Active Directory database maintenance, Operations Masters management, and Remote Installation Services. This includes a look at the different files relating to the Active Directory database, the tools used to change or seize control of Operations Masters, and a deeper look at RIS than what has been taken in previous articles.

Ntds.dit - this is the actual AD database file, where all objects are stored. By default you will find this file (and the others mentioned here) in the %systemroot%\NTDS folder.

Edb*.log - these files are transaction logs. Before any update is written to the database, it is first written to the transaction log. Each edb.log file is 10 MB in size. By default Windows 2000 uses circular logging, meaning that once full, the log file begins overwriting the oldest changes. If circular logging is turned off once the log files are full they are renamed ebdxxxxx.log, with xxxxx representing the number of the file starting at 00001. 

Edb.chk - this is a checkpoint file, used by AD to track which changes have been written to ntds.dit. This is used for recovery purposes. For example, if a domain controller crashed and information had not yet been written to the database, the checkpoint file would server as the marker/pointer as to what from the log file still needs to be written to the database.

Res1.log and Res2.log - These are reserved log files, 10 MB each. Their purpose is to allow Active Directory to continue to log changes, in the event that all disk space in filled. As such, these 20 MB of files are actually just empty files reserving space, and are not used unless needed.

Remember from our earlier look at installing Active Directory that Microsoft recommends placing the log files and database on separate disks for best performance.

You should also be aware of a process that runs on domain controllers every 12 hours by default. The process is referred to as Garbage Collection, and its job is to delete objects that are tombstoned, as well as to defragment the AD database. A tombstoned item is one that has been recently deleted. Note that objects are not immediately removed from AD once deleted. Instead, they are tombstoned, or marked. Objects are actually removed from the database after the tombstone lifetime has passed, which is 60 days by default. As such, you should note that even after deleting an item, the AD database wouldn't immediately get any smaller - try looking again in 60 days, once the object has actually been removed. The purpose of tombstoning is to allow the change to be replicated to all domain controllers. The tombstone lifetime interval can be changed by using the ADSI Edit tool, but you probably shouldn't. If you want to restore an item to the database, you can only do it from a backup made from within the tombstone lifetime - AD doesn't keep any record of objects that have removed after tombstoning.

The defragmentation of the AD database done by the Garbage Collection process simply rearranges how data is written to the database, while also compacting it. It does not actually rearrange how the database is written to the hard disk, as is the case with a traditional defragmentation. This can be done as something called an 'offline defragmentation', which we'll look at shortly.

Backing up the Active Directory database is obviously an important part of maintaining it. The actual backup is performed using the Backup tool by choosing to backup something referred to as System State Data. On a domain controller, System State Data includes the AD database, the SYSVOL folder, the registry, system startup files, class registration database, and the certificate services database if the system is running certificate services. The backup is as simple as checking off one box in the Backup program.

In order to backup System State, note that you must have the right to Backup files and folders. By default Administrators, Backup Operators, and Server Operators have these rights. You should also note that System State data can only be backed up for the local server using the Backup program (remote System State data backups are not supported using Backup).

Restoring Active Directory is actually a little trickier than you might think. First of all, to do any type of restore, you will need to boot the server in Directory Service Restore Mode, found in the advanced startup options. The two modes of restore that exist are what are referred to as an Authoritative and Non-Authoritative restore.

A Non-Authoritative Restore simply restores Active Directory to the state it was in when this backup was done, and allows replication to overwrite any changes that have occurred in the meantime. For example, lets say that you backed up AD on a domain controller yesterday, and the domain controller crashed later that day. In the meantime, you deleted a number of users via a different domain controller. When you would do the Non-Authoritative restore, the entire database would be restore (including the users who were deleted). However, once replication would occur, the users would be deleted in the newly restored database, as they had been while it was offline. The backup program only does Non-Authoritative restores.

This begs the question - what if I accidentally delete a user account and want to restore it? For this purpose, the Authoritative restore exists. Remember that in a Non-Authoritative restore, other domain controllers who would assume I had incorrect (old) information would overwrite the restored user. In an Authoritative restore, what I am doing is restoring an object (such as a user or OU) and marking this copy as the information that other domain controllers should pay attention to. It is accomplished by giving this restored object a version number that is increased by 100,000 for every day between the backup and restore occurring. As such, the authoritatively restored version certainly has the highest version number, and will 'overrule' the deletion noted by the other DCs. 

An Authoritative restore is accomplished by booting into Directory Services Restore Mode and then restoring System State using the backup tool. Without rebooting, the ntdsutil.exe tool must be run. From ntdsutil, the commands below should be issued:

1. At the prompt, type authoritative restore <enter>
2. Then type restore subtree distinguished_name_of_object <enter>.
     For example: cn=Dan DiNicolo,ou=admins,DC=2000Trainers,DC=com
3. Type quit <enter> and again quit <enter>
4. restart the domain controller as normally.


Outside of backup up and restoring the Active Directory database, you should know how to move and defragment the database as well. For both, you must be in Directory Services Restore Mode, and ntdsutil.exe is used for each.

To move the Active Directory database to a new location, run ntdsutil, type files <enter>, and then issue the move DB to <drive>:\<directory> command. Restart the domain controller as normal.

To defragment the AD database (often referred to as an offline defragmentation - it rearranges data on the physical disk) run ntdsutil and type files <enter>, and then issue the compact to <drive>:\<directory> command. This will create a defragmented version of the file in the new location. Quit ntdsutil and then copy the new version over the old version and restart the domain controller as normal.

Page 1 of 3


Comment and Contribute

Your name/nickname

Your email

(Maximum characters: 1200). You have characters left.