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.
Workstation SAMs act in many ways like separate domains with a one-way trust relationship. So while I can't find it explicitly documented, I don't find it surprising that this doesn't work, as it is analogous to adding a domain local group from one domain into a domain local group from another domain, which isn't allowed (see table 7-1).
(The only odd thing is that it seems to work if the domain is Windows 2003 functional level, and I can't find this change documented either.)
In any case, you should be able to solve your problem by changing the domain local group into a universal group. Assuming you are at least running in Windows 2000 native mode and not Windows 2000 mixed mode, universal groups are supported, and they are specifically designed for this sort of scenario.
Best Answer
You're so close... >smile<
You're looking for the following command to manipulate domain local group membership.
You can run that from a DC or a member computer in the domain.
BTW, if your domain functional level is Windows 2000 or higher you can change groups freely between the various types w/o having to recreate them.