With time, your Active Directory (A/D) database can malfunction and become filled with data that you do not need anymore, such as references to users or servers that do not exist anymore. Here are 10 things to know before “de-gunking” your Active Directory.
1: Think simple before anything else
Erratic Active Directory behavior is not always due to a corrupt Active Directory database. For example, not being able to create or remove a domain may be due to the fact that the domain controller hosting the FSMO roles for the domain is down, or even more simple, the user attempting to perform the operation may not have the necessary permissions.
2: Make sure DNS is properly functioning
Active Directory is completely dependent on DNS, so if this server fails, Active Directory begins to have problems too. Indications of a DNS server issue include error messages such as “Domain Not Found”, “Server Not Available”, or “RPC Server is Unavailable”.
3: Know the power and ease 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, and often times, DCDIAG will help you quickly determine the cause of the problem.
4: Delete extinct metadata correctly
While you can use ADSI Edit to manually remove references to extinct servers, doing so often does more harm than good. With Active Directory being 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: ADSI Edit is unforgiving
You can use ADSI Edit to manually create and delete Active Directory entries, however, 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. ADSI Edit is useful to work around this issue, but take extreme caution in using it for other purposes.
6: Don’t use domain controller snapshots
With virtualization being so popular, many organizations have virtualized their domain controller and server virtualization products on the market allow you to create a snapshot of a server. That way, in the event that something goes wrong with the server, you can roll it back to a previous state without having to restore a backup.
While backing up your domain controllers before attempting to repair Active Directory is a good idea, you shouldn’t use snapshots. Rolling back to a snapshot of a domain controller can have catastrophic consequences. Active Directory transactions are numbered and rolling back a domain controller causes the numbering sequence to be disrupted. This leads to all sorts of domain synchronization issues.
7: 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 enough for the problem at hand. In this case, the best option is to restore a backup. If that isn’t possible, though, you can try using ESEUTIL.
ESEUTIL is a database maintenance tool for extensible storage engine databases and it can be used to repair structural problems within the database. This technique should only be implemented as a last resort due to the possibility of data loss during the repair process.
8: 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, meaning 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 while often, an 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 performing any major repair or cleanup work on your Active Directory, it is imperative to perform a full system state backup of your domain controllers. 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 while 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, the importance of a good backup should never be underestimated.