I've looked at this issue numerous times from a variety of standpoints..
I'm also mostly inclined to use *nix for outbound mail services on any given network, even though we use an exchange server predominately.
Were it me, I would create a VM to handle outbound SMTP for my monitoring system. With the myriad of things that can cause Exchange to fail to function as an MTA or MUA, I need to make sure my alerting system handles SMTP as easily as possible, using the standard DNS records look up for delivery to my corporate email.
The basic steps are:
1) Load *nix variant of your choice into guest VM under hypervisor of your choice. Once built, shut it down and take a file copy of the VM image(s).
2) If you're using any of the commercial VM applications, you probably have basic hardware failover events automatically handleable. Otherwise you can monitor it and fail it over manually.
While alerting is high priority for me, it's not mission critical, there is always the web site, so my current, not to be confused with permanent local architecture is a single *nix machine that could be recreated very easily for outbound mail. (Less than 60 minutes including OS load on new hardware)
Another option is to run it to a round-robin DNS entry. Exactly half the lookups *could* fail to make a connection, but half would make it through. I do not know if the MUA built into the Orion NPM is smart enough to retry. I suspect not based on what I've seen in terms of it's behavior.
A better option is to run some sort of HA for your outbound SMTP. While the VM approach is a very easy method to achieve that, you can also hide mail behind some sort of software load balancing or HA. There are a plethora of options to choose from, but I'd point at Linux HA on some very inexpensive hardware with little in the way of disk/cpu/ram. For $2-3k you could have an extremely robust solution on commodity hardware.
Yet another option if that's not attractive to you, is to buy Linux on commodity hardware from a vendor who pre-packages the configuration for you as a mail appliance. Buy the smallest cheapest ones you can, because it's likely you will never tax them. You do not need the comprehensive scanning features an externally facing MTA needs like SPAM and virus scanning because you're just using it as an automated systems relay. I actually *do* virus check my outgoing mail with clamav-milter on sendmail, but it's not a requirement for Orion's outbound, windows though it may be.
Note: I have no sexy SolarWinds software-based solution. Certainly a primary and secondary outbound MTA and MTA global configuration that is defaulted for all email alerts would be better than setting a single MTA for every alert. All of my solutions have to do with architecture outside of Orion NPM/NCM, etc.
No redundant mail servers that i know of built in. You could just load the SMTP service on the Windows Server box that runs the IPMonitor load itself and let that box send out the emails. If your exchange is down just make sure you also send alerts to an alternate external account. I use a blackberry so I have alerts sent to my exchange account and my blackberry account so i dont have to always rely on the exchange server being up.
@jwashburn: We're using email for standard alerts but for critical alerts (ie. ERP system down) we employ out-of-band alerting via a GSM modem. If our mail system, SMTP gateway or ISP connection go down, we still get alerted.
May I ask what make and model of GSM modem you are using with ipMonitor?
Thanks in advance.