Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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:
dc1.example.local
dc2.example.local

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("10.0.0.1", 389);
Error <0x51>: Fail to connect to 10.0.0.1.
ld = ldap_open("10.0.0.2", 389);
Error <0x51>: Fail to connect to 10.0.0.2.
ld = ldap_open("10.0.0.1", 3268);
Error <0x51>: Fail to connect to 10.0.0.1.
ld = ldap_open("10.0.0.2", 3268);
Error <0x51>: Fail to connect to 10.0.0.2.

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.

share|improve this question
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 '11 at 21:15
    
BTW, I love the misspelling in the dcdiag output. –  wfaulk Aug 25 '11 at 20:34
    
Are you getting any error messages/events on the DC's? –  Grizly Aug 31 '11 at 16:26
    
@Grizly: Not that I've seen, no. –  wfaulk Aug 31 '11 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 Steel Sep 15 '11 at 8:28

5 Answers 5

up vote 2 down vote accepted

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.

share|improve this answer

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

Update:

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.)

share|improve this answer
    
Like I said, LDAP connectivity to the DCs works fine. –  wfaulk Aug 3 '11 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 '11 at 21:56
    
Good info. I'll doublecheck both of those things. –  wfaulk Aug 3 '11 at 22:26
    
Anyone know if non-existent PTR records for the DCs would be a problem? –  wfaulk Aug 5 '11 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 '11 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?

share|improve this answer
    
Nope, DNS definitely pointing to the DCs. I think the fact that the LDAP SRV lookup worked confirms that. –  wfaulk Aug 3 '11 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 '11 at 20:52
    
yep. resolves to the two DCs' IP addresses. –  wfaulk Aug 3 '11 at 20:57
    
I'm out of ideas! Good luck to you! –  Alan Aug 3 '11 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?

share|improve this answer
    
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 '11 at 13:41
    
Sorry, I missed that part. –  joeqwerty Aug 4 '11 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 '11 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?

share|improve this answer
    
Interesting guess, but no. –  wfaulk Aug 24 '11 at 3:04

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.