When you use Item-level Permissions and set Read Access to Only their own these emails no longer work.

You can’t select both Read Access = Only their own and “Send email when ownership is assigned”

It appears that when you go back to Settings > Advanced Settings the Send Email when Ownership is assigned radio is set back to No when using Read Access = Only their own.

Why

Speculating here – I think that its because its very possible to set this up so the owner is not the assigned to person so you shouldn’t send an email to someone who shouldn’t be able to read it (and remember that when you re-assign a task an email goes out to both the old assignee and the new assignee) so rather than deal with these tricky scenario they just decided to disable it altogether.

Its probably the least understood part of the troubleshooting process; reading through the newsgroups/blogosphere you will notice lots of posts explaining how something seemingly random like disabling and enabling alerts fixed someone’s problem, who said Reboot? 😉 – but not another.

But hey, whilst its nice to understand why something worked – sometimes we just need to get it working!

If its not running try and start it. Check the Windows Event logs for problems – any problems are almost certainly to do with the account its running under and permissions given.

Check the Timer Jobs Status in SharePoint Central Admnistration

SharePoint 3.0 Central Administration > Operations > Timer Job Satus

Check for any columns where status != Succeeded and progress < 100% for clues. Check the last Started time is in the range you would expect (different jobs run on different schedules, check the Timer Job Definitions)

Use STSADM to verify properties

Note – To add to STSADM’s to paths use SET PATH=%PATH%;"c:Program FilesCommon FilesMicrosoft Sharedweb server extensions12BIN"

STSADM -o getproperty -url http://YourSiteURL -pn alerts-enabled

You should see <Property Exists=”Yes” />

STSADM -o getproperty -url http://YourSiteURL–pn job-immediate-alerts

You should see something like the default (but can be changed) <Property Exists=”Yes” Value=”every 5 minutes between 0 and 59” />

Use STSADM to reset properties

Some users have reported that even though these properties are listed correctly above, simply resetting them solved the problem. Be aware, some but not all have reported that this can remove existing alerts.

Problem

Consider the following scenario. You perform a database migration to upgrade Microsoft Windows SharePoint Services 2.0 to Microsoft Windows SharePoint Services 3.0. To do this, you deploy Windows SharePoint Services 3.0. Then, you add the content databases to the Web applications in the new Windows SharePoint Services 3.0 environment.

However, after the migration, Windows SharePoint Services 3.0 does not send e-mail notifications when content changes in a migrated list or in a migrated document library. Users experience the following symptoms:

Users do not receive e-mail notifications for existing alerts for a list or for a document library that was migrated from Windows SharePoint Services 2.0.

Users do not receive e-mail notifications for new alerts that they create for a list or for a document library that was migrated from Windows SharePoint Services 2.0. To receive e-mail notifications, the user must first delete the existing alert. Then, the user must create a new alert.

Cause

This issue occurs if the URL of the Windows SharePoint Services 2.0 server differs from the URL of the Windows SharePoint 3.0 server. For example, this issue occurs if the URL of the Windows SharePoint Services 3.0 server is http://ServerNameVersion3, and the URL of the Windows SharePoint Services 2.0 server is http://ServerNameVersion2.

The ImmedSubscription table in the content database has a Siteurl column. If the value in the Siteurl column does not match the URL of the Web application, Windows SharePoint Services does not send e-mail notifications when content in a list or in a document library changes.

As always the wild card is spam filtering and email rules – so thoroughly discount these first!

Check the People and Groups list for a correct email address.

Check the site collections people and groups list for a correct email address.

Don’t assume this is correct and skip this step, yes I know its correct in AD but seriously, don’t skip this!

Also be aware that site collections (even in the same web application) are independent and have there own user lists – you may have to check each one.

Site Actions > Site Settings > People and Groups > All People. Find the users and check the email address is correct.

Check the list Permissions

The initial email alert confirmation is sent out regardless of the permissions on the list. Subesquent alert emails are ‘security trimmed’ i.e. they are only sent out if the users has at least read permissions on the list an the list item that would have triggered the email.

Does the site inherit permissions from the site collection?

Check List Settings >Permissions and Management >Permissions for this list

Does this list inherit permissions from its parent web site?

Go back to List Settings > General Settings > Advanced Settings

Under Item-level permissions are users only allowed to Read their own items?

Go to the list view. Click on an item and select Manage Permissions

Does this list item inherit permissions from its parent list? If not then does the user have permission on this list item?

To verify; check the user in question can open both the list and the item in question from SharePoint.

You can also inspect Central Administration > Operations Diagnostic Logging for clues such as

Is the destination SMTP server configured to deliver emails or relay them to another SMTP server and if so is it working?

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

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 and the timer service.

Verify that you haven’t got any anti-virus or other security in place that could allow these test messages through but still block the ones from SharePoint – see “Is there anything that may block SMTP transmissions…” above

Go back to the flowchart and continue onto the next step

You are able to send test emails to some users, but not others

(Note – this section does not apply to emails sent by SharePoint but only to test emails sent using a tool like SMTP Test tool or telnet – see above)

The good news is that you know in this case that its not a problem with SharePoint – its time to bring in whomever is an expert on your email infrastructure but a few tips to get you started :-

Is this user’s email is being delivered successfully from other sources, what about external email addresses such as hotmail / gmail?

This can help narrow down the problem between problems on the sending side an receiving side.

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.

The following users do not have e-mail addresses specified: Username. Alerts have been created successfully but these users will not receive e-mail notifications until valid e-mail addresses have been provided

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.