Rule Engine

Created by Wajih-ur-Rehman.

Overview

This paper explains you the Rule Engine that is employed in some of the MonitorWare Line of Products namely MonitorWare Agent, WinSyslog and Event Reporter 6.0 (and higher)

What is Rule Engine

Rule Engine is actually an engine present in the above mentioned MonitorWare Line of Products using which you can define certain filters and the actions that are to be carried out if the defined filter condition matches with the real time condition.

Rule Engine revolves around four basic concepts:

  1. Information Unit
  2. Information Services
  3. Rule Sets
  4. Queue Manager

In order to understand the complete Rule Engine, you need to understand the above mentioned four concepts. The details of these are written below

1. Information Unit (Info Unit)

“Information Unit” or “Info Unit”, as we call it, is the basic building block of Rule Engine. Info Unit is basically an object that contains all the information about a specific event which includes:

  • Message
  • Which application generated this event
  • When this event was generated
  • Syslog Facility
  • Syslog Priority
  • Info Unit Type (it tells which Info Service has generated this Info Unit)
  • etc

The following figure will give you an idea about an Info Unit:

Figure 1: Conceptual Diagram of an Info Unit

As the figure illustrates, an Info Unit contains most of the properties (mentioned above in bullets) in the form of a list. In addition to this list, it also has some commonly used properties separately stored in it (for efficiency reasons). Apart from the properties, an Info Unit also has some methods which allow it to write it or to construct itself etc. Information about the Rule Sets (will be explained in the coming sections) is also contained within each Info Unit so that it exactly knows which rules will be applied on it.

2. Information Services (Info Service)

“Information Services” or “Info Services”, as we call them, generate Info Units. Each Information Service will generate its own Info Units. The important thing to note over here is that each Info Unit has the same format but can have different properties and rule sets associated with it. For example, if an architect makes a building plan then it becomes a template. Now he can use this template to construct as many buildings as he likes but each one can have different properties (they can differ in color scheme, window styles etc). Exactly in the similar way, an Info Unit is actually a template from which each Info Service makes a specific object of Info Unit that might differ in properties from another Info Unit object.

Examples of Info Services

There can be a number of different examples on Info Services. Following are some of the examples:

1. Syslog Server

It receives the messages that are forwarded to it and for each message (or event) it generates an Info Unit out of it.

2. Event Log Monitor

It picks up the events from the Window’s Event Log and for each event it constructs an Info Unit.

3. Ping Probe

It pings a specified device and if doesn’t find a response from the other side, it generates an Info Unit with desired information.

Important Note

One thing to note about Info Services is that there can a number of different Services running on the same machine. You can even run the different instances of the same Info Service (but with different properties naturally). In either case, each Info Service will generate its own Info Unit.

3. Rule Sets

As the name suggests, a Rule Set is a set of Rules. A “Rule” consists of the following two things

  1. Filter Condition
  2. Actions

You might have noticed that the point 1 written above is singular and point 2 is plural which clearly means that you can define only one Filter condition for one rule but can define as many actions as you like. The filter condition can however contain as many Boolean operators as you like.

Filter Condition

Filter Condition is a combination of different Boolean operators which will evaluate to a Boolean answer. In simple words, the result of a filter condition can either be True or False.

Actions

Actions are all those events which are fired when a filter condition evaluates to a True value. As mentioned above, a Rule can have more than one actions associated with it which means that if a filter condition evaluates to a true value then all of the actions associated with that rule will execute. If the filter condition, on the other hand, evaluates to a false value then all of the defined actions will be skipped.

Note that other than normal actions, there are three special kinds of Actions that are worth mentioning here:

  1. Discard Action (Explained Later)
  2. Include Action (Explained Later)
  3. Actions that can alter the contents of Info Units permanently

4. Queue Manager

Queue Manager simply maintains a queue of all of the Info Units that have been forwarded to it by different Info Services.

Overall Picture

This section will explain you that how the different components are related to each other and how does the whole process work. The picture shown below gives an idea about how things are working. As you can see that we have four different stages through which the events are processed.

Info Services picks up the events and convert them into Info Unit. Note that each Info Service has its own Info Unit. These Info Units are passed to the Queue Manager. The job of the Queue Manager, as mentioned above and as clear from the diagram, is to simply make a queue of these Info Units that it has received from various Info Services. The Rule Engine picks up the Info Units from this Queue Manager, applies the rules on these Info Units (as mentioned above, each Info Unit has the information about which rules should be applied on it) and if necessary carries on the actions. The rule engine keeps on repeating this process while there are some Info Units present in the Queue Manager’s Queue.

Figure 2: Overall Process

How Does the Rule Engine Work

Having explained the overall picture of the whole process, let’s specifically talk about Rule Engine. The following figure explains it in detail:

Figure 3: Working of Rule Engine

As you can see in the figure, the Rule Engine picks up Info Units one by one from the Queue Manager. Since each Info Unit has the information about its Rule sets, it will apply the rules on it in the same order in which they were defined. As you can see above, it will pick up the first Rule and evaluates its Filter Condition. If that Filter Condition is evaluated to false, all the actions associated with that rule will be skipped and it will pick up the second Rule. If the Filter Condition, on the other hand, evaluates to True, it will execute all the actions that are associated with this Rule in the order in which they were defined. After the execution of all these actions, it will pick up the next rule in the current rule set. Once all the rules have been executed, the current Info Unit (that was handed over to Rule Engine by the Queue Manager) will be destroyed and the Rule Engine will go to the Queue Manager to pick up the next Info Unit if there exists one.

The above picture has been drawn for normal flow of executions. There can be 2 conditions when the flow will not follow the diagram shown above. These conditions arise in response to 2 special kinds of actions that are called Discard Action and Include Action.

Discard Action

A Discard Action immediately destroys the current Info Unit and any action of any Rule that has been defined after the Discard Action will not be executed at all. Let’s take a simple example to clarify it further.

Let’s say that Action 2 of Rule 1 in the picture above is a Discard Action. If the Filter Result of Rule 1 is evaluated to true, then Action 1 will be executed. As Action 2 is a Discard Action, immediately the current Info Unit will be destroyed (which means that now the Rule Engine will skip all the Rules and all the actions associated with them) and the Rule Engine will go back to the Queue Manager to pick up the next Info Unit in the Queue.

Include Action

An Include Action simply includes another Rule Set in some existing Rule Set. When this Action is encountered, the Rule Engine leaves the normal flow and go to the included rule set (which may contain many rules as well). It executes all the rules that have been defined in that included Rule Set. After the execution of all of them, it will return to its point from where it left the original flow. Let’s take an example to clarify it a little further.

