Install phpLogCon with IIS6.0

Article created 2008-10-14 by Tom Bergfeld.

In this paper, I describe how to install phpLogCon with IIS6.0. It is intentionally a brief step-by-step guide, targeted to those who want to quickly get it up and running. For more elaborate information about phpLogCon, please consult the phpLogCon manual set.

Installing IIS

If you don’t use IIS so far, you have to install it now. You just need your Windows-Installation-CD. Go to “Add or Remove Programs” in your Control Panel. There you will find IIS by clicking “Add or Remove Windows Components” (in some cases like Windows Server 2003 IIS is in “Application Server”).
Choose it and follow the install instructions.

To check if the install was correct open your browser and type “localhost” in your navigation bar. You should see the following screen (it’s the default startscreen of the IIS).

Downloading PHP-installer

Here you will find the PHP installer. Download it and follow the instructions of the installer. A simple test should show if the install was correct. Create a simple test.php-file in your webbrowser folder (default IIS folder c:\Inetpub\wwwroot) and try to open it via your browser. I created a simple test.php for you, that you can use to test your PHP by clicking here or download it.

Downloading phpLogCon

For obvious reasons, you need to download phpLogCon.
Load the most recent build from here.

Installing phpLogCon

Perhaps you will need to download and install third party software like WinRAR to unpack the downloaded phpLogCon tar.gz file.

Open the windows explorer and go to the Inetpub\wwwroot folder of your IIS web server, which is the folder where you can place html/php files. Create a new folder called phplogcon there.

If you downloaded and unpacked phpLogCon, copy or move the content of the src folder into the C:\Inetpub\wwwroot\phplogcon folder.

The explorer window should be like in the screenshot now.

Before you can start the real install you have to set write permissions in the settings of the IIS like in the screenshot. Right click on the wwwroot folder -> properties -> security

Now open your phplogcon installation in your favourite webbrowser (localhost/phplogcon), you will see an error, and you will be pointed to the installation script. The install script will guide you through the phplogcon installation, just follow the instructions.

In the first step phpLogCon creates the config.php file in your created phplogcon folder and checks the permissions, if the config.php can be written or not.

In the next steps you can set several basic options.

Number of syslog messages per page = 50 (default)
This is the number of syslog messages displayed on each page. You can increase the value (makes phpLogCon slower) or decrease the value (makes it faster).

Message character limit for the main view = 80 (default)
Set the number of characters per message which will be shown in the last column of the main view. Full messages can be reviewed by hovering the mouse over it.

Show message details popup (default yes) = yes (default)
Here you can set, if you want the small window with the complete message to pop up if you are hovering over a event with the cursor. If you choose “No”, then you have to click on the message to see the details.

Create the first source for syslog messages.
Step 7 is the most important. Here, you will configure your first data source, which holds all your syslog data. Mainly, you have to choose a “Name of the Source” and a “Source Type”. The name will be displayed later in a drop-down menu with which you choose your active syslog source. The “Source Type” can be a file, a MySQL database or the PHP PDO which supports different database types like mssql, PostgreSQL, odbc, oracle or even ibm db2.

If you choose the diskfile,like in our case, you have to provide the following information:
Logline Type = Syslog / Rsyslog (default) or Adiscon WinSyslog
This tells phpLogCon, how the lines look like. This is necessary for showing the log messages properly.

Syslog File = /var/log/syslog (default)
This is the position of the logfile in your file system.
The only thing we have to change is the Syslog File into the folder of your choice. I created a file called Webserver.log in the folder c:\Logs, therefore my screen looks like this.

You are done!

In the next step you finish your install. The last thing you have to do is to delete or rename your install.php in your
c:\Inetpub\wwwroot\phplogcon folder to avoid a reinstall everytime you start your phpLogCon.

How to perform a mass update rollout?

Created 2008-10-10 by Florian Riedl

A mass rollout in the scope of this topic is any case where the product is rolled out to more than 5 to 10 machines and this rollout is to be automated. This is described in detail in the Article How to perform a mass rollout?. We now want to take a look at the procedure that needs to be done after you have done a mass rollout before and now want to update MonitorWare Agent to the current version.

Automated Rollout

The basic idea behind a mass rollout is to create the intended configuration on a master (or baseline) system. This system holds the complete configuration that is later to be applied to all other systems. Once that system is fully configured, the configuration will be transferred to all others. For this case, it means you have to update this system first, alter the configuration there if necessary and then export it.

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

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

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

net stop "AdisconMonitoreWareAgent"

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

The file “update.reg” would be the registry file that had been exported with the configuration client. Copying this file is optional, but recommended. In this configuration file, the new license key could be included as well as configuration changes.

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

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

Please note that, in the example above, “c:\some-local-dir” actually is the directory where the product is being installed. The commands “net stop” and “net start” do first STOP the service before copying the new files and then START it again after everything is finished.

Store IIS Logfiles into a Database

Created 2008-10-06 by Florian Riedl

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

Step 1

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

Step 2

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

Figure 1: Configuring the Filemonitor

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

Step 3

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

Step 3.1

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

Step 3.2

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

Figure 3: Change Service Properties

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

Step 4

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

Step 4.1

Figure 4: Select Application

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

Step 4.2

Figure 5: Select Name and Interval

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

Step 4.3

Figure 6: Detailed Startup Setup

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

Step 4.4

Figure 7: Account details

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

Step 4.5

Figure 8: Finish the Configuration Wizard

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

Step 4.6

Figure 9: Detail Configuration

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

Step 5

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

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

Step 5.1

Figure 10: Select Name and Interval

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

Step 5.2

Figure 11: Detail Configuration

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

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

How to setup File logging in MonitorWare Agent to consolidate Webserver logs and view them in phpLogCon

How to setup File logging in MonitorWare Agent to consolidate Webserver logs and view them in phpLogCon.

Article created 2008-10-05 by Andre Lorbach.

This article will help you to setup an environment where you can store weblogs from your webserver at a central place using MonitorWare Agent, and view and search them using phpLogCon.

You can download a preconfigured configuration from this link and import that into your own system. The configuration sample contains comments for better understanding. MonitorWare Agent Client can import the XML/REG configuration file via the “Computer Menu”.

1. Requirements
1.1 About the requirements
1.2 Installing and configuring WAMP
1.3 Installing MYSQL ODBC Connector
2. Installing and configuring MonitorWare Agent
2.1 Download and Install MonitorWare Agent
2.2 Setup Processing RuleSet
2.2.1 Setup Database Logging
2.2.2 Create the Database Action in MonitorWare Agent
2.3.1 Setup File Logging
2.4 Add File Monitor Service(s)
2.5 Starting MonitorWare Agent and verifying the configuration
3. Install and Setup phpLogCon
3.1 Download and copy phpLogCon to the right location
3.2 Install and configure phpLogCon
Final Thoughts

1. Requirements

1.1 About the requirements

If you already have a web server with PHP support and MYSQL Server running, you can skip step 1.1 and 1.2.

This can be done with Internet Information Server, but this article focuses on using Apache to do the job. There is another article underway which describes IIS.

So in order to setup phpLogCon later, you will need a web server with PHP support and a MYSQL Server with an administration interface. For these tasks, we recommend the following open source applications:

Apache Webserver
PHP
MYSQL (optionally)
phpMyAdmin (optionally)

You can install and configure all these applications separately, but it is much easier to get WAMP for Windows. WAMP means Apache, MYSQL, PHP on Windows and combines all applications with a default configuration. This results in a system which can be used out of the box. So you do not need to worry about the Apache or MYSQL configuration, you just install WAMP first.

Download the latest WAMP Version from here:
http://www.en.wampserver.com/

1.2 Installing and configuring WAMP

After you downloaded WAMP, start the installation and follow the instructions.
Make sure you do not have a web server or MYSQL Server already installed because this could result in conflicts. Most often Microsoft ISS is already installed on the Windows platform. If so, there is no need to install WAMP, but you still need MySQL and php for IIS. This is described in another guide.

I will use the default installation location in this article which is C:\wamp.

Once the Installation is finished, a new Icon appears in Windows Icon tray. Click it, and choose “Localhost” from the menu to verify if the installation was performed successfully. If it was, you should see a web site looking like the one on the right.

To check if your MYSQL is running, click on the phpMyAdmin Menu button in the WAMP Menu, and login with the username “root” and no password – if you are asked for a login.

1.3 Installing MYSQL ODBC Connector

If you intend to store messages in MYSQL database, you need to install the MYSQL ODBC Connector. Otherwise you can skip this step.

