Month: April 2010

2010-04-23 MonitorWare Agent 7.1 Final Released

MonitorWare Agent 7.1 Released

Adiscon is proud to announce the 7.1 release of MonitorWare Agent.
This release includes important new features and minor bug fixes. New features are:

  • Old-Style Format Emulation for Event Parameters – the old Windows Event Log
    system contained numbered parameters (name “ParamX” in our implementation). The new
    style implementation (e.g Windows 7, Windows Server 2008) does not support them in the same way.
    The Event Log Monitor V2 is still able to provide parameters in the “old style” format,
    what means that log analysis scripts can receive a consistent stream of data for both
    new style and old style Windows events.

  • Improved Support for NetApp Filer and similar devices –
    which enables to integrate their event logs into a central repository.
    For this, EventReporter is executed on a Windows system and pulls NetApp Events via
    the NetApp event log API. Note that there are various modes for doing this, and
    all of them have some specifics in addition to the “usual” requirements found in
    the Microsoft API specification. EventReporter knows these specifics and has special
    code to work with them.

  • Support for old-style Windows Event Log Backup Files –
    Current Windows releases (like Windows 2008 Server) cannot read event log backup files
    from older Windows systems utilizing the old-style event API.
    This holds also true for event log files created by third-party applications in that
    format (and there are such third-party applications). EventReporter is capable to read
    and process these files on any Windows platform, including the most recent ones.

For more details read the

version history

Version 7.1 is a free download.
Customers with existing 10.x keys can contact our Sales department for upgrade prices. If you have a valid Upgrade Insurance ID, you can request a free new key by sending your Upgrade Insurance ID to sales@adiscon.com. Please note that the download enables the free 30-day trial version if used without a key – so you can right now go ahead and evaluate it.

MonitorWare Agent 7.1 Released (Build-IDs: Service 7.1.392, Client 7.1.1307)


MonitorWare Agent 7.1 Released

Release Date: 2010-04-26

Build-IDs: Service 7.1.392, Client 7.1.1307

New Additions

 

  • EventLog Monitor V2
    – Added %ParamX% emulation Option in EventLog Monitor V2
  • EventLog Monitor V1
    – Changed Checksum verification method, so it works along with third party Eventlog applications like NETAPP Filer.
    – Implemented Fallback method to reading and process EventLog *.evt Backupfiles created on Windows XP/2003 or earlier. This workaround is needed to process these files on Windows VISTA/7/2008.
  • Send Mail Action
    – Added Switch to support old localized date header. This is needed for mail readers, that do not support UTC in date header.
  • PlaySound Action
    – Due the security service hardening in Windows, the PlaySound Action will not work on Windows VISTA/7/2008 anymore, unless you run the service in console mode.

 

Bugfixes

 

  • EventLog Monitor V2
    – Added missing check if rule processing failed.
  • EventLog Monitor V1
    – Hardened Checksum Method against various race conditions.
  • Forward Syslog Action
    – Fixed Action error handling of the Connect attempt failed.

 

You can download Free Trial Version of
MonitorWare Agent.

A complete step by step guide on setting up Scheduling of Reports with Job Manager

How To Schedule Reports with MonitorWare Console

Article created 2003-11-20 by
Wajih-ur-Rehman.

Reports in MonitorWare Console can be scheduled using Job Manager. With Job
Manager you can not only schedule the reports such that they are saved on the
hard disk but also you can schedule the reports such that they are sent via
email to specified recipients.

1. Click "Options" in the main tool bar of MonitorWare Console and then click
on "Job Manager Settings…" You will see a dialog box as shown below

2. Click on the report that you want to schedule. In this example i will
illustrate the scheduling of "System Status Report"

3. Click on "System Status Report" on the left hand side.

4. On the right hand side, set the time and UTC offset. Please note that the
check box must be checked if you want to schedule the report. Lets say
you want to generate this report daily at 11:00 pm. If you have logged the
records in the database with local time, then you dont need to set this UTC
value. It will stay at 0. These settings are shown below:

5. Now click on Action tab. You will see as below:

6. Set the File Prefix. In this case, I leave it as default.

7. Now you have 2 options. Either you can save the report on the hard disk or
you can send an email when the scheduled time is met. If you select "Save as
file" radio button, then the "File Settings" button will be enabled and on the
other hand, if you select "Send as attachment in email" radio button, then both
"SMTP Settings and "Message Settings" buttons will be enabled. You can either
carry on with Step 8 or Step 9 depending upon your requirements