Let’s say that the Action 1 or Rule 1 is an include action. If the Filter Condition result of Rule 1 evaluates to true, it will execute the Action 1. Since Action 1 is the include action in this example, it will go to the included rule set and will execute its Filter Condition. If that filter condition evaluates to true, it will execute all of its actions and will return to Action 2 of Rule 1 (of normal flow) and if on the other hand, the filter condition of the included rule set evaluates to false, it will skip all of its actions and will come back to the Action 2 of Rule 1 (of normal flow).

Note that there is no limit on including the rules which means that a rule that has been included in another rule may contain another rule in it which might contain another rule in it and so on.

Suggestions for Defining Complex Rule Sets

While defining a complex Rule Set, it might be a good idea to follow the stages defined below.

Stage #Actions
Stage 0Discard unwanted events
Stage 1Post Process
Stage 2Discard unwanted events
Stage 3All Actions
Stage 4Individual Actions

As mentioned above, the rules and actions will be executed in the order in which you will define them. So it’s very important that you define the actions in a way such that you achieve the desired results as well as achieve them with efficiency. For example, if you haven’t defined any filter which we call as No Filter (it always evaluates to true) and if the first action that you have defined is the Discard Action, then there is no meaning of defining any action after this first action because the first action will always be executed and it will always discard the complete Info Unit.

Here is the explanation of the above mentioned stages.

Stage 0

In this stage, you can discard those events that you are not interested in. You can use the Discard Action explained above to discard the events.

Stage 1

In this stage, we recommend to Post Process the incoming Info Units. Once the Info Unit has been handed over to the Rule Engine from the Queue Manager, you can actually change the contents of the Info Units to make them more meaningful.

Stage 2

In this stage, you might want to again discard those events that you are not interested in. Simply use the Discard Action.

Stage 3

