Windows 2003 DCDIAG DNS failed test Connectivity


I am  currently in the process of installing Exchange 2003 on a Windows 2003 server. One of the deployment steps asks to run dcdiag. I keep getting the error that I failed the connectivity test for the DNS server. How can I fix this? Or can I skip this and just proceed with the Exchange install?

Here are some things to note:
>My TCP/IP setting has the Preferred DNS Server set to itself (
>There are forwarders set up in dnsmgmt to point to the dns servers of my ISP.

Please help!

Here is the log from dcdiag:


Domain Controller Diagnosis

Performing initial setup:
   Done gathering initial info.

Doing initial required tests

   Testing server: Default-First-Site-Name\SVCTAG-155XNL1
      Starting test: Connectivity
         The host f9018b1b-bcf0-4309-911f-68f4caea94a6._msdcs.WBI_DOMAIN2 could
not be resolved to an
         IP address.  Check the DNS server, DHCP, server name, etc
         Although the Guid DNS name
         (f9018b1b-bcf0-4309-911f-68f4caea94a6._msdcs.WBI_DOMAIN2) couldn't be
         resolved, the server name (svctag-155xnl1.WBI_DOMAIN2) resolved to the
         IP address ( and was pingable.  Check that the IP address
         is registered correctly with the DNS server.
         ......................... SVCTAG-155XNL1 failed test Connectivity

Doing primary tests

   Testing server: Default-First-Site-Name\SVCTAG-155XNL1
      Skipping all tests, because server SVCTAG-155XNL1 is
      not responding to directory service requests

   Running partition tests on : ForestDnsZones
      Starting test: CrossRefValidation
         ......................... ForestDnsZones passed test CrossRefValidation

      Starting test: CheckSDRefDom
         ......................... ForestDnsZones passed test CheckSDRefDom

   Running partition tests on : DomainDnsZones
      Starting test: CrossRefValidation
         ......................... DomainDnsZones passed test CrossRefValidation

      Starting test: CheckSDRefDom
         ......................... DomainDnsZones passed test CheckSDRefDom

   Running partition tests on : Schema
      Starting test: CrossRefValidation
         ......................... Schema passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... Schema passed test CheckSDRefDom

   Running partition tests on : Configuration
      Starting test: CrossRefValidation
         ......................... Configuration passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... Configuration passed test CheckSDRefDom

   Running partition tests on : WBI_DOMAIN2
      Starting test: CrossRefValidation
         ......................... WBI_DOMAIN2 passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... WBI_DOMAIN2 passed test CheckSDRefDom

   Running enterprise tests on : WBI_DOMAIN2
      Starting test: Intersite
         ......................... WBI_DOMAIN2 passed test Intersite
      Starting test: FsmoCheck
         ......................... WBI_DOMAIN2 passed test FsmoCheck
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Hey Tom,

First off, what is SVCTAG-155XNL1 and is it a domain controller? If it isn't, what computer is your domain controller? WBI_DOMAIN2? This server certainly

A basic primer: DNS is the core of modern Windows networks (even more so than other networks, as DNS is used in several ways to organize and access Windows domain information). The DNS server role should be installed on your domain controller (or on *a* domain controller). The domain controller should have its DNS pointed at itself ( as primary DNS in the network card) and should have the forwarders set to your ISPs DNS servers. All of the computer in your organization should *only* have the domain controller's IP in their DNS settings. DO NOT put DNS settings in for servers outside your local network (this is what the forwarders on the DNS server are for) or you will be querying external servers for internal names half of the time which will cause all kinds of "ghost-in-the-machine" types of behavior (read: havoc).

Once you have tried all of this, go to a client computer (not the server), double-check that his DNS settings are only pointed at the domain controller/DNS server's IP (should be the same if your network is a single-server one as I described above), and go into the command prompt (run "cmd.exe"). Type "nslookup", then enter, then "". If it comes back saying the address of as shown below, then that's a good sign that your DNS is querying your server, which is successfully looking it up using its forwarders, then replying to your request. It will look more or less like so if it's successful:

C:\Documents and Settings\Username>nslookup
Default Server:  DomainControllerComputerName.wbi.local

Server:  DomainControllerComputerName.wbi.local

Non-authoritative answer:

If you get an error or don't get's address. Check over my instructions above and/or reply and we'll get that sorted out.

Now that you've done that check, go in to DNS management and see if "SVCTAG-155XNL1" is listed under your domain (you may have set yours to be, for ex., wbi.local, judging by your user name & server name). If "SVCTAG-155XNL1" is not listed in DNS under your domain name, then there is no record and DNS lookups for that computer are failing. The other problem may be that, as suggested above, "SVCTAG-155XNL1" is not actually a domain controller. DCDiag stands for Domain Controller Diagnostics, meaning you need a domain controller and its associated domain properly set up for it to work.

The domain controller sets up a structure called Active Directory, the name of which is, in effect, your local domain name (i.e. wbi.local) or can be your external domain (i.e. if you've got it set up as such (the former is usually the case). Active Directory contains all of the user accounts and many internal Windows accounts, credentials, and myriads of other information that allows a Windows server to manage its client servers (read: "your network of computers"). Exchange relies on this information being accessible in order to function properly which is why they are having you run DCDIAG as a quick check of this accessibility to ensure you have your domain set up properly (at least as far as Exchange is concerned... as DCDIAG is not the be-all-end-all of tests by any means).

Let me know how you do with this...


While you can get Exchange to work, it's highly unrecommended and almost certainly not supported (and it'll likely break in all

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Err... one mistake: "Client servers" was supposed to be "clients" ;-)
Tom_wbiAuthor Commented:
A lot of the things listed in this answer were already done.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2003

From novice to tech pro — start learning today.