8. If you want to save the report on the hard disk at the scheduled time then
select "Save as file" radio button and click on "File Settings" button. Once you
do that, you will see the following dialog box:

You can select any path over here that you feel like. But if you want to view
this report on the web, you will have to create a folder under Inetpub->wwwroot.
In this case, I have created a folder named "MonitorWareConsole" and have
selected the same in the above dialog box. Click OK once you have done that

9. If on the other hand, you are interested in the report being emailed to
some specified recipient at the specified time, then you should select the radio
buttion labeled as "Send as attachment in email". After Selecting it, click on
SMTP Settings. It will show you the following dialog box:

Enter your SMTP server name. Click OK. Then click on "Message Settings"
button. You will see a dialog box similar to the one shown below:

Fill in these values and click OK when done

10. After setting the "Action" tab according to 8 or 9 above, click on Filter
tab. Once done, you will see following dialog box:

You can now select one of the above 3 mentioned filters based on your
requirements.

11. Once done, click on "Save" button. If the Job Manager Service is running,
it will give you a message saying that it would restart the service so that new
settings could take effect. If on the other hand, the service in the background
is not running, it would give you a message saying that you have to manually
restart the service. You can start the service manually by going to Control
Panel->Administrative Tools->Services and start AdisconMWCJobManager Service

Monitoring DHCP Logfiles

Monitoring Windows 2003 DHCP Server Logfiles via syslog

Created 2007-10-10 by Florian Riedl

Information for the usage of this guide. This guide will give you the hints to create a configuration to monitor Windows 2003 DHCP server logs as well as forward all log data to a syslog server. To make things easier, the guide is split up into several mini-guides, which will each cover one big step of the configuration. These mini-guides only describe the general procedure. You may have to adjust settings like IPs or pathnames to your personal needs.

Please note: In order to forward the DHCP logs you need MonitorWare Agent.
Further you need to setup your DHCP server to log into text files. Please review the manual for further instructions.

Step 1

The first step we are going to take is to create a RuleSet with the corresponding action. In this case we want to forward our logs via syslog. Therefore we need a “Forward via syslog”-Action. Instructions on how to create a ruleset and setup the action can be found here:

How to Setup a Forward via Syslog Action

Please Note: You have to edit the IP address of the syslog server. By default it is set to 127.0.0.1. If you do not change this, your syslog server will not receive any data.

Step 2

The next important step is to setup the FileMonitor. We need it to monitor the text file logs created by your DHCP server.

How to Setup the FileMonitor Service

Please Note: This is a general guide, you may have to alter the path- and filename. The default path and filename is “C:\WINDOWS\System32\dhcp\DhcpSrvLog-Fri.log”. The last 3 letters of the filename represent the day on which the log was created. You can use wildcards for the filename.

Step 3

The last and final step is to click on the Save button if necessary and then start MonitorWare Agent. You are now done. Finally you should receive all the log entries of your DHCP Firewall on your syslog server.

If you want, you can download the sample configuration file. Extract the .reg file to the machine where MonitorWare Agent is installed and execute it before opening MonitorWare Agent.

A complete step by step guide on setting up centralized Windows event monitoring. It contains screenshots of all important dialogs as well as links to the necessary free downloads.

How To setup Windows centralized Monitoring

Article created 2003-11-24 by
Wajih-ur Rehman.

Article updated 2004-04-22 by
Tamsila-Q-Siddique.

Monitoring Windows NT/2000/XP/2003 is important even for small environments.
This article is strictly task focused. It does not describe why the
systems should be monitored nor does it provide any further background. Please see
the respective backgrounders or product documentation on this. This article is a
step-by-step description of what you need to do in order to centrally monitor
your Windows NT/2000/XP and 2003 systems.

This article has been extracted from the
MonitorWare Agent documentation. Please be sure to check the MonitorWare Agent online help
if a newer version is available.

Centralized Event Reports

In this step-by-step guide, MonitorWare Agent is configured to work together with
Adiscon’s MonitorWare Console to automatically
generate event summaries for the monitored servers and other devices.

This
guide focuses on a typical small to medium business topography with a single
geographical location and 5 Windows clients and a central hub server. All
systems are well connected via a local Ethernet. Event reports from all machines
should be stored in a database. The administrator shall receive daily
consolidated event reports.

What you need

In
this guide, I am focusing on building a solution with Adiscon’s MonitorWare
Agent and MonitorWare Console. This combination allows you to centralize all your event logs
and report events from them. Free 30 day trial versions are available at the
respective product sites (links below), so you can try the system without the
need to buy anything.

