SharePoint 2013 Search Service Permissions

Configuring Search in SharePoint 2013 can be a tricky process that is best accomplished via PowerShell scripts. For starters, those messy database names with GUID’s in them that get created from UI provisioning are just hideous, but the real issue is that a proper topology (meaning search components running on more than a single machine) can only be deployed via PowerShell cmdlets. Despite our best efforts to script the entire process and avoid the kind of small mistakes that lead to endless hours of frustration, it’s inevitable that some small setting or configuration step will crop up that creates a giant headache.Take, for example, the new “SPSearchDBAdmin” role. This role, which didn’t exist in 2010, is added to each search database when it is created in SQL server. If you are following best practices and assigning service accounts for search operations (one for administration, one for crawling, and neither should be the SharePoint Farm or Admin accounts), the account you assign as the Search admin will be added to the SQL logins and given the “public” role. That’s all well and good for least privileged purposes but that role alone is insufficient for the Search application to function. Unfortunately, there’s no warning about this when the Search service application is created – provisioning will succeed but nothing really works. In order to kick Search into gear, you first need to assign the “SPSearchDBAdmin” role to the Search admin account in SQL server.The SPSearchDBAdmin role in SQL Server

Assigning the SPSearchDBAdmin Role in SQL Server Management Studio

Also bear in mind that the Search admin account requires read/write permissions to the folder in which the index files reside. As this account should *not* be a local administrator it’s very likely that it won’t have access to the folders that hold the primary and replica index files. Be sure to assign the appropriate permissions on each server in the topology which contains an index partition (the default location is “C:\Program Files\Microsoft Office Servers\15.0\Data\Office Server\Applications” which, ideally, should be changed as part of the provisioning process). Possible error messages which indicate your search admin account may not have the correct SQL or folder permissions include:

“Content Plugin can not be initialized – list of CSS addresses is not set.”

“Unable to retrieve topology component health states. This may be because the admin component is not up and running”

“Topology activation failed. No system manager locations set, search application might not be ready yet”

“Could not access the Search database. A generic error occurred while trying to access the database to obtain the schema version info.”

There are a lot of blogs, forum posts, and articles with all sorts of advice on how to deal with these errors, most of which prescribe repetitive un-provisioning and re-provisioning of service applications. Although those solutions may apply to your environment at some point, before going down that road first ensure that the Search admin account has the proper database and file permissions, as no amount of provisioning will overcome basic security limitations.

(Note: For a good walkthrough on Search provisioning via powershell, refer to this post from Ryan Bushnell and the Search cmdlet reference on TechNet)

Take the trouble out of troubleshooting.
Improve service levels and avoid downtime with
SmartTrack Operational Analytics for SharePoint

 

 

Articles

Ten Steps to Optimize SharePoint Performance by Eric Alan Shupps

Webcasts

Eric Shupps – Secrets of SharePoint Part 5: Configuring Microsoft Office SharePoint Server 2007 for Optimal Performance
Creating End User SharePoint Solutions for Performance and Scalability by Eric A. Shupps
SharePoint 2010 Performance Enhancements for Administrators with Eric Shupps Microsoft
SharePoint Server 2010 for the ASP.NET Developer

Eric Shupps on Following Best Practices and Avoiding Common Errors with Microsoft Office SharePoint Server 2007 Development
SharePoint Performance and Capacity Planning Essentials from Eric Alan Shupps
Eric Shupps on Troubleshooting Common Performance Problems in SharePoint 2010

Videos

Channel 9 Interview with Eric Shupps SharePoint
TechTalk – Different Views on Social Computing

Eric Alan Shupps talks SharePoint Post-Deployment Planning and Management

Podcasts

SharePoint Pod Show – Design for Performance eith Eric Shupps
SharePoint Pod Show – Test Driven Development with Eric Shupps
Run As Radio – Eric Shupps Improves SharePoint Performance

Social

