For the most part, the Active Directory database just works. It performs automatic online defrag, rarely becomes corrupt and never requires manual database recovery procedures like Exchange Server does. Still, it's important for administrators to understand the basics of an Active Directory database – how it works and certain important maintenance procedures.
Figure 1 shows where the database (NTDS.DIT file) sits in the Active Directory architecture. You can see how protocols like LDAP interface with the Directory Service Agent (DSA). The DSA is responsible for functions such as schema enforcement of updates, access control enforcement, object identification, referrals and functional level definition. It is associated with a GUID -- specifically the objectGUID attribute of NTDSsettings object -- that is used in replication to identify replication partners. This is exposed in the Repadmin/showrepl command and is the GUID that is mapped to the server's FQDN in the DNS Alias record.
Figure 1 (click to enlarge)
[IMAGE]
There is also a database GUID that is the invocationID attribute of the NTDSsettings object. The database layer is responsible for the creation, deletion and modification of objects, as well as the retrieval of objects, attributes and the schema cache. The schema defines rules for the organization of the database in terms of classes and attributes.
The NTDS.dit -- located in the %systemroot%\ntds directory -- exists on every Windows server installation. It is a basic transactional Jet database just like Exchange Server, and it is recommended to store the database and logs on separate physical disks. The location for these files is determined during Dcpromo, but you can change the location using the NTDSUtil program described later in this article. Figure 2 shows a typical NTDS directory.
Figure 2 (click to enlarge)
[IMAGE]
NTDS.DIT is the database.
To continue reading for free, register below or login
To read more you must become a member of SearchWindowsServer.com
During Dcpromo, it is enhanced with data from other domain controllers if it's joined to an existing domain or starts a new domain. As objects and attributes are added, deleted or modified, the database gains "whitespace" (unused space).
Adding users, computers, printers and other objects along with defining various attributes will cause the database to grow, and it can be anywhere from a few MB in size to several GB. Being able to load the database entirely in addressable memory will significantly improve operations such as authentication. Therefore it is normally recommended for DCs with 4 GB or more of physical RAM to use the \3 GB switch in Boot.ini to expand the user mode section of memory, which permits more of the NTDS.DIT to fit in there.
Windows Server 2003 made an important change that significantly reduced the database size. While a security descriptor value is stored for every object in Windows 2000 Server, Windows Server 2003 uses single instance descriptors, allowing multiple objects to use a single descriptor.
Defragging the Active Directory database
It's important to defragment the Active Directory database for best performance. Normally there is an online defragmentation that occurs about twice a day on the database, but this is more of a backup than defrag. It can give admins a false sense of security, thinking that the database has been defragged without any downtime.
The only way to truly defragment the Active Directory database, remove whitespace and decrease its size is with an offline defrag. This requires you to take Active Directory offline by booting a DC into Directory Service Restore Mode (DSRM), which boots up the DC in safe mode without mounting the AD database. Once booted, enter the NTDSUtil program and you will be able to perform a number of actions that are not possible with Active Directory online, including those in the File menu as shown in Figure 3.
Figure 3 (click to enlarge)
[IMAGE]
Significant functions include:
Figure 4 (click to enlarge)
[IMAGE]
Note that there are other commands available that allow you to move the database and log files, set the online backup directory path and even perform a soft database recovery.
To perform the actual defrag of the Active Directory database, the following steps are required:
If you want to play with this in a test domain, you can record the size of the NTDS.DIT and then create a large number of users -- say 10,000 -- in the domain. Note the increased size of the NTDS.DIT. Then delete the users and follow the procedure just described to compact the database and replace the old one with the whitespace for the 10,000 deleted users. Compare the size of the new, compacted database with the size after you created the users. You could also wait for an online defrag of the database to occur (recorded with an event in the system event log) and see if that changes the NTDS.DIT size. Note that in a production situation, you want to perform database integrity checks to ensure stability.
It is not necessary to perform this offline defrag on a regular basis, but it's good to do it after significant changes have been made -- such as the removal of a large number of users or groups -- to keep the database at an efficient size.
[TABLE]