In this stage, you will apply the actions that will apply to all of the Info Units coming (to be more specific, you will apply those rules over here for which you have selected “No Filter” as the filter condition.

Stage 4

In this stage, you will create the rules for which you have specific filter conditions.

To sum it up, we recommend doing most generic things first and least generic things later or in other words, do the generic things first and the specific things later. Note that this section suggests only the typical scenario but it can vary from depending upon the needs. For example, you might want to perform some actions on some specific events after stage 1 and before stage 2.

Author’s Address

Wajih-ur-Rehman
wrehman@ro1.adiscon.com

Adiscon GmbH
Mozartstrasse 21
97950 Grossrinderfeld
Germany

Disclaimer

The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the authors be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user’s own risk.

How to Monitor Windows from Unix

Article created by Rainer Gerhards.

Many system administrators are running Unix / Linux based monitoring and alerting for a long term. The basic idea behind a successful monitoring and alerting system is to centralize all system events at a single monitoring station. Once the information is centralized, it can be used to build an alerting system or even carry out corrective actions.

Syslog protocol

Many Unix based administration solutions are build around the syslog protocol. Syslog is a quite simple protocol. It’s whole idea is to have a server (or daemon as it is called in Unix speak) listen to incoming messages. That server gathers the received messages and writes them to log files. Minimal filtering capabilities are build into both the syslog daemon as well as the protocol itself: the so-called syslog facility and priority. The facility is meant to identify the source of a message (e. g. the print spooler subsystem or a local application). The priority really is a severity code. It runs from debug messages at the lowest to emergency priority at the top. The syslog daemon itself usually does not assign any specific meanings to the facilities and priorities. However, it can be configured to write messages depending on their facility and priority to different log files. It can also discard them totally or forward them to a chained syslog daemon – but we won’t discuss that in detail.

Once the messages have been written to a file, they can be further examined. Many system administrators nowadays use PERL scripts to parse the files and filter out important events. Older solutions are often build with SED, GREP and a lot of help from shell scripts. No matter how it is done, all solutions have in common that the syslog message file is checked periodically and automatically. With no need for manual intervention, there is also no risk of forgetting it.

The big advantage of syslog is that the message file holds all messages reported (if configured to do so). By using clever scripts, a sys admin can also detect complex error scenarios and act accordingly.

Who Reports to the Syslog Daemon?

The whole idea behind syslog is to have all sources report to the central location. As such, it is extremely important that all devices and systems report to the syslog daemon. Fortunately, syslog has been widely adopted as an industry-standard. Nowadays, all leading manufacturers support it. So it is easy to gather information from e. g. routers, switches, firewalls, SANs (storage area networks), print servers and Unix hosts into the central repository.

Unfortunately, there is one widespread used operating system that is not capable of generating syslog messages – Microsoft Windows NT. With more and more NT systems being installed, that fact is challenging the existing system monitoring and alerting infrastructure. Admins become forced to look for expensive and not integrated Windows NT management systems.

Is there any Way to make Windows Report via Syslog?

As a computer consultant, I stumbled into this problem way back in 1997. I had the task to integrate Windows NT system monitoring into an already existing syslog based system. The Windows NT box had been brought into this data center in order to run an application that was supported under Windows only (by the way: in my experience this is a common scenario for Windows to enter Unix data centers). My customer did not like the idea of running a separate Windows admin system. So I looked into Window’s capabilities to check if there would be any work around. I realized very quickly, that the essentials were build into the product. Windows NT (but not 9x) has a consistent event logging mechanism called the “event log”. This log is maintained on a per machine basis and has different section for different pieces of information (e. g. application and system events). Theoretically, it is extensible but I have never found any third-party application creating it’s own Windows event log. All well behaved applications utilize the event log. This is part of the Windows logo specification, so thing are pretty good you favorite NT application will use it, too.

But that was the end of the good news: the event logging API was very bad documented. Also, NT does not contain any functionality to push that information out of the logs automatically. And it definitely does not talk syslog.

So we decided to write a small tool, EvntSLog (Event to Syslog) to extract the information and forward it to a syslog daemon. That tool was to be implemented as an NT service, so that it could be automatically started on system startup and also be run in the background. The initial tool we crafted in early 1997 was severely limited and far from a commercial product. However, it solved it’s purpose very well and made my clients happy. In fact so happy, that they talked about this tool to their colleagues in other companies. Which yield to a number of requests for this tool and finally yield to the decision to build a real product out of it.

Now, in February 2001, the tool – under the name of EventReporter – has just been released in version 6.2 and is running at thousands of installations worldwide. And it still successfully serves the same need.

So what do I need to do to Integrate NT into my Syslog?

Fortunately, it is fairly simple. First of all, you need to check if your syslog daemon accepts messages from remote hosts. If you already use the syslogd to receive such messages, there obviously is nothing more to do. If you start with syslog, you need to check your specific product’s documentation. Most syslogd’s need a startup switch (usually “-r”) to allow reception of remote messages.

After that, you need to make sure your Windows event logs are active. Unfortunately this must be done on each system separately. To do so, start the Windows Event Viewer under Windows NT. Under Windows 10, the same tool is found in the “Computer Management” under “System Tools” and then “Windows Logs”. Right click on the section you want to configure and then select “Properties”. A window like this should open:


Windows 10 Event Log Properties

As you can see, this are the properties for the application event log. Remember that there are 3 event logs under Windows NT and up to 3 more under Windows server (depending on the server role). The properties need to be set for each event log separately.

First of all, it is important to set the properties so that logging is active. A common problem are log files that are to small. As you can see, the maximum size of the log file is configured. Once this size is reached, NT will disable event logging unless it is instructed to overwrite events as needed. As you can see, we have checked that option. You might ask if that isn’t a possible weakness because events will be overwritten without being seen. With our syslog based environment, that really is not an issue. EventReporter periodically reads all logs and forwards their content to the syslog daemon. There they are finally stored. The local Windows system just needs to have log files large enough to hold all messages that are newly logged between EventReporter iterations. I typically recommend that EventReporter is run every minute or so (it does not place a noticeable burden on the monitored system). As such, the event log buffer needs not to be very large in order to buffer all events during this period. However, with disks being that inexpensive today, I recommend leaving 1 MB for each log file – you never know. Especially security attacks might generate a large number of events in a short period of time and you most probably won’t loose them. Just in case you wonder: EventReporter tracks its last reported message by itself and as such does not report any events already reported, no matter how large the buffer. It does, however, detect truncated log files which can be a nice feature to detect security compromises.

Once you have set up the Windows event system, you need to install and configure EventReporter on each system that is to be monitored. The reason it needs to be installed on each system is performance and stability. With each instance running locally, there is no unnecessary network burden for the transmittal of unneeded events (which can be filtered out by the product) nor is there any single point of failure (like with a single system doing all the monitoring tasks). EventReporter has support for mass rollouts and its configuration settings (registry) are documented in detail. So even large installations do usually not have any issue with the local installation.

The basic EventReporter setup is easy and straightforward. Simply use the client configuration tool that comes with the product. It just needs to be told to which syslog server it should report (IP address or resolvable name). There can also a backup syslog daemon be specified. If done, EventReporter sends each message to both syslogds. Once this is done, EventReporter can be started.

On its initial start, it dumps out all events currently in the NT event logs. So expect quite a number of messages to arrive at the syslogd. After that, it will forward only new messages.

In order to fully integrate into existing environments, EventReporter can send the different Windows event logs with separate syslog facilities. The Windows severity code (Error, Warning, …) is also translated into a standard syslog priority. The message itself can easily be parsed at the receiving side and contains all information from the event log. Most importantly, it contains expanded message strings. One of the problems with the Windows event log API is that the event entries actually do not contain the event message itself. Instead, they contain an index into a so-called “message file”. This was meant to support internationalization, but has a severe drawback: if the message file is not (or no longer) installed at the system, the message text is lost. This most often happens when you try to view an event log remotely and do not have the products installed that generated events (e.g. Exchange server events when viewing from a Windows NT workstation).

EventReporter can also locally pre-filter events. This can be done much like in Windows event viewer. Filter criteria’s can be the event source, event id and other properties of the event log record. Local filtering is a powerful feature to avoid unimportant messages to be forwarded to the syslog daemon. So it helps reduce the size of the central syslogd’s log file.

A simple and effective Solution

With EventReporter, Windows NT can easily be integrated into existing syslog based management systems. The best news for Admins currently using such a system is that they do not need to add a new management system to their environment. They can also use all the powerful tools (like PERL scripts, pager activation programs and the like) they already have in place. It is no wonder that many large organizations have chosen that path.

I hope that this article on the Integration of Windows NT event logs into the Unix environment is helpful. If you have any questions or remarks, please do not hesitate to contact me at rgerhards@adiscon.com.

Discussion on MonitorWare SystemID and CustomerID

Created by Hamid Ali Raja

SystemID

It is a user-configurable numerical value that has been added for grouping a group of systems and improves filtering. It is just like a numerical code to which you can assign a value and query it afterwards.

CustomerID

It is similar to SystemID. It depends on user that how he uses these.

Let us consider the following scenarios to better understand the functionality of these two:

Scenario 1

A service provider has 2 customers, customer A with 2 subsidiaries and customer B with 3 subsidiaries. How can he use SystemID and CustomerID to configure all systems in different subsidiaries to monitor his customers’ networks?

Solution

His configurations for this scenario will be:

 

  • For all systems in subsidiary 1 for customer A, CustomerID = 1 and SystemID = 1
  • For all systems in subsidiary 2 for customer A, CustomerID = 1 and SystemID = 2
  • For all systems in subsidiary 1 for customer B, CustomerID = 2 and SystemID = 1
  • For all systems in subsidiary 2 for customer B, CustomerID = 2 and SystemID = 2
  • For all systems in subsidiary 3 for customer B, CustomerID = 2 and SystemID = 3

 

Scenario 2

A service provider has 2 customers. Customer A has 5 servers and Customer B has 2 servers. Both A and B happen to have a server named “SERVER”. How can the service provider use customer ID to monitor his customer’s servers and differentiate between them?

Solution

To monitor customer’s server, you can put in different CustomerIDs into each of the agents.

 

  • For all systems of Customer A, CustomerID = 1
  • For all systems of Customer B, CustomerID = 2

 

Now with the help of CustomerID, these machines are uniquely identifiable.

You can also use Set Property feature to rename the server.

Scenario 3

A single user has two subsidiaries (A & B) and also wants to group machines by department (marketing, engineering and production). How can he do this using both CustomerID and SystemID?

Solution:

He can address his problem by assigning a unique CustomerID to each subsidiary and unique SystemID to individual department.

Subsidiaries

 

  • A will be assigned CustomerID = 1
  • B will be assigned CustomerID = 2

 

Departments

 

  • Marketing department will be assigned SystemID = 1
  • Engineering department will be assigned SystemID = 2
  • Production department will be assigned SystemID = 3

 

If he wants to view all marketing department machines, he queries for SystemID = 1 and to view all machines in subsidiary A, he queries for CustomerID = 1. He can also get machines which belong to both production department and subsidiary 1 by using CustomerID = 1 and SystemID = 3.

Scenario 4

I have three subsidiaries A, B and C with 200, 2000 and 5000 machines respectively. If I can use “FromHost” to get the system information then why do I need “SystemID”?

Solution

To query all subsidiary C machines using “FromHost” is a lengthy task as it has 5000 elements and you also need to update the queries each time a new machine is installed in a subsidiary.

If you just query the SystemID, you have a single query element PLUS you do not need to modify the queries when you install and configure your new machine correctly to the subsidiary.

Concept of Indexing

What are indexes?

An index

  • Is sorted by key values, (that need not be the same as those of the table)
  • Is small and has just a few columns of the table.
  • Refers for a key value to the right block within the table.
  • Speeds up reading a row, when you know the right search arguments

Why we need indexes?

For large tables an index can improve performance. An index can

1. Make rows unique using single or compound keys
2. Speed up search actions with

  • Data or key values
  • Foreign keys. This kind of indexes will especially speed up joins.
  • Combination of keys, foreign keys and data values.

3. Sort a table

Types of indexes

Unique Index

A unique index is one in which no two rows are permitted to have the same index value.

For example, if you create a unique index on the employee’s last name (lname) in the employee table, then no two employees can share the same last name.

Primary Key Index

A database table often has a column or combination of columns whose value uniquely identifies each row in the table. This column is called the primary key of the table. Defining a primary key for a table in a database diagram automatically creates a primary key index that is a specific type of unique index. This index requires each value in the primary key to be unique. It also permits fast access to data when you use the primary key index in queries.

Clustered Index

In a clustered index, the physical order of the rows in the table is the same as the logical (indexed) order of the key values. A table can contain only one clustered index.

If an index is not clustered, the physical order of the rows in the table does not match the logical order of the key values. A clustered index usually provides faster access to data than does a nonclustered index.

Cluster indexing concept

An overview of indexing related to our database design

The SystemEvents table in the database is of the main concern here. Indexes introduce paging within the database which improves the performance. Clustered indexing normally clusters the similar values in a column of the database. That is, if we apply index on ‘fromhost’, it shall cluster all the records closely having ‘fromhost’ value equals workstation1, workstation2 and so on. Indexes introduce their own paging mechanism and are handled by the database.

This diagram below shall further clarify:

Clustered indexing introduces intermediate pages on which direct pointers are assigned the pages where the actual data exists. For example, we make a simple 2 level paging with no intermediate level. See Fig. 1 below:

Level 1: Pointer pages
Level 2: Data pages

All the similar ‘fromhost’ values are grouped together on minimum pages so that access time is considerably reduced. The indexes now know where and on which page to locate the ‘fromhost’ value exactly. It would not have to traverse the whole table.

Note:

‘fromhost’ is the name of the column in our database table ‘SystemEvents’.

Automatically archiving logfiles written by MonitorWare Agent

Article created by Andre Lorbach.
Last Updated by Pascal Withopf.

This article was written by using the MonitorWare Agent, but it can also be applied to EventReporter and WinSyslog.

By default the log files generated by MonitorWare Agent using the WriteFile Action are written on a daily basis, so you have one log file for each day. Over time this can become a huge number uncompressed log files, so you properly want to archive them automatically to save disk space. There is no inbuilt method in MonitorWare Agent yet to do so, but this article will describe how you can archive this goal by using the Windows Task Scheduler and WinRar.

1 Installing and Configuring MonitorWare Agent

1.1 Download and Install MonitorWare Agent

So if you haven’t done so already, go to www.mwagent.com and download the latest MonitorWare Agent version. It is always recommended to use the latest Version of MonitorWare Agent. Once the download is done, go ahead and install it. You may have to restart after installation, this depends on your system.

1.2 Setup basic MonitorWare Agent Configuration

Start the MonitorWare Agent client and skip the wizard on startup. In this article, we will use an EventLog Monitor as source for our File logging, but you can use any other kind of source. Create a new “EventLog Monitor” service and just name it “EventLog Monitor”. You can leave all configuration settings as they are in the screenshot on the right.

1.3 Configure the Write File Action

In order to create log files we need a Write File Action. Create a new Write File Action like in the screenshot on the right. The default settings will create daily log files automatically. You may customize the log format by using the custom “File format” option. It is important to have the “Create unique filenames” Option enabled, this will enable the daily written log files.

The log file name for 2018-09-06 would be MonitorWare-2018-09-06.log, and for the next day MonitorWare-2018-09-07.log and so on.

1.4 Start MonitorWare Agent

After you configured MonitorWare Agent, you can start the Service and verify that the daily log files are successfully written.

2 Configure log file archiving

2.1 Download and Install WinRar

Visit the RarSoft website to download the latest Version of WinRar, if you haven’t installed it already. There are plenty of other packer applications out there and this article may also be used with them. However I will focus on using WinRar.

Once you downloaded WinRar, start it’s installation, and remember the exact path it was installed to. Usually this is “C:\Program Files\WinRAR” or “C:\Program Files (x86)\WinRAR”.

2.2 Create a VBScript which utilizes WinRar to create the archives

This script will actually do the work for you. It is designed to automatically generate the filename of the log file from yesterday, and create an archive with the same name. If the archive is successfully created, the log file will automatically be deleted. The script is also in the script package which you can download at the top. You can also copy the script content from the textbox below, and create a new file archive_logs.vbs yourself.

By default the script will create zip files, if you rather want to create rar files, just remove the -afzip parameter from the variable szCommand at the end of the script.

The next thing to do is to edit this script to your needs. There are 4 parameters at the top which you may need to customize, so the script fits into your environment.

szWinRardirectory – contains the full installation of your WinRar installation
szBasedirectory – Same as the Basedirectory parameter as in your WriteFile action
szBaseName – Same as the BaseName parameter in your WriteFile action.
szExtension – Same as the Extension parameter in your WriteFile action.

Once you have done this, you should run the script at least once manually by double clicking it to see if it works. You may only notice a short popup of the WinRar Windows, depending if a log file to archive can be found, and archiving takes some time. If it works, you should see a zip-packed log file in your logs directory, like in this screenshot.

2.3 Create Task in Windows Task Scheduler

Open the Control Panel, and go to the scheduled tasks. From there you can create a new scheduled task by clicking on “Create Task”. Once the window is open, click on the “Actions” tab and create a new action, where you can select your VBScript.

Configure the rest of the options the way you need them to be. For example the task should be executed daily, so that you can archive the logs of all days.

Final Thoughts

I hope this article will help you solving your tasks and shows you the potential of MonitorWare Agent, and what you can archive with it. Feel free to email me for recommendations or questions.

How to audit File / Directory delete Operations on a Windows System using security auditing.

Article created by Andre Lorbach.
Last updated by Pascal Withopf.

This article will guide you in how to setup Windows and MonitorWare Agent to track file and directory deletion processes. It is also possible to use EventReporter instead of MonitorWare Agent, however this article will target the more powerful MonitorWare Agent. The guide works both on Workstation and Server versions of Windows.

  • You can download a preconfigured configuration from here, which you can import on your target system. The configuration sample will have comments for better understanding. The MonitorWare Agent Client can import the XML/REG configuration file by using the “Computer Menu”.

A typical scenario of a small to middle sized company. The employees access a file server and store their documents on it. Suddenly an important document is missing. Who deleted it? And more important when was the file deleted? Oh two months ago? To bad our backups don’t go that far, the document is gone forever … ! Wouldn’t it be great to know if a file is deleted, when it was deleted and also who did delete the file? Maybe it was the revenge of an employee who got fired a few weeks ago?

Using Windows Security Auditing and the EventLog Monitor of MonitorWare Agent, you can set up an environment where you exactly know if a file is deleted, when it is deleted and by whom it is deleted.

1 Windows Settings

1.1 Turn on Security Auditing

Our first step is to enable “Audit Object access” in the Audit Policy. If your machine is a Workstation like Windows, open the “Local Security Policy” from the search bar. If you want to enable security auditing for the whole domain, or only domain controllers, open the “Domain Security Policy” or “Domain Controller Security Policy” from the “Administrative Tools”. In this article, we will use the “Local Security Settings” on a Windows machine.

Enable the “Audit object access” policy here. This will also enable object logging we do not need, but the filters in MonitorWare Agent will deal with these events later.

1.2 Add Auditing to the folders/drives you want to monitor

Now we can configure the Security properties for the drives or directories we want to monitor for file / directory deletions. In order to do so, right click the object you want to monitor and click on properties. In our sample, we will use the whole drive C:\. Once you switched to the security tab, click on the “advanced” button.

This will open advanced configuration options, switch to the “Auditing” tab and click on the “Add” button. Select “Successful” for the “Delete” and “Delete Subfolder and Files“, and also for “Failed” if you want to monitor failed deletion attempts as well. Once you have done this and confirm your changes by clicking on “Apply“, it may take a while until the system begins to record audit records. Good time to get a cup of coffee.

If you want to monitor other file operations, go ahead and activate them. However you will need to enhance the filter rules for MonitorWare Agent later by yourself.

1.3 Configure Windows Security Event Log Size

The System defaults are different from Windows to Windows Version. We need to make sure that event logging is continuous, otherwise the event log will fill up at some time, and no events can be written into it anymore. In our example, we will use 16MB of Maximum log size (Can be up to 256MB) and “Overwrite events as needed“.

1.4 Testing File Deletion

For this sample, we created a folder called “sharing” on the drive C:\ and shared it as a network folder. Then we added a file called document.doc into this folder, and deleted it. All done over the network share.

Then we open the Computer Management Console, and take a look into the Windows Security EventLog. You will see that a bunch of events is being generated for each file we delete. We will filter this event by certain parameters later using MonitorWare Agent. This event contains all information’s we need to determine which file was deleted, when it was deleted and by whom.

2 Configuring MonitorWare Agent

2.1 Download and install MonitorWare Agent

So if you haven’t done so already, go to www.mwagent.com and download the latest MonitorWare Agent Version. It is always recommended to use the latest Version of MonitorWare Agent. Once the Download is done, go ahead and install it. You may have to restart after installation, this depends on your System.

2.2 Setup Basics in MonitorWare Agent

Start the MonitorWare Agent Client and skip the wizard on startup. First we create new “Event Log Monitor” Service. Uncheck all event log types and only select “Security“, as this is the only event log needed to achieve our goal. Then save the settings.

Now we need to create some basic rules and filter to preprocess the event log entries. The first rule we create is called “DiscardProcessing” and will discard events if certain filters match. We only want to process Events with ID 560. Then there is the Param14 property which will contain “Accesses” masks from the event entry. The event log message will show DELETE, Read_Control and so on, but the parameters actually are RAW which means we have to deal with numbers.

Here is the list for the most common access mask numbers and their meaning:
1537 = Delete
1538 = Read_CONTROL
1541 = synchronize
4416 = ReadData(or List Directory)
4417 = WriteData(or Add File)
4418 = AppendData (or AddSubdirectory or CreatePipeInstance)
4419 = ReadEA
4420 = WriteEA
4423 = ReadAttributes
4424 = WriteAttributes

While examining the event log I noticed that there are multiple Events generated with ID 560 for each file deletion. The first is also generated if you rename a file and contains the mask “SYNCHRONIZE”. We do not want to process these events, so we add a filter to avoid these. The third filter we add will contain the Access Mask we want to process, in our example here this will be “%%1537” which is DELETE.

Do not forget to add a “Discard” action into this rule.

A few more rules are needed in order to post process the username and domain of the user who deleted the file. If a user deletes a file on the local system, Param8 and Param9 will hold the username and domain which we need to log. If a user deletes a file on a remote system, Param11 and Param12 is important to us.

So the first rule and its actions will initialize the properties del_username and del_domain with Param8 and Param9. Please import the configuration sample to see the actions in detail.

The other two rules will be used to check if Param11 and Param 12 are empty, so not set with a useful value. If they contain any useful information, we will overwrite the del_username / del_domain property with these Params. Using this method, we can be sure to always know exactly who deleted the file.

2.3 Using File Logging to store File Deletion

The most common way to store logged operations like this is to use write a logfile. So lets create a new “Write to file” Action. Set a file path and base name of your choice, and switch the file format to “Custom”. As you can see, you can now define your own line format. In our example, I have chosen a rather simple file format, where the values are separated by comma. So you might load them into Excel later, or another other application which can load csv files.

Use the following custom line format:

So you will see the time the file was deleted, the deleted file (which is %Param2%) and  the username and domain name. Feel free to customize the line format to your needs.

2.4 Create an Email alert

You might want to be alerted by email. But be warned, I recommend to reduce the folders and location you monitor for file deletions. Otherwise you will receive many unwanted emails. It is also possible to add custom filters to avoid emails for certain paths and filenames. Kindly filter the %Param2% property in this case.

In order to receive email alerts, create a new rule and add a new “Forward via Email” action.

Use the following subject format:

Use the following message format:

Final Thoughts

I hope this article will help you solving your tasks or shows you the potential of MonitorWare Agent, and what you can archive with it. Feel free to email me for recommendations or questions. Of course, the outlined actions are only samples and you may do other things with them, for example store log records to a database table instead of storing them to file.

On the recycle bin: if a local file is deleted via Windows explorer, it is by default moved to the recycle bin and not actually deleted. However, the above mentioned events are still generated. This may be especially useful if you monitor e.g. a very important file via an email alert. There may be chances to undelete it even from the recycle bin.

Monitor a SNMP Device using MonitorWare Agent

Article created by Andre Lorbach.
Last updated by Pascal Withopf.

This article will help you to monitor SNMP capable devices using the new SNMP Monitor Service of MonitorWare Agent. There are many devices out there which support SNMP, and can also be queried for information’s using SNMP GET. We will use SNMP GET to monitor a device, if we get a respond, the device is most likely running. If we do not get a response, the device may be offline or is powered off. We will use the Send Email Action to generate Alert Emails in case of that a monitored device is not responding anymore.

  • You can download a preconfigured configuration from here, which you can import on your target system. The configuration sample will have comments for better understanding. The MonitorWare Agent Client can import the XML/REG configuration file by using the “Computer Menu”.

As I said earlier there are many devices out there which do support SNMP like printers, routers, managed switches, linux / windows server and so on. In this article I will show you how to setup the SNMP Monitor Service to monitor a HP LaserJet 4000 laser printer.

1 SNMP Device (Printer) Setup

1.1 Configuring the Printer

As far as I know this printer does not need any special setting to have SNMP support enabled. So by default SNMP is enabled, and it is possible to overwrite the used snmp community name. However for this article I will not modify this setting.

The only thing we will need for this device is it’s IP Address which is 172.16.0.15.

Configuring MonitorWare Agent

2.1 Download and Install MonitorWare Agent

So if you haven’t done so already, go to www.mwagent.com and download the latest MonitorWare Agent Version. It is always recommended to use the latest Version of MonitorWare Agent. Once the Download is done, go ahead and install it. You may have to restart after installation, this depends on your System.

2.2 Setup Basics in MonitorWare Agent

Start the MonitorWare Agent Client and skip the wizard on startup. First we create new “SNMP Monitor” Service by right clicking the Configured Services node and going to the Add Service menu.

Insert the IP of the device you want to monitor in the remote host field. You can leave the default values for the other configuration options, they will work fine for most devices.

The Query OID I use in this sample will query the system name of the device. However there are several other variables you pick for monitoring such as:

  • .1.3.6.1.2.1.1.6 (i.o.d.i.mgmt.mib-2.system.sysLocation)
  • .1.3.6.1.2.1.1.5 (i.o.d.i.mgmt.mib-2.system.sysName)
  • .1.3.6.1.2.1.1.4 (i.o.d.i.mgmt.mib-2.system.sysContact)
  • .1.3.6.1.2.1.1.3 (i.o.d.i.mgmt.mib-2.system.sysUpTime)
  • .1.3.6.1.2.1.1.2 (i.o.d.i.mgmt.mib-2.system.sysObjectID)
  • .1.3.6.1.2.1.1.1 (i.o.d.i.mgmt.mib-2.system.sysDescr)

Other OID’s might also be available, it depends on device you are monitoring. There is also a Instance subidentifier option available. I recommend to leave this value to 0, it is only useful if you want to query a OID which contains multiple data.

2.3 Create a Forwarding Rule for the InterActive SyslogViewer (Optional!)

This is an optional step, only useful for testing and debugging the SNMP Monitor. You can disable the Action of this rule later if you want. As we are using the UDP protocol to forward syslog messages locally, it doesn’t really matter.

So first of all create a new Rule called “FwSyslog” and add a new Forward Syslog Action. The Syslog Server is 127.0.0.1 and the syslog port is 10514. See the screenshot for more details.

2.4 Create an Email alert

The best option to get alerted is by email. So we create another rule called EmailAlert and add a Forward Email Action. Please fill Sender, Recipient and Mailserver configuration yourself.

Use the following text as mail subject:

Use the following text as message format:

2.5 Configure Filters for the Email Alert

We were not finished yet ;). We need to configure some filters, otherwise you would get one Email for each SNMP Monitor check, even if successfully.

