2016-04-04 MonitorWare Agent 10.2 released

Adiscon is proud to announce the 10.2 release of MonitorWare Agent.

This is a maintenenance release for MonitorWare Agent, which includes Features and bugfixes.

There is a huge list of changes, but the most important is the enhanced support for file based configurations.

Also inbuild components like OpenSSL and NetSNMP have been updated to the latest versions.

Detailed information can be found in the version history.

Version 10.2 is a free download. Customers with existing 9.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.

How to perform a mass rollout?

How to perform a mass rollout?

Last Update 2013-01-02 by Florian Riedl

A mass rollout in the scope of this topic is any case where the product is rolled out to more than 5 to 10 machines and this rollout is to be automated. This is described first in this article. A special case may also be where remote offices shall receive exact same copies of the product (and configuration settings) but where some minimal operator intervention is acceptable. This is described in the second half of this article.

The common thing among mass rollouts is that the effort required to set up the files for unattended distribution of the configuration file and product executable is less than doing the tasks manually. For less than 5 systems, it is often more economical to repeat the configuration on each machine – but this depends on the number of rules and their complexity. Please note that you can also export and re-import configuration settings, so a hybrid solution may be the best when a lower number of machines is to be installed (normal interactive setup plus import of pre-created configuration settings).

Before considering a mass rollout, be sure to read “The MonitorWare Agent“. This covers necessary background information and most importantly the command line switches.

Automated Rollout

The basic idea behind a mass rollout is to create the intended configuration on a master (or baseline) system. This system holds the complete configuration that is later to be applied to all other systems. Once that system is fully configured, the configuration will be transferred to all others.

The actual transfer is done with simple operating system tools. The complete configuration is stored in the the registry. Thus, it can be exported to a file. This can be done with the client. In the menu, select “Computer”, then select “Export Settings to Registry File”. A new dialog comes up where the file name can be specified. Once this is done, the specified file contains an exact snapshot of that machine’s configuration.

This snapshot can then be copied to all other machines and put into their registries with the help of regedit.exe.

An example batch file to install, configure and run the service on “other” servers might be:

copy \\server\share\mwagent.exe c:\some-local-dir
copy \\server\share\mwagent.pem c:\some-local-dir
cd \some-local-dir
mwagent -i
regedit /s \\server\share\configParms.reg
net start "AdisconMonitoreWareAgent"

Please note: These files are needed if you are using MonitorWare Agent 8.1 and above. If you are using a older version, you additionally need the files Microsoft.VC90.CRT.manifest, libeay32.dll, ssleay32.dll, msvcm90.dll, msvcp90.dll and msvcr90.dll.

The file “configParams.reg” would be the registry file that had been exported with the configuration client.

Of course, the batch file could also operate off a CD – a good example for DMZ systems which might not have Windows networking connectivity to a home server.

Please note that the above batch file fully installs the product – there is no need to run the setup program at all. All that is needed to distribute the service i.e. mwagent.exe and its helper dlls, which are the core service. For a locked-down environment, this also means there is no need to allow incoming connections over Windows RPC or NETBIOS for an engine only install.

Please note that, in the example above, “c:\some-local-dir” actually is the directory where the product is being installed. The “mwagent -i” does not copy any files – it assumes they are already at their final location. All “mwagent -i” does is to create the necessary entries in the system registry so that the MonitorWare Agent is a registered system service.

Branch Office Rollout with consistent Configuration

You can use engine-only install also if you would like to distribute a standardized installation to branch office administrators. Here, the goal is not to have everything done fully automatic, but to ensure that each local administrator can set up a consistent environment with minimal effort.

You can use the following procedure to do this:

  1. Do a complete install on one machine.
  2. Configure that installation the way you want it.
  3. Create a .reg file of this configuration (via the client program).
  4. Copy the mwagent.exe, mwagent.pem, libeay32.dll, ssleay32.dll, Microsoft.VC90.CRT.manifest, msvcm90.dll, msvcp90.dll, msvcr90.dll and .reg file that you created to a CD (for example). Take these executable files from the install directory of the complete install done in step 1 (there is no specfic engine-only download available).
  5. Distribute the CD.
  6. Have the users create a directory where they copy all the files. This directory is where the product is installed in – it may be advisable to require a consistent name (from an admin point of view – the product does not require this).
  7. Have the users run “mwagent -i” from that directory. It will create the necessary registry entries so that the product becomes a registered service.
  8. Have the users double-click on the .reg file to install the pre-configured parameters (step 3).
  9. Either reboot the machine (neither required nor recommended) or start the service (via the Windows “Servcies” manager or the “net start” command).

Important: The directory created in step 6 actually is the program directory. Do not delete this directory or the files contained in it once you are finished. If you would do, this would disable the product (no program files would be left on the system).

If you need to update an engine-only installation, you will probably only upgrade the master installation and then distribute the new exe files and configuration in the same way you distributed the original version. Please note that it is not necessary to uninstall the application first for an upgrade – at least not as long as the local install directory remains the same. It is, however, vital to stop the service, as otherwise the files can not be overwritten.

How you transfer full licenses to another device

This Article describes how you transfer full licenses to another device.

Article created 2011-09-08 by Tim Eifler.

This Article describes how you transfer full licenses to another device.

The Article is applicable to all versions of EventReporter, MonitorWare Agent and WinSyslog.

1. Start the application.

2. Export the Settings to a XML file.

Left-click on “Computer”. A new menu will appear. Select “Export Settings to a XML File” from this menu. On the screen, it looks as follows:

Edit the file name to whatever you like and save the XML File.

3. Transfer the XML File to your new machine

4. Install the application on the new machine.

5. Import the saved Settings from the XML File.

Left-click on “Computer”. A new menu will appear. Select “Import Settings to a XML File” from this menu. On the screen, it looks as follows:

Search your XML File and make a Left-Click on the file. Then press on Open.

6. Click “Yes”.  After this please restart the program.

7. Check if the license key has been transferred correctly and start the service. You can see it in the Headline “Basic Edition licensed to Test-Key(Your name)”

That was it.

Conclusion

And this is all you need to do to transfer your License to a new machine.

70-486 pdf   ,
AWS-SYSOPS pdf   ,
220-902 pdf   ,
101 pdf   ,
VCP550 pdf   ,
9L0-012 pdf   ,
C_TFIN52_66 pdf   ,
70-411 pdf   ,
LX0-104 pdf   ,
300-115 pdf   ,
102-400 pdf   ,
300-320 pdf   ,
1V0-601 pdf   ,
70-412 pdf   ,
LX0-103 pdf   ,
70-347 pdf   ,
OG0-091 pdf   ,
JN0-102 pdf   ,
1Z0-051 pdf   ,
70-178 pdf   ,
70-980 pdf   ,
70-532 pdf   ,
220-901 pdf   ,
300-135 pdf   ,
210-260 pdf   ,
200-120 pdf   ,
CAS-002 pdf   ,
9L0-066 pdf   ,
NSE4 pdf   ,
NS0-157 pdf   ,
SSCP pdf   ,
ITILFND pdf   ,
HP0-S42 pdf   ,
ICBB pdf   ,

Database Logging with MSSQL

Step-By-Step Guides

Article created 2004-09-14 by Timm Herget.
Last Updated 2011-07-27 by Florian Riedl.

Database Logging with MSSQL

This is a very quick step-by-step guide. It essentially is a step in multiple
configurations. You can refer to this guide whenever you need to add
database logging to one of your services.

Though we need to add some sidenotes for issues with 32/64bit systems. If you have a operating system
which is a 64bit edition, the installer for EventReporter, MonitorWare Agent or WinSyslog will automatically
install the appropriate binaries (64bit) on the system. The problem is now, that generally the 32bit drivers for ODBC
would work fine, but 64bit applications can only use drivers that are for 64bit as well. Therefore it is best
to make sure, that you have installed the 64bit ODBC drivers as well. This does only apply for MSSQL and MySQL databases. If you are trying to use a JET database with Adiscon’s products on a 64bit system, you’re in bad luck, since there are no 64bit ODBC drivers available.

MSSQL Enterprise Manager

1. To create a new Database, open up the Microsoft SQL Enterprise Manager.

2. Right-click on “Databases” and select “New Database”.

3. Select a Database Name there and click “OK”.

ODBC Data Source Administrator

After you created the new Database, go to the Control Panel -> Administrative Tools and open up “Data Sources (ODBC)”.
The following Window will appear:

4. Click on “System DSN” and then “Add…”.

5. Select “SQL Server” as Driver from the List and click “Finish”.

6. Choose a Datasource Name, Description and select the Server where the Database is. In our example we use “localhost”.
Click on “Next”.

7. Select “SQL Server Authentication” and type in your MSSQL Login ID and Password. Click on “Next”.

8. Select “Change the default Database to:” and choose your new created Database, in our example we use “MyMWDB”. Click on “Next”.

9. Leave all at default settings and click “Finish”, a test Window will appear:

10. Click on “Test Data Source”, normally the following Window should be displayed:

11. If not, go back and check your Settings, if yes, Click “OK” and exit the System-DSN Wizard.

Monitor Ware Line Product

12. To define a new rule set, right click “Rules”. A pop up menu will
appear. Select “Add Rule Set” from this menu.

13. Then, a wizard starts. Change the name of the rule set to whatever name you
like. We will use “Database Logging” in this example. The screen
looks as follows:

14. Click “Next”. A new wizard page appears:

15. 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.

16. The wizard closes and the client shows a newly created rule set.

17. 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.
You will see the following Window now:

18. Type in your DSN, User-ID and Password now and press “Save”.

19. Click on the “Create Database” Button to let the Programm create the Adiscon-Table-Layout in your Database.

Done 🙂

Creating a simple Syslog Server

Last updated 2016-08-26 by Jan Gerhards, using Winsyslog 13.2.

In this scenario, a simple Syslog server will be created. No other services are configured. The Syslog server will operate as a standard Syslog server on the default port of 514/UDP. All incoming data will be written to a single text file.

Step 1 – Defining a Rule Set for File Logging

The rule set specifies what action to carry out. You might be tempted to define the service first, but starting with the rule set makes things easier as it will be already present when the service is defined later and needs to be bound to a rule set.

To define a new rule set, right click “RuleSets”. A pop up menu will appear. Select “Add Rule Set” from this menu. On screen, it looks as follows:

Then, a wizard starts. Change the name of the rule set to whatever name you like. We will use “Write Syslog Log File” in this example. The screen looks as follows:

After that, select “Add a Rule for each of these Actions”. You should then be able to change settings in the before greyed-out area. There, select “File Logging” (subitem of “Storing Actions”). Your screen should now look like this:

After that, click “OK” and the wizard will close. The client will now show a newly created rule set.

As you can see, the “Write Syslog Log File” rule set is now present. Please expand it in the tree view until you have the following screen contents:

As you can see, we have a “File” action configured. We will review the settings just for your information. Click on “Filters”:

As you can see, none of the filter conditions are enabled. This means that the all information units (incoming messages) will be matched by these filter conditions. As such, the rules for the “File Logging” action will always be carried out for all messages.

Please note that this also means that all Syslog priorities and facilities will be written to the same file.

Now let us check the “File” action itself. Please select it in the tree view:

As you can see, it has been created with the default parameters. Each day, a file will be created in the C:\temp directory and its base name will be MonitorWare (meaning the name of the generated file will be MonitorWare-*date*, i.e. “MonitorWare-2016-08-26.log”). It will include all information items in the file (you can select the information items that will be in the file by scrolling down and ticking the boxes).

If you would like to store it into a separate directory or change the file name, here is the place to do it. Important: please make sure the directory you specify exists! If it does not yet exist, please create it before you start the service. If the directory does not exist, the service is not able to store any files.

In our example, we would like to save it to “C:\logfiles” with a base name of “Syslog”. Therefore, we change these properties.

After doing so, please remember to save your changes. To do so press “Save” (upper left corner).

Now you have a useable rule set for logging incoming messages to a text file.

Step 2 – Create a Syslog Server Service

Now we need to define a Syslog server service. A Syslog server is also sometimes called a “Syslog daemon”, “Syslogd” or “Syslog listener”. It is the process that receives incoming messages.

To define it, right click on “Services”, then select “Add Service” and the “Syslog Server”:

Once you have done so, a configuration pane opens.

Also, you will see a newly created service beneath the “Services” part of the tree. View and can rename it if you want (in this example, we will name it “My Syslog Server”). After this, press save.

Your screen should now look like this:

As you can see, the service has been created with the default parameters. As such, it operates as a RFC compliant standard Syslog server.

Please note that the “Write Syslog Log File” has been automatically assigned as the rule set to use. This is the case because we already created it and it is the only rule set. If another one is to be used, you can change it to another ruleset here (you might have to scroll down to view the option):

This procedure completes the configuration of the Syslog server.

Step 3 – (Re-) Start the Service

The application cannot dynamically read changed configurations. As such, it needs to be restarted after such changes. In our example, the service was not yet started, so we simply need to start it. If it’s already running, you need to restart it.

Service control can be done with both the respective operating system capabilities or with the configuration client. These are highlighted in the screenshot below:

The buttons resemble Windows service manager – start, stop and restart. In this example, stop and restart are grayed out because the service is not running.

After service restart, the new definitions are active and the application is ready to accept and store incoming messages.

Step 4 – Configure your Syslog-Enabled Devices

Even though application is now ready, it can only receive messages if some devices send them. Remember, Syslog is a protocol where the server is passively waiting for incoming messages. As long as no device sends message, the Syslog server will not log anything.

Since there are a large variety of devices, we unfortunately cannot provide device specific instructions. However, almost all devices need to be configured with their specific configuration tool. Typically, only two settings need to be made: one to activate Syslog messages at all and one with the Syslog server IP address or name.

Remember: the computer running application now acts as a Syslog server. As such, you need to find out its IP address or name and supply it to the device as the Syslog server. Please note that not all devices can operate with computer names. Use the IP address, if in doubt.

SMTP

SMTP

The “Simple Mail Transfer Protocol”. This is an Internet standard for
sending email messages. Virtually all major email systems are either based on SMTP or at
least offer gateways to SMTP capable systems.

SMTP is used for sending email. It can not be used to pick up email messages.
For this purpose, protocols like POP3 or IMAP4 are required.

SMTP is highly standardized. As such, a standard email client can work with
all SMTP compliant servers. In the public Internet, almost all providers offer
SMTP compliant mail servers for their customer’s use.

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.