Mel Lota's Weblog

Silverlight, SharePoint and other related technologies

Sharepoint 2007 task notification alert emails not working

"Where are my alert emails!" I hear you cry. I've been repeating these same words for a number of days now and I've finally managed to get them working so I thought I'd share my solution.

Scenario: 
I've 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 I've never seen them working in the development environment. Interestingly all the standard scheduled alert emails were working fine (ie. if you were to subscribe to a list), it was just the task notifications from the workflows which were not.

Solution:
First thing I 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 I checked were the email settings for the site in Central Admin which again all looked fine. The development site is using local SMTP, so I 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. I also checked that the Timer service was running correctly and under the right account in the windows Services, which it was.

Next thing I checked were the database tables, after I read about the same problem in this newsgroup posting. 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)

I 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 I believe the content database had been restored from a live copy a while ago, and the references obviously had not been updated automatically. So I cleared out each each one of these tables and re-tested the workflow. This made a bit of progress as I 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, I was still having no luck whatsoever at getting these alert emails working so I reverted back to trusty Google for some more answers. I 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 I 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 I spent many a frustrated hour over this one :)

Comments

Robin said:

# October 16, 2007 4:09 AM

SharePointed » Archive » Alerts not working *all the time* said:

Pingback from  SharePointed  » Archive   » Alerts not working *all the time*

# November 17, 2007 6:06 PM

Dylan said:

I am having a strange issue that seems related or close to what you were experiencing. I am not receiving email notifications when tasks or action items are changed. I have a MOSS 2007, SQL 2005 environment where the following is happening:

1. Alerts that users themselves setup are working fine

2. The eventcache,eventlog, and immedsubscriptions tables are logging all the alerts and task notifications, even the ones that I do not receive an email for.

3. When I use my user account to create a task and assign it to myself I receive the email notification that I have a task assigned to me.

4. If I update the same task with my user account I do not receive an email notification that the task has been changed. The eventcache and eventlog tables do have an entry for the change though.

5. If I update the same task with the service account that is a member of the farm administrators group then I do receive the email notification that the task has been changed.

This seems to be a permissions issue but I have tried everything I can think of and still no change. I have an open case with Microsoft but they have yet to provide me an answer. Any ideas or help is greatly appreciated. Thanks.

# November 20, 2007 12:26 PM

mlota said:

Hi Dylan,

Yes it does sound like a permissions related issue, can't say I've come across anything like that myself. Presumably if you increase the priveleges on your standard user account, or add it to the admins group, you are getting the task update emails?

# November 21, 2007 9:01 AM

Tina said:

Hi Mel,

I have the same issue.

I did what u did and am getting the entries in EventCache table but not in ImmedSubscriptions Table and ofcourse emails are not coming as well.

Something interesting in my case is that it was working perfectly alright 2 days ago but is not working since.

Thanks alot.

All help is highly appreciated.

Tina

# November 21, 2007 8:57 PM

mlota said:

Hi Tina,

Have you restored any database backups to your environment from a different server recently? I think that is what initially caused the problem for me. Have you tried all the steps I mentioned in my post? If this is still not working drop me an email with some further details and I'll have a look.

Thanks

# November 22, 2007 7:47 AM

Tina said:

Hi mel,

Thanks for ur reply.

No I have not restored any database from any other server.

And yes I followed al the steps you mentioned and run stsadm command as well, but no good.

The thing I observed, and mentioned in previous email as well is that the content database is getting the entries in EventCache table but not in ImmedSubscriptions Table for the alerts.

Also my timer service is not start and doesnot give me an option of starting it.

The possible cause for my problem could be, I wos working with Windows services on the box. and added the windows user login to the content database for my windows service to work.

Thanks

Tina

# November 22, 2007 6:39 PM

Dylan said:

Thanks for the response. Adding my account to the farm administrators group did not change the issue. Is there a list of certain Hotfixes that should be installed no matter what because most of the ones I see I am not experiencing those issues. Thanks again.

