Working With the Domain Controller Diagnostic Utility (Part 2)

n the first part of this article series, I explained that if you wanted to diagnose problems with a domain controller, you could just enter the DCDIAG command, or you could use any of the numerous available command line switches as a way of getting the utility to test the specific properties of the domain controller that you are interested in. In that article, I began showing you a few command line switches, but there are a few more switches that I want to show you. In this article, I will talk about some additional switches, and will eventually go on to talk about some individual tests that you can run.

/C

I have already mentioned that you can just enter the DCDIAG command without any command line switches, and the Domain Controller Diagnostic Utility will perform a full battery of tests against your domain controller. Even so, there are a few tests that the Domain Controller Diagnostic Utility is capable of performing, but that it does not perform by default.

If you are not really sure what is going on with your domain controller, then I recommend running the DCDIAG command with the /C switch. This tells DCDIAG that you want to perform a comprehensive set of tests. This causes the Domain Controller Diagnostic Utility to run every test that it knows how to run, aside from the DCPROMO and the RegisterInDNS tests, which I will talk more about later on.

Keep in mind that running a comprehensive set of tests can take a long time to complete. If there are tests that you know that you do not need to run, then you can use the /C switch in conjunction with the /SKIP switch. Simply append a colon and the name of the test that you want to skip to the /SKIP switch, and the specified test will be omitted from a comprehensive scan.

/F

At the beginning of Part 1, I showed you what running DCDIAG without specifying any command line switches looks like. As you may recall, the output was fairly long. Of course when I created that screen capture, I simply ran a default set of tests against a healthy domain controller. The output can be a whole lot longer if you specify additional tests, or if the tests detect problems with the specified domain controller.

In some cases, reading the test results from the screen as the tests are run may not be practical. DCDIAG may spew data faster than you can read it. This is where the /F switch comes into play. The /F switch gives you the option of writing the test results to a log file. That way, you can read the results at your leisure. More importantly you will have a permanent copy of the output that you can refer back to for reference.

To use the /F switch, simply append a colon and the path and filename of the log file that you want to create. For example, if you wanted to create a log file named TEST.LOG, then you would enter DCDIAG /F:TEST.LOG. Keep in mind that when you specify the /F switch, the output is completely redirected to the log file. This means that the test output is not written to the screen at all. For operations involving multiple tests, the server may appear to lock up while the tests are performed.

/FIX

So far all of the command line switches that I have shown you are diagnostic in nature. When you use them, they cause DCDIAG to run its tests in certain ways, but DCDIAG only reports the test results. It does not attempt to correct any problems that it may find.

If DCDIAG does report problems you can attempt to correct those problems by specifying the /FIX switch. Even though this switch is simple in that it does not require you to provide any additional attributes, there are some very important things that you need to know about using this switch.

Before you use the /FIX switch, it is important to remember what you are really doing. You are telling an automated utility to make changes to your domain controller, which often means that you are blindly modifying the Active Directory. The Domain Controller Diagnostic Utility is designed so that when you use the /FIX switch, it will only make repairs that it deems to be safe. Even so, the simple fact using this switch involves blindly making changes to a domain controller leads me to recommend that you use the switch with extreme caution. The /FIX switch is designed to be safe, but any time that you are working with something as complex as a domain controller, things can go wrong.

That being the case, I recommend that you never specify the /FIX switch the first time that you run DCDIAG. Instead, you should run your tests, and take the time to evaluate the test results before you ever use the /FIX switch. If you do decide to use the /FIX switch, then I recommend making a full, system state backup of the target domain controller before doing so.

If you want to hedge your bets a bit, then one additional precaution that you can take before you attempt to fix a domain controller is to install Windows onto a spare PC, and then configure that PC to function as a domain controller. When you are done, wait for the replication process to complete, and then shut down and unplug the PC. That way, you have a healthy domain controller that you can use to rebuild your Active Directory if something should go horribly wrong during the repair process.

/TEST

The last switch that I want to talk about is the /TEST switch. So far, most of the command line switches that I have shown you are geared toward controlling the way that the Domain Controller Diagnostic Utility behaves when running various tests. You have also seen that the Domain Controller Diagnostic Utility runs a full set of tests by default, but that you can use either the /C switch or the /SKIP switch to run additional or fewer tests respectively.

The point that I am trying to make is that so far I have worked under the assumption that you will be running multiple tests. You do not have to run multiple tests. The /TEST switch allows you to simply specify the name of an individual test that you want to run. Just append a colon and the test’s name to the /TEST switch.

Keep in mind that you cannot use the /TEST switch to run multiple tests. As you can imagine, the /TEST switch is incompatible with the /SKIP switch, since the two switches do contradictory things.