SharePoint 2013 Search Provisioning Errors – It’s All About 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.
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)
SmartTrack Operational Analytics for SharePoint
Clear and to the point, as usual, thanks Sir !!
Never had that permission missing in my provisioning. Might be a case of the order you create them, or a case of missing permissions (Shell admin, farm admin and Run As Administrator). It is also important to stop all crawls (including continuous crawl) before touching the search topology.
Also remember when setting the index, that the cmdlet is FUBAR (New-SPEnterpriseSearchIndexComponent checks the existence of RootDirectory on local disk not on specified server instance).
Can you repro this on every setup?
Anders Rask