So add a new Custom Property filter, with the property name “%snmp_status%”. Use the compare operation “not equal” and Property Valur of “0”. So this means the Actions in this rule will be fired whenever the status is not 0, and every status which is not 0 means there was an error.

To avoid email flooding, set the Minimum WaitTime to 600 seconds. This means it doesn’t matter how failures are generated, in 10 minutes there will only be one email alert.

Final Thoughts

I hope this article will help you solving your tasks or shows you the potential of MonitorWare Agent, and what you can archive with it. Feel free to email me for recommendations or questions. Of course, the outlined actions are only samples and you may do other things with them, for example store log records to a database table instead of storing them to file.

How to send EventLog entries as SNMP Traps with MonitorWare Agent.

Article created by Andre Lorbach.
Last updated by Pascal Withopf.

This article will guide you to use MonitorWare Agent to generate SNMP Traps from EventLog entries and send them to your SNMP management software. This article also requires at least MonitorWare Agent 5.2 or higher, and the custom ADISCON mibs which are included since MonitorWare Agent 5.2.

  • You can download a preconfigured configuration from here, which you can import on your target system. The configuration sample will have comments for better understanding. The MonitorWare Agent Client can import the XML/REG configuration file by using the “Computer Menu”.
  • To obtain the most recent custom ADISCON mib files, download these two files und put them into your mibs directory of your MonitorWare Agent installation.
    ADISCON-MIB.txt
    ADISCON-MONITORWARE-MIB.txt

