Show/Hide Toolbars

MonitorWare Agent

Navigation: Configuring MonitorWare Agent > Services

Event Log Monitor

Scroll Prev Top Next More

This dialog configures the Windows Event Log Monitor service.


This service was intially introduced by Adiscon's EventReporter product. To allow previous EventReporter customers seamless upgrades, there are a number of compatibility settings to support older message formats.


Newer Windows versions come with a considerably changed event logging system. In theory, the Event Log Monitor works with them, too. However, we know of some incompatibilities. For best results, we recommend using the Event Log Monitor V2 service, which was specifically written for Windows Vista and newer. The Event Log Monitor described here is applicable for Windows 2000, 2003 and XP (where the new event logging system is not available). The Client will automatically detect and load available EventLog types during the first startup of the Event Log Monitor.


Event Log Monitor

Event Log Monitor V2

Windows 2000

Windows Vista

Windows XP

Windows 2008

Windows 2003

Windows 7

Windows 8

Windows 2012

Windows 10

Windows 2016




Event Log Monitor Properties



The most important part of this dialog is the table in the middle. It specifies which event logs are to be monitored. In the screenshot above, the monitor is set to all Windows-native event log types that can possibly occur. However, there might also be custom event logs. Such custom logs can be created by any application. For example, an application "MySuperApp" might create an event log "MySuperAppLog". Then, it might log its messages into this log and not the Windows application event log.


In order to support such custom event logs, the log monitor allows an unlimited number of additional logs to be added to it. In order to do so, press the "Insert" button. A new log is added to the bottom of the list. Then, you can edit its name in the "Eventlogtype Name" combox (yes, you can overwrite the provided values!).


Logs checked in the table are actually processed. Those unchecked are kept in the configuration, but are not processed.



General Options

The General Options available on this form are explained below:



Sleep Time

File Configuration fields:



The event log monitor periodically checks for new event log entries. The "Sleep Time" parameter specifies how often this happens. This value is in miliseconds.


We suggest a value of 60,000 milliseconds for the "Sleep Time". With that setting, the event log monitor checks for new events every 60 seconds. Larger periods can be specified for occasionally connected systems or if email delivery with few emails per day is intended.


Very security-aware environments might use a shorter interval. The event log monitor service is specifically designed to limit the burden on the monitored system. As such, resource usage is typically low, even with frequently run event log checks. However, we recommend not running the event log monitor more often than once a second.


Overrun Prevention Delay

File Configuration fields:



This property allows configuring a delay after generating an event. The time is the delay in milliseconds.


If run at a value of zero, the event log monitor service generates events as fast as the machine permits. We have seen scenarios where routers and receivers are not able to keep up with this rate, resulting in packet loss. In addition, the CPU of the reporting machine is run at 100% - which is not a problem because the service runs at a low priority. However, with even a 1-millisecond delay, there is no noticeable CPU activity even when large bursts of events are forwarded. At one millisecond, the service can still generate 1000 events per second.


The default setting is an overrun protection of five millisecond, which allows roughly 200 events per second. This should be sufficient for even very busy servers.


Prefered Language

File Configuration fields:



You can select a prefered language, and the Eventlog Monitor will send the message in this language. It will only work if these languages are installed and message libs are available with the prefered language. If this fails, it will automatically fall back to the system default language.


Enable Remote EventLog Monitoring

File Configuration fields:



If enabled, the EventLog Monitor will read and process the EventLog from a remote machine. Use the verify button to make sure that the network connection is working correctly


Please make sure that the machine, which you are going to monitor, does have File and Print Services enabled and is accessible by this machine.

This is important as the EventLog Service will read the message libraries on the remote machine by using the default administrative shares. For this reason, the Service must be configured to run with a user who has administrative privileges/permissions on the local and remote machine. If File and Print services remain disabled, the local message libraries will used automatically instead. Note that you may experience a lot of missing message libraries in this case.


Additionally you have an option to read the EventLog Sources from the local machine. If enabled, the local message libraries will be used instead of the remote machines ones. Sometimes local Event Sources are more reliable or are required for thirdparty EventLog implementations.


Compress Control Characters

File Configuration fields:



This option allows you to control the control character removal and space compression. If checked, control characters (e.g. CR, LF, TAB - non printable characters in general) are removed. Also multiple spaces are compressed to a single one. By default this is checked. We recommend keeping it checked for most cases as it provides better display.


Please note that it should be unchecked if events should be forwarded via email. And it MUST be turned off if double-byte character sets are being processed (e.g. Japanese).


Do NOT process existing entries when Event log corruption occurs

File Configuration fields:



When this option is checked, it prevents from reprocessing of the whole Windows event log when it is corrupted or truncated. So EventReporter / MonitorWare Agent do not processes all entries again.


Do NOT process existing entries on Service Startup

File Configuration fields:



When this option is checked, it prevents from reprocessing of the whole Windows event log when the EventReporter / MonitorWare Agent service is restarted.



Remove Control Characters from String Parameters

File Configuration fields:



Enable this option to remove control characters like carriage return or line feeds from  parameter strings and category names in Winows Events.


Default Buffersize

File Configuration fields:



The default Buffersize is 10k. This value will be increased or decreased dynamically if necessary. If you want to use thirdparty applications like Netapp you must increase the Buffersize manually (minimum 65k), because dynamic adjusting is not possible with them.


SyslogTag Value

File Configuration fields:



The SyslogTag Value determines the SyslogTag that is used when forwarding Events via syslog. This is useful, if you want to determine later, what kind of syslog message this is, perhaps because you log EventLogs and syslog into the same database.


How to handle Eventlog Corruption

File Configuration fields:

0 = Retry processing from beginning

1 = Ignore corrupted Eventlog entry

2 = Clear all events from Eventlog


Sometimes it can occur that Eventlog messages are corrupted and cannot be read correctly. This usually happens if someone tampered with the Eventlog or if you are processing the Eventlog for the first time. In cases like this, you can automatically handle the situation with this option. You have the following options:

- Retry processing Eventlog from the beginning: in this case the complete Eventlog will be processed again.

- Ignore corrupted Eventlog entry (default): the affected Eventlog entry will be ignored and processing will continue.

- Clear all Events from the Eventlog: the Eventlog will be cleared completely and new Events hopefully don't get corrupted before they are processed.


Use Legacy Format

File Configuration fields:



This option enhances compatibility to scripts and products working with previous versions of EventReporter. The legacy format contains all Windows event log properties within the message itself.


The new format includes the plain text message only. The additional information fields (like event ID or event source) are part of the XML formatted event data. If the new format is used, we highly recommend sending or storing information in XML format. This is an option in each of the action properties (of those actions that support it – the write to database option for example always stores the fields separated, so there is no specific option to do so).


Legacy format is meant to support existing parser scripts. We encourage you to use the new, XML-bound format for new implemtations. Legacy format will be maintained in future releases to support backward compatibility, but it is no longer actively being developed. There are some shortcomings in legacy format, which can lead to issues when building or operating a log parser. These shortcomings are by design. We will not change this in legacy format - the solution is to use the new format. After all, the new format was created in order to address the issues with legacy format.


Add Facility String

File Configuration fields:



If checked, facility identification is perpended to the message text generated. This parameter enhances compatibility with existing Syslog programs and greatly facilitates parsing the generated entries on the Syslog server. We strongly encourage users to use this enhancement.


This setting only applies if the "Use Legacy Format " option is checked. Otherwise, it does not have any meaning and consequently cannot be configured in that case.


Add Username

File Configuration fields:



If checked, the Windows user that generated the event log entry is transmitted. If unchecked, this information is not forwarded. This is a configurable option for customers who have written parsing scripts for a previous format which did not contain Usernames. This option must also be unchecked if MoniLog is being used.


This setting only applies if the "Use Legacy Format " option is checked. Otherwise, it does not have any meaning and consequently cannot be configured in that case.


Add Log Type

File Configuration fields:



If checked, then log types e.g. system, security etc. etc. is perpended to the generated message.


This setting only applies if the "Use Legacy Format " option is checked. Otherwise, it does not have any meaning and consequently cannot be configured in that case.


Syslog Message Numbers

File Configuration fields:



If checked, a continuously advancing message number is perpended to the generated message. This is useful for Syslog delivery to make sure that all messages have been received at the remote server.


This setting only applies if the "Use Legacy Format " option is checked. Otherwise, it does not have any meaning and consequently cannot be configured in that case.


Delay writing LastRecord

File Configuration fields:



Enables the LastRecord writeback delay to the configured properties below.


Save after amount of entries

File Configuration fields:



The LastRecord will be written after the amount of processed eventlog

entries that are specified here.



Event Log Channels Tab


The "Event Log Channels" are basically a list of the different log types. The corresponding log is only be processed if the respective "Enable" checkbox is checked. The parameters are common to all logs and are explained only once.



Event Log Monitor - EventLog Types General Options



Report Truncated Log

File Configuration fields:



Windows event logs can be truncated programmatically or via the Windows Event Viewer program. When a log is truncated, all information is erased from it. Any entries not already processed by the service are lost.


The service detects event log truncation. If "Report Truncated Log" is checked, it generates a separate message stating the truncation. This option is most useful in environments where truncation is not expected and as such might be an indication of system compromise.


If you regularly truncate the Windows event logs as part of your day-to-day operation, we suggest you turn this option off. In this case, we also recommend using a short sleep period (for example 10,000 which is 10 seconds) to avoid losing log entries.


Do not Process Existing Entries

File Configuration fields:



If you don't want to get a dump of an existing specific Windows event log then use this option. When MonitorWare Agent / EventReport are restarted it will start processing after that last entry and do not look for the prevoius entries.


Try to convert Security IDs (SID) to Object Names

File Configuration fields:



