Need some guidance on new WIndows 2012 R2 server build

[SonicMojo]

I have recently taken delivery on the following new parts to build what I planned to be an "old school" new master file server for the home network:

 

SUPERMICRO MBD-X10SL7-F-O Micro ATX Server Motherboard LGA 1150 Intel C222 DDR3 1600
Intel Xeon E3-1220V3 Haswell 3.1GHz LGA 1150 80W Server Processor
Crucial 16GB (2 x 8GB) 240-Pin DDR3 SDRAM ECC Unbuffered DDR3 1600 (PC3 12800) Server Memory

4x4TB Seagate NAS ST4000VN000

 

I was just going to assemble this thing and stick it in the rack and place it in the "WORKGROUP" like my old server used to work. But then I started reading and thinking that this new box could certainly handle more for me - like maybe allowing me to create an AD domain AND/Or installing WSUS for updates. I am now starting to kick the tires on using Hyper-V to host a domain controller AND possible a WSUS services as well.

 

For years - our network has been the typical WIndows workgroup layout but now with 6 Win 7 workstations - the admin/maintenance is starting to become a real chore. Passwords, updates, user file redirects are all annoying. Plus WSUS would make my life much easier to keep this machines in check and keep Windows 10 off of them.

 

So given the physical parts above  - assuming a clean install of Windows Server 2012R2 - how would you design/allocate the physical/virtual resources available to make the following happen:

 

1. New Domain Controller (Active Directory)

2. WSUS Services (On physical or VM?)

3. File Server (Physical I assume?)

 

Other Q's: Ideally - I want to keep the domain private and behind our current ASUS router firewall - and do not wish to associate it with any of my "real" domain names that I have registered.

 

With that in mind -

 

1. Naming convention for the domain? Is .local still OK or a no no these days?

2. What's the best way to handle DNS/DHCP? Let the DC manage IP's or let the router continue to do it?

 

I would of course assign a hardwired IP to the new server (in the 192.168.0.x range but an IP that is outside the available pool that the ASUS would allocate) Again - simple admin being the goal here.

 

Appreciate any "intel" from the field. This is all new to me so be gentle

 

VP

 

[Danielx64]

Generally speaking you shouldn't have any trouble using .Local for your domain, although I seen people use .Int or .Internal as well.

Also I would let the server handle DHCP although there is no reason why your router cant keep it job. Just be mindful that some minor configuration will be needed on the router for your domain to work correctly.

Lastly I would run everything on the one box and not mess with VMs, better to keep things simple on your small network.

[retrospooty]

