How to send generic SNMP Traps with MonitorWare Agent

How to send generic SNMP Traps with MonitorWare Agent.

Article created 2008-03-06 by Andre Lorbach.

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.

Table of Contents

1. Configuring MonitorWare Agent
1.1 Download and Install MonitorWare Agent
1.2  Setup a Syslog Server in MonitorWare Agent
2. Configuring the SNMP Trap
2.1 Create SNMP Trap Action
2.2 Filtering Syslog messages (Optional)
2.3 Sending a test 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 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.

Back to Top

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.

Back to Top
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).

Back to Top

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.

Back to Top

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.

Back to Top

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)”

Back to Top

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 get MonitorWare Agent 4.4 working on Windows NT4?

How to get MonitorWare Agent 4.4 working on Windows NT4?

Created 2008-02-28 by Andre Lorbach

The last official version of MWAgent which is supported on Windows NT4 is version 3.1 Build 292.

Due to customer requests, we have created a special build of MonitorWare Agent version 4.4a which will also work on Windows NT4. However this will definitely be the last official build which will work on NT4. The newer versions of MWAgent are using features which are only available on Windows 2000 or higher. Please note that the installer used for MonitorWare Agent 4.4 can not be run under NT4. As such, the setup procedure is a bit clumpsy.

Follow these instructions to get MWAgent 4.4 build 333 working on Windows NT4.

  1. Download and install MonitorWare Agent 3.1 from here:
    http://www.mwagent.com/download
  2. Download and unpack the special NT4 Version of MonitorWare Agent 4.4 build 333 from here:
    http://download.adiscon.com/mwagent4.4-nt4build.zip
  3. If you haven’t yet, install the Active Directory Extension for Windows NT 4.0, either by download or using the dclient.exe from the package.
  4. Copy the unpacked files over your existing Installation.
  5. Configure and start the MonitorWare Agent.

If any problems occur, feel free to send us an email to support@adiscon.com.

Monitor a SNMP Device using MonitorWare Agent

Monitor a SNMP Device using MonitorWare Agent

Article created 2008-02-26 by Andre Lorbach.

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.

Table of Contents

1. SNMP Device (Printer) Setup
1.1 Configuring the Printer
2. Configuring MonitorWare Agent
2.1 Download and Install MonitorWare Agent
2.2  Setup Basics in MonitorWare Agent
2.3 Create a Forwarding Rule for the InterActive SyslogViewer (Optional!)
2.4 Create an Email alert
2.5 Configure Filters for the Email Alert
Final Thoughts

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.

Back to Top

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. (This article will only work with MonitorWare Agent 5.2 or higher).

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.

Back to Top

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.

Back to Top

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:

Back to Top

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.

Back to Top

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.

Is SMS-alerting possible with a GSM modem and the Send to Communications Port-Action?

Is SMS-alerting possible with a GSM modem and the Send to Communications Port-Action?

Created 2008-02-13 by Florian Riedl.

Which tools to use …

Every of our products (EventReporter, MonitorWare Agent and WinSyslog) contain a action which is able to send messages to the communications port of the PC. The question is, if it is possible, to use a GSM modem connected to this port for realtime SMS alerting.

The “Send to communication port”-action allows you to directly send data to the com-port of a PC. If you have a modem connected, the device will receive the message and interpret it’s content and acts as programmed. In most cases, you would possibly connect a serial audit printer or for example a separate display for showing recent log data. For this, in most cases, the pure message and a line feed will be sufficient.

Sending SMS

For sending to a modem device, in this case a GSM modem, you would need to know, how the message must look like for the GSM modem to send a SMS with the message to a specific recipient. So in general, this is quite likely to work, but we have no information on stock how to setup a specific message.

The easiest way to achieve SMS alerting is by using a E-Mail2SMS service. There are several service providers on the web who provide the possibility to send a E-Mail to a gateway host, which will then send a SMS with the log message to a specified mobile phone number. This is a idea, which is most likely to work.

Anyway, both ideas are likely to get cost-intensive. Once a large number of errors occur, which should be forwarded, this could get out of control. We recommend to use filter settings in order to get only emergency alerts via sms. In any case, this kind of alerting is connected with extra costs.

Different providers are listed here:

Forwarding NT Event Logs to an SETP Server

Step-By-Step Guides

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

Forwarding NT Event Logs to an SETP Server

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

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

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

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

Step 1 – Defining a Rule Set for SETP Forwarding

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

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

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

Click “Next”. A new wizard page appears:

There, select only “Forward via SETP”. Do not select any other options for this sample. Also, leave the “Create a Rule for each of the following actions” setting selected. Click “Next”.

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

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

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

As you can see, we have a “Forward via SETP” action configured. We will review the settings just for your information. Click on “Filter Conditions”:

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

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

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

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

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

After the changes, the dialog looks as follows:

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

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

Step 2 – Create an Event-Log Monitor Service

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

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

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

Once you have done so, a new wizard starts:

Again, you can use either the default name or any one you like. We will use “My Event Log Monitor” in this sample. Leave the “Use default settings” selected and press “Next”:

As we have used the default, the wizard will immediately proceed with step 3, the confirmation page. Press “Finish” to create the service. The wizard completes and returns to the configuration client. There, you will see the newly created service beneath the “Services” part of the tree view:

To check its parameters, select it:

As you can see, the service has been created with the default parameters. As such, it monitors all event logs that are present on the system. It also has some protection against overruns of the receiving system or intermediary routers. It monitors the event log in a 60 second interval (sleep time of 60.000 milliseconds), which is the recommended value for typical installations.

Please note that the “SETP Forwarding” rule set has been automatically assigned as the rule set to use. This is the case because we already created it and it is the only rule set. By default, the wizard will always assign the first rule set visible in the tree view to new services. If that is not the intended rule set, you need to change it to the correct one here in the service definition.

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

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

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

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

Click OK to return to the main property sheet.

This procedure completes the configuration of the event log monitor.

Step 3 – (Re) Start the Agent Service

MonitorWare Agent/EventReporter cannot dynamically read changed configurations. As such, it needs to be restarted after such changes. In our sample, the service was not yet started, so we simply need to start it. If it already runs, you need to restart it.

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

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

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

Forwarding NT Event Logs to an SETP Server

Step-By-Step Guides

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

Forwarding NT Event Logs to an SETP Server

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

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

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

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

Step 1 – Defining a Rule Set for SETP Forwarding

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

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

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

Click “Next”. A new wizard page appears:

There, select only “Forward via SETP”. Do not select any other options for this sample. Also, leave the “Create a Rule for each of the following actions” setting selected. Click “Next”.

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

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

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

As you can see, we have a “Forward via SETP” action configured. We will review the settings just for your information. Click on “Filter Conditions”:

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

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

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

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

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

After the changes, the dialog looks as follows:

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

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

Step 2 – Create an Event-Log Monitor Service

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

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

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

Once you have done so, a new wizard starts:

Again, you can use either the default name or any one you like. We will use “My Event Log Monitor” in this sample. Leave the “Use default settings” selected and press “Next”:

As we have used the default, the wizard will immediately proceed with step 3, the confirmation page. Press “Finish” to create the service. The wizard completes and returns to the configuration client. There, you will see the newly created service beneath the “Services” part of the tree view:

To check its parameters, select it:

As you can see, the service has been created with the default parameters. As such, it monitors all event logs that are present on the system. It also has some protection against overruns of the receiving system or intermediary routers. It monitors the event log in a 60 second interval (sleep time of 60.000 milliseconds), which is the recommended value for typical installations.

Please note that the “SETP Forwarding” rule set has been automatically assigned as the rule set to use. This is the case because we already created it and it is the only rule set. By default, the wizard will always assign the first rule set visible in the tree view to new services. If that is not the intended rule set, you need to change it to the correct one here in the service definition.

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

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

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

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

Click OK to return to the main property sheet.

This procedure completes the configuration of the event log monitor.

Step 3 – (Re) Start the Agent Service

MonitorWare Agent/EventReporter cannot dynamically read changed configurations. As such, it needs to be restarted after such changes. In our sample, the service was not yet started, so we simply need to start it. If it already runs, you need to restart it.

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

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

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

Default Timevalues Setting in EventReporter/MonitorWare Agent/WinSyslog explained.

Default Timevalues Setting in EventReporter/MonitorWare Agent/WinSyslog explained.

Created 2008-01-24 by Andre Lorbach.

The general options of each product (EventReporter, MonitorWare Agent and WinSyslog) contain a setting for the “Default Timevalues”. This setting can be set to Localtime and UTC (Universal Coordinated Time) which is default.

If you switch this setting to Localtime, you may wounder why output timevalues still are in UTC.

Internally we need to calculate with UTC time. This is needed in order to maintain the time values if they are send via Syslog or SETP. If we wouldn’t do this, this could result to unexpected time differences.

So where does this setting have an effect?

  • Send Email Action: The date in the email header is affected.
  • Start Program Action: Time parameters in the command line are affected.
  • Write File Action: Time properties in the file name are affected.
  • Filter Engine: If you filter by weekday or time fields, localtime does affect the filter result.