You
need to run the following products:

  • 1 MonitorWare
    Agent for each system that is to be monitored. In our scenario, this means 6
    copies, one for each client and one for the central hub server to be monitored.
  • 1 MonitorWare Console togenerate consolidated reports based on the gathered log data.

  • To deliver
    MonitorWare Console’s reports, you need a local web server (for example Microsoft’s IIS or
    Apache) and a mail server capable of talking SMTP (most modern servers support
    this)

You
need administrative privileges on each of the machines. This is required both
for installation and configuration. Make sure you log on with a sufficiently
privileged user account.

Step 1 – Download Software

As you read the MonitorWare Agent
manual, you most probably downloaded the MonitorWare Agent. If you haven’t,
please visit www.mwagent.com/download
to do so. In addition to the agent, you also need MonitorWare Console. A free,
full-featured 30 day trial is available at

http://www.mwconsole.com/en/download/.

Step 2 – Install MonitorWare Agent

Run the MonitorWare Agent setup
program on all systems that should be monitored. This means you need to run it
on all 5 clients and the central hub server. Take a note of the central hub
server IP address or host name. You’ll need this value when configuring the
agents on the client machine. For our example, we assume this system has an IP
address of 192.168.0.1.

For larger installations (with many
more servers) there are ways to set it up in a simpler fashion, but in a
scenario like ours, it is faster to install it on each machine manually. You can
install it with the default settings. When setup has finished, the program
automatically is configured to operate as a simple syslog server. However, it
does not yet create the log in our database we need. So we will go ahead and
change this on each of the machines or by launching it on one machine and
remotely connecting to the others. It is your choice. In this sample, I use the
MonitorWare Agent on each machine (it is easier to follow).

Step 3 – Create a RuleSet for Forward by SETP

The steps to configure the agents are
as follows (repeat this on each of the 5 client machines). This step needs not
to be done on the central hub server!:

Forward via SETP Steps

Step 4 – Create a RuleSet for database logging

This
step needs only to be done on the central hub server!

Database Logging Steps

Step 5 – Create an Event Log Monitor Service

The steps to configure the MonitorWare Agents are as follows (repeat this
step on each of the 5 client machines and the central hub server!):

EventLogMonitor Service Steps

Step 6 – Create a SETP Server Service

The
steps to configure the agents are as follows (only central hub server!):

SETP Server Service Steps

Step 7 – Preparing Web Server for MonitorWare Console

MonitorWare Console publishes its reports through
the local web server (central hub server).

To avoid confusion, we recommend
creating a separate directory on the web server for MonitorWare Console. Let us assume you
use Microsoft Internet Information Server and run it in the default
configuration. Then, you web pages are stored in the c:\inetpub\wwwroot
directory. Create a subdirectory “MonitorWareConsole” directly beneath this
directory.

Step 8 – Installing and Configuring MonitorWare Console

MWConsole- Installation and Configuration Steps (1.1)

MWConsole- Installation and Configuration Steps (2.0)

Step 9 – Generating Reports with MonitorWare Console Manually

This section explains how the reports can be generated with MonitorWare
Console manually. Since “System Status” Report is most comprehensive report that
tells a detailed description about the network, in this section I will explain
this report only. Please note that, the procedure for generating any report is
almost the same.

Generating Windows Reports with Console 1.1 Manually

Generating
Windows Reports with Console 2.0 Manually

Step 10 – Scheduling the Generation of Reports with MonitorWare Console

This section explains how the reports can be generated with MonitorWare
Console automatically using Job Manager. With Job Manager, you can generate all
the reports based on a pre-defined schedule and ask it to either store it in
some location on the hard disk or send it to specified recipient via email. Once
again, I will explain the scheduling of System Status Report in this section.
Please note that, the procedure for scheduling any report is the same.

Scheduling Reports with Console 1.1

Scheduling Reports with Console 2.0

You are done!

Well, this is all you need to do to
configure the basic operations. Once you are comfortable with the basic setup,
you can enhance the system with local pre-filtering of event, enhanced logging
and alerting (with MonitorWare Agent) and changing report options (with
MonitorWare Console).

We hope this article is helpful. If you have any questions or remarks,
please do not hesitate to contact us at
support@adiscon.com

“A complete description of common uses of the MonitorWare line of products. – Relaying events

Common uses

Article created 2003-05-14 by Rainer
Gerhards.

