Why can't I join my test Windows Server 2012 R2 Domain

NEVER Use public Name seis versa in the network configuration.
The workstations make all requests for DNS information to the DNS service that runs inthe DC!

Your error is because the request to identify the DC responsible for your ADdomain name went to google, which responded with no such domain.
While DNS is setup to handle failover, a failover is a non answer, timeout, a no such domain does not tell the DNS resolver, hey how about you try the other.

This also causes issues in the server in the intitial phase when it needs to write data .......

From the client attempting to join the domain, what is the output of:

nslookup -type=a willowdental.willowdent.com.

Select allOpen in new window

Do you have the DC set as the DNS server for the client? It should contain no other DNS servers that are not hosting the willowdent.com DNS zone. Typically these are almost always DNS related issues, so rule that out first. Next would be to check connectivity to the DC. Do you have a host based firewall active on the client/DC preventing communication?

NEVER Use public Name seis versa in the network configuration.

There is no problem using a public name internally if the DNS environment is correctly configured in a split-brain configuration.

At Note second set of images where the name servers listed for the HOST that point to 8.8.8.8
This will cause problems for the AD DC resolution.

The question that must be answered when joining a domain is
nslookup -q=SRV _tcp._ldap.dc._msdcs.willowdent.com.

If you do not get an answer that includes your ori.willowdent.com as an answer, the ad join attempt will fail.

Ok gentlemen,
Let me try to summarize. I should omit all references to my server dns that are not 192.168.168.3. In other words, delete 8.8.8.8 and 8.8.4.4?
Yes or No

yes delete all but the ip of the dc 192.168.168.3.

Yes, the only DNS that your workstations should be using is the 192.168.168.3

You can inthe DC server ORI,'s DNS management configure forwarders that pint to 8.8.8.8 and 8.8.4.4 to offload the work fromYOUr DNS server to them.

Ok Gentlemen,

I removed all references to 8.8.8.8 and 8.8.4.4 from both the OR1 workstation and from the Server. I tried to join the domain again and received the following error when I typed in willowdental.com:


However, when I tried to join the domain with willowdent without the .COM, I was prompted for a username and password. I was getting excited that a solution was forth coming, but when I put the user name and password in, the process eventually timed out with the following error:

Please use the query I posted above to confirm your workstation get the outlined results.

Second, instead of clicking domain radio button, and entering info, use the more button and go through the wizard to join this workstation to the domain.

arnold, forgive me for be obutuse, but I understand your second request but not the first.

are you referring to this:  

The question that must be answered when joining a domain is
nslookup -q=SRV _tcp._ldap.dc._msdcs.willowdent.com.

I wrote "forgive me for be obutuse" , but I meant forgive me for being obtuse.

arnold,
I followed your second response stating:

instead of clicking domain radio button, and entering info, use the more button and go through the wizard to join this workstation to the domain.

I still received:

If sonething, comment raises question, concerns it's more than fine with me if clarification is needed.

Yes, the lookup is a way to locate a DC responsible for the AD domain.
If you get no answer, that means there is an issue, potentially with your server's Windows firewall.
1) make sure in network settings, make sure the server is on a domain, private, work network, it MUST not be on a public network. If it is public, this will explain the issue, meaning the Windows firewall is blocking requests on 445,389, etc.

You can use dism if memory servers to change the network classification from public.

My last screen shot was in error. I did indeed use the More button.

First question is do you get records in the response to the query?
If you did, confirm the server is seen in the work, private, domain network classification within the network center view.

The domain shoukd be fully identified willowdent.com
Not partially as you gave displayed in the image.

Pkease confirm the first two suggestions before working on the workstation.

I am curious about something. My reverse lookup screens shows


should not it be 168.168.192 instead of 3.168.168.192?

Hi Arnold,
are yo referring to the network profiles under network and sharing center???

arnold wrote:

First question is do you get records in the response to the query?
If you did, confirm the server is seen in the work, private, domain network classification within the network center view.


