Created 2004-06-24 by Tamsila-Q-Siddique.
We are using MonitorWare Agent / EventReporter to forward Windows Event logs to a Syslog Server. The resulting syslog message doesn’t have the Event IDs in them. How can we make Event ID part of the actual Syslog message?
One of the proposed solution would be to forward the Event Log messages using SETP Server. The resulting message would have the Event IDs in them. Click here to know the difference between SETP and Syslog!
But there are other ways to include the Event ID even without using SETP (which is obviously not an option if you would like to send to a non-Adiscon backend). So you can do one of the following:
- Use XML Format – This is the best recommended option. With XML format, you get everything about this event and you get it in a well-structured way. It includes all of the properties described in our Event Properties reference. To enable XML format, simply check “Use XML to Report” in the “Forward Syslog” Action.
- Use Custom Format – In the “Forward Syslog” action, you can specify your own custom format in the “Message Format” text box. By default it is set to %msg%, but you can include whatever you like. Use the “Insert” link to do this (or simply type it)! Be sure to read the Property Replacer” documentation to see the full power. This option is a good one, especially if you intend to parse the data… because *you* can exactly specify what you would like to see.
- Use MoniLog Format – This is our former legacy format. It includes a bunch of useful information, but it has a number of anomalies, which might hit you in few cases when parsing. We do not recommend it, but if you would like to use it, you can select the “Insert” link in the “Forward Syslog” action properties. Then, select “Replace with MoniLog Format”. It will generate a custom format of the type given below. Again, we do not recommend this, but it is a way.## %severity% %timereported:::uxTimeStamp%: %source%/%sourceproc% (%id%) – “%msg%” ##
- Change Event Log Monitor Settings – You could also change the Event Log Monitor itself to generate the legacy format. Then, you do not need to change the “Forward Syslog” action’s settings. The big drawback is that now the Event Log Monitor does emit an old format, which is not meant to be processed by any other MonitorWare product. If you just use the product as a back-end for your own front-end, this is not an issue. Anyhow, we still recommend to go for approach #3 instead of this. If you absolutely want to do it this way, this is how it is done:
Go to the Event Log Monitor properties. Click on the “Advanced Options” button. Check the “Use Legacy Format” checkbox. This will enable some other checkboxes. Review the options to see which of these you want.
We have provided the options at hand. We *strongly* recommend to go for either option 1 or 2. If you choose option 3 or 4, you can receive a parsing error from time to time. However this has been solved after introducing the newer formats.
As a general hint, you may want to take into account that Windows Event Log messages can become rather lenghty. They often go over the syslog RFC size of 1024 bytes. If you run a non-Adiscon Syslog Server, you need to ensure it can receive such large messages, because otherwise some information might be missing (with option 2, you can customize what you would like to be missing in such cases – by limiting the size of %msg% via the property replacer).
An update can be made from one version to the next, e.g. from Vx to Vx+1. The upgrade fee is 75% of the current product price. Is the difference between the license greater than one version (Vx to Vx+2) it is necessary to buy a new license.
The scenario is, that we need to monitor the behavior of users logging into machines, as well as failing or being locked out, due to bad inserted passwords. All those events should be written into a text file with a unique message that indicates to us what has happened. We need only one ruleset and one service for this. The service would be the EventLog Monitor. In the ruleset, we need 3 separate rules with each having one Action, the Write to File Action. The basic setup should look like this:
Image 1: Basic Setup
Now we will get to the core part of this setup. The filters. This will be a little bit complex, as there are a lot of possibilities when it comes to monitoring logon events. We need to monitor the events with the following IDs:
- Event ID: 528 – Successful Logon
- Event ID: 529 – Logon Failure: Unknown user name or bad password
- Event ID: 530 – Logon Failure: Account logon time restriction violation
- Event ID: 531 – Logon Failure: Account currently disabled
- Event ID: 532 – Logon Failure: The specified user account has expired
- Event ID: 533 – Logon Failure: User not allowed to logon at this computer
- Event ID: 534 – Logon Failure: The user has not been granted the requested logon type at this machine
- Event ID: 535 – Logon Failure: The specified account’s password has expired
- Event ID: 536 – Logon Failure: The NetLogon component is not active
- Event ID: 537 – Logon Failure: An unexpected error occurred during logon
- Event ID: 539 – Logon Failure: Account locked out
We need to split up these events for the different rules we created before. To summarize it, we need the following packages:
- Logon Success: Event ID 528
- Logon Failure: Event ID 529 – 537
- Account Lockout: Event ID 539
There are a lot of Events available for logon failure. So we have to consider all the events that would fit. If some events do not fit for your account policy auditing, then simply leave them out. With this information in mind, we set up the filters. The first two filter will be for “Successful Logon” and “Account Lockout”. We use the “AND”-Operator and filter for the Event ID. This looks as follows:
Image 2 and 3: Filter for “Successful Logon” and “Account Lockout”
The last filter for “Logon Failure” looks a bit different, as we have multiple conditions that we need to check. Therefore we need a different Operator. We will take the “OR”-Operator as this is the most suitable. It will evaluate to true once one of the multiple conditions is true. So the same Action (writing a message to a textfile that tells us, that a login has failed) can be performed for multiple events. In contrary, the “AND”-Operator needs all conditions to be true to process the Event, else the Action will not be carried out. The filter should look like this:
Image 4: Filter for “Logon Failure”
The last thing we have to do is to set the messages that should be written into the textfile. Therefore go to each “Write to File”-Action and set the “File Format” to “Custom”. Then you can edit the message to whatever you like. I chose these messages for my example:
- A User has successfully logged in, see message details: %msg%%$CRLF%
- A User has been locked out. See messages details: %msg%%$CRLF%
- A User has failed to log in. See message details: %msg%%$CRLF%
These messages give you directly a comment about the event that happened and show you the original message, which holds the information about the user, machine and message details. The configuration for one of those Actions could look like this:
Image 5: Settings for “Write to File”-Action
Please Note: Every “Write to File”-Action needs to write its messages into the same file. Else, you will have separate files for all three kinds of messages. If writing to the same file, a message will be written one after another, so there will not be any overlapping with the messages.
You could also make this message a bit more detailed by including the timestamp and the name of the machine on which the Event happened. Then it could look like this:
- %timereported%, %Param0%, %Param1%, %Param5%, Logon Failure%$CRLF%
This would result in the following message:
2008-10-14 09:24:33, Username, Domain, Workstation, Logon Failure
The message now contains the complete timestamp with date and time, the name of the Domain for which the Event applies, the Workstation name from which the message originates and “Logon Failure” as comment to what happened. We have to do this in a fixed way, as we do not have this information automatically parsed from the Event message. If you want to have the detailed description for the Event you can either add the complete message with %msg% or parse out the information before writing it and put it into a custom property with the “Post-Processing”-Action (only available in MonitorWare Agent Professional and Enterprise).
This is all that needs to be done for having all events for Successful Logon, Logon Failure and Account Lockout written into a textfile. If you have any remarks, suggestions or questions to this article, please send a email to our Support Team.
By default the log files generated by MonitorWare Agent using the WriteFile Action are written on a daily basis, so you have one log file for each day. Over time this can become a huge number uncompressed log files, so you properly want to archive them automatically to save disk space. There is no inbuilt method in MonitorWare Agent yet to do so, but this article will describe how you can archive this goal by using the Windows Task Scheduler and WinRar.
- You can download the scripts needed for this article here, which you will need on your target system.
1. Installing and Configuring MonitorWare Agent
1.1 Download and Install MonitorWare Agent
1.2 Setup up basic MonitorWare Agent configuration
1.3 Configure the Write File Action.
1.4 Start MonitorWare Agent
2. Configure log file archiving
2.1 Download and Install WinRar
2.2 Create VBScript which utilizes WinRar to create archives.
2.3 Create Task in Windows Task Scheduler
|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.|
|Start the MonitorWare Agent client and skip the wizard on startup. In this article, we will use an EventLog Monitor as source for our File logging, but you can use any other kind of source.Create a new “EventLog Monitor” service and just name it “EventLog Monitor”. You can leave all configuration settings as they are in the screenshot on the right.|
|In order to create log files we need a Write File Action. Create a new Write File Action like in the screenshot on the right. The default settings will create daily log files automatically. You may customize the log format by using the custom “File format” option. It is important to have the “Create unique filenames” Option enabled, this will enable the daily written log files.
The log file name for 2008-11-28 would be MonitorWare-2008-11-28.log, and for the next day MonitorWare-2008-11-29.log and so on.
|After you configured MonitorWare Agent, you can start the Service and verify that the daily log files are successfully written.|
|Visit the RarSoft website to download the latest Version of WinRar, if you haven’t installed it already. There are plenty of other packer applications out there and this article may also be used with them. However I will focus on using WinRar.
Once you downloaded WinRar, start it’s installation, and remember the exact path it was installed to. Usually this is “C:\Program Files\WinRAR” or “C:\Program Files (x86)\WinRAR”.
|This script will actually do the work for you. It is designed to automatically generate the filename of the log file from yesterday, and create an archive with the same name. If the archive is successfully created, the log file will automatically be deleted. The script is also in the script package which you can download at the top. You can also copy the script content from the textbox below, and create a new file archive_logs.vbs yourself.
By default the script will create zip files, if you rather want to create rar files, just remove the -afzip parameter from the variable szCommand at the end of the script.
The next thing to do is to edit this script to your needs. There are 4 parameters at the top which you may need to customize, so the script fits into your environment.
szWinRardirectory – contains the full installation of your WinRar installation
Once you have done this, you should run the script at least once manually by double clicking it to see if it works. You may only notice a short popup of the WinRar Windows, depending if a log file to archive can be found, and archiving takes some time. If it works, you should see a zip-packed log file in your logs directory, like in this screenshot.
|Open the Control Panel, and go to the scheduled tasks. From there you can create a new scheduled task using a wizard. Once the wizard is opened, click on browse to manually select the “archive_logs.vbs” script. Then proceed to the next step of the wizard.|
|Choose “Daily”, and set the start time in the next wizard step. I have chosen 02:00 am in this article, but you can also chose 04:00am or 01:00am. It should not be 00:00am, because the script might archive the log file too early.
In the next step you have to configure the Username and Password, the task is going to run under. Once you finished creating the scheduled task, right click it in the task list and select “Run” in order to test that the task is working.
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.
Will the same key work when I upgrade from 10.x version to 11.x version?
You can use this license key for any 10.x version of EventReporter. But this license key will not work if you want to upgrade from 10.x to 11.x and it will also not work if you want to switch from e.g. basic edition to professional edition. It calls for a new license. If you had got a new license and aren’t sure what to do follow these simple procedure.
Note 2: We assume you already have installed the trial version. If you do not have it installed, please visit the product web site and download and install the product first.
- Download WinSyslog from http://www.eventreporter.com/en/Download/
- After downloading the software start the client application.
- Switch to the “License” tab.
- Enter the License Name and License Key into the respective fields.
- Click “OK”
This process will switch the product from the trial version to the licensed one. Be sure to enter the license name and license key exactly as provided by us. Remember that the license key information is case-sensitive. Documentation on how to enter the license key is in the manual. If you still encounter problems, please go throught this License Information FAQ.
Note 4: This FAQ is also applicable for the case when you upgrade from version 4.x to 5.x or higher!
Build-IDs: Service 14.3.395, Client 14.3.484
Adiscon is proud to announce the 14.3 release of EventReporter.
This is a bugfixing release with minor feature update.
Most importantly, the Adiscon SNMP MIB now supports messages sizes up to 64k (previous limit was 255 characters). The OpenSSL Library has been updated to 1.0.2h. Bugs were fixed primarily in RELP and syslog forwarding processing. For details please see the change log.
Detailed information can be found in the version history.
Version 14.3 is a free download. Customers with existing 13.x keys can contact our Sales department for upgrade prices. If you have a valid Upgrade Insurance ID, you can request a free new key by sending your Upgrade Insurance ID to firstname.lastname@example.org. Please note that the download enables the free 30-day trial version if used without a key – so you can right now go ahead and evaluate it.
Build-IDs: Service 14.2.389, Client 220.127.116.111
Build-IDs: Service 14.2.388, Client 18.104.22.1689