Adiscon
EventReporter
User Manual

Version 5.4
2002-10-11

Table of Contents

  1. Introducing Adiscon EventReporter
    1. Features
    2. Components
    3. System Requirements
  2. Installation
    1. Full Install
    2. Engine-Only Install
  3. The EventReporter Client
    1. Launching the Client
    2. The General Tab
    3. Log Specific Tabs
    4. The Advanced Filter Configuration Dialog
    5. The License Tab
  4. The EventReporter Service
    1. The Service Account
    2. Command Line Switches
  5. Troubleshooting
    1. Getting Help
    2. Working with an instrumented Version
    3. Product Updates
    4. Frequently asked questions
  6. EventReporter Registry Keys
    1. General Parameters
    2. Log-Specific Parameters
    3. Filter Rule Sets
    4. How to use REGEDIT
  7. Background Information
    1. Facility Code
    2. XML Message Format
  8. Version History
  9. Purchasing EventReporter
    1. The License
    2. Pricing
    3. How to Order
  10. Miscellaneous

Introducing Adiscon EventReporter

Microsoft Windows NT™, Windows 2000™ and Windows XP™ are highly capable operating systems (we will call all of them "NT" in the following documentation). However, their standard event reporting mechanisms are rather limited. Administrators seeking complete control over their server environment need to regularly check the server event logs. Adiscon's EventReporter provides central notification of any events logged to the NT system event log. Messages can be delivered via email and syslog protocol.

The initial product - called EvntSLog - was specifically written with mixed NT and Unix environments in mind. It supported the syslog protocol only. It is currently in use by many large-scale commercial organizations, universities and government bodies (like the military) all around the world. EventReporter empowers data center operators to integrate NT event logs into their central syslog setup. Administrative duties and exception notification can easily be built via Unix-based scripting.

But smaller size organizations also demanded relive from checking server logs. As such, EventReporter allows delivery of NT event notifications via standard Internet email. Each server's events are gathered, filtered according to rules set up by the administrator and - if they matter - forwarded to the admin. Especially small sized organizations operating a single server can rest assured that they won't miss any important log entries.

EventReporter can be teamed with Adiscon's WinSyslog and the MoniLog product. In this scenario, it provides a totally centralized and automatted event log collection, monitoring and analysis solution. If you are looking for a solution that not only can forward event information but monitor additional system settings, you might want to have a look at the MonitorWare agent available at www.monitorware.com.

EventReporter is also a great tool for computer resellers, consultants and other service providers in need to monitor their customer's systems.

The product is easy to install and configure, uses only minimal system resources and is proven to be reliable. Furthermore, it is extremely inexpensive with a per system licensing fee starting at US$ 49.

Features

  • Centralized Logging

This is the key feature. EventReporter allows consolidation of multiple NT event logs and forward them automatically to either a system process or an administrator.

  • Ease of Use

Using the new EventReporter client interface, the product is very easy to setup and customize. We also support full documentation and support for large-scale  unattended installations.

  • Syslog Support

NT Event Messages can be forwarded using standard syslog protocol. NT severity classes are mapped to the corresponding syslog classes. Syslog facility codes are fully supported.

  • Email Support

NT event log information can also be delivered via standard Internet email. This option is an enabler for smaller organizations or service providers unattended monitoring their client's servers.

  • Local Filtering

EventReporter can locally filter events based on the NT event log type (e.g. "System" or "Application") as well as severity.

  • Full Windows 2000 and XP Support

We had full Windows 2000 and XP support since these products were released! All extended Windows 2000 log information can be gathered, fully decoded and submitted to the log targets (email or syslogd).

  • Robustness

EventReporter - under its previous name EvntSLog - is running in a large number of installations. It is written to perform robustly even under unusual circumstances. Its reliability has been proven at customers' sites since 1997.

  • Remote Administration

The client can be used to remotely manage EventReporter instances.

  • Minimal Resource Usage

EventReporter has no noticeable impact on system resources. It was specifically written with minimal resource usage in mind. In typical scenarios, it's footprint is barely traceable. This ensures it can also be installed on heavily loaded servers.

  • Full NT Event Log Decoding

EventReporter can fully decode all types of NT event log entries. It has the same capabilities like event viewer.

  • NT Service

The log forwarding process "the engine" is implemented as a native multithreaded Windows NT service. It can be controlled via the control panel services applet.

  • Runs on large Variety of NT Systems

NT 3.5(1), 4.0, 2000 or XP; Workstation or Server - EventReporter does run on all of them. We also have Compaq(Digital) ALPHA processor versions on platforms supporting this processor (engine only, available on request).

  • Double Byte Character Set Support (e. g. Japanese)

EventReporter supports characters encoded in double byte character sets (DBCS). This is mostly used with Asian languages like Japanese or Chinese. All DBCS strings are forwarded correctly to the syslog daemon or email recipient. However, the receiving side must also be able to process DBCS correctly. Adiscon's syslog daemon for Windows, WinSyslog, does so. The output character encoding is selectable and support Shift-JIS, JIS and EUC-JP for Japanese users.

  • Multi-Language Client

The EventReporter client comes with multiple languages ready to go. Out of the box, English, German and Japanese are supported. Languages can be switched instantly. Language settings are specific to a user.

Additional languages can be easily integrated using Adiscon's brand new XML based localization technology. We ask customers interested in an additional language for a little help with the translation work (roughly 1 hour of work). Adiscon will than happily create a new version. This service is free!

Components

EventReporter Client

The EventReporter Client is used to configure all components and features of EventReporter. The client can also be used to create a configuration profile on a base system. That profile can later be distributed to a large number of target systems.

EventReporter Service

The EventReporter Service runs as an NT Service and coordinates all log processing and forwarding activity at the monitored system (server or workstation).

The service is the only component component that needs to be installed on a monitored system. The EventReporter service is called the product "engine". As such, we call systems with only the service installed "engine-only" installations.

The EventReporter service runs in the background without any user intervention. It can be controlled via the control panel "services" applet or the "Computer Management" MMC under Windows 2000. The service operates as follows:

After starting, it periodically reads the NT event log. Each message is formatted and then sent to the given syslog daemon or email recipient. After all entries have been read, EventReporter goes to sleep and waits a given amount of time without any processing. This so-called "sleep period" is user configurable. As soon as the service returns from the sleep period, it once again iterates through the NT event logs. This processing continues until the process is stopped.

Due to its optimized structure, EventReporter uses only very minimal processing power. How much it uses mainly depends on how long the sleep period is. We recommend a sleep period between 1 and 5 minutes for syslog delivery and some hours up to 1 day for email delivery. However, feel free to customize this value according to your needs. We strongly recommend not to use sleep periods of 500 milliseconds or less (although possible).

System Requirements

EventReporter has minimal requirements.

The EventReporter client needs roughly 10 MB of disk space. The EventReporter client is optional and needs not to be present on a production system.

Engine-only installations require roughly 200 KB of disk space and 2MB of virtual memory. Please note that this is not actual used RAM - RAM usage is roughly 1 MB during iterations (can be higher for very large entries). During the idle period the engine does not need any actual RAM - just swap space. Idle periods are implemented via operation system sleep() calls which do not use any processor cycles at all. 

Please note that EventReporter is developed under Windows 2000 and XP. It is tested under Windows 2000, XP and  NT 4.0. Although not tested under NT 3.5(1), we do not see any reason why it shouldn’t perform well in this environment. EventReporter runs on top of Windows NT server and Windows NT Workstation. Under Windows 2000, the 3 additional event logs ("DNS Server", "File Replication Service" and "Directory Service" are automatically supported.

The default install set (most probably the one your found this documentation in) contains the executable for the Intel platform. However, there is an ALPHA version available on request. As ALPHA is not supported for Windows 2000 or XP, there are no ALPHA executable for that operating systems.

Installation

Installation is quick and easy. To facilitate mass rollouts, EventReporter has two setup modes:

  • Full Install
  • Engine-Only Install

The full install includes both the EventReporter client and service. In large environments, this is typically installed on a "master machine" being used to create the configuration parameters. The Engine-Only install includes the EventReporter service only. In large environments, that is the install process used primarily on a large number of target machines.

The EventReporter setup is based on Microsoft Windows Installer technology. So it can easily be integrated into MSI aware tools.

All users are highly encouraged to use the full install. It is the default install set downloadable from the EventReporter web site.

EventReporter must be installed by a user with administrative permissions.

Full Install

The install set (the ZIP file you downloaded) contains a standard setup program and it's necessary helper files. Please unzip the archive to any directory you like. This can be a local drive, a removable one or a remote share on a file server. A Win32 Unzip program can be found at http://www.winzip.com.

After unzipping, simply double-click "setup.exe" and follow the onscreen instructions.

Setup.exe will install the EventReporter client and copy the Service process to disk.

Full Install mode is highly recommend for first time instalations!

Engine-Only Install

There is no GUI setup program for an engine-only installation. The main purpose of this install mode is to roll out the product to a large number of machines.

Actual installation is straightforward

  1. Copy EvntSLog.exe to any location you like (on the machines local hard drive)
  2. Install it as a service by running "EvntSlog -i"
  3. Use regedit to customize its settings – most importantly the syslog daemon’s IP address (a .reg file can be used for this purpose).

Important

Please be sure to copy EvntSLog.exe to a directory on a local drive. The install process (EvntSLog -i) will install the service to run from the current working directory. If that is not on the local drive, you need to have access privileges to the file server EvntSLog is stored on. The default service account - local system - does not have such privileges. Thus service startup will fail. If you need this setup, be sure to set the service account to someone with sufficient privileges (via control panel services applet).

Customization of the EventReporter service is via the registry. Modifications can be made directly via RegEdit (see documentation on how to do that) or via the EventReporter client (which must then be installed). Please note that the registry "Parameters" key ("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
AdisconEvntSLog\Parameters")can be exported to a .reg file and re-imported by calling regedit. As such, a mass rollout can be fully scripted by the following batch file:

copy \\server\share\eventslog.exe c:\some-local-dir
cd \some-local-dir
evntslog -i
regedit \\server\share\configParms.reg

Users of any prior NT service versions of EventReporter can uninstall the old version via "EvntSlog -u" before installing the new one. Please note that uninstalling the service will also remove all configuration settings. Uninstallation of old service version is not required. All EventReporter service versions are able to work on the configuration settings of previous ones.

The EventReporter Client

The EventReporter Client is used to customize the product. It doesn't need to be installed in order to monitor a system. In fact, we recommend so-called "engine only installations" if a large number of machines are to be monitored.

The client loads the configuration parameters upon startup. Modifications are saved by clicking the "OK" button. Clicking the "Cancel" button will close the EventReporter Client without saving any modifications.

Launching the EventReporter Client

To run the EventReporter Client, click the "EventReporter Client" icon present in the EventReporter program folder located in the Start menu.

The EventReporter Client can also be launched from the command prompt:

  1. Open a Command Prompt window
  2. Change to the drive and directory where the EventReporter software is installed (default: "\Program Files\EventReporter")
  3. Type "cfgevntslog.exe" and hit enter.

Attention Windows XP Limited Users

EventReporter is a system administration tool. As such, administrative privileges are required to configure and operate it. If you do not have these permissions, the client can be started but it will simply display an error message pointing to the missing permissions. However, if the limited user has administrative rights on a remote machine, the user can connect to that remote machine and configure it from the machine he is running as a limited user.

The General Tab

This tab holds the general service parameters. They customize the behavior of all all log processing and formatting. 


EventReporter Client - General Tab
EventReporter Client - General Tab

  • Syslog Server

IP Address or computer name of the syslog server. For performance reasons, we recommend using an IP address. If a computer name is used, it must be resolvable (e.g. via DNS or the local hosts file).

The syslog service will receive all syslog messages if operating in syslog mode. It won't receive any messages if email delivery mode is selected. Email delivery mode can be selected in the log specific tabs.

If only email delivery is used, this property is ignored. You can simply leave it at the default (127.0.0.1).

  • Protocol Type

Defines which protocol should be used. UDP is always default, TCP is also possible (since Version 5.4). If you use TCP, make sure that your Syslog Server supports it.

  • Output Encoding

This setting specifies how the outgoing message should be encoded. It is mainly of use for Japanese characters. It should be left at "System Default" except when you know exactly why it is to be changed. 

  • Backup Syslog Server

All messages can be sent to a second syslog server, too. If "Send a copy of all messages to the following server" is checked, a duplicate of all generated messages is sent to the server specified in the textbox directly below the checkbox. This textbox again holds either the IP address or a resolvable name of a syslog server.

The "Backup Syslog Server" functionality was requested by a number of customers who operate under a very tight security policy. It will ensure that at least one syslog server will be able to receive the message, even if one is down for whatever reasons. Please note that due to the nature of the syslog protocol, there is no way for EventReporter to discover that the syslog server eventually is down. So if it is down, EventReporter will still send it's message and think it went well. As the syslog server wasn't able to process the message, it will actually be lost. Specifying a backup server will prevent this.

Important: If a backup server is selected, each message will be sent twice (once to each server). 

  • Sleep Time

This is the period in milliseconds that EventReporter will pause before re-processing the event log. Note that a millisecond is a thousands of a second, this the value of 5000 shown above means 5 seconds.

Be sure to use a reasonable high value for this parameter - if chosen too low, it can affect system performance. We recommend 60,000 for syslog delivery and 43,200,000 (12 hours) for email delivery.

Values below 500 are supported but we strongly advise not to use them.

  • Overrun delay prevention

This list box allows to configure a delay after sending a message. The time is the delay in milliseconds. If run at a value of 0, EventReporter forwards 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. Also, the CPU of the reporting machine is run at 100% - which is not a problem because EventReporter 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 1 millisecond, EventReporter can still forward 1000 events per second. The default setting is an overrun protection of 5 millisecond, which allows roughly 200 events per second to be forwarded. This should be sufficient for even very busy server.

  • Replace Computername

Use this setting if you want to overwrite the default computer name. This is useful if the  computer name is something like "PC1234".

  • Configure for MoniLog Button

When pressed, this button automatically sets all options in the way MoniLog expects them to be. If you intend to run the solution including MoniLog, this is a very easy way to set up things correctly. If you run EventReporter without MoniLog at the backend, this button is meaningless for you.

  • Compatibility Mode

EventReporter supports the relatively recent syslog RFC 3164. However, there are some limitations with that RFC, so EventReporter can be configured to support the options as required by the user.

In mode 0, the previous EventReporter format is generated which is not at all compatible with RFC 3164. However, many users have existing scripts which would be broken if the format changed. Mode 0 is for these users so that they don't need to change their scripts. We still recommend to plan to update them - we expect the syslog RFC to become more popular in the future so it might be a good idea to be able to use that format.

In mode 1, EventReporter generates a standard RFC 3164 header. However, it does not impose the size limitation of 1024 characters that the RFC requires. The reason simply is that NT Event messages - especially those with binary data - can be quite lengthy. So if your syslog deamon supports oversize messages, we highly recommend mode 1.

Also, for double byte character sets like Japanese, the 1024 byte character limit can be very short. Again, we recommend to not impose it.

In mode 2, EventReporter is fully compliant which includes imposing the 1024 character limit. Messages are truncated to fit into that limit. As there are no continuation lines defined in syslog, the truncated part is simply not sent. We recommend to use this mode only if absolutely needed.

  • Forward Binary Data

If checked, the binary data portion of the event log entry is forwarded. Please note that this data can be potentially very large. So we recommend checking that box only if definitely needed.

  • Send each Event in separate EMail

When EventReporter forwards event log entries via email, it typically combines many events in a single email. This is effcient from the view of the email system, but there might be situations where it is more feasable to have a single email per event. This box is checked, each event will be sent within it's own email. Please note that this can potentially generate a large amount of email traffic if no filters are applied.

  • Use Legacy Format

EventReporter 5.3 introduces a new extensible XML format for message reporting. This format has many advantages, but may conflict with existing scripts and applications that expect the old format. It is also a little bit more lengthy, so you might not want to use it if you stick with the 1024 character RFC limitation of the syslog message size.

If "Use Legacy Format" is checked, the previous format will be used. In that case, the following format options ("Additional Options") apply. If it is unchecked, the new XML format is used and the "Additional Options" do not apply and consequently can not be set.

MoniLog users please note: as of MoniLog 1.1, MoniLog requires the legacy format option to be checked.

  • AddFacilityString

If checked, a facility identification is prepended to the syslog message sent out. 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.

However, pre-version 3.2 customers might want to turn it off to preserve compatibility with their existing parsing scripts. These versions did not support the "facility string.

If using email delivery, we recommend checking this box. It extends the email format, too.

Please note that this option is not compliant with RFC 3164. In order to be compliant to that RFC, you need to turn on the respective compatibility mode. This setting here is for older scripts that require the respective string to be present in the EventReporter reported message.

  • Add Username

If checked, the NT 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 scripts to parse EventReporter's output. These scripts would be broken by the format change. So it needs to be explicitly enabled.

We highly recommend checking this option if you are a new customer or do not have scripts that require the user information to be omitted. From a security point of view, this is very valuable information.

  • Syslog Message Numbers

If checked, EventReporter generates an unique and incrementing number for each message it sends out. These messages can be used to detect potential disruption of message receipt at the server side. If unchecked, these numbers are not generated.

  • Add Logtype

If checked, the Logtype that generated the event log entry has, is transmitted. If unchecked, this information is not forwarded.

 

The Log Specific Tabs

A number of parameters can be specified on a per-log basis. NT support three different logs: System, Security and Application. Windows 2000 adds 3 more logs: Directory Services, DNS and File Replication Services.

The EventReporter Client can be used to customize settings for all of these log types. It has 6 tabs with equal parameters. Their meaning is the same, but each one customizes processing of a specific log type. They are named according to the log types. We describe these parameters only once.

Please note: the Windows 2000 logs can only be customized if the EventReporter Client is running on top of Windows 2000 or XP. If running on earlier operating system releases, these tabs are labeled as "Win2K only" and are disabled.


 EventReporter Client - Security Log Tab

  • Report Truncated Log

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

EventReporter detects event log truncation. If "Report Truncated Log" is checked, EventReporter will generate 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 NT 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 (10,000, which is 10 seconds) to avoid loosing log entries. 

  • Enable Logging

Specifies if this NT event log is to be processed at all. If unchecked, this part of the event log won't be processed. In this case, all other parameters on the tab are ignored.

  • Event Types to Log

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

  • Last Record

NT event log records are numbered sequentially, starting at 1. The EventReporter 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 NT event log, reset the "Last Record" to 0. 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 will suspend event reporting until that record has been created. We strongly discourage to use this feature unless definitely needed.

  • SMTP Properties

The SMTP Properties are used for email event reporting.

If email reporting is turned on, reports are forwarded as mail messages. One mail is generated per NT event log. Mails are only sent if there is anything to report. If there were no new event log entries since the last reporting run, no mails are generated. If the event type filter is, for example, set to "error only" and there are no errors to report for some days, there won't be any mails appearing. This was specifically done to prevent overwhelming administrators with unnecessary mail traffic.

Please note: if  email delivery is turned on for a specific part of the NT event log, syslog delivery will be turned off for that part.

  • Enable Mail Delivery

If checked, event log entries will be delivered by email rather than syslog protocol. This is called "email delivery mode".

Even if email delivery is unchecked, the other email properties can be configured. This is because the other settings are being used when an advanced filter action requests email to be sent (which is possible even though general email delivery has been disabled). Of course, if email will never be sent, the other configuration settings can be left blank.

  • Mail Server

IP address or resolvable computer name of the SMTP server to be used for sending mail messages. This server must support forwarding to the recipient. For performance reasons, we recommend using an IP address.

  • Sender

Email address (e. g. sender@adiscon.com) to be used as the sender address in outgoing event reports.

  • Recipient

Email address (e. g. admin@adiscon.com) of the intended recipient. Only a single email address can be specified. If you would like to send event reports to a group of people, please create a distribution list in your email system and specify it's address as the recipient address.

  • Subject

Subject line used in outgoing mail. Can be used for automatic filtering at the recipient site.

The subject line can contain place holders that will be replaced with actual event data before the email is send. This is especially useful when sending email to cellular phones or pagers, which often display only the subject line and not the actual message body. The subject line – after expansion of the replacement characters – can hold a maximum of 255 characters. Characters beyond this will be truncated. Please note that some email systems do impose a stricter limit and truncation as such might occur before the 255 character limit.

The following replacement characters can be used inside the subject line:

%s - event source as it is in the Windows event log

%i -  numeric event id

%m - the complete message itself. Please note: this is the complete message text and can be rather lengthy. As such, it is most probably subject to truncation. If that occurs, all other information after the %m replacement character is also truncated. As such, we strongly recommend using the %m replacement at the end of the subject line only.

%% - represents a single % sign.

Please note that the subject line will always reflect the values of the first event included in the email message. If there are multiple events inside the email, the other ones will not be reflected in the subject line. So subject line replacement characters are primarily meant for short notification messages, which are most probably triggered via the advanced filter configuration.

Please note that EventReporter can be instructed to send each event in a separate email message by the "Send each event in a separate email" general configuration setting. With that setting, you can assure that the subject line reflects the exact events. If you consider this option, please keep in mind that it potentially generates a large number of emails.

Please also keep in mind that most mobile providers (pagers, cell phones) do limit the number of messages a device can receive via email per day. After this hard-coded limit has been reached, most of them simply discard all other messages without any notification. If in doubt, check with your service provider.

  • "Copy Settings from 'System'" Button

This button is available on all log specific tabs except the system. When pressed, it simply copies all email configuration values from the system tab to the current one. This enables very quick email configuration if the same settings are to be used throughout all tabs.

  • Filter Rules

This checkbox activates advanced local filtering. If checked, the filter rule base for this log is processed. Advanced filter rules allow finer control about which messages are forwarded and which ones not.

Click "Advanced" to configure the advanced filter rule base for a specific log. Information on how to do that can be found in the following section. The "Advanced" button is only available if advanced filtering has been enabled. Please see the following section on how to configure advanced filtering.

By default, the Filter Rules checkbox is disabled.

The Advanced Filter Configuration Dialog

The advanced filter configuration dialog is available for all log types. It is enabled for a specific log type by checking the "Filter Rules" check box.

Advanced Filter Configuration
EventReporter Client - Advanced Filter Configuration

Advanced filtering works in combination with the basic, priority based filter mechanism. When EventReporter processes an event, it first checks if its event type is checked in the "Event types to log" settings. If it is not checked, the event will be ignored, no matter what is configured in the advanced filter configuration.

If it is checked, the event is to be processed. In this case the advanced filter configuration is applied. The filter rules are processed from top to bottom or from number 1 to the highest rule number. This is important, because as soon as a matching entry is found, this entry is applied. If its action is set to "Completely Discard", the event will be ignored. If it is set to "Use Default", the event will be forwarded to whatever event target (syslog daemon, email recipient) is configured. Starting with release 5.3, there are additional settings that allow to specifically request these events to be forwarded to email, syslog OR both together. The available options can be seen in screen shot 3 below. When working with this settings, keep in mind that the default action is whatever is configured in the respective log tab - so this is either email or syslog. With the filter action, carrying out both actions on the same event is possible.

Please note that rules can be more and less strict matching. In the above example, rule number 1 filters out event 180 of the ESE97 event source - only this event. The category is left blank, so it is not used to match. Rule 2 enables processing of event #20 of the "Print" event source (this is the printer driver added or removed event). Rule 3 disables (turns off) all events of the "Print" source. Rule 4 is a rule that specifically request the Exchange POP 3 logon failure event to be forwarded both via email and syslog. The effect of this setting is that

  • all ESE97 #180 events are ignored
  • printer messages in general are ignored
  • but printer event #20 (add/remove print driver) is nevertheless being reported (by whatever method is defined to be the notification method for this log part)
  • all "MSExchange POP3" #13003 events are being reported both via email and syslog
  • all other events are being reported by the default action (either email or syslog)

This happens, because the specific #20 printer event matches before the more general one. So if event #20 occurs, rule 2 matches and rule processing is terminated. Any other printer events will hit rule 3, where they match (because here only the event source is being matched, all other values are irrelevant and as such deemed to be matching).

Now look at this scenario. Rule #2 and 3 have been exchanged:


EventReporter Client - Filter Rule #2 and #3 exchanged.

Now no printer event would ever be reported, because the new rule #2 would always match. In this case, rule #3 would never be processed and as such event #20 would also be ignored.

Now let's focus on rule # 4:


EventReporter Client - Syslog AND EMail Delivery.

Here we do have action #6, "Send syslog and send email". This action will send both an email notification as well as a syslog message - no matter what is configured in the log specific tab. It will use the email settings configured in the log specific tag when sending mail.

One last question might be left from the scenario: why are all other events being reported? Fairly easy: if no rule matches, EventReporter assumes the event is to be processed by the default action. As such, there is no need for a "catch-all" rule at the end of the rule set - it is implicitly placed there by EventReporter.

Using clever ordering of the filter rules allows for highly complex filter scenarios. However, you should also keep in mind that complex rule sets can be hard to understand and troubleshoot.

Please also keep in mind that entered values (e. g. event source names) can not be verified by the EventReporter client, as all values are potentially valid. As such typos can not be detected and an ill-behaving advanced filter configuration can be caused by a simple typo. Please check your rule sets carefully. The client tries to avoid typos by reading out all registered event sources at the machine being configured. However, this might not be the complete set (some might not be correctly registered by the event source). As such, it is possible to enter any value - but the values in the list box should be a good starting point. 

The License Tab

The license tab is used to activate your EventReporter installation after activation.

After evaluation, EventReporter can be activated just by entering a correct registration name and number. There is no need to reinstall. The activation information is provided by Adiscon after purchasing.

Please note: the EventReporter Client can not verify the correctness of  the registration information. So it will accept any combination without complaint. However, if the information is incorrect, the EventReporter service will not switch into active state. For this reason, it will continue to report that it is unregistered. If you have purchased EventReporter licenses and are unable to turn off the services' registration reminder, you should check the exact registration information entered. There most probably is a typo in it.


EventReporter Client - License Tab

  • Registration Name

The registration name is chosen by you. It should correspond to your organization name, e.g. a company called "AA Carpenters, Inc." should not chose "AA" as registration name. This can easily be mistaken and most probably will be rejected by Adiscon for that reason. With the above scenario, we recommend using the full company name "AA Carpenters, Inc.".

Please note: the registration name is case sensitive. It must be entered exactly as given. Leading and trailing spaces are also part of the registration name, so be sure to enter none.

  • Registration Number

This number is provided by Adiscon. It is valid for a specific registration name. Be sure to enter the correct registration number. The EventReporter Client is unable to detect invalid registration numbers and as such can not detect any typos.

The EventReporter Service

The EventReporter Service is the component that runs on the source machine (the one reporting events). The service is also called the "engine" of EventReporter. It needs to be installed on every machine that needs to report events. 

EventReporter can be "engine only" installed. In this case, only the service is installed onto a machine. It can be customized either by directly editing the registry or copying a registry snapshot from a machine with installed client. Please note that "Engine Only" installs need a full EventReporter license.

The EventReporter service program is called "evntslog.exe". It is the sole executable that needs to be distributed for mass rollouts. Please note that it's name stems from pre-version 4.0 releases, which were called "EvntSLog". We have decided to retain this name in order not to break any custom created scripts.

The Service Account

NT Services must utilize an NT logon account in order to perform their intended tasks. The EventReporter Service is  no different. The account initially used by the service is "local system". We recommend to retain this setting.

If for any reason you would like to change the service account, you can do so via the control panel "services" applet (or the "Computer Management" MMC under Windows 2000 and XP). However, you need to make sure that the new account has permissions to read the system logs. We recommend assigning it "Administrator" privileges.

Command Line Switches

The EventReporter supports a limited set of command line switches. These are primarily used for unattended installations or "engine only" installs. These are:

evntslog -h Help, displays a short usage notice.
evntslog -i Installs the service
evntslog -u Removes (uninstalls) the service
evntslog -v Displays version information as well as whether or not the service is installed.

Troubleshooting

Getting Help

Do you need help with EventReporter or need an important question answered? No problem, there is lots of help available!

Please note that all options (except priority support) are also open to evaluating customers. So do not hesitate to try them. Help is available in English and German language. Our local resellers may provide local language support. Please check with them.

  • EventReporter Web Site

Visit the support area at http://www.eventreporter.com/en/support for further information. If for any reason that URL will ever become invalid, please visit http://www.adiscon.com for general information. 

  • Support Newsgroups

Share questions and answers with your peers! These groups are also monitored by Adiscon support staff.

NNTP (Newsreader) news://news.adiscon.com/adiscon.products.evntslog
HTTP (Web Browser) erftstadt.adiscon.com/exchange/root.asp?acs=anon
  • Email

support@adiscon.com - an appropriate subject line is highly appreciated

  • Phone

+49-2235-985004   (with "+" being the international dialing prefix, e.g. 011 in the US)

Please note that we are in the Central European Time zone (CET). That is 1 hour east of Greenwich. If it is 12pm in New York, it is 6pm at our office location. Our office hours are from 9am to 4pm. So we generally advise US customers to call in early mornings and Asian customers to call in late afternoon.

For best customer service, highly recommend limiting phone calls to emergencies. We are checking our other support options regularly.  

  • Fax

+49-2235-985032   (with "+" being the international dialing prefix, e.g. 011 in the US)

  • Software Maintenance

Software maintenance is available as part of our UpgradeInsurance package. UpgradeInsurance includes unlimited free updates and upgrades as well as priority support. It can be purchased at an annual fee of 20% of the product purchase price.

  • Non-Technical Questions

info@adiscon.com

This email alias will answer all non-technical questions like pricing, licensing or volume orders (51 licenses and up). 

Working with an instrumented Version

Unfortunately, no software product is totally bug-free. Due to the complex nature of software development, every product is expected to have some weird bugs that show up only on very rare occasions. We at Adiscon try our very best to avoid such bugs. However, we still see some of these bugs from time to time. 

If technical support is contacted and we see a bug but are unable to reproduce the error, we offer to created an "instrumented version". That is basically the current product, but with additional debugging codes in it. If the customer agrees to this, we basically try to reproduce the error on the failing system and gather diagnosis information while doing so. We do not sent any information to us automatically - so the process is totally secure. We need a person to send the data to us.

Here is how it works.

We use a Microsoft API (OutputDebugString) to generate the diagnostic information. As such, we send 2 files as the instrumented version. The first one is evntslog.exe, the new version with diagnosis code. This needs to be copied over the existing installed service. The service must be stopped in order to do so. The other file send is dbmon.exe, a program from Microsoft. It is used to capture the diagnosis information sent from the EventReporter service. It can be copied to any place on the machine's local hard drive.

To gather the diagnostic information, start dbmon.exe before starting the EventReporter service. A DOS-box like window will open. Click on it's system menu and select "Properties". Select the "Layout" tab. Adjust the screen buffer size to have a height of at least 1000 (one thousand) - more is better. Click "OK". A new dialog appears asking wether the properties should be applied to just the current window (default option) or the shortcut. Select whatever best fits your needs. If in doubt, select the default. 

Now start the EventReporter service. Messages will appear in the dbmon window. With an actual support case, Adiscon will instruct the user when to stop the EventReporter service. Once this is done, information from the dbmon window can be copied to a text file (notepad) via cut and paste.

Important: dbmon.exe needs to be active while the EventReporter service is running. Please do not stop it. Unfortunately dbmon is a console application and can not be run as a service. As such, someone needs to remain logged onto the machine as long as the test is running. Locking the machine is fine during that time.

Once the information is stored in the text file, the user might want to edit it and remove any offending information, e.g. internal IP addresses, passwords etc. Then, the file can be emailed to Adiscon for further analysis.

Product Updates

EventReporter has been developed since 1997. New versions and enhancements will be made available from time to time.

Please visit http://www.eventreporter.com for information about new and updated products. 

Frequently asked Questions

For a current list of Frequently Asked Questions (FAQ), please visit http://www.eventreporter.com/en/FAQ.

EventReporter Registry Keys

EventReporter is configurable via the registry. All parameters can be changed dynamically. They are reacquired during each iteration of Service event log read cycle. Please note that during a cycle or the sleep period, parameter changes do not have any effect!

The most common mistake is to use a very high sleep time, then modify it and expect EventReporter to immediately start running. In order to save valuable system resources, this is not possible. However, as soon as the service restarts or enters active state again, the new settings are in effect.

Starting with version 4.0, EventReporter has a GUI configuration program, the EventReporter Client. all options are customizable via the client. So there is no need to modify the registry directly. However, we still document the most important registry keys in order to facilitate mass rollouts and unattended installs. If you need to have complete registry details, please contact Adiscon support.

If you need to customize the product without the EventReporter client available, you can do so via Windows Regedit. Please see "How to use REGEDIT" if you are new to direct registry editing.

All EventReporter registry keys are stored under 

"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
Adiscon EvntSLog\Parameters"

and it's subkeys. There are 4 locations for configuration parameters:

  • directly under the "Parameters" key
  • "Parameters\System"
  • "Parameters\Security"
  • "Parameters\Application"

Windows 2000 specific parameters are stored in 3 additional subkeys:

  • "Parameters\DNS Server"
  • "Parameters\File Replication Service"
  • "Parameters\Directory Service"

All configuration parameters stored directly under the "Parameters" key modify the general processing mode of EventReporter, e. g. how long its sleep period will be.

The parameters below the other keys configure EventReporter when processing the respective part of the NT event log: the System, Security and Application, DNS, etc log. Under each of these keys there is the same set of parameters with the same names. Depending under which subkey they are stored, they'll configure EventReporter when processing the corresponding part of the NT event log. E. g. the nFacility parameter specifies the facility value to use when sending log entries to the syslogd. The nFacility under "Parameters\System" specifies the facility value for system event log entries while the same parameter under "Parameters\Application" specifies the facility level for application events.

General Parameters

All these are directly beneath the "Parameters" key.

nSleepTime

Type: DWORD value.

This one is important. It determines the sleep time in milliseconds. Please note the "milli" in this word. One second is 1000 milliseconds. The most common error is to specify 60 instead of 60000 if you want a sleep period of 1 minute.

nDBCSEnabled

Type: DWORD value.

This parameter controls handling of double byte character sets (DBCS). DBCS are used mostly for Asian languages like Japanese or Chinese. If the Windows event log contains entries with DBCS characters, this switch must be set, otherwise the messages most probably will not display correctly. If DBCS support is enabled, control character filtering and space compression is turned off.

Value 0 means DBCS is disabled. This is the default value. A value of 1 enables DBCS support in EventReporter.

szTarget

Type: string value

This is either the IP address or the system name of the system running the syslog daemon. You need to change this setting in order to make EventReporter do something intelligently, as the default is "127.0.0.1" which is your local machine. But there’s your event log anyway, isn’t it.

If you use a symbolic system name, be sure this one is resolvable either via DNS, WINS or the local hosts file. If it is not resolvable, EventREporter silently will not work.

For performance reasons, we recommend using an IP address rather than a symbolic name.

szTarget2

Type: string value

This parameter is optional. It is not written by the service installation script. Use szTarget2 if you want to send syslog messages to two machines at once. If present, szTarget2 is used as a backup host, which receives a copy of every message sent out to szTarget. Format is the same as szTarget. However, if this parameter is not present, no second message is sent (there is no default as in szTarget).

szLicensee

Type: string value

This is the name of the licensed user. The trial version does not have a licensee name string. It specifies "unregistered". If you register your copy of EventReporter, you specify the license string of your choice. If it is not already used by another user, you will receive a matching license number (next parameter, nLicenseKey) from Adiscon. Enter both the license name and key into the registry. This will turn off the trial version warning. If it doesn't turn them off, be sure to check if both the name and number are correctly entered.

Please note that this parameter is case-sensitive!

nLicenseKey

Type: DWORD value.

This is the license key issued by Adiscon. It must match the license name (szLicensee, see directly above). If it does not match, the EventReporter service will not recognize your installation as licensed.

bAddFacilityString

Type: DWORD value.

This controls enhanced compatibility to standard syslog format. If set to 1, the facility string "EvntSLog:" is added to the syslog message sent. EventReporter versions prior to 3.1 did not support this. So if you have written scripts to work together with pre 3.1 versions, you might need to turn this feature off in order to preserve your scripts. To turn this behavior off, set this parameter to 0.

This parameter also controls severity codes. They are output right after the facility sting ("EvntSLog:"). Severity codes are: [AUS] - audit success, [AUF] - audit failure, [WRN] - warning, [INF] - informational, [ERR] - error. Severity codes are only written if bAddFacilityString is 1.

iSyslog1OutputEncoding

Type: DWORD value.

This parameter is mostly of use for users with double byte character sets (e. g. Asian languages). It specifies the output encoding used for the syslog message sent to the szTaget1 syslog server. Possible values are:

Encoding Value
use system default 0
JIS (ISO-2022JP) 51220
EUC-JP 51932

The default value is 0, which uses the system default encoding.

iSyslog2OutputEncoding

Type: DWORD value.

Same like iSyslog1OutputEncoding except that it configures the encoding for the szTarget2 syslog server.  

nLastSyslogMsgNbr

Type: DWORD value.

Last message number used when sending syslog output. This is a simple counter that is incremented when each message is sent. There is no way to change this parameter via the client program (intentional left out).  

bShowSyslogMsgNbr

Type: DWORD value.

Boolean controlling the output of syslog message numbers. If set to 0, no message numbers will be generated. If set to non-zero (e.g. 1), each syslog message send has a unique message number (message ID). The numbers are incremented at each message. If they do not show up serially at the syslog daemon, messages have been lost. Turning on syslog message numbers is another security feature. If someone has managed to "steal" some messages, at least this fact is logged. The default value is 0 for compatibility reasons. We strongly recommend setting this parameter to 1.

nAddLogType

Type: DWORD value.

If this value is set to 1, the Logtype of the Event will be added into the generated message. If it is 0, it will not be added.  

nProtoType

Type: DWORD value.

Defines which Protocol is used for Syslog delivery. 0 (Which is also default) is used for UDP and 1 is used for TCP. Other values are not possible.

nProtoTypeBackup

Type: DWORD value.

Same as nProtoType, but used for the backup Syslog Server. 

szReplaceComputerName

Type: string value

Optional value, if set it will replace the computer name with the value set in this string. 

Event Log specific Parameters (under "Parameters\..." subkeys)

nLastRecord

Type: DWORD value.

This parameter is usually not to be modified. It contains the last event log record read (of the particular event log part). If you would like to get a complete dump of your event log instantly, enter 0 in these parameters.

If for any reason EvntSLog is unable to read the event log (e. g. truncated by administrator), it will reset nLastRecord to 0 automatically (that event, too, is logged in the NT application event log).

nFacility

Type: DWORD value.

This setting specifies the syslogd facility to use when sending event log entries. Each subsection of the event log (system, security and application) can be assigned a separate facility. The priority within that facility is automatically mapped based on the NT event type (e. g. error, informational, ...) and can not be manipulated.

The "nFacility" parameter holds the base value for a given facility according to the following table.

 

Facility Value
KERNEL (do not use) 0
random user level (do not use) 8
LOG_MAIL 16
LOG_DAEMON 24
LOG_AUTH 32
LOG_SYSLOG 40
LOG_LPR 48
LOG_NEWS 56
LOG_UUCP 64
LOG_CRON 72
LOG_LOCAL0 128
LOG_LOCAL1 136
LOG_LOCAL2 144
LOG_LOCAL3 152
LOG_LOCAL4 160
LOG_LOCAL5 168
LOG_LOCAL6 176
LOG_LOCAL7 184

Values other than specified above can be set but will yield to unpredictable results. We discourage using facilities other than LOG_LOCAL0 to 7. If you do so, be sure to know it's implications on the Unix site.

nFilterEventType

Type: DWORD value.

Support for local filtering. This parameter is a bit value. It specifies which NT event types are to be reported. It's values are:

NT Event Type Value
Success 1
Error 2
Warning 4
Information 8
Audit_Success 16
Audit_Failure 32

If multiple event types are to be reported, their values need to be added. One example: warning and error message shall be reported. Their respective values are 2 and 4. These are added, resulting in a value of 6. This is the value the "nFilterEventType" parameter is to be set to.

The default value is 255 which means "report all events".

bReportTruncatedLog

Type: DWORD value

This controls whether or not a log truncation will be logged to the event log (and thus be reported).
Default is logging on (value 1, value 0 is off).

Please note that a truncated NT event log can be caused by an intruder. So it might be a good idea to leave this parameter to 1 (on) on a security sensitive system.

nDeliveryMethod

Type: DWORD value.

Sets type of delivery method. 0 (default) is reporting via syslog protocol, 1 is email reporting.

More information about the email reporting properties can also be found in the EventReporter Client documentation.

szSMTPSender

Type: String Value

Email address to be used as sender address ("MAIL FROM"). Can be a single email address only. Default is "eventreporter@local". Only used if email reporting is used. Otherwise ignored.

szSMTPRecipient

Type: String Value

Email address to report to ("RCPT TO"). Can be a single email address only. Default is "eventreporter@local". Must be customized in order to do operate correctly. Only used if email reporting is used. Otherwise ignored.

szSMTPSubject

Type: String Value

Subject line to be used for email reporting. Default is an empty string (""). Only used if email reporting is used. Otherwise ignored.

szSMTPServer

Type: String Value

IP address or resolvable hostname of STMP server. For performance reasons, using the IP address directly is recommended. This server must operate as an forwarder. Relaying to the szSTMPRecipient is required, otherwise email delivery will fail silently. Default is "127.0.0.1" (local machine). Only used if email reporting is used. Otherwise ignored.

iEMailOutputEncoding

Type: DWORD value.

This parameter is mostly of use for users with double byte character sets (e. g. Asian languages). It specifies the output Encoding used for the syslog message. Possible values are:

Encoding Value
use system default 0
JIS (ISO-2022JP) 51220
EUC-JP 51932

The default value is 0, which uses the system default encoding.

Filter Rule Sets

Events are filtered based on the global filter list. The list is stored in the log specific parts of the EventReporter registry key. Consequently, there is one filter list for each of the possible event log types. All keys related to a filter list have a trailer that consist of a numerical value. This value is the position of this entry in the list. Values start with 1 and run upwards as needed (there is a theoretical limit of 4 giga entries in the list).

While applying the list, processing is strictly begun with the filter rule number 1 and moved numerically upwards until a match is found. As soon as a match is found, filter processing terminates for this event. The action from the matching entry is then taken as processing instruction. Currently, only two actions are defined: either process or discard the event. Future product versions will include a much richer filter engine as well as more powerful actions (code is already being written at the time of this writing - it will be part of the EventReporter 6.0 product).

A match is detected, if all specified criterias met the current event. It is important to know that not all criterias need to be specified for a given filter. In that case, the other criterias are not to be stored in the registry. This is very important: do not leave them blank but make sure they are not present! In that case, the missing parameters will not be considered for checking the match.

The following registry keys build the filter list. As already said, they are stored under the log specific registry

nFilterVersion

Type: DWORD

Current version of the filter list. Just for detecting changes. Starts at 0 and is incremented each time the filter changes. The actual value does not really matter, as long as it is different from the value it had when the filter list was read the last time. In this case, EventReporter will reload the filter list.

Important: If registry changes are applied to the filter list and nFilterVersion is not incremented, EventReporter will reload the filter list at the next service startup. A running instance will not reload it!

nFilterRules

Type: DWORD

The number of rules in the filter list. Must exactly match the number of rules.

FR#Action

Type: DWORD

Please note: this key is written multiple times to the registry. It is part of the filter list. The #-sign is to be replaced by the actual number of the rule, e.g. FR1, FR2, FR3 and so on.

Indicates the action to carry out if this rule matches. Currently only values 0 and 1 are defined. If it is set to 0, the event is discarded. If it is 1, it is to be processed (either send via syslog or email). Other values then 0 and 1 lead to unpredictable results.

FR#EventSource

Type: String Value

Please note: this key is written multiple times to the registry. It is part of the filter list. The #-sign is to be replaced by the actual number of the rule, e.g. FR1, FR2, FR3 and so on.

This is the name of the event source that generated the event. Please note that in order to match, it must be an exact match, including case. If in doubt, look up the name in NT Event Viewer before setting this filter.

FR#EventID

Type: DWORD

Please note: this key is written multiple times to the registry. It is part of the filter list. The #-sign is to be replaced by the actual number of the rule, e.g. FR1, FR2, FR3 and so on.

Numerical value. Corresponds to the EventID of a given event.

FR#EventType

Type: DWORD

Please note: this key is written multiple times to the registry. It is part of the filter list. The #-sign is to be replaced by the actual number of the rule, e.g. FR1, FR2, FR3 and so on.

The type of event to check (as can be seen in NT Event Viewer or the output of EventReporter).

FR#EventCategory

Type: DWORD

Please note: this key is written multiple times to the registry. It is part of the filter list. The #-sign is to be replaced by the actual number of the rule, e.g. FR1, FR2, FR3 and so on.

The event category to check (as can be seen in NT Event Viewer or the output of EventReporter).

FR#EventUser

Type: String Value

Please note: this key is written multiple times to the registry. It is part of the filter list. The #-sign is to be replaced by the actual number of the rule, e.g. FR1, FR2, FR3 and so on.

This is the name of the event user that generated the event. Please note that in order to match, it must be an exact match, including case. If in doubt, look up the name in NT Event Viewer before setting this filter. 

How to use REGEDIT

Use the Windows NT run command and type "regedit" (NT 3.5 users please type "regedt32") as the program to run. Once regedit has started, you see several configuration settings. Please navigate the tree structure by clicking the elements. Navigate to

"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
AdisconEvntSLog\Parameters"

Please note that this is all on a single line.

The following screenshot displays a sample configuration.

regedit3.gif (11622 bytes)
Screenshot of regedit

Please note the parameters on the right side. Double-click the ones you would like to modify. The following picture shows the dialog appearing after double-clicking nSleepTime:


nSleepTime double-clicked

Please note the "Base" setting on the right side. The default is hexadecimal, which usually is not very user friendly. Change this to "Decimal" as show above. The "Value Data" holds the value you would like to set.

After modifying the value, click "OK" and the registry will be updated. EvntSLog will shortly accept the new parameter.

Background Information

This section holds some background information that might be useful for some users.

The Facility Code

EventReporter originally was written to integrate Windows event log information into Unix syslog based management systems. Of course, the product has evolved very much since them and now is very successfully used to monitor Windows systems by itself. Nevertheless, there are a number of references to the so-called syslog facility code. If you are not familiar with syslog, these might be confusing. So here is some background on syslog facilities that hopefully clears up things:

The facility is a code inside the syslog message. From a technical point of view, it is just a numeric value. From the application point of view, it is typically used to filter incoming messages at the receiving server. Thus, you might designate a specific facility to event messages stemming from the system event log. At the (syslog) server side, that facility can then be used to direct these messages to a specific log file, database table or whatever. The set of possible facilities is very limited. Our registry section has a complete list of them. Typically, some of the LOCAL0 to LOCAL7 facility codes are used for applications. By convention, the others should be reserved for the respective Unix operating system components. But of course you are free to use them.

So at the bottom line, there is no need to care for facility codes if you do not see a need for them in you application and system monitoring setup. For example, if only email delivery is desired, the facility codes do not play any role at all. Also, the WinSyslog and MoniLog products do not rely on the facility - but WinSyslog can be configured to handle different facilities differently, so you might want to consider this option.

Format of  EventReporter generated XML Messages

EventReporter 5.3 uses XML formatted messages as a primary reporting means. XML has the advantage of being extensible as required. It can also easily be parsed with most scripting languages and programming systems. The XML message is embedded in  whatever "transport" (syslog or email) EventReporter uses. A typical syslog message in EventReporter XML format looks like:

Oct 11 15:12:33 w2krainer EvntSLog: <event><iut>ntelr</iut><msgnum>6573</msgnum>
<severity>[INF]</severity><user>N\A</user><logtype>Application</logtype><source>LTRAINER</source><sourceproc>Service Control Manager</sourceproc><id>6573</id><msg>The Adiscon EvntSLog service entered the running state.</msg><category>0</category></event>

Right after the syslog header (which ends in EvntSLog:), the XML data starts. A more structured form of the same data looks like this:

<event>

<iut>ntelr</iut>
<msgnum>6573</msgnum>
<severity>[INF]</severity>
<user>N\A</user>
<logtype>Application</logtype>
<source>LTRAINER</source>
<sourceproc>Service Control Manager</sourceproc>
<id>6573</id>
<msg>The Adiscon EvntSLog service entered the running state.</msg>
<category>0</category>

</event>

As can be seen in this structured view, there is an so-called "event" entity. This entity contains all attributes of the event log record beneath it as separate XML tags. None of them has any specific attributes. As of now, there is no further level down the tree - but this can change. An parser should note that the event log record might have all, some or even none of the XML tags. Even in the last case it is validly formatted - though of course useless. But even in this case the parsing script should not fail. For reference, the following log properties are defined currently:

Property Contents
iut This is the InfoUnitType. This uniquely identifies the type of event. For EventReporter, it is either "ntelr" or 3 (the numerical value three). Please keep in mind that both values represent this type. So if you parse the files, you should not rely on the "ntelr" exclusively. Future versions might report the numerical value. For other members of the MonitorWare line of products it can have different values.
msgnum The syslog message number if it is generated. This number is incremented with each record sent.
severity The NT Event Log severity code.
user The user information that was logged with the event. The constant "N\A" denotes that there has no user information been logged with this record.
logtype The Event logtype, for example "Application"
source The computer the event originates from. It is the Windows name of that machine (as it knows itself)
sourceproc The event source as reported in the event log.
id The event ID as reported in the event log
msg The event message itself. Pure textual data - the same information that can be seen via NT Event Viewer.
category The numerical category ID as reported in the event log.
bdata Binary data, if such is available in the event record. Please note that the EventReporter General settings must be specifically set to provide this information because it can potentially be very large (up to 128 KB). This field contains a textual representation. It is a byte stream of the binary data stored in the event log record. Each byte is encoded in two hex digits.

Please note that there is also a previous legacy format available. We highly recommend basing new scripts or products on the XML format because of its many advantages.

Version History

This short history shall provide you with some background information about the versions available as well as their pros and cons.

This is user driven software. Please provide us with your feedback. Many features have become reality with the help of envisioning users!

1.0

This is the initial release. Made available on March, 23rd 1997. It provides all the basic functionality, but has some restrictions:

  • There is no configuration program
  • Only the system event log can be read
  • Only a single syslog daemon is supported
  • It does not run as a service

2.0 beta 2

The next version publicly offered. It provides these enhancements:

  • Runs as Windows NT system service.
  • All three parts (system, security and application) of the event log can now be processed
  • fixes some minor and one serious version 1.0 bug. With 1.0, event logging could stop if a very large log record (> 2 K of data) should be processed. This has been removed in 2.0 beta 2.
  • Documentation has been changed to HTML only

Please note that this version is beta software.

2.0 beta 2a

Contains one quick enhancement of the installation process. Released shortly after the initial 2.0 beta 2. Didn't change any core functionality.

  • Service installations writes default registry parameters

Please note that this version is beta software, too.

2.0 beta 2b

  • Parameter szTarget2 added for enhanced robustness of the logging process
  • The EventID is now written to the syslog host, too (in parentheses after the source name)

Please note that this version is beta software, too.

2.0 release version

There are no functional upgrades when compared to 2.0 beta 2b. However, this is the fully tested and officially released version.

2.1

Fixed a bug when using NT SP 4 or some post SP3 hotfixes. These caused EvntSLog to crash when trying to access the security log.

3.0 beta 1

This version has been released to the public on September, 22nd 1998.

This version is much improved. It contains the following enhancements:

  • multiple spaces inside a log record are compressed to a single one
  • control characters (like CR/LF) are filtered out of the eventlog messages. These characters caused truncated log entries on some syslogds.
  • Syslog facilities are now supported. A separate facility can be set for the system, security and application event log. By default, all logs are reported to LOCAL0. Facility setting can be modified by 3 new registry settings: System\nFacility, Application\nFacility, Security\nFacility. These settings are the decimal numer of the facility code.
  • Syslog priorities are now supported. Windows NT event types are mapped to syslog priorities based on the following mappiong table:
    EVENTLOG_AUDIT_SUCCESS, EVENTLOG_INFORMATION_TYPE ==> LOG_NOTICE;
    EVENTLOG_AUDIT_FAILURE, EVENTLOG_WARNING_TYPE ==> LOG_WARNING;
    EVENTLOG_ERROR_TYPE ==> LOG_ERR;
  • Licensing via licensee name and license key. There is only a single executable for both the trial and the licensed version. This way, a trial installation can become a fully licensed one with even less effort.
  • support for the Compaq/DEC ALPHA platform

3.0 beta 3

This version has been released to the public on November, 1st 1998.

Beta 2 was a private build. Beta 3 contains some fixes. This version is scheduled to become the final release.

  • Beta 1 lost a couple of log messages if there was a high logging demand. Beta 3 fixes that.
  • Performance has greatly been improved by avoiding unnecessary writes during each iteration
  • Fixed a bug which caused EvntSLog to stop logging when the event log was reset. Please note: this was not a beta bug, but a bug contained in all previous releases of EvntSLog.
  • Fixed a bug which caused EvntSLog to become unresponsive during longer sleep periods (> 15 seconds). EvntSLog is now a multithreaded service.
  • Location of registry parameters was incorrectly printed during service installation (evntslog -i). This was mere a cosmetic problem, but caused user confusion.
  • Release history in documentation improved.

3.0 release version

This version (Build 121) has been released to the public on November, 14th 1998.

There are no functional upgrades when compared to 3.0 beta 3 except that the build ID is displayed when installing the service.

This is the fully tested and officially released version. 

3.1

This version (build 134) has been released to the public on November, 24th 1999. It is a final release.

This version is much improved. It contains the following enhancements:

  • support for Windows 2000 (NT 4 type event logs, only)
  • all buffers increased for much larger message sizes
  • fixed a bug that caused event message IDs to become erratically negative
  • allows to control whether or not log truncations cause notifications to be sent
  • enhanced output format (higher compatibility layer to syslog) as well as added severity information in a standard header
  • fixed a bug with message library handling that could cause truncated messages in some uncommon situations 

3.2

This version (build 136) has been released to the public on February, 14th 2000, just in the timeframe for Windows 2000 (release February, 17th 2000 by Microsoft). It is a final release.

It contains a single enhancements:

  • automatic support for the 3 additional Windows 2000 event logs ("DNS Server", "File Replication Service", "Directory Service". This support is automatically enabled if Windows 2000 is detected.

4.0

This version (build 137) has been released to the public on July, 1st 2000. It is a final release.

It contains a the following enhancements:

  • support for message delivery via email (complete delivery system and abstraction layer added)
  • EventReporter Client added
  • filtering of events based on severity code (e. g. error, warning, informational)
  • greatly enhanced documentation
  • greatly enhanced web site - especially support area

4.1

This version (build 138) has been released to the public on September, 25th 2000. It is a final release, mainly for maintenance reasons.

It contains a the following fixes:

  • fixed a bug that caused the installation to abort in some environments
  • fixed a bug that caused the email delivery mode to fail (problem reported was "Fatal error (0) initializing transport", occurred only with a very limited number of mail servers)

4.1.1

This version (build 139) has been released to the public on September, 29th 2000. It is a final release fixing a single problem.

It contains a the following fixes:

  • fixed a bug that caused a debugging message to be reported in syslog delivery mode

4.2

This version (build 140) has been released to the public on November, 6th 2000. It is a final release, mainly for maintenance reasons.

It contains a the following fixes:

  • daemon process runs at below normal thread priority, further lowering the performance impact on the monitored server
  • fixed a bug that caused incorrect formatting of event messages in some scenarios under Windows 2000
  • added support for misbehaving message libraries (If an external product message library failed, the EventReporter process could be aborted. We have added structured exception handling to catch this exception. This error occurred very rarely and only in conjunction with failing third-party products.)
  • support for double byte character sets added

All users are strongly encouraged to upgrade to this release.

5.0 Beta 2

This version (build 142) has been released to the public on November, 29th 2000. It is a first publicly available 5.0 release. It is a beta build.

It contains the following fixes and enhancements:

  • Local pre-filtering has been added both to the service and the client. The product can now filter based on the event id, source, severity and category. Very complex filter rules can be created in order to care for the most demanding environments.
  • localized client - immediately available in English, German and Japanese
  • XML based system for localization - new client languages can be added very easily. Customers interested in a new language and willing to provide the translation of a few strings are very welcome to contact us.
  • Fixed a problem that could cause the service to abort when using SMTP delivery and the mail server was offline.
  • New, improved setup program based on Microsoft Windows Installer - the new standard for both manual and automated software installation.

5.0 Final Release

This version (build 145) has been released to the public on November, 29th 2000. It is a first publicly available 5.0 release. It is a production build without any notable differences from Beta 2.

5.1 Beta 1

This version (build 147) has been released to the public on 2001-02-07. It is a first publicly available 5.1 release. It is a beta build.

It contains the following fixes and enhancements:

  • Fully based on Unicode. This enables the product to process all international characters in the Windows NT event logs. Also further speeds up the product, as Unicode-based processes can be executed faster by Windows NT (NT itself is based on Unicode - non-Unicode applications need to use a translation layer which takes it's time toll).
  • Selectable output character encoding supporting system standard, EUC-JP and JIS. Specifically build in for the Japanese market.
  • Syslog messages can now be consecutively numbered. So it is easy to detect if someone has deleted some messages from the syslog files.
  • Remote Administration - client can now manage remote instances of EventReporter as long as there is network connectivity between the client and the machine the service is running on.
  • Time savers in client: "Reload" and "Restore to Default" buttons. Customer feedback told us these were really missing!
  • some minor bug fixes

5.1 final release

This version (build 148) has been released to the public on 2001-03-01. It is the official final release of the 5.1 product.

It contains all build 147 features as well as one important fix and a new feature:

  • Fixed a bug that could cause EventReporter to fail if DNS resolution was not available for the SMTP server specified. If that happened, EventReporter will ungracefully shutdown via a general protection fault. This has been fixed in build 148 - a matching error will now be reported to the event log and EventReporter will re-try in its next iteration.
  • The client can now automatically check for product updates. To do so, it connects to Adiscon's real time product status system on the Internet.

5.2 final release

This version (build 150) has been released to the public on 2001-04-20. It is the official final release of the 5.2 product.

  • Fixed a bug in SMTP-Delivery. Emails sent by EventReporter had the wrong timestamp. 
  • Added a new Setting "Add Username". You can append the Username to all outgoing messages.
  • Enhanced the EventReporter Client there are now more possibilities to control the Service.
  • New install package based on InstallShield - service is now automatically installed at setup time

5.2 SP 1 (service pack 1)

This version (build 151) has been released to the public on 2001-06-01. It contains some fixes and enhancements. It is part of all EventReporter download sets beginning at the build date. 

  • Spanish language support added to the EventReporter client
  • client can now copy email settings from the system tab to all others 
  • Fixed a bug that could cause the EventReporter service to abort when it processed an invalidly formatted third party message library

5.2 SP 2 (service pack 2)

This version (build 152) has been released to the public on 2001-07-16. It contains some fixes and enhancements. It is part of all EventReporter download sets beginning at the build date. 

  • Removed bug in EventReporter Service. In some cases the event log message from an unregistered event source was not correctly read.
  • Enhanced SMTP-Sending support.
  • Removed a bug from EventReporter Client. When a Rule with no event source was added using the filter rules editor, the registry-key was also written. So this rule could never apply. Now the key is not written if the event source is empty and the rule applies to all event sources.

5.3 final release

This version (build 157) has been released to the public on 2002-01-21. It contains some fixes and major enhancements. It is part of all EventReporter download sets beginning at the build date. 

  • Binary data contained in the event log records can now be (optionally) forwarded to the message receiver.
  • Support for sending both email AND syslog messages for the same event. This is done via the advanced filters configuration.
  • fixed a bug in Japanese language encoding. Half size kana characters were improperly translated in any mode besides "System Default".
  • customizable email subject line - the subject can now contain actual data fields. Great for notifying pagers.
  • Events can now be reported in XML format. This allows easy extension with new data fields as they become available. It can also easily parsed with most script languages.
  • With the XML format, the category field of the event log can be forwarded
  • French language support in the EventReporter client
  • This release fully supports all feature of Windows XP and has received the "Designed for Windows XP" logo from Microsoft.
  • A number of client improvements - for example, the existing event sources can now be read out by the advanced filter dialog and need not to be manually entered.
  • French language support for the EventReporter client
  • Added a feature to prevent syslog server and network overload by allowing to throttle the rate by which EventReporter sends out event reports (default is now around 200 events per second maximum).

5.4 Release Candidate 1

This version (build 160) has been released to the public on 2002-08-02. It contains some fixes and some minor enhancements. 

  • Add Support for Syslog over TCP. You can now use TCP as transmission protocol for Syslog delivery.
  • Replace Computer name - Allows you to change the computer name of Eventlog messages.
  • Added new Filter - You can now also filter by EventUser in the advanced filter configuration.

5.4 Final Release

EventReporter 5.4 (Build 163) has been released into public on 2002-10-11. The new version offers the same as well as new enhancements (As bug fixes) as the 5.4 Release Candidate 1

  • Added Options for LogType. The event logtype (Like "Application") can now added into a message. There will also a new xml tag for the logtype. See the documentation for more.
  • The is a new setup for Windows NT available (witch does not need ServicePack level 6).

Please note that there was a minor update to service build 158 on 2002-01-28 fixing a bug in the advanced filter rules. As it was a minor fix, we did not increase the version number. If you experience problems with the advanced filter rules, make sure you have build 158. This can be seen in Help/About.

Purchasing EventReporter

The License

For full license details, please see the license displayed during setup. This section here covers the most important points, but is not the complete license.

EventReporter is distributed as Shareware. You are free to use the product for evaluation. However, if you feel comfortable with it and plan to use it for an extended period of time, you must register with Adiscon and pay the license fee. A license is needed for any system the EventReporter service is running on. It does not matter if the operating system is a workstation or server version.

Please support further development by registering the product. There is a license fee per system the EventReporter service is running on. No license is required for the EventReporter client.

BBS sysops feel free to include the distribution set of this product in your library. Please be sure to include the full set (program & this documentation). Any questions can be directed at Info@Adiscon.com.

Liability

Please use the evaluation period to check if EventReporter is suitable for you and your system environment. We encourage you to try EventReporter in a test environment. We accept no liability for any damage during the evaluation period.

Liability for registered users is limited to the amount of the registration fee.

Are there any restrictions in the unregistered trial version?

No, the version is fully functional for 30 days. It identifies itself as such. From time to time, it sends "EvntSLog 4.0 SHAREWARE Version – Please Register" to the syslog daemon.

Pricing

For orders outside of Germany, the fee is $US 49 (plus tax if applicable). European Community orders are EURO 65,-- including 16% VAT. European Community residents with VAT identification number should state this number in order to recieve tax exemption. If not stated, full VAT will be charged. All Euro Zone orders will be processed in EURO. US$ payment is available for international customers, only.

Please call for volume orders (info@adiscon.com).

How to order

Most convenient way - order online: https://secure.adiscon.com/EventReporter/en/.

If you do not like to order only, registration is still as simple as 1-2-3:

  1. Print out the following registration form
  2. Please fill it in. Remember to include number of licenses requested and payment information as well as your email id.
  3. Mail or fax the registration form to Adiscon.

We accept all major credit cards.  We do also happily accept purchase orders from all countries (except some very few countries we are not allowed to deal with by law for being on the international embargo list). For details, please visit

http://www.adiscon.com/Common/en/OrderByPO.asp

If you need any additional payment options, please contact us at Info@Adiscon.com or the below given addresses.

Direct your orders to:

Adiscon GmbH
Franz-Marc-Strasse 144
50374 Erftstadt
Germany

Fax: +49-2235-985032
email: order@Adiscon.com
Web: http://www.Adiscon.com

Due to German laws, all credit card orders need to be processed in EURO. US$ payments will be converted to EURO according to the current exchange rate. There might be a slight difference in the converted value due to exchange rate differences.

Order Form

Your order can be placed using the following form. If you would like to order online, please visit

    https://secure.adiscon.com/EventReporter/en/.

If you'd like to order by mail or fax, please print out the order form and sign it.

 

EventReporter Order Form

Company
Last Name
First Name
Street
ZIP/Postal Code
City
State/Province
Country
Phone
Fax
EMail
VAT Registration Number
European community only

Hereby I order:
Number of Licenses @ US$ 49/EURO 65 (including 16% tax)
Fee Schedule
Nbr. of Licenses Discount
2-5 3%
6-20 8%
21-50 15%
51+ 20%

Licensee Name:

Please note: The licensee name can not be changed afterwards. Please make sure you use the correct spelling and there are no typos. There won't be any exchanges for incorrectly spelled names.

Payment Options:
EuroCard/MasterCard
American Express
VISA
Diners Club
JCB
Card Number
Cardholder Name
Valid until

Please sign:

________________________________________________________
Date & Signature

and forward this form to

Adiscon GmbH
Franz-Marc-Strasse 144
50374 Erftstadt
Germany

Fax: +49-2235-985032
Fax option for Credit Card orders, only.

 

 

Miscellanous

Year 2000 Compliance Statement

EventReporter has been designed to avoid any problems that may occur with the change of century. There are no dates stored internally in a manner that might make them susceptible to errors due to the century change. EventReporter also does not contain  any date specific operations. Any date directly written by EventReporter is output as 4 digit year.

EventReporter itself is Year 2000 Compliant.

Note: This statement does not in any way guarantee that EventReporter will correctly operate across the Year 2000 boundary on any machine who’s BIOS and operating system is not Y2K compliant. Also please note that EventReporter forwards event log records written by a vast variety of products. We cannot guarantee that all of this products are year 2000 compliant. EventReporter simply forwards what is written to the event log, so be sure to check with the other vendors.

As of this writing (January 2002) we have not received a single support call regarding Y2K issues. So it seems to be fairly proven that there are no problems at all.

Copyrights

This documentation as well as the actual EventReporter product is copyrighted by Adiscon GmbH, Germany.

Microsoft, Windows, Windows 2000, Windows XP and Windows NT are registered trademarks of Microsoft Corp., Redmond, WA, USA. Other mentioned trademarks are copyright of there respective owners.

Other Products of Interest

You might be interested in Adiscon WinSyslog. This is a syslog daemon for Windows NT. It might be useful when evaluating EventReporter as it allows you to run both the logger as well as the daemon on a single machine for immediate feedback. If also allows central consolidation of NT event logs. Adiscon's MoniLog then allows to automatically analyze them. MoniLog creates consolidated HTML reports based on the data collected by EventReporter.

EventReporter ist part of the MonitorWare line of products.

 

Copyright (C) 1997-2002 Adiscon GmbH. All rights reserved.