Mike, Ok - now I think I understand most of the setup ;-)
One question - is Exchange/SQL in the "empty root 2003 domain" that you mentioned in the original message? If this is the case keep reading. If not, that brings up other questions ;-) Either case (child domain or separate tree in the same forest) would put you in a better position than where you are now. IMO, I think that the issue is going to boil down to a DNS namespace issue. If you go the child domain route you have a contiguous DNS namespace while the separate tree route leads to a non-contiguous namespace. I like the contiguous namespace because I am a KISS person and I think that the DNS setup is much simpler (child DCs forward to the root domain, root domain delegates to child). One thing that you need to confirm is that the forest root domain is the existing exchange domain (i.e. it contains the Enterprise Admins universal group). If the Exchange domain is not the forest root domain, you are in a corner because you are at least going to have to keep both the Exc domain and whatever domain is the forest root domain. Back to the question. Going back and re-doing a DNS/AD namespace is a major PITA. In your case I would look for the following: Keep the Exc domain and check to see if it is also the forest root domain (contains the Enterprise Admins group). Hopefully it is. Keep this domain. If the forest root is not the existing Exc domain, find the forest root domain. Keep this domain. -or- If the Exc domain is also the forest root, find the domain that currenly has most of your objects. Keep this domain and migrate the remaining users to this domain. You end up keeping the Exc domain and (ideally) the domain that already has most of your users/servers/etc. The forest ends up being a two tree forest where each tree is a single domain. This is probably as good as you are going to get from a trust tree viewpoint. Hopefully this helps. I don't envy your position... Frank -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Newell Sent: Tuesday, January 25, 2005 5:47 PM To: [email protected] Subject: RE: [ActiveDir] Sites VS domains in a distributed global environm ent. Not to confuse the issue but what I would end up with is a root domain with Exchange and SQL in it (already set up this way) and a separate domain tree, not a child domain of the root. I don't really have much choice regarding Exchange unless I want to rebuild in a different domain. Its setup this way now, the only difference would be I'd only have one domain and the root, instead of 25 or 30 separate domain trees for each company we own. DNS is AD integrated. Again, I inherited this and I am looking for a better way to build our environment. Would a child domain of the root be a better option? Again, I appreciate the input. Thanks. Mike Newell Information Systems Manager OSI Systems -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, January 25, 2005 2:06 PM To: [email protected] Subject: RE: [ActiveDir] Sites VS domains in a distributed global environm ent. Deji, The way that I read the original post, he was going to consolidate into a single child domain under a Top Level Domain (i.e. he ends up with a forest that consists of a TLD placeholder domain and a single child domain under that). If that is the secnario, all of the forest locator information is going to end up in the _msdcs zone of the TLD (_msdcs.tld.com). If he ends up in a true single domain forest and on AD integrated DNS then he does not need to worry about moving secondaries around and I mis-read the original post. Given that the assumption is that the site does not have a TLD DNS server on-site: In the perfect world of no network outages it would be acceptable to have the child DCs/DNS servers forward to the TLD DCs/DNS servers and that would be where the client eventually gets their forest locator records from via the forwarding relationship. The downside to this is that if the network link goes down and the DNS server at the child site cannot reach a TLD DNS server the client is going to logon with cached credentials. This is bad in a kerberos environment. The alternative to this is to place a DC/DNS server for the TLD on each child site. This would ensure that even if the link is down the child DNS server would be able to forward to a TLD DNS server and get the forest locator records. Of course, this would mean buying more boxes. The trick with the secondaries is mostly to cover network outages when there is not a TLD DNS server on the child site. Even with the secondary, you would still forward DNS traffic from the child DC/DNS server to the TLD DC/DNS server to get the rest (non _msdcs.tld.com) of the DNS info for the TLD. In addition, in my specfic case, my TLD forwards to a legacy DNS backbone and ultimately to a split DNS to get Internet DNS resolution back to the client. The tradeoff here is that you cover the possibility of a network outage by creating the secondaries on the child DNS server (admittedly also creating a little more admin work). Frank -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, January 25, 2005 3:04 PM To: [email protected] Subject: RE: [ActiveDir] Sites VS domains in a distributed global environm ent. With apologies to the original poster, I would like to hijack this thread and respond to Frank's idea on this: <quote> DNS - If you use AD integrated DNS for your AD domains (I did), make sure that each of your child DCs has a standard secondary of the TLD _msdcs zone and then have the clients use their site DC as their DNS server. This is related to the logon requirements for an AD account in a multi-domain forest. Be careful how you grab the secondary from the TLD zone because you can end up with SOA problems if the TLD DNS is AD integrated. </quote> I am somewhat confused on this point, especially considering that you agreed that a single domain would suffice for the requirements of the scenario under discussion. If he has only one domain, then this is mooot, no? Aside from that, I am still confused about the reasoning behind creating secondary zones of the TLD in child domains where there is a child-parent relationship. The rationale you mentioned (This is related to the logon requirements for an AD account in a multi-domain forest) can be easily accomplished by simply configuring the child DNS servers to forward to the TLD DNS servers. This will avoid the need to manage secondary zones and requires no on-going maintenance whatsoever. I know that Frank is not alone in making this recmmendation, but I still can't grasp (or agree with) the technical rationale. I have been known to be slow at times. Is this one of those times? What are the advantages of secondarying parent zones from children or child zone from parent (or even inter-children zone secondaries) over configuring Parent-to-child delegation and child-to-parent forwarding? Sincerely, D�j� Ak�m�l�f�, MCSE+M MCSA+M MCP+I Microsoft MVP - Directory Services www.readymaids.com - we know IT www.akomolafe.com Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon ________________________________ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
