Submit a ticketCall us

AnnouncementsTHWACKcamp 2018 is here

2018 is the seventh year for THWACKcamp™, and once again we’ll be live October 17 – 18 with packed session tracks covering everything from network monitoring and management, to change control, application management, storage, cloud and DevOps, security, automation, virtualization, mapping, logging, and more.

Register for online sessions.

Home > Success Center > Server & Application Monitor (SAM) > SAM Documentation > SolarWinds Guide to Monitoring Exchange > Best practices for configuring Exchange alerts

Best practices for configuring Exchange alerts

After you have configured your SolarWinds products to monitor Exchange, alerts are triggered when any conditions are outside of the specified parameters. SolarWinds provides a number of preconfigured alerts, many of which are enabled by default. To effectively monitor Exchange, you must determine which alerts should be enabled, what thresholds are appropriate for your environment, and who should be notified (or what action should be taken) when an alert is triggered.

Use the following guidelines to configure alerts for your Exchange environment. For more information about working with alerts in the Orion Platform, see Create and manage alerts.

Guidelines for enabling alerts and configuring thresholds

Alerts should reflect a need for action or further investigation. If alerts are not configured correctly, system monitoring becomes noise and support teams begin ignoring alerts. Important alerts can be missed if they are buried in a sea of insignificant alerts. Use the following guidelines to avoid alerting noise in your Exchange environment.

For additional tips and techniques, see Reduce alerting noise.

  • Let the system run for about two weeks to determine what "normal" is in your environment. Do not send email notifications during this time. When this time period is up, then determine which alerts should be enabled and what the thresholds should be.
  • Use baselines to determine threshold values.
  • The advice for some alerts explains that the condition is not a problem unless a second condition also exists. Instead of enabling these alerts, create a custom alert that is triggered only when both conditions are met.

Guidelines for testing alerts

  • Test alert notifications using your own email address before sending notifications to a mailing list or group.
  • Test alerts during non-business hours. If your organization is global, determine when the lowest usage times are and test during that time period.
  • In some cases, email might not be the best way to test alerts. Consider writing a syslog message or writing to the Windows event log.

Guidelines for sending notifications

  • Limit the number of people you send alerts to and the number of times the alerts are sent.
  • If an alert sends an email, don't include log files in the email. The log file can be very large, so it can consume a lot of storage and slow down the email delivery.
  • Consider sending alert emails to a group or a list of individuals rather than a shared mailbox. In many organizations, not everyone checks shared mailboxes regularly. Or, send notifications to your ticketing system.
Last modified