I suppose that this is why they pay folks who devise solutions to make this stuff work like it's supposed to the big bucks.
<shrug> Rick [msft] -- Posting is provided "AS IS", and confers no rights or warranties ... -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Sunday, October 16, 2005 8:54 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Knowing when users were deleted. Yup information overload 'is' a problem. And then after the scale its... okay what the heck is the server trying to tell me? I'm still a fan of www.eventid.net over microsoft.com's click here. Rick Kingslan wrote: >And, as you know that does work well in SBSland. However, when the >scale grows, so do the requirements. IN the Medium to Enterprise >space, the idea is more along the lines of a system or series of >systems pumping this type of information into paging and making >intelligent decisions based on the audit, event, alerts, services, etc. > >Which, is right where MOM 2005 drops into the picture. If it _IS_ the >event aggregator, or if it's pushing up to a bigger overall item such >as HP OpenView - that data is available. It's just that instead of >getting an e-mail per server (most admins would just begin to create a >rule to send these to DEV/NUL after a while...) MOM collects, enforces >and reports this same type of information. > >Scale makes the problem much tougher, as I'm sure you can imagine.... > >Rick [msft] >-- >Posting is provided "AS IS", and confers no rights or warranties ... > > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, >CPA aka Ebitz - SBS Rocks [MVP] >Sent: Sunday, October 16, 2005 8:33 PM >To: ActiveDir@mail.activedir.org >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: 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/ >> >> >> >> >> > > > -- 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/
