An interesting support case came up recently involving one of the staples of SQL Sentry Event Manager functionality – SMTP support. The basic problem was that all email actions were failing reporting “GeneralFailure”, which is kind of the catch-all for SMTP communication errors. It can often be very difficult to troubleshoot. In a lot of cases it actually requires gathering logs from the SMTP server itself.
In order for SQL Sentry to send notifications via email certain settings are required such as the SMTP Server, the “from” email address and, if necessary, security credentials for the SMTP server. In this case, we were able to send a test email using the simple test from the SQL Sentry console application’s settings tab. This let me know that the SMTP server was working, so I needed to look deeper into what was going on in the software as opposed to what was going on at the SMTP server.
I found a nice article online (here) pointing out that I could enable a trace listener for System.Net.Sockets which would log detailed information about the SMTP conversation with the server. This trace revealed a nasty NullReferenceException that was being thrown every time the SQL Sentry server service tried to call the Send method on SmtpClient.
After some quality time with Bing.com I found this Microsoft Connect record:
Apparently, if you provide a login, but no password, SmtpClient.Send() will not be your friend (prior to .NET 4.0). This turned out to be the problem. Luckily, with a little testing, we discovered that this SMTP server didn’t really need to have credentials provided at all (not from the inside anyway). Simply removing the login got everything rolling again.
What we learn here is just that our impatience for .NET 4.0 is that much more justified. Thank goodness Brooke Philpott is already working toward targeting .NET 4.0 with SQL Sentry. I’ll save the details on that for him though. ;o)
Until next time,
-Jason R. Hall