Author: adisconteam

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.

Centralized Event Reports with MoniLog

Step-By-Step Guides

Article created 2003-05-08 by Rainer Gerhards.

Centralized Event Reports with MoniLog

In this step-by-step guide, MonitorWare Agent is configured to work together with Adiscon’s MoniLog 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 MoniLog. 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 MoniLog to automatically generate consolidated reports based on the gathered log data.
  • To deliver MoniLog 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.

Our new product called, MonitorWare Console (still in its beta stages) can also be used with MonitorWare Agent. MonitorWare Console is a very strong and comprehensive tool that will help you out in carrying out sophisticated analysis of your system. For more information about MonitorWare Console, please refer to its manual.

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/en/download to do so. In addition to the agent, you need also the MoniLog product. A free, full-featured 30 day trial is available at www.monilog.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!:

  1. Start the MonitorWare Agent.
  2. Select your language – in this example, I use English, so it might be a good idea to choose English even if that is not your preference. You can change it any time later, but using English makes it much easier to follow this guide here.
  3. Then define a new rule set, right click “Rules”. A pop up menu will appear. Select “Add Rule Set” from this menu. On screen, it looks as follows:
  4. Then, a wizard starts. Change the name of the rule to whatever name you like. We will use “Forward SETP” in this example. The screen looks as follow:Click “Next”. A new wizard page appears.
  5. Select only Forward by SETP. Do not select any other options for this sample. Also, leave the “Create a Rule for each of the following actions” setting selected. Click “Next”. You will see a confirmation page. Click “Finish” to create the rule set.
  6. As you can see, the new Rule Set “Forward SETP” is present. Please expand it in the tree view until the action level of the “Forward SETP” Rule and select the “Forward by SETP” action to configure.
  7. Now, type the IP address or host name of our central hub server in the “Servername” field:
  8. Make sure you press the “Save” button – otherwise your changes will not be applied.

Step 4 – Create a RuleSet for database logging

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

  1. Start the MonitorWare Agent
  2. Again, you can select the language to use. And again, I suggest using English, as this makes the guide easier to follow.
  3. Then define a new rule set, right click “Rules”. A pop up menu will appear. Select “Add Rule Set” from this menu. On screen, it looks as follows:
  4. Then, a wizard starts. Change the name of the rule to whatever name you like. We will use “Database Logging” in this example. The screen looks as follows:Click “Next”. A new wizard page appears.
  5. Select only Database Logging. Do not select any other options for this sample. Also, leave the “Create a Rule for each of the following actions” setting selected. Click “Next”. You will see a confirmation page. Click “Finish” to create the rule set.
  6. As you can see, the new Rule Set “Database Logging” is present. Please expand it in the tree view until the action level of the “Database Logging” Rule and select the “Database Logging” action to configure.
  7. Now click on the Data Sources (ODBC) button to open the ODBC Data Source Administrator. Then choose the “System DSN” tab an click the “Add” button to add a new System-DSN (Select the Microsoft Access driver like in the screenshot below).
  8. In the next step, click the “Select” button and go to the MonitorWare Agent installation directory (Usually C:\program files\MonitorWare\Agent\) and choose the sample database called sample97.mdb. After that name the new DSN with “MyDatabaseDSN” like in the following screenshot and press OK.
  9. Now close the ODBC Data Source Administrator and switch back to the MonitorWare Agent Client and insert “MyDatabaseDSN” in the DSN field. Leave all other settings in their default and save the changes.

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!):

  1. First, right click on “Services”, then select “Add Service” and the “Event Log Monitor”.Once you have done so, a new wizard starts.
  2. Again, you con use either the default name or any one you like. We will use “My Event Log Monitor” in this sample. Leave the “Use default settings” selected and press “Next”.
  3. As we have used the default, the wizard will immediately proceed with step 3, the confirmation page. Press “Finish” to create the service. The wizard completes and returns to the configuration client.
  4. Now, you will see the newly created service beneath the “Services” part of the tree view. To check its parameters, select it:As you can see, the service has been created with the default parameters.Please note that the “Default RuleSet” has been automatically assigned as the rule set to use. By default, the wizard will always assign the first rule set visible in the tree view to new services. In our case, this is not correct and will be corrected soon.
  5. Check “UseLegacyFormat”. Next is to uncheck “Syslog Message Number” and uncheck “Add Username”.
  6. Now you must differentiate between clients and central hub server. In clients use the “Forward ” RuleSet we have created in Step 2, select it as rule set to use. In central hub server select the “Database Logging” RuleSet we have created in Step 3. Leave all other settings in their default.Clients:Central hub server:

  7. Finally, save the changes and  start MonitorWare Agent. This procedure completes the configuration of the syslog server.MonitorWare Agent cannot dynamically read changed configurations. As such, it needs to be restarted after such changes. In our sample, the service was not yet started, so we simply need to start it. If it already runs, you need to restart it.

With step 5 the client machines configuration has finished. All the next steps are only concerned with the central hub server.