Eric Shupps – ConferenceHound
Eric Shupps on Talk TechNet
Eric Alan Shupps on Channel 9
Planet SharePoint Eric Shupps profile
Eric Shupps Lanyrd
Eric Shupps MVP Profile
Eric Alan Shupps About.me
The SharePoint Cowboy Tumblr
Eric Shupps on Speakerfile
Eric Shupps – Facebook
Eric Shupps LinkedIn Profile
Eric Shupps Google+
Twitter – @eshupps

Wrapping Long Words in Firefox

Eric Shupps

I know it’s all the rage among web developers to blame IE for everything that’s wrong on the Internet but sometimes – just sometimes – the folks in Redmond get it right and the fine volunteers of the Mozillaverse get it wrong.  Perhaps there’s no better example of this than word breaking in columns.  For years, IE has had the ever-so-useful CSS property “word-wrap” which, when supplied with a value like “break-word”, will split up a long string of text and preserve the precious layout you’ve slaved for hours to create.  It’s so handy, in fact, that it actually made it into the CSS3 spec (don’t be a hater – even the standards busybodies know a good thing when they see it).

Unfortunately, Firefox doesn’t recognize this property.  Yes, I know it’s supposed to in version 3.5+ but I have yet to see it actually working.  I’ve spent the better…

View original post 450 more words

Wrapping Long Words in Firefox

Eric Shupps

I know it’s all the rage among web developers to blame IE for everything that’s wrong on the Internet but sometimes – just sometimes – the folks in Redmond get it right and the fine volunteers of the Mozillaverse get it wrong.  Perhaps there’s no better example of this than word breaking in columns.  For years, IE has had the ever-so-useful CSS property “word-wrap” which, when supplied with a value like “break-word”, will split up a long string of text and preserve the precious layout you’ve slaved for hours to create.  It’s so handy, in fact, that it actually made it into the CSS3 spec (don’t be a hater – even the standards busybodies know a good thing when they see it).

Unfortunately, Firefox doesn’t recognize this property.  Yes, I know it’s supposed to in version 3.5+ but I have yet to see it actually working.  I’ve spent the better…

View original post 450 more words

Empty SharePoint People Search Results and SSL Web Applications

The great thing about SharePoint Enterprise Search is that once it’s up and running it mostly just works. Except, of course, when it doesn’t. Recently I was troubleshooting a farm in which People search stopped returning any results. In this environment, the main OU containing user accounts had been moved and a new profile import run to re-populate the profile database. The import was successful but the changes required a full crawl of the content source which had been working just fine up until that point. After the next crawl completed all queries against the People scope returned an empty result set.

After confirming that none of the permissions had changed, and that the default crawl account still had access to the User Profile service app and all web applications, another full was run without success. It was during this run that the crawl log displayed the following error for the primary web application (which had probably been there all along but was buried beneath a number of other content-related crawl errors):

An unrecognized HTTP response was received when attempting to crawl this item. Verify whether the item can be accessed using your browser.

A bit of research indicated that this is usually due to insufficient permissions – either the crawl account does not have Full Read permissions set in the web application User Policy or it hasn’t been granted the “Retrieve People Data for Search Crawlers” right for the user profile service application. But in this case both sets of permissions were valid. An attempt to connect to the search crawl web service (/_vti_bin/spscrawl.asmx) confirmed this but also revealed something interesting – all HTTP requests were being redirected to HTTPS. Another look at the Content Source in Search Administration showed that the primary web application was, in fact, set up to crawl content via an HTTPS URL.

The SharePoint People Search mechanism requires a specific URL format within a Content Source, one that begins with “sps3://” instead of the usual “http://”. The site cannot actually be browsed via this URL; instead, it’s merely a connector reference that the search crawler associates it with the proper URI under the covers. When a web application is secured via SSL the protocol portion of the URL has to be changed from “sps3://” to “sps3s://” – the “s” letting the crawler know it should use HTTPS instead of HTTP.

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack

Specifying an SSL target for the People search content source

Changing the URL value in the Content Source from “sps3://” to “sps3s://” resulted in a successful crawl and People search started returning results at the conclusion of the next full crawl. So if any of the web applications in your farm use HTTPS by default, be sure to check the Content Source settings to be sure that the search crawler can properly access them.