During a recent consulting engagement with an enterprise customer, we resolved a strange issue with search in SharePoint 2013. I wanted to create this blog post as I was unable to find another source with the steps to resolve the behavior. I hope this will help anyone encountering this issue and save you days of troubleshooting!
The Environment:
We designed and built a large-scale Internet-facing anonymous site hosted in Azure IaaS. The farm consists of a number of web front-end and application servers running SharePoint 2013 Enterprise. We used the Publishing Portal site template for all sites. Page Output Caching was originally configured with the following default profile settings:
We use an Enterprise Search Center subsite that sits at /search. All sites in the site collection redirect to this search center to serve queries.
The Issue:
After the platform went live we received reports of a strange behavior with search. We investigated and were able to reproduce the issue on our stage environment. The stage environment is an exact copy of the production farm/config.
The issue centered around anonymous users hitting the site and executing a query. After the query was issued, the user was redirected to our search center site collection as expected. However, after the user was redirected the URL string would still contain the correct query string but the search box and results didn’t match the query. So to demonstrate at a high level:
- User issues query from root site collection for “Apples”
- The user is redirected to the search center subsite and the query string in the browser looks correct (/search/pages/results.aspx?k=apples)
- However, the query in the search box does not match and neither do the results
- You scratch your head?!?!?
An example:
The plot thickens when you start to troubleshoot the issue. When two people are executing queries at the same time you will always get the previous users query/result when the mismatch occurs. So if user A queries for Apples. Then user B queries for Oranges, User B’s result set will be for Apples. Strange for sure!
The Cause:
We beat our heads against this issue for about a week before our team started to narrow down the root cause. We knew it was something to do with caching. But which caching mechanism became the question. Furthermore, even if we did narrow it down to a specific caching feature, what would the ultimate fix be?
SharePoint 2013 has a number of caching features built into it. Some are on by default while others take specific configuration to enable. Others are made available once certain site collections features are enabled such as Publishing Infrastructure. If you recall from above, we were in fact using the Publishing Portal site template. This means the Publishing Infrastructure site collection and Publishing Server site features were enabled by default. Also, since this is an anonymous Internet-facing SharePoint deployment, we’re heavily dependent on caching to improve overall page load performance.
With performance in mind, we enabled Page Output Caching. Page Output runs a set of predefined caching templates for sites using the publishing features. These templates are intended to improve performance by reducing the number of round-trip requests to the database server. Page Output Caching allows you to define one template for anonymous users and one for authenticated users.
We enabled Output Caching and selected the following default templates:
The Public Internet (Purely Anonymous) has the following out of the box settings:
Our team zeroed in on the Public Internet Output Cache Profile and started to play with the various settings. This was done by creating a new template under the Site Collection Cache Profiles Page (<SiteCollectionURL>/Cache%20Profiles/AllItems.aspx) and tweaking the settings.
We would then apply it to the root site collection level and test after clearing our browser cache. After much trial and error we were able to determine the exact settings the profile needed to run to resolve the issue.
The Fix:
1. Create a new output caching profile from the cache profiles page at the top of the site collection (<SiteCollectionURL>/Cache%20Profiles/AllItems.aspx).
2. Give the template a descriptive name then set the following settings:
3. Apply the newly created template as the Anonymous Caching Profile under the Output Cache Settings page (<SiteCollectionURL>/_layouts/15/sitecachesettings.aspx) and apply the setting:*
4. Clear your browser cache and open a new browser. Try your search queries again. The problem will now be resolved and all queries/results will match for anonymous users.
*NOTE: The template must be applied at the Site Collection level and then inherited by the search subsite. If you allow subsites to run their own output caching profiles and only set this at the search subsite, the issue will not be resolved.
Conclusion:
When you apply the custom template you are telling SharePoint to cache everything except search results pages. These pages are the only ones that use the “?k” argument. So that is why we designate that in the custom template. This allows you to cache all other pages for performance but to work around the search results issue.
I hope this post saves you the time and energy we had to put into this one to get it resolved!
