Page refresh after postback from UpdatePanel in Sharepoint 2013 RRS feed

  • Question

  • Hello!

    Strange behavior appears when using Updatepanel on Apllication page or usercontrol in Sharepoint 2013.

    In FF and Chrome postback leads to full page refresh after small idle between requests (around 30 seconds). Example: we have a page with button and label inside UpdatePanel. We open this page and click the button -> updatepanel refreshes its content without page reload. If we will wait more than 30 seconds and click the button again, page will reload. 

    In Firebug or Fiddler we can see follow:

    1) POST-request from updatepanel to server

    2) Response from server will contains 

    1|#||4|53|pageRedirect||/_login/default.aspx?ReturnUrl=<my page url>

    3) After there will be request to /_login/default.aspx and then redirect to  /_windows/default.aspx?ReturnUrl=<my page url>

    4) And then it will be redirected to my initial page.

    Users see only page reload.

    But if we will wait a long time (around 20 minutes) there will be not page reload and updatepanel refreshes only their content.

    This error happens in different environment in defferent domains. We use standart Claims based authentication and Minimal Download Strategy feature is disabled.

    In IE this error occurs, but not so often.

    I found that error disappears if Form Authentication is disabled in IIS web application (but in this case there are some problems in another pages in portal).

    Can anyone help me with this problem. Thanks

    Sunday, February 16, 2014 1:16 PM