Step 6 – Create a SETP Server Service

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

  1. First, right click on “Services”, then select “Add Service” and the “SETP Server”.Once you have done so, a new wizard starts.
  2. Again, you con use either the default name or any one you like. We will use “My SETP Server” in this sample. Leave the “Use default settings” selected and press “Next”.
  3. As we have used the default, the wizard will immediately proceed with step 3, the confirmation page. Press “Finish” to create the service. The wizard completes and returns to the configuration client.
  4. Now, you will see the newly created service beneath the “Services” part of the tree view. To check its parameters, select it:As you can see, the service has been created with the default parameters.
  5. To use the “Database Logging” RuleSet we have created in Step 4, select it as rule set to use.
  6. Lastly, save the change and than restart MonitorWare Agent. This procedure completes the configuration of the syslog server.MonitorWare Agent cannot dynamically read changed configurations. As such, it needs to be restarted after such changes.

Step 7 – Preparing Web Server for MoniLog

MoniLog 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 MoniLog. 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 “monilog” directly beneath this directory.

Step 8 – Installing and Configuring MoniLog

Log on interactively to the web server. Then, run the MoniLog setup with default parameters. When setup has finished, perform the following steps:

  1. First, switch to the “general” tab.
  2. “Logs Location” expects the DSN from the database in our scenario. Type in “MyDatabaseDSN”.
  3. Select MonitorWare Database in “Select Syslog server type”.
  4. Next is to check the “Process Non-Windows Syslog messages” box. Leave all other options by default. Now it should look as follow:Click “Apply” after making your changes!
  5. This has already enabled MoniLog reporting. Now, we can verify the installation. To do so, switch back to the “Profiles” tab. Click the “New Profile” button and enter a name. In this example I use the name “Profile1”.Click the “OK” button to create a new profile.
  6. Under “Reports Location”, enter the directory where MoniLog reports should be stored. In our sample, we use “c:\inetpub\wwwroot\monilog”. Leave all other settings as default. The tab should look like this one:Click “Apply” to save your changes!
  7. Next step is to set your report options. To do so, click “Report Options”. A new window opens. Check Success Audit and Information. Now it should looks like this one:Click on “OK” to close the windows by using default options.
  8. Click “Analyze now” to test it. After a short while, a browser window with a MoniLog report will appear. The actual content of this report varies greatly. It depends on which events have been forwarded while setting up the agents. Probably, your report will be empty. This simply indicates that there was not yet any data to be analyzed. Immediately after setup, this is OK. If you don’t receive any data after some hours then of course there is something wrong. If that is the case, check the steps done before. A typical report looks like follows:
  9. Now we have verified the system is working. Next, we can schedule the automatic report. To do so, we need to check “Enable Schedule” and also “Enable Email delivery”. A quick reminder: we would like to receive a pointer to the report via email each working day. We first need to set the web directory the reports are to be stored to and enable email delivery. It is all done in the following screenshot:The “Email Options” and “Scheduled Options” become colored and are now available.
  10. Now we need to configure the email options. Click “Email Options…”. We assume the web server (192.168.0.1) is also acting as a mail server. The emails should be sent to “admins@sample.adiscon.com”. With that, the dialog looks like follows:Important: make sure the values match your configuration! This is vitally important because otherwise MoniLog is incapable of sending email correctly. Click “OK” to apply the new settings.
  11. Next, click the “Report Options…” button. As we schedule reports only on working days, we need to tell MoniLog that it should include all those events occurred since its last run into the reports. We cannot leave the default of 24 hours, as this would exclude the weekend’s events. So change the “Report Type” option to “From last run till now” as seen below.Click “OK” to apply the setting.
  12. Lastly, click on “Schedule Options” to set a schedule. As long as no schedule is set, no reports will be generated automatically. In our sample, we let MoniLog generate reports each working day at 8:00 in the morning. Weekends are not enabled. The dialog looks like this:
  13. Click on “OK” to apply the settings. Typically, the following window occurs:This tells you that the MoniLog service has not yet been started. The service generates the scheduled reports (so you don’t need to run the client in foreground). For now click “OK”. We’ll start the service in the next step. Please note that we now have fully configured reporting, but it will not occur because the service is not yet running.
  14. To conclude your configuration of MoniLog, start the service. To do so, select “Service”, then “Start Service” from the menu. This will start the service. During setup, the service is set to start automatically with system startup. So there is no need to manually restart the service after a reboot.

MoniLog is now completely configured. You will not immediately receive reports, because they will only be generated at 8am each working day. So you need to wait for the next morning. If you would like to change the schedule to have an immediate feedback, please go to “Schedule” and change the time to be a few minutes in the future. Then click “OK” and restart the service. This can be done via the “Service” menu. A restart is necessary because the service reads changed parameters at startup, only.

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 MoniLog).

How To setup SETP Server Service

Last updated 2016-09-01 by Jan Gerhards, using Winsyslog 13.2.

1. First, right click on “Services”, then select “Add Service” and the “SETP Server”.

2. Now you will see a newly created service called “SETP Sever” in the tree view. This will be selected by default after creating the service.

3. The service will be created using default parameters, wich you could change now. In this example, we will leave everything as it is.
However, we will rename the service to “My SETP Server”.

4. Now we still need to set a ruleset for this service to work with. Since we have no configured ruleset available at the moment, simply use the Default RuleSet, if it’s not being used automatically.

5. Last, save the change and then restart the application. This procedure completes the configuration of the SETP server.

The Application cannot dynamically read changed configurations. As such, it needs to be restarted after such changes.

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 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 was the Counterpane Sentry, a device that receives Windows event log data via syslog and stores and processes it.