Sunday, July 27, 2008

Problem with SharePoint SqlSessionStateResolver

The Error

I've seen this error a couple of times now and the fix unfortunately hasn't been all that consistent. The event log item looks like:

Event Type: Warning
Event Source: ASP.NET 2.0.50727.0
Event Category: Web Event
Event ID: 1309
Date: 7/18/2008
Time: 5:31:59 PM
User: N/A
Computer: [COMPUTERNAME]
Description:
Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 7/18/2008 5:31:59 PM
Event time (UTC): 7/19/2008 12:31:59 AM
Event ID: 5e5f200f0a3042648734373e1a3e2fc6
Event sequence: 356
Event occurrence: 1
Event detail code: 0
Application information:
Application domain: /LM/W3SVC/773312491/Root-1-128608981453287591
Trust level: WSS_Minimal
Application Virtual Path: /
Application Path: [PATH]
Machine name: [COMPUTERNAME]
Process information:
Process ID: 5428
Process name: w3wp.exe
Account name: NT AUTHORITY\NETWORK SERVICE
Exception information:
Exception type: NullReferenceException
Exception message: Object reference not set to an instance of an object.
Stack trace: at

Microsoft.Office.Server.Administration.SqlSessionStateResolver.System. Web.IPartitionResolver.ResolvePartition(Object key)
at System.Web.PartitionManager.GetPartition(IPartitionResolver partitionResolver, String id)
at System.Web.SessionState.SqlSessionStateStore.GetConnection(String id, Boolean& usePooling)
at System.Web.SessionState.SqlSessionStateStore.DoGet(HttpContext context, String id, Boolean getExclusive, Boolean& locked, TimeSpan& lockAge, Object& lockId, SessionStateActions& actionFlags)
at System.Web.SessionState.SqlSessionStateStore.GetItemExclusive(HttpContext context, String id, Boolean& locked, TimeSpan& lockAge, Object& lockId, SessionStateActions& actionFlags)
at System.Web.SessionState.SessionStateModule.GetSessionStateItem()
at System.Web.SessionState.SessionStateModule.BeginAcquireState(Object source, EventArgs e, AsyncCallback cb, Object extraData)
at System.Web.HttpApplication.AsyncEventExecutionStep.System.Web. HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Custom event details:

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

The more we bump into it the more frustrating it gets.

Session State

As far as we can tell the exception is a function of Session State not being properly serialized/de-serialized into the Session State database. SharePoint, because of its farm like nature is geared to use database tables in the Shared Services database to store session.

This way if your SharePoint is deployed to a farm and users continue to get bounced around from one Web Front End to another, they won't lose they're session (like they would if it were stored in memory on the WFEs). This Session is stored in the ASPStateTempApplications and ASPStateTempSessions tables of the Shared Services database.

The Terror

What's kind of creepy about this fix is that it still doesn't make a ton of sense to us. Your options are as follows:

  • If you only have one WFE, or you have in IP Source Sticky Load Balancer servicing your web servers you can turn on InProcess session for the session state. IE. turn the following line in the web.config from this:
    <sessionState mode="SQLServer" timeout="60" allowCustomSqlDatabase="true" partitionResolverType="Microsoft.Office.Server.Administration. SqlSessionStateResolver, Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

    to this:

    <sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20"/>

    You can also experiment with using the classic ASP.NET ASPState database and SQL Session Provider. You should know that even in the IP Sticky scenario some users (like AOL users) may still come at the farm using different IP's which will log them out if you're using InProcess session. I'm not positive that AOL still does this.

  • If you're not happy with the above, the following will fix it most of the time (I'm still not 100% from the field with this one).
  1. Go to the Farm database server and open up SQL Management Studio. Connect to the SharePoint database server.
  2. Get the name of the Web Front End that is experiencing the error. Expand the Logins folder in the SQL Management Studio on the Farm database server and add an account named DOMAIN\WFEMachineName$.
  3. Open up the User Mappings for that user, ensure that they have db_owner and public roles for the Shared Services Database (often of the form SharedServices_DB_[GUID]).Adding machine account as login to fix SharePoint SQL Session State error.
  4. Restart IIS on the WFE that you just added an account for. The error should stop appearing.

The Prayer

I have no idea why adding more an account would help fix this in most cases. You would think that you would see connectivity errors or failed audits if connection/authentication/authorization was the issue. Either way I have seen this fix work too often to not pass it on.

May it help you, or better yet you never see this error in the first place.

My Best,
Tyler

13 comments:

Ryan said...

Wow, crazy fix. worked for me, thank you much for posting it!

Tyler Holmes said...

Thanks for the feedback Ryan. It's good to know (especially for these unexplained fixes) that they work for other.

Best,
Tyler

Mr. Ryan said...
This comment has been removed by the author.
Mr. Ryan said...

(signed in with google this time...)
So, it DID work... :(

I had to create a new SSP and I'm getting the same error, but adding the WFE accounts to SQL doesn't fix it this time.
Since I've got two WFE boxes and one APP box (indexer, Central Admin host...) in a farm that's attached to a SQL cluster I didn't try the first fix. Do you have any other tips or tricks that I could try?

Mr. Ryan said...

My fault... my AAM had a misspelling. That's what was causing these errors. :(

Fortunately, I found it and it works now!

Thanks again Tyler.

Tyler Holmes said...

No worries man. Thanks for closing the loop.

Windows Native API Reference said...

Unbelievable. IT WORKS. Thank you so much for this helpful article.

al@mckinnonsoftware.co.uk said...

Thanks Tyler
now on to the next problem...

Microsoft.Office.Server.Search.WebControls.CoreResultsWebPart.OnLoad(EventArgs e) +70

Does anyone get this software working?

Jerry said...

I was handed a development VM with an incomplete farm configuration. I was able to use the InProc solution and bypass any farm config issues. Much appreciated!

Mostafa M. Arafa Elzoghbi said...

Thanks a million :)

Pedro Santana said...

It works for me...
Tanks Tyler

Anonymous said...

Hello,

As Mr Ryan has mentioned this error can also be caused by a problem with your Alternate Access Mappings.

If you attempt to access a SharePoint resource using a URL which is not in the AAM you should get an error in the Application Event Log (Event Id 8214) informing you of this. This may or may not appear together with the SharePoint Event Code 3005 - SqlSessionStateResolver error. On the client side you should get the standard ASP.NET server error page.

I would suggest you try and see whether this is the problem before messing with session state or SQL permissions.

sharepoint said...

Thanks Tyler. It worked for me and saved my day.