# November 26, 2007 5:31 PM

Phani said:

Hi,

We are implementing the IAlertNotifyHandler to modify the alert message.

If we trigger alerts on multiple documents; we are getting the wrong item id from the SPAlertHandlerParams.

To get the item id we are using the below syntax

SPListItem alertitem = list.GetItemById(ahp.eventData[0].itemId); where "ahp" is SPAlertHandlerParams object

But the itemId is not coming correctly.

Do let us know how to solve this.

Thanks

Phani

# December 27, 2007 8:32 AM

Subodh said:

Thanks for great help.... This works for me. But I don't know what that -LCID means and how to get it.

# January 9, 2008 6:03 AM

mlota said:

Hi Subodh,

The LCID simply refers to the locale ID, in my case I am using the locale ID for the UK which is 2057. For a full list of id's please see the following link:

www.microsoft.com/.../lcid-all.mspx

Hope this helps.

Thanks

# January 13, 2008 12:20 PM

Nita said:

Hi Mel,

I am facing a similar situation. We are working on alerts set for changes on a document library. when the alert is set, everyone recievs a confirmation. But only some of us recieve alerts when a change is made in the document library. Since this problem does not persist for all the people we put into the alerts list. Woudl doing somehting in the content database help? I am still lookin out for a possible solution. Am still reading on it... please do let me know if you might be able to help.

Regards,

Nita

# January 16, 2008 2:24 AM

Wade P said:

I just wanted to say thank you for posting this information. I would also like to add something I noticed incase it might help someone else.

After running the stsadmin command posted above, I tested the workflow alert which still failed. I then remembered that I recently added an alternate access mapping for testing a different issue. That URL was https://servername . After removing that mapping, the only remaining mapping was my DNS https://dnsname.domainname . At this point with only one mapping, I tested the workflows and they worked. After looking in the database tables listed above on this page, I saw log entries for the https://servername URL. Hopefully this will help someone. Thanks again. So, I can tell you two things for sure that were done to resolve the issue for me. 1. run the stsadmin command, 2. remove the additional access mapping. As a note, my site is forced through a proxy, so the URL plays an issue. It may not for you.

# January 22, 2008 1:13 PM

Hymen S said:

My workflow/alerts email issues must have everything to do with permissions.  All the right entries are being made to the databases.  Members (Contributors) don't get the alerts of doclibs, but Owners (Full Control) do.  

In the EventCache, there are fields for "EventData" and "ACL" that show "Binary data" for the failed alert messages.  Successful alerts show "NULL" in these fields.

# January 31, 2008 11:32 AM

Dirk said:

I just had the same problem after migrating the app and SQl servers.

The ImmedSubscriptions still held information relating to the old servers.

Deleting all alerts has resolved this.

# February 20, 2008 6:44 AM

Lem said:

If I delete the entries in the tables listed above am I deleting the alerts or am I

deleting the actual task the alert pertains to?

# February 26, 2008 6:13 PM

Dan said:

Thanks for this. It worked great for me and saved me lots of frustration after numerous hours of troubleshooting.

# February 29, 2008 10:35 AM

mlota said:

Lem; When you delete the entries in the tables you are just deleting the scheduled alerts *not* the actual tasks themselves

Cheers

# February 29, 2008 10:45 AM

Rob said:

This worked for me. THANKS!!!!!  I cleared out those tables then ran that command then it started working.  USA LCID=1033 btw.

# March 12, 2008 11:25 AM

Pieter said:

I also had this problem and followed your instructions, but it still didn't work untill I found out I was settting my alerts on a site that was created on the sharepoint administration site (don't ask my why :)

Since templates are not designed to be created on the central administration page email alerts were not configured to run even if you carry out the correct procedure in enabling it

I tested it on another site and it worked

# March 20, 2008 1:56 PM

PhilB said:

Calling All SPS Experts:

