Common Recovery Tools in Active Directory: Part 1

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.

There are a few other helpful, additional tests that are not in the default set. These are important to know as well. To run the specific tests, simply type the following at the command prompt:

>dcdiag /test:TESTNAME

Where testname is the name of the test. You can see a list of these tests in the following table. The most notable tests are those in the DNS set. As the DNS is such an integral part of AD, testing its functionality will rule out, or at least narrow down, several things that could be wrong with the DNS.

Additional tests



Tests DNS checks for the entire enterprise; subtests can be checked separately


Tests the basic DNS functionality such as connecting and looking up records


Checks the forwarders and root hints for errors


Checks the DNS delegations


Checks if dynamic updates are working


Checks if the DNS registration works


Checks if external names can be resolved


Runs all the subtests


Can be used with /DnsResolveExtName with a URL to resolve


Checks for security errors or potential security errors


Checks all replicas on all replica servers for consistency


Checks whether the entire topology is fully connected


Checks for servers whose partners are not available, and therefore can't receive replications

Running DcDiag with the /fix flag will attempt to fix some minor problems it encounters. Some of the DNS-related issues, for example when the DC is not registered in the application partition, could quickly be fixed this way.


NetDiag is another command-line utility that lets you perform tests with a lot of verbose output. It is also included in the Windows Support tools. While DcDiag allowed to you to test everything related to the DCs and DNS, NetDiag allows you to test everything related to the network stack of the machine.

NetDiag, by default, just like its cousin DcDiag, runs an extensive set of tests. These tests include checking network connectivity, checking which hotfixes are installed, whether the network card is configured properly and the network speed is configured correctly, what protocols and services are running, domain membership, and many more. A sample output from a working DC ( is as follows:

C:Documents and SettingsAdministrator>netdiag
Computer Name: DC1
DNS Host Name:
System info : Microsoft Windows Server 2003 (Build 3790)
Processor : x86 Family 6 Model 15 Stepping 8, GenuineIntel
List of installed hotfixes :
Netcard queries test . . . . . . . : Passed

Per interface results:

Adapter : Local Area Connection
Netcard queries test . . . : Passed

Host Name. . . . . . . . . : dc1
IP Address . . . . . . . . :
Subnet Mask. . . . . . . . :
Default Gateway. . . . . . :
Dns Servers. . . . . . . . :
AutoConfiguration results. . . . . . : Passed
Default gateway test . . . : Passed
NetBT name test. . . . . . : Passed
[WARNING] At least one of the <00> 'WorkStation Service',
<03> 'Messenger Service', <20> 'WINS' names is missing.

WINS service test. . . . . : Skipped
There are no WINS servers configured for this interface.

Global results:
Domain membership test . . . . . . : Passed
NetBT transports test. . . . . . . : Passed
List of NetBt transports currently configured:
1 NetBt transport currently configured.

Autonet address test . . . . . . . : Passed
IP loopback ping test. . . . . . . : Passed

Default gateway test . . . . . . . : Passed
NetBT name test. . . . . . . . . . : Passed
[WARNING] You don't have a single interface with the <00>
'WorkStation Service', <03> 'Messenger Service', <20>
'WINS' names defined.

Winsock test . . . . . . . . . . . : Passed
DNS test . . . . . . . . . . . . . : Passed
PASS - All the DNS entries for DC are registered on DNS server
'' and other DCs also have some of the names registered.

Redir and Browser test . . . . . . : Passed
List of NetBt transports currently bound to the Redir
The redir is bound to 1 NetBt transport.

List of NetBt transports currently bound to the browser
The browser is bound to 1 NetBt transport.
DC discovery test. . . . . . . . . : Passed
DC list test . . . . . . . . . . . : Passed
Trust relationship test. . . . . . : Skipped
Kerberos test. . . . . . . . . . . : Passed
LDAP test. . . . . . . . . . . . . : Passed
Bindings test. . . . . . . . . . . : Passed
WAN configuration test . . . . . . : Skipped
No active remote access connections.
Modem diagnostics test . . . . . . : Passed
IP Security test . . . . . . . . . : Skipped
Note: run "netsh ipsec dynamic show /?" for more detailed information

The command completed successfully

As you can see from this example output, there are several warnings and skips of tests. The warnings shown here occur because we do not have certain services running on the DCs. These are not critical services and we do not need them. However, NetDiag tested them anyway because, by default, it executes a standard set of tests which includes these. The Messenger Service, Workstation Service, and WINS names were not running because they are not needed in our domain structure.

Should you rely on these services, especially as many companies still have WINS servers running, these warnings should catch your attention because they should be running. As the WINS server address was not defined, the service test for WINS was skipped. We also have no current trust relationship with other domains, and therefore that test was also skipped. If we had one, the trust connection would have been checked to verify that it was working and the other end can be contacted. Lastly, we do not have any IPSec configured on our network cards, and no WAN or Remote Access connections, so this is why these tests were skipped as well. If you have a RAS connection configured, the test will try to use it and verify its state. This is particularly useful if you have modem or DSL-based backup lines that are used for replication should the LAN fail between the networks and DCs.

Just like DcDiag, NetDiag also has a set of extra switches and tests. The interesting ones are listed in the following table. And you can invoke the tests by typing:


The options in NetDiag are the ones that can give a lot of information on the verbose and debug flags.

Netdiag switches



This creates a quiet mode and only shows the errors and warnings encountered, if any


Creates a verbose output for more information about each test result


Is the most verbose output; NetDiag can take quite a while to complete


Creates a log file called netdiag.log in the same directory as executed


NAME represents the domain name, and this option will find a DC in that domain


Like dcdiags /fix, this option fixes minor problems quickly


Enumerates all of the DC computer accounts within a domain


Name here is the name of the single test to run; for a full list, type netdiag /?

If you have connectivity issues, NetDiag will almost certainly find them, and as with DcDiag, it is recommended that you always output everything to a log file, which is easier to read. The output of both utilities scrolls by rather quickly in the command line, and can be difficult to read.


In this article, we discussed small command line utilities such as DcDiag and NetDiag, together with the whole set of tools in the Resource Kit and the Support tools, are invaluable to have in the DCs, or at least on an administrative machine where they are available for use at any time. The output of these smaller utilities can be faster than sifting through event logs that also contain a lot of other things. In the next part, we will cover monitoring your AD with Sonar and Ultrasound.

You've been reading an excerpt of:

Active Directory Disaster Recovery

Explore Title