locked
The context has expired and can no longer be used. (Exception from HRESULT: 0x80090317) RRS feed

  • Question

  • We have a problem with our wiki site collection. Once a day (and sometimes more), we get the following error message :

    The context has expired and can no longer be used. (Exception from HRESULT: 0x80090317)

    This message is displayed to everyone, and will stay there for an hour or so before the collection is back to life.

    Doing an iisreset would get the site working but that will last for a day at the most.

    This is what we checked and tried so far :

    1. Our time zones are set and are correct.

    2. Changing the timeout or disabling the web page security validation (followed by an iisreset) didn't work.

    3. All server use the same NTP server for time sync (and they are indeed in sync).

    4. It is happening only on the wiki collection, not the other collections.

    5. We are unable to reproduce the behavior on the staging servers.

    Some particularities :

    1. Regional settings are set to French (Canada)

    2. We have 500+ wiki pages in the site collection

    3. We require page check-out / check-in for editing. Tried without, same problem.

    Any ideas as to what should we try next ?

    Regards,

    homerggg

    Tuesday, February 4, 2014 10:31 PM

Answers

All replies

  • Hi,

    I'm currently looking in to the same problem in 2 of our farms, one is with a WIKI and the other with a community portal. I have tried the same as you in relation to timezone settings etc. but I have had no luck. I have found that a quicker way to fix it temporarily is to just recycle the app pool, rather than an iisreset.

    I found this post earlier today which you might find useful.

    http://blog.randomdust.com/index.php/2013/06/sharepoint-2013-claim-expiration-and-ad-sync/

    Rob


    • Edited by RobMarwood Wednesday, February 5, 2014 12:48 AM Corrected link
    Wednesday, February 5, 2014 12:47 AM

  • Well that would be easier to recycle the app pool, thanks Rob !

    As for the link you provided, this is what we are currently looking into. Yesterday we tried raising the delays/timeout/expirations we were using (they may have been too short) :

    • Token-timeout = 120m
    • FormsTokenLifetime = 60m
    • WindowsTokenLifetime = 60m
    • LogonTokenCacheExpirationWindow = 10m (default)

    Today we are trying :

    • Token-timeout = 240m
    • FormsTokenLifetime = 120m
    • WindowsTokenLifetime = 120m
    • LogonTokenCacheExpirationWindow = 10m (default)

    We'll keep an eye on that.

    Did raising the various timeouts worked for you ?

    Regards,

    Wednesday, February 5, 2014 2:55 PM
  • Unfortunately for me the issue is only presenting itself in our production environments, so I haven't been able to make any changes to the various timeout values yet. I have been trying to introduce the problem into another environment so I can test, but I haven't had much luck with it yet; typical.

    I have a call open with Microsoft at the moment for this, if we come across anything I'll certainly update this thread.

    Rob

    Wednesday, February 5, 2014 5:27 PM
  • We only have this problem in production environments too. But we only have 20 live users or so, and an iisreset have little impact for now, we then decided that we would change the timeouts on our production servers. I know, not the best way to go...

    We didn't manage to reproduce the problem in staging environments.

    The new timeouts we tried today didn't work.

    I confirm that an app pool recycling work.

    We will set all the timeouts as default and see what will happen.

    Thanks for keeping us informed of your call with Microsoft.

    Wednesday, February 5, 2014 6:39 PM
  • Rob,

    What are your timeouts in your production environment ?

    Regards,

    Wednesday, February 5, 2014 6:50 PM
  • Hi,

    I don't think we have changed them from the default, a quick look shows ours are set to:

    • Token-timeout = 24hrs
    • FormsTokenLifetime = 10hrs
    • WindowsTokenLifetime = 10hrs
    • LogonTokenCacheExpirationWindow = 10m

    Rob

    Thursday, February 6, 2014 5:08 PM
  • I confirm that even with default timeouts values, the problem persist.

    We will try disabling some in-house functionnalities to rule that out.

    Guillaume

    Friday, February 7, 2014 2:59 PM
  • Rob, do you have content search web parts in your problematic sites ?

    Guillaume


    Monday, February 10, 2014 4:17 PM
  • Hi Guillaume,

    Yes, we have a search webpart displaying sites that are being followed by the user.

    I was called today by Microsoft and told they would have an action plan ready for me tomorrow, hopefully I will be able to provide some more information on this in the next couple of days.

    Rob

    Monday, February 10, 2014 4:41 PM
  • Hi Rob,

    Upon deactivating every search webpart on our wiki, the problem persist. There's probably no connection between the problem and the search content web part.

    I hope Microsoft's action plan worked (or will work) and I'm looking forward for an update ;-)

    Guillaume

    Tuesday, February 18, 2014 2:54 PM
  • Hi Guillaume,

    I'll be making the changes Microsoft have suggested, this evening, so I should know within the next couple of days if it has resolved the problem.

    As soon as I know, I'll update this thread.

    Rob

    Tuesday, February 18, 2014 4:21 PM
  • Hi Guillaume,

    I'm still monitoring the situation here, but I have noticed that this only seems to be an issue on sites that have the Publishing Site feature enabled. Is this the same for your environment?

    Rob

    Wednesday, February 26, 2014 3:34 PM
  • Hi Rob,

    Yes, we noticed that after enabling that feature on another site collection the problem quickly hit that collection. We disabled that feature soon after and the problem has not been seen since on that collection.

    But disabling this feature on a wiki site collection is not an option, as it would become unusable.

    Regards,

    Guillaume

    Friday, February 28, 2014 8:16 PM
  • Hi Rob,

    Any updates on this particular problem ?

    Guillaume

    Tuesday, March 11, 2014 5:47 PM
  • Hi Guillaume,

    Unfortunately not, I have received a new action plan from Microsoft and I will be working on it today, but as this is affecting our production environment most of the tasks they want me to do are going to need to go through our change procedure; again.

    Rob

    Wednesday, March 12, 2014 9:47 AM
  • Hi Guillaume,

    It looks like we might have found the cause of the problem in our environment. We had incorrectly configured Kerberos and setting 'Trust this computer for delegation to any service (Kerberos only)' on all servers in the farm seems to have resolved the issue.

    I'm still monitoring and will update you if anything changes, but it's been 4 days now and I haven't had an error about content expiration yet.

    Hope this helps you.

    Rob

    Monday, March 24, 2014 2:38 PM
  • Hi,

    We were not using Kerberos but still tried that setting. No surprise there : it didn't work.

    It's been a while now that you applied that solution. It is still working out for you ?

    We will consider opening a ticket with Microsoft (no idea how to do that and how much money it's gonna cost...)

    Regards,

    Guillaume

    Wednesday, April 9, 2014 5:57 PM
  • Hey Guillaume,

    Unfortunately not, it was fine for almost 2 weeks and then the problem returned. I'm back going through troubleshooting steps with Microsoft. Sigh...

    Rob

    Thursday, April 10, 2014 8:41 AM
  • Hi Rob,

    Nothing new to report ?

    Regards,

    Guillaume

    Tuesday, April 29, 2014 3:22 PM
  • Any update on this issue?

    Regards,

    Amiya

    Tuesday, May 13, 2014 12:23 AM
  • Hi,

    We just began to be impacted with the same error. Do you have any news about this issue ?

    Thank you.

    Tuesday, May 27, 2014 1:29 PM
  • As of today, we still have that problem.

    Any of you installed SP1 ? We will do so in a couple of week or so, maybe that will help.

    SP1 will, anyway, help with some other problems we have...

    Regards,

    Guillaume

    Tuesday, June 3, 2014 1:44 PM
  • Hi,

    Apologies for not updating this tread for a long time. I'm actually still troubleshooting this with Microsoft and had a support call with them earlier today. The issue is now much worse and occurring every hour.

    We haven't installed Service Pack 1 yet, we're currently running on the August CU. I'll chat with our architect and find out if he has any plans for us to upgrade to SP1.

    I'll try and provide more information about the support calls with Microsoft and not leave you in the dark as long this time.

    Regards,

    Rob

    Tuesday, June 3, 2014 2:05 PM
  • Greetings all,

    I'm joining this thread because we appear to be having the same issue. We see it in on a specific web application that hosts our host named site collections. Any time Publishing is enabled on one of those site collections, we get these errors.

    We haven't see this issue in another webapp that uses Publishing but no host named site collections. Not if there's a tie in there or not.

    I'd love to hear about how these support calls are going... You're not alone on this one!

    Thanks,

    Pete

    Tuesday, June 10, 2014 6:29 PM
  • We're also in same boat, seeing same error message only in Production. Is anyone found any solution so far?

    Thanks!

    Tuesday, August 5, 2014 6:34 PM
  • Same problem here in our production environment. It looks like this problem only comes up in host named site collections.

    We're on SP2013 SP1 at the moment.

    Wednesday, August 20, 2014 11:53 AM
  • When I saw msmilde's reply I was anxious to see if SP1 indeed would help.

    I'm sorry to say that we are now on SP1 and the problem still exist.

    And for us this is not happening on a host named site collections.

    So SP1, based on msmilde's experience and us, is of no help for this issue.

    Rob, any news ?


    Monday, August 25, 2014 5:49 PM
  • I moved my sitecollection to a "regular" site collection, and the issue is still there. So we can rule out the HNSC (also based on the observations of Guillaume).
    Tuesday, August 26, 2014 9:38 AM
  • Hi to all,

    are there any news about this issue?

    I'm currently facing the same problem.

    Running SP2013 SP1, Publishing Template, Publishing Infrastructure activated, Time Zone set correctly, iisreset fixes the problem for some days, than same as before.

    The page hosts a public Website, so anonymous access is configured. Issue occures for anonymous and logged in users.

    Monday, October 6, 2014 12:29 PM
  • No news on my side. Still waiting for someone to figure that one out.

    Hopefully Rob hasn't forget about us ;-)


    Thursday, October 30, 2014 3:31 PM
  • I am also seeing this problem and have been fighting it for a month. I can add a few things about the farm I am trying to fix:

    1. It was a WSS 3.0 site that when through a 2007-2010-2013 migration in short order. 

    2. It is under-powered on the hardware side. All VMs on a host shared with 40 VMs. Here's the virtual farm breakdown:

    -1 WFE with 12GB RAM and 2 cores

    -3 app servers with similar resources

    -No paging file on C: on any VM. This is a decision by sysadmin. Paging on D: is system managed. Probably irrelevant.

    3. Rapidly clicking from link to link seems to bring on the failure much sooner.


    Monday, November 3, 2014 4:41 PM
  • What seems to have fixed it for me was turning off the Request Management service in Central Administration - System Settings - Services on Server - Request Management - STOP.

    I'm wondering if maybe my servers have some problems with their certificates. Also, I know our servers are a few seconds off on their time but I cannot imagine that is the reason. That would be entirely too fragile for an enterprise system.

    Monday, November 3, 2014 10:25 PM
  • Request Management service is not a service which is enabled by default. In my case, it's not running at all
    Tuesday, November 4, 2014 12:24 PM
  • Hi,

    Request Management service is not running on our servers.

    Maybe someone will find similarities between all of our setups :

    1. Brand new SP2013 installation (no migrations).

    2. We have 1 WFE and 1 app server.

    3. Running on VMs under VMWare ESXi v5.1.

    4. All servers get their time from the domain controler, which in turn get its time from the canadian ntp pool (GMT -5).

    Tuesday, November 4, 2014 4:34 PM
  • In the end, request management did help but was not the sole reason for the bombs. In fact, I have one site that continues to bomb out. My suspicion is either lack of ram - the place I am doing some consulting for is underpowering their environment considerably - or something odd about this one particular site.

    As a workaround, I set the app pool to recycle periodically during the day so that even if the one site was down for a bit it would eventually come back to life without my intervention. The client says they have a new VM host on order. When it arrives and more resources are thrown at the problem I will know whether or not that's the dealio. Hope so...although it doesn't instill more confidence in me for SharePoint's robustness :/

    Monday, December 1, 2014 3:50 PM
  • It looks like my errors are away for a couple of months now. The biggest changes I made were:

    • Install SP2013 SP1
    • Install AppFabric 1.1 CU 5
    • Enable Garbage collection within AppFabric 1.1 (.config file)
    • Give the SharePoint FrontEnd Server MORE RAM!!!
    Friday, December 5, 2014 11:30 AM
  • Interesting. I also have sp2013 sp1 but I didn't know about AppFabric 1.1 CU 5. Will definitely get that installed. I'll add GC, too. 

    We're supposed to get a new ESXi host, soon. (We are also running ESXi but I think it is 5.5). More RAM may definitely help.

    I will just add that the VMs do seem to have minor time issues. They can't seem to stay sync'd to the second with our house time server. Since this is something that most environments probably do not experience, it might fit with why  folks don't run into this issue often.  The thing that is odd about this, though, is that I'm now only experiencing it on one particular site collection consistently. Weird. Probably take someone who likes rabbit holes to really figure out what is going on. That would not be me. However, here's what I can do to investigate further:

    - ESXi env might be the common denominator. I could try Hyper-V and see if it changes.

    - My single-box dev environment has the same content db mounted. It hasn't thrown up any issues yet so I could try replicating the farm precisely in dev. I doubt sysadmin gonna let that happen, though, unless users complain.

    Friday, December 5, 2014 2:23 PM
  • We had the same issue today and got it fixed. The root cause was because, for some unknown reason, the time of the WFE server was not in sync with the current local time. It moved back a minute or so, we reset the time to show the current local time and then did an iisreset and the site was up and running! Hope this helped...

    Thanks, Melvin


    Melvin David

    • Proposed as answer by Melvin David Friday, December 12, 2014 10:51 PM
    Friday, December 12, 2014 10:31 PM
  • Hi,

    It seems that the problem was the AppFabric Service and the Distributed Cache.
    After applying this patch and reboot each FrontEnd Server the problem was solved in our farm.

    http://www.wictorwilen.se/how-to-patch-the-distributed-cache-in-sharepoint-2013

    Thanks also to msmilde

    Regards,



    • Edited by SinedQc Thursday, February 19, 2015 9:46 PM
    • Proposed as answer by SinedQc Thursday, February 19, 2015 9:46 PM
    • Marked as answer by Guillaume Gilbert Saturday, February 21, 2015 5:40 PM
    Thursday, February 19, 2015 9:35 PM
  • Hi Rob,

    You can change the default timeouts to desired value only be sure that its order in Token-Timeout > WindowsTokenLifeTime > LogonTokenCacheExpirationWindow .

    I got the same issue when I changed the values to 

    • Token-timeout = 120m
    • WindowsTokenLifetime = 60m
    • LogonTokenCacheExpirationWindow = 10m (default)

    But I fixed the issue by starting Claims to Windows Token Service (C2WTS) on my app server which was stopped.

    Please try it in your environment and see if it works.

    Regards,

    Manish

    Thursday, October 8, 2015 11:00 AM