On some occasion, we can encounter the fact that the Sharepoint Alert that we setup does not work. Even though we have set this up properly on Sharepoint Central Administration, it does not fire the alerts properly. Why can this happen?

This article will discuss the scenario that you may encounter and the solution offered to tackle this problem. We certainly hope it will benefit you who are using Sharepoint as a hosted solution/service. In case you are looking for European Sharepoint Hosting Provider, you can take a look at HostForLife.eu. Price starts just from as low as €6.00/month and you can have your Sharepoint site hosted with reasonable features!

We have been working with a MOSS site which has three environments; development, staging and live. We have a number of custom workflows which were created using Workflow Foundation and InfoPath for the forms. Each of the workflow tasks should automatically send out a task notification email whenever the task is reassigned to a different person. This has always worked fine on staging and live environments, but we have never seen them working in the development environment. Interestingly all the standard scheduled alert emails were working fine (i.e. if you were to subscribe to a list), it was just the task notifications from the workflows which were not.

First thing we did was go through the usual process of checking the log files and windows event viewer for errors which yielded no significant results. Next thing we checked were the email settings for the site in Central Admin which again all looked fine. The development site is using local SMTP, so we checked if the emails were getting generated in the ‘DROP’ folder in the mailroot. The scheduled alert emails were getting generated in here fine, but the task notifications were not. We also checked that the Timer service was running correctly and under the right account in the windows Services, which it was.

The following four tables in the content database contain entries related to the alert emails:

ImmedSubscriptions (Stores the alerts for emails that are sent immediately when changes occur)
SchedSubscriptions (Stores daily or weekly scheduled alerts)
EventLog (This table contains events for which only non-immediate alerts exist)
EventCache (This table contains a list of site events for which users have requested alerts. WSS inserts events into this table as they occur)

We checked in these table to see if information about the alerts were being inserted and discovered that in the ImmedSubscriptions and EventLog tables there were actually entries which were related to the live server, as we believe the content database had been restored from a live copy a while ago, and the references obviously had not been updated automatically. So we cleared out each each one of these tables and re-tested the workflow. This made a bit of progress as we could now see that the alert information was getting inserted correctly into the EventCache and EventLog tables. However the ImmedSubscriptions table was still not receiving information about the alert.

After some frustrated iisresets and restarts of the timer job service, we were still having no luck whatsoever at getting these alert emails working so we reverted back to trusty Google for some more answers. We found this blog, which although not directly related, provided the winning answer. Updating the alert templates. After running the following stsadm command on the development machine, the task notification alert emails automagically started working again woohoo!

stsadm -o updatealerttemplates -url http://testserver -f “c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML\alerttemplates.xml” -LCID 2057

So we can assume that the problem transpired from a restore of the content databased from a different server which somewhere along the line maintained some references to the original server. A clear out of the relevant databases and re-registering the alert templates seemed to solve the problem for me.

Hopefully this comes in handy for somebody else, as we spent many a frustrated hour over this one 🙂