Relaying Events

In all but the easiest scenarios event data needs to be relayed between
different machines. Please note that relaying is also often referred to
as “forwarding” – both terms have the same meaning in the context
of this documentation.

A typical relay scenario might look like follows:

Here, devices send event data to servers configured for relaying. These
servers in turn forward the data to its final destination, the central
server.

Please note that the so-called “Relay Server” need not be limited to the
relay function. It can also perform any other MonitorWare agent function
like data gathering or real time alerting. Also, the devices of course
can include Windows systems monitored by a MonitorWare Agent configured as data gathering- The idea behind the picture is to provide a quick sample – it is in no means complete.

Whenever it comes to relaying messages, an important decision must be made: the protocol used for relaying must be selected. Basically, either syslog or the SETP protocol can be used. This is an important choice, because the two protocols offer very different benefits:

syslog

  • supported by virtually all network devices (like routers, firewalls and the like)
  • standardized (but not necessarily all devices follow the standard)
  • THE universal network event notification protocol
  • UDP based, as such event data might be lost in transit
  • limited to 1024 characters per event, which is definitely too short for Windows
    event log entries (larger messages can be processed by MonitorWare, but
    this can result in more likely packet loss)
  • event source system typically can not be tracked correctly when using inside a cascaded system
  • event information for non-original syslog events is lost as they can not be transmitted in native format

SETP

  • Adiscon’s proprietary protocol for event notification
  • so far, supported by MonitorWare Agent exclusively
  • TCP based, reliable delivery possible
  • can be used with Windows IPsec
  • optimized for event data transmittal
  • events are transmitted in native format and thus can be fully reconstructed at
    the receiving side
  • no event size limit
  • XML based

Given the advantages, Adiscon recommends using SETP whenever possible. This is then the case when an MonitorWare Agent sends events to another MonitorWare Agent. When events from other devices, e.g. routers, are to be received, syslog protocol must be used for these incoming events. If event data is to be sent to a non-MonitorWare Agent system (e.g. a management system on a Linux or UNIX system), syslog must also be used as these other systems do not “speak” SETP.

MonitorWare Agent can process both of these protocols concurrently. So it is no problem to use SETP in a mixed environment. Again, we highly recommend using SETP whenever possible.

A complete description of common uses of the MonitorWare line of products. – Solving Products

Common uses

Article created 2003-05-14 by Rainer
Gerhards.

Solving Problems

Solving problems is closely related to alerting. As with alerting, actions are to be executed if a trigger condition exists. With problem-solving,
these are actual corrective actions. Samples are deleting temporary
files when disk space goes low or blocking an external IP address in a firewall in case an attack is detected.

MonitorWare itself does only provide limited “canned” actions for
problem-solving. However, it contains the “execute program” action,
which is a very powerful tool in solving problem conditions.

The basic idea behind this concept is that the MonitorWare agent detects
correctable conditions and then executes an external program (or a batch
file!) to correct the problem. With the power of external program, batch
files and scripts, many minor conditions can be solved before they cause
deep trouble. Many routine tasks can be solved without operator
intervention which also means they can be solved while no operator is
available.

Problem-solving logic can be put on any Agent. However, Adiscon highly recommends placing it on the each of the machines that will use problem solving logic. This not only ensure quick response time and reliability, it also guarantees that actions are carried out as quickly as possible.

A complete description of common uses of the MonitorWare line of products. – Alerting

Common uses

Article created 2003-05-14 by Rainer
Gerhards.

Alerting

In this scenario, the primary concern is to receive alerts if specific events happen. Of course, alerting is often used together with other scenarios as alerting alone does not provide in-depth analysis or storage of the captured events.

Alerts can be generated by every running instance of MonitorWare Agent. As such, alerts can be generated both on each machine that is monitored as well as on a central machine. Also, alert generation can be combined.

There are advantages and disadvantages for each mode. The big plus of generating alerts on each monitored machine is that they will be triggered whenever they are detected. There is no interim system that events need to be passed to and as such no interim system that can fail. However, this implies that alerts need to be configured on each monitored machine, which can be inconvenient (but becomes less of a burden with the soon available central configuration service).

Central alert generation ultimately solves this issue, as alerts are only generated on a single machine – or at least few machines. On the other hand, if the reporting system is not able to reach the central server for some reason – or the central server fails, no alerts will occur at all. This, of course can be largely worked around by monitoring the central server’s health with another instance of the MonitorWare Agent running on another machine, but this adds complexity.

