I have read many blogs that talk about SharePoint alert issue – basically alerts just don’t work as they are supposed to. I suppose you checked to make sure if you are set up correctly by reading other posts. I am putting this post together based on my experience for those who haven’t found a solution hoping this may help. First of all, before you even try to fix anything, make sure you check the following items to ensure your SharePoint farm is correctly configured to send alerts…
- You should check Timer Job status in the Central Administration site (Operations > Timer Job Status). The job status should display “Succeeded” message if an alert has been successfully created - Immediate Alerts servername Succeeded 100% 12/17/2009 3:50 PM
- You get a notification email shortly after you created an alert in SharePoint with the following subject: ”You have successfully created an alert for …”. However, you may not get any real alerts afterwards – this will be addressed below. If you are not even getting the first notification email, you should check your outgoing e-mail settings in CA.
- You should make sure ”On” is selected for ”Alerts on this server are” in your web application general settings in CA (Application Management > Web Application General Settings).
- You should check the content database that contains site collection(s) having the alert problem to see if “” (for immediate alerts) and “SchedSubscriptions” (for scheduled alerts) tables contain rows for created alerts – if you have empty tables, alerts are not getting created.
- Make sure you have the following stored procedures in content databases - if any of these is missing, you can copy from your Dev/QA environment content databases to test your alerts):
“proc_AddSubscription“,
“proc_DeleteSubscription“,
“proc_GetMatchingSubscriptionsData“,
“proc_GetWebSubscriptions“,
“proc_GetWebSubscriptionsForBackup“,
“proc_GetWebSubscriptionsUniqueUsers“,
“proc_MatchSubscriptions“,
“proc_ModifySubscription” and
“proc_UpdateSchedSubscriptionTimes“
I usually review the configurations listed above to fix lots of my alert problems. But in some cases, I had to apply one of the below solutions to fix the issue. Some of these solutions are:
- Setting the property values for SharePoint site(s) to make sure the alert is enabled: stsadm.exe -o setproperty -url http://site -pn alerts-enabled -pv true
- Setting the proeprty values for SharePoint site(s) to make sure the alert is being sent immediately: stsadm.exe -o setproperty -url http://site -pn job-immediate-alerts -pv “every 5 minutes”
- Restarting “Windows SharePoint Services Timer” service in all SharePoint server(s) to trigger the timer service.
- Upgrading your SharePoint environment with service packs and/or cumulative updates – this seems to solve the issue for most cases. Make sure you backup your environment if you are planning to do so. Also, be patient when the upgrade is in progress. In some environments, I had to wait 8+ hours per server in a farm to complete the update. After the update is applied completely to your SharePoint farm, all congested alerts will be flushed out (so, you should plan to warn your users if you have had this problem for a long time because end users may be receiving sever hundreds of alerts at once).
- Making sure the SMTP relay configuration includes all SharePoint servers’ IP addresses (including all SQL database IP addresses) - your relay restriction settings should grant access to all SharePoint servers including all SharePoint related SQL servers. A lot of times, I have seen people excluding IP addresses for SQL servers when granting access but this will result in no alert or random alert behavior.
I hope this post helps! If you have a unique case, please share your story here. I may be able to help 
Tags: alert, alerts, issue, list, moss, notification, sharepoint, wss
tigirry
HI Tiggiry,
I went through your blog and found it very interesting.
We have been working on alerts on a standalone box.we may in sometime need to move this to the other environments.
Issue
——–
Our other environment configuration is different. We have 4 web front ends and a database server.2 of the webfront end’s have central admin site’s running.This boxes exist in one Zone(say Zone A).
The other 2 webfront end runs in Zone B. Both the zones don’t have the same smtp server address to relay the mails..we could workaround this by providing the smtp info in the web.config file and picking it up from there.
We are customising the alert emails to meet out requirement.We do this by hooking into the alert email by extending the IAlertnotifyhandler .We deploy this assembly into the gac.
Some of the confusions I have:
1)Which timer is responsible for triggering the immediate,daily and weekly e-mails.is it the immediate timer job or the owstimer job?I am confused about the difference between between them.
2)when we have a farm environment which wfe’s(Web front end) timer jobs will trigger the alert?
3)which wfe will send the subscription mails?where is the smtp server address for sending the subscription mails picked from?
4)if the subscription mail smtp info is picked from the central admin ,there lies always a possiblity that the a wfe in zone B picks the alert and tries to send the mail using the smtp address mentioned in Central admin site in Zone A.This will cause the sending to fail.
Please provide your suggestion. I will be lookinf forward to hear from you.
Thanks
Mathews
Hi Matthews,
Below are my responses to your question based on my knowledge…
1) I believe it’s the owstimer job. The owstimer is SPTimer (i.e., owstimer) is the process running on your server and the immediate timer job is the job definition that the SPTimer is executing.
2) Normally, the timer jobs are to be triggered on one of your SharePoint servers (as Shared Services Timer Job i believe). You should be able to view the history.
3) One of your servers that’s joined to the farm will send the subscription mail using the value you specify in the outgoing email settings.
4) I personally haven’t tried your scenario but my guess is, yes, I think in your environment, the sending may fail. If I find any additional information, I will update you
We have SharePoint Server 2007 and recently had to change our domain name. With that, the outbound email changed from smtp.olddomain.edu to smtp.newdomain.edu (example). After
that, the Immediate Alerts just don’t get delivered. I have traced the path from the server to the smtp server and it’s not blocking these.
On the main page, the old smpt shows as “Not configured” rather than going away. My theory is that after a time the jobs are getting put into the old queue and not the new one. I don’t know what tool/command to use to see the table in SQL like you showed above. Can you tell me how you saw the records? Also, can you offer any other suggestions for solving this? We don’t get any errors or traces – restarting the timer job works for about a day, then they just silently stop working. Thanks!
Hi Jenny,
If the old smtp showss as “Not configured”, you can remove the server by going into “Operatings” -> “Servers in Farm”. If you restart the timer service, it should pick up the newly added smtp value in CA. I basically took time to review the tables in SQL; i don’t know if there is any tool designed for reading SharePoint SQL tables and SP’s. Try removing the server listed in CA first to see if this resolves the issue.