MonitorWare Agent sending to the Microsoft Message Queue

Created 2011-02-03 by Florian Riedl

With version 8.0 of MonitorWare Agent we introduced a new action called “Send MSQueue”. This action allows MonitorWare Agent Professional and Enterprise to forward the received messages to the Microsoft Message Queue. This action is also available in EventReporter Professional (v12.0) and WinSyslog Professional and Enterprise (v11.0).

To get this new functionality working, you need to do some work in advance. Basically, you need to have the Microsoft Message Queue functionality installed on both the system you want to use MonitorWare Agent on, as well as the system where you want to have the messages being forwarded to. If both systems are the same, the process is can be shortened a bit. But our assumption is, that this is not the case.

Step 1

The server which should receive the messages from the message queue needs the most attention here. We will show how to configure it with the example of a Windows 2008 server. These steps should be similar for a Windows 2003 Server as well.

Go to the Server Manager. On the left hand side, you find everything, that is necessary for the server. Go to “Features”. Then click in the right pane on “Add Features”.

Message Queue 01

You will get a list of features you can install. Right now, we are only interested in the Message Queueing feature. Mark it to be installed. You could expand the view, but for now the default options are sufficient (depending on your needs you might want to install some of the other options). When you have marked Message Queuing, click on “Next”.

Message Queue 03

You will be shown the Features to be installed. The screenshot shows only the Message-Queuing Service, since this is the only feature we want to install right now. Click on “Install”.

Message Queue 04

The feature will be installed now. When the results are shown, it should say that the installation was successful. Click on “Close” now.

Message Queue 05

In your Server-Manager you should now find Message Queuing und Features. Expand the view completely. You will see the different queues now.

Message Queue 06

Most interesting to us are the privat queues. It will hold the received messages later. But for that, we need to create a queue first. Right-click on the private queues. In the context menu go to “New” and then on “privat queue”. A window pops up, where we can define a name for it. Choose a name and click on “Ok”.

Message Queue 08

You can see the newly created queue named test on the screenshot. By expanding the view further, you will find more sub-folders like queued messages and journal messages. We will later find the messages in queued messages.

Message Queue 09

That’s it for now. The server is now ready to receive messages for the message queue.

Step 2

Now we take care of the client setup. We need to setup the message queue feature here as well. In this example we show how to do that on a Windows XP machine. The process should be similar on a Windows Vista or Windows 7 machine.

Go into the Control Panel and open “Add or Remove Programs”. Click on the “Add/Remove Windows Components” on the left side. The Windows Components Wizard will open and it will show you a list of additional programs and services. Scroll down until you find the entry “Message Queuing”.

Message Queue 10

Mark it for installation and click “Next”. The components for Message Queuing will now be installed. When it is finished, the installation wizard will tell you, that you have successfully completed the installation. Click on “Finish”. You can close the “Add or Remove Programs” window as well.

Message Queue 11

That was pretty quick. We do not have to do any extra configuration here. We just needed to install these components for the API to be available, so MonitorWare Agent can use it.

Step 3

We can now configure MonitorWare Agent to send to the Message Queue. We assume, that a basic configuration for MonitorWare Agent is already available and it is configured as a syslog receiver with a ready ruleset.

Therefore we just need to create the action. It is called “Send MSQueue”. Right click on “Actions”. A menu will open. Move the mouse to “Add Action” and the list of available actions will appear. Click on “Send MSQueue”, you will find it in the middle of the list.

Message Queue 12

The setup wizard will occur. Simply click on “Next” and then on “Finish”. You can now see the “Send MSQueue” action with its default values.

Message Queue 13

We need to change at least the “Server Computername / IP” field and the “Queuename” field. These need to be changed for the scenario to work. The rest can stay as is. Though you might want to change at least the “Queue Message Label” as this will always be the same then. You can change it, by using the properties available in MonitorWare Agent. The same goes for the field “Queue Message Body”, which can be completely customized with properties and you own content. By default it holds the message of the Syslog Message or Windows Event.

We need to change the adress field, which is on the top, to the IP of the machine we want to send to. Hostnames currently do not work yet. The “Queuename” must be set as well. This is needed for the queue that should be filled with messages. You can see on the image below, how this should look like.

Message Queue 15

You can get the path yourself by going to your queues on the server. Right click on the queue you want the path of and click on “Properties”. A window with the properties will open. In the field “Label” is the path to the queue. This should be copied and pasted into MonitorWare Agent.

Message Queue 16

Final Thoughts

This is the easiest way to set up MonitorWare Agent to work with the Microsoft Message Queue. More information on the Message Queue is available at the Microsoft website.

Please note: the MonitorWare Agent Service must be started with some account credentials that have administrative privileges on the local machine as well as on the remote server, that shall receive the messages. You might need to set this manually in the control panel for “Services”.

Massive use of memory when using TCP

Massive use of memory when using TCP

Article created 2011-02-01 by Florian Riedl.

Due to some testing we found, that in some cases MonitorWare Agent uses a lot of memory. This will happen, when MonitorWare Agent is configured as a syslog receiver and is listening to TCP. Additionally, this only occurs, when there are large message bursts, that are continously sent.

We realized it, when MonitorWare Agent used up all free memory and even the page file and didn’t stop to allocate memory blocks. First we thought this was a real bug – the memory would be allocated, but not be purged after it was used. But that was not the problem. Further testing proved, that the memory would be free again after a while.

It turned out, that the real reason was a configuration issue in MonitorWare Agent. With the default values for receiving syslog over TCP, the service would not recognize the line separators of the syslog messages, thus “thinking” it would get a single message only and thus allocating more and more memory for this “huge” message. This would happen when receiving large bursts of message and the buffer for receiving syslog messages would be full.

The solution is pretty simple, yet effective. In the configuration client you need to activate a setting for the syslog server. Just activate “Messages are separated by the following sequence” in the TCP Options. With this activated, MonitorWare Agent can properly recognize line breaks. Thus, it will only allocate memory for the real messages in the queue.

This option will be activated by default in the next release of MonitorWare Agent (8.0).

2010-12-02 MonitorWare Agent 7.2a released

Adiscon is proud to announce the 7.2a release of MonitorWare Agent. This is a bufixing release.

This release only consists of two bugfixes:

  • File Monitor
    Fixed issue an which caused message processing problems when the percent characters was within the loglines.
  • Core Engine
    Fixed string processing issues, partitially related to the SetProperty Action.

For more details read the version history

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

MonitorWare Agent 7.2a Released (Build-IDs: Service 7.2.0.399, Client 7.2.0.1326)

MonitorWare Agent 7.2a Released

Release Date: 2010-12-02

Build-IDs: Service 7.2.0.399, Client 7.2.0.1326

Bugfixes

  • File Monitor
    Fixed issue an which caused message processing problems when the percent characters was within the loglines.
  • Core Engine
    Fixed string processing issues, partitially related to the SetProperty Action.

You can download Free Trial Version of MonitorWare Agent.

MonitorWare Agent 7.2 Released (Build-IDs: Service 7.2.0.398, Client 7.2.0.1322)

MonitorWare Agent 7.2 Released

Release Date: 2010-08-02

Build-IDs: Service 7.2.0.398, Client 7.2.0.1322

New Additions

  • Syslog Server
    – Added support for Syslog TLS (RFC 5425). It is possible to use the following modes: anonymous, x509name and x509fingerprint authentication. Note that this requires a valid server certificate as well. More details can be found in the manual.
  • Forward Syslog Action
    – Added support for Syslog TLS (RFC 5425) using your own certificate and
    keyfile, or the anonymous mode. When using the anonymous method, no client
    certifcate is needed.
  • Send Mail Action
    – Added support for STARTTLS command. This extension is required for SMTP Servers which can optionally enable encryption during communication.
  • Updated OpenSSL Components to v1.0.0 for more SSL/TLS stability

Bugfixes

  • Send Mail Action
    Fixed time issue in when “Use UTC Time” option was disabled
  • Property Engine
    Added property replacer option “replacepercent”. This option replaces all % occurrences with %%, which is needed in case that a string is reprocessed using the property engine.

You can download Free Trial Version of MonitorWare Agent.

2010-08-02 MonitorWare Agent 7.2 released

Adiscon is proud to announce the 7.2 release of MonitorWare Agent. This is a minor release including some a new feature and minor bug fixes.

As a very important enhancement, this release offers support for native and standards-compliant secure syslog transport via SSL/TLS. Based on RFC5425, MonitorWare Agent now permits sending and receiving of messages in a secure way. All RFC5425 authentication modes are supported, so messages can not only traverse the network encrypted but clients and server can also authenticate each other. Among others, this provides a reliable safeguard against man-in-the middle attacks. Note that this type of authentication is much stronger than IP-based authorization modes (as, for example, are usually found in firewalls). Of course, both can be used together for even stronger security.

The “Send Mail” Action was improved again, and now supports the STARTTLS command. This means the connection to a mailserver can be secured during transmission, if the mailserver supports it.

For more details read the version history

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

2010-04-23 MonitorWare Agent 7.1 Final Released

MonitorWare Agent 7.1 Released

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

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

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

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

For more details read the

version history

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

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


MonitorWare Agent 7.1 Released

Release Date: 2010-04-26

Build-IDs: Service 7.1.392, Client 7.1.1307

New Additions

 

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

 

Bugfixes

 

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

 

You can download Free Trial Version of
MonitorWare Agent.

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.