I'll see your Eurocents and add raise you two. :)

I fully understand where you're coming from Ulf.  Adding this information
into the DIT when it is currently possible to get is something that grates
against common sense and common engineering principles even if you subscribe
to belts and braces methodologies. 

However, I think two things make this a worthwhile request with a big
payoff.  First to Laura's point about diminishing returns.  I agree, at some
point there will be diminishing returns.  I also believe that as hardware
gets bigger (i.e. Standard 80 GB hard drives, 1 GB memory in workstation
machines, etc. [1]) the bar gets raised until we get to the diminishing
return.  Since we're targeting 80/20 out of the box [2] it seems reasonable
that 80% of the deployments would benefit from such a change. The other 20
would be those that a) don't care or know about such things and b) those
that can't tolerate the additional overhead and therefore wouldn't want to
deploy it.  I say tough pickles to them.  :)  Seriously, this could be on by
default but configurable (group policy?) to disable it as a performance
issue etc. 

Second, I think that the major benefit is the ability to actually get usable
information native to the product vs. having to invest in a third party
product. Why?  Because today in order to get that information I have to have
something that scrapes the Security logs looking for such information.  Is
this a good idea?  I think it is.  Is it something that could be native?  I
think it could and should be native if technically feasible. 

Making us look in a particular DC's event logs is more difficult than it
should be without yet another product.  That's fine for the really large
companies that have deeper pockets, and larger needs.  For the small to
medium businesses, it should not be so difficult nor should it *require* SQL
licensing or expertise.  



[1] I'm not saying that the quality has kept up, only that the hardware is
bigger, faster, stronger and cheaper. 
[2] I'm making that up, but it sounds reasonable




-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B.
Simon-Weidner
Sent: Sunday, October 16, 2005 4:42 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Knowing when users were deleted.


Hmm.

Do we really want to excuse prior failure of proper auditing by putting more
data into AD? Wouldn't that lead into every request of non-configured
auditing to requests for extending the AD? Do it right the first way.

I completely agree that we should make the people more auditing aware, and
it would be great to have a centralized auditing together with some force of
configuration instead of the per server events and auditing which is rearly
configured.

However I'm not sure if I want this kind of data in the AD.

Just my Eurocents.

Ulf 

|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED] On Behalf Of Laura 
|E. Hunter
|Sent: Sunday, October 16, 2005 10:28 PM
|To: ActiveDir@mail.activedir.org
|Subject: Re: [ActiveDir] Knowing when users were deleted.
|
|Various thoughts from this thread:
|
|[1] I agree with Al and Paul[1] on a desire for that sort of metadata.  
|I'm not as convinced of the trade-off value of bloating the DIT for 
|full undelete information, particularly in monster big environments.
|For my teeny-tiny single domain it probably wouldn't be that 
|bad of a hit, but I imagine that the laws of diminishing 
|returns would quickly set in.
|
|[2] Please finish the thought, Brett, I'm sure I'd find it
|helpful/enlightening/informative even if it's only speaking in 
|hypotheticals.
|
|[3] It's Gil and Darren's turn to crack me up today, I guess
|joe is taking a break.
|
|
|[1] *waves*  Hi Paul!  Glad to see you alive post-Summit.
|
|- L
|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/
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