Outch - Sorry Brett! 

|-----Original Message-----
|From: [EMAIL PROTECTED] 
|[mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells
|Sent: Wednesday, October 19, 2005 5:20 AM
|To: Send - AD mailing list
|Subject: RE: [ActiveDir] Knowing when users were deleted.
|Importance: Low
|
|Such beauty in a mere typo -
|
|<Ulf>
|"Hi Bratt"
|</Ulf>
|
|... still laughing at the irony ;o)
|
|ah hahahahaha
|
|--
|Dean Wells
|MSEtechnology
|* Email: [EMAIL PROTECTED]
|http://msetechnology.com
|
|
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B.
|Simon-Weidner
|Sent: Tuesday, October 18, 2005 10:34 AM
|To: [email protected]
|Subject: RE: [ActiveDir] Knowing when users were deleted.
|
|Hi Bratt,
|
|I knew, however assuming performance and size issues I'd 
|prefer to get a better solutions within the OS for auditing AD 
|instead of bloating it up for retrieving "some" information.
|
|But thanks to your prior post I'd vote for a auditing within 
|AD as well, if it's even decreasing the metadata and doesn't 
|have a high impact on performance (I know - reading less data 
|is mostly better than worrying about the time it takes to be 
|decompressed, and depending how you would implement this this 
|might even be done distributed on the requesting machine).
|However - and I was impressed of your sharp brain at the 
|summit ;-) - the DCRs I've been involved with don't make me to 
|confident - even if it's you suggesting that - still a stony 
|path to take until we might see something like this.
|
|Ulf
|
||-----Original Message-----
||From: [EMAIL PROTECTED]
||[mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley
||Sent: Tuesday, October 18, 2005 4:02 PM
||To: [email protected]
||Subject: RE: [ActiveDir] Knowing when users were deleted.
||
||Ulf, what Al (well the suggestion on the plate) is suggesting is taht 
||the "something to centralize that info", _is_ AD replication. 
| Implying 
||the data is in AD.
||
||Cheers,
||-Brett
||
||
||On Tue, 18 Oct 2005, Ulf B. Simon-Weidner wrote:
||
||> |  Wherever the information gets put, it should be a) done as the 
||> |default yet configurable b) centrally viewable (I should
||NOT have to
||> |visit each DC in my forest to find the data) and
||> |c) be included in the base product.
||> 
||> Exactly, that's what I ment. Enable that logging by default and 
||> provide something to centralize that info.
||> 
||> |-----Original Message-----
||> |From: [EMAIL PROTECTED]
||> |[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick
||> |Sent: Tuesday, October 18, 2005 2:42 AM
||> |To: [email protected]
||> |Subject: RE: [ActiveDir] Knowing when users were deleted.
||> |
||> |Not sure that's going to fix the issue though, unless I'm missing 
||> |something.
||> |  Wherever the information gets put, it should be a) done as the 
||> |default yet configurable b) centrally viewable (I should
||NOT have to
||> |visit each DC in my forest to find the data) and
||> |c) be included in the base product.  I can see no valuable way to 
||> |otherwise do this.  Having to deploy yet another product
||doesn't fix
||> |the problem, it exacerbates it; it's even worse if it's a
||reskit item
||> |as those aren't "supported" nor as heavily tested.  This is
||important
||> |enough that it should be and should meet those criteria above.
||> |
||> |We may just need to knock a few more edges off before
||submitting this
||> |FMR ;)
||> |
||> |
||> |>From: "Ulf B. Simon-Weidner" <[EMAIL PROTECTED]>
||> |>Reply-To: [email protected]
||> |>To: <[email protected]>
||> |>Subject: RE: [ActiveDir] Knowing when users were deleted.
||> |>Date: Mon, 17 Oct 2005 23:36:44 +0200
||> |>
||> |>Another Hmm.
||> |>
||> |>I'd still like to see that better configured that putting it into 
||> |>the AD if the infos are already there (or configurable). We could 
||> |>request to make it default to log that kind of info. And 
|as far as 
||> |>we are talking about looking into every server: Where's ACS? And 
||> |>also SNMP would be an option to get notified on a single system 
||> |>instead of looking into every DC.
||> |>
||> |>Ulf
||> |>
||> |>|-----Original Message-----
||> |>|From: [EMAIL PROTECTED]
||> |>|[mailto:[EMAIL PROTECTED] On Behalf Of
||Al Mulnick
||> |>|Sent: Monday, October 17, 2005 3:10 AM
||> |>|To: [email protected]
||> |>|Subject: RE: [ActiveDir] Knowing when users were deleted.
||> |>|
||> |>|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: [email protected]
||> |>|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: [email protected]
||> |>||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/
||> |>|
||> |>
||> |>
||> |>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/
||> 
||
||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/
|


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