But how can I get localtime output?

We added two additional options into the property engine which can be applied on time based values for this purpose.

Property Option: localtime = converts the output of the timestamp into localtime
Sample: %variable:::localtime%

Property Option: uxLocalTimeStamp = same output as uxTimeStamp, but localtime is used
Sample: %variable:::uxLocalTimeStamp%

How to monitor a Software-Raid on Windows 2003 by using the EventLog Monitor of MonitorWare Agent

How to monitor a Software-Raid on Windows 2003 by using the EventLog Monitor of MonitorWare Agent.

Article created 2008-01-17 by Andre Lorbach.

This article will guide you in how to monitor a software raid on Windows 2003 by filtering specific events by using the EventLog Monitor in MonitorWare Agent. This is also possible with EventReporter, however this article will target the more powerful MonitorWare Agent.

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

Raid Systems have a big advantage for failover support and prevent data loss. But what when a hard disk is failing, you don’t know it? Windows Server Systems often run for months without being monitored, and what if two hard disk fail in this time period? A nightmare for every system administrator. So we will setup a EventLog Monitor in MonitorWare Agent which alert you by email in case of a raid brakes, a hard disk fails or anything else bad happens.

Table of Contents

1. Creating a Windows Software Raid (Skip if Raid exists!)
1.1 Convert Hard disks into dynamic disks
1.2 Adding a Mirror to the existing system partition
2. Installing and Configuring MonitorWare Agent
2.1 Download and Install MonitorWare Agent
2.2 Setup up basic MonitorWare Agent configuration
2.3 How to verify that the alert is working?
Final Thoughts

1. Creating a Windows Software Raid (Skip if Raid exists!)

1.1 Convert Hard disks into dynamic disks

So in case you have no Software Raid configured yet, open the Computer Management und go to the Disk Management. You will see your System drive and you should have a second hard disk with enough free space available. For a sample see the screenshot.

Right-Click one of the disks and click on “Convert to Dynamic Disk”. A wizard will appear, select both hard disks, the system one and the one you are going to use as raid mirror. Once you have accepted this, a couple of questions will follow which you need to accept and finally a reboot is required. This is because Windows can not convert a hard disk if the system is running on it.

Once you have rebooted, logged in and open the Disk Management. You will notice the different partition color. This means your system partition runs on a dynamic disk now, the conversion went fine. If not review the System EventLog for possible errors.

Back to Top

1.2 Adding a Mirror to the existing system partition

All requirements for a software raid (mirror) are now given, so kindly right click your system partition and click on “Add Mirror“. A requester will open which will ask you on which disk you want to add the mirror. In our sample, this would be disk 1. After the mirror has been added, Windows will start regenerating the mirror which means it will sync both hard disks. This may take some time depending on the size of your hard disk, maybe even hours.

As you can see the partitions are now marked red which represents the color for mirrored partitions. After the synchronization has finished, the red partitions will be marked as healthy in the Disk Management view.

Back to Top

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.

Back to Top

2.2 Setup up basic MonitorWare Agent configuration

Start the MonitorWare Agent Client and skip the wizard on startup. First we create new “Event Log Monitor” Service. Uncheck all event log types except System, as this is the only event log needed to achieve our goal. If you like to monitor other Event Log Types too, you may select them. It will have no impact on our following configuration.

Now we can add another Rule called “Send Email Alert”. This rule will have a few filters to only allow events with warning or error severity. The Eventlogtype is System and the event sources which matter to us are dmio and dmboot. The filters should look like in this screenshot.

For additional reference, here is a list of possible dmboot und dmio events:
Event ID 1: “dmboot: Volume %2 (no mountpoint) started in failed redundancy mode.”
Event ID 2: “dmboot: Volume %2 (%3) started in failed redundancy mode.”
Event ID 3: “dmboot: Failed to start volume %2 (%3)”
Event ID 4: “dmboot: Failed to encapsulate selected disks”
Event ID 5: “dmboot: Disk group %2 failed. All volumes in the disk group are not available.”
Event ID 6: “dmboot: Failed to auto-import disk group %2. All volumes in the disk group are not available.”
Event ID 7: “dmboot: Failed to restore all volume mount points. All volume mount points may not be available. %2”

Event ID: 1, “dmio: Device %2,%3: Received spurious close”
Event ID: 2, “dmio: Failed to log the detach of the DRL volume %2”
Event ID: 3, “dmio: DRL volume %2 is detached”
Event ID: 4, “dmio: %2 error on %3 %4 of volume %5 offset %6 length %7”
Event ID: 5, “dmio: %2 %3 detached from volume %4”
Event ID: 6, “dmio: Overlapping mirror %2 %3 detached from volume %4”
Event ID: 7, “dmio: Kernel log full: %2 %3 detached”
Event ID: 8, “dmio: Kernel log update failed: %2 %3 detached”
Event ID: 9, “dmio: detaching RAID-5 %2”
Event ID: 10, “dmio: object %2 detached from RAID-5 %3 at column %4 offset %5”
Event ID: 11, “dmio: RAID-5 %2 entering degraded mode operation”
Event ID: 12, “dmio: Double failure condition detected on RAID-5 %2”
Event ID: 13, “dmio: Failure in RAID-5 logging operation”
Event ID: 14, “dmio: log object %2 detached from RAID-5 %3”
Event ID: 15, “dmio: check_ilocks: stranded ilock on %2 start %3 len %4”
Event ID: 16, “dmio: check_ilocks: overlapping ilocks: %2 for %3, %4 for %5”
Event ID: 17, “dmio: Illegal vminor encountered”
Event ID: 18, “dmio: %2 %3 block %4: Uncorrectable %5 error”
Event ID: 19, “dmio: %2 %3 block %4:\r\n Uncorrectable %5 error on %6 %7 block %8”
Event ID: 20, “dmio: Cannot open disk %2: kernel error %3”
Event ID: 21, “dmio: Disk %2: Unexpected status on close: %3”
Event ID: 22, “dmio: read error on object %2 of mirror %3 in volume %4 (start %5, length %6) corrected”
Event ID: 23, “dmio: Reassigning bad block number %2 on disk %3”
Event ID: 24, “dmio: Reassign bad block(s) on disk %2 succeeded”
Event ID: 25, “dmio: Fail to reassign bad block(s) on disk %2: error 0x%3”
Event ID: 26, “dmio: Found a bad block on disk %2 at block number %3”
Event ID: 27, “dmio: Corrected a read error during RAID5 initialization on %2”
Event ID: 28, “dmio: Failed to recover a read error during RAID5 initialization on %2: error %3”
Event ID: 29, “dmio: %2 read error at block %3: status 0x%4”
Event ID: 30, “dmio: %2 write error at block %3: status 0x%4”
Event ID: 31, “dmio: %2 write error at block %3 due to disk removal”
Event ID: 32, “dmio: %2 read error at block %3 due to disk removal”
Event ID: 33, “dmio: %2 is disabled by PnP”
Event ID: 34, “dmio: %2 is re-online by PnP”
Event ID: 35, “dmio: Disk %2 block %3 (mountpoint %4): Uncorrectable read error”
Event ID: 36, “dmio: %2 %3 block %4 (mountpoint %5): Uncorrectable read error”
Event ID: 37, “dmio: Disk %2 block %3 (mountpoint %4): Uncorrectable write error”
Event ID: 38, “dmio: %2 %3 block %4 (mountpoint %5): Uncorrectable write error”

The next step is to create a SendEmail Action and configure it like in the screenshot.

Here is the Event message we suggest to use, but feel free to create and modify your own:

You need to replace the mail server, sender and recipient with yourself.

Back to Top

2.3 How to verify that the alert is working?

There is a simple way to test if our alerting is working, however it isn’t without risks. I only recommend you to do this step if your really want to test the alerting! I do NOT recommend to perform this test on a productive system!

First of all shutdown the server and open the case. Then disconnect the second hard disk by removing the power or the data connector. Then boot the server, once windows is starting the services you should get an alert by email. It should look like the sample email in the screenshot.

If the test was successful, you can shutdown your server again. Connect the power / data connector and boot your server. You may receive the same email message again, as the raid is now OUT OF SYNC. So you need to open the Disk Management and right click the disk with the exclamation mark. Then select “Reactivate Disk”, the raid will begin resynchronization immediately after this.

Back to Top

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

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

Article created 2007-12-12 by Andre Lorbach.

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.

Table of Contents

1. Windows Settings
1.1 Turn on Security Auditing
1.2 Add Auditing to the folders / drives you want to monitor
1.3 Configure Windows Security EventLog Size
1.4 Testing File Deletion
2. Configuring MonitorWare Agent
2.1 Download and Install MonitorWare Agent
2.2  Setup Basics in MonitorWare Agent
2.3 Use File Logging to store File Deletion
2.4 Create an Email alert

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 XP / Vista, open the “Local Security Settings” from the “Control Panel->Administrative Tools”. 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 XP machine.

Back to Top

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.

Back to Top

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.

Back to Top

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.

