Tag: step by step

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.

Centralized logging in a hybrid environment (Windows/Linux) – Step 4

Step 4 – Setting up the Linux Clients

We still need to implement the Linux clients into our logging network. This could be Linux workstations or servers. Currently, rsyslog is already shipped with many Linux Distributions as the default syslog daemon already. Though, often a rather old version is installed (mostly v3), this will be sufficient for our current goals.

For our example we will use a Fedora system and alter the configuration accordingly. In the end, rsyslog should use the logs, that are logged locally and forward them via TCP to the central log server.

Please note: The example has been made with Fedora 13. Some steps may vary with other Linux distributions. Since there are so many possibilities, we cannot list them all. So we only concentrate on one version.

Step 4.1:

First of all, we need a terminal or command line and go into root mode with su. We do not need the root rights desperately, but it is a bit easier to achieve our goals.

Step 4.2

We need to alter the configuration accordingly. We will use the vi text-editor to do so. If you are not familiar with vi, you should consider getting some knowledge first with the vi man page.

You can find the default configuration file in

/etc/rsyslog.conf

This configuration file will be loaded once rsyslog is started.

Open the configuration file by the following command:

vi /etc/rsyslog.conf

Your terminal should look like this:

centralized_monitoring_4001

Step 4.3

Under the header “#### MODULES ####” you can see the loaded modules. The ones we need are already loaded. For sending syslog, we do not need a extra module to be loaded. Basically, the imuxsock.so is listening to the local log socket and imklog.so provides the support for kernel logging. More is currently not needed.

When going further down in the configuration, we see parts that are called UDP and TCP syslog reception. They are uncommented. We don’t need them, so we leave them that way. As you can see, there is the command to load a module (introduced my $ModLoad) and then a specific command that is given to the module which tells it to run as a syslog server on a specific port.

Step 4.4

When scrolling further down in the configuration file, we will find the header “#### RULES ####“.

centralized_monitoring_4002

Here, some rules are defined about which logs are stored in which location. These rules have a basic format. Basically, this looks like this:

facility.severity storage_location

The facility roughly determines, what has generated the log message. The severity tells you, how urgent the message is. And the storage location determines, where to store the logs. In the default config, there are several rules for some important log files. They will all be stored in the folder /var/log.

We need to add another rule for forwarding all log messages via TCP syslog. For now, go to the last of the rules and insert the following:

*.* @@central_server:10514

This rule means that all messages, no matter the facility or severity, will be forwarded via TCP to the central server on port 10514. We need to choose port 10514, since our central server will listen to TCP syslog on this port.

In the configuration file, this should look like this:

centralized_monitoring_4003

You can now save and quit vi.

Step 4.5

Now that we have altered our configuration according to our needs (which hasn’t been too much), we still have one more thing to do. We need to restart the service.

Now that we are back on the command line, we can easily use the following command:

service rsyslog restart

This will tell the rsyslog service to stop and start again. Thus, the configuration will be loaded with the changes we made.

centralized_monitoring_4004

Step 4 – finished

We are now finished with setting up rsyslog correctly. It will take all the logs it receives and forwards them to our central log server via TCP on port 10514. In addition to that, the default log rules still exist and will log messages to the local harddrive.

Though, there could be many more scenarios and configurations. We decided to keep it simple for a basic setup.

<< Go back to the main page

Centralized logging in a hybrid environment (Windows/Linux) – Step 1

Step 1 – Setting up the central log server:

The central log server is the most important part of our central log storage and thus will be configured as the first part. And due to all the things it needs to do, it has the most work of course. When selecting your machine to install the central log server on, please keep in mind, that you need quite a good machine for larger networks. If you have a very large environment, it might be a good idea to use multiple servers for this scenario with a load balancer and a separate database server. But in this guide, we will have it all on one machine.

Prerequisites:

The following should be installed and working:

  • Windows Server operating system (Windows Server 2008)
  • Database Server (MSSQL)
  • IIS Webservice
  • MonitorWare Agent Professional Server (V7.2)

The list holds the things necessarily needed. In the brackets is schon which we will use in this example. Please note, that this will work with other versions as well, especially with MonitorWare Agent.

