Author: adisconteam

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

How To setup Windows centralized Monitoring

How To setup Windows centralized Monitoring

Article created 2007-10-26 by Florian Riedl
Article updated 2011-05-23 by Tom Bergfeld

Please Note: This article is valid for EventReporter, WinSyslog and MonitorWare Agent in addition to MonitorWare Console!

Windows systems monitoring is really important for all small to large sized environments. The MonitorWare line of products helps to accomplish this important task. This article is to help you establish a small setup to monitor your Windows systems.

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 backgrounds or each of the products documentation on this. This article is a step-by-step description of what you need to do in order to centrally monitor your Windows systems.

Centralized Event Reports

In this step-by-step guide, we want to monitor the windows eventlog on all of our client machines (which can be done either with EventReporter or MonitorWare Agent) and then forward the logfiles to a central log server which writes the data into a database (can be done with WinSyslog or MonitorWare Agent). After this, MonitorWare Console should read the data from this database and automatically generate event summaries for the monitored servers.

This guide focuses on a typical small to medium business topography with a single geographical location and five windows clients and a central hub server. All systems are well connected via a local ethernet. Event reports from all machines should be stored in a database. The administrator shall receive daily consolidated event reports.

What you need

In this guide, I am focusing on building a solution with Adiscon’s EventReporter, WinSyslog and MonitorWare Console. (Please note that you can use and configure MonitorWare Agent in the same way like either WinSyslog or EventReporter because it is our main product which has all the features of the other two products too. Please also see our article on which product to choose if you are in doubt which one is right.)
This combination allows you to centralize all your event logs and reports on them. Free 30 day trial versions are available at the respective product sites (links below), so you can try our products without the need to buy anything. You need to run the following products:

  • One EventReporter (alternative: MWAgent) for each system that is to be monitored. In our scenario, this means 6 copies, one for each client and one for the central hub server, if you want to monitor the hub server as well.
  • One WinSyslog (alternative: MWAgent) to receive and store event reports from the EventReporter (alternative: MWAgent) monitoring agents.
  • One MonitorWare Console to automatically generate consolidated reports based on the gathered log data. MonitorWare Console is a very comprehensive tool that helps you to carry out sophisticated analysis of your system. For more information about MonitorWare Console, please refer to its manual.

Notes:

  • You need administrative privileges on each of the machines. This is required both for installation and configuration. Make sure you log on with a sufficiently privileged user account.
  • You need a database to store the events. Recommended are MySQL or MSSQL databases, but you could use a JET database as well.
  • To deliver MonitorWare Console reports, you need a mail server capable of talking SMTP (most modern servers support this)

Step 1 – Download Software

You should check the web sites for new versions if you downloaded your copies a while ago as security and monitoring is a short lived business, and new product versions can appear quickly. Please visit www.eventreporter.com/en/download, eventually www.mwagent.com/en/download, www.winsyslog.com/en/download and www.mwconsole.com/en/download/ to download the latest versions of EventReporter, MWAgent, WinSyslog and MonitorWare Console.

Step 2 – Installing WinSyslog/MWAgent

Identify the system; WinSyslog or MWAgent (and probably MonitorWare Console) should run on. Take a note of its IP address or host name. You’ll need this value when configuring the EventReporter clients. For our example, I assume this system has an IP address of 192.168.0.1.

Run the WinSyslog/MWAgent setup with default parameters. When setup has finished, it automatically is configured to operate as a simple Syslog server. However, it does not yet use a database as we need it to. We’ll later set it up to write data into the database.

Step 3 – Install EventReporter/MWAgent

Run the EventReporter/MWAgent setup program on all systems that should be monitored. This means you need to run it on all five clients and the central hub server (as mentioned above that it is also to be monitored).

For larger installations (with many more servers) there are ways to set it up in a simpler fashion, but in a scenario like ours, it is faster to install it on each machine manually. You can install it with the default settings. When setup has finished, the program automatically is configured to operate simply to report events. However, it does not yet create the log in our database we need. So we will go ahead and change this on each of the machines or by launching it on one machine and remotely connecting to the others. It is your choice. In this sample, I use the EventReporter/MWAgent on each machine (it is easier to follow).

Step 4 – Configuring the Central Agent

The steps described are for setting up your WinSyslog/MWAgent installation on your central hub server. Some steps will be described in a mini-guide, so be sure to follow the links:

1. Start WinSyslog/MWAgent.

2. Select your language – in this example, I use English, so it might be a good idea to choose English even if that is not your preference. You can change it any time later, but using English makes it much easier to follow this guide here.

3. We will now create a ruleset for logging into a database. You can see the detailed steps in the following guide. It describes setting up the action and the ODBC datasource. In this example, a JET database will be used, but you can adapt these steps to let the ODBC driver point to a different database. For setting up the database, please refer to the software producer. Immediate troubleshooting can be done with us, too.
How to create a ruleset for database logging?

4. Now that we have created our ruleset, we are ready to configure the receiving service. Again, follow the mini-guide for the specific steps. We will create a SETP server. With this, we will be able to receive the eventlog data from our agents on our central hub server. Why not using syslog? Because syslog will change the format of the log message and for creating reports we need the correct format.
How to create a SETP server service?

5. Make sure you press the “Save” button – otherwise your changes will not be applied. The only thing left is to start/restart the service with the Play button. Once done, your central agent is ready to receive the log data and store it into your database.

Step 5 – Configuring the Reporting Agents

The steps you will take now will show you how to setup your EventReporter/MWAgent to monitor your Windows Events and forward them via SETP to your central hub server from Step 4. The procedure is the same as above. Follow the links to the miniguides for a detailed description of the respective step.
Please Note: If you use MonitorWare Agent on your central hub server, then you do not need to install EventReporter. You can do these configuration parts in MWAgent, too. You just have to make sure, that the service uses the correct ruleset!

1. Start WinSyslog/MWAgent

2. Again, you can select the language to use. And again, I suggest using English, as this makes the guide easier to follow.

3. We will now setup a new ruleset for forwarding the log data to our central host. Please make sure, that you insert the IP 192.168.0.1 (respective the IP you noted and which belongs to your central hub server) into the forward SETP action. This is crucial or else your central hub server will not receive any data.
How to create a Forward vis SETP Action?

4. After creating the ruleset, we will now create the service which will poll the eventlog data for forwarding via SETP. The service we are going to create is the EventLog Monitor. It will check in set time intervals for new events and if some occurred, they will be processed by the ruleset. Here are the steps for this procedure:
How to create the EventLog Monitor Service?

5. Again, make sure you press the “Save” button – otherwise your changes will not be applied. The only thing left is to start/restart the service with the Play button. Once done, you reporting agent will begin to poll the log data from your eventlog and forward it via SETP to your central hub.

Step 6 – Installing and Configuring MonitorWare Console

Now we will turn to MonitorWare Console. To keep traffic low, you could set this up on your central hub server as well. This will give MonitorWare Console direct access to the database and helps to perform better. In the following guide, we show you how to install MonitorWare Console and do the basic configuration steps:
MonitorWare Console 3.x – Installation and Configuration Steps

Step 7 – Generating Reports with MonitorWare Console Manually

This section explains how the reports can be generated with MonitorWare Console manually. Since “System Status” Report is most comprehensive report that tells a detailed description about the network, in this section I will explain this report only. Please note, that the procedure for generating any report is almost the same.
How To Generate Reports with MonitorWare Console 3.x 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. Once again, I will explain the scheduling of System Status Report in this section. Please note that, the procedure for scheduling any report is the same.
How To Schedule Reports with MonitorWare Console 3.x

You are done!

Well, this is all you need to do to configure the basic operations. Once you are comfortable with the basic setup, you can enhance the system with local pre-filtering of event, enhanced logging and alerting (with MonitorWare Agent) and changing report options (with MonitorWare Console).

I hope this article is helpful. If you have any questions or remarks, please do not hesitate to contact us at support@adiscon.com.

Supported Windows Versions: Windows 7 / 2008 / Vista / 2003 / XP

2007-10-11 MonitorWare Agent 5.1 Final (Build Service 5.1.340/Client 5.1.1166)

MonitorWare Agent 5.1 Released

Build-IDs: Service 5.1.340, Client 5.1.1166

New Additions

  • EventLog Monitor

    Added new option to use the new Checksum method to verify if the LastRecord is still valid. This option can be set in each EventLogType. We also had to redesign the Client advanced options form, as all the options did not fit into it anymore. This option will prevent you from modifying the LastRecord value which means if you change the LastRecord value, the whole EventLog will be reprocessed! Continue reading “2007-10-11 MonitorWare Agent 5.1 Final (Build Service 5.1.340/Client 5.1.1166)”