1 Configuring MonitorWare Agent

1.1 Download and Install MonitorWare Agent

So if you haven’t done so already, go to www.mwagent.com and download the latest MonitorWare Agent Version. It is always recommended to use the latest Version of MonitorWare Agent. Once the Download is done, go ahead and install it. You may have to restart after installation, this depends on your System.

1.2 Setup an EventLog Monitor in MonitorWare Agent

Start the MonitorWare Agent Client and skip the wizard on startup.

Then add a new EventLog Monitor called “Main EventLog Monitor”. I have set the Sleep time to 5 seconds, for testing purposes. But you can also set this value to 5 seconds in production, it won’t have much impact on the Servers performance.

You also might unselect EventLog Types you do not want to monitor, for this article I will allow all EventLog Types.

2. Configuring the SNMP Trap

2.1 Create SNMP Trap Action

Now add a new Rule under your Default RuleSet called SendTrap. Then add a Send SNMPTrap Action. The default values will already generate a generic “monitorwaretrap”, which is fine for most cases. But we are going to configure our own trap properties.

So you have noticed that the Trap OID and the variable OID’s are represented numeric. Once you click on the Browser Button, the Client will automatically load and display the installed mibs. You can configure the Configuration Client to automatically load the mibs during each startup in the Client Options.

So as you can see you have a few trap OID’s available, in this article we will use the eventmontrap OID which is “.1.3.6.1.4.1.19406.1.2.3”, or in human readable form “ADISCON-MONITORWARE-MIB::eventmontrap”. You can actually define the one or the other form as OID, both will work but the textual representation only if you have the ADISCON Mibs installed. The the numeric representation is always the saver way to configure the OID’s.

