The LandPhil be honest, be honorable, be kind, be compassionate, and work hard.

September 20, 2011

SharePoint: Configuring Foundation Search

Filed under: SharePoint — phil @ 12:08 pm

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
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’
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. (0x80041205)

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: 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.


  1. I have a question regarding this post – I am experiencing the same exact issue as you above. I am running foundation 2010 and search is not working. i get the errors in the application log just as you specifiy.. I have my default zone for the site configured as FBA and another zone configured as NTLM. the URL for the deafult zone seems to be the one that it wants to use to do the crawl but then it fails because it needs NTLM to execute the crawl. I am trying to figure out what to do inside of Alternate Access Mappings to get my main url ( to use a different zone configured for FBA and then set my search URL ( as the default zone with NTLM. when I attempted to do this using Edit Public URLs and just swapping them – then I couldnt log into either site – i would just get 401 unauthorized


    Comment by Derek — October 21, 2011 @ 12:16 pm

  2. Derek,

    I poked around and it looks like you’ve posted in all of the usual places and it also seems like there’s not a lot of information out there. One of the problems with the Foundation search is that it’s NOT particularly configurable. You might look into the free Search Server Express 2010. It adds a search service application (similar to the search service applications you would find in the SharePoint Server and Enterprise versions) which IS fairly configurable. It ALSO adds the Secure Store service which leverages the ability to masquerade as other users in certain contexts.
    I know that we have a couple of problems with search even now in our MOSS 2007 environment and it’s based on forms based authentication. It works, there’s just a handful of anomalies. (One being that the search results are built and displayed based on the crawler account, not on the user, so it’s not security trimmed properly.) We’ve actually made big strides here to integrate our authentication systems so that we can run 2010 in basic auth mode.

    Comment by phil — October 21, 2011 @ 12:35 pm

  3. phil, you are a genius. I had everything set up except the backconnectionhostname part. That kind of thing makes me want to choke someone. Thanks for saving whoever that would’ve been. Cheers!


    Comment by Troy — February 17, 2012 @ 9:32 pm

  4. You can force a CONTENT CRAWL: Start a crawl: ‘C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN\stsadm -o spsearch -action fullcrawlstart’.

    Just in case you delete a SharePoint search index database (DELETE): You can delete the search index database file from the database server and then stop the “SharePoint Foundation Search” service, but to recreate the search index database you will need to create a “different” database name and in SharePoint Central Administration > under Application Management > Manage content databases > click the appropriate SharePoint web application associated content database that contains the site(s)/site collection(s) you want to index > Search Server: select your SharePoint Server > OK, and then you can do the same again to go back to the original database name if you like. Run C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN\stsadm -o spsearch -action fullcrawlstop’, then start a content crawl again. See also database references in SharePoint 2010 Management Shell: Run ‘get-spdatabase’.

    Comment by Brian — June 22, 2012 @ 5:29 pm

  5. Phil, useful article thanks.

    Couple of things
    This article gives futher info about SPF Search

    Also, there’s another way around the loopbackissue see

    After all of this, I still havn’t got it to work as there seems to be a weird proxy error.

    “Error from SharePoint site: HttpStatusCode ProxyAuthenticationRequired The request failed with HTTP status 407: Proxy Authentication Required.”

    If anyone knows how to fix this let me know! Cheers

    Comment by John — July 19, 2012 @ 7:45 am

  6. John, do you have a proxy server? This article would seem to address that:

    If not, maybe get your network folks involved. May be that there is a group policy proxy setting that’s getting in your way.


    Comment by phil — July 19, 2012 @ 9:18 am

  7. Setting the default access mapping back to the original setting was the key for me. At least then I was able to get some access denied issues to SQL corrected. My search service is working great.

    Just wanted to say thanks for posting such detailed info. Couldn’t have fixed my problem without it.

    Comment by Jay — November 10, 2012 @ 6:05 pm

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress