Unable to Join Domain

[YeOldeStonecat]

You always want servers manually assigned TCP/IP addresses...especially with DCs...since you want the IP to be set during bootup, so that services such as DNS will load properly. If you have them "obtain auto"..even with a reservation from DHCP, the service will attempt to load before it ARPs and then pulls an IP, and the service like DNS will usuall fail.

Printers I prefer to do via DHCP reservation...so it's easy to manage them from right there...DHCP reservations is like a list documenting them for you so you know which is which.

 

[Mike McCall]

Ok, so this is all new information (which is very good) about ip addressing that I have not heard before. I've known that most consumer private ip addresses use 192.168.1.x, but figured there was no problem with that. After all, there's NAT translation at both ends isolating them from public view, and the packets have the destination address and port. Whatever took place at one end was independent of what took place at the other. If I understand what you're saying properly, this is still largely true...until we get to VPN.

So, if I understand this, when using a VPN the networks at each end must be different. If I'm at 192.168.1.5, and the office server I'm trying to reach is also at 192.168.1.5, the little packets get confused and don't know where to go? To put it another way, irregardless of what's in between the sending address and port cannot be the same as the receiving address and port. Is this why the loopback address is 127.0.0.1 rather than the hosts ip address?

Yes, I get that certain devices such as routers, switches, servers, and such require static ip's. It's good to know more about why. I can see how a reservation for a server may take a few milliseconds longer to resolve and therefore cause DNS/AD problems. That's not something I care to cause, or have to repair. Is there any performance advantage to the lower ip addresses within a range vs. the higher ones (.5 vs. .200)?

 

[YeOldeStonecat]

When it comes to routers, and VPN tunnels...remember it's just 2x sides to a wall, the inside, and the "other side".

Be it straight router mode, or...a VPN tunnel....you need different IP ranges on either side. The router "routes" packets...those not in the same IP range/subnet...need to go to the "other side". If both sides of the router are the same IP range....the packet goes "WTF...which way do I go George??!!?!?!" You can see the circle of confusion here.

Loopback addy...no real reason in my book, just one less thing to change or determine I guess...if it's set to loopback. Some techs prefer it, others don't. No right or wrong here.

No performance diffy with lower numbers range versus upper.

 

[Mike McCall]

Alright, thanks! I think I get this.

