Search not Indexing Webpart Content

Problem

You have a SharePoint 2010 farm.  You use unique permission settings in some sites for some pages and web parts.  You create new pages and content, using Dataview, Content, and other web parts.  You run a SharePoint 2010 Search crawl of the new content. You check the crawl and discover that the pages are being crawled, but discover that the new content is not being indexed. You investigate this further and find that all new content on all pages is not being crawled.

Solution

The problem likely involves the site settings Search and Offline Availability.  The setting can be found here:

Site Actions > Site Settings > Site Admin > Search and offline availability

By default, the Indexing ASPX Page Content setting is set to Do not index Web Parts if this site contains fine-grained permissions. OOTB, this settings causes no problems.  However, once you begin to implement unique permissions for some sites, such as for example, hiding content on some pages from some user groups, this setting becomes problematic.  Once unique permissions are implemented, the NOINDEX property is set for web parts.

The solution is simple: set the Search and offline availability setting to Always index all Web Parts on this site.  Then re-run the crawl.

References

• SharePoint 2010 Search : not showing any results for anonymous users?
• Search and offline Availability in SharePoint 2010

TIP: Change Site Collection Search Results Page

To change the page that displays search results:

1) On the root site of your site collection, click the Site Actions dropdown

2) Look for the Site Settings option on this menu, and then click it.

3) On the Site Settings page, look for the Site Collection Administration section, and then click Search Settings.

4) In the Site Collection Search Results Page box, you'll see the relative URL to the default search results page.

5) Enter into this box, the relative URL to your custom search page.  For example, if you have created your own themed page, "Results.aspx," and you placed this file in the Site Pages folder, your URL would be:

/SitePages/Results.aspx

6) Leave the other settings at their default, and then click OK.

References

• How to get the site collection search results page in Sharepoint 2010
• Technet: The final guide to SharePoint 2010 Site Settings

SharePoint Foundation Search Refresh Failed

Problem

You have a SharePoint 2010 instance.  You are running the SharePoint Foundation Help Search service.  You check Job History (CA > Monitoring > History > Failed Jobs), and you find a list of SharePoint Foundation Search Refresh failed jobs:

Job Title: SharePoint Foundation Search Refresh

Server: (your SharePoint server)

Web Application:

Content Database:

Status: Failed

Complete: (date/time)

Duration: 0:00:00

Error Message: Logon failure: unknown user name or bad password.

Solution

By default, the SharePoint Foundation Search Refresh job runs hourly.  This job runs under the service account you configured for the Foundation Search service, e.g., sp_fSearch.  This account connects to the SharePoint backend and interacts with several databases.  Make sure that this account has the following permissions for these databases:

• Server Farm Configuration (SharePoint_Config): dbdatareader
• SharePoint Admin Content (SharePoint_AdminContent): dbdatareader
• SharePoint Foundation 2010 Search (WSS_Search_[servername]): db_owner

If you can't recall the names of the databases, go to Step 1 of the Farm Backup page, and you will see a listing of components along with their descriptions, which will guide you to noting the names of the databases listed above.  Once you know the appropriate databases, go into SQL Server Management Studio to configure the accounts appropriately.  After performing this step, you can either perform a manual run of the SharePoint Foundation Search Refresh job, or wait for it to run as scheduled, in order to see the affect of these changes.

References

• Initial deployment administrative and service accounts (SharePoint Server 2010)
• Account permissions and security settings (SharePoint Server 2010) 

Windows SharePoint Services Search Failure and Errors 10036 and 17836

Introduction

This procedure provides one resolution to a failure in Windows SharePoint Server 2007 Enterprise Search along with the appearance of Errors 10036 and 17836 in the Windows Server 2003 Enterprise Edition Application Event log.  It provides some general background for the error and the steps that were taken to successfully resolve it.

Background

An unexpected power outage led to the abrupt shutdown of a blade server hosting a customer SharePoint 2007 instance.  Both the SharePoint 2007 instance and its SQL Server instance were co-located on this blade.  The outage occurred over a weekend.  The blade server was restarted the following business day, and the SharePoint instance restarted automatically, presenting all pages normally.  In all ways, the SharePoint instance appeared to be fully operational.  A few business days later, a user attempted to perform a search and immediately experienced an error page.  Further attention by technical support verified the user experience and the matter was placed under investigation.

Review

SharePoint Shared Services was found to be running.  The crawl record showed that crawls executed previous to the outage had completed successfully without unexpected errors.  Crawls were configured to execute daily.  No crawls were logged after the power outage.  A manual crawl was attempted but was unsuccessful.

A review of the Windows System Event log found no unexpected errors.  A review of the Windows Application Event log identified the appearance of several unexpected warnings and errors:

• Error 17836: MSSQLSERVER
• Error 10036: Office Server Search
• Error 10036 Windows SharePoint Services 3 Search
• Warning 2423: Windows SharePoint Services 3 Search
• Warning 2423: Office Server Search

These errors and warnings appeared at the time of the outage but did not recur.

A review of Windows Component Services found the following:

• Office SharePoint Server Search | Started | Automatic...
• Windows SharePoint Services Search | [Stopped] | Manual...

These findings suggested that there was database corruption, specifically the search index database.  Given these findings, the following resolution steps were performed.

Method

The Office SharePoint Server Search service was restarted. The Windows SharePoint Services Search service was started and set to Automatic.  A search was then performed, in the SharePoint 2007 website, but was found to still be unsuccessful, returning an error page.

In SharePoint Shared Services, a Reset all crawled content was performed.  After the reset completed, a new crawl was initated manually. The crawl completed successfully.  A new search was then performed, in the SharePoint 2007 website, and this time it was completed successfully, returning expected results.  The issue was found to be resolved.

Summary

From review of the findings and resolution steps, the following is our best understanding of the sequence of events involved.  A power outage apparently led to a corruption in the SQL Server database servicing a SharePoint 2007 instance.  The specific database corrupted involved the SharePoint search index database.  As a result of the search index corruption, a routine scheduled crawl failed, leading to a shutdown of the Windows SharePoint Services Search service, which stopped further crawls being performed.  The stoppage of the SharePoint Services Search service caused users to experience an error whenever searches were performed.

References

• WSS 3.0 SP2 broke search
• Plan alternate access mappings (Windows SharePoint Services)
• EventID.Net