Directory Service Maintenance

摘录自：http://drummermark.com/mcsenotes/

Directory Service Maintenance

Active Directory is a transactional database. This means that it has built-in recovery techniques that are performed automatically should a system fail because of a hardware problem. However, there are routine maintenance AD activities--on each DC--that should be performed regularly:

• Backing up AD data - a backup can be performed with the DC online. It is wise to back up the database, log files, and system state data. Also, back up your users' data, just in case of a flood or an earthquake-they'll appreciate it! Remember, system state data is:
  • AD database files - (see below)
  • SYSVOL folder - used to replicate GPO data and logon scripts; exist on all DCs.
  • Registry - you know, the registry.
  • System startup files
  • Class Registration database - installed component services.
  • Certificate Services database (if installed)
• Restoring AD data
  • Rely on AD replication to take care of updating a new DC; simply install new DC.
  • Restore Wizard from the Backup utility; if backups were accomplished.
    • Nonauthoritative restore - a restore of data from backup. Because the data will probably be out of date, normal AD replication processes make sure that data elements are updated. The server must be offline.
    • Authoritative restore - used to restore individual pieces of AD; increments the property version number (PVN) to 100,000; forces replication to all other DCs via normal AD replication processes. At the command prompt, enter:

      ntdsutil
      
      authoritative restore
      
      restore subtree {distinguished name} i.e. OU=finance,DC=HCSNET,DC=COM
      
      quit
      
      quit
      
      

    Restore operations are highly dependent upon the tombstone period (see below). You cannot restore system state data from tapes that have backups older than the tombstone date. This is because data is deleted once the tombstone lifetime has expired. Introducing a DC with older data that has been erased from other DCs will cause database inconsistencies.

• Moving the AD database - it's wise to move the database file to a separate physical hard disk from the log files to prevent disk contention. Log files are being written to constantly. When a query is made against the AD database, the disk's heads have to move to read from ntds.dit, which reduces overall performance of the disk subsystem. The database can be moved with ntdsutil. Perform the following steps:
  • Restart the server, press F8 during startup, and select Directory Services Restore Mode. (Starts server, but not AD).
  • Log in using the Administrators account. (Stored locally and can be different for each DC in the enterprise).
  • Open a command prompt enter the following:

    ntdsutil
    
    files
    
    move db to {drive\folder}
    
    quit
    
    quit
    
    

    These commands move the database file and update the Registry to point to the new location.
• Defragmenting AD data
  • online - slower than offline; automatically runs every 12 hours; full defragmentation can take place with this method, but the size of the AD database file will never be reduced. The records are moved to contiguous sectors, but the empty space remains.
  • offline - never occurs on the live database file; occurs on a copy. When defragmentation is complete, you must archive the current version of ntds.dit that is being used and move the defragmented version in its place. Don't delete the old ntds.dit until the DC has been rebooted and proven to work with the new defragmented file. Offline defragmentation is the only way to return space from the database to the file system. The procedure is as follows:
    • Restart the server, press F8 during startup, and select Directory Services Restore Mode. (Starts server, but not AD).
    • Log in using the Administrators account. (Stored locally and can be different for each DC in the enterprise).
    • Open a command prompt enter the following:

      ntdsutil
      
      files
      
      compact to {drive\folder}
      
      quit
      
      quit
      
      

    • Once the process is complete, a new ntds.dit will exist. Copy the new ntds.dit file over the old version of ntds.dit and restart the DC.

AD files

AD uses the Extensible Storage Engine (ESE), which was first used in Exchange Server. It uses the concept of transactions to ensure that the database does not become corrupted by partial updates. This allows it to recover in the case of a power failure. Each transaction is a call to modify the database. For the transactional system to work, the AD database must have log files. They are used to store modifications before the data is written to the physical database file. Remember, these files exist on every DC and each instance must be maintained separately:

• ntds.dit - the single file that holds all the AD data. This includes all objects and schema information. It is stored by default in \NTDS. The .dit extension stands for "directory information tree."
• edb*.log - the transactional log for ntds.dit. The current file being used is called edb.log. When that file reaches a specified size (10MB), the file gets renamed to edbxxxxx.log. When the files are no longer needed, they are deleted by the system.
• edb.chk - the checkpoint file that keeps track of which entries in the log file have been written to the database file. In case of failure, Windows 2000 uses this file to find out which entries in the log file can safely be written out to a database file.
• res1.log, res2.log - two placeholders that exist to "take up space." If a DC runs out of disk space, these two files (10MB each) prevent a DC from being able to write to the log files, such that, AD can be sure that it has at least 20MB of space to write out any necessary log data.

Garbage Collection

Garbage collection is the process in which old data is purged from AD. Data is not immediately deleted from AD. Instead, the object's attributes are deleted and the object is moved to the Deleted Objects container. The object is then assigned a tombstone. By default, the tombstone is 60 days. This gives AD replication time to replicate the change to all DCs. Garbage collection is also the process of defragmenting the database.

To change the garbage collection interval, use ADSIEdit. Connect to the Configuration container and edit the garbageCollPeriod and the tombstoneLifetime attributes, which will show as <not set> in the tool.