When you have an Active Directory problem, what do you do? Panic? Sit in the corner and sob? A much better reaction would be to reach into your software toolbox, pull out some utilities, and get to work. But of course, that begs the question: What tools can you use to diagnose and repair Active Directory problems? In this Daily Drill Down, I’ll explain what some of the common Active Directory troubleshooting tools are and where you can find them.

Before you begin
Before I talk about the various Active Directory diagnostic tools, I need to point out that many of these tools aren’t installed by default. To install these tools, you must install the Windows Support Tools. To do this, insert your Windows 2000 Server CD, and when the Windows 2000 splash screen appears, select the Browse This CD command. Now, navigate through the CD’s directory tree to the \SUPPORT\TOOLS folder and run the Setup program. Once the Windows Support Tools are installed, all of the utilities that I’ll be discussing in this article will be available to you.

The Active Directory Replication Monitor tool (REPLMON) allows you to view the Active Directory replication status and to force replication, if necessary. You can open the Replication Monitor by entering the REPLMON command at the Run prompt.

When the Replication Monitor opens, select Add Monitored Server from the Edit Menu. When you do, you’ll see a screen that allows you to either enter a server’s name or search an entire domain for servers to monitor. Once you’ve selected the server you want to monitor, you’ll see the server’s replication information, as shown in Figure A.

Figure A
The Replication Monitor tool allows you to view a server’s replication status.

As you can see in the figure, the Replication Monitor displays all of the selected server’s replication data. Each of the nodes that you see in the figure represents a link to a replication partner. If you select one of these nodes, you’ll see a summary appear in the column to the right.

This summary tells you whether the servers are in sync and when the last successful replication took place. If you need to force replication between two replication partners, you can do so by right-clicking on the replication partner that you want to synchronize and selecting the Synchronize With The Replication Partner command from the resulting context menu.

The Replication Monitor is also a great source of general information about your Active Directory replication. For example, you can select Domain | Search Domain Controllers For Replication Errors on the Action menu to scan the entire replication partner list for replication problems. You can also select the server that you’re monitoring and use the Action menu’s Server command to gain a wide variety of information related to the server’s replication status. For example, you can view the replication topology or the current performance data. Figure B shows the various commands on the Server menu.

Figure B
The Action | Server menu allows you to access a wide variety of information regarding a server’s replication status.

DSASTAT is a command-line utility that you can use to detect differences between naming contexts on domain controllers. You can use this Active Directory diagnostic tool to compare two replicas within the same domain, or you can compare a replica within any domain to the global catalog.

The DSASTAT utility is one of the simpler Active Directory utilities to use. It doesn’t have nearly as many command-line options as some of the other utilities that I’m discussing in this article. You can view the syntax of this command by entering the DSASTAT /? command at the command prompt.

The one thing that you need to know about the DSASTAT command before you use it is that the comparison process takes some time to complete. On my test environment, a comparison between two replicas took about 10 minutes to complete. Keep in mind, though, that because I ran the command in a test lab, my Active Directory didn’t contain nearly as many objects as you would expect to find in a medium-sized company’s Active Directory. Therefore, your comparison may take considerably longer than mine did. You can see a sample of the output from my DSASTAT comparison in Figure C.

Figure C
The DSASTAT command will detect differences in two Active Directory replicas or between a replica and the global catalog.

All Active Directory queries are based on the Light Weight Directory Access Protocol (LDAP). The LDP tool allows you to make LDAP queries to the Active Directory through a graphical tool.

You can use the LDP tool to connect to a server and then view information, such as the security descriptor for the various Active Directory objects. You can open the LDP tool by entering the LDP command at the Run prompt. When LDP opens, use the Connect command on the Connection menu to connect to the target server.

Once you’ve connected to the target server, you may begin making LDAP queries against it. You can use the options found on the Browse menu to add, delete, modify, search, and compare LDAP entries. You can even use options on the Browse menu to look at the security descriptor, user rights, and the replication meta tag.

Before you attempt to use the LDP tool, it’s important to know that after you’ve made the initial connection to a server, you can’t use simple names like USER1 to interact with objects. Instead, LDP requires you to use distinguished names, which LDP abbreviates as DN. A distinguished name is a name that uniquely identifies an object by its location within the Active Directory. An example of a distinguished name would be CN=User1,CN=Users,DC=Test,DC=COM. This particular distinguished name refers to User1 as a user object in the test.com domain. You can see an example of the way that you’d use a distinguished name by looking at the bottom of Figure D.

Figure D
When referring to an object, the LDP tool requires you to use its distinguished name.

