This is one article in the larger Troubleshooting SharePoint Alerts guide

Problem

Task lists can send an email notification when a task is assigned or changed (Settings > Advanced Settings > E-Mail Notification).

If you modify the Assigned To column of the task list to “Allow multiple selections” then the email may be sent to random, incorrect recipients – some names will be crossed out (strike-through) in the email.

References

• Random emails getting sent out when changing “Assigned to” to allow multiple items

• Email Notifications and Alerts problem

To Resolve

This is a known issue and was fixed in Windows SharepPoint Services 3 Hotfix (KB948945 21st February 2008)

“On a SharePoint Server 2007 site, you modify a task in a task list. When you do this, users other than the users who are assigned to the task receive the notification e-mail message for the change.”

This fix is believed to have been included in

• WSS3 SP2 (April 24th 2009)

This guide will help you troubleshoot why you are not getting the Alert emails you expect from SharePoint.

There are a multitude of problems and we can’t possibly cover every possibility here, but following this guide should help you resolve the most common problems.

The wild cards in this process are spam filters and email client processing rules (e.g. file anything that comes from this address or with this subject in this folder) – so it’s worth ruling those out before going any further.

The guide is split into the following main sections

1. Are you getting any emails from SharePoint?
2. You are getting the initial “You have successfully create an alert…” email, but no subsequent emails
3. You are getting alert me emails but the information in them is incorrect (they contain the wrong urls, they go to the wrong people etc)

(Part 2 coming soon!)

Are you getting any emails from SharePoint?

The first stage is to determine if the problems are caused by SharePoint or other parts of your email infrastructure.

When you setup an email alert you receive an immediate “You have successfully created an alert for…” confirmation email.

TODO

• If you do not receive this then continue with this guide, its likely that the problem is not within SharePoint, but some other part of your email infrastructure.

If you receive this email reliably we still can’t be sure that your email infrastructure is setup correctly as the confirmation email is sent from a

then we know that the email infrastructure is setup correctly and any further problems are to do with SharePoint.

(Note – if you are not familiar with SMTP and related technologies you might want to review this SMTP Primer before going any further)

If you receive this for some users but not others then verify :-

• That all users have a valid email address in SharePoints user list ( Site Actions > Site Settings > People and Groups > All people, find the user and check the Email field)

• That this user’s email is being delivered successfully from other sources?

• Do emails to users on the internal domain get delivered and external email addresses fail (or vice versa) – in which case you need to look in detail at your email infrastructure to determine where the problem lies. 
  • If internal emails are getting through but external ones are not then use the SMTPDiag utility to verify DNS configuration on your SMTP server are not stopping external delivery.

If you receive this email intermittently

And are running a server farm then you may have a problem with the configuration of one of the servers in your farm so continue with the “you do not receive this email” section, applying the troubleshooting steps to the servers individually where appropriate.

If you do not receive this email

• Check the email settings in SharePoint central administration are correct (SharePoint Central Administration > Operations > Outgoing Emails Settings) – note the Outbound SMTP server, From and Reply To addresses.

• Run a tool like the SMTP Test Tool or Telnet on your SharePoint server to send an email via your SMTP server.  Be sure to use the same settings you noted above. Check :-

• Is there anything that may block SMTP transmissions on port 25 (common to stop mass mailing worms/viruses), for example
  • A firewall running on or in between the SharePoint server and the SMTP server
  • Antivirus software (viruses and other malware often send large numbers of emails)
  • Remember that if your security blocks SMTP transmissions based on process or account then test tools such as Telnet or SMTP Test tool will be a different process and will often be running under a different account to SharePoint.
• Does the SMTP server permit connections (relay’s) from your SharePoint servers – including all the Web Front Ends (WFE) and Index server?
  • This post shows how you can configure Microsoft Exchange to accept connections from SharePoint
• Is the SMTP server configured to deliver emails or relay them to another SMTP server and is it working?

• Does your SMTP server require a username/password or SSL? In which case you will have to install something like Windows IIS SMTP server (locally on or another server), set SharePoint to deliver emails to this and then deliver emails directly or relay those emails onto your main SMTP server. This guide shows how you would set IIS SMTP server to relay messages from SharePoint to smtp.google.com as an example.

This is a very simplified primer giving you just enough knowledge to follow the Troubleshooting SharePoint Alerts article , it’s neither complete or totally accurate so you may want to read more complete guides.

• Simple Mail Transfer Protocol (SMTP) is used to transport and route emails.

• A sending Message User Agent (MUA) such as your email client or SharePoint sends an email to a Mail Transfer Agent (MTA) aka outgoing mail server.

• The MTA (such as Windows IIS SMTP server which may be running on the same server as SharePoint or a separate server) may in turn ‘relay’ or pass all messages on to another MTA.

• In a large organisation there may be multiple relays and emails to different destinations may be routed through different paths of MTA’s – you can see the path an email has taken if you look at the Internet Header (in Message Options in Outlook) for the “Received: …” lines.

• For an external recipient a delivering MTA will take the destination domain (@yourdomain.com) use a DNS lookup to find the Mail Exchanger (MX) record for the destination domains incoming mail server and then send on the message via the Internet.

• Eventually the email will reach a Mail Delivery Agent (MDA) and then a mailstore such as Microsoft Exchange where it will wait until picked up by the recipients email client via POP,IMAP, or MAPI protocols.

For many organisations using Microsoft technologies the infrastructure will look as simple as this – SharePoint sends on emails to Microsoft Exchange, if the recipient is external its then delivered to the recipients mail server.

Simple email infrastructure

(Note these services can exist on the same physical machine, for example SBS or Small Business Server will contain SharePoint and Exchange on the same server)

This is one article in the larger Troubleshooting SharePoint Alerts guide

Problem

When you setup an Alert in SharePoint the URL is stored in the content database as absolute URL’s and using the URL of the page you were using at the time (for example it could be intranet or intranet.yourdomain.com if using Alternate Access Mapping with external zones)

If you later change the url used to access your site (for example the name of the server, the host name, the port, protocol change from http to https etc) then the URL used in the email alerts will not change and may no longer work.

References

• KB 936760 : The URL of alerts in e-mail notifications that you receive are incorrect after the URL of a … site in … SharePoint changes

To Fix

Use STSADM’s updatealert command that was released in the SharePoint Administration Toolkit in April 2008 (see download links in above KB)

E.g.

stsadm -o updatealert -url http://yournewurl -oldurl http://yournewurl

This is one article in the larger Troubleshooting SharePoint Alerts guide

Problem

The date format in emails received from workflow notification emails such as Task Assigned do not use the correct (site) date format.

For example you may get emails with US date formats for a site using UK date formats and vice versa.

References

• Date Format Incorrect in Email Task Alerts
• Task notification emails have US date format in them?

Fixed in

• Windows SharePoint Services 3.0 hotfix package (Sts.msp): October 28, 2008
• December Cumulative Update for MOSS2007 and WSS3 (Dec 17th 2008)
• Subsequent CU’s
• WSS3 SP2 (April 24th 2009)