Well, back in the land of SharePoint ducking in and out of writing my now tome of a book <grin>

Strange issue today with a client setup – typical farm arrangement, two front ends, application, cluster. Fromt checking one of the front ends scanned the application event log and came across Enterprise Library Logging errors. Mighty strange since they dont appear on the other front end….

============

Timestamp: 3/17/2010 9:49:33 AM
Message: HandlingInstanceID: c7102a4b-1d12-4565-bff1-15cb5d4ed39c
An exception of type ‘System.NullReferenceException’ occurred and was caught.
03/17/2010 10:49:33
Type : System.NullReferenceException, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
Message : Object reference not set to an instance of an object.
Source : Microsoft.SharePoint.Portal.ExtendedSearch
Help link :
Data : System.Collections.ListDictionaryInternal
TargetSite : System.Data.DataTable GetCachedData(System.String, Int16, Int32, Int32, Boolean ByRef, Boolean ByRef)
Stack Trace :    at Microsoft.SharePoint.Portal.ExtendedSearch.WebControls.SearchProcessor.GetCachedData(String selectColumns, Int16 resultsPerPage, Int32 longCacheTimeout, Int32 fastCacheTimeout, Boolean& usingCachedData, Boolean& run2ndTime)

Additional Info:

MachineName : [WEBFRONTEND]
TimeStamp : 3/17/2010 9:49:33 AM
FullName : Microsoft.Practices.EnterpriseLibrary.ExceptionHandling, Version=3.1.0.0, Culture=neutral, PublicKeyToken=a646907c4a695009
AppDomainName : /LM/W3SVC/1068090012/Root-1-129132648705494509
ThreadIdentity : domain\username
WindowsIdentity : domain\username

Category: General
Priority: 0
EventId: 100
Severity: Error
Title:Enterprise Library Exception Handling
Machine: [WEBFRONTEND]
Application Domain: /LM/W3SVC/1068090012/Root-1-129132648705494509
Process Id: 10360
Process Name: c:\windows\system32\inetsrv\w3wp.exe
Win32 Thread Id: 13924
Thread Name:
Extended Properties:
===========

From investigation, this appeared to take place whenever a user was carrying out a search. Seems that for some strange reason that faceted cached searches are attempting to use the currently named user to access the content dbs directly. Didn’t occur before, and the users did not suffer any issues from the searches as results were pushed through.

This appears to therefore be a bug, but, does not seem to require fixing? I decided that I’d rather not have faceted search cache results – so in the Search Faceted Results web part I switched off caching.

That cured the issue and prevented any further enterprise logging errors like this being displayed.

Still, thats really strange. Something in the infrastructure or at DB level may have changed – maybe even SPN at Kerberos level? Going to check this out further.

Another point would be I suspect that the other front end would not have noticed if the services were not load balanced (i.e. the front end were not). That said, very unusual to see these errors …. Another watch this space!

However, I hope this entry helps anyone out there who came across the same issue.

Bottom line:

I did some monitoring on sharepoint and sql.  I went through the process of setting up kerberos on the SQL server and SharePoint, took a bit of time to get that working.  However I have a site collection setup on Kerberos and with the faceted search webparts.

Caching is enabled and functioning with no generic 100 enterprise library errors.  Also verified that Kerberos is the preferred security option and is successful.  I also have faceted search webparts setup on our ntlm site collection, and caching is turned off which yields 100 erros on web front ends.

Turning it on of cause does cause the errors but the faceted interface still works!