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: ActiveDir@mail.activedir.org 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: ActiveDir@mail.activedir.org |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: ActiveDir@mail.activedir.org |> |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: ActiveDir@mail.activedir.org |> |>To: <ActiveDir@mail.activedir.org> |> |>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: ActiveDir@mail.activedir.org |> |>|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: 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/ |> |>| |> |> |> |> |> |>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/