As mentioned before, MonitorWare Agent will have multiple purposes. It should receive syslog via TCP and UDP, monitor the local EventLog and textbased logfiles as well as writing everything into a database and sending email messages in case of error and critical messages occuring.

Step 1.1

First of all, we will set up the processing rules and actions. We will start this way due to the design of MonitorWare Agent. Since the Services need to be bound to a ruleset upon creation, we will start this way, so the ruleset is there already when creating the service.

centralized_monitoring_1001

When starting MonitorWare Agent the first time, you will see on the lefthand side our overview of “Configured Services” and “Rulesets”. Right now, there shouldn’t be any entries here.

centralized_monitoring_1002

Right click on “Rulesets”. A context-menu will open.

centralized_monitoring_1003

Choose “Add Ruleset”. The ruleset wizard will open. On this first screen, we can choose the name of the ruleset.

centralized_monitoring_1004

After choosing a name (in this example “Storage & Alert”), click on “Next”. Here we can set, what we will need. Leave the marker for “Create a Rule for each of the following actions” and choose “Send Email” and “Database Logging”.

centralized_monitoring_1005

You can now click on Finish. You will now see a new ruleset in the treeview on the left hand side. If you expand this view completely, you can see the two rules that have been created and the actions that are in there. You should have a rule “Database Logging” and a rule “Send Email”.

Step 1.2

We will now start with configuring the action for “Database Logging”. Expand the branch called “Database Logging” completely. Under actions you will find the “Database Logging” action. When you click it, you will see the configuration window.

centralized_monitoring_1006

Click on the button “Data Source (ODBC)”. This will open the ODBC Data Source Administrator.

centralized_monitoring_1007

Go to System DSN and click “Add…”.

centralized_monitoring_1008

Select SQL Server from the list and click “Finish”.

centralized_monitoring_1009

Choose a name for the datasource and a description. In this case we choose MyMWDB as name. As server choose the name of the server where the database is. In our example we use localhost. Now click on “Next”.

centralized_monitoring_1031

Select “SQL Server Authentication” and type in your MSSQL Login ID and Password. If you have Windows NT authentication like in our case, leave it as is. Click on “Next”.

centralized_monitoring_1010

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

centralized_monitoring_1011

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

centralized_monitoring_1012

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

centralized_monitoring_1013

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

centralized_monitoring_1014

Now we are back in MonitorWare Agent. Insert the DSN for your database, User-ID and Password.

centralized_monitoring_1015

After that, click the “Create Database” button. We still need the tables that the log messages will be stored in. After clicking the button, a small window will open. Insert the DSN, User-ID, Password and choose the type of database you are using, in our case MS SQL. By clicking on the “Create” Button, the tables needed for the default database format of the MonitorWare Products will be created. After that, close the window.

Since we want to log all messages into the database, there is no need to set up any filters.

Step 1.3

In the next step, we want to set up the Send Email rule. But since we only want error log messages, we need to set some filters. Click on the Filter Conditions. You will see the overview over the filters for this rule.

centralized_monitoring_1016

Right now, the view is empty except for a AND operator. Double-click it to change it into a OR operator.

centralized_monitoring_1017

Right-click on the OR operator. A context menu will open. Go to Add Filter -> Syslog -> Priority.

centralized_monitoring_1018

Click on the filter setting and change the property value to “Error (3)”.

centralized_monitoring_1019

Again click on Add Filter -> EventLog Monitor V2 -> Event Severity.

centralized_monitoring_1020

Click on the second filter setting and change the property value to “[ERR]”.

We are now finished with the filter settings. The filter will accept all log messages that are either of syslog proiority error or critical or Windows Event severity error. The OR operator ensures, that every of these cases will be accepted. When the messages are approved of fitting into the filter, the action will process them.

centralized_monitoring_1021

Click on the “Send Email” action now. You will see the configuration window on the right pane. Currently, there are only the default values in there.

centralized_monitoring_1022

We need to change some settings here, like the Mailserver, Sender and Recipient, the subject and the Mail Priority. If necessary for your mail server, you need to change the authentification settings at the bottom as well. in our example we need SMTP Authentication for that. If you want, you could even enable the backup mail server.

Now we have all actions fully configured. It is now time to setup the configured services.

Step 1.4

Currently, when clicking on Configured Services you will not see a thing. But we will configure the services now. Without them, MonitorWare Agent is not able to get any log messages. We will setup 2 Syslog Receiver, 1 EventLog Monitor and 1 File Monitor.

centralized_monitoring_1030

When right clicking on Configured Services a context-menu will open. By moving your cursor to “Add Service” you can see a list of Services, that may be configured. The list seems pretty long, but we basically need 3 services of them.

centralized_monitoring_1024

Click on “Syslog Server” first. The Services Wizard will open. Simply click on Finish for now. Repeat this again for Syslog Server, EventLogMonitor V2 and File Monitor.

centralized_monitoring_1025

In the end, you should have a list with 4 Services. For our example I renamed the services by doing a right-click on the Service name I wanted to change and the choosing “Rename Service”. This was mostly to distinct the two Syslog Servers.

Step 1.5

Settings for Syslog Server UDP

centralized_monitoring_1026

We can leave the “Syslog Server UDP” on default settings. It is already listening to UDP on port 514. The rest of the default settings is just fine.

Step 1.6

Settings for Syslog Server TCP

centralized_monitoring_1027

We will now go to the “Syslog Server TCP” now. Here we need to change several settings. Change the protocol type to TCP and the Listener Port to 10514. Further, we need to enable the option “Messages are separated by the following sequence” in the TCP options. It should look like this now:

Step 1.7

Settings for Event Log Monitor V2

centralized_monitoring_1028

The Event Log Monitor V2 needs no additional setup. Again the default values are ok. If you want specific Event categories not to be stored, you can disable the options. But the basic format is sufficient.

Step 1.8

Settings for File Monitor

centralized_monitoring_1029

The File Monitor needs some additional settings. First, enable the option “Allow Directories or read multiple files”. You will see, that the use of wildcards will be automatically enabled and some other options completely being disabled.

Then we need to set the source files. For our example, we want to monitor the IIS logfiles. At the top of the File Monitor configuration you can see the option “File and path name”. There is a Browse button right next to it. Click it.

A windows explorer window will open, where you can choose the file you want to monitor. Navigate to the path C:\inetpub\logs\LogFiles\W3SVC1\. This is the location where the log files are stored. Please note, that the file location could be different when using another version of IIS. Choose the first file in the list. (Note: Daily Internet Information Server log files are named “u_exyymmdd.log”, with yy being the 2 digit year, mm the month and dd the day of month. To generate the same name with file monitor, use the following name “u_ex%y%m%d.log”.)
Set the Logfile Type to “W3C WebServer Logfile”.

Please note, that this step can be easily adapted for other log files (e.g. DHCP log files) as well.

Step 1 Finished

We have now finished the configuration for our central server. It will now be able to receive syslog either via TCP (port 10514) or UDP (port 514), monitor the local Event Log as well as the IIS logfiles. Once more click the “Save” button to save the configuration (if not done already) and start the service. All log messages will now be stored into the database as they arrive/occur. Further, administrators will be alerted via email once an error occurs.

<< Go back to the main page

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.

Store IIS Logfiles into a Database

Store IIS Logfiles into a Database

Created 2008-10-06 by Florian Riedl

For storing IIS logs into a database you need MWAgent. With the help of this guide, we will show you, how to create a proper configuration for storing IIS logs into a given database structure. The main goal of this guide is to achieve, that the logs will be parsed after a given time of the day, when the database isn’t very busy anymore and then again stopping later to prevent the service from idling all the day.
Please Note: With this setup you are not able to constantly monitor the Windows Eventlog or receive syslog messages at all times.

Step 1

First, create a new RuleSet for storing data into the database. You can simply follow this guide: Creating a Rule Set for Database Logging. Use your own settings of the database for this part.

Step 2

Then create your Filemonitor and point it to the location of your IIS Logfile which you want to monitor. For the basic setup follow this guide: How To setup File Monitor Service. For in-depth configuration, please go on.
(Note: Daily Internet Information Server log files are named “exyymmdd.log”, with yy being the 2 digit year, mm the month and dd the day of month. To generate the same name with file monitor, use the following name “ex%y%m%d.log”.)
Set the Logfile Type to “W3C WebServer Logfile”, set the Check Interval to “1 day” and assign it to your newly created RuleSet.


Figure 1: Configuring the Filemonitor

We have now already created the configuration we need for our goal to be achieved. We now need to determine the correct time to start the service and again to stop it.

Step 3

We will start and stop the service via Scheduled Tasks. But before we create the tasks, we have to do a little bit configuration to the service itself. Therefore, go to the services panel. Press the Windows-button + R and type services.msc into the field and hit enter.

Step 3.1


Figure 2: Type services.msc into the Run-Windows

Step 3.2

After this, the services panel will open. Double-click on the service AdisconMonitoreWareAgent to open up it’s properties and change the Startup Type to “Manual”.

Figure 3: Change Service Properties

After you have done this, confirm the changes and close the Service Properties as well as the Service Panel.

Step 4

Now we can create the Scheduled Task to start the service. Go to the Control Panel and select Scheduled Tasks. You can create a new Task by double-clicking on “Add Scheduled Task”. Simply follow the wizard as I show it.

Step 4.1


Figure 4: Select Application

The first screen of the wizard is of no concern. Simply hit “Next”. Then we shall choose an application. We could browse for any .exe file, but this does not matter, as we have to change all details later anyway. Because of this, I chose the Calculator.

Step 4.2


Figure 5: Select Name and Interval

The second Step is to choose a name with which the Task will be stored and an interval in which it should be run. For this example, I chose to run it daily. The reason for this is, that we want to submit the log data to the database on a daily basis. This can be changed later if necessary.

Step 4.3


Figure 6: Detailed Startup Setup

On the next screen we can be a more precise with the interval configuration. I set the starting time to 5:00 AM. This will start the Task each day at the same time.

Step 4.4


Figure 7: Account details

Here we have to insert the account details with which the Task needs to be run. Please note, that this has to be an account with administrative privileges. Else the service won’t start.

Step 4.5


Figure 8: Finish the Configuration Wizard

Finally, we have reached the end of the configuration wizard. Please check the box to open the advanced properties for this task right after finishing the wizard. Then we can complete the setup. If you missed to check the box, simply double-click on the newly created Task in the list to open the properties.

Step 4.6


Figure 9: Detail Configuration

Now we only have to finish the last step for this Task. We need to change the run command. Instead of calling the calculator.exe we now insert “net start AdisconMonitoreWareAgent” (without the quotes). This command will start the service. Please Note: Check and see if you wrote the Service name correctly, as shown in the screenshot. If you are unsure, check the name in the Services Panel.

Step 5

Now that we have created a Task for starting the MonitorWare Agent service, we need a task to stop it as well. Please note: This Step is only necessary if you do NOT want the service to idle all day. If you do not care about this, it doesn’t matter, because MonitorWare Agent is configured to check the log files every 24h anyway.

Please repeat the Steps 4.1 to 4.6 with the following changes:

Step 5.1


Figure 10: Select Name and Interval

In the second Step, you need to choose a different name of course. This will help you to keep an eye over those Tasks and not mix them up.

Step 5.2


Figure 11: Detail Configuration

In the detail configuration, the command has to be different as well. Instead of the parameter “start” we need to use “stop”. Very self-explanatory.

This concludes this guide. If you have any remarks or suggestions, feel free to contact us. Your feedback is very welcome.

Database Formats

Database Formats

These sample here implement the MonitorWare Common Database Format in widely used database systems. Attention Sybase users: the “Message” name is reserved in your database system and cannot be used as a field name. It needs to be changed, otherwise the table create will fail. Be sure to also change it in to client database field name configuration.

  • JET (MS Access) Sample
  • Microsoft SQL Server Sample
  • MySQL

JET (MS Access) Sample -A sample JET (Microsoft Access) database file is included in the MonitorWare Agent, EventReporter and WinSyslog install set. It conforms to the MonitorWare Common Database format. It is in Microsoft Access 97 format to enhance compatibility. It can be converted to any more current format without any problems. In fact, we recommend using the most current format supported by your system because it offers the best performance. To convert it, please use Microsoft Access.

Microsoft SQL Server Sample – If you would like to create the default database on Microsoft SQL server, please use the following script:

CREATE TABLE.SystemEvents
(
ID int IDENTITY (1, 1) NOT NULL,
CustomerID bigint,
ReceivedAt datetime NULL,
DeviceReportedTime datetime NULL,
Facility smallint NULL,
Priority smallint NULL,
FromHost nvarchar (60) NULL,
Message text,
NTSeverity int NULL,
Importance int NULL,
EventSource nvarchar (60),
EventUser nvarchar (60) NULL,
EventCategory int NULL,
EventID int NULL,
EventBinaryData text NULL,
MaxAvailable int NULL,
CurrUsage int NULL,
MinUsage int NULL,
MaxUsage int NULL,
InfoUnitID int NULL ,
SysLogTag varchar(60),
EventLogType varchar(60),
GenericFileName VarChar(60),
SystemID int NULL,
Checksum int NULL
)

CREATE TABLE.SystemEventsProperties
(
ID int IDENTITY (1, 1) NOT NULL ,
SystemEventID int NULL ,
ParamName varchar (255) NULL ,
ParamValue varchar(255) NULL
)

MySQL Sample – If you would like to create the default database on MySQL, please use the following script:

CREATE TABLE SystemEvents
(
ID int unsigned not null auto_increment primary key,
CustomerID bigint,
ReceivedAt datetime NULL,
DeviceReportedTime datetime NULL,
Facility smallint NULL,
Priority smallint NULL,
FromHost varchar(60) NULL,
Message text,
NTSeverity int NULL,
Importance int NULL,
EventSource varchar(60),
EventUser varchar(60) NULL,
EventCategory int NULL,
EventID int NULL,
EventBinaryData text NULL,
MaxAvailable int NULL,
CurrUsage int NULL,
MinUsage int NULL,
MaxUsage int NULL,
InfoUnitID int NULL ,
SysLogTag varchar(60),
EventLogType varchar(60),
GenericFileName VarChar(60),
SystemID int NULL,
Checksum int NULL
)

CREATE TABLE SystemEventsProperties
(
ID int unsigned not null auto_increment primary key,
SystemEventID int NULL ,
ParamName varchar(255) NULL ,
ParamValue varchar(255) NULL
)

This script should also be easily adaptable to other database systems like Oracle.

When porting the script to other database systems, please note that “nvarchar” is essentially “varchar”. The difference is that data is stored in Unicode which allows storage of non-ANSI characters. Typically, it can be replaced with “varchar” or an equivalent data type without any problems.

Forwarding NT Event Logs to an SETP Server

Step-By-Step Guides

Article created 2003-04-30 by Rainer Gerhards.
Last Updated 2008-02-04 by Florian Riedl.

Forwarding NT Event Logs to an SETP Server

In this scenario, an event log monitor is used to forward all events written to the NT Event Log to a SETP server. This is another instance of the MonitorWare Agent, typically running at a central hub system. This instance receives the event data generated by the sending MonitorWare Agent/EventReporter and can then act accordingly on it. Please note that by utilizing SETP instead of syslog, the MonitorWare Agent/EventReporter can guarantee reliable delivery. Also, the full event details are preserved: another thing not possible with syslog.

This is a scenario often used in a Windows MonitorWare based management system. The event log monitor is used here to forward events into a central repository, where it will be analyzed using pre-existing procedures. Of course, it could also be combined with other event sources like the file monitor or the ping probe. This has been left out to keep the step-by-step guide simple.

Please note that if you need to forward event log data to a syslog based monitoring system (for example on UNIX), you need to use the syslog forwarder. A step-by-step guide on how this can be done is found at “Forwarding NT Event Logs to a Syslog Server”.

In our example, we assume all events should be forwarded to a SETP server at address 10.0.0.1.

Step 1 – Defining a Rule Set for SETP Forwarding

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 already is present when the service will be defined later and needs to be bound to a rule set.

To 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:

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

Click “Next”. A new wizard page appears:

There, select only “Forward via 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”.

This is just a confirmation page. Click “Finish” to create the rule set.

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

As you can see, the “SETP Forwarding” 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 “Forward via SETP” action configured. We will review the settings just for your information. Click on “Filter Conditions”:

As you can see, none of the filter conditions are enabled. In addition, all weekdays are selected. This means that the all information units (the event log information) will be matched by these filter conditions. As such, the rules for the “Forward via SETP” action will always be carried out.

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

As you can see, some useful defaults are already there. It forwards SETP messages to the standard port of 5432. This value is specified by the SETP standard and an unmodified SETP server expects it. Only change it if you definitely know that the SETP server is configured to use another value. If in doubt, use the default value.

However, there are also some things that need to be completed and changed for this scenario.

The only thing that is missing in our property sheet is the server’s address. You can use either a system name or IP address. In our sample, we will use the IP address, because this is faster and more reliable as it does not depend on DNS name resolution. Our target SETP server is on address 10.0.0.1.

After the changes, the dialog looks as follows:

After doing so, you will notice the yellow text on top of the window. It tells you that the configuration changes have not yet been applied. To do so, press “save”.

Now you have a workable rule set for forwarding event monitor data to the SETP server.

Step 2 – Create an Event-Log Monitor Service

Now we need to define an “event log monitor” service. It is the process that monitors the Windows event log for new entries and creates information units as soon as a new entry is found. These information units are then passed to the rule set which in turn forwards them to the SETP server configured in step 1.

Please note that there are some differences in the setup of a SETP supporting event log monitor when compared to the syslog supporting. Of course, the same monitor can be used with both services, but in reality there are a number of format requirements in existing syslog implementations that require a specific format. With SETP, all event information can be transmitted unaltered, so there is no need for any legacy format information.

To define the event log monitor, right click on “Services”, then select “Add Service” and the “Event Log Monitor”:

Once you have done so, a new wizard starts:

Again, you can 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”:

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. There, 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. As such, it monitors all event logs that are present on the system. It also has some protection against overruns of the receiving system or intermediary routers. It monitors the event log in a 60 second interval (sleep time of 60.000 milliseconds), which is the recommended value for typical installations.

Please note that the “SETP Forwarding” rule set 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. By default, the wizard will always assign the first rule set visible in the tree view to new services. If that is not the intended rule set, you need to change it to the correct one here in the service definition.

Also, please note that the wizard uses the default properties from the “Service Defaults”. Obviously, if these are changed, the default properties for new services will differ.

In contrast to the syslog sample, we do not need to change any settings. Specifically, the “Use Legacy Format” checkbox does not need to be checked, as SETP is capable of forwarding all events log-data in native format.

Finally, we review the log specific advanced properties. As a sample, we will go over the application log advanced properties. To do so, click the “Advanced” button:

For our sample, the “Syslog Facility” is not relevant and can be left at the default. Also leave the “Report Truncated Log” option checked. This option will generate a warning message if the respective Windows log is truncated, for example by operator request. If that happens during day-to-day operations in you environment, you might want to uncheck it.

Click OK to return to the main property sheet.

This procedure completes the configuration of the event log monitor.

Step 3 – (Re) Start the Agent Service

MonitorWare Agent/EventReporter 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.

Service control can be done with both the respective operating system capabilities (like service manager MMC) or with the configuration client. These are shown in the red surrounded area in the following screen shot:

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

After service restart, the new definitions are active and MonitorWare Agent/EventReporter will forward all events from the Windows event log to the configured SETP server. Please note that on the first run, all already existing events will be forwarded. Therefore, this might take a little while. On all successive service start, only new events will be forwarded.

Forwarding NT Event Logs to an SETP Server

Step-By-Step Guides

Article created 2003-04-30 by Rainer Gerhards.
Last Updated 2008-02-04 by Florian Riedl.

Forwarding NT Event Logs to an SETP Server

In this scenario, an event log monitor is used to forward all events written to the NT Event Log to a SETP server. This is another instance of the MonitorWare Agent, typically running at a central hub system. This instance receives the event data generated by the sending MonitorWare Agent/EventReporter and can then act accordingly on it. Please note that by utilizing SETP instead of syslog, the MonitorWare Agent/EventReporter can guarantee reliable delivery. Also, the full event details are preserved: another thing not possible with syslog.

This is a scenario often used in a Windows MonitorWare based management system. The event log monitor is used here to forward events into a central repository, where it will be analyzed using pre-existing procedures. Of course, it could also be combined with other event sources like the file monitor or the ping probe. This has been left out to keep the step-by-step guide simple.

Please note that if you need to forward event log data to a syslog based monitoring system (for example on UNIX), you need to use the syslog forwarder. A step-by-step guide on how this can be done is found at “Forwarding NT Event Logs to a Syslog Server”.

In our example, we assume all events should be forwarded to a SETP server at address 10.0.0.1.

Step 1 – Defining a Rule Set for SETP Forwarding

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 already is present when the service will be defined later and needs to be bound to a rule set.

To 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:

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

Click “Next”. A new wizard page appears:

There, select only “Forward via 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”.

This is just a confirmation page. Click “Finish” to create the rule set.

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

As you can see, the “SETP Forwarding” 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 “Forward via SETP” action configured. We will review the settings just for your information. Click on “Filter Conditions”:

As you can see, none of the filter conditions are enabled. In addition, all weekdays are selected. This means that the all information units (the event log information) will be matched by these filter conditions. As such, the rules for the “Forward via SETP” action will always be carried out.

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

As you can see, some useful defaults are already there. It forwards SETP messages to the standard port of 5432. This value is specified by the SETP standard and an unmodified SETP server expects it. Only change it if you definitely know that the SETP server is configured to use another value. If in doubt, use the default value.

However, there are also some things that need to be completed and changed for this scenario.

The only thing that is missing in our property sheet is the server’s address. You can use either a system name or IP address. In our sample, we will use the IP address, because this is faster and more reliable as it does not depend on DNS name resolution. Our target SETP server is on address 10.0.0.1.

After the changes, the dialog looks as follows:

After doing so, you will notice the yellow text on top of the window. It tells you that the configuration changes have not yet been applied. To do so, press “save”.

Now you have a workable rule set for forwarding event monitor data to the SETP server.

Step 2 – Create an Event-Log Monitor Service

Now we need to define an “event log monitor” service. It is the process that monitors the Windows event log for new entries and creates information units as soon as a new entry is found. These information units are then passed to the rule set which in turn forwards them to the SETP server configured in step 1.

Please note that there are some differences in the setup of a SETP supporting event log monitor when compared to the syslog supporting. Of course, the same monitor can be used with both services, but in reality there are a number of format requirements in existing syslog implementations that require a specific format. With SETP, all event information can be transmitted unaltered, so there is no need for any legacy format information.

To define the event log monitor, right click on “Services”, then select “Add Service” and the “Event Log Monitor”:

Once you have done so, a new wizard starts:

Again, you can 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”:

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. There, 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. As such, it monitors all event logs that are present on the system. It also has some protection against overruns of the receiving system or intermediary routers. It monitors the event log in a 60 second interval (sleep time of 60.000 milliseconds), which is the recommended value for typical installations.

Please note that the “SETP Forwarding” rule set 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. By default, the wizard will always assign the first rule set visible in the tree view to new services. If that is not the intended rule set, you need to change it to the correct one here in the service definition.

Also, please note that the wizard uses the default properties from the “Service Defaults”. Obviously, if these are changed, the default properties for new services will differ.

In contrast to the syslog sample, we do not need to change any settings. Specifically, the “Use Legacy Format” checkbox does not need to be checked, as SETP is capable of forwarding all events log-data in native format.

Finally, we review the log specific advanced properties. As a sample, we will go over the application log advanced properties. To do so, click the “Advanced” button:

For our sample, the “Syslog Facility” is not relevant and can be left at the default. Also leave the “Report Truncated Log” option checked. This option will generate a warning message if the respective Windows log is truncated, for example by operator request. If that happens during day-to-day operations in you environment, you might want to uncheck it.

Click OK to return to the main property sheet.

This procedure completes the configuration of the event log monitor.

Step 3 – (Re) Start the Agent Service

MonitorWare Agent/EventReporter 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.

Service control can be done with both the respective operating system capabilities (like service manager MMC) or with the configuration client. These are shown in the red surrounded area in the following screen shot:

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

After service restart, the new definitions are active and MonitorWare Agent/EventReporter will forward all events from the Windows event log to the configured SETP server. Please note that on the first run, all already existing events will be forwarded. Therefore, this might take a little while. On all successive service start, only new events will be forwarded.