Sladescross's Blog

Blogging about Sharepoint related stuff

Sharepoint Alert Customisation February 19, 2011

Filed under: Alerts,Sharepoint Alerts — sladescross @ 1:41 pm

http://blogs.msdn.com/b/sharepointdeveloperdocs/archive/2007/12/07/customizing-alert-notifications-and-alert-templates-in-windows-sharepoint-services-3-0.aspx

Alerttemplates.xml is located at: Local_Drive\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\XML directory.

Steps to Modify Alerts

You can use any XML editing tool to edit the templates.

  1. 1.      Create a working copy of AlertTemplates.xml.

Note   Remember to always modify a copy of Alerttemplates.xml, not Alerttemplates.xml itself.

  1. 2.      Edit the working copy that you just created.
  2. 3.      Use the stsadm command to read the changed templates into the database.
    STSADM -o updatealerttemplates -url <http://urlname&gt; -filename <your working copy filename>.
  3. 4.      Restart IIS.

Note   It may be necessary to restart SharePoint Timer Services.

To assign a custom alert template to a specific list

  1. 1.      Create a new custom template with a unique Name attribute in your working copy of AlertTemplates.xml (You can copy paste the entire section with Name SPAlertTemplateType.GenericList, change the name and modify the sections you want to). Modify the template as necessary. After restarting IIS, write object model code to set the list alert template

SPAlertTemplateCollection ats = new SPAlertTemplateCollection((SPWebService)(WebApplication.Parent)); //give appropriate values for WebApplication

list.AlertTemplate = ats[“name from above”];

list.Update();

 

Sharepoint Alerts February 21, 2010

Filed under: Alerts,Sharepoint,Sharepoint Alerts — sladescross @ 4:46 pm

Check for failed alerts:

SELECT [EventTime]
      ,[Id]
      ,[SiteId]
      ,[WebId]
      ,[ListId]
      ,[ItemId]
      ,[DocId]
      ,[Guid0]
      ,[Int0]
      ,[Int1]
      ,[ContentTypeId]
      ,[ItemName]
      ,[ItemFullUrl]
      ,[EventType]
      ,[ObjectType]
      ,[ModifiedBy]
      ,[TimeLastModified]
      ,[EventData]
      ,[ACL]
  FROM [WSS_Content_Portal].[dbo].[EventCache]
  WHERE EventData is Not Null

http://sharepointalert.info/2009/11/troubleshooting-sharepoint-email-primer/

Confirmation emails separate from email alerts which are sent via a timer job.

http://sharepointalert.info/2009/11/troubleshooting-sharepoint-alerts-user-email-address-list-permissions/

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

"Alertsjob results for *** delivery: 10 prematches, 10 passed filtering, 8 of 10 passed security

http://sharepointalert.info/tag/troubleshooting/

List of trouble-shooting options.

Use STSADM to verify properties

Note – To add to STSADM’s to paths use SET PATH=%PATH%;"c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\"

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.

stsadm –o setproperty –url http://YourSiteURL –pn alerts-enabled –pv False

stsadm –o setproperty –url http://YourSiteURL –pn alerts-enabled –pv True

stsadm –o setproperty -url http://YourSiteURL –pn job-immediate-alerts –pv “Every 5 minutes between 0 and 59"

Reference for alerts-enabled and job-immediate-alerts properties

Use STSADM to re-register the alert templates

Again, some people have reported that this works with no agreement on the cause.

stsadm -o updatealerttemplates -url http://YourSiteURL
   -f "c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML\alerttemplates.xml"
   -LCID 1033
http://www.eggheadcafe.com/software/aspnet/29625230/email-alerts.aspx
I tried the following to fix the issue. Please check whether this helps
1. Alerts are based on SMTP and checked whether the SMTP is configured
properly and made sure that the server running sharepoint has proper access
to SMTP
2.Alert mails would be sent as bulk-mails and made sure that anti-virus
software is not blocking bulk mail functionality
3. Made sure that events are turned-on in the server running sharepoint.
Because events should be fired to trigger the alert functionality
4.Alert related details are stored in in the tables of the content database
of sharepoint. Made sure that the following database-tables of sharepoint has
proper entries for alerts
EventLog table
EventCache table
SchedSubscription table
ImmedSubscription table
5. Made sure that all the accounts (Service LOG ON accounts, APP Pool accounts
and DataBase accounts)
6.Made sure that indexing and crawling happened properly
7.Made sure that gatherer log has no errors

