Troubleshooting SMTP Virtual Server Settings in Windows Server 2008

One of our development servers today needed to be configured to send emails from our web site to users and staff within the organization. We knew that the application was coded properly, as the email piece was functioning on other servers using the same code base.

Within Windows Server 2008, you must first add the IIS 6.0 Manager Components. We had this piece installed and configured using the IP of the web server and the default port of 25. Everything looked fine, but for some reason email wasn’t sending.

What I really needed was a way to troubleshoot the problem. I couldn’t step through the code, so I needed a way to determine what about the SMTP virtual server message delivery settings were incorrect. I then found a helpful KBA on troubleshooting via telnet.

By using telnet and following the steps in the KBA referenced above, I was able to see at which step during the email process the failure occurred. Making an EHLO command, the failure showed a domain different than what I was expecting. Instead of “”, I saw the name of the server. Going back into the SMTP virtual server properties, I quickly realized where the problem was.

The SMTP Advanced Delivery Options required domains for both:

  • Masquerade domain
  • Fully-qualified domain name

After changing the settings above, then retracing the steps to telnet back into the server and send an email, I then got a successful “Queued message for delivery” status.

Telnet test SMTP settings blur

One last note… make sure your SMTP Service is set to start up automatically. Ours wasn’t. For every IISRESET, the SMTP virtual server would stop and remain stopped until manually started again.

SMTP Service Automatic Startup

Set the SMTP Service to automatic startup


Sitecore OMS Error: Overwhelming Change Notification

Today, our websites generated a stack trace error with an “Out of Memory Exception” message for the whole world to see.

Immediately looking at the IIS logs, we discovered 500 internal server errors over a 3-minute time span. Using the time stamp generated by IIS, I then compared against the error logs created by Sitecore (typically in [website path]\data\logs).

Looking at the Sitecore logs, sandwiched between two Analytics errors, I see the following:

4304 14:29:31 ERROR Failed to insert Analytics data
Exception: System.Data.SqlClient.SqlException

4276 14:30:18 INFO  **************************************************
4276 14:30:18 WARN  Sitecore shutting down
4276 14:30:18 WARN  Shutdown message: Overwhelming Change Notification in C:\inetpub\wwwroot
Overwhelming Change Notification in C:\inetpub\wwwroot
HostingEnvironment initiated shutdown
CONFIG change

4304 14:30:26 ERROR Failed to insert Analytics data
Exception: System.Data.SqlClient.SqlException

Having no idea what “Overwhelming change notification” meant of what it was referring to, our team contacted Sitecore directly. Turns out that this error is a result of a bug in OMS 1.0.1 (running under Sitecore 6.1). An unhandled exception appeared in the Sitecore OMS module due to improper handling of the AnalyticsLogger class. Their support team were able to reproduce the issue and generate the following error message related to the one triggered above:

ERROR Unhandled exception detected. The ASP.NET worker process will be terminated.
Exception: System.IndexOutOfRangeException
Message: Index was outside the bounds of the array.
Source: mscorlib
   at System.Collections.Generic.List`1.Add(T item)
. . .

Currently, the only work around for this is to disable error logging for Sitecore OMS by following the steps below:

  1. Open the \Website\App_Config\Include\Sitecore.Analytics.config file.
  2. In Sitecore.Analytics.config file, comment the following pipeline’s processor:

    <!– <processor type=”Sitecore.Analytics.

    Pipelines.HttpRequest.StartDiagnostics, Sitecore.Analytics” patch:after=”processor[@type=’Sitecore.Pipelines.HttpRequest.StartMeasurements, Sitecore.Kernel’]” /> –>

Tough choice here…. Keep your OMS error logging or take your chances with random OMS exceptions?