Back to Top

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

Back to Top

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. The Event which is interesting for us is the first Event with ID 560. 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.

Back to Top

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.

Back to Top

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.

Back to Top

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

Back to Top

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:

Back to Top

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.

How To setup PIX centralized Monitoring with MonitorWare Console 3.x

How To setup PIX centralized Monitoring with MonitorWare Console 3.x

Article created 2005-05-17 by Hamid Ali Raja
Last Updated 2011-05-24 by Tom Bergfeld

Adiscon Products can be used to efficiently analyze PIX traffic as well. This article is strictly task focused. It does not describe why the systems should be monitored nor does it provide any further background. Please see the respective backgrounders or product documentation on this. This article is a step-by-step description of what you need to do in order to centrally monitor your PIX logs.

Centralized PIX Reports

In this step-by-step guide, WinSyslog is configured to work together with Adiscon’s MonitorWare Console to generate summaries for the traffic passing to and from PIX.

What you need

In this guide, I am focusing on building a solution with Adiscon’s WinSyslog and MonitorWare Console. This guide will be equally good for you if you want to configure MonitorWare Console with WinSyslog or to configure MonitorWare Console with MonitorWare Agent. The reason is that in this configuration a syslog server that will be listening for syslog messages is required. Since MonitorWare Agent and WinSyslog can act as syslog server, this guide can be used for both. The configuration steps are exactly the same in both cases.

This combination allows you to centralize all your logs and generate reports on them. Free 30 day trial versions are available at the respective product sites (links below), so you can try the system without the need to buy anything.

You need to run the following products:

  • 1 WinSyslog for the system that will act as the syslog server.
  • 1 MonitorWare Console to generate consolidated reports based on the gathered log data. This will also be installed on the same machine where you have installed WinSyslog.
  • You need administrative privileges on each of the machines. This is required in both cases, for installation and configuration. Make sure you log on with a sufficiently privileged user account.

    Step 1 – Download Software

    You need to download the following software to follow this step by step guide:

    1. www.winsyslog.com/en/download
    2. www.mwconsole.com/en/download

    Step 2 – Install WinSyslog

    Run the WinSyslog program on the system that is to act as the central server. Take a note of this server’s IP address or host name. You’ll need this value when configuring PIX to forward the messages to it.

    Step 3 – Configure a Syslog Server

    The steps to configure the WinSyslog as a syslog server are as follows:

    Configuring a Syslog Server

    Step 4 – Create a RuleSet for Database Logging

    In this section, you will create an action to write the messages that are coming from PIX to a database. Please note that these steps would be exactly the same for both MonitorWare Agent and WinSyslog.

    Database Logging Steps

    After configuring this RuleSet, make sure that

    • this rule set is associated with the syslog server service that you created in step 3. You can do this by clicking on the syslog server service on the left hand side and by selecting the name of the rule set that you created in step 4 in “Rule Set to Use” combo box on the right hand side.
    • The service is running. You can do this by clicking on the Play button at the top of the client.

    Step 5 – Configure PIX

    In this step, you will need to configure PIX in such a way so that it sends the messages to the syslog server that you created in the above step. You would need to give the IP address or the hostname in PIX.

    PIX Configuration Steps

    Step 6 – Installing and Configuring MonitorWare Console

    MWConsole- Installation and Configuration Steps

    Step 7 – Generating PIX Reports with MonitorWare Console Manually

    Following are the reports in MonitorWare Console that can be generated for PIX logs.

    • Accessed Web Sites Report
    • Blocked Ports Activity Report
    • Possible Attacks Report
    • PIX Summary By Message Type
    • PIX Summary by Severity Level
    • Traffic By Hour Report
    • Traffic By Port Report
    • Outbound Traffic By IP
    • Traffic by Target IP

    This section explains how the PIX reports can be generated with MonitorWare Console manually. In this section I will explain the generation of a specific report only. Please note that, the procedure for generating any report is almost the same.
    Generating PIX Reports with Console 3.0 Manually

    Step 8 – Scheduling the Generation of Reports with MonitorWare Console

    This section explains how the reports can be generated with MonitorWare Console automatically using Job Manager. With Job Manager, you can generate all the reports based on a pre-defined schedule and ask it to either store it in some location on the hard disk or send it to specified recipient via email. The following section explains the scheduling of System Status Report. You can use exactly the same method to generate any of the PIX reports that are mentioned above.

    Scheduling Reports with Console 3.0

    You are done!

    Well, this is all you need to do to configure the basic operations. We hope this article is helpful. If you have any questions or remarks, please do not hesitate to contact us at support@adiscon.com