This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Alert: " The transport failed to connect to the server. "

I am seeing the following error in NPM when trying to send emails out as an action on an alert:  The transport failed to connect to the server.

This seems to have started since upgraded to NPM 11.5   .

I have individually tested the SMTP server I use for this in NPM, and it does successfully send test emails out.  It just seems to fail only when the email is triggered from an alert.

any one come across this as well?

  • Any chance your alerts are set to use an SMTP server that is different from the one configured globally?  Or perhaps you have authentication parameters wrong?  Do you have anything set in Admin --> Reports and Alerts --> Manage SMTP servers?  If so, is it different from what is specified in an alert definition?

    Just a few things to check.  Maybe one of those settings got defaulted during upgrade?

    I have also seen those errors when HIPS blocked my application (HIPS admins had to whitelist the executable processes that were allowed to send mail).  And when firewalls broke my connectivity to SMTP server.  In those situations, it's helpful to determine if the mail environment ever saw the attempt (vs. something breaking at the SolarWinds server keeping SMTP traffic from leaving).

  • In working with 11.5 today we were unable to fire off a test email from the default SMTP settings despite everything being configured correctly.  Trial and error showed that turning off the firewall on the SMTP server allowed the test email to go through – great!  Digging through Thwack there was a reference to add an exclusion for AdvancedAlertEngine.exe (pretty sure that was the executable…) which we did and fired the firewall back up.  Once again no emails getting out.

    We started looking at the Windows Event logs on the SMTP server and we could see where a rule was firing (blocked by port blocking rule… prevent mass mailing worms from sending mail) but not which executable was responsible.   Digging further into the actual log files for the McAfee application itself pointed to W3WP.exe as the culprit.  Added an exclusion for that particular executable allowed us to configure and send email from the NPM default SMTP server in settings.  Test firing an alert however resulted in another fail.  Looking back at the same McAfee log file showed another executable as being blocked, this time SolarWinds.BusinessLayerHost.exe.  Excluded this one as well and now all seems fine.

    TL;DR – With the new web based alerting if the firewall on the SMTP server is aggressive you may need to add an exclusion for W3WP.exe to send test emails from the default SMTP config area.  Additionally you may need to add SolarWinds.BusinessLayerHost.exe as well for the Alerts to be able to send email.  This is different than the executable you had to exclude when the Alerting engine was a standalone.

    Hope this helps!!

  • I think you are pretty close Larry,

    I actually opened a support case for the error and after sending the logs,. they found that McAfee on on NPM server was treating smtp traffic from it as malicious and blocking it, whereas testing the smtp server itself from solarwinds went through OK.

    here's the deal:

    Please try the following to isolate the error:
    Disable all Mc Affee services.
    Also,
    -Select the Viruscan Console
    -Double click access protection
    -Under Ports to Block uncheck "Prevent Mass Mailing Worms from sending mail (PORT 25)"

    Next, make sure the following path are excluded from Anti-virus scanning:


    http://knowledgebase.solarwinds.com/kb/questions/2124/What+files+and+directories+should+I+exclude+from+antivirus+protection+to+optimize+performance+and+to+ensure+adequate+file+access+for+Orion+products%3F

    it fixed my problem