Fortunately, MonitorWare is flexible enough to allow all imaginable configurations. For example, it is possible to trigger for extremely urgent alerts on every monitored machine while less critical alerts are checked at a central server.

In any case, alerts are defined via rule sets. Inside the rule set, filters are defined for the alert conditions and action carry out the actual alert. Of course, alert actions are most often sending emails or starting a “net send” command to broadcast the message e.g. to a group of network administrators.

Alerts can be executed on a MonitorWare Agent who is also performing other functions.

A complete description of common uses of the MonitorWare line of products. – Event archival

Common uses

Article created 2003-05-14 by Rainer
Gerhards.

Event archival

If you have to create an archive of past events, this scenario is for you.
The main focus here is storage of event data. Potentially, data is
stored for a long time and eventually never being overwritten. It is
also highly likely that data will be written to a read-only media like
CD-R.

Event archive are created for a number of reasons, some samples are

  • Corporate requirementsYour organization, as a general policy, requires you to log data for later review.
  • ISO 9000 requirementsDepending on where logs are being generated, they might be needed to be long-term
    archived to fulfil the ISO 9000 requirements.
  • legal requirementsDepending on your country, some or all organizations might be required by law to
    save log data for an extended period of time. For example, in many
    countries internet service providers are required by law to archive
    connection logs for at least some month so that criminal investigators can use them to track down cyber-criminals.

Depending on the exact requirements you have, the event archive can be placed on a server that performs other functions or it can not. If the log archive is potentially used in court, we highly recommend to use a dedicated and specifically configured machine.

Creating an “unsecured” Event Archive

By “unsecured”, we mean an archive that is created without any specific measures against tampering with the log data. This type of archive is meant to be used for internal audits, only. This archive is not intended to be used as evidence in court. As such, a less restrictive security policy might be used.

This scenario is often found in organizations where event archiving is not the topmost priority and funding thus is limited. The advantage of an unsecured archive is that no dedicated machine or complex procedures are needed. If that level of security is sufficient for your application, the unsecured archive can be placed on event repository server that also performs other actions. For example, the event data could be written to a database which is also access by other tools.

However, as a general recommendation, we recommend to write archives as text files, which can later easily be compressed and written to read only media (if there is justification for this). This also allows to keep the database clean of otherwise unneeded historical data.

Setting up a unsecured event archive is relatively trivial.

Creating a highly secure Event Archive

This type of archive is needed if log data is potentially to be used in
court. Please note that some countries require organizations to store
log data securely.

As law is very different in different countries and states, this guide here
can not provide a definite answer on how to set up an archive to comply with local laws or to be used as evidence. You need to work with your legal advisor on how to do that. However, Adiscon’s scenario here describes some steps that are typically required.

A secure event archive is one where event data can not be tampered (or at least where it is highly unlikely). As such, special care must be taken that the system the archive resides on is tamper-resistant as well as the archived logs.

A typical configuration for a secure log host looks as follows:

As a general guideline, we recommend the following steps to create a highly secure event archive:

  • Firstly, check with your legal counsel and make sure you understand the legal requirements and implications of your doing! This is an essential step. If, for example, event log data is meant to be used in court and there is even a slight failure in your procedures, the data can not be used as evidence!
  • Make sure that the central log host is a dedicated, well-equipped machine.
  • Ensure physical security of the central log host.
  • Ensure that the log host is protected by a firewall and there is no other system inside the log host’s network. Remember: nowadays firewalls have become quite inexpensive. If in doubt, look for a Cisco PIX 501, which offer very much for very little money!
  • Review “Creating a hardened log host” for information on hardening your log host.After mastering the initial steps, creating the log host itself is quite simple:
  • Then, follow the “Creating a simple Syslog Server” step-by-step guide.
  • If you would like to receive Windows event log data or other non-syslog based events, we recommend to set up a SETP server and use SETP for relaying messages from the local Agents. This is described in
    “Forwarding NT Event Logs to a SETP Server”    .
  • Keep in mind that both the syslog server and the SETP server can run concurrently!
  • Point all your log sources to the log host. Instructions for common syslog devices can be found in “Sample Syslog Device Configurations”.This concludes the creation of the log host.
  • Ensure that log data is written to offline media on a regular basis. It is highly recommended to use read-only media like CD-R or DVD-R. Using rewriteable made might make the archive questionable in court. As does writing too infrequently to offline media. We recommend a daily schedule. Be sure to make backup copies from this media and store it on two physically different, secure places. Keep in mind that log data contains very sensitive information: make sure no unauthorized person has access to it. For example, it is not the best idea to send these CDs via postal mail or regular courier.
  • After you have finally set up your system and documented all procedure, be sure to re-check with your legal counsel.
  • Finally, remember that security is not a one-shot! Neither is law. Be sure to apply all hot-fixes to your server as they become available and change your procedures as need arises. Be sure to check with your legal counsel on a regular basis to ensure continued compliance with legal requirements.As you have seen, when creating a secure log host, there are many things beyond the scope of Adiscon’s software to consider. The small guidelines above are hopefully a good starting point. But it is strongly advised to check with other security sites (like www.cert.org)
    and consultants before implementing such a system. Your local government might even run a dedicated site with recommendations.

    Creating a log archive for Evidence in Court

    This is more or less the same scenario as “Creating a highly secure Event Archive”.
    We are providing a separate section as many people have inquired about
    some legal specifics. So we have tried to find some good sources, which
    we list here.

    Again, we can not and do not provide legal advise here – check with your
    legal counsel before implementing any solution.

    In the US, you might also want to visit www.cybercrime.gov.

    To set up a log archive that should potentially be used as evidence in
    court, please follow “Creating a highly secure Event Archive“.

