How to remove specific events from the event log in Windows Server 2008
windows-event-logwindows-server-2008
Do I need a third party tool for this?
Best Answer
Microsoft purposely prevents you from doing this. The whole concept of the Event Viewer is to present to you certain events that may require your attention. If one could go in and delete any random event, then the system could - in a sense - be compromised without you knowing, therefore making it unsafe.
If you have an error event logged, find out what is causing the problem and fix it. You don't want to patch a hole in a dam by sticking a wad of gum in the hole.
If something is logging informational or caution events too often, then many times the event log source (either Microsoft or a third-party) has some setting that indicates how often or to what level of logging is configured for the application. That is where you go to minimize the logging, not by doing surgery on the event log.
I would strongly recommend NOT using Win32_Product if you can avoid it. First, it is really, really slow. Second, and more significant is that you can screw up your system:
The Win32_Product class works by enumerating every MSI package that is installed on the system. When a package is touched, it performs a reconfiguration where the application is validated (and repaired if found to be inconsistent with the original MSI).
This can be a huge problem if you have applications that were configured after install (i.e. previously disabled services can be re-enabled, etc.)
As an alternative, you can do a search on a particular file and check its version to see if an application is installed. Here is a link to a blog post I did describing the technique (and also has a link to an article by Darren Mar-Elia discussing Win32_Product):
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:
Filter out the informational alerts so that you're just seeing warnings and errors.
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.
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:
Configure the tool to watch for specific entries and alert on them
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.
Best Answer
Microsoft purposely prevents you from doing this. The whole concept of the Event Viewer is to present to you certain events that may require your attention. If one could go in and delete any random event, then the system could - in a sense - be compromised without you knowing, therefore making it unsafe.
If you have an error event logged, find out what is causing the problem and fix it. You don't want to patch a hole in a dam by sticking a wad of gum in the hole.
If something is logging informational or caution events too often, then many times the event log source (either Microsoft or a third-party) has some setting that indicates how often or to what level of logging is configured for the application. That is where you go to minimize the logging, not by doing surgery on the event log.