I would stay away from .local unless you are 110% sure this domain will never ever be used for any sort of web based hosting, Exchange server etc. .local is no longer supported by alot of entities and you may have issues with it, especially if you ever need a certificate issued. Sometimes your current plans change due to unforeseeable events several years later and you might regret it, changing domains later is a massive pain so keep that in mind.  I always let the DC manage DNS and DHCP. Much easier to manage than any router, and Windows does a great job with this. Set it up once and you are done forever (unless of course something changes regarding your network IP's). You "could" divi the resources up and do HyperV VM's, the server is more than capable, but it isn't necessary. If you are looking to gain experience on HyperV do it, because its highly valuable stuff to know, but there really isn't a "need" for it. 

Edited March 20, 2016 by retrospooty

[+LogicalApex MVC]

To answer the direct questions:

 

1. I'd recommend using a non-standard domain name as it reduces the risk of having to deal with a split domain issue (separate DNS records internally and externally). I use a .local for my AD domain and I'd recommend you do the same... That being said, the split domain issue isn't really a problem as long as you own the domain in question. As you can address any split issues in a manner you chose...

 

I setup my home lab AD back in 2002 or 2003, but everyone else has better advice in this area. Stick with a sub domain of a domain you have control over, ex ad.frazell.net sort of deal.

 

2. Either device can handle DHCP. If you let the DC handle it you'll get the added benefit of automatic PTR records based on DHCP registration and a lot more control over your DHCP server, but you can swap these at any point (of course, beware that swapping with active leases from another device can risk IP address clashes). Just be sure to let the DC handle DNS. You'll need AD controlled DNS for your domains to work properly.

 

I'd recommend running the DC in a VM mainly because it makes backups and migrations smoother and it can help you get a lot more utilization out of your hardware. Hyper-V is included for free and would be a breeze to get the DC running on top of that...

Edited March 20, 2016 by LogicalApex
Correction.

[SonicMojo]

56 minutes ago, LogicalApex said:

To answer the direct questions:

 

1. I'd recommend using a non-standard domain name as it reduces the risk of having to deal with a split domain issue (separate DNS records internally and externally). I use a .local for my AD domain and I'd recommend you do the same... That being said, the split domain issue isn't really a problem as long as you own the domain in question. As you can address any split issues in a manner you chose...

 

I setup my home lab AD back in 2002 or 2003, but everyone else has better advice in this area. Stick with a sub domain of a domain you have control over, ex ad.frazell.net sort of deal.

 

2. Either device can handle DHCP. If you let the DC handle it you'll get the added benefit of automatic PTR records based on DHCP registration and a lot more control over your DHCP server, but you can swap these at any point (of course, beware that swapping with active leases from another device can risk IP address clashes). Just be sure to let the DC handle DNS. You'll need AD controlled DNS for your domains to work properly.

 

I'd recommend running the DC in a VM mainly because it makes backups and migrations smoother and it can help you get a lot more utilization out of your hardware. Hyper-V is included for free and would be a breeze to get the DC running on top of that...

Thanks for the update - I do appreciate it.

 

So to recap:

 

1. I do own several actual domains but only one of the three is actually active on the Internet. Should I look at a sub domain (internal.mydomain.ca) of one of my two unused domains as a start point? Or build this thing against my actual active domain - which is hosted at Wix right now?

 

2. I am willing to let the DC handle this all - but is it really as simple as turning off DHCP for my ASUS router? If I go this route - I guess I am tad unprepared for the correct "order" of turning things off and on to ensure all the machines/devices in the house can stay connected whilst I am messing around.

 

Since this is going to be a potentially long learning experience - I suspect that even if I got a DC up (in a VM) today - I am betting I would not get it running smoothly DNS/DHCP wise for several days. I want make sure the family doesn't lose their mind if they can't fire up Netflix on the iPad later tonight or something

 

3. Since I only have the one new physical box and a robust file server is/was the primary objective - what would be the best way (and order) to install Windows Server 2012 R2 and then build out the required elements? Would I:

 

A: Install the OS and configure it as a new File Server first (running on WORKGROUP)

B: Once the FS is settled and working 100% on the existing network - build out a VM (on the File Server) using Hyper-V and make this first one - my DC?

C: Configure the DC (along with AD, DNS and DHCP)

D: Then make the big network changes to the router and activating the DC to handle the routing?

E: If/When I get the DC working - how do I tell the physical file server to log into the domain? (I am having a hard time understanding how a virtual DC which is on the same physical box as the file server - will manage the logon on the file server?)

F: Where do I put WSUS when all the previous steps are done? With the File Server instance? On another VM and make that a lone WSUS server? Certainly not on the DC?

G: When/how to connect the rest of the clients to the domain?

H: Or - as others have suggested - since this is a very tiny build - and vert tiny network - just stick all the roles on the actual physical server (order would be handy to know) and let it handle everything?

 

So many questions...and steps. Just trying to make sure I can think about this in the right order before diving in.

 

VP

[+LogicalApex MVC]

For domain choice, the domain you choose doesn't matter too much as long as you pick a sub-domain under one you control. This prevents you from having a conflict with an existing domain especially since ICANN is now allowing essentially anything as TLD.

 

In regards to DHCP, it depends on how many devices you already have deployed and your existing DHCP lease realities. For instance, let's assume you're using 10.0.0/24 for your local network now and this is configured as DHCP on your Asus router. I'd find it highly unlikely you're using all 253 (assuming 10.0.0.1 is your router/gateway) addresses you're allocated. So I'd take a look at the existing DHCP leases on the Asus. You might be able to let the Windows DHCP issue leases on a range similar to 10.0.0.100-200 or similar. Allowing you to disable the Asus without needing to be concerned about lease conflicts as you'd have no overlap (assuming all existing leases are below .100 in this case).

 

You *should* be able to accomplish this, even via a VM, without severe impact to your existing network. As outside of turning off DHCP on your Asus router you shouldn't have any impact on your existing devices until you move them over. Meaning, they will still point to your Asus router for DNS and Gateway and you can leave those on while you're configuring and testing your network swap out.

 

I would highly suggest VMs (as I did earlier) to just make life easier. WSUS, for instance, can muck up IIS and impact other services on the server if you're running in a shared scenario. Especially if you later decide to pull the plug on WSUS. I learned this as it impact a shared service VM I had running (not AD or anything critical in my home lab). Separation is good, easy, and safe to do now that VMs are mainstream. If you start out with VMs there is more work up front, but you'll be happy you did down the road...

[goretsky Supervisor]

Hello,

 

.INT is actually one of the first seven TLDs, and is used for intergovernmental (international treaty) organizations such as WWW.NATO.INT and WWW.WIPO.INT.

 

.LOCAL, on the other hand, is reserved for private networks and covered by IETF RFC-6762, so it is unlikely it would be changed, as this would break innumerable numbers of networks.

 

Regards,

 

Aryeh Goretsky

 

[sc302 Veteran]

On 3/30/2016 at 4:32 AM, goretsky said:

Hello,

 

.INT is actually one of the first seven TLDs, and is used for intergovernmental (international treaty) organizations such as WWW.NATO.INT and WWW.WIPO.INT.

 

.LOCAL, on the other hand, is reserved for private networks and covered by IETF RFC-6762, so it is unlikely it would be changed, as this would break innumerable numbers of networks.

 

Regards,

 

Aryeh Goretsky

 

TechNet article 726016^[5] cautioned against using .local:

…we do not recommend using unregistered suffixes, such as .local.

[SonicMojo]

On 3/30/2016 at 2:32 AM, goretsky said:

.LOCAL, on the other hand, is reserved for private networks and covered by IETF RFC-6762, so it is unlikely it would be changed, as this would break innumerable numbers of networks.

 

 

That's good enough for me.

 

Especially the part about potentially millions of private networks out there already using .local.

 

VP