Unable to Join Domain

Mike McCall

Well-Known Member
Reaction score
1,072
Location
Silverton, Oregon
So, I'm trying to learn AD on Server 2012 and have AD DS installed. DNS Server is installed with the Ad.Dork-SCS domain. I've added myself as a user. Everything appears to be in order at the server end. However, when I attempt to join my laptop (Win7Pro) to the domain, it says the domain doesn't exist. It does say that the DNS server is the ip address of the router, but then, so does everything else on my network. Everything seems to work fine, except the ability to join the domain. Do I need to tell the laptop the DNS server is the actual server? If I do, will I lose internet connectivity? Have I neglected to enable something on the server?
 
Yes. Either manually input the IP address of the server as the DNS server on the laptop (easiest for testing) or have your router hand out the server address for the primary DNS. You would then also need to add your router IP address as a secondary DNS so other devices not joined to domain can get to the internet. (Ok for small offices.) In larger environments, let the server handle DHCP and DNS.
 
Ok, just to be sure...currently my router lists OpenDNS as both primary and secondary DNS servers. It also acts as my DHCP server. I can point my laptop to the Server ip for primary DNS, and leave the router ip as the secondary and I'll be fine.
 
The only DNS you should have on the LAN side is the M$ box otherwise you will have problems. You can have the server forward to OpenDNS, or whatever DNS you want to use, for requests it cannot handle. I'd also recommend that you have the server handle DHCP as well.
 
Thanks, Mark. The server is the only DNS on the LAN, the router points to the OpenDNS servers on the WAN side. That's why (for the laptop) it makes sense that it couldn't see the internal domain since it looked only to the router for DNS. Therefore, setting the primary DNS on the laptop to the ip of the server will allow it to find the internal domain, while setting the secondary DNS to the router will allow internet access.

I do understand that in most applications the server should handle DHCP. However, because I'm currently busy breaking the server so I can learn how to fix it, I don't want to take down my entire network when I (often) screw something up.
 
Mark beat me to it but in a Windows domain the domain server MUST repeart MUST act as your DNS server. Never use the router for that job. And if you run DHCP instead of static IPs then it needs to handle that as well.
 
Mike for your setup you need to use Static IPs instead of DHCP if you don't want down time. Make sure your server is the first DNS server and then make openDNS your backups.
 
Follow my tips in this thread here...think it was just yesterday.
https://www.technibble.com/forums/threads/100th-domain-is-giving-me-trouble.63356/

In my reply there, there is a link to an old article I wrote years ago at Speedguide.Net....check that link. Yes it's old SBS03 but the principles are still true.

Clients on a domain must use the domain controllers IP for their only DNS...nothing else....only time you use secondary is if you have more domain controllers.

The domain controller should run DHCP for the network too, not a router.
 
Looking back at my posts in this thread it may not be clear that this is a home network with a consumer router doing NAT translation and acting as a gateway. Behind that is a managed switch with everything from a Roku, to an Ooma VOIP, 2PC's, a Mac, NAS, Network Printer, and other devices as well as the server. Some devices I can give static ip's to, but others I can't. Other than my Mac, my laptop is the only device capable of joining a domain. Since the only reason I have a server at all is to serve as my learning lab, and I've taken the network down completely more than once, it made sense to me to let it handle DHCP (with reservations) so everything wouldn't go down if it took me awhile to get the server back up. Perhaps I'm missing something more important here?
 
If this is a lab environment to learn..and the laptop will be the only client on the domain, OK sure..leave DHCP on the router for the rest of your home LAN, and just manually assign the TCP/IP on your laptop. Lets say your router hands out 192.168.1.xxx via DHCP...from .100 up, make your server manually assigned outside the DHCP handout range...pick something like 192.168.1.10.

So Server...IP of 192.168.1.10, 255.255.255.0 subnet, gateway 192.168.1.1, and for its primary DNS...itself...192.168.1.10 (or 127.0.0.1 loopback).

Now for your laptop, give it something like 192.168.1.15, rest of the info is the same as the server..same subnet, gateway, and use the server for DNS...period.

Make sure you setup the DNS forwarders on the server, in dnsmgmt.msc (DNS management console)...refer to that prior link of mine.
 
Sounds reasonable. On my LAN all of my servers, 2 x OS X, 1 ESXi + VM's, 1 x FC12, 1 x WD DX4000 and 2 network printers are all fixed IP. I setup my DHCP with just 25 seats for DHCP for laptops.
 
If this is a lab environment to learn..and the laptop will be the only client on the domain, OK sure..leave DHCP on the router for the rest of your home LAN, and just manually assign the TCP/IP on your laptop. Lets say your router hands out 192.168.1.xxx via DHCP...from .100 up, make your server manually assigned outside the DHCP handout range...pick something like 192.168.1.10.

So Server...IP of 192.168.1.10, 255.255.255.0 subnet, gateway 192.168.1.1, and for its primary DNS...itself...192.168.1.10 (or 127.0.0.1 loopback).

