I noticed this SharePoint bug already at a couple of SharePoint deployments. Users can create alerts both on their WSS sites (on lists, document libraries) as well as on the SharePoint Portal Server (on areas, persons, searches,...). The alerts from WSS sites are send by e-mail, but the alerts from the Portal are not send, they are only visible on their My Site. When you take a look at the logfiles - you will notice the following error in SPNOTIFICATIONSERVICE.log
02/07/05 16:00:23:047 UNK 00000000 00001204 Alert Notification could not access database. Database appears to be offline or tables are locked
02/07/05 16:00:23:047 UNK 00000000 00001204 The notification could not be generated temporarily. Retrying(limited). Notification details:{Seed Owner=0491436a-6170-4723-8737-b057395185e9 TypeId=AlertResultNotification SeedValue=2831;1;Feb 4 2005 2:36:19:513PM Tag=21} Portal site details:{site=PORTAALSITE RZST id=9fd4be2e-db61-48e6-ba70-3bbdc00433a2} Exception information: Microsoft.SharePoint.Portal.Alerts.NotificationDataTemporarilyUnavailableException: Failed to generate notification:Alert Notification could not access database. Database appears to be offline or tables are locked ---> Microsoft.SharePoint.Portal.Alerts.SecurityAccessCheckFailedException: Tripoli Security trimmer failed and returned a null array at Microsoft.SharePoint.Portal.Alerts.x.a(PortalContext A_0, SecurityTrimmer A_1, DataTable A_2, Hashtable A_3, Boolean A_4, WindowsIdentity A_5, Byte[] A_6, Boolean[]& A_7, Int32& A_8) at Microsoft.SharePoint.Portal.Alerts.x.a(at A_0, PortalContext A_1, SecurityTrimmer A_2, DataSet& A_3, Guid A_4, WindowsIdentity A_5, Byte[] A_6) at Microsoft.SharePoint.Portal.Alerts.at.a(Guid A_0, String A_1, SqlParameter[] A_2, WindowsIdentity A_3, Byte[] A_4) at Microsoft.SharePoint.Portal.Alerts.at.a(Guid A_0, String A_1, SqlParameter[] A_2) at Microsoft.SharePoint.Portal.Alerts.j.a(String A_0, SqlParameter[] A_1) --- End of inner exception stack trace --- at Microsoft.SharePoint.Portal.Alerts.j.a(String A_0, SqlParameter[] A_1) at Microsoft.SharePoint.Portal.Alerts.NotificationTypes.a.a() at Microsoft.SharePoint.Portal.Alerts.ai.c()
This is a bug which you can solve with a hotfix from Microsoft Product Support Services - for more information goto
http://support.microsoft.com/default.aspx?scid=kb;en-us;834859. This hotfix will fix the API call that
the alert service is using to read the TGGAU attribute. This hotfix really should be applied to all of your SPS machines in your environment, assuming you have more than one, but the most important one is the SPS server that has the Job component on it. You can check this from the Central Administration page by choosing the Topology manager and reviewing the assignments.
sharepoint
2 comments:
I ran into the same problem for our deployment of SP2003 on Windows Server 2003 SP1. I noticed that silimar problems do not exist on Windows Server 2003 R2 SP1.
From your experience, if I apply SP2 to Windows Server 2003, will the problem be fixed?
Thanks a lot for your help.
Never mind, I found how to solve this problem. The SharePoint services should run under a domain account rather than a local account. The alert service needs to contact Active Directory to resolve security issues before sending out emails.
Post a Comment