With this option you can convert Security ID's (SIDs) to object names. You can enable this feature in the advanced configuration of each event log type in the Event Log Monitor service. Simple check the "Try to convert Security IDs (SID) to Object Names" option.


Note that only the Security event log has this feature enabled by default. For all other event log types this feature is disabled by default.


Try to convert Active Directory Object Classes

File Configuration fields:



With this option you can convert ActiveDirectory Schema GUID's from Security Events on Domain Controllers to object names. For Example Event 565, which usually has a lot of these Schema GUID's! The GUID's are internally cached to speed up EventLog processing operations.


Note that only the Security event log has this feature enabled by default. For all other event log types this feature is disabled by default.


Use Checksum to verify the last processed Event

File Configuration fields:



A checksum of the last processed Event will be stored along with the LastRecord of an eventlog. This checksum is checked during each iteration. If the checksum does not match , we consider the EventLog has been altered, cleared or something else happened. In this case the EventLog is being reprocessed from the beginning.


Please note: This option will prevent you from modifying the LastRecord value. If you do, the whole EventLog will be reprocessed! Please note that this behavior is by design and cannot be avoided. So we recommend to use this feature only if you intend to double check if the LastRecord value is valid.


Always search for the last processed Event using this Checksum

File Configuration fields:



Usually, the last processed Event is determined by the LastRecord value. If the Checksum to verify the last processed Event is activated, then thie option to always search for the last processed Event using the Checksum is available. When activated, the last processed Event will also be always determined by the Checksum, not the LastRecord value.


Syslog Facility

File Configuration fields:



The Syslog facility to map information units stemming from this log to. Most useful if the message is to forward to a Syslog daemon.


Last Record

File Configuration fields:



Windows event log records are numbered serially, starting at one. The service records the last record processed. This textbox allows you to override this value.

Use it with caution!


If you would like a complete dump of a specific Windows event log, reset the "Last Record" to zero. If you missed some events, simply reset it to some lower value than currently set. It is possible to set "Last Record" to a higher value. This suspends event reporting until that record has been created. We strongly discourage to use this feature unless definitely needed.


Read Eventlog From File

File Configuration fields:



When enabled, the Eventlog is read from a file instead from the system.


File&Path Name

File Configuration fields:



It defines that which file to be read, only available when "Read Eventlog From File" is enabled.


Type of Event Log

File Configuration fields:



It defines as which type of Event log from file is handled. This is important to read the correct message libs from the system.


Enable date replacement characters

File Configuration fields:



Allow the use of dynamic files/paths when using evt files. The same replacement characters as in the FileMonitor apply to this feature. A configured filename may look like this: C:\temp\evt_%Y%m%d.evt and would be replaced with C:\temp\evt_20130101.evt.


To support changing log file names, there are replacement characters available within the file name. These are:





Year with two digits (e.g. 2002 becomes "02")


Year with 4 digits


Month with two digits (e.g. March becomes "03")


Minute with two digits


Day of month with two digits (e.g. March, 1st becomes "01")


Hour as two digits


Seconds as two digits. It is hardly believed that this ever be used in reality.        


Weekday as one digit. 0 means Sunday, 1 Monday and so on.


Weekday as three-character string. Possible values are

"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat".

This replacement character is most useful for DHCP log files.


It contains the fully generated filename (Can be useful for filtering).


Only available if enable in the advanced option of the File Monitor. This value contains the current used messageseperator. This is usefull if you want to reconstruct messages where the seperator is part of the message.


Only available if enable in the advanced option of the File Monitor. This value contains the last used messageseperator. This is usefull if you want to reconstruct messages where the seperator is part of the message.

Character Replacement Table


Offset in Seconds

File Configuration fields:



When "Enable date replacement characters" is enabled, the current date will be used to generate the filenames. However in certain cases, there is a need to generate filenames with past or future dates. Negative values will generate past filenames, while positive values will generate filenames in the future. For example if you want to generate filenames from yesterday (24 hours back), use -84600 as offset.



Event Types to Log

These checkboxes allow local filtering of the event log. Filtering is based on the Windows event type. There is a checkbox corresponding to each Windows event type. Only checked event types will be processed. Unchecked ones will be ignored.


Filtering out unnecessary log types at this level enhances system performance because no information units will be generated and passed to the rule engine. Thus, Adiscon strongly recommends dropping unnecessary log types.



General Values (Common settings for most services)


Default Ruleset Name

File Configuration fields:



Name of the rule set to be used for this service. The Rule Set name must be a valid Rule Set.



Please Note if you intend to make the Event ID part of the actual Syslog message while forwarding to a Syslog Server then you have to make some changes in the Event Log Monitor Settings. Click here to know the settings.


The event log monitor caches messages libraries. This greatly speeds up processing, but causes memory consumption for the cached libraries. By default, libraries are chached for 30 minutes. If memory consumption is too high, you may consider to lower the cache period. The cache is global to all event log monitors. As such, its size must be changed in the general settings.