Now what you don’t see in the mib browser is the list of variables which are connected with the SNMP Trap. For the eventmontrap, we need a few snmp variables:

genMsg,
genSource,
eventlogEventID,
eventlogEventType,
eventlogEventSource,
eventlogEventSeverity,
eventlogEventCategoryID,
eventlogEventCategoryName,
eventlogEventUser

Start removing the default configured variable, and add our own ones (as in the list above). Add one variable, and use the Mib Browser to select the suitable OID’s and also the correct variable values (See the screenshot for more).

2.2 Filtering for EventLog severity (Optional)

With our current setup, you would send one SNMP Trap for each incoming Syslog messages. But you may not want this, so you can optionally add some filters to reduce the number of outgoing SNMP Traps.

For example you can add a Syslog Severity (Priority) filter, so that only EventLog entries with error messages will be send as trap to your SNMP Manager.

2.3 Start sending SNMP Trap

Now you are ready to start the MonitorWare Agent, note that you properly will get a lot of SNMP Events during the first run.

To show you how the result looks like, here is the output of snmptrapd on a linux machine. There are many SNMP Manager utilities out there, you can even receive SNMP Traps with MonitorWare Agent itself if you like.

2008-03-07 15:18:31 172.16.0.122 [UDP: [172.16.0.122]:1119]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (742090390) 85 days, 21:21:43.90 SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::enterprises.19406.1.2.1 SNMPv2-SMI::enterprises.19406.1.1.2.1 = STRING: “MWAgent: This is a Test no. 1” SNMPv2-SMI::enterprises.19406.1.1.2.2 = INTEGER: 3 SNMPv2-SMI::enterprises.19406.1.1.2.3 = INTEGER: 16

