I've long been a fan of site specific DNS domains (e.g. <site>.company.com). With AD, having a separate domain means an extra pair (for redundancy) of DCs which seems excessive (in cost and complexity) in small environments.
As a result, in my previous company we had a single AD domain but two DNS domains. This worked out pretty well but it also meant including the sitename in the Windows servers names (e.g. <site>name) which gives a redundant FQDN: <site>name.<site>.company.com (The reason for this is that, obviously, you can only have a single AD computer called "name" within a domain. [Yes, technically you can have one per OU but in practice the NetBIOS/pre2000 name prevents this from being practical.])
The answer then seems to be to give up site awareness in the DNS domain which may not be such a big deal with Windows (given that AD has subnet based site-awareness) but still seems wrong to me.
So, what do you do?
Also, if you have multiple AD domains,
- where do you put your user accounts?
- where do you locate your company.com DCs?
- what else should I be thinking about?
We have a single AD domain which spans our two sites. Machines have a two letter site code in the name to show which site they belong to. Then use use sites and services to handle setting up the different sites via subnet.
My motto has always been ... don't put intelligence in machine names. People will pester you forever with their requirements; they will want site, serial#, vendor, business unit, laptop/desktop, userid, etc. Over the years, things change, and you are either renaming for weirdo reasons or falling out of sync.
We run a generic name with a number in it, and use another place to store metadata on the machine, with anything you want.