You see child domains or peer trees a lot when you have a distributed environment. Either by geography or logical LAN boundries. Sometimes you will see a break because of admistrative duties.
Geographic Example:
ad.comany.com (the US main site)
asia.ad.comany.com
europe.ad.company.com
LAN Example: (each branch is firewalled heavily from each other)
dorms.school.edu
labs.school.edu
administration.school.edu
If that's not helpful, tell us more about why you are considering breaking stuff apart?
There are many other reasons for having different domains and forests, i'll give you a few of the ones we use:
1. We have an empty root domain and then a child domain underneath in the same forest which holds all user accounts and computers etc. The reason for this two fold. One is security. In order to carry out any enterprise wide changes, such as Schema modification, you would need an account which is in the Schema Admins group in the root domain. This means only a few priveldged administrators can do this, not just anyone who's in the Domain Admins group in the child domain. The second reason is, if our child domain was to fail for whatever reason, the basic building blocks held in the Schema that we've made are still in existence. Since no administration or changes are done in the root domain, this is quite a good cost effective safeguard at protecting this information.
2. Other child domains in the same forest are basically used to decentralise administration without losing control over your own area e.g. if your IT teams in Europe and the US worked independently of one another, two domains could allow Europe administrators full control over their own domain but only basic access (or whatever was deemed necessary) over the US domain and vice versa. This could be ruled by department as well as geography e.g. a high security department in a company may well have their own domain to prevent other users in the same company from getting access to confidential resources i.e. it's an extra layer of security.
3. Other forests are used by us for development environments. In our case, we have a team that develops software etc. for Exchange 2000 and many other applications that all modify the Schema. Since the Schema is common forest wide, if they had a domain that was part of our production forest, everytime they installed a new application, it would modify our Schema. This could be very damaging for a live environment!!
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.