You’ve got SharePoint installed.  You’re generating content.  Now you’d like it if that little Search bar on the top right actually returned something other than:

  • Your search cannot be completed because this site is not assigned to an indexer.  Contact your administrator for more information.
The first step is to turn on the Foundation Search Service.  You do that with the following:
  1. Open Central Administration
  2. Go to System Settings -> Manage services on server
  3. Click on SharePoint Foundation Search
  4. Assign a service account to start the service (this is a managed account, so select on or add a new one)
  5. Assign a content access account (more on that below)
  6. Enter a database server and database name (or accept the defaults)
  7. Choose an indexing schedule
  8. Click Ok
  9. When you return to the Manage services on server page, click Start next to SharePoint Foundation Search
That’s only the first part, however.  You’ve got the Search service running and the indexer on a schedule, but you actually have not yet identified what to index.  In standard and enterprise version of search, you get a full blown service application and a lot of that configuration takes place there.  However, that’s not the case with foundation search, so let’s continue.

The next thing that you need to do grant the content access account (that you entered above) read access to your applications.  Do this:
  1. Go to Central Administration
  2. Go to Application Management -> Manage web applications
  3. Highlight the web application that you want foundation search to index
  4. Click User Policy in the ribbon
  5. In the Policy for Web Application box that appears, click Add Users
  6. Leave the Zone selection at (All zones), click Next
  7. In the Choose Users box, enter the username of the Content Access Account you used above when you configured SharePoint Foundation Search
  8. Check Full Read for permissions
  9. Click Finish
Alright.  Now you have the indexer running and the content access account has privileges to read all of the content in your web application.  But you still haven’t identified the content to crawl.  That’s done at the content database level. So:
  1. Go to Central Administration
  2. Go to Application Management -> Manage Content Database Settings
  3. Click on the content database that contains the site(s)/site collection(s) that you want to index
  4. In the settings for that content database, in the section Search Server, use the drop down list to select the server with SharePoint Foundation Search service running
  5. Click OK.
Viola!  You have turned on and set a schedule for indexing, granted permissions for the crawl account, and identified content to crawl.  More than likely, you’re done.  Based on the schedule that you created in the first part, and the amount of data that you need to crawl, you may need to wait a little while to check to see if everything is working.

In my case, it did not.  The search box continually returned “no results” for anything that I typed in.  So I turned to the Application Event Log and found this:
Log Name: Application
Source: SharePoint Foundation Search
Logged: <datetime>
Event ID: 14
Task Category: Gatherer
Level: Warning
User: <search service account>
Computer: <sharepoint server>
OpCode: Info
General:
The start address sts4s://<website address>/contentdbid={<guid of content db>} cannot be crawled.
Context: Application ‘Search_index_file_on_the_search_server’, Catalog ‘Search’
Details:
Access is denied.  Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository.  If the repository being crawled is a SharePoint repository, verify that the account you are using as “Full Read” permissions on the SharePoint Web Application being crawled. (0×80041205)

This was rather disheartening as the error message indicated that the fix was to do all of the things that I had already done.  It turns out that the answer was hidden in the start address.  You see, I had created the web application with <address1> and that was the Default address.  I had then created a multitude of Custom addresses and was using one of those as the main address for the website <address2>.  However, no matter how you are viewing the web page, the crawler will always use the Default address <address1>, but when you search the site while viewing it at <address2>, it cannot match them and the search engine returns “no results found”.  I resolved the problem by changing around the Default and Custom zone access mappings in: Central Administration -> Application Management -> Configure alternate access mappings.


However, I also had Audit Failures for logons with the Content Access Account.  After much gnashing of teeth and dead end searching, I stumbled upon this article: http://support.microsoft.com/kb/896861 which details a registry change that allows for loopback to a specific list of addresses.  The details are at the link, but I will also include what I did below:
  1. Click Start, Click Run, type regedit, and then click Ok.
  2. In the Registry Editor, locate and then click on the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
  3. Right-click MSV1_0, point to New, and then click Multi-String Value.
  4. Type BackConnectionHostNames, and then press Enter.
  5. Right-click BackConnectionHostNames, and then click Modify.
  6. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click Ok.
  7. Quit Registry Editor, and then restart the IISAdmin Service
I included all of the alternate access mapping addresses in the list above.


My foundation search works fine now.  I am able to query and return information for sites and sub-sites for all of the content databases that I’ve identified for indexing.
Posted: 20 Sep, 2011 | [2] Comments
Categories: SharePoint | Tags: | By: phil.