locked
Alerts are only being sent to some users RRS feed

  • Question

  • Hello,

    we are having problems with unreliable alerts on Windows Sharepoint Services 3.0. Our WSS setup consists of the frontend server (in German) and a MSSQL-Server 2008, both on the same Windows Server 2003 R2 x64 box.

    Scenario to describe the problem:

    • User A and B both set up an alert for a calendar to be immediately notified on any changes to the calendar. They are both in the same user group and can both read and write to the calendar successfully.
    • They both get an email saying that the alert has been set up.
    • The alerts are successfully inserted into the "ImmedSubscriptions" table in the database. The rows in that table for user A and B are also EXACTLY the same, except for the columns "Id", "UserId" and "UserEmail" of course, which differ.
    • Now a new entry is added to the calendar.
    • The database query "SELECT * FROM EventCache where EventData is not null" correctly shows that the new calendar entry has been added to the EventCache table in the database.
    • After 5 minutes the EventData and ACL column in the EventCache table are nulled, and user A receives his alert email.
    • However user B does not receive anything!

     

    After setting the log level to debug in the Central Administration and restarting the Tracing service, I found the following in the logfile:

    OWSTIMER.EXE	0x08E4	Windows SharePoint Services  	Timer             	5utp	Verbose 	Scheduled timer job Sofortige Warnungen, id {CE0E23D0-D573-4495-8447-B6C35E92BFC8} at 26 Apr 2011 17:25:52 +0200 (now is 26 Apr 2011 17:20:52 +0200)	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	General            	6t8h	Verbose 	Found typical site / (b7030af9-ab55-4b43-be29-c0af3eabe6c8) in web application SPWebApplication Name=SharePoint Parent=SPWebService.	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	General            	72nz	Medium 	Videntityinfo::isFreshToken reported failure.	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	General            	8xfr	Verbose 	PermissionMask check failed. asking for 0x00000001, have 0x08011000	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	General            	72nz	Medium 	Videntityinfo::isFreshToken reported failure.	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	General            	72nz	Medium 	Videntityinfo::isFreshToken reported failure.	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	Timer             	95lg	Verbose 	Alertsjob results for immediate delivery: 2 prematches, 2 passed filtering, 1 of 2 passed security trimming, 1 final after rollup	 
    OWSTIMER.EXE	0x1470	               	1624             	8acc	Verbose 	Current user before SqlConnection.Open: Name: EXAMPLE\WSS_ADMIN SID: S-1-5-21-1188793562-2819145915-3253092572-1294 ImpersonationLevel: None	 
    OWSTIMER.EXE	0x1470	               	1624             	8acf	Verbose 	Current user after SqlConnection.Open: Name: EXAMPLE\WSS_ADMIN SID: S-1-5-21-1188793562-2819145915-3253092572-1294 ImpersonationLevel: None	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	Database           	880m	Verbose 	SqlCommand: 'dbo.proc_getObjectsByClass'   CommandType: StoredProcedure CommandTimeout: 0   Parameter: '@RETURN_VALUE' Type: Int Size: 0 Direction: ReturnValue Value: ''   Parameter: '@ClassId' Type: UniqueIdentifier Size: 0 Direction: Input Value: '8d8b6e93-d1e7-449a-a533-c35cbce1ba63'   Parameter: '@ParentId' Type: UniqueIdentifier Size: 0 Direction: Input Value: '87e7e43d-8371-4e10-9a3e-cc6e1aa89968'   Parameter: '@Name' Type: NVarChar Size: 128 Direction: Input Value: 'SPAlertTemplateType.Events'	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	Topology           	88b9	Verbose 	Determining if the current user is a SharePoint Farm Administrator	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	Timer             	8e45	Verbose 	Begin invoke timer job Sofortige Warnungen, id {CE0E23D0-D573-4495-8458-B6C35E92BFC8}, DB {274637CC-329F-495A-819C-FC816F31CE6B}	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	Topology           	88b9	Verbose 	Determining if the current user is a SharePoint Farm Administrator	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	Timer             	6euw	Verbose 	Begin dispatch WSS native timer job 0	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	Timer             	95lc	Verbose 	AlertsJob loaded 1 of 1 event data records	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	Timer             	95ld	Verbose 	AlertsJob loaded 2 of 2 subscription records	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	General            	6t8b	Verbose 	Looking up context site http://examplewss in the farm SharePoint_Config	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	General            	6t8d	Verbose 	Looking up the additional information about the typical site http://examplewss.	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	General            	6t8f	Verbose 	Site lookup is replacing http://examplewss with the alternate access url http://examplewss.	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	General            	6t8g	Verbose 	Looking up typical site http://examplewss in web application SPWebApplication Name=SharePoint Parent=SPWebService.	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	General            	8xfr	Verbose 	PermissionMask check failed. asking for 0x00000001, have 0x08011000	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	General            	72nz	Medium 	Videntityinfo::isFreshToken reported failure.	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	Database           	880l	Verbose 	ConnectionString: 'Data Source=DBSERV;Initial Catalog=SharePoint_Config;Integrated Security=True;Enlist=False'  ConnectionState: Closed ConnectionTimeout: 15	 
    OWSTIMER.EXE	0x1470	               	1624             	8acb	Verbose 	Reverting to process identity	 
    OWSTIMER.EXE	0x1470	               	1624             	8acc	Verbose 	Current user before SqlConnection.Open: Name: EXAMPLE\WSS_ADMIN SID: S-1-5-21-1188793562-2819145915-3253092572-1294 ImpersonationLevel: None	 
    OWSTIMER.EXE	0x1470	               	1624             	8acf	Verbose 	Current user after SqlConnection.Open: Name: EXAMPLE\WSS_ADMIN SID: S-1-5-21-1188793562-2819145915-3253092572-1294 ImpersonationLevel: None	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	Database           	880m	Verbose 	SqlCommand: 'dbo.proc_getObjectsByBaseClass'   CommandType: StoredProcedure CommandTimeout: 0   Parameter: '@RETURN_VALUE' Type: Int Size: 0 Direction: ReturnValue Value: ''   Parameter: '@BaseClassId' Type: UniqueIdentifier Size: 0 Direction: Input Value: '8d8b6e93-d1e7-449a-a533-c35cbce1ba63'   Parameter: '@ParentId' Type: UniqueIdentifier Size: 0 Direction: Input Value: '87e7e43d-8371-4e10-9a3e-cc6e1aa89968'	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	Database           	880l	Verbose 	ConnectionString: 'Data Source=DBSERV;Initial Catalog=SharePoint_Config;Integrated Security=True;Enlist=False'  ConnectionState: Closed ConnectionTimeout: 15	 
    OWSTIMER.EXE	0x1470	               	1624             	8acb	Verbose 	Reverting to process identity	 
    OWSTIMER.EXE	0x1470	Windows SharePoint Services  	Timer             	95l5	Verbose 	AlertsJob processed 1 immediate notifications in 1 digests, sent 1 emails, failed to send 0 emails	 
    

    The line "1 of 2 passed security trimming" could be a cause for this problem, however as mentioned above, both users can read and write in the calendar with their browser. How can B then not pass the security trimming and how can this be fixed?!

    To make it even worse, user B was getting SOME of the alert emails last week for new calendar entries, however not all of them. After updating WSS to 12.0.6554 he does not get any updates on calendar items anymore.

    Tuesday, April 26, 2011 5:00 PM