MonitorWare Agent will need a MYSQL ODBC driver in a later step in order to write into the MYSQL database. These drivers have to be downloaded and installed separately from here:
http://dev.mysql.com/downloads/connector

If your Windows System is a x64 version, it is important to install the x64 Version of the MySQL Connector driver. As the WinSyslog Service runs as a 64bit application itself, it will need the connector to be 64bit as well.

2. Installing and configuring MonitorWare Agent

2.1 Download and Install MonitorWare Agent

So if you have not 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 has completed, go ahead and install it. Depending on your system, a system restart may be needed (but it usually is not)

2.2 Setup Processing RuleSet

Start MonitorWare Agent Client, and skip the First Startup Wizard.

Add a new RuleSet and call it “Store Logdata”.

2.2.1 Setup Database Logging

If you want to store messages inside MYSQL, follow this step.

Click on your WAMP Icon, and open the phpMyAdmin. Now Create a new database called “mwagent”.

Once done, select the newly created database, switch to the “SQL” tab and copy the SQL statements from the textbox below.

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

Now insert the copied commands into the SQL field. Then Click “GO”, you should see “Your SQL query has been executed successfully” after that as well as two new tables on the left list called systemevents and systemeventsproperties.

2.2.2 Create the Database Action in MonitorWare Agent

Get back to the MonitorWare Agent Client and create a new Rule in your self-created RuleSet called “Database”. Then add a new “Write to Database” Action, and name it “MYSQL ODBC”. After creating this action, you should automatically be taken to the actions properties.

Click on the “Data Sources (ODBC)” button to open the System ODBC Administrator. Click on the “System DSN” Tab and add a new Datasource, select “MySQL ODBC 5.1 Driver” as driver. It is important to add a System DSN rather then a User DSN, because User DSN’s are not usable by the MonitorWare Agent Service (this is a Windows design restriction).

Name the new datasource “mwagent” and use “localhost” as Server, “root” as username and no password. Then you are able to select the database which we created before called “mwagent”.

Check the database logging action again, it should look like the one in the screenshot.

2.3.1 Setup File Logging

If you want to consolidate your webserver logfiles in one large logfile, proceed with this step. Otherwise you can skip this step.

Create a new rule called “File Logging” and add a “Write to File” Action.
Select Custom Line Format, use the following (use copy&paste to enter it):%timegenerated:::localtime%,%timereported:::localtime%,%source%,%syslogfacility%,%syslogpriority%,%syslogtag%: %msg%%$CRLF%

2.4 Add File Monitor Service(s)

First of all find the exact location of the webserver logfiles you want to monitor. In this example, I use the access.log from my local wamp installation located at C:\wamp\logs.

Now add a file monitor service. Inside that service, configure the correct file and path name of the file to be monitored. If you would like to read multiple files, you can enable the property replacer inside the filename.

Be sure to specify the log file type to “W3C WebServer Logfile”. This is important so that the contents can properly be interpreted.

It may also be a good idea to set a syslog tag name that matches the filename (or the function of the file name, e.g. “online-shop”). By doing so, you can easily filter inside phpLogCon.

2.5 Starting MonitorWare Agent and verifying the configuration

From the MonitorWare Agent configuration point of view, everything is setup now. So kindly start the MonitorWare Agent Service and wait a few moments, so that the data can be processed.

If you are using file logging, you should see that the logs folder on C:\ has been created and contains a WebServer.log file. If not, something went wrong. In this case please check the Windows Application EventLog for possible error reports from MonitorWare Agent.

If you are logging into a database, switch back to phpMyAdmin and browse through the systemevents table. You should see at least one data record in this table now, like in the screenshot sample. If not, something went wrong, in this case please check the Windows Application Event Log for possible error reports from MonitorWare Agent.

3. Install and Setup phpLogCon

3.1 Download and copy phpLogCon to the right location

If you are using MonitorWare Agent 8.3 or higher, a proper version of phpLogCon can be found in the MonitorWare Agent installation folder. If you are using an older Version of MonitorWare Agent, I recommend to download the latest stable or beta build from here: http://www.phplogcon.org/downloads
In this article I will use phpLogCon Version 2.5.13.

To unpack the install set, you need a program capable of processing tar.gz files. Most ZIP programs support this. If you do not have one, you can find WinRAR by following the link (we have no affiliation with the makers of WinRAR, but have found it to be a useful tool – use at your own risk).

