You all knew I had to weigh in on this
subject.
First some reading on the subject is found
here. I think this is what the initial request for information was
for. You might also want to reference the article on lucent’s site
she points out for what happens when you remove EA from a child domain, etc.
Good information.
http://redmondmag.com/columns/article.asp?EditorialsID=436
I think all the responses on the list
pretty much cover the business case scenarios really well. I am going to
argue against Empty Roots from a more primitive / narrow minded approach.
See back in 1999/2000 I was a young
Exchange Administrator wanting to do good for my organization. Exchange
5.5 and the eventual migration to Exchange 2000 was our primary driver for
adopting Windows 2000 Active Directory. At the time, our Exchange Organization
supported multiple sites (Remember sites were both administrative and
replication boundaries in Exchange 5.5) and so in order to migrate the existing
exchange 5.5 architecture to Exchange 2000, we would have to prune a lot of the
NT 4 domains, and establish a core set of domains that would support the decentralize
security / administration model of our organization. The design me and my
colleague came up with supported several “experimental” AD design
constructs to promote ease of resource location, and what we thought at the
time security separation of enterprise roles verses domain and data
administration function. What fueled our desire to adopt some of these constructs
was Microsoft’s “marchitecture” that expounded on how
application development could leverage all the standards in AD to centralize management,
etc. So we justified going to an Empty Root design to facilitate the separation
of security functionality and to centralize the core directory service
functions for extended the schema and replication convergence. Politically
we wanted to facilitate collaboration with other operating divisions within our
department, so having a natural domain to house these functions also was
attractive. Fundamentally, though we were an email shop and we needed a
directory service to facilitate the next generation of Exchange. The
design works and is functional, it allows for us to collaborate and incorporate
other entities into our design pretty easily, but operationally it is not
streamlined, the technology has a lot of inherit dependencies, and the service
isn’t optimized for the various roles and functions it serves.
My recommendation is to try to identify
what functions you want your directory service to perform, and then stand up AD’s
or LDAP directories to facilitate the functions required. With the
inclusion of MIIS in 2003+ in makes a lot more sense these days to design your
security around isolation models than to try and make one big giant AD.
It might seem cool, but the number of problems you will run into down the road,
are greatly compounded when you use the wrong directory for the job.
Todd Myrick
From: Jef Kazimer
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 26, 2006
12:30 PM
To: [email protected]
Subject: RE: [ActiveDir] Root
Place Holder justification
Guido,
My
thoughts exactly. I always start my complaining with "It was
designed with what we knew at the time.....but....if I could it again today,
blah, blah".
I
think the decisions that would use this model today will most likely stem from
political and administrative decisions, where as earlier the infrastructure had
a larger impact on such a design.
If
only there was the do over button..:)
J
Subject: RE: [ActiveDir] Root Place
Holder justification
Date: Wed, 26 Apr 2006 17:08:31 +0100
From: [EMAIL PROTECTED]
To: [email protected]
> I believe many of our headaches stem from this past
decision (in place before I was here) and often ponder making
> the bold statement of considering collapsing them all
into a single domain.
There is nothing wrong with a past decision that was based
on the knowledge and recommendations available at the time. I've designed and
implemented empty root forest-models myself and I believe most companies have
implemented this model in the early days of AD. But with the knowledge we have
about this infrastructure today, there's hardly a reason to stick to this
model.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Jef Kazimer
Sent: Mittwoch, 26. April 2006
17:48
To: [email protected]
Subject: RE: [ActiveDir] Root
Place Holder justification
I
would tend to agree that a single domain is optimal with the current AD and
infrastructure that is available. Other than security, legacy, and
most importantly political issues, for most a single domain should be
considered.
Where
I am, we have 3 domains in a single forest, with one being a root
domain. I believe many of our headaches stem from this past
decision (in place before I was here) and often ponder making the bold
statement of considering collapsing them all into a single domain.
Though I suspect I would be lynched. :(
We
have over 160 sites, and around 150k users within 2 domains, with the slowest
link today around 256k link to departmental sites (50< users).
The
security requirements are the same throughout all domains, and I believe the 2
domains exist for political reasons that fortunately are fading away.
Many bad policies and practices grew from one decision to keep things seperate.
Of
course your companies policies and practices for managing the domain globally
go a huge way into that consideration. Issues such as account
provisioning, group management, and replication convergence times could
impact the business if the infrastructure impact is not understood.
If
I had a magic wand....I'd wish for a single domain. :)
Jef
> Subject: RE: [ActiveDir] Root Place Holder
justification
> Date: Wed, 26 Apr 2006 09:56:04 -0400
> From: [EMAIL PROTECTED]
> To: [email protected]
>
>
>
Your subject is your answer. They need to justify a root domain. Is
> there an actual reason for it?
>
>
There are only three reasons to have one, imho....(cut and pasted from a
> google search)
>
>
1. Security requirements are different (password, lockout, and Kerberos
>
policies must be applied at the domain level).
> 2. To control/limit replication (but note the recommendations for number
> of
>
objects in a domain with slow links - if the slowest link is 56 kbps,
> the
>
domain should have no more than 100,000 users).
>
3. Because you inherit a multiple domain setup.
>
> I question number three myself. I would rather clean it up than continue
>
with a past decision but I guess that depends upon the impact to
> operations and the complexity of consolidation.
>
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
>
> [mailto:[EMAIL PROTECTED] On Behalf Of Mark Parris
>
> Sent: Wednesday, April 26, 2006 9:37 AM
> > To: ActiveDir.org
>
> Subject: [ActiveDir] Root Place Holder justification
> >
> > Does anyone have any official documentation as to the
>
> justification for a root place holder, pro's and con's ?
> >
>
> Where I am - I have started at one domain and can see no
>
> reason to expand on that - they only have 6 DC's now in a
>
> single domain - yet the partner they have chosen is
>
> recomending a root place holder with 5 DC's and then 8 in the
>
> child domain (they are NOT even supplying the tin) and I
>
> wanted some decent amo - a little bit stronger than schema
> > and Ent admin separation.
> >
> > I know at DEC the concensus was the desire to eliminate and I
>
> believe Guido and Wook have stated this for the past two DEC's
> >
>
> I have searched this list and can find no relevant articles.
> >
> > Many thanks
> >
> > Regards
> >
> > Mark
> > 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/
Join the next generation of Hotmail and you could win the
adventure of a lifetime Learn More.
Join the next generation of Hotmail and you could win the
adventure of a lifetime Learn More.
