|
Rich,
one other consideration - sometimes it's *preferable* to define your own
attribute rather than using an existing one - depends on how good a match the
data is to the existing attribute you're considering. For example, if
they want to add a user's title, there's a perfectly good attribute for that
already. If they want to store something that's specific to your business
- let's say "restaurant code" or some such - there are likely no existing
attributes that sound anything like this that are not already in use (or that
you're likely to use for their intended purpose at some point). In a case
like that, by all means extend the schema - it makes more sense to all who come
after you and need to understand what you *really* meant by stuffing values in a
seemingly unrelated bucket.
I
guess what I'm trying to say is that extensions are not to be feared or
discouraged IF they make sense - In my opinion, I'd rather do the extension than
forever be explaining that the values in Attribute X *really* mean data Y.
Ditto for using the 'extension attributes'. Just my
opinion.
As for
the process, just make sure it's clear who owns the decision, what the criteria
are for making that decision, and what documentation and testing are
required. For example, we have a schema czar (me) who makes the decision,
but I have some specific criteria I use to decide. I also require a
written description of what the changes are for, and require an LDIF file for
the changes. I put them in a 'throwaway' lab and require the developer to
do their functional tests there and sign off that it actually meets their
needs. Only after that can it go into the normal development forest, and
then eventually to production. There's more detail than that, but you get
the idea. I think each shop has to craft such a policy in line with how
they run their IT.
Dave
Thank you Mark, Bob,
and Robbie (by reference). This will help, I had not seen it
before. That’s the approach we’re taking, unless we get overruled by
someone higher up who was a developer… don’t know what they want to do yet but
I suspect it can be done by using an existing attribute. If it’s really
screwy I’ll check back here.
Thanks again -
Rich
From:
Creamer, Mark [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 15, 2004 12:05
PM
To:
[EMAIL PROTECTED]
Subject: RE: [ActiveDir] Proposed schema
changes research
Rich, I realize this
is only an outline, and you may already know all this, but this presentation
may help you get some ideas on things to specifically research
www.rallenhome.com/conferences/RAllen_Extending_the_Schema_Roundtable.ppt
I guess one of the
main things I took away from the presentation was that I (that is, the
operations team) own the schema, not the development team. We require a well
thought-out and documented request before we add an attribute, and we have a
small approval group that has to sign off.
-----Original
Message-----
From: Rich
Milburn [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 15, 2004 12:15
PM
To:
[EMAIL PROTECTED]
Subject: [ActiveDir] Proposed schema
changes research
As was
inevitable, development wants (“needs”) to modify and/or extend our AD
schema. While I’m checking into what they “need” to do, does anyone know
some good references for do’s and don’ts on this, besides the basic
stuff? It’ll help if I can point to documentation if I find some
problems with what they “need” to do.
Thanks –
Rich
-------APPLEBEE'S INTERNATIONAL, INC.
CONFIDENTIALITY NOTICE------- PRIVILEGED / CONFIDENTIAL INFORMATION may be
contained in this message or any attachments. This information is strictly
confidential and may be subject to attorney-client privilege. This message is
intended only for the use of the named addressee. If you are not the intended
recipient of this message, unauthorized forwarding, printing, copying,
distribution, or using such information is strictly prohibited and may be
unlawful. If you have received this in error, you should kindly notify the
sender by reply e-mail and immediately destroy this message. Unauthorized
interception of this e-mail is a violation of federal criminal law. Applebee's
International, Inc. reserves the right to monitor and review the content of
all messages sent to and from this e-mail address. Messages sent to or from
this e-mail address may be stored on the Applebee's International, Inc. e-mail
system.
-------APPLEBEE'S INTERNATIONAL, INC.
CONFIDENTIALITY NOTICE------- PRIVILEGED / CONFIDENTIAL INFORMATION may be
contained in this message or any attachments. This information is strictly
confidential and may be subject to attorney-client privilege. This message is
intended only for the use of the named addressee. If you are not the intended
recipient of this message, unauthorized forwarding, printing, copying,
distribution, or using such information is strictly prohibited and may be
unlawful. If you have received this in error, you should kindly notify the
sender by reply e-mail and immediately destroy this message. Unauthorized
interception of this e-mail is a violation of federal criminal law. Applebee's
International, Inc. reserves the right to monitor and review the content of
all messages sent to and from this e-mail address. Messages sent to or from
this e-mail address may be stored on the Applebee's International, Inc. e-mail
system.
|
