Sunday, 30 May 2010

Issue indexing pages containing the Search Core Results Web Part in SharePoint 2010

I have spotted an issue with search on SharePoint 2010 when it tries to index a page containing the Search Core Results Web Part, which I am using in particular pages on a site to rollup content across an entire Web Application. When it tries to index one of these pages, the following message appears: "The SharePoint item being crawled returned an error when attempting to download the item”.

Usually, Search Center sites are created with the <noindex> attribute enabled, so you don't normally see this behaviour as the search results pages containing the Web Part are not normally indexed.​ You can choose an option in the crawl logs to prevent the page being indexed in the future, and it appears that this issue does not prevent the rest of the site from being indexed as long as the Search Core Results Web Part is not used on the home page of the site - I have noticed it can stop the whole site from bring indexed if it is.

Audience by Skills or Interests on SharePoint 2010

I have noticed that you can now create audiences based on the terms people select for Skills or Interests in their profile. I have used this to show personalisation links on My Sites whenever anyone selects certain keywords.

For example, if you enter "SharePoint" either as an interest or a skill in your user profile, a link to the SharePoint Team Site will appear in the top navigation bar of your My Site pages.

You could obviously apply this to any number of pages, links and Web Parts across the site, using it as a sort of self-subscription mechanism for exposing content of a particular subject matter.

Events 1001, 1004 & 1015

I have been getting a number of event log errors on my SP 2010 server similar to the Event 1004 shown below:

Log Name:      Application
Source:        MsiInstaller
Date:          07/05/2010 10:27:31
Event ID:      1004
Task Category: None
Level:         Warning
Keywords:      Classic
User:          NETWORK SERVICE
Computer:      SPSERVER.domain.internal
Description:
Detection of product '{90140000-104C-0000-1000-0000000FF1CE}', feature 'PeopleILM', component '{1C12B6E6-898C-4D58-9774-AAAFBDFE273C}' failed.  The resource 'C:\Program Files\Microsoft Office Servers\14.0\Service\Microsoft.ResourceManagement.Service.exe' does not exist.

I was also getting similar errors for other folders in the 'C:\Program Files\Microsoft Office Servers\14.0' path, so I resolved it by assigning Read permissions on the 14.0 folder to the NETWORK SERVICE user.

Access Denied when indexing sps3:// paths for People Search in SharePoint 2010

If you set a dedicated Default Content Access Account (recommended) for search indexing, you may find the following error when indexing the sps3:// path for People 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 has "Full Read" permissions on the SharePoint Web Application being crawled. ( HttpStatusCode Unauthorized The request failed with HTTP status 401: Unauthorized. )"

I checked the Full Read permissions for the content access account as recommended, but these were correctly implemented. I then discovered that you have to add the content access account to the permissions of the User Profile Service Application by clicking the "Administrators" button when highlighting the User Profile SA in Central Administration.

Then, add the content access account to the list of administrators and assign it "Retrieve People Data for Search Crawlers" permissions, as shown below.

UserProfilePermissionsForSearch

Finally, start a full crawl in search to check the problem has been resolved.

Things to watch for when installing Office Web Apps

A few notes to pass on from my recent experience of installing Office Web Apps in SharePoint 2010:

1) I used the following PowerShell script to set up the Service Applications and associated proxies:

$AppPool = Get-SPServiceApplicationPool -Identity "SharePoint Service Applications Default"
New-SPWordViewingServiceApplication –Name "Word Viewing Service Application" –ApplicationPool $AppPool
$WdViewSA = Get-SpServiceApplication -Name "Word Viewing Service Application"
New-SPWordViewingServiceApplicationProxy –Name "Word Viewing Service Application Proxy" -URI $WdViewSA.Uri.AbsoluteUri
New-SPPowerPointServiceApplication –Name "PowerPoint Service Application" –ApplicationPool $AppPool
New-SPPowerPointServiceApplicationProxy –Name "PowerPoint Service Application Proxy" -ServiceApplication "PowerPoint Service Application"
New-SPExcelServiceApplication -Name "Excel Services Application" -ApplicationPool $AppPool

2) After creating the SA's, I started the Word Viewing, Excel Services, and PowerPoint services from the "Services on Server" option in Central Admin (I know I could have also done this in PowerShell, but it is just as straight forward from the UI!)

3) I was getting errors when trying to load any type of document in Office Web Apps so I checked the Event logs. I found Event 3760 which advised me that my service account for the SA application pool failed to logon to the SharePoint content database. I had a quick look around, but couldn't find anything concrete on what permissions the service account needed in SQL, so I gave it datareader and datawriter, ran an IISRESET, and tried again - same errors.

However, this time the event log reported Error 5214, telling me that I need to assign EXECUTE permissions to the SA application pool service account for the content database. To accomplish this, I created a db_executor role on each content database using the following SQL script:

CREATE ROLE db_executor
GRANT EXECUTE TO db_executor

I then opened up the properties of the SA application pool account in the Logins section of SQL Management Studio and assigned the db_executor role on each content database.