This is a bit late, but Rob Rutherford posted a question on this topic on
Tuesday. I don't post very often, but this is one topic of particular
interest to me. Schema design is perhaps the thing that is done least well
by the average NT/Win2K Sys Admin. I think that this is due in large part
to MCSE training being particularly poor when it comes to the management of
distributed data. It's an area we need to work on. Anyway, here are a few
thoughts on Robs specific question.
A second top level domain may not be as good an idea as tiering down a level
(e.g. ad.company.com or some such).
Think of your schema as though it were a living tree whose trunk leads to
all things, and each branching opportunity being obvious, in terms of having
someone know which way will lead to what they are after. Additional top
level domains can be important, if you come to believe that there are
multiple ways that users will approach you, and you want to get them all.
For example, the following entry points all take you to the same place:
mariners.mlb.com
mariners.org
seattlemariners.com
Note that while each of these is a different top level domain, they all lead
to the same root, and the rest of the schema starts to branch out from
there. This is important, I believe, unless you really do have separate
businesses that require separate entry points, but even then you will
probably want to tie them together in multiple ways.
The rest of the schema is more important. You want to implement a services
based schema that tracks with your company structure. The best way to
illustrate this that I can think of is found in the "new printer" wizard in
settings-printers. The browse option presents the user with the AD top
level schema. If there is a top level OU that is labeled "printers" then
the user will know what to do. If not, then you just shot your support
labor costs and will look like an idiot. This same logic applies all the
way down through the schema. You have to pick labels that have meaning to
someone trying to walk the tree. ending up with device serial numbers or
property tracking numbers may be convenient for sys admin purposes, but they
totally subvert the operational intent. Why does a company buy computers?
It is not so that sys admins can have nice lists of property tags.
Also, remember that your domain and OU naming design will be seen in
different ways by different services. For example, while your new printer
wizard walks the tree and does not require you to deal with the entire
string, your users will have to deal with the entire e-mail string that you
impose on them. For this reason you want to do two things - install the
root Exchange OU very high in the tree (company root is not a bad idea, but
one tier down can work if you make that OU name VERY short, and you rewrite
outbound "from" addresses so that a simplified string suitable for business
card presentation is exposed.
Look at each service separately. How people interact with the directory
data for a given service will guide you on how best to craft the OU branches
for it.
I hope this helps. If not, present yourself to R'lyeh Consulting as a
humble supplicant. CJ really is the MOSMWNMTK.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 02, 2001 6:17 AM
To: [EMAIL PROTECTED]
Subject: [ActiveDir] Naming Standards
Hi All,
a quick one for you.. I've read allot of conflicting reports on how to
decide on the root domain
Basically our registered DNS name is Company.com but took advice to
separate the internal and call it CompanyIntl.com... Do you think this may
cause any problems in the future? If so then I'm going to have to look at a
way of changing the whole structure, i.e. migrating the users, objects,
etc.
Thanks in advance
Robert Rutherford
List info: http://www.activedir.org/mail_list.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