NLTEST is a fairly complicated command-line tool that’s designed to help perform various administrative and diagnostic tasks. Unfortunately, space restrictions don’t permit me to cover NLTEST exhaustively. Therefore, I will provide you with an overview of some of the more useful features. You can access the remaining features by entering the NLTEST /? command in a command-prompt window. Doing so will display the command summary shown in Figure E.

Figure E
The NLTEST command has a significant number of command-line options.

Some of the more useful tasks that NLTEST can perform include testing trust relationships, forcing a remote server shutdown, getting a list of PDCs, checking replication status, and forcing synchronization of Windows 2000 and Windows NT domain controllers.

The syntax for NLTEST is fairly straightforward. For example, suppose you wanted to remotely shut down a server. You could do so by entering the following command:
NLTEST /SHUTDOWN:servername [seconds]

If you need to abort a shutdown after the command has been issued, you can do so by entering the following command:

NLTEST is also capable of revealing the PDC for a domain. To determine a domain’s PDC (or PDC emulator), enter the following command:
NLTEST /DCNAME:domainname

While you’re at it, you can get a list of which domain controllers belong to a domain by entering the command below. This command is extremely useful when dealing with those situations in which a machine is supposed to be a domain controller but Windows isn’t acknowledging it as such. To see which domain controllers Windows thinks belong to a given domain type, enter this command:

You can also use the NLTEST command to test a domain’s trust relationships by entering the following command:

You can narrow things down by examining specific types of trusts rather than all trusts. To do so, simply substitute the /ALL_TRUSTS switch with one of the following switches: /PRIMARY, /FOREST, /DIRECT_OUT, or DIRECT_IN.

Another way that NLTEST can check trust relationships is by testing to see which domains a user is allowed to log on to. Remember that a user account normally exists in only one domain, so if a user is allowed to log on to any domains other than his or her home domain, it’s usually because a trust relationship exists. You can see which domains a user is allowed to log on to by entering the following command:

By far, the most powerful Active Directory tool that Windows 2000 has to offer is the NTDSUTIL utility. NTDSUTIL is a command-line utility that allows you to interact directly with the Active Directory databases. For example, the NTDSUTIL tool allows you to restore the Active Directory database, clean up Active Directory objects that have been decommissioned, prepare for new domain creation, and manage the LDAP deny list.

The best thing about the NTDSUTIL utility is that it allows you to do things that would normally be impossible. For example, you can use NTDSUTIL to remove an orphaned domain from the Active Directory, even if the demotion was unsuccessful. When my network experienced a catastrophic Active Directory failure several months back, the NTDSUTIL tool was the one utility that was able to solve my problems. Unfortunately, in the case of a severe Active Directory crash, NTDSUTIL isn’t a quick fix. Recovering from such a crash usually involves using the other utilities to gather information about the crash and then using several different NTDSUTIL command options to correct one issue at a time, all the while inching closer to your goal of fixing the Active Directory.

Other tools
As you work toward repairing a damaged Active Directory, remember that, whenever possible, the Active Directory-related Administrative Tools, such as Active Directory Users And Computers and Active Directory Sites And Services, should be your primary tools. The reason is that these console tools are designed to give you everything you need to deal with many of the situations that you’ll encounter.

Many of the tools that I’ve discussed in this article don’t feature certain safety mechanisms that are built into the Active Directory console tools. Therefore, if you need to do something to the Active Directory and you have a choice between using one of the console tools and one of the tools that I’ve discussed in this article, try using the console tool first.

In addition to the tools that I’ve discussed and the console tools, there are some other Active Directory tools available to you. One such tool is Repadmin.exe, which is a command-line tool that’s designed to help troubleshoot replication problems. What’s unique about this tool is that it allows you to view the replication policy from the standpoint of each domain controller and modify the replication policy, if necessary. Keep in mind that the knowledge consistency checker maintains the replication policy, and under normal circumstances, you should never have to manually modify it. Making manual adjustments to your replication policy can have some serious negative effects on your network. Therefore, use this tool at your own risk.

Another tool that’s worth looking into is the Security Descriptor Check Utility or Sdcheck.exe. This command-line tool allows you to view the security descriptor of any object in the entire Active Directory. Not only does this tool display an object’s access control list but it also tells which permissions in the access control list were inherited from a parent object.

Finally, the Dsacls.exe tool is a command-line tool that allows you to manage the access control list for Active Directory objects. This tool does the exact same thing that you do when you modify permissions through one of the Active Directory console tools. The only difference is that this tool makes the modifications at the command prompt rather than through a GUI.

When Active Directory falters, you need a strategy. Moreover, you need the right tools to help you solve the problem. Fortunately, Microsoft provides several of these tools right on the Windows 2000 CD-ROM—one or all of which might be able to help you diagnose and repair Active Directory problems. Once you’re aware of the existence of these tools and how to use them, you don’t have to panic when problems occur; you can just go to work.