So, as I continue to plan for this overhaul of the network I see that everyone seems to have their pet addressing conventions. I see the value in that and am already developing my own. Bearing in mind that my network must serve a dual purpose as both a functional home network (at least when the wife get's home), as well as a learning lab, my questions continue.

I plan to assign static ip's to as many devices as will take them...hosts, servers, switches, NAS, and such. .1 - .10 will cover them with a few to spare. The network printer will get a reservation in the .11- .15 range. Not sure if I should place my laptop in the static or reservation group. I could place the Roku and VOIP in the .16 - .20 range, but I like the idea of breaking them out onto their own LAN to minimize their impact on internal traffic. I'm not able to set static ip's for them but I can use reservations so I know where they are. That leaves WiFi devices such as my iPad, phone, netbook, and potentially even my laptop which is part of my AD. This range is where I think DHCP makes the most sense for my network, with the exception being the laptop. However, since this is also a learning lab and I need to learn how to setup and manage a switch, perhaps I might break out the WiFi devices onto their own LAN, specifically for the purpose of then creating a VLAN that puts them back on the same LAN as the Hosts and other network resources. In for a penny, in for a pound!

 

[YeOldeStonecat]

So, as I continue to plan for this overhaul of the network I see that everyone seems to have their pet addressing conventions. I see the value in that and am already developing my own. Bearing in mind that my network must serve a dual purpose as both a functional home network (at least when the wife get's home), as well as a learning lab, my questions continue.

Don't over complicate it in your head....for the purpose of your residential equipment...the network is the same, only difference is the source of DHCP moved from the router to the server. But the home devices won't care.

 

[Mike McCall]

Don't over complicate it in your head....for the purpose of your residential equipment...the network is the same, only difference is the source of DHCP moved from the router to the server. But the home devices won't care.

Me? Have you been talking to my wife?

Yes, my home devices won't care what the ip addressing convention is or the source of DHCP. If all I intended to do was to use the server for DNS/DHCP while playing a bit with AD and leave the network alone after that, then I would agree that I should leave well enough alone. Were I doing this for a client, I would stop here unless there was a compelling reason to do otherwise. In this case this is a learning lab. I don't want to find myself in a position where I'm doing work for a client on a network and I've never even properly set up anything but a flat network and therefore a VLAN. If I don't put hands on this here, where will I? In my overly analytical mind this seems a perfect opportunity to delve into this. I'm reworking the addressing scheme of the entire network, so if I were doing this for a client would this not be the time to address such a thing? Shouldn't I have some idea what effect different LAN's will/won't have on AD?

I really do appreciate ALL the help I have received from various members of Technibble, in every form it has taken! I'm not going to impress anyone, whether client or otherwise with my youthful good looks (think middle-aged, bald, fat-guy that bears a striking resemblance to Uncle Fester), so I better know what I'm doing. That's what I'm trying to do. Since I have no one else to victimize I come here. At least until I become too annoying.

 

[Markverhyden]

There is no "performance" related to what ever IP scheme you use. An IP is an IP is an.... you get it. Simply pointing out that having some form of logic your network IP topology makes troubleshooting, documentation, etc much easier.

 

[Mike McCall]

There is no "performance" related to what ever IP scheme you use. An IP is an IP is an.... you get it. Simply pointing out that having some form of logic your network IP topology makes troubleshooting, documentation, etc much easier.

Yes, but my logic often has not only holes in it, but brick walls to run into.

I have everything converted and functioning except for 2 things - my printer and my NAS. The NAS I can fix as I neglected to allow any of the new ip addresses past the firewall. Annoying, but fixable. I'm so far unable to set a reservation for the printer because the server thinks the MAC address (00:15:993:13:F4), is invalid. It see's the device and assigns an ip, but won't let me set a reservation. I suppose I should set a reservation for the Roku and VOIP as well. I'll listen to the advice of YOSC and not complicate my life more than it needs to be at this point by adding different LAN's. However, at some point I'll have to let my masochistic tendencies run free on that issue. Maybe smaller steps are a wiser approach. Thanks YOSC!

Edit: Haha! There isn't supposed to be a smiley face in the MAC address. It should be: D.3 (without the dot between). Could this be the reason the server doesn't like the MAC address?

 

[jzukerman]

Windows Server 2012 Essentials is designed to work without DHCP service (using router's DHCP service). The install wizard walks through the changes that need to be made (DNS on the router). I don't know why they did that. I've always used DHCP service on Windows Servers instead of on a router, and that's how Microsoft always was.

http://blogs.technet.com/b/sbs/arch...server-on-windows-server-2012-essentials.aspx

 

[YeOldeStonecat]

Windows Server 2012 Essentials is designed to work without DHCP service (using router's DHCP service). The install wizard walks through the changes that need to be made (DNS on the router). I don't know why they did that.

They did that because on small networks (which Essentials is designed for)...the typical install scenario is a growing small "workgroup" network that already has a router doing DHCP for the LAN...and so many people stumble when installing a server and leave DHCP on the router which just hands out the routers LAN IP for DNS relay, or hands out the WAN ports obtained DNS servers (typically from the ISP) which of course causes AD to not function. So they instead forced that configuration guide to come up and have you reconfigure the router. Plus they like to "dumb down" things for the SBS family, designed for the not-IT person (layman)...with wizards and such to auto configure things and make it easy peasy.

Microsofts logic when it comes to small business servers has often gone against best practices and even their own guides. For example...having Exchange on a DC (earlier SBS versions)...and most notably of late, they've recently preached about no longer using .local for the FQDN....yet Essentials does a .local out of the box! //enter confusion

Yet when you do DHCP on a router, things are more likely to not work well, such as RWW...because internal DNS is "less aware" of clients. Not to mention many routers have poor DHCP services with limited options. (many have very poor DHCP reservation options for example).

 

[Mike McCall]

They did that because on small networks (which Essentials is designed for)...the typical install scenario is a growing small "workgroup" network that already has a router doing DHCP for the LAN...and so many people stumble when installing a server and leave DHCP on the router which just hands out the routers LAN IP for DNS relay, or hands out the WAN ports obtained DNS servers (typically from the ISP) which of course causes AD to not function. So they instead forced that configuration guide to come up and have you reconfigure the router. Plus they like to "dumb down" things for the SBS family, designed for the not-IT person (layman)...with wizards and such to auto configure things and make it easy peasy.

Microsofts logic when it comes to small business servers has often gone against best practices and even their own guides. For example...having Exchange on a DC (earlier SBS versions)...and most notably of late, they've recently preached about no longer using .local for the FQDN....yet Essentials does a .local out of the box! //enter confusion

Yet when you do DHCP on a router, things are more likely to not work well, such as RWW...because internal DNS is "less aware" of clients. Not to mention many routers have poor DHCP services with limited options. (many have very poor DHCP reservation options for example).

It appears that their desire to make things "easy peasy" tripped me up when I tried Essentials. I was certain that during installation it automatically configured itself for DHCP. Apparently that one (which caused me more than a few problems at the time) was another operator error.

So at this point DHCP/DNS is now on the server. The ip addressing has been converted to 10.58.58.xx. In doing the conversion I learned that I was able to set static ip's for all the hosts, NAS, and the network printer as well. While I have some reading to do on DHCP scopes, I did set a scope ranging from .2 - .20, leaving .1 out as it's the router and I didn't know if I should include it or not. I then set an exclusion for .2 - .10 as that covers the static ip's and the server won't try to assign them to another device should one with a static ip drop off the network for some reason.

This seems like a good stopping point for this project. It started with my wanting to setup AD on my server so I could at least get a little hands on with it through the initial setup and addition of a single user (myself), and a single host (my laptop). As things like this often go, it grew into other required areas such as DNS, DHCP, ip addressing, and touched on several other subjects. I learned a lot through this project with the help of all those who participated. Yes, I still plan on complicating things by breaking certain devices out onto their own LAN specifically to VLAN them back together again. That's the purpose of a home learning lab, to learn. I would much rather break it at home so I learn not to break it at a client's. The more I learn at home, the less likely it is that I'll make a fool of myself at a client's. So, a big thank you to @YeOldeStonecat, @markverhyden, and everyone else who contributed to this thread. I'm off to find more trouble to get into.