In the last two months, I have discussed some of the finer points of DNS troubleshooting. In this issue, I'm going...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
to introduce you to a very cool DNS tool that has been added to the old DCDiag.exe that you no doubt have used in the past to assess a domain's health. This new version of DCDiag is available in the Windows Server 2003 SP1 support tools on Microsoft's website.
The DCDiag tool must be run on a Windows Server 2003 server or a Windows XP workstation but there can be Windows 2000 servers, DCs and clients in the domain. The example shown later in this article shows the result of this command run in a Windows 2000 domain
Introduction to DCDiag /Test:DNS
Microsoft has stated that one of the biggest call generators their support engineers face is that of misconfigured DNS environments. We aren't talking rocket science here (no deep dark secrets or unreported bugs). Just simple stuff – delegations pointing to the wrong server, TCP/IP properties of DCs not pointing to the right DNS server (perhaps a DNS server's IP address changed), or the always popular disabling of dynamic updates.
The problem, of course, is in a complex environment of many sites and DCs and a multiple domain model, with several Admins in different timezones, it gets difficult to keep track of changes. In order to help their support engineers as well as customers, Microsoft developed a very powerful option to the DCDiag.exe tool that has the ability to test the entire environment and report on the DNS "health" of each DNS server in every domain in the forest. Besides providing detailed information on every error related to DNS configuration, it includes a summary at the end that is a simple table listing the DNS servers and the various tests, with a Pass, Fail, or Warn in each field. This gives you a quick snapshot of the health of the entire DNS structure, along with sufficient error detail to allow you to resolve the problems.
Let's look at the command syntax. The command is:
The options are:
/e all DCs in the forest
/a all DCs in a site
(focuses on a single DC)
(pipe to a log file)
There are six (6) basic tests that can be run separately or together. You can specify individual tests to run:
DCDiag /Test:DNS /
The tests are:
/DnsBasic (this is a basic connectivity test and is always run)
If you don't specify any switch, it will run all tests except the DnsResolveExtName test.
In my experience to this point with this tool, I've always run all the tests. It may make sense if you narrow the problem down to a forwarder on one server, to create a command to specify the /S: switch with the DC name and just run the forwarder test, but I've never used it.
Here is a sample output from a pretty broken domain. (the names have been changed for security reasons). The command we used is simple:
Dcdiag /test:DNS /v /e /f:dnstest.txt
Note: You can also use >dnstest.txt rather than the /f: option if you prefer.
Let's start with the summary. This will be the last thing done and will appear at the end of the file:
One very cool thing about the summary that is actually a by-product of the command, is that it lays out the entire domain structure (lists all the domains) and all the DCs in each domain. I'm not aware of a faster way of getting this information, so even if that's all you use it for, I think it has great value.
In this example we see that there are three domains – company.com, NA.company.com and SA.company.com, and we see all the DCs associated with each domain. The tests, in order from left to right are Authentication, Basic (connectivity), Forwarders, Delegation, Dynamic Updates enabled, Resource Record Registration, and External Name test. Further we can see there are a LOT of Warn and Fail reports. Note that there are some N/A entries in the table. They are listed for every server for the External Name test since it is not run by default. The N/A entry normally means that the test is dependant on a previous component being available, and the test is not run since the dependency would cause it to fail.
Note that NA-DC21 and all the DCs in the SA domain report PASS on the Authentication test but FAIL on the BASIC (connectivity) test. Thus the other tests are not run and flagged with the n/a status.
Resolving the Errors
The actual output in this example is several pages long due to the errors. However some sample errors are shown here. If we focus on NA-DC1, for example we see it fails the forwarder test and gets a warning on the Basic Connectivity test. Looking in the results earlier in the report we see:
(Note that we have only included the Authentication, Basic and Forwarder tests, but you can see how these are the details for the entries in the summary table we saw previously. Where the table gave Warn, Pass, Fail, this part includes the details.)
TEST: Authentication (Auth)
Authentication test: Successfully completed
TEST: Basic (Basc)
Microsoft Windows 2000 Advanced Server (Service Pack level: 4.0) is supported
NETLOGON service is running
kdc service is running
DNSCACHE service is running
DNS service is running
DC is a DNS server
Network adapters information:
Adapter  WAN Miniport (IP):
MAC address is 00:53:45:00:00:00
IP address is static
IP address: 192.168.234.235
Warning: 127.0.0.1 (
) [Invalid (unreachable)] Adapter  Intel(R) PRO/1000 XT Network Connection:
MAC address is 00:06:5B:F7:A7:B4
IP address is static
IP address: 184.108.40.206
Warning: 220.127.116.11 (
The A record for this DC was found
The SOA record for the Active Directory zone was found
The Active Directory zone on this DC/DNS server was found (primary)
Root zone on this DC/DNS server was not found
TEST: Forwarders/Root hints (Forw)
Recursion is enabled
So in these tests we see nice details like the IP address and that it is static. In addition there are two network adapters, and the DNS server for one of them is using the loopback address which can't be resolved. There is a DNS server address specified for the second adapter that is invalid (thus the warning).
Further, in the forwarders test, we can see recursion is enabled (not necessary since we are using forwarders). We also see the cause of the Fail status. Both forwarders are reported as "Invalid". Looking at the summary we see that every DC is getting the Fail status on the forwarders test. Obviously the two IP addresses used for forwarders are not valid (likely the server's IP address changed and it was not updated in DNS).
With this kind of detail, we can work our way through the table - DC by DC - then re-running the DCDiag /test:DNS tool until everything passes. It should be obvious that this is much faster and more efficient than combing event logs on 50 DCs.
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers.