Re: Error: can't find _ldap._tcp.dc._msdc.<DNSDomainName>

Ron wrote:
Hi Kevin,

<answered inline>


This is information that should have been in your original post,
which didn't give a good description of the real problem. Knowing
this now, I don't think the problem is with the server, it is with
the binding order of
the VPN.
Let me get this right, you are trying to join remote computers to a
domain over a VPN?

Yes, some of the computers ( the ones with problems) are in remote
locations, joining the main site via Router based VPNs

Hello Ron,

Thanks for this posting it clears up a lot of questions, I will attempt to
help you as much as I can based on the info you posted. I've tried to be as
concise as possible, but it did get a little lengthy.


The DNS server name as listed in the DNS manager is cda.cdaxxxx.org.uk
this name is also registered with our internet registrar so the name
will resolve to the outside address of the central site's router when
called from the internet, It should also resolve to its internal
value 192.168.2.10 when called from inside the LAN or from a VPN
connected workstation.

To start with, and I'll help you understand why, the AD domain name MUST
resolve to the Domain Controller's IP address (the IP that has file sharing
enabled on it) for all domain members, no exceptions. JFYI, the reason the
AD domain name must resolve to the DC's address is for group policies at
\\cda.cdaxxxx.org.uk\sysvol and logon scripts at
\\cda.cdaxxxx.org.uk\NETLOGON. If you allow the remote clients to get the
external address of your router for the domain name, they will attempt to
connect to the router with many ports that should not be open to find the AD
services. (And you certainly don't want them open)

The internal IP also has alternate names, CDA and CDA-SERVER the
former is also the workgroup name and cda-server is the simple form
of the hostname, so cda.cdaxxxx.org.uk is equivalent to cda-server
and cda-server.cda.cdaxxxx.org.uk

Is that how things are supposed to be ?

With the exception of the public DNS publishing the router's IP for the
internal AD name, it is.


Does each remote client have its own VPN connection?

Yes and No, Some workstations have a software VPN running on the
workstation tunnelling to the central-site router, others have a
hardware VPN running between the remote Router and the central-site
Router. The Software tunnel type seems OK as I have set the PC's
preferred DNS server setting to point to the DC (using the internal
IP address) on the other site, the secondary DNS address is pointing
at the local ADSL router.

This part "the secondary DNS address is pointing at the local ADSL router."
is not OK for domain members. All DNS servers, in all positions, on all
interfaces, must be the DNS server that supports the AD Domain. This means
the ADSL router cannot be used as an alternate DNS for any AD domain
members.
I can see this is going to put you between a rock and a hard spot, should
the link be down, you would need a separate hardware profile in this case,
and the user will have to logon with a local account as long as a network
connection is available. Even then, you will see an extended startup time on
the Workstation while it searches for a DC.


Are the VPN connections on the same or different subnet from the
local network (at the remote site) when connected?

The LAN - LAN ones have to be on different subnets but they can see
and use the Exchange server service when in peer to peer mode, The
network addresses are the same when trying to attach as a domain
client. so the routers do appear to be routing correctly for general
workstation - workstation /
peer - peer purposes

Software VPN connected workstatuons are given a central site subnet
address when the connection is established, they use this to connect
to the central site or their native one to connect to local devices,
like local network connected printers.

On each of the remote clients right click on Network Places, choose
properties, in the Advanced menu select Advanced settings, move the
VPN connection to the top of the connections list. This makes the
VPN the default Network adapter, then the DNS servers configured on
it will become your default DNS servers.

Yet mors hidden gems revealed !
Thanks I didn't know that the connections themselves could be
prioritised in that way.
Hmmm . . . .
I've just tried that and found one entry for LAN connections, and
one for (Remote Access connections) - the latter does not appear to
have any Binding info, and the their are no VPN entries - even though
I have 6 configured ( for six different client networks)

Six VPN connections?
This might be a catch-22 What kind of VPN client software do you use?
You will need the Connection to the AD domain Network at all times when
logged on from a domain member. I am not sure about how to configure your
particular VPN Client connection. If it is the Windows VPN client, it is a
matter of clearing the check box, "Use default gateway on remote network"
on the VPN to the AD network.
Clearing this box, prevents additional VPN connections from going through
the remote router when you connect them concurrently. This setting is here:
VPN properties, Networking tab, TCP/IP properties, Advanced button, General
Tab.



I've just tried ipconfig /all, the Primary Dns Suffix is shown as my
DC: cda.cdaxxxxx.org.uk
and the Suffix search list has the same, followed by cdaxxxxx.org.uk
and org.uk.

Yes, the DNS suffix search list, is the default behavior of the DNS Client
service in Windows, this does create a problem for your network. When you
try to resolve any name not ending with a trailing "." the DNS client (and
Nslookup) will search down through the suffixes, slowing resolution and
creating a problem if it cannot contact the internal DNS before it fails
over to the ISP's DNS.
The resolution is twofold, assign a custom DNS suffix search list to all
your clients with cda.cdaxxxx.org.uk only. Then do not allow your AD domain
clients access to an external DNS server to resolve any name.

The reason why your getting the wrong name when you start nslookup, is
when
you created the A record you did not clear the check box for "create
associated PTR record" which created a PTR for the host you created, which
is also the DNS server's IP.

Can I clear these unwanted PTR records,?

Yes.

more importantly How do i know which ones to delete and which ones I
need ?

Reverse lookups are only important to public SMTP servers and Nslookup, you
can delete all of them. The DHCP client service (required service for DDNS
clients whether they are Static or DHCP clients) will re-register the PTR
records when you run ipconfig /registerdns, at reboot, or when the IP is
re-leased from the DHCP server on DHCP clients.


also to re-pose my initial question, perhaps now in better context,
when attempting to join the domain for the first time, what domain
name should i be using ?

I have the choice of :

CDA

This is the NetBIOS Domain name? If it is, you may use this name if you have
NetBIOS resolution at all sites. You have said nothing about WINS, but in
your infrastructure you should be using WINS, if you have not set up a WINS
server, do so, it make things a lot easier. Don't worry about WINS, it is
easy to set up, and requires few system resources.

CDA-Server<--No, this is not a valid name for your domain, it is a NetBIOS
name of your DC.

cda.cdaxxxx,org.uk<--Yes, this is your AD DNS name

cda-server.cda.cdaxxxx.org.uk<--No, this is the DNS name of your DC, not
the AD Domain name.


Internally on the LAN, CDA works, from my software VPN i needed to use
cda.cdaxxxx.org.uk

This is likely due to the Lack of a WINS server, so you have no NetBIOS
resolution. This is compounded by the fact that you have an External DNS in
TCP/IP properties, and invalid suffixes in your DNS suffix search list for
the AD domain. The DNS suffix search list should only have names that exist
as zones in your local DNS.

Your infrastructure can be made to be very reliable, I have a similar setup
myself. There are some keys to making it work.

1. Install WINS, and assign the WINS server's address to all internal
interfaces, easily done with DHCP.
2. Configure the AD zone in DNS on the WINS tab of zone properties, to check
the WINS server for unknown host names, the reverse zone can do the same
using WINS-R.
3. Do not allow any domain member access to DNS servers that do not support
the AD domain.



--
Best regards,
Kevin D. Goodknecht Sr. [MVP]
Hope This Helps
===================================
When responding to posts, please "Reply to Group"
via your newsreader so that others may learn and
benefit from your issue, to respond directly to
me remove the nospam. from my email address.
===================================
http://www.lonestaramerica.com/
http://support.wftx.us/
https://secure.lsaol.com/
===================================
Use Outlook Express?... Get OE_Quotefix:
It will strip signature out and more
http://home.in.tum.de/~jain/software/oe-quotefix/
===================================
Keep a back up of your OE settings and folders
with OEBackup:
http://www.oehelp.com/OEBackup/Default.aspx
===================================


.