Working With the Domain Controller Diagnostic Utility (Part 1)

If you would like to read the other parts in this series please go to:

Domain controllers are the backbone of just about any Windows network. After all, if your domain controllers are not working then the Active Directory does not work either. If the Active Directory does not work, then users cannot log on, group policies cannot be enforced, and a whole slew of other features become unavailable. Fortunately, Windows ships with a tool that you can use to keep your domain controllers running smoothly. This tool is called the Domain Controller Diagnostic Utility. In this article, I will show you how to use this tool to perform basic maintenance and diagnostic tasks on your domain controllers.

Before I Begin

The Domain Controller Diagnostic Utility has been a part of Windows for quite some time now. For the purposes of this article, I will be working with the version of this utility that comes with Windows Server 2008. Most, if not all of the features that I will be talking about are also available in the Windows Server 2003 SP1 version. DCDIAG existed prior to Windows Server 2003 SP1, but many of the commands that are available today were first introduced in Windows Server 2003 SP1.

You can access the Domain Controller Diagnostic Utility by running the DCDIAG command from a Windows command prompt.

Running the Domain Controller Diagnostic Utility

If you want to keep things simple, you can run the Domain Controller Diagnostic Utility by entering the DCDIAG command into a Windows Command Prompt window. Upon doing so, the utility will perform a variety of tests against the domain controller that you’re connected to. You can see an example of what these tests look like in Figure A.

Figure A: The Domain Controller Diagnostic Utility runs a variety of tests against a domain controller

By simply entering the DCDIAG command does get the job done, but this would not be much of an article if I just told you to run the command, and left it at that. There is a lot more to the Domain Controller Diagnostic Utility than meets the eye. Before you can really appreciate all the tool’s capabilities you need to become familiar with the optional parameters that you can use in conjunction with the DCDIAG command. If you look at Figure B, you can see that the DCDIAG command’s syntax is too long to even fit on a screen capture. Like most things that are really complicated the command’s syntax is not as bad as it initially appears. Once you understand how the command works, using it becomes fairly easy.

Figure B: The DCDIAG command’s syntax is so long that it won’t even fit on the screen

Breaking Down the Syntax

As you can see in the figure above, the DCDIAG command’s basic syntax looks like this:

dcdiag.exe /s:<Directory Server>[:<LDAP Port>] [/u:<Domain>\<Username>
           [/hqv] [/n:<Naming Context>] [/f:<Log>] [/x:XMLLog.xml]
           [/skip:<Test>] [/test:<Test>]

Although the screen capture shown in Figure B lists what each of the command line switches does, the explanation is a bit sparse. That being the case, I am going to try to give you a better explanation of what each of the command line switches does.


If you run the DCDIAG command with the /H parameter, it simply displays the DCDIAG command’s syntax in the manner shown in Figure B. If you look closely at the figure, you will notice that you can also use the /? Switch to display the command’s syntax.


The /S parameter allows you to specify a home server. Essentially, this means that you can use the /S parameter to specify the name of the domain controller that you want to run DCDIAG against. As you may recall, when I ran the DCDIAG command in Figure A, I did not have to specify a home server. If you do not specify a home server, then DCDIAG will just pick one automatically.

There are a couple of instances in which a specified home server will be ignored. The DCPROMO and the Register In DNS tests are run locally rather than being run against a domain controller. Therefore, if you try to specify a home server for these tests, it will be ignored. I will talk more about these tests later on.


The /N parameter allows you to specify a domain naming context. In case you aren’t familiar with this term, every domain is represented by a domain naming context. The domain naming context stores objects for the domain such as users, computers, groups, etc. You don’t have to specify a domain naming context, but if you choose to use one, you can enter it is NetBIOS, DNS (fully qualified domain name), or distinguished name (DN) form.


Unless you are logged on as an administrator of the domain that you are testing, you will have to supply the DCDIAG command with a set of administrative credentials that it can use. As you no doubt know, administrative credentials typically consist of a username and a password. The /U switch is used to specify the username. Since you are entering the name of an account with domain admin permissions, you will have to enter the username in domain\username format.


The other switch that is used when entering a set of credentials is the /P switch. As you have probably already figured out, you would follow the /P switch with the password for the account that you specified through the /U switch.


An Active Directory is often grouped into sites. A site typically represents a collection of domain controllers that all have reliable, high speed connectivity between them. For example, if an organization has two different facilities, connected together by a WAN link, each of the two facilities would typically be configured to act as its own site since the computers within the facility are on a common LAN, but there is no LAN connection between the facilities.

If your organization is divided into sites, then you will be interested in the /A switch. Using this switch tells DCDIAG to test all of the domain controllers in the current site.


The /E switch is similar to the /A switch, except that instead of telling DCDIAG to test all of the domain controllers in the current site, it tells DCDIAG to test every domain controller in the entire enterprise.


As you have already seen, the DCDIAG command’s output is pretty long. It can be easy for error messages to get lost in such a long output. If this happens to you, you can use the /Q switch to run DCDIAG in Quiet more, which will cause it to only list error messages.


The /V switch is kind of the opposite of the /Q switch. While the /Q switch reduces the size of the output, the /V switch increases it. That way you can get more detailed (verbose) information on the problem that you are trying to correct.


Sometimes DCDIAG will produce meaningless error messages that can really be confusing to less experienced administrators. If this happens to you, you can use the /I switch to tell DCDIAG to suppress any unimportant error messages.


In this article, I have introduced you to some of the basic commands used by the Domain Controller Diagnostic Utility. In Part 2, I will continue the discussion by showing you how to use a few additional command line switches, and how to specify specific tests that you would like to run.

If you would like to read the other parts in this series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top