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.

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

HI Welph, check this http://support.microsoft.com/kb/976440/ Thanks, Raj

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...