The OP's post is valid. The number one problem with logging, error reporting, and alerting is white noise. When too many "errors" are reported and most of them are low priority or of no concern at all, administrators tend to ignore ALL errors. Good or bad, this is just a fact of life.
One of the errors he is talking about is (I think) event ID 1111. It simply means that you have a printer mapped with a driver that is not available on the server to which you are connected. It is an error of no concern in most cases ... there is nothing to "fix" as it is not a problem.
If you want to find actual problems and you have specific event ID's that you don't care to weed through, create a custom view with the following steps:
In your event log click on
"Filter Current Log" in the action
pane.
About half way down the dialog box
that pops up, you will find a text
box with <All Event IDs>
Replace this text with your filter
needs.
If you want only a certain
event, put that event ID in there.
If you have multiples, use commas to
separate.
If you wish to exclude,
use a minus sign.
In this case we
would use "-1111" (without the
quotes of course).
Click "OK" on the dialog box.
In the action pane you now click
"Save Filter to Custom View".
Now when you wish to look at your event log, use your custom view and only the information you are truly concerned with will be displayed.
I know that this is a late post to a dead thread but hopefully it helps someone else who is Googling this more than posts of "[Working as intended, n00b!]" ;-)
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.
The only thing you can do in Windows is clear the whole log.
I only found one third party app that claims to do this -Winzapper, however I have never used it and it states it is for NT and 2000 so I do not know if it will work for server 2003/2008. Be aware that there is potential for corruption of the Event log when using these, so tread carfeully.
What might solve your problem is to change the audit policies in group policy. Without knowing what specifically you want to not show up, I'm not sure if there's a setting for it, but here's an example.
In GPMC, drill down through Computer Configuration - Windows Settings - Security Settings - Local Policies - Audit Policy. There's not a TON of granularity here, but maybe you can get rid of what's filling up your logs. (My DCs aren't 2008, so this is what I've got from a 2003 AD perspective, hopefully it's not completely different)
There is no supported way to delete individual log entries from Windows Event Logs. This is purposely designed that way for a number of very good reasons.
The best way to address undesired log entries is to handle the events that generate them appropriately within the application. Also, selecting the appropriate log level, i.e. verbose, information, warning, error, and critical error, for each message being written is an important component in providing logs that are easy to filter. Some logging frameworks also provide the ability to roll up repeated identical events to a single log entry with a count.
Unfortunately, I have seen quite a few comments from people who appear to be missing a fundamental grasp of key computer security concepts. The events in a log, especially a security event log, are immutable for a reason. If events in the security event log could be deleted you would be lessening the security of the computer far more than having someone's password in the log because they typed it into the wrong text box. Good OS designers know understand that people make mistakes and that a user's password may show up in the security event log. It is one of the reasons why security event logs are only allowed to be viewed by Administrators.
Providing the ability to delete individual events from the security log, however, allows an attacker to conceal their activities in a way that is much more difficult to spot than when clearing the entire log is the only delete-type operation that is provided.
As a case in point refer to the Cover Tracks section on the Open Web Application Security Project (OWASP) site's Error Handling, Auditing and Logging page which states:
Cover Tracks
The top prize in logging mechanism attacks goes to the contender who
can delete or manipulate log entries at a granular level, "as though
the event never even happened!". Intrusion and deployment of rootkits
allows an attacker to utilize specialized tools that may assist or
automate the manipulation of known log files. In most cases, log files
may only be manipulated by users with root / administrator privileges,
or via approved log manipulation applications. As a general rule,
logging mechanisms should aim to prevent manipulation at a granular
level since an attacker can hide their tracks for a considerable
length of time without being detected. Simple question; if you were
being compromised by an attacker, would the intrusion be more obvious
if your log file was abnormally large or small, or if it appeared like
every other day's log?
I would further argue that anyone who has administrative access to a system should be engaging in a higher level of caution and attention to detail to begin with. Part of that is double-checking work as it is performed and stopping to read even common dialog boxes to safeguard against damaging mistakes.
The OP's post is valid. The number one problem with logging, error reporting, and alerting is white noise. When too many "errors" are reported and most of them are low priority or of no concern at all, administrators tend to ignore ALL errors. Good or bad, this is just a fact of life.
One of the errors he is talking about is (I think) event ID 1111. It simply means that you have a printer mapped with a driver that is not available on the server to which you are connected. It is an error of no concern in most cases ... there is nothing to "fix" as it is not a problem.
If you want to find actual problems and you have specific event ID's that you don't care to weed through, create a custom view with the following steps:
<All Event IDs>
Now when you wish to look at your event log, use your custom view and only the information you are truly concerned with will be displayed.
I know that this is a late post to a dead thread but hopefully it helps someone else who is Googling this more than posts of "[Working as intended, n00b!]" ;-)
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.
The only thing you can do in Windows is clear the whole log. I only found one third party app that claims to do this -Winzapper, however I have never used it and it states it is for NT and 2000 so I do not know if it will work for server 2003/2008. Be aware that there is potential for corruption of the Event log when using these, so tread carfeully.
What might solve your problem is to change the audit policies in group policy. Without knowing what specifically you want to not show up, I'm not sure if there's a setting for it, but here's an example.
In GPMC, drill down through Computer Configuration - Windows Settings - Security Settings - Local Policies - Audit Policy. There's not a TON of granularity here, but maybe you can get rid of what's filling up your logs. (My DCs aren't 2008, so this is what I've got from a 2003 AD perspective, hopefully it's not completely different)
There is no supported way to delete individual log entries from Windows Event Logs. This is purposely designed that way for a number of very good reasons.
The best way to address undesired log entries is to handle the events that generate them appropriately within the application. Also, selecting the appropriate log level, i.e. verbose, information, warning, error, and critical error, for each message being written is an important component in providing logs that are easy to filter. Some logging frameworks also provide the ability to roll up repeated identical events to a single log entry with a count.
Unfortunately, I have seen quite a few comments from people who appear to be missing a fundamental grasp of key computer security concepts. The events in a log, especially a security event log, are immutable for a reason. If events in the security event log could be deleted you would be lessening the security of the computer far more than having someone's password in the log because they typed it into the wrong text box. Good OS designers know understand that people make mistakes and that a user's password may show up in the security event log. It is one of the reasons why security event logs are only allowed to be viewed by Administrators.
Providing the ability to delete individual events from the security log, however, allows an attacker to conceal their activities in a way that is much more difficult to spot than when clearing the entire log is the only delete-type operation that is provided. As a case in point refer to the Cover Tracks section on the Open Web Application Security Project (OWASP) site's Error Handling, Auditing and Logging page which states:
I would further argue that anyone who has administrative access to a system should be engaging in a higher level of caution and attention to detail to begin with. Part of that is double-checking work as it is performed and stopping to read even common dialog boxes to safeguard against damaging mistakes.
See also:
You can write a .net application to delete event log and event source.
Example source code as below:
Reference: http://msdn.microsoft.com/en-us/library/system.diagnostics.eventlog(v=vs.100).aspx
You can delete the entry from this share registry location to remove the event: