Working With the Domain Controller Diagnostic Utility (Part 4)

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

• Working With the Domain Controller Diagnostic Utility (Part 1)
• Working With the Domain Controller Diagnostic Utility (Part 2)
• Working With the Domain Controller Diagnostic Utility (Part 3)
• Working With the Domain Controller Diagnostic Utility (Part 5)
• Working With the Domain Controller Diagnostic Utility (Part 6)

I ended the previous article in this series by talking about some of the individual tests that you could run by using the Domain Controller Diagnostic Utility. In this article, I want to pick up where I left off and talk about more tests that you may perform.

DCPROMO

Some of the tests that are available through the Domain Controller Diagnostic Utility tend to be a bit obscure to say the least. In contrast though, the DCPROMO test is actually very useful. It is designed to let you test a server’s readiness prior to promoting the server to a domain controller. Granted, promoting a server to a domain controller is a fairly simple process. You just enter the DCPROMO command, click Next a few times, and you are on your way. Even so, I have created hundreds of domain controllers over the years, and it has been my experience that every once in a while the process goes belly up because of something unexpected. Personally, I would rather know up front whether or not the server was prepared to be promoted to a domain controller, then to try the promotion, have something go wrong, and have to figure out why. Of course if the domain controller promotion process does end badly, then you can always use the DCPROMO test after the fact to help you to figure out what happened.

If you are going to use the DCPROMO test, then you are going to have to use at least two command line switches with it. The first switch that you have to use is the /DNSDomain switch. You must use this switch to tell the Domain Controller Diagnostic Utility which domain the server is going to be made a domain controller in.

You have to follow the /DNSDomain switch with a secondary switch that tells the Domain Controller Diagnostic Utility what your intentions are for the server. For example, if the server is going to be a domain controller in a new forest, then it would need to be tested differently than it would if it were going to be an extra domain controller in an existing domain.

The switches that you use to tell the Domain Controller Diagnostic Utility how the new domain controller will fit into the existing Active Directory structure are self explanatory for the most part. The switches are:

/NewForest
/NewTree
/ChildDomain
/ReplicaDC

For example, if you wanted to use the server as an extra domain controller in an existing domain named Contoso.com, then the command’s full syntax would be:

DCDIAG /test:DCPROMO /DNSDomain:Contoso /ReplicaDC

One caveat that I do want to mention is that if you use the /NewTree switch, then you will have to use a third switch named /ForestRoot. Simply follow the /ForestRoot switch with a colon and the name of your root domain (/ForestRoot:Contoso.com)

DNS

It is easy to think of the Domain Controller Diagnostic Utility as a mechanism for running diagnostic tests against your domain controllers. Even so, this utility comes with a whole series of tests designed to help you to diagnose problems with your DNS servers. This should really come as no surprise. After all, the Active Directory is completely dependent on the Domain Name Services, and the first domain controller in a forest is usually configured to act as a DNS server.

The DNS test is actually made up of quite a few individual tests, any of which can be performed individually. If you choose to call the DNS test without specifying any additional switches, then the Domain Controller Diagnostic Utility will run all but one of the sub tests. The test that gets skipped involves resolving external domain names. I will talk more about this test in a moment. Before I do, I want to give you a list of the tests that are performed when the DNS test is run without any extra switches. Figure A shows what some of the default DNS tests look like when executed.

Figure A

Figure B: This is what it looks like when you perform a default DNS test

Earlier, I mentioned that the only test that is not run by default when you specify that you want to test the DNS configuration is the external name resolution test. There are a few switches that you can use if you want to run the external name resolution test though.

One option is to use the /DNAAll switch. This switch tells the Domain Controller Diagnostic Utility to run all of the DNS related tests, including the external name resolution test. The full syntax of this command is:

DCDIAG /TEST:DNS /DNSAll

You also have the option of explicitly calling the external name resolution test rather than just bundling the test with every other DNS related test that the Domain Controller Diagnostic Utility can run. If you want to explicitly call the external name resolution test, then you can do so by specifying the /DNSResolveExtName switch.

In case you are wondering, the external name resolution test attempts to resolve the domain name Microsoft.com. You can however, specify a different external domain name to be resolved by adding the /DNSInternetName switch, in conjunction with the name that you want to resolve.

SysVolCheck

One of the simpler tests that the Domain Controller Diagnostic Utility can perform is the SysVolCheck. This test performs  some basic tests against various Active Directory partitions including the forest DNS zones, the domain DNS zones, the schema, the configuration partition, and on the domain partitions. You can see what the SysVolCheck test looks like when executed in Figure C.

Figure C

The SysVolCheck test performs some initial connectivity tests, and then tests the various Active Directory partitions.

FrsEvent

The last test that I want to mention in this article is the FRSEvent test. In Windows FRS refers to the File Replication Service. As such, this test checks to see if the File Replication Service is experiencing any operational errors. This is important, because if the FRS is malfunctioning, then the domain controllers can become out of sync, which can cause policies not to be applied properly until the problem is fixed.

Conclusion

In this article, I have discussed a few more tests that you can run by using the Domain Controller Diagnostic Utility. In the next article in this series I will show you some more tests that you can run.

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

• Working With the Domain Controller Diagnostic Utility (Part 1)
• Working With the Domain Controller Diagnostic Utility (Part 2)
• Working With the Domain Controller Diagnostic Utility (Part 3)
• Working With the Domain Controller Diagnostic Utility (Part 5)
• Working With the Domain Controller Diagnostic Utility (Part 6)