Answers

  • Hi and thanks for the answers.

    The content approval of the calendar is not enabled, neither is the setting to create a new version everytime an item is modified. So the issue described in http://support.microsoft.com/kb/976440/ doesn't apply here.
    Also the calendar does inherit its permissions from the parent site and the users can view and modify all items, not just their own.

    However I found something else: When going to Site actions > Check effective permissions of the parent site and checking the permissions of user B, the result is "no permission", even though user B can access the site just fine.

    The rights are as following: User B is member of the AD group "employees" and "employees" is member of the WSS group "users", which has read and write access to the site. When I run the permission check against user A, who is also member of "employees", the correct access rights are returned. Is this a known bug?

    I completely deleted the "employees" and the "user B" object in WSS and also removed user B from the "employees" group in AD, then readded everything and now it seems to work. I'll see for how long...

    • Marked as answer by welph Wednesday, April 27, 2011 11:00 AM
    Wednesday, April 27, 2011 10:58 AM

All replies

  • Hi welph,

     

    It seems that this is a known issue, please check this article and try the solution there, maybe this could help you to solve this problem: http://sharepointalert.info/2009/11/troubleshooting-sharepoint-alerts-user-email-address-list-permissions/.

     

    Thanks & Regards,

    Peng Lei

    Wednesday, April 27, 2011 5:23 AM
  • HI Welph,

    check this http://support.microsoft.com/kb/976440/ 

    Thanks,

    Raj

    Wednesday, April 27, 2011 7:14 AM
  • Hi and thanks for the answers.

    The content approval of the calendar is not enabled, neither is the setting to create a new version everytime an item is modified. So the issue described in http://support.microsoft.com/kb/976440/ doesn't apply here.
    Also the calendar does inherit its permissions from the parent site and the users can view and modify all items, not just their own.

    However I found something else: When going to Site actions > Check effective permissions of the parent site and checking the permissions of user B, the result is "no permission", even though user B can access the site just fine.

    The rights are as following: User B is member of the AD group "employees" and "employees" is member of the WSS group "users", which has read and write access to the site. When I run the permission check against user A, who is also member of "employees", the correct access rights are returned. Is this a known bug?

    I completely deleted the "employees" and the "user B" object in WSS and also removed user B from the "employees" group in AD, then readded everything and now it seems to work. I'll see for how long...

    • Marked as answer by welph Wednesday, April 27, 2011 11:00 AM
    Wednesday, April 27, 2011 10:58 AM
  • Hi,

    Did you ever find the root cause to the alert issues with users that were given permissions through AD groups?

    We are having the exact same issue, people with direct permissions are working and those that are given permission through AD groups do not (after 24 hours).

    Tuesday, September 22, 2015 6:16 PM