Below are some of the most common configuration requirements that need to be taken into consideration when planning for a SharePoint 2013 environment. A more comprehensive list of best practices -guidelines can be found in Technet.
Web Application configuration considerations
- It is recommended to target the search crawl to the public site url of the default zone of the web application (http://blogs.msdn.com/b/sharepoint_strategery/archive/2014/07/08/problems-when-crawling-the-non-default-zone-explained.aspx)
- Crawling the default zone, the search results from the same Web Application are retrieved relative to URL from which they were queried. So for example if the url of the default zone was “company.com” and the url of the intranet zone is intranet.company.com, the search results when queried through the url of the intranet zone will be relative to intranet.company.com and not company.com
- If a non-default zone is crawled the search results will be relative to the url of the crawled zone and not the url of the queried zone.
- In case custom authentication is used such as SSO, its recommended to extend the web application to use one of the 5 available zones and then configure the extended web application to use the custom authentication.
- This is done so that even if the custom authentication module fails, the site can be accessed through the url of the default zone using windows authentication
- If possible avoid configuring multiple authentication types on a specific each web application zone, it complicates troubleshooting and depending on the design of the custom authentication functionality it doesn’t work well with crawling
Alternate Access Mapping Considerations (http://blogs.msdn.com/b/sharepoint_strategery/archive/2013/05/27/alternate-access-mappings-explained.aspx)
- Creating a new AAM zone without extending the Web Application or manually altering the Public URL of any zone from Central Admin could result in ambiguous scenarios for routing requests to SharePoint leading to connectivity issues or unexpected authentication failures
- Unless configuring for Reverse Proxy or adding additional Internal address(to support SSL-offloading) , it is recommended to avoid manually altering AAMs
Troubleshooting Performance Issues with Search Crawling content can significantly decrease the performance of the servers that host the content. The effect depends on whether the host servers have sufficient resources (especially CPU and RAM) to handle the load. Therefore, when you plan crawl schedules, consider the following best practices:
- Schedule crawls for each content source during times when the servers that host the content are available and when there is low demand on the server resources.
- Stagger crawl schedules so that the load on crawl servers and host servers is distributed over time. You can optimize crawl schedules in this manner as you become familiar with the typical crawl durations for each content source by checking the crawl log. For more information, see Crawl log in View search diagnostics in SharePoint Server 2013. (https://technet.microsoft.com/en-us/library/dn535606.aspx )
- Performance issues can be alleviated by moving resource intensive components such as the indexing component to a dedicated server
- The system does a full crawl even when an incremental crawl or continuous crawl is scheduled under the following circumstances:
- A search administrator stopped the previous crawl.
- A content database was restored, or a farm administrator has detached and reattached a content database.
- A full crawl of the content source has never been done from this Search service application.
- The crawl database does not contain entries for the addresses that are being crawled. Without entries in the crawl database for the items being crawled, incremental crawls cannot occur.
In addition, I recommend Peter Dempsey’s blog on monitoring and tuning SharePoint search components, which I have found pretty useful on several occasions.