Adding to Schema

Good Afternoon,
I've been trying to research the best option for this one....

We have a front end application that allows users to update their basic AD
information (Address, phone, etc...). This works nicely with no impact on
AD. We've been asked to look at adding an option for users to enter
information on their job responsibilities as well as what they're currently
working on. The fields would be a max of 250 characters.

I would like to know if it's recommended to add this stuff as extended
attributes in to AD considering the data will never be the same and will be
free text. The other thing is that will this make a difference if we're
running on a large domain with DCs in multiple countries.

If this is not recommended, then are there any other easy options for
associating this information with AD but not actually adding it to the
schema. This way, I can help to guide the developers in the right direction.

Please let me know and thanks in advance for the Help!
T

If you want to add the data to AD, then there is no real important
difference between creating your own attribute and using an existing one.
The advantage of creating your own is that you are ensured that no one else
will ever use it for anything else since no other software will be built to
manage it. You will need to provide your own tools to manage the data
though. If you were to use description for this, you could also use ADUC
(which has UI for description).

If you really don't want to put the data in AD, you might consider storing
it in ADAM and creating a sync setup to sync your AD users with objects in
ADAM that would basically be pointers to AD users. The apps that read and
write the data would be coded to access it from ADAM.

This solution, while not that complex, is more complex than adding the data
to AD. However, it minimizes any impact of this data to AD replication or
DIT size.

So, it depends on what you are trying to optimize for. Any of the solutions
may be appropriate for you.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"tmpotvin" <tmpotvin@discussions.microsoft.com> wrote in message
news:A906E0E2-D456-481B-826F-DD900F59576A@microsoft.com...
> Good Afternoon,
> I've been trying to research the best option for this one....
>
> We have a front end application that allows users to update their basic AD
> information (Address, phone, etc...). This works nicely with no impact on
> AD. We've been asked to look at adding an option for users to enter
> information on their job responsibilities as well as what they're
> currently
> working on. The fields would be a max of 250 characters.
>
> I would like to know if it's recommended to add this stuff as extended
> attributes in to AD considering the data will never be the same and will
> be
> free text. The other thing is that will this make a difference if we're
> running on a large domain with DCs in multiple countries.
>
> If this is not recommended, then are there any other easy options for
> associating this information with AD but not actually adding it to the
> schema. This way, I can help to guide the developers in the right
> direction.
>
> Please let me know and thanks in advance for the Help!
> T

Thanks for the reply!

I will pass this information along.

"Joe Kaplan" wrote:

> If you want to add the data to AD, then there is no real important
> difference between creating your own attribute and using an existing one.
> The advantage of creating your own is that you are ensured that no one else
> will ever use it for anything else since no other software will be built to
> manage it. You will need to provide your own tools to manage the data
> though. If you were to use description for this, you could also use ADUC
> (which has UI for description).
>
> If you really don't want to put the data in AD, you might consider storing
> it in ADAM and creating a sync setup to sync your AD users with objects in
> ADAM that would basically be pointers to AD users. The apps that read and
> write the data would be coded to access it from ADAM.
>
> This solution, while not that complex, is more complex than adding the data
> to AD. However, it minimizes any impact of this data to AD replication or
> DIT size.
>
> So, it depends on what you are trying to optimize for. Any of the solutions
> may be appropriate for you.
>
> --
> Joe Kaplan-MS MVP Directory Services Programming
> Co-author of "The .NET Developer's Guide to Directory Services Programming"
> http://www.directoryprogramming.net
> "tmpotvin" <tmpotvin@discussions.microsoft.com> wrote in message
> news:A906E0E2-D456-481B-826F-DD900F59576A@microsoft.com...
> > Good Afternoon,
> > I've been trying to research the best option for this one....
> >
> > We have a front end application that allows users to update their basic AD
> > information (Address, phone, etc...). This works nicely with no impact on
> > AD. We've been asked to look at adding an option for users to enter
> > information on their job responsibilities as well as what they're
> > currently
> > working on. The fields would be a max of 250 characters.
> >
> > I would like to know if it's recommended to add this stuff as extended
> > attributes in to AD considering the data will never be the same and will
> > be
> > free text. The other thing is that will this make a difference if we're
> > running on a large domain with DCs in multiple countries.
> >
> > If this is not recommended, then are there any other easy options for
> > associating this information with AD but not actually adding it to the
> > schema. This way, I can help to guide the developers in the right
> > direction.
> >
> > Please let me know and thanks in advance for the Help!
> > T
>
>