none
Search no longer works anonymously after upgrading site collections to SP2013 from SP2010 compatibility

    Question

  • We have a SharePoint 2013 farm, which was upgraded in May of 2016 from SP2010. After the upgrade we chose not to upgrade our site collections to SP2013 and chose to leave them in SP2010 compatibility mode until now. As we are going through and upgrading all of our collections to SP2013, as well as solutions that were used with it, we have come across a problem with search results. The problem stems from the fact that the our site collections will no longer allow us to use "Search Scopes" and we now have to use Result Sources. 

    With the upgraded site collections, and search result pages, we are finding that if we replace the original Search Results WebPart with the new SP2013 Search Results WebPart, we can no longer view results anonymously. If I revert the page back to the original SP2010 Search Results WebPart and remove the scope from the configuration of the WebPart, I can get results anonymously. Although we're no longer able to limit the results as we had done previously, we are at least getting results with the original WebPart. Once I put the SP2013 WebPart in, it will not return results for anonymous users. It will, however, return results to users who are logged in. 

    Considering that this is a public facing website, we have to be able to deliver search results anonymously after we complete the upgrade of the site collections.

    Has anyone here experienced this before? I have found a few solutions on the web but nothing specific to our problem and trying out the various solutions I have found did not change this behavior. 

    Any help or suggestions would be appreciated!

    Thursday, April 13, 2017 5:43 PM

Answers

  • Well, it appears that the problem here is with our web application and the fact that it is in "Classic" mode authentication. This was the authentication method that was carried over from our SharePoint 2010 farm when we upgraded to SP2013. As a test, I upgraded the web application on a development system and it fixed this problem with search. 

    I'm not 100% sure that this is the fix to the issue and will need to test all of our site collections and such to make sure they are all working as expected. I had tried to perform an upgrade to claims mode at one point in time and it seemed to have caused us problems with the site collections when we logged into SharePoint to make content changes to pages and such. 

    Does anyone here know about this? Is the fact that we were running a classic mode web application the reason why this would fail, or was this just a fluke? I would like to make certain that this would be the fix before we move forward with performing this change in production.

    • Marked as answer by JM Estrada Thursday, May 11, 2017 2:44 PM
    Thursday, May 04, 2017 7:02 AM

