| 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/