All replies

  • did you ever find a solution to this?
    Sunday, March 2, 2014 3:41 PM
  • No. Do you have the same problem?

    I found that it is related with claims based authentication and maybe it is related with authentication between servers. Bug occurs if AD, SQL and Sharepoint are installed on different servers. And there is no bug if AD, SQL and Sharepoint are on the same server.

    If web application is configured to classic windows aunetnication there is no bug.

    Friday, March 21, 2014 7:00 AM
  • Hi,

    I've got the same symptoms. Can't figure it out at all. The funny thing is update panels had been working fine on this environment for months and it's just stopped working all of a sudden. I don't think anything in the environment has changed and I can't see code changes which would affect it.

    Thursday, June 5, 2014 2:21 PM
  • Hi.

    Can you describe your farm topology? How many servers and what is installed on them?

    Thursday, June 5, 2014 6:04 PM
  • Hi Dmitry,

    It's like you said, separate machines for AD, SQL and SharePoint. We have 2 AD, 2 SQL and 2 SharePoint servers. We have live environment with the same setup where it seems to work fine. The only difference is that the problem environment is a subdomain of the corporate domain, and there's less resources allocated to it. But I don't think that's the problem. I've spent a long time looking at this now, and all I can think of is it's some type of security/authentication issue. Why is it redirecting the request to a login page?


    Friday, June 6, 2014 7:31 AM
  • Hi Dan.

    As i understand redirect occurs when system cannot determine user claims. In fact it cannot determine claims after ~30 seconds idle.

    We made some experiment: we have added js script to page which calls any sharepoint web service every 15-20 seconds. And this bug  has particulary disappeared. In other words if there is any request from browser to server with period less than 30 second, it works almost fine:) 

    But i believe that problem is related with environment settings or (maybe) permissions between services in environment.  I've seen this problem in several different companies and i don't think they have any strange settings. Problem must to be related with some main settings of claims auth, IIS or service accounts permissions.

    In one of the previous posts you have written "update panels had been working fine on this environment for months and it's just stopped working all of a sudden". Are you sure that there was no change in authenticaation settings for web application?


    Friday, June 6, 2014 8:48 AM
  • Hi,

    That's very interesting thanks.

    Hmmm, I'm not 100% confident now that it ever worked in this environment. But no one's ever noticed it before. But there's the possibility if could have never worked.

    It's frustrating because it works perfectly in the production environment (thank god), so I know it can work. I just don't know what the problem is.

    Thanks very much for your help

    Friday, June 6, 2014 10:11 AM
  • Dan, maybe we can join our forces to find the reason of this problem? We could to make contact in LinkedIn to  share experiences on this issue. This is link to my profile.


    Friday, June 6, 2014 2:34 PM
  • Hi,

    This is happening because ViewState architecture has been changed in SharePoint 2013. Right click and open ViewSource of the page, search for _VIEWSTATE, you will see only a GUID rather than actual viewstate of controls.

    To improve the client-server network performance, Microsoft has introduced the concept of Distributed Cache, and all the controls view state is getting stored in DistributedViewStateCache [on server side]. 

    So if you will not scale out your SharePoint environment to meet the timeout requirement, then during partial post back you will get this experience - "full post back".

    Fix - if you are using lot of asp.net concepts/.ascx user controls then I would say opt for managing view state on client side[asp.net style]

    • $contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService;
    • $contentService.ViewStateOnServer = $false;
    • $contentService.Update();

    But if you want to keep out of box architecture, then consider changing timeout values.

    Not only DistributedViewStateCache timeout can cause this, DistributedLogonTokenCache timeout can also be issue. So set the values like below:-

    $DLTC = Get-SPDistributedCacheClientSetting -ContainerType DistributedLogonTokenCache

    $DLTC.ChannelInitializationTimeout = "60000"
    $DLTC.ConnectionBufferSize = "131072"
    $DLTC.MaxBufferPoolSize = "268435456"
    $DLTC.MaxBufferSize = "1073741824"
    $DLTC.MaxOutputDelay = "2"
    $DLTC.ReceiveTimeout = "60000"
    $DLTC.ChannelOpenTimeOut = "60000"
    $DLTC.RequestTimeout = "60000"
    $DLTC.MaxConnectionsToServer = "100"

    Set-SPDistributedCacheClientSetting -ContainerType DistributedLogonTokenCache $DLTC

    Restart-Service -Name AppFabricCachingService

    Get-SPDistributedCacheClientSetting -ContainerType DistributedLogonTokenCache

    Also update the App fabric of the servers to CU5+, there is a memory leak bug with oob version... http://support.microsoft.com/kb/2787717/en-us

    Hope this will help you to resolve your issue...

    If you are migrating from SharePoint 2007 to 2013, there could be other issues also you may need to consider like classic to claims based authentication..

    • Edited by Pardeep Bassi Monday, September 22, 2014 6:34 PM
    • Proposed as answer by Pardeep Bassi Monday, September 22, 2014 6:36 PM
    Monday, September 22, 2014 6:08 PM
  • Thanks for your effort Pardeep.

    It'll take me a while to validate if this works for me or not. It's definitely the best idea I've heard.


    Tuesday, September 23, 2014 7:49 AM
  • I also have this problem, and I don't believe that changing Distributed Cache timeouts will help anything in this case.

    The full postback (while they are actually redirects to the _login page and then back to the ReturnUrl) sometimes happens instantly on first async postback, sometimes on 5th async postback, sometimes it takes more.

    It's more or less random.

    Also in SP2013 when you disable Distributed Cache service, the full (old style) __viewstate is visible in the page, so it works the old way, and I still get full postbacks (while they are actually redirects to the _login page and then back to the ReturnUrl).

    One quick test that I did, was disabled the redirects to from the _login page, like it is mentioned here:


    The only thing that surely helps is to disable Forms Authenticaation in IIS for that web application, but that is also not an option.

    Tuesday, September 23, 2014 11:26 AM
  • Please disregard my above post, this is a known issue with SharePoint and Microsoft is working on to release the fix as cumulative update.

    Basically the fix will deploy an IHttpModule , this module will check if REQUEST is partial post back or request header contains ["X-MicrosoftAjax"] then set SuppressFormsAuthenticationRedirect to true.

    Tuesday, October 7, 2014 7:36 PM
  • Please disregard my above post, this is a known issue with SharePoint and Microsoft is working on to release the fix as cumulative update.

    Basically the fix will deploy an IHttpModule , this module will check if REQUEST is partial post back or request header contains ["X-MicrosoftAjax"] then set SuppressFormsAuthenticationRedirect to true.


    Where did you get this info that this is a known bug?

    Also it seems that this fix will only prevent for the automatic redirect to the initial page (Or the ReturnUrl that is mentioned in the first page).

    But we need the fix on why the user gets logged out in the first place and gets the 401 error.


    This is a post on how to add the suppression, but I think it would only prevent from redirecting to the ReturnUrl, but not fix the problem itself.

    Wednesday, October 8, 2014 9:50 AM
  • We created a ticket with Microsoft for this issue, and the above one is the only workaround till they release CU.
    Thursday, October 9, 2014 3:40 PM
  • We created a ticket with Microsoft for this issue, and the above one is the only workaround till they release CU.

    Hi again,

    Did you try the proposed workaround? Did it work? If so, could you please share the source for the workaround?

    Friday, October 10, 2014 5:08 AM
  • Oh Guys,

    I'm struggeling with the same issue for months...

    Is there any further information about the release of the CU or a Hotfix?

    I'd be very thankful if someone could provide more information if there is any.

    Tuesday, October 14, 2014 10:58 AM
  • Hello,

    Did you find any new info on this issue? 
    Friday, November 14, 2014 2:52 PM
  • Hello,

    Did you find any new info on this issue? 
    I recieved a call from MS-Support yesterday. "This Issue will be fixed in the next CU in December or January."
    Thursday, November 20, 2014 7:55 AM
  • http://support2.microsoft.com/kb/2910943 

    The Hotfix is here ;)

    • Proposed as answer by normalo Wednesday, December 10, 2014 11:26 AM
    Wednesday, December 10, 2014 11:23 AM
  • this hotfix is for foundation... what about Sharepoint Server 2013?

    Friday, December 19, 2014 1:15 PM
  • Also hotfix did not fix the issue...
    Friday, December 19, 2014 2:59 PM
  • Same here, only:

    1. it happens if the page is idle a bit, much more than 30 seconds.

    2. it also happens after a full page refresh with no cache - every time. this is a 100% reproducible scenario: either ctrl+r on IE to refresh the page, or clear browser cache to refresh the page, and click on the ajax update button within 4 seconds. if you wait longer the issue will be gone, if you do an ajax update within the 4 seconds - it will redirect to login and back in what looks like a refresh.

    In my scenario:

    1. using claims

    2. all installed on the same machine expect the AD and claims which is on separate ADCX machine.

    3. distributed cache is completely disabled, so no view state on the server

    4. the user does have a valid login cookie, and form digest when this happens, since I clear cache not cookies he is still logged in.

    This is driving my customers crazy!!! Hotfix - I will try it now...

    Regards, Shai Petel.

    Tuesday, February 24, 2015 6:14 PM
  • http://support2.microsoft.com/kb/2910943 

    The Hotfix is here ;)

    I can confirm the hotfix doesn't fix it for me. My scenario listed below with 100% chances of reproduction.

    If you make the ajax update within a few seconds of the page load - it does a refresh for the first time after clear cache (or ctrl+r in IE).

    Regards, Shai Petel.

    Tuesday, February 24, 2015 6:40 PM
  • Hi,

    We also ran into the described issue.  We ended up creating the following work around solution.

    The solution details

    The main goal of the implemented solution was to ensure that NTLM connection is established before UpdatePanel submits a request. 

    To achieve this goal we implemented the following components:

    1. a JavaScript function that  asynchronously calls one of the SharePoint's out of the box web services and effectively re-establishes NTLM connection (if it was lost)
    2. a JavaScript function that intercepts any postback request from any of the update panel on the page and cancels that.  But in order to later re-issue the request, this function also captures and preserves the required metadata about the request right before the request is canceled
    3. a JavaScript function that reissues the request after we ensure that NTLM connection is up and ready

    Below is the complete JavaScript code that performs the described above actions



    var isNtlmActive = false;
    var updatePannelsToUpdate = [];
    var eventTarget = '';
    var eventArgument = '';
    var causesValidation = false;
    var validationGroup = '';
    var requestBody = '';

    function initializeRequestHandler(sender, args) {
        var onSuccess = function () {
          //At this point the NTLM connection is re-established 

          var  pageRequestManagerInstance;
          isNtlmActive = true;

          pageRequestManagerInstance = Sys.WebForms.PageRequestManager.getInstance();

         // re-issuing the 'original' request
         pageRequestManagerInstance.beginAsyncPostBack(updatePannelsToUpdate, eventTarget, eventArgument, causesValidation, validationGroup);

        var onError = function () {
          // do something here if error occurred

        if (!isNtlmActive) {
          // capturing and preserving the body as well as some other meta data about the original request
          requestBody = args.get_request().get_body();
          updatePannelsToUpdate = sender._postBackSettings.panelsToUpdate;
          eventTarget = sender._postBackSettings.asyncTarget;
          eventArgument = '';
          causesValidation = false;
          validationGroup = '';

          // NOTE: the variable '_spFormOnSubmitCalled' is a global variable that gets injected by the logic iplemented in the 'init.js' file.  
          // Based on our observation of the logic in 'init.js' the varialbe '_spFormOnSubmitCalled' is set to true when HTML form's

          // 'onsubmit'  function is called and it is never set back to false (after we cancel the postback)
          // As the result, any subsequent attempts to submit the form do not work.
          // Thus, we excplicetely set the value back to false before we cancel the original post back request.
          //'init.js'is autoatically referenced by SharePoint and included on to the 'master' page.
          // The HTML form as well as the functionality to handle submit is also provided by SharePoint.
          if (typeof _spFormOnSubmitCalled === "boolean") {
             _spFormOnSubmitCalled = false;

          callServerSideServiceToReviveNtlmSession(onSuccess, onError);
        else {
          // resetting the body of the request with the value captured from the original request

          isNtlmActive = false;
          updatePannelsToUpdate = [];
          eventTarget = '';
          eventArgument = '';
          causesValidation = false;
          validationGroup = '';

    function getCurrentSiteCollectionUrl() {
        var url;

        url = window.location.protocol + "//" + window.location.host + _spPageContextInfo.siteServerRelativeUrl;

        return url;

    function callServerSideServiceToReviveNtlmSession(successHandler, errorHandler) {
        var siteCollectionUrl;
        var testServiceUrl;
        var spRequestExecutor;
        var request;

        siteCollectionUrl = getCurrentSiteCollectionUrl();
        testServiceUrl = siteCollectionUrl + "/_api/web/title";

        spRequestExecutor = new SP.RequestExecutor(siteCollectionUrl);
        request = {
            url: testServiceUrl,
            method: "GET",
            headers: { "Accept": "application/json; odata=verbose" },
            success: successHandler,
            error: errorHandler

    try {
        $(document).ready(function () {
            try {
                var pageRequestManagerInstance = null;
                //Note: Sys.WebForms.PageRequestManager gets injected into your page the minute you use ScriptManager (and UpdatePanel)
                pageRequestManagerInstance = Sys.WebForms.PageRequestManager.getInstance();

            catch (ex) {
                //alert('INNER EXCEPTION: document ready - ' + ex.message);
    catch (ex) {
     //alert('EXCEPTION: document ready - ' + ex.message);


    As a prerequisite for the code above, You must have references to the following JavaScript files(libraries)

    1. jQuery
    2. <script src="/_layouts/15/SP.RequestExecutor.js" type="text/javascript"></script>


    Based on my observations (in Development using Google Chrome), after implementing the solution the undesired behavior does not occur.  Meaning, SharePoint does not cause redirection to the login page when UpdatePannel control submits a partial(async) "post back".

    Best Regards

    • Proposed as answer by DizzyBlack Monday, June 22, 2015 3:54 PM
    • Unproposed as answer by DizzyBlack Monday, June 22, 2015 4:00 PM
    • Proposed as answer by Kaushal Khamar Monday, September 7, 2015 11:03 AM
    Tuesday, April 14, 2015 3:09 AM
  • Sounds very clever way about it, I will definitely try and see if it helps in my scenario.

    Regards, Shai Petel.

    Tuesday, April 14, 2015 4:32 PM
  • I have been investigating an issue like this for approximately two months.

    The issue manifested itself in our production environment during implementation of a new web application. A modal window had a number of tabs and a number of postbacks. Generally, the redirect to /_windows/default.aspx?ReturnUrl=<url> would be triggered resulting in the modal window being emptied.

    There was a pre-release environment where the issue did not manifest and no amount of testing could reproduce it.

    We considered every aspect of the solution, timeout values, session state, load balancing, sticky sessions, session persistence, the ASP Session State Service.

    After a ground up comparison, we discovered that the Request Management Service was enabled in the production environment on the Web Front End servers but was not enabled in the Pre-release environment. No configuration had ever been done for the Request Management Service so it was started but effectively unconfigured. We were never able to reproduce the issue in the Pre-release environment, however, noticing this difference between the environments, the Request Management Service was then enabled in Pre-release on the Web Front End servers only.

    The issue immediately manifested itself for the first time in Pre-release. We are currently still in the testing phase in Pre-release to confirm that the issue "goes away" again after the Request Management Service is disabled.

    I realise of course that some of you may be using the Request Management Service for its intended purpose or in fact the Request Management Service may not even be enabled in your environments but this is the most promising lead we have up to now and the only thing that enabled us to repro the issue.

    I'll report back on this thread in the event of success or failure..

    • Edited by Lewis Roberts Thursday, April 23, 2015 8:40 PM edits to clear up grammar
    Thursday, April 23, 2015 1:59 PM
  • Thanks, but I just checked - this service was stopped on my server, never started.

    It happens to me quite regularly especially when using ajax updates on a page shortly after the page has loaded.

    Usually if i wait a minute before having ajax updates it works ok

    Cannot explain this crazy thing... Only thing i know for sure is that it redirects me to the login and comes back.

    Regards, Shai Petel.

    Thursday, April 23, 2015 6:01 PM
  • Well, after further testing, the result is positive for us. Stopping the Request Manager on the WFEs resolved our issue.

    We were able to reproduce and then resolve the issue by toggling Request Manager on (issue experienced) and off (resolved, no issue).

    We rolled this forward in to the production environment and it was instantly resolved. My assumption for why turning off Request Manager for us worked is that the request pipeline was being intercepted by Request Manager during postback and sent to a server which the user had not authenticated to. The server that received the request responded in kind and forced the user to log on (claims, but NTLM) - the user would be bounced to the log on page, which was destroying (somehow) the viewstate information. Since this was done in the background, when the user next performed a postback, they were dumped back to an empty form.

    Secondarily, we had an issue with massive ULS log utilisation on the WFE servers with dozens of the following messages every few seconds: "Cannot find site lookup info for request Uri http://<wfe-servername>/", these were usually followed by System.IO.FileNotFoundException messages.

    Turning off Request Manager resolved this for us too.

    I read this article from Spencer Harbar and Request Management indeed pings/polls the servers to get information from them very frequently. http://www.harbar.net/articles/sp2013rm1.aspx

    Sorry it doesn't look as though it's going to resolve your issue though Shai.

    Thursday, April 23, 2015 8:25 PM
  • Shai, have you tried setting AllowAnonymousImpersonation to false?


    Still testing, but this seems to be working to resolve the same (or very similar) issue for me.  Good luck.


    Tuesday, April 28, 2015 4:49 PM
  • Thanks, I'll give it a try and update

    Regards, Shai Petel.

    Wednesday, April 29, 2015 12:26 PM
  • Shai, have you tried setting AllowAnonymousImpersonation to false?


    Still testing, but this seems to be working to resolve the same (or very similar) issue for me.  Good luck.


    no, didn't help.

    today it actually gotten worst (not due to this change) but it is now redirecting to login on almost every ajax update, like 99% of the time.

    fiddler is clear about this: response to the ajax request returns a redirect statement to the login page. the login page auto-logins and redirects back to where I was, which appears as a refresh to the user.

    The ajax request does not send the Authorization with it:

    POST https://xxx.cld.sr/....... HTTP/1.1
    Host: xxx.cld.sr
    Connection: keep-alive
    Content-Length: 29149
    Origin: https://xxx.cld.sr
    X-Requested-With: XMLHttpRequest
    Cache-Control: no-cache
    X-MicrosoftAjax: Delta=true
    User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.152 Safari/537.36
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    Accept: */*
    Referer: https://xxx.cld.sr/.............
    Accept-Encoding: gzip, deflate
    Accept-Language: en-US,en;q=0.8,he;q=0.6
    Cookie: Ribbon.List=1571973|-1|201|-2144448243; ksmeredirect=false; WSS_FullScreenMode=false

    and when getting back from the refresh after login, here is how the page loads, this time with the authorization:

    GET https://xxx.cld.sr/..... HTTP/1.1
    Host: xxx.cld.sr
    Connection: keep-alive
    Authorization: NTLM .......................
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
    User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.152 Safari/537.36
    Referer: https://xxx.cld.sr/........
    Accept-Encoding: gzip, deflate, sdch
    Accept-Language: en-US,en;q=0.8,he;q=0.6
    Cookie: Ribbon.List=1571973|-1|201|-2144448243; ksmeredirect=false; WSS_FullScreenMode=false

    I'll try to dig and see why ajax does not send the authorization with the request.

    any ideas?

    Regards, Shai Petel.

    Friday, May 15, 2015 2:44 PM
  • Alexander Khaykin, Tried your code "as is" and it seems that it does fix the issue (have tested it in chrome). Will test it further, thank you!

    • Edited by DizzyBlack Monday, June 22, 2015 4:09 PM
    Monday, June 22, 2015 4:07 PM
  • I tried to use Alexander Khajkins JavaScript Version to solve a very similar Problem with a 3. Party Library.

    But i have a little Problem:

    If i add the given js-code with a Content Editor to Page, it works until the point where it should call the original function.

    pageRequestManagerInstance.beginAsyncPostBack(updatePannelsToUpdate, eventTarget, eventArgument, causesValidation, validationGroup);

    After this call nothing happens. This does apply to all Ajax calls on the site (therefore i can't edit the page anymore unless i delete the Content Editor.

    Any idea why this happens?

    Best regards,


    • Edited by lolsharp Tuesday, June 30, 2015 1:46 PM
    Tuesday, June 30, 2015 1:46 PM
  • Did you install DEC 2014 CU? here is the link https://support.microsoft.com/en-us/kb/2910945. This includes the hotfix.

    Tuesday, July 28, 2015 1:25 AM
  • Are you sure the DEC 2014 CU addresses this issue?  I don't see the issue mentioned in KB link you provided.  Are you able to provide a link to a page showing this issue has been addressed?


    Monday, August 3, 2015 5:46 PM
  • Yeah, it's there:

    "When you browse to a SharePoint 2013 page that contains an UpdatePanel control, the page may be refreshed randomly. Therefore, if you type something in a text field on the page, the text field may become empty."

    I will confirm once I get a chance to test this.

    Regards, Shai Petel.

    Wednesday, August 5, 2015 2:01 PM
  • Hay anyone can tell me that is this issue has been resolved in this DEC 2014 CU hotfix?
    Can anyone confirm?
    Monday, September 7, 2015 10:02 AM
  • Did you install DEC 2014 CU? here is the link https://support.microsoft.com/en-us/kb/2910945. This includes the hotfix.

    just did. even got my hopes up.

    alas, this huge update file ran, restarted my server, but the issue remains.

    It seems non IE browsers are more affected by this issue. Chrome now has this issue every single time, before it was hit and miss, now it is consistent.

    update: in Edge browser, and in IE, it happens first time only. like before. Now in chrome it happens every single time. Any ajax updatepanel update will get a response "redirect" since the authentication cookies are not sent to the server.

    Regards, Shai Petel.

    • Edited by Shai Petel Tuesday, September 15, 2015 12:28 AM added more info
    Tuesday, September 15, 2015 12:24 AM
  • Thank you very much!  Alexander Khaykin your solution works great. We had problems with update panels only on pre-production machine and your solution solved it. In our case the Dec 2014 CU didn't worked. Thanks a lot.
    Sunday, September 27, 2015 1:24 PM
  • Thank you very much!  Alexander Khaykin your solution works great. We had problems with update panels only on pre-production machine and your solution solved it. In our case the Dec 2014 CU didn't worked. Thanks a lot.

    Can you describe exactly how you used this solution?

    I was at first reluctant, but when I put this code on my pages and add request executor it just goes to an endless loop of updates since the listener is never removed. Removing it after the first successful call also did not help, and I was back to the "normal" refresh page issue.

    Regards, Shai Petel.

    Monday, September 28, 2015 6:16 PM
  • We had a similar problem but we had no way of reproducing the page reload and it seemed to happen from time to time just.

    We could reproduce a similar behaviour by:

    1. Navigate to any page where a ajax postback is made.
    2. By using Fiddler and clicking "Remove all" (ctrl + x) to remove the sessions so far in Fiddler we could "force" this page reload behaviour to happen.
    3. Directly after doing a ctrl + x in Fiddler, selecting something in the SharePoint page which would do a postback and the page would reload.

    This happened, what seemed, very random on production and sometimes everything worked perfectly. However the annoyence of this issue forced us to find a solution.

    The javascript posted from Alexander Khaykin actually did solve our problem, but it made some other things not work as it should. One being that we didn't get any feedback (progress/indication) if the wet parts were loading or not when an ajax postback was made.

    A colleague of mine found the following link ( http://discussions.citrix.com/topic/362243-netscaler-and-sharepoint-2013-claims-auth/ ) which contains a small script to be inserted into the global.asax file found in the folder C:\inetpub\wwwroot\wss\VirtualDirectories\80

    <script runat="server">

        protected void Application_BeginRequest()  {
            if (FormsAuthentication.IsEnabled && Context.Request.RequestType == "POST" && Context.Request.Headers["x-requested-with"] == "XMLHttpRequest")
                Context.Response.SuppressFormsAuthenticationRedirect = true;

    This solved the problem for us. More testing has to be made but so far it looks very promising.

    • Proposed as answer by Carl Fredrik Tuesday, October 6, 2015 12:58 PM
    Tuesday, September 29, 2015 8:09 AM
  • One thing I would point out with this script is that it relies on jQuery to be available and it calls jQuery(document).ready. This is not good practice within the SharePoint ecosystem because jQuery ready can give false-positives about the document being fully loaded. You would be better off tying the initialization of this sequence into the SOD framework and making sure that SP.RequestExecutor.js and jQuery are fully loaded first.
    Monday, October 26, 2015 9:50 PM
  • Ok, so nothing of the above worked for me.

    The one thing I can mention is: it only happened to us in our CloudShare environments, when using cld.sr short names.

    when using vm.cld.sr the issue didn't happen.

    My bet is that it was something to do with the way they set up their proxy server that redirects the requests. I am not sure, but in any case we stopped using CS and now we don't experience this issue anymore.

    Regards, Shai Petel.

    Tuesday, October 27, 2015 10:46 PM
  • Finally, found 2 fixes for this problem.

    1. Simple .Net framework fix. https://support.microsoft.com/en-us/kb/3062825

    - OR -

    2. I also found that if you add this script to all pages it fixes this issue without the hotfix:

    ExecuteOrDelayUntilBodyLoaded(function () {
        try {
            if (Sys.WebForms.PageRequestManager.getInstance().digestFixed !== true) {
                Sys.WebForms.PageRequestManager.getInstance().digestFixed = true;
                Sys.WebForms.PageRequestManager.getInstance().add_beginRequest(function () {
                    if (typeof (UpdateFormDigest) === "function" && typeof (_spPageContextInfo) === "object")
                        UpdateFormDigest(_spPageContextInfo.webServerRelativeUrl, 3 * 60 * 1000);
        catch (e) { }

    Regards, Shai Petel.

    • Edited by Shai Petel Wednesday, November 11, 2015 9:50 PM added link to kb
    Wednesday, November 11, 2015 9:49 PM
  • Alexander Khaykin's solution worked for me in Internet Explorer but still no success when using Google Chrome.
    Monday, October 16, 2017 12:24 PM