“A complete description of common uses of the MonitorWare line of products. – Analysis

Common uses

Article created 2003-05-14 by Rainer Gerhards.

Updated 2004-06-21 by Tamsila-Q-Siddique.

Analysis

If you are interested in receiving a consolidated view of your overall system
state and activity, you are probably interested in the analysis features of the MonitorWare system.

Please note that this chapter is currently being expanded. As such, the examples and uses given herein do only reflect some of the things that can be done with MonitorWare.

The MonitorWare Agent itself provides the necessary data-gathering facilities to supply event data for analysis. The MonitorWare Agent
itself does not include any analysis feature. As such, it is always teamed up with either other members of the Adiscon MonitorWare line of products or
third party solutions. MonitorWare Agent is also often used to integrate Windows-based event data like Event Log data or IIS log files into UNIX based management solutions.

Centrally Monitoring Windows Event Log Data

In this scenario, you are primarily interested in consolidating Windows Event Log data into a single system. Also, a scheduled overall system activity report should be automatically generated and provided for your review.

This scenario is so common that we have created a dedicated step-by-step
guide covering all steps necessary. Please find it at “Centralized Event
Reports with MonitorWare Console”.

After following the step-by-step guide, you are encouraged to configure your Windows system to supply as many security related and audit information as needed. This is detailed in
“Configuring Windows for the Event Log Monitor”.
Please note that in default configuration Windows supplies only limited
information and also runs the risk of event loss due to filled-up log
files. Follow the guide to resolve this.

The scenario described can easily be extended to include non-Windows
event data, for example Cisco router logs. These events will also become
part of the MonitorWare Console overview report.

Delivering Windows Event Data to UNIX based Management Solutions

In this scenario, Windows Event data is “just” to be forwarded to a
UNIX based management solution. Most often, the UNIX based solution is
already in operation but lacking Windows event information.

In this scenario, MonitorWare Agent is simply configured to forward
captured events via syslog to a central, UNIX based server. There, the
data is stored and further processed. Most often, customer scripts will
parse the gathered data and perform the actual analysis. The key point
here is that MonitorWare Agent enables these scripts and applications to
process Windows events, which are otherwise unavailable to them.

Please note that “Windows Events” does not only include Windows event log data but also text files like IIS log files.

Delivering Windows Event Data to Windows based Third-Party solutions

In this scenario, Windows event data (including event log data as well as
text files and other supported sources) is delivered to a central
Windows loghost and stored there for further analysis. In contrast to
other scenarios, the analysis part is done by third party software and
– most often in this scenario – customer developed scripts.

This scenario is not very common, but there are a number of customers with very specific needs that have great success with it. In general, it can
be combined with Adiscon’s analysis tools described in
“Centrally
Monitoring Windows Event Log Data”.
If used without any Adiscon analysis software, events can be written to
whatever source the custom scripts supports, for example text files or
the database.

Delivering Windows Event Data to Third-Party Solutions

There are a number of third party “black boxes” out that can receive and
process Windows events. A popular example is the Counterpane Sentry, a
device that receives Windows event log data via syslog and stores and
processes it. The Sentry is part of Counterpane’s services offering.
For more information, please visit the Counterpane web site at
www.counterpane.com.