Best practices for configuring a new Active Directory

I've always been a ".local" person.
If your businesses public domain name is something like "catspad.com" for the website, I'd make AD catspad.local.

Couple of years ago starting reading .local causes issues on some networks due to Apples protocol...I think it was Bonjour. I didn't care at all about that.

But last year the second wave of this chatter started coming about due to 5x name UCC SSL certs not able to support .local for the internal FQDN anymore. Not a biggie really, we just started using standard SSL single name certs with the public FQDN which we'd set Exchange and/or RWW to.

What makes this odd...is that if you go get Windows Essentials Server...it assigns itself .local still, and there is no way around it that I know of. The "setup wizard" breezes through it with no advanced options that I've seen allowing you to customize that. So you still end up with catspad.local. Why is Microsoft forcing you into that, if the whole industry is supposed to move away from .local? Ah...such logic!

For full servers I've done the office.catspad.org
 
Last edited:
Interesting. Thanks for the input Stonecat.

I've always used .local too. In fact I think practically every DC I've ever worked on used .local, .lan or something similar.

This got me thinking though; if there are no real disadvantages to using the business' public web domain, wouldn't it make sense to do so when setting up a new DC server ... just in case. I mean, I certainly wouldn't want to change any existing configurations, without good reason, but, by the same score, I wouldn't relish the thought of having to reconfigure any new ones later either.

I'm presently configuring a DC that will likely have another DC join it at a later date, down the other end of a VPN tunnel. The two servers will probably need to work together to share/sync data, and I can't rule out the possibility of self-hosted websites/emails at some point in the future. So I'm thinking, in this case at least, using a public domain now may be a wise move.

I haven't used a public domain with a DC before; presumably the only issues would be connecting to the externally hosting public domain from the internal domain, which I guess would simply require some DNS forwarder configuration to resolve it, would it not? And if that is the only potential issue, would it not make more sense to configure all new DCs this way?
 
Only "drawbacks" I saw in the past of using a public FQDN internally....the old way (catspad.org for example)....is when you have public services for that domain name outside the network, you have to create records on the DNS server to point internal users out to it.

Example...way way back when Server 2000 came out, I upgraded a clients NT 4 server to 2000. Back with NT 4 it was all about WINS and we didn't bother with DNS much. Win2K put all networking on DNS (and active directory on DNS).
This client, I'll call them "insurance.com"...had their internal directory named "insurance.com".

So as far as their server was concerned, it owned/ran insurance.com
Now this client had a website made, and put up at their web host. www.insurance.com.
People out in the world of course could access it. But the staff at the office, inside the network, could not. Why? Because their workstations looked to their server for directions of course (that DNS thing)..and the server said it was insurance.com...so their web browser stopped at the servers IIS. Since no webpage was there...page couldn't be displayed. So I went into the servers DNS mgt, and created a WWW record pointing to the IP of the web host at their websites people data center. Now it worked for inside users.
Similar with mail...back then they used POP mail, so the mail server was mail.insurance.com...which when the office people launched Outlook, it used DNS to find it, stopped at the server. Had to create an MX record pointing to the actual host.
 
YeOldeStonecat said:
Only "drawbacks" I saw in the past of using a public FQDN internally....the old way (catspad.org for example)....is when you have public services for that domain name outside the network, you have to create records on the DNS server to point internal users out to it.
Click to expand...

Which is trivial to do, is it not? That's why I'm thinking it's probably wise to use the public FQDN, just in case.

When you say "the old way", do you mean using something like catspad.org, rather than internal.catspad.org, for example?

..... actually, I'm wondering, would the server even believe itself to be catspad.org in that example?


I think I need to boot my 2008 R2 VM and experiment ...
 
So if we aren't supposed to use .local anymore what are we supposed to use? nothing at the end or match the public with .com?
 
Blues said:
So if we aren't supposed to use .local anymore what are we supposed to use? nothing at the end or match the public with .com?
Click to expand...

As I understand it, the recommended format would be internal.somebusiness.com, where somebusiness.com is the public domain.
 
We use the companies public domain. In the case of the AD, we normally assign it local.domain.* or lan.domain.*

In some situations, we've done domain.local and domain.lan without issue

I've talked to support over at MS a few times about the Essentials and the ".local" issue. Basically it boiled down to if you want to change it, upgrade your server OS. They don't expect essentials to be using SSL certs, and to be strictly internal servers. Essentials are for small companies who don't know how to do servers. That's how I've taken it.
 
Moltuae said:
Which is trivial to do, is it not? That's why I'm thinking it's probably wise to use the public FQDN, just in case.

When you say "the old way", do you mean using something like catspad.org, rather than internal.catspad.org, for example?.
Click to expand...

"Yes"...trivial to us. But for many "sorta learning AD" techs...it's a big stumper!
And "Yes" regarding what I meant with the old way.
 
For the record, I've just tested this with a couple of VMs and it works pretty much as expected.

If you use a public domain with a subdomain (eg local.domain.com) as the DC's root domain, and join the domain from a Windows 7 machine, any pings to the local domain receive a reply from the DC server, while pinging and browsing to domain.com connects to the web host as usual .... no DNS forwarding necessary it would seem.
 
You must log in or register to reply here.
Back
Top