Here is one Microsoft techs could not figure out.

1 - List Alerts work

2 - Task Notifications don't get sent

3 - SQL EventCache shows an "EventTime" that is 4 hours ahead (yes I checked the servers time and zone).

I tried all the fixes here and elsewhere. Yes I set the fix to the Alerttemplate.xml to LCID of 1033.

I am really tapped out on this one. Where the heck is this time coming from!!!

All suggestions welcome.

Thanks,

PB

# May 8, 2008 11:41 AM

Steve said:

Maybe someone can help me.

I have a several task lists that will not send alerts when configured to send the alert when the item gets assigned to me. If I configure the alert to send all changes, I receive them just fine.

The faulty alerts show up correctly in the immedsubscriptions table and in the eventcache and eventlog tables. The eventdata column is even getting NULLed as it is supposed to when the timer service runs. Am I missing something? What is the logical next step?

# May 21, 2008 1:15 PM

Henk Dirksen said:

Helps me out, thanx a lot kid. We saved many hours

# May 28, 2008 4:05 AM

Sopa said:

Hi,

I have a different problem, and I hope someone can help me with it.

I have a custom workflow attached to a custom list. The workflow is supposed to send an email to a manager, when a criteria is equal to true.

The problem is that for some reason two identical emails are sent. And I do not know why.

Thanks

//S

# July 29, 2008 4:28 AM

Gagneesh said:

We have a similar issue though it appears to be a SharePoint limitation on custom lists. We have a custom list created by importing a spreadsheet (MOSS 2007). It does not have the e-mail notification capability as available with the SharePoint Lists like "Issue Tracking".

Requirement: Send an email to the "Assigned To" person on the list. This feature exists in the Issue Tracking (MOSS 2007).

Is there a way to either:

Enable e-mail notification for a custom list (created based on an import from an excel spreadsheet).

OR

Import data from Excel spreadsheet to a SharePoint empty List (basically the list is created from Issue Tracking template and columns added - it then has the e-mail notification features).

OR

Move data from a SharePoint custom list to a SharePoint empty List (basically the list is created from Issue Tracking template and columns added - it then has the e-mail notification features).

OR

How to create a simple workflow to just accomplish sending the email whenever the "Assigned To" field is changed?

Further when creating a custom list, be very sure that the title field is assigned to the correct column. When importing data, SharePoint assigns one of the initial columns in the spreadsheet to be the "Title" column. This is the column which will be appended to the email title for any alerts defined on the List. In our case, it assigned the incorrect column as the Title column and there does not appear to be an easy way to change it (except for exporting the data to excel and re-creating the list again but one will lose the versioning and timestamp information with the updates/comments to the issues).

I am more of a beginner SharePoint user and would prefer if this can be accomplished with no coding or very little/simple coding. Any helpful comments will be highly appreciated.

Thanks!

Gagneesh

# August 21, 2008 4:16 PM

Arjunan Ramachandran said:

Your solution worked a charm! Thanks very much!

regards

Arjunan

# September 22, 2008 10:14 AM

John Palmer said:

This article definitely pointed me in the right direction.  My workflow tasks stopped sending emails after I enabled SSL and updated the alternate access mapping to use https.  I found that the value in the SiteUrl column in ImmedSubscriptions still had http rather than https.  I added the missing "s", an IISRESET, and restarted the timer service.  Email is working again!  Thanks!

# October 16, 2008 4:56 PM

T-Mac said:

I have a similar issue except it's just the opposite in that multiple emails are being generated. Could this be a matter of just needing to some of my database tables mentioned ie ImmedSubscriptions

# October 16, 2008 8:05 PM

Dev said:

Hi,

I have 2 custom list work flows. Emails are sent to recipient from one of them but does not work from the latest custom list that was created. Please advice.

# November 27, 2008 3:06 PM

ebonato said:

Hi,

If you have backup-restored your sharepoint site to a new server farm, check-out this KB at

