[ Main Index | ipSentry Help Index ]
 

From the Entry Editor, click on the Alerts Tab, click on Mail Tab

Email Alert Configuration
The email alert allows you to be notified via email should there be a problem detected.  The email alert subject and message body are key word enabled allow you to create a common message structure without literal text entry for each device.

IPSentry Email Alert Configuration

The settings outlined below are common to all of the ipSentry outbound email configuration dialogues including Email Alert, Pager (SMTP) Alert, and the Email Transaction Monitoring Add-In.

Mail Server
Enter the IP Address of the SMTP Relay server that should be used to route the email message to the final recipient. The SMTP Server must accept SMTP email.

If you require MAPI delivery (Exchange Server), you will need to enter the MAPI declaration followed by the profile name used to send email.

For example, start Control Panel and select Mail.
Select Show Profiles to view or add an exchange profile.
The name given to the profile should be used here as follows:
MAPI:ProfileName
 

If the SMTP Server has any Anti-Spam features enabled that disable email based on this configuration, the alert will never be delivered and an error will be logged.  Some common errors that you will receive if Anti-Spam or Anti-Relay restrictions are disallowing mail will be in the 5.xx number range.

Errors such as "Relaying Prohibited" will suggest that you contact the mail server administrator to insure that your IP Address, From Address, To Address, and any other information specific to your network are set to allow SMTP email from the ipSentry machine as configured here.

