Over time, you may find that your Active Directory database becomes cluttered with obsolete data (such as references to users or servers that no longer exist) or that it begins to malfunction. Here are some things you should consider before you set out to clean up or repair your Active Directory.

Note: This article is also available as a PDF download.

1: Look for the simple solutions first

In spite of outward appearances, erratic Active Directory behavior is not always related to a corrupt Active Directory database. For instance, take a situation in which you can’t create or remove a domain. While it is possible for a corrupt database to cause this problem, it’s more likely that the domain controller hosting the FSMO roles for the domain is down. Another possibility is that the user who is attempting to perform the operation may not have the necessary permissions.

2: Verify that DNS is functioning properly

Active Directory is completely dependent on DNS. So if your DNS server fails, it will be only a matter of time before Active Directory begins to have problems too. If you are receiving error messages such as Domain Not Found, Server Not Available, or RPC Server is Unavailable, you may have a DNS server issue.

3: Never underestimate the power of DCDIAG

Windows domain controllers include a command-line utility called DCDIAG. Running this utility performs a number of diagnostic tests on a domain controller. Often times, DCDIAG will help you quickly determine the cause of the problem.

4: Delete extinct metadata the right way

One of the most common issues with Active Directory is that it contains numerous entries related to servers that no longer exist. While you can use ADSI Edit to manually remove references to extinct servers, doing so often does more harm than good. Active Directory is a relational database. Removing an entry for an extinct server can orphan other database entries and cause a whole slew of problems. A better approach is to use the NTDSUTIL tool’s METADATA CLEANUP option. This TechNet article provides a full set of instructions on the process.

5: Use ADSI Edit sparingly

You can use ADSI Edit to manually create and delete Active Directory entries. However, ADSI Edit is very unforgiving. Making a mistake can destroy your entire Active Directory. Therefore, it is important to know when and when not to use it. For example, Exchange 2007 can’t be uninstalled until the last public folder has been removed, but a bug prevents you from removing the remaining public folders. I have found ADSI Edit to be useful in working around this issue, but I am extremely hesitant to use it for other purposes.

6: Don’t use domain controller snapshots

With virtualization all the rage, it’s no surprise that many organizations have virtualized their domain controllers. Most of the server virtualization products on the market allow you to create a snapshot of a server. That way, if something goes wrong with the server, you can roll it back to a previous state without having to restore a backup.

While I’m all in favor of backing up your domain controllers before attempting to repair Active Directory, you shouldn’t use snapshots. Rolling back a snapshot of a domain controller can have catastrophic consequences. Active Directory transactions are numbered. Rolling back a domain controller causes the numbering sequence to be disrupted. This leads to all sorts of domain synchronization issues.

7: Remember that Active Directory is based on the extensible storage engine

Normally, NTDSUTIL is the tool of choice for repairing Active Directory problems. But in the case of severe corruption, NDTSUTIL may not be able to fix the problem. If this happens, your best bet is to restore a backup. If that isn’t an option, though, you can try using ESEUTIL.

ESEUTIL is a database maintenance tool for extensible storage engine databases. You can use it to repair structural problems within the database. You should use this technique only as a last resort because data loss is a possibility during the repair process.

8: Understand the difference between authoritative and non-authoritative restore

When you restore the Active Directory database on a domain controller, the restoration is usually non-authoritative. This means that the restoration process restores the domain controller to the point at which it existed when the backup was made. The domain controller is brought into a current state by the replication process. Other domain controllers replicate any missing entries to the recently restored domain controller.

An authoritative restore does not backfill a restored domain controller using data from other domain controllers. Instead, you are effectively telling Windows that the recently restored domain controller contains the desired data and that you want to remove any subsequent data from the other domain controllers in the organization.

9: Check NTFS permissions

When Active Directory related services fail to start on a domain controller, the problem is often mistaken for database corruption. But often, an overzealous administrator has recently tried to secure the system volume. Excessive NTFS permissions can actually prevent Active Directory from starting. Microsoft discusses this problem in Knowledgebase Article 258062.

10: Back up your domain controllers

Before you perform any major repair or cleanup work on your Active Directory, it is imperative that you perform a full system state backup of your domain controllers. As I’m sure you know, countless knowledgebase articles talk about the importance of backing up a system prior to modifying the registry — and modifying the Active Directory database is much more dangerous than editing the registry. If you make a mistake when editing the registry, you can destroy Windows. If you make a mistake in Active Directory, you can destroy the whole thing, which potentially affects every system in your organization. Therefore, you should never underestimate the importance of a good backup.