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.
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, 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.
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
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
Metrics