--
Thanks & Regards,
Sundar Narasiman
http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/MS-SharePoint/Q_23592930.html
RESOLUTION:
============
1. Opened the MOSS Central Administration page, clicked on Operations--Timer Job
Status, made sure the following two jobs were showing "success" and 100%
Change Log
Immediate Alerts

2. Opened the command window, navigated to the BIN folder and got the property of
Alerts-enabled to make sure the alerts are enabled for the timer service:
C:\Program Files\Common Files\Microsoft Shared\web server
extensions\12\BIN>stsadm.exe -o getproperty -url <http://problemsite> -pn
alerts-enabled
The expected output is
<Property Exist="Yes" Value="yes" />

3. Made sure the account running the SharePoint Timer service is the account which
has the administrator Full Control permission over the site and the full permission
over the content database. Then we restarted the timer service. 

4. We found EventData and ACL are not NULL for the specific content database. This
seems to be the key to the problem. 

5. We checked the property job-immediate-alerts schedule
C:\Program Files\Common Files\Microsoft Shared\web server
extensions\12\BIN>stsadm.exe -o getproperty -url <<http://ProblemSite>> -pn 
job-immediate-alerts
it showed Property Exist="No" for that specific site. 

6. We used the following command to re-set the schedule
stsadm.exe -o setproperty -url <<http://ProblemSite>> -pn job-immediate-alerts -pv
"every 5 minutes between 0 and 59"

Alerts began to work. 

ADDITIONAL INFORMATION
=========================
The internal working mechanism of how an alert should work in v3:
1. The EventCache table records the SQL level events as they occur and the
EventData and ACL columns are not NULL for an alert event.
2. There is an alerts timer job that runs periodically to process the records in
the EventCache. After the alerts timer job runs, it nulls out the EventData and
ACL columns.
3. Then, it will log an event into the EventLog table. 

MORE TROUBLE SHOOTIING STEPS
=============================
1. Open the command window, go to the BIN folder and get the property of
Alerts-enabled to make sure the alerts are enabled for the timer service:
C:\Program Files\Common Files\Microsoft Shared\web server
extensions\12\BIN>stsadm.exe -o getproperty -url <http://problemsite> -pn
alerts-enabled
The expected output is
<Property Exist="Yes" Value="yes" />

2. Open the MOSS Central Administration page, click Operations--Timer Job Status,
make sure the following two jobs are showing "success" and 100%
Change Log
Immediate Alerts

3. Make sure the account running the SharePoint Timer service is the account which
has the administrator Full Control permission over the site and the full permission
over the content database. Restart the timer service if required. 

4. Open SQL Query Analyzer, connect to the content database of problematic site.
Run the following query and copy the result out.
Select * from timerlock
Let me know the server name seen in the LockedBy column is the same one of this SPS
server. This server is responsible for processing the timer service. 

If the issue persists, collect the following information:
1. Run the following query against the content database of problematic site
select * from eventcache where EventData is not null
This will out put all fo the subscritions which have not been processed yet. We can
see if there are some alerts which are not processed. Export the result to us. 

2. select * from eventlog where ListID = 'xxx'
Export the result to us.
You can get the ListID from the EventCache table by running
Select * from EventCache and check the documents which correspond to the
problematic list. 

3. If you cannot find any record in the step 1, please perform the following
tests: Put filemon on the SPS server and we can see if the Timer service picks up
the alert template during the whole process.
a. Upload a new document to the document library which is supposed to have the
alerts. Begin running the filemon.
b. Run
select * from eventcache order by EventTime DESC
Check if the latest log is the one corresponds to your uploaded document. Make sure
the EventData and ACL columns are not NULL.
c. After 5 minutes or more minutes, check the EventCache table again to see if the
EventData and ACL columns are NULLed.
d. If so, stop filemon after the EventData and ACL columns are NULLed . Send the log to us.
http://weblogs.asp.net/mellota/archive/2007/10/11/sharepoint-2007-task-notification-alert-emails-not-working.aspx
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
 

 
Follow

Get every new post delivered to your Inbox.

Join 63 other followers