support.microsoft.com/.../942989

Some timer jobs definitions aren't restored, then task mail alerts becomes broken (ImmediateAlerts).

# December 11, 2008 6:54 AM

David S said:

I have the same issue as Hymen S above.  I ran the STSADM command, and still no alerts.  However, the ACL and EventData values are NULL, as with successful alerts for users with Full Control.

If I empty the two tables, EventCache and ImmedSubscriptions, I would have recreate all the user alerts, correct?

# December 30, 2008 4:50 PM

Chris said:

The issue I am having is more in the user and groups. When a Site collection is created and you go to add a member it creates the groups with permission and the options to E-mail the notification. upon receiving the email with the name of the Site with the link  it doesn't display the Full path URL to the site. do you think Running the stsadm -o updatealerttemplates -url http://testserver -f "c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML\alerttemplates.xml" -LCID 2057

will help this situation.

# January 15, 2009 6:07 PM

Tom Jreige said:

Hi Everyone,

I have fixed the timer problem for immediate jobs.  So when changes are made now on a document etc, i am receiving immediate alerts to the change.  However, scheduled jobs are not working.  I have reconfigured the schedule times for Daily and Weekly jobs  but they are not showing up in Timer Job Descriptions in the Central Admin like the Immediate jobs show up?

Any ideas?

# February 9, 2009 5:22 PM

Nate said:

Mel, I stumbled onto this page after hours of searching.  All I have to say is if you are ever in NC I owe you a beer.

# February 12, 2009 3:57 AM

Microsoft Office Sharepoint Server 2007 said:

Purpose : To get notified whenever something new gets indexed, based on a search term you specify. Say

# February 24, 2009 3:27 PM

Chris S said:

John P, I had the same issue and I came to the same conclusion.  I changed the host header on my SharePoint server and the task e-mails stopped coming.  I updated the SiteUrl column in the ImmedSubscriptions table (A big no-no by Microsoft standards I know, but didn't have another way around it)

After that update alone, not even an IIS restart needed and the task e-mails started working again.

Does anyone hav a way to trigger the e-mails that I missed while the host header in the SiteUrl was wrong?

# April 1, 2009 5:21 PM

Vandana said:

Nice information regarding troubleshoot the alerts issue. I had a problem where only initial alerts were send to but after that no alerts mail were send.

Doing research I found this article that help me resolve the issue alerts. Just thought of sharing it with you.

www.ekhichdi.com/.../moss-2007-alerts-not-working

Regards

# April 2, 2009 6:17 PM

Catherine Wright said:

I had the same problem. It got resolved when the SharePoint administrator installed a Hotfix just released by Microsoft. You can find more information in the Microsoft Knowledge Base - Article 946517 KB.

# April 22, 2009 1:35 PM

Lulla said:

When a user assigns a workflow task to another user, the email only works if the user asssigning the task is part of administrator group, if the user is not then the email isn't sent.

Hence emails are working but only if from admin group anyone else and it disappears, no errors .

I thought emails are sent using the same account irrespective of who the assignee is directly from sharepoint and not using users credentials to email from within sharepoint.

Environment MOSS, Windows Server 2008

Any help greatly appreciated

# May 14, 2009 5:49 PM

Reuben said:

Same problem. This post fixed it for me.  I tried tons of other before I cam across this one!

objectmix.com/.../297830-re-users-notified-alert-creation-but-do-not-receive-alert.html

# June 17, 2009 4:53 PM

Paul said:

I have users who are signing up for alerts on a site and it is saying they are successful. However, they are not receiving alerts and then when I go to view there alerts they are not even listed as registered?

# June 24, 2009 8:37 AM

Engrooving said:

Fixing Sharepoint 2007 alerts

# July 10, 2009 5:26 AM

naren said:

The ACL and EventData values are NOT NULL in my Event cache  table. What should I do now?

# September 3, 2009 8:50 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)