SharePoint 4.0: Search Core Results Web Part Internal Error

Description:

Search results page error caused by Core Results Web Part after modifying the Fetched Properties.

Error:
"Internal server error exception:
Troubleshoot issues with Microsoft SharePoint Foundation
Correlation ID: aba98106-d203-48bf-bdc9-bf2f8dd15bcd"


Solution:

In addition to the Column Name tags, the Fetched Properties must be properly opened and closed with Columns and /Columns tags, respectively. One possible cause for this error is that thet Fetched Properties XML is missing the opening and closing tags.

SharePoint 4.0: How Search Indexing Works

The crawl process is essential to the Indexing side of SharePoint 2010 Search. Exploring the Search Service Application screens provides some insight to the configurable components that make up Search in SharePoint 2010, but you may actually have to dive deep into the system documentation and other resources to gain an understanding for the steps that occur within the subsystems, when SharePoint is instructed to crawl content.

The crawl process goes something like this:
1. Full crawl started
2. Start address moved to queue
3. Protocol determined
4.Connector selected
5. iFilter opens files
6. Content index created on crawl server
7. Index moved in batches to query server
8. Data written to Crawl and Property databases
(Microsoft, 2010)

One myth about SharePoint 2010 crawl process is that when content is crawled it never touches the file system of the Crawl Server and goes directly to Query Server...this isn't true. The way it works in environments that have crawler and query roles on separate servers is; a content index is built on the crawl server initially, but is moved in batches to the query server(s). The point when all batches have propogated to the query server, then it may appear as if there is no foot print on the Crawl server's file system...this is because all the batches have been moved up.

From a server topology perspective, Search requires three different server roles. These include Crawl Server, Query Server, and Database Server. Each of these roles plays a role in the crawl process. For scalability and availability, the architecture supports configurations that include one or many of each of the server roles. Determining the best topology is a balancing act of capacity requirements with available resources.

Reference

Microsoft (2010). Microsoft SharePoint 2010 Product Information Capabilities Search. Retrieved September 22, 2010 from
http://sharepoint.microsoft.com/en-us/product/capabilities/search/Pages/default.aspx.

Sample Sizing Estimate for SharePoint Server 2010 Search Environment

Below is a sample search storage estimate for environment with 500GB content databases. This was calculated by adding up the sum of MDF files. There are so many considerations for storage, and this is just a rough sketch of the storage aspects related to the Search Service Application. This does not consider base installation overhead nor does it factor in other SharePoint Service Applications (SSA), Office integrations, User Profiles, Usage Database, PowerPivot, etc..

1.
ContentDBSum = Measure the size on disk of MDF files. For this example, 500 GB.

2.
IndexTotalIndexSize = ContentDBSum * .035 or 17.5 GB
QueryComponentIndexSize = TotalIndexSize / Number of Index Partitions
StorageQueryComponentIndexSize * 3 single query component with space for index merging
QueryComponentIndexSize * 4 single query component with space for index repartioning or 70 GB

3.
TotalPropertyDBSize = ContentDBSum *.015 or 8 GB
TotalPropertyDBLogSize = ContentDBSum *.0031 or 2 GB

4.
TempDBSize = TempDBSizeContentDBSum * .00034 or 1 GB

5.
TotalCrawlDBSize = ContentDBSum *.046 or 23 GB
TotalCrawlDBLogSize = ContentDBSum *.011 or 6 GB
ContentDBSum *.011 = TempDBSize = 6 GB

6.
SearchAdminDBSize = # items in index * .3 or override as 5 GB
In this case, I don't know how many items there will be in the index so I am going to allocate 5GB.

7.
Backup Size = basically, add all of the database sizes together.

Reference

Microsoft Technet (2010). Performance and capacity test results and recommendations. Retrieved April 27, 2010 from http://technet.microsoft.com/en-us/library/ff608068(office.14).aspx.

Links: Planning SharePoint Server 2010 Search

(1 of 4) Microsoft: Search Technologies for SharePoint 2010 Products
http://www.microsoft.com/downloads/details.aspx?familyid=D7C0091E-5766-496D-A5FE-94BEA52C4B15&displaylang=en

(2 of 4) Microsoft: Search Environment Planning for Microsoft SharePoint Server 2010
http://www.microsoft.com/downloads/details.aspx?familyid=5655EACA-22DF-4089-BCD3-38A1F5318140&displaylang=en

(3 of 4) Microsoft: Search Architectures for Microsoft SharePoint Server 2010
http://www.microsoft.com/downloads/details.aspx?familyid=22FFC029-2C08-457D-8311-CA457C6D160E&displaylang=en

(4 of 4) Microsoft: Design Search Architectures for Microsoft SharePoint Server 2010
http://www.microsoft.com/downloads/details.aspx?familyid=5A3CA177-FB9A-4901-9797-0C384277DB7C&displaylang=en

Documenting Your SharePoint Server Search Design Specifications

During a SharePoint Server Search implementation, it is especially important to document the technical design specifications of Search, prior to configuring. By creating a Search Design Specifications document and continiously managing changes in it, the document acts as a good reference for future projects, knowledge transfer, upgrades, migrations, and disaster recovery scenarios.

When I document search specifications, I do it in a Word document and capture detailed information in a similar format to how the actual configuration screens appear. Here are some samples:

Content Sources

Crawl Rules

Crawl Schedules

Metadata Property Mappings

Scopes