Saturday, June 29, 2013

Alerts Timer Job Failure SharePoint 2010

After migrating to SharePoint 2010 from MOSS 2007, we faced issues of alerts not being sent. Many users reported the issue and it was an intermittent issue. It was failing for few lists. Even if there are two lists on a site, alerts from one list are working fine, but the other list was failing to send notifications.

I checked the ULS logs and it has entries for COM exception.

Timestamp    : 6/22/2013 8:30:01 AM
Continuation : False
Process      : OWSTIMER.EXE (0x1D64)
ThreadID     : 8464
Area         : SharePoint Foundation
Category     : Alerts
EventID      : c6f5
Level        : Verbose
Message      : AlertsJob, Filter for Immediate subscription with id {2D5D9F07-D0CE-478F-BFBD-B05AE9C8D337} matched event with Id 11471939
Correlation  : aa6f068e-da75-44ff-bcb1-9ef3313dccde
Context      : {}

Timestamp    : 6/22/2013 8:30:01 AM
Continuation : False
Process      : OWSTIMER.EXE (0x1D64)
ThreadID     : 8464
Area         : SharePoint Foundation
Category     : General
EventID      : 837l
Level        : Exception
Message      : An unhandled exception occured. Watson will be invoked.
Correlation  : aa6f068e-da75-44ff-bcb1-9ef3313dccde 

Exception stack trace:
at Microsoft.SharePoint.SPGlobal.HandleComException(COMException comEx)
at Microsoft.SharePoint.Library.SPRequest.DispatchTimerJob(Int32 lJobType, Guid gVServerId, Int32 lScope, Guid gDatabaseId, String bstrDSNServer, String bstrDSNDatabase, String bstrDSNUser, String bstrDSNPassword)
at Microsoft.SharePoint.Administration.SPNativeDatabaseJobDefinition.Execute(Guid targetInstanceId)
at Microsoft.SharePoint.Administration.SPTimerJobInvokeInternal.Invoke(SPJobDefinition jd, Guid targetInstanceId, Boolean isTimerService, Int32& result)

The common thing in these errors was "it was throwing exception after applying filter for immediate subscription as highlighted above.

I first located the alert by using PowerShell script given below. I used the script for web application on which the timer job was failing.

$webs=Get-SPWebApplication <webappurl>|Get-SPSite -Limit All| Get-SPWeb -Limit All
$alert=$webs|%{$_.Alerts}|?{$_.Id -eq "<subscriptionid>"}
$alert|Select @{Name="User";Expression={$_.User.LoginName}}, List, @{Name="Url";Expression={$_.List.ParentWeb.Url}}

The script listed the "SharePoint\System" account as user. This was weird and so we verified on the site "is it really a system account subscribing the alerts?". Yes., it was "System Account."

System account cannot subscribe to alerts in SP2010. We were not sure whether it was possible in MOSS 2007. System account do not have Email ID and so we cannot subscribe to alerts using System Account. This was causing the failure of the Immediate Jobs timer job.



The timer job was failing for the lists where system account had subscription and for other lists it was working.

We removed all system account subscription on all sites in the web application and there were no failures any more.

Hope this will help others.

Sunday, May 26, 2013

Display Form returning 404 Not Found in a List created from Custom List Template

Recently one of the SharePoint site user complained that display form of a list is not working. We checked the list and everything was properly set (DefaultDisplayFormUrl ), but still it was not working. The list was created from a custom list template. The list template was based on an existing list (original list). The original list is working fine but the new created from the template was returning "404 Not Found" error.

I opened turned OFF the dialog and checked the URL it uses to launch display form. As the normal list behaves, it is first invoking the "listform.aspx" page with  query string. The "listform.aspx" page normally causes redirection to appropriate page type specified in the query string. Due to the 404, browser was not displaying the correct final URL. So I just launched the developer tools and checked the HTTP request/response cycle.

The "listform.aspx" is sending 302 for redirection but the location it was referring to the original list. As the original list does not have the new created display form of the new list. It was returning 404.

Then we removed content type ID from the query string and it was working fine. We further investigated and checked if it refers to wrong content type. It was referring to the content type available with the new list. So content type is not the issue.

Why "listform.aspx" referring to the original list?

I de-compiled the code of the "listform.aspx". The "listform.aspx" page invokes a method of ListFormWebPart. This method prepares the final display URL  based on the "DisplayFormUrl" property of content type.


The PowerShell script confirmed it that the problem is with the content type display form URL. The content type is right but it's property has wrong reference.

$web=Get-SPWeb http://
$list=$web.Lists[]
$ct=$list.ContentTypes[0];
$ct.DisplayFormUrl

We updated the DisplayFormUrl in script and it started working. Great job!!!

Monday, March 25, 2013

Lists.asmx: Method not Found


Recently we had an intermittent issues with lists.asmx. It was giving us SoapServerException as below:
Method not found: 'Microsoft.SharePoint.Utilities.SPChunkedStringBuffer Microsoft.SharePoint.SPListItemCollection.GetXmlInternal(Boolean, System.Collections.Hashtable, Boolean, Boolean)'.

The issue was occurring infrequently. We located the issue on two WFE machines.

The exception was saying "Method not found." This is little weird as how OOB dll file miss this method and what is the DLL it is referring to.

I opened the lists.asmx and found that it refers to STSSOAP.DLL.


I searched for the DLL file and we located at two different locations : 1. SharePointRootFolder\ISAPI 2. WebApplicationVirtualDirectory\_app_bin

While browsing through these directories I noted that the DLL files have different "Modified Date". We checked the other WFEs and this difference was not present there. The both files had different versions as "14.0.6024.1000" and "14.0.6122.5000". We recently had server patching and somehow this web application _app_bin folder had the old file and using it.

We replaced the DLL with latest version and the issue is resolved. :)