When you receive the trap with MonitorWare Agent, the message output will look like this:

MonitorWare: source=”172.16.0.122″ community=”public” version=”Ver2″ variables: snmp_var_1 = ‘DISMAN-EVENT-MIB::sysUpTimeInstance: ‘Timeticks: (741870389) 85 days, 20:45:03.89” , snmp_var_2 = ‘SNMPv2-MIB::snmpTrapOID.0: ‘OID: ADISCON-MONITORWARE-MIB::syslogtrap” , snmp_var_3 = ‘ADISCON-MONITORWARE-MIB::syslogMsg: ‘STRING: “MWAgent: This is a Test Error MEssage no. 1″” , snmp_var_4 = ‘ADISCON-MONITORWARE-MIB::syslogSeverity: ‘INTEGER: error(3)” , snmp_var_5 = ‘ADISCON-MONITORWARE-MIB::syslogFacility: ‘INTEGER: local0(16)”

As you can see eventlogEventCategoryID and eventlogEventCategoryName are missing. Most EventLog entries do not have a Event Category assigned, so these variables are not added into the SNMP Trap.

Final Thoughts

I hope this article will help you solving your tasks or shows you the potential of MonitorWare Agent, and what you can archive with it. Feel free to email me for recommendations or questions. Of course, the outlined actions are only samples and you may do other things with them.

How to send generic SNMP Traps with MonitorWare Agent.

Article created by Andre Lorbach.
Last updated by Pascal Withopf.

This article will guide you to use MonitorWare Agent to generate generic SNMP Traps and send them to your SNMP management software. It is also possible to use WinSyslog instead of MonitorWare Agent in some cases, however this article will target the more powerful MonitorWare Agent. This article also requires at least MonitorWare Agent 5.2 or higher, and the custom ADISCON mibs which are included since MonitorWare Agent 5.2.

  • You can download a preconfigured configuration from here, which you can import on your target system. The configuration sample will have comments for better understanding. The MonitorWare Agent Client can import the XML/REG configuration file by using the “Computer Menu”.
  • To obtain the most recent custom ADISCON mib files, download these two files und put them into your mibs directory of your MonitorWare Agent installation.
    ADISCON-MIB.txt
    ADISCON-MONITORWARE-MIB.txt

As you know MonitorWare Agent has many different input sources (services) from which we can generate useful traps. In this article, I will show you how to generate a SNMP Trap from a received  Syslog message, so we are going to use the Syslog Service.

1 Configuring MonitorWare Agent

1.1 Download and Install MonitorWare Agent

So if you haven’t done so already, go to www.mwagent.com and download the latest MonitorWare Agent Version. It is always recommended to use the latest Version of MonitorWare Agent. Once the Download is done, go ahead and install it. You may have to restart after installation, this depends on your System.

1.2 Setup a Syslog Server in MonitorWare Agent

Start the MonitorWare Agent Client and skip the wizard on startup.

Then add a new Syslog Service called “Main Syslog Server”. We use default values here, Port 514 UDP. Leave the other Options as they are.

2 Configuring the SNMP Trap

2.1 Create SNMP Trap Action

First add a new Rule under your Default RuleSet called SendTrap. Then add a Send SNMPTrap Action. The default values will already generate a generic “monitorwaretrap”, which is fine for most cases. But we are going to configure our own trap properties.

So you have noticed that the Trap OID and the variable OID’s are represented numeric. Once you click on the Browser Button, the Client will automatically load and display the installed mibs. You can configure the Configuration Client to automatically load the mibs during each startup in the Client Options.

So as you can see you have a few trap OID’s available, in this article we will use the syslogtrap OID which is “.1.3.6.1.4.1.19406.1.2.1”, or in human readable form “ADISCON-MONITORWARE-MIB::syslogtrap”. You can actually define the one or the other form as OID, both will work but the textual representation only if you have the ADISCON Mibs installed.

