Domain Controllers are the backbone of many networking environments in many organizations. Unavailability and a lack of performance of these servers quickly escalates into numerous helpdesk calls and employee disgruntlement.
Many admins opt to beef up Domain Controllers with larger amounts of RAM, more processor power and more capable networking interface cards (NICs). Another avenue is to optimize the contents within the Active Directory database. Here’s how.
Caching the Active Directory Database
Every object in Active Directory takes up space in the Active Directory database (ntds.dit). For performance, the Active Directory databases is cached into RAM by Domain Controllers, since accessing data on Random Access Memory is way faster than accessing data on traditional hard disks and solid state disks. When parts of the Active Directory database are not cached in memory, these parts will be significantly slower compared to parts that are.
Keeping the Active Directory database as small as possible is key to Domain Controller performance, especially on (x86-based 32bit-only) hardware that can no longer be beefed up and on Windows Server installations that don’t support more processors or RAM, like Windows Server Standard Edition in previous versions of Windows Server.
While many large Active Directory databases have grown steadily throughout the years, new functionality might lead to sudden growth. Storing user photos and BitLocker recovery information in Active Directory without proper planning will quickly result in poor Active Directory performance.
Indexing of attributes
Indexing an attribute helps queries find objects that have that attribute more quickly and efficiently than if the attribute had no index. The Active Directory directory service index is built automatically by a background thread on the directory server, instead of being created through a query at the moment you need it (and then have to wait for it).
By default, some attributes in Active Directory are indexed. You can index additional attributes for objects, when you (or your application’s vendor) feel this might improve the performance of queries for the attributes.
(Part of) The solution
Properly plan Domain Controllers
When introducing a Domain Controller to a networking environment, ideally, you should make sure you enable the Domain Controller to make it through its economic lifetime without major problems. In most organizations, this means:
- Comply with Best Practices
The Active Directory infrastructure needs to comply with Microsoft’s best practices, since these make you avoid 90% of the situations where data loss might occur. Typical best practices include placing at least two Domain Controllers per Active Directory domain and making regular backups of Domain Controllers. The Active Directory Best Practices Analyzer (AD BPA), available since Windows Server 2008 R2, can help you make your environment compliant.
- Properly dimension Domain Controllers
Domain Controllers need to be dimensioned to handle the load for four to seven years (their typical economic lifetimes). This means you need to make sure free disk space is adequate to accommodate the Active Directory database and leave sufficient disk space for online and offline defragmentation.
- Install Domain Controllers with supported Windows Server versions
Two Domain Controllers might exhaust your budget, but, economically, avoiding the risk of data loss will aid your business case swing in the right direction. Another argument for making the right choices (like not implementing new Windows Server 2003-based Domain Controllers) is, economically it’s more efficient to only implement the environment once (instead of having to migrate it later on). Procrastinating during the planning phase doesn’t pay off.
These planning thoughts, however, are to no use, when your Active Directory infrastructure is suddenly experiencing a performance impact.
Reducing the size of the Database
Reducing the Active Directory Database size will increase the performance of Active Directory on improperly dimensioned Domain Controllers. Not only does this imply only the necessary objects are created, but also that unnecessary objects are gone from the database. The latter is not as easily achieved as you would think, though.
Creating only necessary objects
Let’s start by only creating necessary objects. Since every object in the database consumes at least 4KB in the Active Directory database size, every object that is reused or relabeled saves 4KB both on disc and in RAM. Every large attribute that is stored as efficiently as possible will prevent database bloat.
Part 1 of this series on stale objects and Part 2 of this series on unnecessary complexity and token bloat are good takes on how to successfully achieve this goal within your organization.
Deleting unnecessary objects
The second part would be to keep only the previously created necessary objects, and toss out the unnecessary objects. The first part would be to identify these objects, then deleting them and then the third part would be to take out the trash.
Identify unnecessary data
Unnecessary data appear in many shapes and forms in Active Directory. They can be user accounts, computer accounts, groups, managed service accounts, fine-grained password policies, Active Directory sites, Active Directory-integrated DNS data and Active Directory replication-related data, like old InvocationIDs.
Most of the data won’t take up much space, unless you’re really putting your Active Directory environments through their backup and restore paces. One of the situations in which a new InvocationID is created is a successful non-authoritative Domain Controller restore. This is not something you should be needing to do on a daily basis…
Delete unnecessary objects
Once you’ve identified unnecessary objects, you can delete them. If you paid attention while reading this blog through the years, you should know by now that deleting in Active Directory does not immediately result in a smaller Active Directory database size. That’s because you need to take out the trash.
Take out the trash
When you delete an object in Active Directory, it becomes tombstoned. With the Active Directory Recycle Bin enabled, items become recyclable for a period of time and then tombstoned. Only after the tombstone lifetime period, the object is deleted from the database.
While this deletion helps the performance of Active Directory in terms of caching the database, it merely creates whitespace (slack) in the database. This whitespace does not result in a diminished size of the database on disk.
To diminish the database size on disk, you will need to offline defragment the Active Directory database as described in Microsoft KnowledgeBase article 232122:
- Reboot the Domain Controller, select the appropriate installation from the boot menu, and press F8 to display the Advanced Options menu. Choose Directory Services Restore Mode and press ENTER. Press ENTER again to start the boot process.
- Log on using the Administrator account with the password defined for the local Administrator account in the offline SAM.
- Open a Command Prompt. At the command prompt, type ntdsutil.exe, and then press ENTER.
- Type files, and then press ENTER.
- Type info, and then press ENTER. This displays current information about the path and size of the Active Directory database and its log files. Note the path.
- Establish a location that has enough drive space for the compacted database to be stored.
- Type compact to drive:\directory
Where drive and directory is the path to the location you established in the previous step. Then press ENTER. Note:
You must specify a directory path. If the path contains any spaces, the entire
path must be surrounded by quotation marks. For example, type:
compact to “c:\new folder”
- A new database named Ntds.dit is created in the path you specified.
- Type quit, and then press ENTER. Type quit again to return to the command prompt.
- If defragmentation succeeds without errors, follow the Ntdsutil.exe on-screen instructions. Delete all the log files in the log directory by typing the following command:
del drive:\pathToLogFiles \*.logCopy the new Ntds.dit file over the old Ntds.dit file in the current Active Directory database path that you noted in step 6. Note:
You do not have delete the Edb.chk file.
- Restart the computer normally.
Depending on the amount of whitespace (slack) in the database, you will need up to 100% more disk size to perform an offline defragmentation.
Index often-queried attributes
When you identify typical Active Directory actions with poor performance, you might opt to index the queried attribute. An example would be an Active Directory-integrated application that references a specific attribute. In that case, you can speed up the action by marking the attribute as an indexed attribute in the Active Directory schema.
The procedure for this is:
- Open the Active Directory Schema snap-in (schmmgmt.msc).
- In the left-hand pane, click Attributes.
- In the right-hand pane, right-click the attribute that you want to index, and then click Properties.
- Click Index this attribute in the Active Directory and click OK to save the change.
- Close the Active Directory Schema snap-in.
Your Domain Controllers will now build an index for that attribute.
When you’re using Windows Server 2012-based Domain Controllers, however, you might have enabled Deferred Index Creation. In that case, you might need to perform a UpdateSchemaNow rootDSE mod or reboot your Domain Controllers before they start building the index.
Optimal performance of Active Directory is not just the art of throwing sufficient hardware at it. Keeping your Active Directory database tidy may have a significant impact on performance, depending on the amount of RAM in your Domain Controllers, the amount of slack in the database and whether crucial attributes are indexed.
Related KnowledgeBase articles
232122 Performing offline defragmentation of the Active Directory database
257218 Default Active Directory Attributes in the Windows 2000 Schema
307323 AD replication delayed when indexed attributes rebuilt during schema upgrade
307219 Replication Stops After Active Directory Schema Update