Open windows explorer and go to the www folder of your Apache web server, which is the folder where you can place html/php files. By default this will be “C:\wamp\www” if you have installed WAMP into the default installation folder. Create a new folder called phplogcon there.

If you downloaded and unpacked phpLogCon, and copy or move the content of the src folder into the C:\wamp\www\phplogcon folder. If you have MonitorWare 8.3 or higher, you can use and copy the contents of the phpLogCon folder of your MonitorWare installation.

The explorer window should look like in the screenshot now.

3.2 Install and configure phpLogCon

Open this link to start the phpLogCon installation: http://localhost/phplogcon/

If you do not see a page like in the screenshot, something went wrong in the steps before, please check them in this case.

Otherwise click on the text-link “here” on phpLogCon’s error page to start its installation routine.

Follow the installation steps of phpLogCon.

I recommend to “Enable User Database” in Step 3, as this will give you an advanced admin control panel. The User Database requires a MYSQL database to work, you can use the same one as you are using for MonitorWare Agent.

If you are using MYSQL to store log messages and you have reached Step 7, switch the source type to “MYSQL Native” and name the Source “WebLogStore DB” Use “mwagent” as Database Name and “root” as Database User. Leave the other configuration variables as they are, see the screenshot for how it should look like. Then click on the Next button to finish the installation.

After you finished the Installation of phpLogCon, you need to login and switch to the sources admin and configure the source “WebLogStore DB” there.

– In field “Message Parsers” add apache2 if you are using combined log format. Add apach2common if you are using common log format.

If you are using file logging and you have reached Strep 7, switch the source type to “Diskfile” and name the Source “WebLogStore FILE” Use “C:/logs/WebServer.log” as syslog file. Leave the other configuration variables as they are, see the screenshot for how it should look like. Then click on the Next button to finish the installation.

After you finished the Installation of phpLogCon, you need to login and switch to the sources admin and configure the source “WebLogStore FILE” there.

– In field “Message Parsers” add apache2 if you are using combined log format. Add apach2common if you are using common log format.

After clicking on the “Finish” link, you should see a working phpLogCon installation. If you do not see any data, there may be no data in your database yet. Otherwise you will see an error code and message from phpLogCon.

Final Thoughts

I hope this article will help you installing and configuring phpLogCon and MonitorWare Agent. If you have problems or question related to this article, don’t hesitate to contact me or our support by email.

Please note that while this setup works, it is not very secure. At a minimum, it is recommended to set proper passwords for the databases (instead of using a password-less root account). Please review the relevant documentation on how to do that.

Forwarding NetApp Event Log Entries via Syslog

Article created 2008-09-22 by Rainer Gerhards

NetApp devices provide diagnostic information via an Windows Event Log like interface. This enables their messages to be browsed by Windows Event viewer and and be automatically processed by tools like EventReporter and MonitorWare Agent.

It goes without saying that there are ample benefits from this capability. For example, instant alerting can be enabled by simply reading the NetApp event logs, checking for some conditions and alerting (for example via email) if something unusual is logged. Another big benefit is that by converting the NetApp Event Logs into syslog, they can be forwarded to a central loghost and thus easily be integrated into a centralized logging and alerting system.

There are two ways to access the NetApp logs. First of all, NetApp exposes them as files which obey the event log file format. These files are dynamically re-written and as such considered to be “live”. Adiscon products support this mode since long and are used with great success in that mode (there exists another article on how to do that).

Secondly, NetApp also provides an emulation of the Windows event log API. Under that emulation, a NetApp devices “looks and feels” just like another Windows machine offering its event log. Well … mostly. There are a couple of subtle differences, with the most important one being that the event log record number is not incremented on NetApp devices. This record number is associated with each event log record. Native Windows always increments this number (up to a very high max value, where it then wraps). The NetApp emulation does not use such a unique record number. Instead, the API always exposes a fixed number of most recent records, but always uses the same recrord number for them. So while the data is being rolled as new records come in, the record number stays the same. Thus, for example, if new data comes in, the data for record number 312 is moved to record number 311 and 312 receives the data from record 313. Under this implementation, event log record numbers do no longer identify a given event log entry.

