Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Emailed recipients for alerts based on variables (?)

Hey everyone,

I was wondering if we can do the following:

We would like for an Advanced Alert within NPM to email a different email address, depending on a node's group membership when it goes down.

So, for example, if a core switch in New York goes down, the alert is sent to NetAdmins-NY@domain.com; conversely, if a core switch goes down in Miami, the alert is sent to NetAdmins-MIA@domain.com.

Does that make sense? One alert defined, but many different email actions available, based on group node membership, within that alert.

Please let me know. Thank you!

Find more posts tagged with

Accepted answers

Well, there's not exactly this functionality inside single alert definition

But you can specify variable inside mail TO which is evaluated for each node. If each your node has correct information filled, it's done automatically.

This will evaluate property Contact on node where alert occurred.

Or You can of course create VBS (or run external program) where you add own logic and send email via CDO or other engine.

All comments

FormerMember

Anyone?

Hi,
you can create extra alert for each mailing group. For instance

Create alert when node goes down for Miami only = specify Location condition to MIAMI and assign appropriate alert action.

Alert for New York can be created as a Copy of this one with changed location condition and new actions.

FormerMember

Hi ET,

Yes, this is indeed what we understand. The problem is, we can't figure out a way to send alerts to different email addresses depending on the Location, defined as a trigger condition.

So in other words, the trigger condition might look like this, logically:

IF Location=Miami

THEN email networkadmins-miami@domain.com

IF Location=NewYork

THEN email networkadmins-newyork@domain.com

Does that make sense? We wish to have all of these defined inside one alert itself -- and so that we can avoid creating alerts for each email recipient group.

Thank you for your help.

Well, there's not exactly this functionality inside single alert definition

But you can specify variable inside mail TO which is evaluated for each node. If each your node has correct information filled, it's done automatically.

This will evaluate property Contact on node where alert occurred.

Or You can of course create VBS (or run external program) where you add own logic and send email via CDO or other engine.

epenney

This proposal of using a custom field ie: CONTACT for the affected node, is that if you want to alter CONTACT based on WHO is oncall, then you need to update/edit CONTACT field for ALL nodes - this method just doesn't scale for folks with hundreds / thousands of nodes.

Another thwack thread comes close, but still misses the mark.

The following is just brainstorming an idea, based on inspiration from various threads, and analyzing our own needs within our organization -

I think a separate orion table is required to permit customers to have flexibility with managing emailing of alerts, to avoid having to edit custom fields for hundreds, thousands of nodes every time oncall rotation changes. For example, create a new table "AlertEmailManager", custom or prebuilt fields "AlertEmailto1", "AlertEmailto2", "AlertEmailto3" etc. You can then create a custom view to permit a non Orion administrator, ie: manager, helpdesk etc, to edit these custom fields in this special table "AlertEmailManager". The advanced alert, would then reference email recipient as: ${AlertEmailManager.AlertEmailto1} for example.

mxmlaz

Could you not accomplish this with an AD Group that everyone has access to? OnCallA, OnCallB, etc., where the group gets updated and no change to the alerts would be required at all, that way you could delegate the permissions to modify those AD groups to anyone who would need to make an update.