Script: Email Event Logs - Configurable Parameters


I’d like to share the following procedure/script in case it is useful to anyone else. Feel free to do with it as you wish. I’m writing this up in detail in order to show the methodology used and make it easier for the community to use, edit, understand or improve.

This procedure runs a powershell script that finds the specified event logs and then a report is emailed in HTML format. The email settings, how many days prior to include, event log name and event log type are all configurable via the procedures parameters for easy setup and modification. The goal was to make the procedure modular and mobile, so that the core script code doesn’t need to be modified for basic usage. Credit for the original powershell script is included in commented notes. I have only slightly modified it and adapted it for use with C1, especially with parameters.

Use Cases
This was developed to enhance event log alerting and reporting. Currently available scripts in the C1 library for emailing event log information did not meet all the desired needs. This script uses C1’s parameters feature to allow flexibility on what event log and event type should be included. This can aid in troubleshooting issues or for compliance in security related policies. This can be used in conjunction with a monitor that detects when a specific event has occurred. This procedure can then be run on auto remediation to provide a report when the monitor is triggered. For example, if a monitor looks for specific error event ID in the system log, when triggered it would run this script with pre-configured parameters to gather the last 30 days worth of logs of type Error from the System event log. You can also configure the script to include all event types, which may be helpful to include more information around the event in question.

Requirements and Limitations
This script relies on gathering events from a specified windows event log. Currently, you can specify the log name and log type. It does not target specified event ID’s. The idea is that it can be used to gather all recent event logs of a more generic type to help gather more information that can help troubleshooting specific issues. Additionally, the amount of history the script can pull is dependent on how far back the event logs go on the machine its run on. By default, assuming a reasonably standard and healthy windows machine, it should be able to go back at least a week.

How to setup and use

  • Download the procedure:
  • Import the procedure under Configuration Templates - Procedures - Import Procedure
  • Configure the default parameters for the procedure from the Parameters tab of the script. You can set this up at run-time but the defaults need to be set in order for it to be used for auto remediation. Here are the current configurable parameters
    • Event Log Name
    • Number of Days to Retrieve History
    • Event Level Type
    • SMTP Server Address
    • SMTP Port
    • SMTP Username
    • SMTP Password
    • From Email Address
    • Send to Email Address
Example below for application crash alert
  • Create a new monitor under Configuration Templates - Monitors - Create Monitor. Configure with these settings (modify to your environment and desired settings)
    • Name: Application Crash/Hang Alert
    • Condition 1: Type = Event, Event ID = 1000, Level = Error, Source = Application Error
    • Condition 2: Type = Event, Event ID = 1002, Level = Error, Source = Application Hang
    • Trigger an alert if: Any of the conditions are met
    • Select an appropriate alert setting
    • Auto remediation on alert: Run procedure = Email Event Log Entries
    • If not already done so, configure parameters of the report procedure. In this example, parameters Event Log Name = Application and Event Level Type = Error
  • Apply the monitor to your desired profile. I especially use this on servers and workstations to monitor for application crashes or pretty much any other important error or warning logs. Leverage the maintenance window profile feature to prevent unwanted alerting/reporting when performing intended tasks that could trigger the monitor.
Future development Alot more can be done to improve this script but its a starter. Eventually I'd like to enhance it by adding or making these changes. Listing here for those interested
  • Making a configurable parameter to specify storing the report in a configurable path (server/local path).
  • Add more output options, such as HTML and PDF file
  • Add integration with siPortal/IT Portal using their API to store output information in a device or config items history/notes.
  • Other ideas welcome
I hope this is of help to anyone.


20191228-Email-Event-Log-Entries.json (11.1 KB)

Hi @eztech,

Thank you so much for taking your valuable time to share this post. We appreciate your efforts.

Kind Regards,