Mrtg (actually mrtg + rrdtool) and nagios are standard equipment in many an enterprise, mrtg in particular. You can get mrtg to graph damn near anything if you're good. Nagios in my opinion is better than MOM in certain respects, and it's free.
Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Sunday, October 16, 2005 10:02 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Knowing when users were deleted. <sorry .. I know...I know...lurk..lurk....> The consultant crowd who can't handle 300 SBS boxes hitting their inbox at 6 a.m have asked for a dashboard. I can handle a daily email.... they can't. At a NTuser group meeting I was at ...some of the dashboard tools in Linux were discussed. Nagios in particular was one they used for monitoring. Monitoring -- MRTG: The Multi Router Traffic Grapher: http://mrtg.hdl.com/mrtg.html Graphical console for Snort - Analysis Console for Intrusion Databases (ACID): http://acidlab.sourceforge.net/ Intrustion detection - Snort.org: http://www.snort.org/ Monitoring - Nagios: Home: http://www.nagios.org/ Traffic probe - ntop - network top: http://www.ntop.org/head.html Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote: > 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/
