Setting up SharePoint 2010 Search Service is easy…. if you are running a plain vanilla web application. But, if you are running a more sophisticated setup of SharePoint, you may be in for a rough ride.
In our case, we have a complex setup where we have multiple SharePoint web applications running on a single IIS server, each using HTTPS protocol and host headers.
Overview
- Two SharePoint web applications on a single IIS server using HTTPS. The HTTPS URL is the only entry point to the web application (I.E. no HTTP or non-SSL support for the applications)
App1 exists at https://portal.myurl.com
App2 exists at https://employee.myurl.com - Both web applications need to support search
- Both web applications are using Basic Authentication to eliminate the need to type the domain name when logging in. (Yes, we can get away with this… we are on an SSL channel after all)
- Both web applications have a super user read account to support the search service
Easy right? Nope….
Our First Try
Our first attempt at getting search to work followed these steps:
- Installed the search service from the Central Administration web site using the following navigation:
Application Management –> Manage Service Applications –> New –> Search Service Application - Configured the Search Service Application to taste
- Add the application URLs to the default content source Local SharePoint Sites
- Set a crawl rule for https://*.myurl.com with support for basic authentication enabled and the search user/password entered.
NOTE: This is required to allow the search service to logon to the web application.
And then we executed a full crawl….
And we received two errors:
Access denied to sts4s://portal.myurl.com
Access denied to sts4s://employee.myurl.com
after some digging around, it appears SharePoint search is accessing the web application through a middle layer (the sts4s part). As we are using Host Headers and basic authentication, the sts4s protocol appears to be ignored by IIS.
Our Second Try
Out second attempt at getting the search to work revolved around extended the web applications to a host header using integrated authentication. This extended application would be visible to the internal network only
- Extend the web applications to
http://portal.myurl.local
http://employee.myurl.local - Remove all of the crawl rules created in our first attempt
- Reset the default content sources Local SharePoint Sites to use the myurl.local based addresses
And then we executed a full crawl….
No errors! (There was much rejoicing)
And then we actually searched on a keyword we knew existed. SharePoint’s search returned nothing. We were receiving the very frustrating “we did not find any results for …” dialog. (So much for rejoicing)
Our Third Try
We know the crawl worked as we had thousands of Searchable items listed in the search server. To make the situation even more confusing, the Recent query rate showed the exact number of test queries we had executed.
After more digging, it appears the myurl.local extended applications need a server name mapping defined. This allows the search engine to know that the HTTPS link is one and the same as the HTTP link. Here is what we did
- Create new Server Name Mappings for each URL.
Example:
Address for indexing would be http://portal.myurl.local
Address for display in search results would be https://portal.myurl.com
And then we executed a full crawl…
And everything worked!