Now for your laptop, give it something like 192.168.1.15, rest of the info is the same as the server..same subnet, gateway, and use the server for DNS...period.

Make sure you setup the DNS forwarders on the server, in dnsmgmt.msc (DNS management console)...refer to that prior link of mine.

Perhaps knowing the application of the server and its environment has helped some. I'm reading the page you linked to and I understand (mostly) why one would set things up that way. In my application I chose to continue using the router for DHCP, though I use reservations, specifically to isolate the server. Everything worked fine until today when I attempted to join my laptop to the new domain. So, now everything appears to be working as it should, but apparently only because the secondary DNS server designated on the laptop points back to the router instead of to the server as the primary does. So, it appears that my next steps are to learn about and setup DNS forwarders on the server and point both the primary and secondary DNS on the laptop to the server.

As for addressing, currently .1 is the router, .2 is the switch, .3 is the server .4 - .8 are workstations, .9 is a printer, .11 - .13 are wifi devices, .101 and .102 are the Roku/Ooma VOIP respectively. This is wrong? I have some reading to do.
 
It's making sense..what you're doing...so just to double check, the laptop is the only one you want to join the domain?
With active directory...it's all build on top of DNS. Your server(s) is a domain controller. It needs to run on top of DNS, which is why servers that are DCs run DNS themselves..and need to look at themselves for DNS. Clients needs to look at the server(s) for DNS..since they need to communicate with active directory thus have to go through the server, register with the server, and all that DNS ties together. Without that DNS from the domain controller(s)...active directory between the servers, themselves, and the clients...cannot function.

Your router has no idea about your server, or internal DNS...active directory, etc. Plugging in public DNS servers like your ISPs..or Googles...or safe DNS services....any public DNS server, they do not know about your active directory or your server and its DNS....so they cannot be of any use to the client workstations of your domain.

Some people like plugging in public DNS servers like the ISPs for secondary DNS...."in case the domain controller is down or not working". Well...first, a server should not be down. Second...this often leads to broken DNS...if not immediately...it can down the road. Workstations can start failing to register in your internal DNS properly and become orphaned, and domain controllers can do the same...since they stop communicating through that internal DNS. There is a timeout period when a workstation will query the primary DNS...not get an answer quick enough, and immediately query the secondary DNS. A poor performing server can fail to respond to DNS queries fast enough and cause the clients to turn to their secondary DNS....and the breaking of that important DNS communcation begins...typically unknown to the end user. Sure...workstations get internet access and all appears well..but really DNS is breaking internally.

So your servers DNS role needs to be there for both internal resolution (and active directory)...and also respond to queries for public domains (surfing the internet). This is where the DNS forwarders come into play (under DNSMGMT.MSC).

Time for me to take some time to write up a fresh article on doing this with a newer server....may take a few weeks but I'll do one and post it in the articles here.
 
It's making sense..what you're doing...so just to double check, the laptop is the only one you want to join the domain?
With active directory...it's all build on top of DNS. Your server(s) is a domain controller. It needs to run on top of DNS, which is why servers that are DCs run DNS themselves..and need to look at themselves for DNS. Clients needs to look at the server(s) for DNS..since they need to communicate with active directory thus have to go through the server, register with the server, and all that DNS ties together. Without that DNS from the domain controller(s)...active directory between the servers, themselves, and the clients...cannot function.

Your router has no idea about your server, or internal DNS...active directory, etc. Plugging in public DNS servers like your ISPs..or Googles...or safe DNS services....any public DNS server, they do not know about your active directory or your server and its DNS....so they cannot be of any use to the client workstations of your domain.

Some people like plugging in public DNS servers like the ISPs for secondary DNS...."in case the domain controller is down or not working". Well...first, a server should not be down. Second...this often leads to broken DNS...if not immediately...it can down the road. Workstations can start failing to register in your internal DNS properly and become orphaned, and domain controllers can do the same...since they stop communicating through that internal DNS. There is a timeout period when a workstation will query the primary DNS...not get an answer quick enough, and immediately query the secondary DNS. A poor performing server can fail to respond to DNS queries fast enough and cause the clients to turn to their secondary DNS....and the breaking of that important DNS communcation begins...typically unknown to the end user. Sure...workstations get internet access and all appears well..but really DNS is breaking internally.

So your servers DNS role needs to be there for both internal resolution (and active directory)...and also respond to queries for public domains (surfing the internet). This is where the DNS forwarders come into play (under DNSMGMT.MSC).

Time for me to take some time to write up a fresh article on doing this with a newer server....may take a few weeks but I'll do one and post it in the articles here.

Yes, the laptop is the only device I intend to join to the domain. I understand why the laptop needs to look to the server for DNS and therefore AD. I did not understand why pointing the secondary DNS on the laptop to the router is incorrect. Now that I understand that I should setup DNS Forwarding on the server and point both the primary and secondary DNS on the laptop should point to the server I'll work on that tomorrow. I have more to learn. Thank you!
 
Back
Top