One way around anti-relay (or if you don't know your relay server) is to send mail directly to the mail exchanger of the recipient email address.  You can obtain the mail exchanger address using NSLOOKUP -q=MX domain.name (where domain name is the domain of the TO address) - for example, nslookup -q=MX ipsentry.com

Backup / Redundant SMTP Server Configuration
ipSentry provides the means necessary to attempt delivery of email through multiple SMTP Relay servers to avoid situations where one or more relay servers may be unavailable when the alert is triggered. Simply enter the IP Address of each mail server that ipSentry should try in the order delivery should be attempted, separated by semi-colon.

(example: 10.1.1.1; 10.32.32.2; 10.27.33.3 ...)

In the event the first server is unavailable, ipSentry will attempt to deliver the message through the next relay host. ipSentry will attempt each host until the email is successfully accepted for delivery or until the list has been exhausted.

Note: Redundant SMTP Server option is not available when using MAPI / Exchange.

SSL / TLS - Authentication
You may specify to use an SSL or STARTTLS option by prefixing your mail server entry with <TLS> or <SSL>.  Normally, you will require this setting if your mail relay is secured and requires secured authentication.  The default port for SMTP relay for secured logon is 465.
 

Port
This field signifies the TCP port on which ipSentry should connect in order to deliver the message. By default, this field is set to 25 (SMTP), however, some internal SMTP servers may be setup on non-standard ports which will require that this field be changed to match the listening port of the mail exchanger.

Note: This option is not used when using MAPI / Exchange..

User
When sending mail through an Authenticated SMTP server, you can fill in the User and Password fields appropriately. If you are not using a secure SMTP server, an error 5xx "unrecognized" command may be returned from the server if you enter anything into one of these fields.  Note that the authentication method used is the standard SMTP AUTH and does not utilize Kerberos, NTLM, or SSL.  If encryption is required for the relay, you may want to look at sending directly to the mail exchanger for the recipient domain or if using exchange server, utilizing the MAPI method of sending email.

Note: This option is not used when using MAPI / Exchange..

Password
When sending mail through an Authenticated SMTP server, you can fill in the User and Password fields appropriately. If you are not using a secure SMTP server, an error 5xx unrecognized command may be returned from the server if you enter anything into one of these fields.

From
Enter the email address to be used as the FROM address in the email message. This field must be in standard name@domain.dom address format unless your relay server is prepared to accepted 'default domain' from addresses.

Most problems involving configuration of the Email alert are due primarily to an invalid email address format specified in the FROM/TO fields.  Specifically, send email to "SOMENAME" rather than "SOMENAME@SOMEDOMAIN.DOM".

Note: This option is not used when using MAPI / Exchange - instead, the profiles account address is used.

To
Enter the email address of the recipient (or recipients) of the email message. This field must be in standard name@domain.com address format unless your relay server is prepared to accepted 'default domain' from addresses.


Multiple Recipients
You may specify multiple recipients by simply separating the email addresses with a comma ",".
e.g.: me@here.com, you@there.com, somebody@somewhere.com


BCC Directive
In some cases (especially when monitoring your customer sites), you may want several internal messages to be delivered along with a message to the customer. In this case, you may not want the customer to see the address of the internal support staff, so a BCC (Blind Carbon Copy) can be utilized.

To accomplish this, simply precede the address list with "BCC:". This will cause ipSentry to send a unique email to each recipient in the list without including the actual recipient list in the "TO" line of the received message.
e.g.: BCC:me@here.com, you@there.com, somebody@somewhere.com

Most problems involving configuration of the Email alert are due primarily to an invalid email address format specified in the FROM/TO fields.  Specifically, send email to "SOMENAME" rather than "SOMENAME@SOMEDOMAIN.DOM".
 

Subject
The contents of this field will be placed in the subject field of the email message. All ipSentry keywords used in this field will be translated before the message is sent allowing you to specify crucial information in the subject of the message as well as the message text itself as it relates to the entry and the status of the entry..

Remember, when Alert Success is checked for this alert, the status keywords will be replaced by the actual status in verbose format depending on the state of the device. Use of status keywords in the subject is highly desired for obvious reasons.

Message
.Enter the message you wish to send when this alert is triggered. All ipSentry Keywords used in this field will be translated.

Special Headers
In some cases, you may want to insert special header information into the email message which may trigger special actions upon receipt of these alerts (either by the mail client software or within the mail processing cycle itself).

In order to specify special headers, you would make use of the "<HEADER:..." directive at the top of the message text.

Syntax: <HEADER:HeaderName: VALUE>
Use of this directive would cause an email header "HeaderName" with the value of "VALUE" to be inserted into the headers of the email message before the message is sent to the server.

For instance, if you wanted to set Importance to HIGH and Priority to 1 to insure that special attention was given to these email messages, you might use the following directives:
<HEADER:X-Priority: 1>
<HEADER:Importance: high>

ipSentry expects NOTHING ELSE on a HEADER line.
Also note: You can use the ipSentry keywords in the header fields as replacement values. Be careful not to use a value with a new line character...

Note: Special headers are not used for MAPI delivery.

Alert Status
This group represents the status of the selected alert for the device.
Alert Status - Enable, Disable, Use From Template

Enabled
When this option is selected, the configuration details for the alert are active and specific to this entry.  Other entries may reference this entry.

Disabled
When this option is selected, no alerting of this type will be performed by the selected entry when a CRITICAL result is encountered

Use From
When this option is selected, the alert configuration defined in the selected entry (named in the field next to this selected) will be utilized.  You will use this option when you wish to utilize a group or template reference for alerting configurations.  By clicking on the browse button (...), you will be presented with a list of entries from which you may use their configuration for the specified alert.

When selecting this option, all detail entry fields will be disabled.

Trigger  on recovery count
Recovery Alert Specification
When this option is selected, the alert specified will also be triggered when the system recovers from a critical state.  The most common uses for this option are in email messaging and pager/cell/SMS messaging where you specify the %%mach.state%% keyword in the alert messages.   This way, if a system fails and then recovers, the recipient of the notification would be alerted to this fact.

The value that you enter after this option is the number of successful (OK) results that must occur after a failure before the entry is deemed 'recovered'.   If you enter a value of say three (3) in this field, ipSentry will need to monitor this item at least 3 times, with three successful results before any recovery alert would be generated.  This helps avoid constant UP/DOWN/UP/DOWN notifications.
For add-in alerts, this option will be specific and specified within each add-in configuration entry.

Alert Schedule
The alert schedule provides you with the ability to define the failure count requirements and alert/notification quantities that will be generated.  For example, you may want to be alerted immediately upon failure of a device, but from that point on, if the device is still failing, you may only want to be alerted every 5 failures and receive no more than 6 alerts during any constantly failed duration.   This is exactly where you specify this information.
For add-in alerts, this option will be specific and specified within each add-in configuration entry.
IPSentry Alert Schedule Part

First After
This field represents how many failures (sequential) must occur before any failure notifications are triggered.  A value of 1 will cause immediate notification upon the first failure.  A value of 2 or more will require that number of failures before the first alert is generated.  In the example scenario above, you would enter a 1 in this field.

Then Every
This field represents the number of failures that must occur before further alert/notification actions are taken once the first notification has been processed.   In the example scenario above, you would enter a 10 in this field.

No More Than...
This field represents that maximum number of times that the alert will be triggered during a failure.  If you set this value to -1, there is no maximum.  If you set this value to zero - you might as well just disable the alert.   In the example scenario above, you would enter a 6 in this field so that no more than the alert will be triggered no more than 6 times during a failure.

Alerting Frequency Schedule

Load From
Click this button to load the alert configuration data from another entry in the ipSentry system.  This function comes in handy when you have an alert configured that needs only minor changes for the current configuration.   Once you select a device from which to copy the alert, the configuration of that alert will be populated into the appropriate fields.

Copy To
Click this button to copy the current alert configuration being modified to one or more existing entries.  This allows for the bulk duplication of alert configurations via entry selection.  You will be presented with a list of entries to which you wish to apply this alert configuration.

Test Alert
Click this button to test your alert configuration settings and insure that the basic configuration is correct.

You will be presented with a dialogue requesting whether you wish to test as critical or as a recovery type alert.

Test Alert Dialogue

After selecting to test as Critical or Recover, you will be presented with an active display during the test.
 
Alert Test

Note that when testing alerts, many of the keyword will not contain accurate data since there will be no monitoring data available.  For example, if use the %%mach.trimres_fxxxx%% keyword, the result will either be empty or contain the results of the last live monitoring of the current item.

When testing alerts to insure that keyword structures are correct, the result text should not contain the keyword.   The data will either be replaced with nothing (if no data is available) or it will be replaced with the correct data.

For example: If you enter the keyword %%mach.nameX%%, this is an invalid keyword so it will not be replaced and will be included as it is entered.  However, if you enter %%mach.name%%, this will be replaced. Similarly, if you use a keyword such as %%mach.drive.minfree%% and have the alert tied to a service monitor, the value will be unknown since service monitoring does not use this value - but the keyword will NOT exist in the resulting message data.
 


 



     If you require additional assistance, please visit our on-line support forum at http://forum.ipsentry.com.
 
  Copyright ©1997-2018 by RGE, Inc. - All Rights Reserved
  ipSentry® is a registered trademark of RGE, Inc.
Web Site: https://ipsentry.com
Support Email: support@ipsentry.com