This is quickly becoming one of those religious type argument items. Top
post -vs- bottom post. Universal Groups -vs- Domain Local Groups. Open -vs-
fixed naming standards. Open Source -vs- proprietary. Linux -vs- Windows.
Linux -vs- BSD.  IIS -vs- Apache. MySQL -vs- SQL Server. PHP -vs Perl. Coke
-vs- Pepsi. House -vs- ER. Jennifer Aniston -vs- Angelina Jolie. Cats -vs-
dogs. Kelly Pickler -vs- Katharine McPhee[1]. Empty Root -vs- No Empty Root.

Basically there are valid arguments either way and unless people are willing
to actually discuss the true benefits in an unemotional clear way you end up
with whatever the stronger debater wants for better or worse. 

There are times that I think empty root is a great idea, there are times
when I think it isn't a great idea. I won't recap posts that I have sent
multiple times to the list on this topic. 

Yes, as a general rule MS has backed off the "Everyone should do an empty
root" but they haven't gone as far as some would like to think of "Never do
an empty root" - though you may be pressed to find someone who doesn't say
that. 

In your situation as in any other, write down the perceived benefits and
perceived issues and go from there. It should become pretty clear when you
have them up on the whiteboard next to each other.

Adding five empty root DCs to a forest that currently only has 6 DCs would
put me on the offensive pretty fast against whomever was just throwing that
out and I would really make them explain the logic. They may have some good
logic behind it, that just may be what their cookie cutter says. 

In general if you have a single domain, the initial thought should be you
need to prove why you need more. If you have multiple domains then the
argument, IMO, for an empty root is not as hard a sell; again that is IMO,
OMV - as I recently read... In a group of 12 bright people you will have at
least 13 opinions. I am absolutely not saying that I wouldn't do an empty
root if I already have just a single domain, I am saying I would need to sit
down and write out the reasons for and against like I mentioned above. These
are going to vary for companies but people (including myself) have posted
various reasons for this that they have thought through, check the archives.


I am neither for nor against empty roots in the general case. I like to see
what the goals and issues are and work from there. That being said, I don't
dislike them like many have grown to. 

What kinds of issues can you have with empty roots or more generical
multiple domains in a forest? Well one good issue was mentioned... Stupid
applications that can't deal with multiple domains. These usually are ports
from other OSes and directories but people writing code for MSFT products
aren't exempt from this category either. I seem to recall the PlumTree
Software folks having some spectacularly bad ideas around LDAP and AD and
they only ran on MSFT OS servers the last I saw (been a couple of years).
Exchange, if I were to pick an application at complete random, has issues
once the number of domains exceeds the number of domains in their forest
that they appear to test on in their R&D lab (i.e. >1). They are getting
better but still aren't there. LCS as we recall from a week or two ago
required Global groups which isn't very multi-domain friendly in many cases
(ask anyone who tries to put dom2\user1 into dom1\domain admins). You will
note that that if you don't do it because of these reasons, it isn't a
failing or a problem in AD, it is your crappy apps forcing you.

As for Guido and Wook, I don't believe either would outright close the book
on whether an empty root should be used or not. They will, however, almost
certainly have different things that will push them in that direction but if
a reason came up that they thought was pretty good, they would say it was
fine as well. 

So, I would ask the nice partner... Why do you want to do it this way? Could
be they are a bit out of touch and may quote the old "security boundary"
argument which has been thoroughly thrashed out on this list in the past but
some people still don't understand. I personally like my safe harbor (from
domain level GPO or other domain wide issues) thoughts about a root domain,
many tried to take me to task here on the list about it but I still stand
behind that idea. I don't think I would more than double the number of DCs
to do it though unless I was really scared about the people doing ops or
more realistically getting heavy duty access.

  joe


P.S. Top, DLG, fixed, don't care, Windows, BSD, don't care, don't care,
perl, Coke, House, either, cats, (Kat) Katharine definitely - Kelly has a
blowpop for a brain, don't care.



[1] For those outside of the US, this is reference to our current run of the
American Idol TV show. 


--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm 
 

-----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/

Reply via email to