Now what you don’t see in the mib browser is the list of variables which are connected with the SNMP Trap. For the syslogtrap, we need syslogMsg, syslogSeverity and syslogFacility.

So we are going to remove the default configured variable, and add our own ones, for the message, syslog severity and syslog facility. Kindly add 3 new variables, you use the Mib Browser to select the suitable OID’s and also the correct variable values (See the screenshot for more).

2.2 Filtering Syslog messages (Optional)

With our current setup, you would send one SNMP Trap for each incoming Syslog messages. But you may not want this, so you can optionally add some filters to reduce the number of outgoing SNMP Traps.

For example you can add a Syslog Severity (Priority) filter, so that only syslog error messages will be send as trap to your SNMP Manager.

2.3 Sending a test SNMP Trap

The easiest way to create a SNMP Trap for testing now is use the “Send Syslog Test Message” from the Configuration Client tools menu. If you configured filters, don’t forget to set the correct syslog facility and priority.

To show you how the result looks like, here is the output of snmptrapd on a linux machine. There are many SNMP Manager utilities out there, you can even receive SNMP Traps with MonitorWare Agent itself if you like.

2008-03-07 15:18:31 172.16.0.122 [UDP: [172.16.0.122]:1119]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (742090390) 85 days, 21:21:43.90 SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::enterprises.19406.1.2.1 SNMPv2-SMI::enterprises.19406.1.1.2.1 = STRING: “MWAgent: This is a Test no. 1″ SNMPv2-SMI::enterprises.19406.1.1.2.2 = INTEGER: 3 SNMPv2-SMI::enterprises.19406.1.1.2.3 = INTEGER: 16

When you receive the trap with MonitorWare Agent, the message output will look like this:

MonitorWare: source=”172.16.0.122″ community=”public” version=”Ver2″ variables: snmp_var_1 = ‘DISMAN-EVENT-MIB::sysUpTimeInstance: ‘Timeticks: (741870389) 85 days, 20:45:03.89” , snmp_var_2 = ‘SNMPv2-MIB::snmpTrapOID.0: ‘OID: ADISCON-MONITORWARE-MIB::syslogtrap” , snmp_var_3 = ‘ADISCON-MONITORWARE-MIB::syslogMsg: ‘STRING: “MWAgent: This is a Test Error MEssage no. 1″” , snmp_var_4 = ‘ADISCON-MONITORWARE-MIB::syslogSeverity: ‘INTEGER: error(3)” , snmp_var_5 = ‘ADISCON-MONITORWARE-MIB::syslogFacility: ‘INTEGER: local0(16)”

Final Thoughts

I hope this article will help you solving your tasks or shows you the potential of MonitorWare Agent, and what you can archive with it. Feel free to email me for recommendations or questions. Of course, the outlined actions are only samples and you may do other things with them.

How to monitor and forward message tracking logfiles from Microsoft Exchange Server using MonitorWare Agent.

Article created 2008-05-09 by Andre Lorbach.
Last updated by Pascal Withopf.

This article will guide you in how to monitor and forward message tracking logfiles from Microsoft Exchange Server using syslog over tcp. As receiver you have the choice of using different applications like WinSyslog, MonitorWare Agent or even open source projects like rsyslog.

  • You can download a preconfigured configuration from here, which you can import on your target system. The configuration sample will have comments for better understanding. The MonitorWare Agent client can import the XML/REG configuration file by using the “Computer Menu”.

If message tracking is enabled in Exchange Server, the logfiles are created daily by default and contain informations about each message which is routed through the Exchange server. Depending on the workload of your server, you may need to delete the logfiles from time to time to save harddisk space. But you need a backup of these logfiles in case you need to review them. This is where MonitorWare Agent comes into play. The File Monitor of MonitorWare Agent can be easily used to forward the message tracking logfiles to a syslog repository.

1 Exchange Server preparations

1.1 Enabling Message tracking logging in Exchange Server

If already enabled, you can skip this step.

To enable message tracking logging, kindly check the “Enable message tracking” option.

Optionally you can select “Remove log files” option and define how old the logfiles have to be in order to get deleted. You may also change the log file directory, may be to another hard disk, in order to save the space on the main hard disk.

If enabled, Exchange Server creates one message tracking logfile per day. As you can see in the date modified column, Exchange Server is using UTC and not localtitme to create the logfiles. My testmachine is running with European central time which is GMT+1 and GMT+2 daylight saving time (which is currently set).

2 Installing and Configuring MonitorWare Agent

2.1 Download and Install MonitorWare Agent

So if you haven’t done so already, go to www.mwagent.com and download the latest MonitorWare Agent version. It is always recommended to use the latest Version of MonitorWare Agent. Once the download is done, go ahead and install it. You may have to restart after installation, this depends on your system.

2.2 Setup basic MonitorWare Agent configuration

Start the MonitorWare Agent client and skip the wizard on startup. First we create new “File Monitor” service and name it “Exchange File Monitor”.

Then use the browse button to select the directory which contains the message tracking logfiles. Kindly select one of the logfiles and replace its name with this string: %Y%m%d.log

This will automatically match the logfiles each day, %Y will match the year, %m the month and %d the current day.

It is also important to select UTC as Timemode for the filename, as I already mentioned in step 1.1, the Exchange server used UTC (GMT) to create the logfiles.

Now click on the Advanced Options, and the following dialog will appear. In this dialog, enable the option “Ignore empty lines”. The message tracking logfiles sometimes contain empty lines between the logfiles, so this option will remove them automatically.

2.3 Configure the Forward Syslog Action

The last step is to configure the forward syslog action, first create a new Rule and name it ForwardSyslog. Then create a new Forward Syslog Action and call it Repository for example. You also see a InterActive Action in the sample screenshot here, this is a helper action which forwards to the local InterActive Syslogviewer, which is also installed with MonitorWare Agent by default.

As I wrote in the beginning of this article, there are several syslog products available which can be used as receiver. On Windows, we recommend to use WinSyslog or MonitorWare Agent. On Unix based systems, we recommend to use rsyslog, which is open source of course ;)! Rsyslog is available on many plattforms and integrated in many package systems.

All these syslog products are able to receive syslog message over tcp and also in a persistent connection.

Final Thoughts

I hope this article will help you solving your tasks and shows you the potential of MonitorWare Agent, and what you can archive with it. Feel free to email me for recommendations or questions.