Adiscon products are optimized for highest throughput and least demand on system ressources. One way to do that is to utilize the uniqueness of record numbers. This optimization leads to problems on NetApp. Namely, new records are never forwarded, because no new record numbers are seen (which leads EventReporter and MonitorWare Agent to beliefe there are no new records). The cure, however, is simple. First of all, checksum verification for the last processed event must be turned on in the configuration of the event log monitor in question. This ensure that an internal checksum is generated as a unique identifier for an event log record. Secondly, the event log monitor must be instructed to always search for new events based on that checksum. This will enable the monitor to properly detect new events. This configuration can be seen in the screenshot below:

Event Log Monitor settings for NetApp

Please note that while we turn off some optimizations with these settings, performance is still quite good. Most importantly, typical NetApp event logs are relatively small as the contain only a small subset of recent records. This makes reading through them quite painless. Secondly, we still apply a lot of other optimizations, especially when comparing to other tools which blindly try to re-do everything always. Users are still advised to use a sensible sleep value for the event log monitor (the default should be fine), as without the optimizations additional i/o overhead is unavoidable.

Should you have problems implementing this configuration, please contact support@adiscon.com for assistance. We are glad to help.

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

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

Article created 2008-05-09 by Andre Lorbach.

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
2. Installing and Configuring MonitorWare Agent
2.1 Download and Install MonitorWare Agent
2.2 Setup up basic MonitorWare Agent configuration
2.3 Configure the Foward Syslog Action.
Final Thoughts

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

Make sure that you use only “\n” as message separation sequence, as the typical Windows “\r\n” is not used in the message tracking logfiles.

2.3 Configure the Foward 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.

Database Formats

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

JET (MS Access) Sample
Microsoft SQL Server Sample
MySQL

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

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

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

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

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

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

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

2008-03-31 MonitorWare Agent 5.2 Final Released

MonitorWare Agent 5.2 Released

Grossrinderfeld, 2008-03-31

Adiscon is proud to announce the 5.2 release of MonitorWare Agent. This is a maintenance release including new features and bugfixes. The most important changes are:

InterActive SyslogViewer – We are introducing a new tool for Realtime Syslog viewing called “Interactive SyslogViewer”. This application is written in Microsoft .Net which means, the .Net Framework will also be installed with the setup.
New Service “SNMP Monitor” – This new Service can monitor SNMP Devices using the SNMP Get Method. There are many snmp capable devices out there which can be monitored with this new service.
SMTP SSL support for the Send Email Action – This means you can use a secured connection to SMTP Servers. Note that the common default port for SMTP over SSL is 465. If you enable SSL Support and use a normal SMTP Server, the email delivery will fail.
Queue Manager – This feature enables the Agent to cache items in its internal queue on disk using a fixed data file. Warning(!), this feature will slow down processing speed depending on your hard disk speed. This feature can give you an additional level of failover support.
File Monitor – Added full support for UTF Textfiles which means we now support UTF8, UTF16 and normal ASCII text files.
Filter Engine – A new Extended Property type for number based properties is available now, so you can filter for custom properties as numbers.
General SNMP Change – Updated all NET-SNMP MIBS which are shipped with MWAgent, and also introduced custom enterprise MIBS for Monitorware Agent. These Mibs will now be used by default in the SendSNMP Action, to generate useful traps.

For more details read the version history

Version 5.2 is a free download, but requires a version 5 key. Customers with existing 4.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.

2008-03-31 MonitorWare Agent 5.2 Final (Build Service 5.2.348/Client 5.1.1196)

MonitorWare Agent 5.2 Released

Build-IDs: Service 5.2.348, Client 5.2.1196

New Additions

InterActive SyslogViewer
With this release, we are introducing a new tool for Realtime Syslog viewing called “Interactive SyslogViewer”. This application is written in Microsoft .Net which means, the .Net Framework will also be installed with the setup. Continue reading “2008-03-31 MonitorWare Agent 5.2 Final (Build Service 5.2.348/Client 5.1.1196)”

How to send EventLog entries as SNMP Traps with MonitorWare Agent

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

Article created 2008-03-06 by Andre Lorbach.

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
1.2 Setup a EventLog Monitor in MonitorWare Agent
2. Configuring the SNMP Trap
2.1 Create SNMP Trap Action
2.2 Filtering for EventLog severity (Optional)
2.3 Start sending SNMP Trap

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