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

Tuesday, July 22, 2008

Back In the Saddle

AWOL

It's been over a month since I've posted anything. If you've subscribed to this RSS feed, I'm sorry for wasting your time/bandwidth over the last month. It's about to get a lot better.

Over the last month I've been working like a dog. I got assigned to this new account that was highly visible, highly complex and for the most part has been highly stressful. I can't say I've ever felt so much pressure in my professional life.  That being said, it helps to realize that what we do (software) often isn't as life and death as we'd convince ourselves into believing. Yes, when things go poorly companies often incur down time, lose data and there IS a cost to these failures. But all that being said, lives are very seldom ruined and too seldom to developers give themselves a break.

I was just recently snapped out of my work conceived tunnel vision in the most startling way. I was banging my head against this problem that I just could not fix for the life of me. And then just as I was about to lose all hope I was completely saved by another developer. A guy I barely knew. The funny thing is that after implementing the solution and fixing our issues I realized that my troubleshoot had been heading in the completely wrong direction. Had this guy not thrown me a lifeline I might not have circled back for days if not weeks to come up with the correct fix.

Community Karma

I can't count the number of times I've been completely saved by a forum thread or a blog post. The fact of it is that every one of us is often asked to perform tasks and deliver solutions with technologies that we are yet not experts in. Even if you were a pro in the technologies you chose to work in, there'll inevitably be some configuration that comes along that will test everything you know and then some.

I've made an extremely conscious decision that I not only owe the community a lot for all the help they've given me, but blogging makes me less likely to run into trouble in the first place.

Blogging regularly not only makes sure you research what you blog about but you also come in to contact with a lot of other blogger's. You absolutely need these people if you're going to succeed in this ever growing and ever changing tech stack. No man is an island and you're going to need a safety net as tall and wide as you can cast.

That being said I can't wait to meet the next person to save me from my next  technical nightmare. I'm sure I'll never forget his/her name and learn a tonne while being pulled from the burning building.

We're only as good as the help we give each other.

See you soon,
Tyler