I seriously dislike multi-tree forests. They tend to
confuse support admins and some programs just aren't written properly for them
and break. For instance I have the domain joe.com, what is the DN for my
configuration container? Well you would like to assume
cn=configuration,dc=joe,dc=com, however, you look at the rootdse and see that it
is actually cn=configuration,dc=someotherdomainname,dc=local. A properly written
program or script will work fine with either but that is a hell of an
assumption, I still run across scripts and programs that try to parse the
domains out to figure out DNs. When you bring in new people to work on your
environment, it is silly to have to train them on such silly decisions as it is
one more thing that they have to keep in mind that is special for your
company.
The main question I like to ask people when they propose a
multiple tree forest structure[1] is WHY??? What do you feel the benefit is? It
has nothing to do with your email address. It has nothing to do with your
userPrincipalName for logon. NetBIOS names can be A whether you have
A.root.com or A.com. So what, besides making your support staff have to work
harder and recall special things is the purpose behind having multiple
trees?
On the LDAP searching part. I have seen programs that
assume that the forest root DN is where you can base a GC search and get
everything in the forest. This is of course incorrect and can cause failures in
multi-tree forests. This is easily corrected by using the null base for the full
forest search.
Every time I have encountered a desire for a multitree
forest it has been the result of political infighting or an architect that
really doesn't understand the product and thinks they are getting something that
they aren't. I had one guy once tell me that any admin at the top of a domain
tree automatically had full admin rights on every domain in the tree
hierarchy... I actually had to get up and walk out of the room for a moment to
decide if I really wanted to get too involved with that deployment because
heaven knows what other decisions were made on knowledge that was also that
wrong. Instead of working out implementation details, it required a complete
review of the entire architecture and to understand the end goals. A completely
different thing than what I was there for.
joe
[1] Which this is, a disjoint namespace is a different
thing. You can have two different disjoints in the name space. The first is
between the NetBIOS and DNS names of the domain - say the domain joe.com has a
NetBIOS name of UncleBob. The second is on the DNS Suffixes used on the clients.
For instance a client of bob in the domain joe.com would normally have a FQDN of
bob.joe.com but in a DNS Suffix disjoint could have something like
bob.sanfran.cali.joe.com or even bob.somethingelse.local.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Thursday, July 28, 2005 7:25 AM
To: [email protected]
Subject: [ActiveDir] Multiple Domain Trees in a Single Forest
Hello All,
Looking to decide on an AD
domain structure
in a single forest. The options on the table are;
1. Dedicated root domain (x.com) and child domains (i.e. a.x.com,
b.x.com etc.) based on the regions.
2. Dedicated root domain (x.com) and other domains (i.e. a.com and
b.com etc.) based on the regions.
The potential risk for the second option that has been identified is
that the deep LDAP search against a regular DC instead of a GC in one
domain for a resource in the another domain may not return any results.
However, the client intends to take the risk and mitigate it by
deploying enough Global Catalogs (GC). In a nutshell, we would like to go with a disjointed namespace for the multiple domains within the forest. However, I need pro\cons to this approach. In addition, does the introduction of conditional forwarding and stub zones mitigate many of the issues that plauged disjointed namespaces?
in a single forest. The options on the table are;
1. Dedicated root domain (x.com) and child domains (i.e. a.x.com,
b.x.com etc.) based on the regions.
2. Dedicated root domain (x.com) and other domains (i.e. a.com and
b.com etc.) based on the regions.
The potential risk for the second option that has been identified is
that the deep LDAP search against a regular DC instead of a GC in one
domain for a resource in the another domain may not return any results.
However, the client intends to take the risk and mitigate it by
deploying enough Global Catalogs (GC). In a nutshell, we would like to go with a disjointed namespace for the multiple domains within the forest. However, I need pro\cons to this approach. In addition, does the introduction of conditional forwarding and stub zones mitigate many of the issues that plauged disjointed namespaces?
Thanks!
Rob