All replies

  • Hi JM Estrada,

    How did you revert the page back to original SharePoint 2010 Search Results web part?

    Please ensure the “Limited-access user permission lockdown mode” site collection feature is disabled. Try to disable and re-enable anonymous access,  and start the full crawl to check it works.

    Best Regards,

    Linda Zhang


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Friday, April 14, 2017 8:59 AM
    Moderator
  • Linda,

    I believe they were in the web parts list when I was working on this earlier, but I had also hidden the 2010 web parts on the page, then added the 2013 webpart when I was testing this.

    The "Limited-access user permission lockdown mode" is enabled, but I had tried disabling this earlier on and it didn't make a difference, however I did not try disabling this feature, disabling and then re-enabling the anonymous access on this web application and then run a full crawl. I will try this and see how this works.

    Thanks for the suggestion!

    Monday, April 17, 2017 4:02 PM
  • Linda,

    I tried the steps you mentioned and it did not make a difference.

    I deactivated the "Limited-access user permission lockdown mode", then I went over the web application and disabled anonymous access and saved it, then I went back in and re-enabled it. After I did this, I went to the search application admin and reset the index, then I ran a full crawl. I'm still not able to see results. I am getting results, and as I've seen with the original SP2010 webpart, they will get displayed.

    What is really odd is that, when I do a search, and I get my results page back there is nothing displayed, however if I view the page source, I can see way at the bottom of the page source the results that would be returned. It's almost as if they are hidden from the user but still being generated.

    This is in the page source:

    <script type='text/javascript'>//<![CDATA[
    var ctl00_ctl44_g_6aa2075a_ba48_4b85_bd09_a31bc0060d5d_ctl00results={
    "_ObjectType_":"Microsoft.SharePoint.Client.Search.Query.ResultTableCollection","ElapsedTime":304,"Properties":{
    "RowLimit":10,"SourceId":"\/Guid(8413cd39-2156-4e00-b54d-11efd9abdb89)\/","WasGroupRestricted":false,"IsPartial":false,"EnableInterleaving":true,"piPageImpression":"279_3601_1033","SerializedQuery":"<Query Culture=\"en-US\" EnableStemming=\"True\" EnablePhonetic=\"False\" EnableNicknames=\"False\" IgnoreAllNoiseQuery=\"True\" SummaryLength=\"180\" MaxSnippetLength=\"180\" DesiredSnippetLength=\"90\" KeywordInclusion=\"0\" QueryText=\"Medicare\" QueryTemplate=\"{searchboxquery}\" TrimDuplicates=\"True\" Site=\"f7ff9f56-4343-414e-b156-9cf491831e13\" Web=\"6278e88b-eab2-4ff0-a9be-929cb4eb2c71\" KeywordType=\"True\" HiddenConstraints=\"\" \u002f>"
    },"QueryErrors":null,"QueryId":"623b99a3-6a41-4f9d-af81-36e5cfc90289","SpellingSuggestion":"","TriggeredRules":[
    
    ],"ResultTables":[
    {
    "_ObjectType_":"Microsoft.SharePoint.Client.Search.Query.ResultTable","GroupTemplateId":null,"ItemTemplateId":null,"Properties":{
    "GenerationId":9223372036854775806,"ExecutionTimeMs":110,"QueryModification":"Medicare -ContentClass=urn:content-class:SPSPeople","RenderTemplateId":"~sitecollection\u002f_catalogs\u002fmasterpage\u002fDisplay Templates\u002fSearch\u002fGroup_Default.js","piPageImpressionBlockType":2,"StartRecord":0,"IsLastBlockInSubstrate":true,"IsFirstBlockInSubstrate":false,"IsFirstPinnedResultBlock":false,"IsLastPinnedResultBlock":false,"IsFirstRankedResultBlock":true,"IsLastRankedResultBlock":true
    },"QueryId":"623b99a3-6a41-4f9d-af81-36e5cfc90289","QueryRuleId":"00000000-0000-0000-0000-000000000000","ResultRows":[
    {

    This is then followed by ten (10) rows of results preceeded by a

    "Rank":12.(some value) and then the information to the result. There are 10 of these.

    I'm beginning to wonder if this is some kind of template or something else that might be restricting the results from being displayed.

    Monday, April 17, 2017 5:01 PM
  • So our developers have partially solved the problem. It turned out that a custom control on the page was causing the issue with search results not being shown for anonymous users, we still have an issue.

    An anonymous user can perform a search and they will get results back now, however when they attempt to access results on page 2 or higher, they are then prompted for credentials. This problem is really driving me nuts as I'm not certain why this would happen, however when I view the page with Chrome and access the developer tools, I can see that when the user selects page 2, the page loads and halts at this url:

    http://www.mysite.org/search/_api/contentinfo then I see associated with this a whole bunch of references to http://www.mysite.org/ScriptResource.axd?(some long string of characters).

    It appears that maybe something related to these two are causing the problem and asking for authentication. I did find some information on the internet about turning off the "Require Use Remote Interfaces Permission" on the site collection, which I did but it did not change the result. I also tried to turn this off at the web application level from the Authentication Providers setting but this also did not make any differences.

    Has anyone seen this before?

    Thanks.

    Wednesday, May 03, 2017 9:38 PM
  • Well, it appears that the problem here is with our web application and the fact that it is in "Classic" mode authentication. This was the authentication method that was carried over from our SharePoint 2010 farm when we upgraded to SP2013. As a test, I upgraded the web application on a development system and it fixed this problem with search. 

    I'm not 100% sure that this is the fix to the issue and will need to test all of our site collections and such to make sure they are all working as expected. I had tried to perform an upgrade to claims mode at one point in time and it seemed to have caused us problems with the site collections when we logged into SharePoint to make content changes to pages and such. 

    Does anyone here know about this? Is the fact that we were running a classic mode web application the reason why this would fail, or was this just a fluke? I would like to make certain that this would be the fix before we move forward with performing this change in production.

    • Marked as answer by JM Estrada Thursday, May 11, 2017 2:44 PM
    Thursday, May 04, 2017 7:02 AM