I can ping the server on the network. The server is indeed a domain controller. I don't believe I understand what you are asking me to do arnold. Pretend that I am a noobie (because I am) and dumb it down a little for me. I would really appreciate it. Possibly a step by step of what you want me to do.

Arnold,

When I try to turn on network discovery under the domain network profile and save it, it does not take. In other words:

 
It always reverts back to turn of network discovery.

What should I do about that??

you went one view too far. Look at the network and sharing center. How is the connection categorized?

Please post the output from running the following command on the server within a command window.
nslookup -q=SRV _tcp._ldap.dc._msdcs.willowdent.com.
Then if it returns info, pkease run the same query on the or4 workstation and see whether you get the same info.

As to your reverse zone, you gave an error
Add a new reverse zone 192.168.168 only which translates into 168.168.192.in-addr.arpa

An IP A.B.C.D is a reverse Zone where PTR records map the IP to the name (from the forward zone.
This is why the view us reversed least significant octet in this case D is an entry with inthe zone C.B.A.In-addr.arpa

3 In PTR  dcname.willowdent.com.

Make sure the reverse xk e is AD integrated.

arnold wrote:

"you went one view too far. Look at the network and sharing center. How is the connection categorized?"

arnold
Network discovery is now on for the domain profile:


I ran nslookup and here are the results:



arnold wrote:

As to your reverse zone, you gave an error
Add a new reverse zone 192.168.168 only which translates into 168.168.192.in-addr.arpa



I added the proper reverse zone to exclude the last octet.



Arnold,
I am still unsure about the following instructions:

3 In PTR  dcname.willowdent.com.

Make sure the reverse xk e is AD integrated

also I am not sure that within the reverse lookup that the following should be:


This cant be right. The Ip address is unknown

Hi arnold,

The network connection is not public. I have already made that change. The domain profile is the current network.  IN the forward zone , I do have an A record 192.168.168.3. On the OR4 workstation I ran ipconfig /flushdns and then ipconfig /registerdns.

I think I have covered all the bases, but I am still doing something dramatically wrong and I don't know what that is.

I still get non-existent domain from the nslookup command.


Frustrated a little bit. I will keep trying and researching the errors I am getting.

Double check the server and DNS settings to make sure it is bound
in DNS management interface, properties of the DNS server.
make sure it is bound to all interfaces

run the
ipconfig /registerdns

run netstat -an | find /i "listen"
do you have an entry with *:53 LISTENING?

what about ipconfig /all?

Make sure to add a period at the end of the query letter for letter as I posted it.
nslookup -q=srv _ldap._tcp.dc_msdcs.willowdent.com.

try this

nslookup -q=srv _ldap._tcp.dc_msdcs.willowdent.com. 127.0.0.1

If you get an answer, this would confirm that the only IP your DNS server is listening on is localhost.

Please post an image of the network and sharing center view.
The advanced sharing settings information is of little use when I am unclear which Network TYPE your system things it is in.
Work/Private
Domain
Public

Double checking now...

It's not clear to me if you have DNS setup properly on both the server and the workstation.  I've only seen one set of IPv4 configs and they look like they belong to the server.

Bottom line, forget the DNS management tool.  You shouldn't have to touch it.  If you did, you could be messing things up.
Instead, make sure on the server your IP settings point DNS ONLY to the server itself.  NO OTHER DNS SERVERS.
On the workstations, make sure the DNS is ONLY pointing to the server - NO OTHER DNS SERVERS.

Run IPCONFIG /ALL on BOTH the server and a problem workstation and post the results showing DNS config.

Then, from the workstation, ping the server by FQDN. if you get a reply, try to join the domain.  If that fails, look through your event log for warnings, errors, and criticals.

Good evening  Arnold,

I believe I have done the things you asked of me to try. Here is the order that I did them in:

msdcs.WILLOWDENT.COM view


WILLOWDENT.COM VIEW


Reverse-Lookup Zone view


Reverse Lookup Name Servers view


nslookup view


RegisterDns


netstat view

-07----NETST.TXT

Ipconfig /all view

-08----IPCON-all.TXT

ns lookup local host view


Network and sharing center  view


sharing options for different profiles


private guest and public profiles turned off

It seems your DNS service is setup and listens on all IPs, but has no answer.
The network is on the domain..

Look at the _msdcs.willowdent.com. Zone you have a DC, expand, drill down
_tcp
Then _ldap
There shoukd be an SRV reord that pints at willow dental.willowdent.com.

Recheck the SOA tab under the properties of each of your forward zones to make sure it points/resolves the willow dental.willowdent.com name to 192.168.168.3

Lee wrote:

It's not clear to me if you have DNS setup properly on both the server and the workstation.  I've only seen one set of IPv4 configs and they look like they belong to the server.
Bottom line, forget the DNS management tool.  You shouldn't have to touch it.  If you did, you could be messing things up.
Instead, make sure on the server your IP settings point DNS ONLY to the server itself.  NO OTHER DNS SERVERS.
On the workstations, make sure the DNS is ONLY pointing to the server - NO OTHER DNS SERVERS.
Run IPCONFIG /ALL on BOTH the server and a problem workstation and post the results showing DNS config.
Then, from the workstation, ping the server by FQDN. if you get a reply, try to join the domain.  If that fails, look through your event log for warnings, errors, and criticals.

Lee,
I am certain (or maybe not)  that the DNS is working. Based upon the responses that I received, I have removed all other dns settings except for the server , which is 192.168.168.3. The workstations that I am working on only have the one dns ipaddress  (192.168.168.3) associated with them.
I only created an MMC console so I could readily show those who are looking at this thread. I only have aduc and dns in them. I don't much around with dns unless an expert exchange member recommends it. I ran the ipconfig /all only on the server , but I will also post one of the workstations that I am working with. From any workstation , I can ping the fully qualified domain name of the server and vice versa. I will look at my log files and report back.

Arnold,
I am checking your last post to me. Stay tuned.

arnold wrote:

Look at the _msdcs.willowdent.com. Zone you have a DC, expand, drill down
_tcp
Then _ldap
There should be an SRV record that points at willow dental.willowdent.com.


Hi Arnold,

There is definately an SRV record pointing at willowdental.willowdent.com.



SOA is as follows:

As you can see the Primary server is: willowdental.willowdent.com.

try restarting the DNS server via the DNS management right click, tasks...

Then recheck the nslookup query
nslookup -q=SRV _tcp._ldap.dc._msdcs.willowdent.com.

You need it to answer before you can proceed.

Good morning arnold,

I agree with you a hundred percent. I tried all the above responses, but I should have been asking the person that I was creating this domain for what was the actual DNS. You see unbeknownst to me my friend  went with comcast to handle DNS and routing and DHCP. The original DNS's were from comcast.net. I found this out when I did a nslookup. it would only resolve to comcast.net , therebye preventing me from adding workstations to the domain. The DNS  configuration of 8.8.8.8 and 8.8.4.4 (or was it 4.4.8.8) were coming from comcast and all the clients were getting there ipaddresses dynamically from the comcast router. I don't know why it was configured this way,because I usually have the server give out ipaddreses and look to server for DNS. I told him he should have let me know about this before I began. Fortunately , this was not the production server. It was a new server that is slated to replace the old domain. He had to revert back to the old domain, so we can configure the new server with the proper DNS and,DHCP. I told him that since the comcast router was 192.168.168.1 , the users would still have access to the internet. THIS WAS A BAD CONFIGURATION.

I want to thank you for all of your input, because it allowed me to be familiar with Active Directory again. It heartening  to know that I did create the domain properly with your help. Much appreciated. I chose both you and Lee comments as the most helpful , but you were a trooper to go this far above and beyond. How do I award you the most points, as I see the point system isn't something that is available. As I said , Lee was helpful, but you were stellar. Is there a new way to award points. Please let me know ,so I can give credit where credit is due.

Pick the comment that solved the issue while selecting comments that were asssiting along the way. submit when done. The points are just that some points.