I've discussed something like this recently: display a monitoring summary at every admin login, e.g. instead of the annoying configure your server thingie ;-) There are just to many admins not paying any attention to the event logs, so if they don't go into event logs bring the event logs to them :D
Ulf |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Susan |Bradley, CPA aka Ebitz - SBS Rocks [MVP] |Sent: Monday, October 17, 2005 3:33 AM |To: [email protected] |Subject: Re: [ActiveDir] Knowing when users were deleted. | |<here she goes again.. I know ... I'm terrible at lurking> | |In SBSland we have a daily monitoring email [well ... I send |it daily anyway, but it's configurable] and it looks at the |event logs and tells daily health status of my server. | |Like today my email tells me my server has been running for 6 |hours [just rebooted it last night] and it gives me an |overview if auto services are not running, critical alerts and |critical errors in the event logs. | |It tells me memory/disk size, cpu use, top processes, if the |backup ran, and aggregates the alerts from all the log files. | |It's a health mon that dumps it's data into a msde database |and builds the email to be sent internally or externally. | |What it does now, is only pulls data from the one box, the SBS |box. but I can go into health mon and build my own monitors |and grab those event logs from other machines [need to so that |just haven't gotten around to it]. | |Right now if someone [usually me] fat fingers a password, for |example, it gives me an alert in the email of the last time it |occurred and how many occurrances. Basically it's tracking |the critical alerts in all the event logs and summarizing the |events along with the number of events in the email [and |showing the last time the event occurred so you can start your |investigation from that point back] | |For SBS ....it's in the box, it's a gui wizard that builds |this pretty little html email that my server builds and hits |me every morning at 6 a.m and says "Hey here's how I'm |doing...how are you?". It's the mid market that doesn't have |this. [and yes, we've told Mothership Redmond they need to |steal this sucker and put it in the mid market server bundle] | |Does it make me more aware of events on my server? Oh you |betcha it does. Which is why this needs to be ....as you |say...native in small and medium servers....heck I'd strongly |argue that no server should be shipped without some admin |somewhere getting an in your face report on that sucker. | |I'll go to Frys and buy bigger harddrives if I need to. But |give me a big fat audit log file and I'm a happy camper. | | |Al Mulnick wrote: | |>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/ |> |> |> | |-- |Letting your vendors set your risk analysis these days? |http://www.threatcode.com | |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/
