3

I have been managing Windows Server 2003 machines at work, but I am a software developer. (Please don't say 'hire a sysadmin', the point of this question is my own learning).

How do server admins learn what to look for in event viewer? Sometimes there will be strange things that I don't understand, many times there will be things that are always there that I simply ignore because they are always there.

Is there some resource somewhere that can train me on what is normal behavior for a Windows Server event viewer log and what things may spell disaster?

Or maybe there is some third party tool that will decipher them and make recommendations? I would prefer the learning route though.

MetaGuru
  • 896
  • 6
  • 22
  • 36

2 Answers2

5

The event logs are a clearing-house for any messages or errors thrown by the OS, its components, and any software installed on the system. So we can't fully cover all it's potential contents because there's unlimited potential things it could contain and they all require individual treatment.

One way to analyze event logs is:

  1. Filter out the informational alerts so that you're just seeing warnings and errors.
  2. Research each one in turn and attempt to resolve each one as you go. Google is a perfectly legitimate way of accomplishing this. If you're able to resolve an error so that it doesn't re-occur, great, case closed for that one. On to the next.
  3. If you can't resolve an error, try to determine whether it's benign or a genuine problem. If it's a genuine problem, escalate it. If it isn't, add it to your 'known error' records (or mental 'ignore this' pool) and move on to the next error.

That's about all there is to it. Security Event Log auditing is a bit different but Application and System can usually be covered pretty well with the approach above.

You can set up monitoring/alerting packages to watch event logs and alert you. There's 2 typical approaches to this:

  1. Configure the tool to watch for specific entries and alert on them
  2. Configure the tool to ignore known benign entries and alert on everything else

Each approach has its strengths. One key thing to remember though is that a monitoring tool is only as useful as its configured to be, and there's no 'magic bullet' for this that'll give you a good blend of 'quiet enough' and 'guaranteed to alert you every time there's a genuine problem'. Unfortunately that requires continuous balancing.

Chris Thorpe
  • 9,953
  • 23
  • 33
  • I have been an SBS admin for 10 years and that is the best answer one can give. I would elaborate: Much depends, too, on the specific applications and roles of the server--does it have IIS, is it a DC? etc. You will find one of three things: 1) It's a real problem and you can fix it (or get it fixed), 2) It's a real problem but it doesn't affect you and you can't reasonably fix it (such as, the fix breaks something else) or 3) It is a spurious noise message that you can ignore. It'll take a while to figure out. Don't get too obsessed--or ignorant. – dmoisan May 03 '11 at 12:57
1

An additional piece of advice, if you're running good server-quality hardware, is to run the free monitoring software from the vendor. IBM has Director, HP has SIM, Dell has OpenManage. Each of these, when configured properly, will alert you about bad things - most specifically, about dead fans, high heat, impending disk failure from SMART alerts, or actual disk failure that you might not know about (when in a RAID volume.)

Other than hardware alerts, there's not much point to trawling through your event logs proactively (very often.) You'll most often use them to find the cause of problems after they have been reported. Of course, every environment is different, and as noted above, the Security log can be a different story if you have auditing or other security requirements (HIPAA, PCI, etc.)

mfinni
  • 36,144
  • 4
  • 53
  • 86