I am trying to connect a Windows 7 Ultimate machine to a Windows 2k8 domain and it's not working. I get this error:

Note: This information is intended for a network administrator. If you are not your network's administrator, notify the administrator that you received this information, which has been recorded in the file C:\Windows\debug\dcdiag.txt.

DNS was successfully queried for the service location (SRV) resource record used to locate a domain controller for domain "example.local":

The query was for the SRV record for _ldap._tcp.dc._msdcs.example.local

The following domain controllers were identified by the query:

However no domain controllers could be contacted.

Common causes of this error include:

  • Host (A) or (AAAA) records that map the names of the domain controllers to their IP addresses are missing or contain incorrect addresses.

  • Domain controllers registered in DNS are not connected to the network or are not running.

The client is in an office connected remotely via MPLS to the data center where our domain controllers exist. I don't seem to have anything blocking connectivity to the DCs, but I don't have total control over the MPLS circuit, so it's possible that there's something blocking connectivity.

I have tried multiple clients (Win7 Ultimate and WinXP SP3) in the one office and get the same symptoms on all of them.

I have no trouble connecting to either of the domain controllers, though I have, admittedly, not tried every possible port. ICMP, LDAP, DNS, and SMB connections all work fine.

Client DNS is pointing to the DCs, and "example.local" resolves to the two IP addresses of the DCs.

I get this output from the NetLogon Test command line utility:

C:\Windows\System32>nltest /dsgetdc:example.local
Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

I have also created a separate network to emulate that office's configuration that's connected to the DC network via LAN-to-LAN VPN instead of MPLS. Joining Windows 7 computers from that remote network works fine.

The only difference I can find between the two environments is the intermediate connectivity, but I'm out of ideas as to what to test or how to do it. What further steps should I take?

(Note that this isn't actually my client workstation and I have no direct access to it; I'm forced to do remote hands access to it, which makes some of the obvious troubleshooting methods, like packet sniffing, more difficult. If I could just set up a system there that I could remote into, I would, but requests to that effect have gone unanswered.)

2011-08-25 update:
I had DCDIAG.EXE run on a client attempting to join the domain:

C:\Windows\System32>dcdiag /u:example\adminuser /p:********* /s:dc2.example.local

Directory Server Diagnosis

Performing initial setup:
   Ldap search capabality attribute search failed on server
   dc2.example.local, return value = 81

This sounds like it was able to connect via LDAP, but the thing that it was trying to do failed. But I don't quite follow what it was trying to do, much less how to reproduce it or resolve it.

2011-08-26 update:
Using LDP.EXE to try and make an LDAP connection directly to the DCs results in these errors:

ld = ldap_open("", 389);
Error <0x51>: Fail to connect to
ld = ldap_open("", 389);
Error <0x51>: Fail to connect to
ld = ldap_open("", 3268);
Error <0x51>: Fail to connect to
ld = ldap_open("", 3268);
Error <0x51>: Fail to connect to

This would seem to point fingers at LDAP connections being blocked somewhere. (And 0x51 == 81, which was the error from DCDIAG.EXE from yesterday's update.) I could swear I tested this using TELNET.EXE weeks ago, but now I'm thinking that I may have assumed that its clearing of the screen was telling me that it was waiting and not that it had connected.

I'm tracking down LDAP connectivity problems now. This update may become an answer.

  • 3
    Given that DNS appears to be working, I would suggest sticking NetMon or Wireshark on both ends and capturing the packets to see what is happening on the wire.
    – ITHedgeHog
    Aug 3, 2011 at 21:15
  • BTW, I love the misspelling in the dcdiag output.
    – wfaulk
    Aug 25, 2011 at 20:34
  • Are you getting any error messages/events on the DC's?
    – Grizly
    Aug 31, 2011 at 16:26
  • @Grizly: Not that I've seen, no.
    – wfaulk
    Aug 31, 2011 at 17:09
  • Have you access to any network devices in between the workstations and the servers? You'd want to check their filtering/connection logs and see if any of them are dropping/filtering packets from/to the workstations.
    – Ashley
    Sep 15, 2011 at 8:28

5 Answers 5


It took forever to find where it was happening, but it turns out that there were filters within the VPN blocking LDAP (and other) traffic. I cleared those filters and now it's working.


There could be a firewall between the Win7 machine and the domain controllers.

If you have access to nmap:

nmap -PN -p389 dc1.example.local dc2.example.local


nltest /dsgetdc:example.local

nslookup -q=srv _ldap._tcp.dc._msdcs.example.local  
nslookup -q=a $prefered_host  
ldapsearch -h $IPaddress_of_A_record -x -b "" -s base (&(DNSDomain=example.local)(HOST=$localmachineshostname)(NtVer=\\\\16\\\\00\\\\00\\\\00)) netlogon

NtVer is asking for V5 (version5 netlogon), V5EX(version 5 extened logon), VCS (closest dc). Taken from Win7Ent.

(ldap hex is trixy.)

  • Like I said, LDAP connectivity to the DCs works fine.
    – wfaulk
    Aug 3, 2011 at 21:18
  • My bad. Still all nltest does is 2 dns lookups and a cldap search. I'll update with behavior.
    – 84104
    Aug 3, 2011 at 21:56
  • Good info. I'll doublecheck both of those things.
    – wfaulk
    Aug 3, 2011 at 22:26
  • Anyone know if non-existent PTR records for the DCs would be a problem?
    – wfaulk
    Aug 5, 2011 at 18:28
  • Shouldn't be; every other machine joined without them. nltest doesn't look for them. Double check that the client can get the SRV record. Don't think MS DNS servers do split view, but running out of options.
    – 84104
    Aug 6, 2011 at 2:08

Sounds like the win7 is not pointing its DNS to a DC? Perhaps DHCP is pointing DNS to the internet providers DNS?

  • Nope, DNS definitely pointing to the DCs. I think the fact that the LDAP SRV lookup worked confirms that.
    – wfaulk
    Aug 3, 2011 at 20:50
  • can you ping the domain name without the hostname? for excample if the DC is DC1.mydomain.com can you ping mydomain.com from the win7 box?
    – Alan
    Aug 3, 2011 at 20:52
  • yep. resolves to the two DCs' IP addresses.
    – wfaulk
    Aug 3, 2011 at 20:57
  • I'm out of ideas! Good luck to you!
    – Alan
    Aug 3, 2011 at 20:58

It sounds like you've tried and tested everything as far as DNS is concerned but have you verified that the A records for the DC/DNS servers exist and are correct? What happens when you run nslookup testing both servers for the presence of the A records for both servers? Are the DC's returned in the error message actually the correct DC/DNS servers for the domain?

  • Given that joining the domain works fine from a different network, I don't think it's something as fundamental as that.
    – wfaulk
    Aug 4, 2011 at 13:41
  • Sorry, I missed that part.
    – joeqwerty
    Aug 4, 2011 at 13:51
  • Have you made sure that the traffic over the following ports is making it across the MPLS circuit: Microsoft-DS traffic (445/tcp, 445/udp) • Kerberos authentication protocol (88/tcp, 88/udp) • Lightweight Directory Access Protocol (LDAP) (389/udp) • Domain Name System (DNS) (53/tcp, 53/udp)
    – joeqwerty
    Aug 5, 2011 at 4:28

Is there a possibility that the client in the remote office only is running IPv6 and while it does find the SRV record for the DC, DNS is not configured with AAAA (IPV6) records?

  • Interesting guess, but no.
    – wfaulk
    Aug 24, 2011 at 3:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .