Weird AD / DNS Issue

T

twincountycomputers

Member
Reaction score
24
Location
Galax, Va
I've taken over support for a local company from a competitor and seem to have inherited a headache. Local computers can join the domain but I cannot join the domain from computers at another site via VPN (site-to-site hardware VPN, not software).

First thing I found is that the local computers were not set to use the DC as their primary DNS, after that local computers can join fine.

From the remote site I can ping the DC by IP and by hostname and I have the computer I'm testing with set to use the DC as it's only DNS server.

When I try to do the join I get an error saying the server is not set for delegation. dcdiag on the server itself returns a bunch of errors saying that xxxxxxxxxxxxxxxxxxxxxxxxxxx._msdcs.domain coult not be resolved to an IP address.

The server itself has 127.0.0.1 and it's local IP address as it's two DNS servers.

This customer has somewhat of a history also, at some point this domain was updated from a Windows 2000 server, and at one point this server was taken by the state police as evidence... long story...

Any ideas?
 
If computers on the network local to the server can join the domain, we can assume that the DC is running "healthy enough". Granted it may have some deeper issues....but those wouldn't be preventing remote satellite branch computers from connecting through the tunnel...if computers at the mothership office can join fine.

Although, don't need a 2nd DNS entry on that DC pointing to itself...lol.
And I'd square away the DHCP on the server so it's handing itself out for the one and only DNS for the network

Sounds like the VPN tunnel isn't setup well, not sure of how it's done, or how the remote satellite office routers are handling things. Depending on the hardware being used, there are different ways of handling the DNS for WANs, specifically when it comes to host names and DNS suffixes. All else fails, you can often force things through by jamming in the DNS suffix in the DNS properties of advanced TCP properties.
http://support.simpledns.com/KB/a137/how-to-configure-dns-suffixes-on-windows-2000xp2003.aspx

Sometimes, also depending on how the server was setup, and how the tunnels are setup, and DNS...I find sometimes you have to type in the full domain name when joining the domain..such as "mydomain.local"..instead of just "mydomain", or instead of the abbreviated name like "MD".
 
YeOldeStonecat said:
If computers on the network local to the server can join the domain, we can assume that the DC is running "healthy enough". Granted it may have some deeper issues....but those wouldn't be preventing remote satellite branch computers from connecting through the tunnel...if computers at the mothership office can join fine.

Although, don't need a 2nd DNS entry on that DC pointing to itself...lol.
And I'd square away the DHCP on the server so it's handing itself out for the one and only DNS for the network

Sounds like the VPN tunnel isn't setup well, not sure of how it's done, or how the remote satellite office routers are handling things. Depending on the hardware being used, there are different ways of handling the DNS for WANs, specifically when it comes to host names and DNS suffixes. All else fails, you can often force things through by jamming in the DNS suffix in the DNS properties of advanced TCP properties.
http://support.simpledns.com/KB/a137/how-to-configure-dns-suffixes-on-windows-2000xp2003.aspx

Sometimes, also depending on how the server was setup, and how the tunnels are setup, and DNS...I find sometimes you have to type in the full domain name when joining the domain..such as "mydomain.local"..instead of just "mydomain", or instead of the abbreviated name like "MD".
Click to expand...

the issue there is the other company named the domain "domain" not "domain.local" just "domain".... I've always used .local myself, could that be the problem?
 
Make sure the VPN clients are picking up correct DNS settings from DHCP (do they have local DHCP?) Try nslookup from a VPN machine and make sure it is querying the correct DNS server i.e. the HQ DC. In an ideal world the VPN branch offices would have a local DC.
 
twincountycomputers said:
the issue there is the other company named the domain "domain" not "domain.local" just "domain".... I've always used .local myself, could that be the problem?
Click to expand...

You mean there's no TLD? (like .biz or .local or .com?)

I've seen "domain.com"...yup, lol...an eye care center I picked up about 2 years ago. Prior tech dude named the local directory "domain". LMAO!
 
PCSComputerGuy said:
Shouldn't the DNS record be itself only. I have seen strange issues when using 127.0.0.1
Click to expand...

127. is itself. Microsoft has servers do that now if you run the wizards. I normally type in the IP address, 192.168.10.11 for example...but I've worked on enough servers that also just do the loopback and I've not seen issues.

The remote site would have to be a different IP range..since VPN tunnels typically require that on opposite ends.
 
Code: 
C:\Users\Administrator.RTOV>dcdiag

Directory Server Diagnosis

Performing initial setup:
   Trying to find home server...
   Home Server = RTSERVER
   * Identified AD Forest.
   Done gathering initial info.

Doing initial required tests

   Testing server: Default-First-Site-Name\RTSERVER
      Starting test: Connectivity
         The host 2a404c52-f8a2-4f67-8e67-9e5706af45a6._msdcs.RTOV could not be
         resolved to an IP address. Check the DNS server, DHCP, server name,
         etc.
         ......................... RTSERVER failed test Connectivity

Doing primary tests

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


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

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

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

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

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

   Running enterprise tests on : RTOV
      Starting test: LocatorCheck
         ......................... RTOV passed test LocatorCheck
      Starting test: Intersite
         ......................... RTOV passed test Intersite
 
YeOldeStonecat said:
127. is itself. Microsoft has servers do that now if you run the wizards. I normally type in the IP address, 192.168.10.11 for example...but I've worked on enough servers that also just do the loopback and I've not seen issues.

The remote site would have to be a different IP range..since VPN tunnels typically require that on opposite ends.
Click to expand...

I know that 127 is the loopback... I have had AD oddities on server 08 that were resolved by using the actual IP... I couldn't come up with a reason reason why but just something for him to try.

Also, I remember having to do something in AD/DNS in order to get remote VPN sites to connect... I don't remember what now but was hoping someone else had done it more recently than I.
 
PCSComputerGuy said:
Also, I remember having to do something in AD/DNS in order to get remote VPN sites to connect... I don't remember what now but was hoping someone else had done it more recently than I.
Click to expand...

There is AD Sites and Services, where you setup different subnets of remote sites, but that is IF you have a DC at the remote sites. It's not necessary, but it steamlines replication to deal with the slow link.
 
As a temporary workaround, you might try adding the IP address and name o the server to the HOSTS file (in \WIndows\system32\drivers\etc.. If this works, then you need to work on getting the VPN able to resolve named addresses.

Having a domain with a single name is, from what I've read, not a good thing. You should look into what options you have to change it to something like "domain.local".
 
HankArnold said:
As a temporary workaround, you might try adding the IP address and name o the server to the HOSTS file (in \WIndows\system32\drivers\etc.. If this works, then you need to work on getting the VPN able to resolve named addresses.

Having a domain with a single name is, from what I've read, not a good thing. You should look into what options you have to change it to something like "domain.local".
Click to expand...

yes, long-term before we add any more remote computers to the server I think starting from scratch is the best option, only problem is there are 20 or so computers joined to this domain at the moment, but that is better than the 60 or so total when the 4 small remote sites are linked.

I have tried the DNS with and without the 127 loopback address.
 
twincountycomputers said:
yes, long-term before we add any more remote computers to the server I think starting from scratch is the best option, only problem is there are 20 or so computers joined to this domain at the moment, but that is better than the 60 or so total when the 4 small remote sites are linked.

I have tried the DNS with and without the 127 loopback address.
Click to expand...

Could always do a domain rename. Not bad unless Exchange is in the mix, and even then it's usually not terribly bad.
 
quick update on this in case anyone else comes up with this.

I eventually reloaded the server over one weekend and created a new domain linking all 25 pc's back to it. Were now in the process of linking another 25 or 30 computers to the domain at the 4 smaller sites. After reloading the server (and using a domain with .local) the domain join is working fine with NO changes to the VPN hardware.

The culprit could have been one of many things, either the lack of a tld on the domain name, screwy dns configuration, something corrupt with the registry, who knows, but the users all seem to agree that things run a lot faster now that it is reloaded.

The funny part is that after I spent all weekend on-site doing the reload, re-joining all the pc's, copying profiles, etc, etc, now they are talking about a new server if they have the funds in the budget before the fiscal year is up at the end of this month.
 
You must log in or register to reply here.

Similar threads

thecomputerguy
Weird DNS Issue ...
Replies
2
Views
591
YeOldeStonecat
YeOldeStonecat
thecomputerguy
Can I use a UDM-Pro as a controller ONLY?
Replies
1
Views
263
phaZed
phaZed
HCHTech
Slow opening times for files on a network drive
Replies
10
Views
884
trevm999
trevm999
HCHTech
Hyper-V - Moving VM to a new host
Replies
6
Views
407
britechguy
britechguy
thecomputerguy
Have to restart Server DNS every time we try to send a dental case.
Replies
16
Views
1K
thecomputerguy
thecomputerguy
Back
Top