Too bad I wasn't awake for the party, eh? I'll take a crack anyway.
I taught MCSE classes for several years, and Microsoft's recommendations were always fairly consistent between their various training materials.
Don't use a domain name you don't own for your Active Directory domain name (i.e. microsoft.com).
Don't use an FQDN for the domain that other DNS servers are already authoritative for (i.e. company.com)
Do use an FQDN for the domain that is globally unique (i.e. ad.company.com, corp.company.com).
I believe the ".local" TLD "recommendation" started about the time of Windows Small Business Server 2003. The ".local" TLD is not reserved by ICANN though it's doubtful, at this point, that it would ever be used "for real" on the Internet (the Zeroconf protocol has dependencies on the ".local" TLD, too, I believe).
I've been in too many environments where "company.com" got used for the AD Domain name, necessitating stupid ugly hacks involving manually copying DNS records from the Internet DNS servers into the DNS servers supporting AD. I've answered a boatload of questions on this site that came down to this poor domain name choice causing hacks to have to be implemented (having to run web servers to do redirects to the "real" "company.com" web site on every AD domain controller, etc).
I don't know why companies persist in doing the "company.com" naming scheme for AD domains. It only creates problems. There isn't any good argument why you should do it, and it "goes against" the basic tenet of DNS that only one set of DNS servers in the world should be authoritative for a given DNS domain name. (I often hear the "UPN suffix" argument. If you want users to have a UPN suffix of "@company.com", for example, you can do that w/o actually naming the domain "company.com". All your users can have "@whitehouse.gov" UPN suffixes if you want, regardles of the domain's name...)
I've always been partial to "ad.company.com", myself.
The "empty root" domain idea is purely a political construct. Originally (W2K timeframe) Microsoft touted "empty root" as a way to have isolation of security concerns between parts of an organization while still having a single AD infrastructure. Fortunately, they've let up on this attitude (though they haven't necessarily gone back and corrected all the documents that were erroneous) since it's been demonstrated that any member of "Domain Admins" in any domain of the AD forest can, fairly easily, make themselves into members of the "Enterprise Admins" group.
So, today "empty root" is only ever really used for political purposes. I would argue that there's no place for it at all because it adds needless complexity (never, ever have a multi-domain environmnet where a single domain environment will do) and offers no real advantages.
If you want security isolation between concerns in your organization you must use a multi-forest deployment (which is absolutely the least fun kind of environment and to be avoided at all costs).
This has been a fun topic of discussion on Server Fault. There appear to be varying "religious views" on the topic.
I agree with Microsoft's recommendation: Use a sub-domain of the company's already-registered Internet domain name.
So, if you own foo.com, use ad.foo.com or some such.
The most vile thing, as I see it, is using the registered Internet domain name, verbatim, for the Active Directory domain name. This causes you to be forced to manually copy records from the Internet DNS (like www) into the Active Directory DNS zone to allow "external" names to resolve. I've seen utterly silly things like IIS installed on every DC in an organization running a web site that does a redirect such that someone entering foo.com into their browser would be redirected to www.foo.com by these IIS installations. Utter silliness!
Using the Internet domain name gains you no advantages, but creates "make work" every time you change the IP addresses that external host names refer to. (Try using geographically load-balanced DNS for the external hosts and integrating that with such a "split DNS" situation, too! Gee-- that would be fun...)
Using such a subdomain has no effect on things like Exchange email delivery or User Principal Name (UPN) suffixes, BTW. (I often see those both cited as excuses for using the Internet domain name as the AD domain name.)
I also see the excuse "lots of big companies do it". Large companies can make boneheaded decisions as easily (if not moreso) than small companies. I don't buy that just because a large company makes a bad decision that somehow causes it to be a good decision.
Best Answer
A root CA can easily be made an enterprise CA because that's the deployment that makes sense in some scenarios. A lot of deployments don't want or need an offline standalone root, or any intermediates at all; those can work just fine with an enterprise root. Say, for instance, if you're not issuing more than a couple of long-lived templates (so availability isn't a huge concern) and don't need to publish CRLs often.
I'm right there with you on it being a little too easy to just toss up a poorly planned CA - you develop an appreciation for how carefully they should be planned after reviewing the documentation, but it's not obvious when you're doing the install (and don't get me started on the simultaneous necessity and obscurity of
capolicy.inf- put that stuff in the GUI!).I've dealt with cleaning up these half-baked deployements more than I'd care to admit, but pulling them down is definitely doable (make sure all clients trust the new root, strip the templates from the old CA, bump the template version to force a re-enroll against the new CA); it just requires much more work and careful planning than was put into the initial sloppy deployment.