|
:o)
It is our job as technical experts or subject matter
experts or technology specialists or whatever it is you want to call us to
explain the ramifications of bad decisions to management and convince them to
follow a more prudent course. Anytime a manager refuses to listen to me on a
subject area I am paid to be an expert for them in, I ask them, why am I here if
you aren't going to listen to what I say? We are not here to say "hear hear" and
back up every stupid thing said. We are there to make sure things are done right
and if they aren't, to implement whatever stupid thing it is and try to make the
best of it. I personally, would rather nip things in the bud and make sure I
don't have to spend extra time trying to make the best of anything. This tends
to make me unpopular with managers who tend to speak more than listen regarding
technical topics they aren't qualified to even think about and popular
with people who have to do the real work.
I am not saying that it is always possible to get the best
solution, by no means, if we had no "in the end" stupid management decisions,
the world would be a very different place. I have had to live with some
extremely stupid management decisions in my time that in almost every case,
actually I am pretty sure every case I had all the right in the world at the end
to say "I told you so". I generally choose not too because it doesn't help
anything, it is just good to get people to understand that maybe they should
have listened more in teh first place. This experience in
seeing bad ideas resulting in bad results is why I have the
foresight now to look at things from multiple angles and farther out and the
confidence to voice the opinions. I basically think people should figure that
anything new you are taking on you will have half the money and half the time to
do it in the next couple of years. Can you still support it? If not, why not?
What could make it easier then that you can do now? Again, you won't always
catch everything but you need to be trying to and when you see something bad,
you have to point it out.
I am more likely to live with purely business decisions
such as naming standards etc as long as they don't impact supportability too
much. I am far more likely to live with bad management decisions as a consultant
than as someone who would have to live day in and day out supporting those
decisions. As a consultant I have the luxury of saying, "I told you what I
think should be done, it is your decision to do what you want.". Whatever is
done, they have to live with, not I. I still will speak up, but I won't get in a
fight with anyone about it.
I will say again, multiple trees is not a business
decision. There are no business reasons to support it, I have heard oodles of
supposed reasons and not a one made any real sense when weighed against the
complexity it involved and never delivered the stated goal. However, there are
solid technical reasons for not doing it. It may be because of inept or
unskilled programmers or vendors or admins but those are real reasons that
you need to keep in mind when trying to make an efficient, bulletproof, easy to
use architecture. The number one rule is KISS. Keep it simple stupid. Why?
Because you don't want to have to refer to a book to understand how your
environment is supposed to work. Because you want new admins to easily pick up
on how things work at that company when you hire them in. Because simple tends
to just plain work better than complex. Don't get me wrong, a complex
architecture can work, but it is more costly and takes better admins (which are
themselves more costly) to do so. It is far more likely something will be
forgotten when deploying something new or when something breaks and you are
running around trying to correct it.
My notes here are not an attack on anyone who implemented
multiple trees, I have seen several customers who have done this and talked more
customers out of it. Take these as notes to make people think who are
looking in the future to possibly doing it. Just like I spoke out several
years ago when anyone, including some MS engineers, said separate domains in a
forest offered extra security I am speaking out now about multiple trees in a
forest. If you ask Microsoft about multiple trees, they will of course tell you
it is a fully viable option because it is. They aren't going to tell you you
can't do it. Depending on the analyst though, you may get someone honest enough
to tell you that it probably isn't what you really want to do though. I have a
friend in MCS who recently ran into this and was very adamant with the customer
that they really didn't understand AD and that the architecture designed was
really pretty bad. I applaud that.
I would much rather someone be mad at me up front for
telling them something is stupid than having them call me months or years down
the road and say, why didn't you tell me this was so stupid?
joe
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Sunday, July 31, 2005 11:38 AM To: [email protected] Subject: RE: [ActiveDir] Multiple Domain Trees in a Single Forest Joe said: “WHY??? What do you feel
the benefit is?” In my experience, it’s been not what
*I* think the benefit is – it’s
more about what management WANTED for reason A, or reason B, or whatever whacked
business justification that they had. I’m not much into creating trees for
the heck of it. However, it does interest me to a) keep my job b) try to
convince people that this is purely a business decision, and technically I can
provide an invisible ‘separation’ if that’s what they
want. However, as in all business – there
is a time to make a decision. Fight or not. In the cases that I’ve
had to implement additional trees, I’ve allowed it to happen because it wasn’t a
battle worth fighting. However, I pushed to get the tree merged back into
the main tree as time and emotions settled. Sometimes, joe – the only benefit of
doing something that you don’t find palatable is because it’s not technically
bad enough to warrant the fight that will ensue. Rick From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of joe 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] Hello
All, Looking to decide on
an AD domain structure Thanks! Rob |
- RE: [ActiveDir] Multiple Domain Trees in a Singl... joe
- RE: [ActiveDir] Multiple Domain Trees in a ... Myrick, Todd (NIH/CC/DNA)
- RE: [ActiveDir] Multiple Domain Trees in a ... al_maurer
- RE: [ActiveDir] Multiple Domain Trees in a ... Al Mulnick
- RE: [ActiveDir] Multiple Domain Trees in a ... Al Mulnick
