7.5 KiB
Suche erneuern
Dienstag, 6. Juni 2017
10:40
Recreate Search
Apologies in advance for the lack of links, it seems Microsoft hasn't verified my account yet... but I'll provide search terms so you can verify things yourself.
Alright, I've got this one licked (probably).
First, check through services on the server (either on the central admin GUI or using the services.msc console) that the SharePoint Search Host Controller service is NOT running (you'll probably see it in "starting" mode, or totally stopped, even though it's set to Automatic start).
I'm assuming that your SharePoint farm service account is NOT administrator on the box (this is a good thing, and although someone here suggested giving it admin privileges fixed the problem, that's not a very good solution security-wise). You are probably also using different service accounts for your host controller service and the server search service; I'm betting that the problem lies with the lack of admin on the farm service account.
It seems that if the farm service account, SPfarm, is NOT administrator on the box, then it's incapable of setting the correct permissions on a particular reg key when it provisions the search service.
Here's how to fix it, first the best practice way (by "best practice way" I mean assuming that you are using at least 3 service accounts, SPfarm (farm admin), SPsearch (the search host controller service) and SPcrawl (the crawl account and the account that SharePoint Server Search runs as in the Service Accounts section of the GUI) - I have no idea if this is MS best practice in any way shape or form.)
Do this to fix the permissions problem (search your favorite search engine for SharePoint MMMan "Search Host Controller Service in Starting State (SharePoint 2013)" to find the source of this:
$acl = Get-Acl HKLM:\System\CurrentControlSet\Control\ComputerName
$person = [System.Security.Principal.NTAccount] "Users"
$access = [System.Security.AccessControl.RegistryRights]::FullControl
$inheritance = [System.Security.AccessControl.InheritanceFlags] "ContainerInherit, ObjectInherit"
$propagation = [System.Security.AccessControl.PropagationFlags]::None
$type = [System.Security.AccessControl.AccessControlType]::Allow
$rule = New-Object System.Security.AccessControl.RegistryAccessRule($person, $access, $inheritance, $propagation, $type)
$acl.AddAccessRule($rule)
Set-Acl HKLM:\System\CurrentControlSet\Control\ComputerName $acl
$sh = Get-SPServiceInstance | ? {$_.TypeName -eq "Search Host Controller Service"}
$sh.Unprovision()
$sh.Provision($true)
Follow the guidelines to fix the permissions problem. A couple of notes from that post, however:
1) The author's comment regarding the fact that "this service is being provisioned as the user who you're running the PowerShell as" doesn't seem to be accurate -- it'll be provisioned as whatever account is set in the Manage Service Accounts page in the Central Admin, under the Windows Service -- Search Host Controller Service entry, so you don't need to run as the farm account, which won't work if the farm account isn't a machine administrator anyway.
2) If you have more than one server in your SharePoint search topology/farm, you'll have to modify the line:
$sh = Get-SPServiceInstance | ? {$_.TypeName -eq "Search Host Controller Service"
to be:
$sh = Get-SPServiceInstance | ? {$_.TypeName -eq "Search Host Controller Service" -and $_.Server -match <servername>}
(replace <servername> with your server name in quotes, i.e. "SPAPP1") and run it on every server on the farm where search is provisioned.
3) The permissions applied via the script to the registry are likely overpermissive as well. I haven't tested it otherwise (as our farm is now in production after implementing these fixes), but I believe you don't need the full SERVER\Users group to have FULL CONTROL of that key. FULL CONTROL is required, however you could probably limit it to the SPfarm, SPsearch, and SPcrawl accounts rather than all users. Note that I haven't tested this.
Finally, you'll likely have to apply some permission fixes to the databases as well. Check that your SPsearch and SPcrawl accounts have SPSearchDBAdmin to all 4 search databases (Search_Database, LinksStore, AnalyticsReportingStore, and all CrawlStore databases; the accounts probably don't have that role - from a blog post on security, (search for psconfig "My Sites and The SPDataAccess SQL Role") it would seem that although it SHOULD set the permissions correctly upon creation/provisioning, it doesn't, and you need to fix it manually).
Here's some handy SQL code to help you out with that (modify the USE lines as needed for each database and be sure to use the ACTUAL service accounts for this):
USE [SharePoint_Search_Database]
GO
EXEC sp_addrolemember N'SPSearchDBAdmin', N'DOMAIN\SPsearch'
GO
USE [SharePoint_Search_Database]
GO
EXEC sp_addrolemember N'SPSearchDBAdmin', N'DOMAIN\SPcrawl'
GO
You will also have to ensure that a user is created for at least the SPsearch account for those databases. In all likelihood, the crawl account will exist and have a user, but the search account won't. But if you see a red downward arrow in front of the account name in the SQL Server Manager for the SPsearch account, you need to create the login. Here's the SQL code for that:
USE [SharePoint_Search_Database]
GO
CREATE USER [DOMAIN\SPsearch] FOR LOGIN [DOMAIN\SPsearch] WITH DEFAULT_SCHEMA=[DOMAIN\SPsearch]
GO
USE [SharePoint_Search_Database]
GO
ALTER AUTHORIZATION ON SCHEMA::[DOMAIN\SPsearch] TO [DOMAIN\SPsearch]
Repeat for all other databases.
After you're done, your issues should be gone, including:
Event ID 2548 error message: Content Plugin can not be initialized -- list of CSS addresses is not set
Event ID 3760, SQL Database is on SQL server instance not found
Event ID 1026 for .NET Runtime, hostcontrollerservice.exe, the process was terminated due to an unhandled exception (Microsoft.Ceres.HostController.WcfServer.WcfService.StartService())
Event ID 1000, Faulting application name: hostcontrollerservice.exe, version: 15.0.4420.1017, time stamp: 0x50672c2d
Faulting module name: KERNELBASE.dll, version: 6.1.7601.17965, time stamp: 0x506dcae6
Note that this is a bit of a catch-22 - you have to provision search (or start provisioning search), allow it to create the 4 databases and adjust the permissions on the database before it will work 100% (note that fixing the reg key should at least allow the service to start, but it will only have partial access to the DB's it needs or perhaps none at all.)
Here's the simple way, i.e. where you're running everything as SPfarm but still maintaining that the farm account is NOT admin:
Grant admin privileges, provision search either using the GUI or via Powershell, then remove the admin rights :) (note that I haven't tested that this works 100%; it should provision fine and start up, but but in my dev instance I believe this is what I did and had no problems).
I hope this helps. It took me some while to figure this out with much help from the internet.
Note that the other suggestions here, regarding RAM on the server etc., should probably also be followed, but this will get things moving on search (or should).
Good luck!