Common Recovery Tools in Active Directory: Part 1

7 min read

Software for your DCs and administration

Although the software packages installed on the DCs might not be a specific recovery step in the true sense, when you are hard-pressed for time you don’t want to start looking for tools and programs; you want to have them installed and ready to work on, anywhere you need.

There are many tools. Instead of copying the specific executables to your DCs, it is much easier to install the toolkits as part of the deployment when you install a DC.

Windows support tools

For both Windows 2000 and Windows 2003, the support tools package is a must-have. This is included on the installation CD under Support/Tools, as shown in the following screenshot, which shows the contents of a 64-bit installation CD. The location of Windows 2003 Small Business Server Support Tools is on CD 2 of the SDS CD set.

active directory

As you can see, what Microsoft considers the most essential tools, namely DcDiag.exe and Repadmin.exe, are available as standalone executables. Among many medium and large-sized organizations, it is considered a best practice to install the support tools on every DC. This is so because the support tools package provides you with essential tools that you can use for troubleshooting when errors appear in the event log, or the DC starts behaving strangely.

Once you have the Support Tools installed, you will have an additional entry in your Start menu for Windows support tools, which contains a link to the Help file and a shortcut to the command prompt.

Windows Resource Kit tools

The Windows Resource Kit traditionally only came as books in the NT 4.0 era. With Windows 2000, Microsoft started making the tools that are included in the Resource Kit available online for free download. You can still purchase the books as well, which are quite useful because they describe each tool and its application in great detail. However, the tools themselves can easily be downloaded. The links are listed here:

For Windows Server 2003 64bit, there is no Resource Kit because Microsoft’s website clearly states that the tools are not supported on 64-bit platforms. Given that the tools can be run from any XP client as well, this is not much of an issue unless you want to run a complete 64-bit server environment, and would like to distribute the tools with the DCs. One option is to have a virtual DC that runs Windows Server 2003 in 32-bit mode.

As only a handful of tools are necessary for Disaster Recovery, and you can run the tools from a client, it does not matter that much. The main point is that the tools should be available somewhere close to the DCs in every location. So, if you run them from a client, it might be a good idea to copy the tools onto the administration PC. A good option is to keep a CD copy of these tools stored with the Disaster Recovery Guide.

Adminpack for Windows XP/Vista Clients

The Administrative Tools package (Adminpack) is the least-used administrator tool in most organizations. Although it is considered a best practice to install Adminpack onto the administrative PCs or the PCs of the IT department, this is rarely done. In several cases, a lot of the administrative tasks are performed via Remote Desktop, directly on the DCs. This, of course, means that you have to give all of the people who make even small changes in the AD access to log on to the DCs. This might not be a good idea from a security perspective and can lead to actions that could have been prevented, such as downloading things directly to the DC, and installing or copying/modifying settings on the DC directly.

As DCs are the heart that make AD work, these machines should be as secure and isolated as possible.

The Adminpack is actually a file called adminpack.msi, which can be found in the i386 folder on the 32-bit installation CD of Windows 2000 and Windows server 2003. It is also in the same directory on the 64-bit installation CD, but there it is called wadminpack.msi.

The Adminpack contains the necessary snap-ins for the Microsoft Management Console (MMC), and puts them into your Administrative tools folder. These snap-ins are the normal tools you would have on a DC in order to administer the AD (shown in the following screenshot). It is, however, possible to run them directly from your client instead of on the DC.

active directory

Using the Adminpack also allows you to re-target the tools to different DCs and you don’t have to log on every time.

Diagnosing and troubleshooting tools

In this section we are going through some of the more advanced uses and possibilities of three tools that will undoubtedly be of great help in diagnosing either AD problems or replication problems.

The three tools that almost every person who needs to perform troubleshooting on Windows Server 2003 should be familiar with are NetDiag.exe, DcDiag.exe, and Repadmin.exe.

All three are command-line utilities, which implies that they can be run from a Windows XP Professional or Windows Vista workstation, and that they are standalone executables that can be copied from one machine to another. A nice feature of these tools is that they connect remotely to the DCs via the Remote Procedure Call service (RPC) and therefore you do not need to log on to the DCs. The only requirement for most of them is that they need to run from a machine that is a member of the domain and has access to the network.


DcDiag is the domain controller diagnostic utility. It allows you to diagnose a domain controller, and check if everything is ok. If it is not, then the tests will run until failure, and based on which tests fail, you can go about finding the cause. Even though this may sound rather simple, this utility, even if run without any flags or options, will execute a set of very meaningful tests, and based on pass or fail, you will have a very good idea of where to start looking. The tests performed are listed in the following tables:

Primary tests



Tests whether or not the DC is connected to the network


Tests to ensure replications can be started, and are run on time


Checks that the security descriptors on the naming context heads have appropriate permissions for replication


Tests if the DC allows the appropriate logons to initiate replication


Tests if the DC can advertise itself (DNS)


Tests if the DC knows which servers hold the FSMO roles


Tests if the DC can contact the RidManager

Machine Account

Tests if the DC has a valid Machine Account


Tests if the necessary services are running on the DC


Tests whether or not the DSA and Machine Account objects have ever been replicated


Checks if the sysvol share is listed in the File Replication Service (FRS)


Tests if FRS errors have been generated


Tests if KCC errors have been generated


Tests if there are system errors


Tests if AD FRS records are intact and correct for the replication infrastructure

DNS Partition tests


Forest DNS tests


Checks if the replication cross-references are intact in the forest DNS zone


Checks if the Security descriptors for the forest are intact

Domain DNS tests


Checks if the replication cross-references are intact in the domain DNS zone


Checks if the Security descriptors for the domain are intact

Schema, Configuration, and Enterprise tests


Schema tests


Checks if the replication cross-references are intact in the schema itself


Checks if the Security descriptors within the schema are intact



Checks if the replication cross-references are intact in the current forest configuration


Checks if the Security descriptors within the configuration are intact

Partition tests


Checks if the replication cross-references are intact in the current application partition


Checks if the Security descriptors for the application partition are intact

Enterprise tests


Checks if the inter-site replication can be initiated


Checks that all FSMO roles are assigned and can be contacted

As you can see, DCDiag performs a lot of tests. But bear in mind that most of these are run locally on the DC with the data held by that DC. This means that any error in the DNS, Schema, configuration or partition tests can be working on another DC. It is possible that only this particular replica of the DC is malfunctioning.


Please enter your comment!
Please enter your name here