This project has moved and is read-only. For the latest updates, please go here.

SharePoint 2013 Activating Search Topology - Error

Nov 8, 2012 at 3:11 PM
Edited Nov 8, 2012 at 3:15 PM

Hi at all,

can anybody help me ? I have no idea what i can do ....

Is there a soulution for this problem?

thanks in advance

- Checking Search Query and Site Settings Service Instance...Starting...Done.
- Checking Search Service Application...Creating Search Service Application...Done.
- Setting content access account for Search Service Application...Done.
- Checking administration component...Creating...Done.
- Checking content processing component...Creating...Done.
- Checking analytics processing component...Creating...Done.
- Checking crawl component...Creating...Done.
- Checking index component...Creating...Done.
- Checking query processing component...Creating...Done.
- Activating Search Topology...--------------------------------------------------------------
- Script halted!

Exception             : System.Management.Automation.MethodInvocationException:

                         Ausnahme beim Aufrufen von "Activate" mit 0

                      Argument(en): "Timed out waiting for search service

                       'SPSearchHostController' provisioning timer job to

                       complete" ---> System.TimeoutException: Timed out

                       waiting for search service 'SPSearchHostController'

                       provisioning timer job to complete

                           bei Microsoft.Office.Server.Search.Administration.Se



                           bei Microsoft.Office.Server.Search.Administration.To


                           bei Microsoft.Office.Server.Search.Administration.To


                           bei Microsoft.Office.Server.Search.Administration.To


                          bei CallSite.Target(Closure , CallSite , Object )

                           --- Ende der internen Ausnahmestapelüberwachung ---

                           bei System.Management.Automation.ExceptionHandlingOp

                       s.CheckActionPreference(FunctionContext funcContext,

                       Exception exception)

                           bei System.Management.Automation.Interpreter.ActionC

                       allInstruction`2.Run(InterpretedFrame frame)

                          bei System.Management.Automation.Interpreter.EnterTr

                       yCatchFinallyInstruction.Run(InterpretedFrame frame)

                           bei System.Management.Automation.Interpreter.EnterTr

                       yCatchFinallyInstruction.Run(InterpretedFrame frame)

                           bei System.Management.Automation.Interpreter.Interpr

                       eter.Run(InterpretedFrame frame)

                           bei System.Management.Automation.Interpreter.LightLa

                       mbda.RunVoid1[T0](T0 arg0)

                           bei System.Management.Automation.ScriptBlock.InvokeW

                       ithPipeImpl(Boolean createLocalScope,

                       ErrorHandlingBehavior errorHandlingBehavior, Object

                       dollarUnder, Object input, Object scriptThis, Pipe

                       outputPipe, InvocationInfo invocationInfo, Object[]


                           bei System.Management.Automation.ScriptBlock.<>c__Di


                           bei System.Management.Automation.Runspaces.RunspaceB



                           bei System.Management.Automation.ScriptBlock.InvokeW

                       ithPipe(Boolean useLocalScope, ErrorHandlingBehavior

                       errorHandlingBehavior, Object dollarUnder, Object

                       input, Object scriptThis, Pipe outputPipe,

                       InvocationInfo invocationInfo, Object[] args)

                           bei System.Management.Automation.ScriptBlock.InvokeU

                        singCmdlet(Cmdlet contextCmdlet, Boolean

                       useLocalScope, ErrorHandlingBehavior

                       errorHandlingBehavior, Object dollarUnder, Object

                       input, Object scriptThis, Object[] args)

                          bei Microsoft.PowerShell.Commands.ForEachObjectComma


                           bei System.Management.Automation.CommandProcessor.Pr


TargetObject        :

CategoryInfo         : NotSpecified: (:) [ForEach-Object],


FullyQualifiedErrorId : TimeoutException,Microsoft.PowerShell.Commands.ForEachO


ErrorDetails         :

InvocationInfo       : System.Management.Automation.InvocationInfo

ScriptStackTrace     : bei <ScriptBlock>, C:\SP2013\AutoSPInstaller\AutoSPInst

                       allerFunctions.ps1: Zeile 3581

                       bei CreateEnterpriseSearchServiceApp, C:\SP2013\AutoSPI

                       nstaller\AutoSPInstallerFunctions.ps1: Zeile 3417

                       bei Setup-Services,


                        Zeile 177

                       bei <ScriptBlock>,


                       Zeile 322

                       bei <ScriptBlock>, <Keine Datei>: Zeile 1

PipelineIterationInfo : {}

PSMessageDetails     :

Nov 8, 2012 at 5:32 PM

A timeout is occurring that is unrelated to the script. First place to check is the ULS logs to see if you can find more specific error messages. Its possible  you don't have enough RAM or other hardware issue.

Nov 9, 2012 at 7:36 AM


My VM only have 4 GB RAM. :D

I will test it with more RAM.


Nov 9, 2012 at 10:13 AM

I can confirm this one. More discussion can be found here:

Trawling through the ULS I see the following:

Content Plugin can not be initialized - list of CSS addresses is not set.


Failed to extract required parameter FastConnector:ContentDistributor, hr=0x80070002 [pluginconfig.cpp:81] search\native\gather\plugins\contentpi\pluginconfig.cpp

There is a large number of errors in the event log in regards to:

Volume Shadow Copy Service error: The process that hosts the writer with name OSearch15 VSS Writer and ID {0ff1ce15-0201-0000-0000-000000000000} does not run under a user with sufficient access rights.

Faulting application name: hostcontrollerservice.exe, version: 15.0.4420.1017, time stamp: 0x50672c2d
Faulting module name: KERNELBASE.dll, version: 6.2.9200.16384, time stamp: 0x5010ab2d
Exception code: 0xe0434352
Fault offset: 0x00000000000189cc
Faulting process id: 0xb28
Faulting application start time: 0x01cdbd9cdb476553
Faulting application path: C:\Program Files\Microsoft Office Servers\15.0\Search\HostController\hostcontrollerservice.exe
Faulting module path: C:\Windows\system32\KERNELBASE.dll
Report Id: 19dd379c-2990-11e2-93f1-0050569657e8
Faulting package full name:
Faulting package-relative application ID:

This would tie in nicely with the following:

Unfortunately I'm using Server 2012 so this hotfix isn't available.

Not really sure where to go next. I tried manually activating it using PowerShell but it again timed out.

Nov 13, 2012 at 3:13 AM

I believe I have found a solution to this issue. I am currently running Windows Server 2012, and SQL Server 2012. When running the Auto SP Installer, I was getting the error when trying to activate the Search Topology. The solution was to add the Search Service account to the local administrators group, and to grant the Search Service account DB Creator and Security Admin rights on the SQL Server.

Nov 13, 2012 at 8:11 AM

I found another solution. You have to reboot your computer before the script want to configuration the search service. After reboot run the script again and it runs successfully.

Nov 13, 2012 at 9:11 AM


At what point did you reboot then? Is it before any search configuration takes place? Is it after the Search Topology get's stuck at activating?

Any help would be much appreciated.

Nov 13, 2012 at 9:23 AM

Until now, I always rebooted the computer AFTER the error occured but I would like to find a better spot within the script to force this break, so I don't have to wait for the timeout event to occur every time. I do not have that much time to test and waiting 15 minutes for each new try to time out or pass is way too long. I believe the testing could work better if I's reboot the system before any search configuration takes place. As soon as I figure out how/where to place the optimal break I will post my results.

Feb 7, 2013 at 5:04 PM
It works for me if I create a Firewall Inbound Rule for TCP Port 808 on all my SharePoint Servers before starting the Topology activation. Maybe the Firewall settings are causing the problem.
Someone can try to confirm this? I already tried to collect the information here:
Apr 21, 2013 at 1:26 PM
Although I am not using AutoSPInstaller, I had the same issue - my farm was three-tier, streamlined topology - DB, App and WFE. All with Windows Server 2012, SQL 2012, SharePoint 2013 RTM. I tried everything I found in internet, but the host controller service didn't started.
My resolution was to add all features from .NET 3.5 and .NET 4.5, including all kind of WCF activations (except MSMQ activation).
May 18, 2013 at 4:07 AM
For me, the reboot did not help at all. I had to add SP_SearchService Account to the local Administrators Group and that did the trick. The issue was that the "SharePoint Search Host Controller" Service owned by the SP_SearchService account was stuck at Restarting and it would never start. As-soon-as the account was added to the Local Admins group, the service just started fine.
May 23, 2013 at 7:53 AM
Hi, I'm experiencing the same issue - adding the SP_SearchService account to the local administrators group "fixes" it for me.

See this Tweet on the subject
May 23, 2013 at 6:13 PM
@wortony - @alpesh's tweet seems to be a different topic, unrelated to local admin privileges.

I'm puzzled as to why the SP_Search account would ever need to be added to the local admins group. I have never needed to do this and my Search provisions flawlessly almost every time. Could there be a local group policy in effect, perhaps interfering with what the script is trying to do? Often I see GPOs that restrict certain activities on a server to certain groups (which adding to local Admins would appear to resolve).

Jun 12, 2013 at 7:05 AM
Edited Jun 12, 2013 at 10:28 AM
i use AutoSPInstaller 3.87 to install a 2 server sharepoint 2013 farm.
When i install the first server (including search service) i always stuck at "Activating Search Topology...".
In the event logs i get

Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (7aaa0d49-4d43-4369-a6c7-069a7f87c658).

Reason: Access to the path 'D:\SharePoint\Index' is denied.

Technical Support Details:
System.UnauthorizedAccessException: Access to the path 'D:\SharePoint\Index' is denied.
at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize()
at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)

I does not make a difference when i create the index location in advance or not. It doesn't make any difference when i grant the groups wss_admin_wpg and wss_wpg (all relevant service accounts are members of these groups) full control to the index location.

Moreover I have problems with the usage log location

The Execute method of job definition Microsoft.SharePoint.Administration.SPUsageImportJobDefinition (ID 173173f9-3cbe-4f4c-988c-504a188cdd96) threw an exception. More information is included below.

The directory D:\SharePoint\Logs\Usage does not exist.

The location exists and the service accounts should also have access to this group.

The installation includes the march 2013 public update.
I tried the same installation on the second server with exactly the same result.

Does anyone else have this problems?

The problem was solved by installing the lastest windows updates. Missing updates are a plausible explanation of this weird behaviour..
Jun 26, 2013 at 2:56 AM
Hi, my bruteforce trick helps me:
1) Delete SearchServiceApplication from CA or Powershell with all associated data
2) Re-check on SQL that all Search Databases are removed
3) Delete SearchContentIndex file share (you probably specified path to that in autospinstaller.xml)
4) Re-run the script, wait for "Activating topology..", shutdown the script (maybe this step is unneccesary)
5) Reboot your box and Re-run the script again
Jul 3, 2013 at 12:43 PM
Same problem here. My workaround is rebooting the server and then launching AutoSPInstaller again. I don't have to remove the service app or the databases.
Jul 9, 2013 at 8:01 AM
Hi All,

I had also problem configuring the topology. I managed to get it to work by starting Search Query and Site Settings Service on app server. After that I managed to active the topology on WFE servers.

With this script you can check if the Search is working ok. I ran this on the app server (before I enabled the service).


Jul 26, 2013 at 1:55 PM
Hi !

Same problem here.
So weird, I was unable to activate the topology for 4 tests days, then installed the KB mentioned in this post :

Yesterday, with the KB, it worked !

But today, also with the KB, it was a NO WAY again !

Same virtual machine, same state.

Can't understand.

Anyone has found some good and reliable workaround ?
Something to add/remove/modify in the scripts, maybe to force reboot ?

Thanks !
Sep 4, 2013 at 1:23 AM
I am running SP 2013 and SQL 2012 - first time I ran the script, it was stuck on Activating Search Topology - I rebooted the computer and started AutoSPInstaller again and it worked fine.

I didn't need to make any changes to SQL, or add the Search Service Account to Local Administrators.
Sep 20, 2013 at 9:20 PM
I executed the SQL scripts on the Search DB in resource below, and then topology activated imidiately.

USE [SharePoint_Search_Database]
EXEC sp_addrolemember N'SPSearchDBAdmin', N'DOMAIN\SPsearch'
USE [SharePoint_Search_Database]
EXEC sp_addrolemember N'SPSearchDBAdmin', N'DOMAIN\SPcrawl'


USE [SharePoint_Search_Database]
USE [SharePoint_Search_Database]
Oct 8, 2013 at 8:43 PM
Same problem, activation timed out. Restarted machine and re-ran AutoSPInstaller and everything finished up fine.
Oct 8, 2013 at 9:23 PM
Edited Oct 8, 2013 at 9:24 PM
Have you tried version 3.93 of the AutoSPinstaller released on Sep-5. I tried it 4 times last week and it has a workaround for this issue without having to restart any server.
Sep 29, 2014 at 6:32 PM
Edited Sep 29, 2014 at 6:33 PM
This issue can occur if the server is unable to reach the Internet to validate CRLs from Microsoft causing the topology service provisioning to timeout. If the server cannot be placed online, perform the following steps to resolve the problem before running AutoSpInstaller.
  1. Open the 'Local Security Policy' MMC on the server.
  2. Select the 'Public Key Policies' node
  3. Locate 'Certificate Path Validation Settings' located in the 'Public Key Policies' node (List in the right window)
  4. Open 'Certificate Path Validation Settings' and click on the 'Network Retrieval' Tab
  5. Check the box 'Define these policy settings' and clear the box for 'Automatically update certificates in the Microsoft Root Certificate Program (recommended)'
    Click ok and close the MMC.
Some Caveats:
  • In the process of troubleshooting this, I installed the SharePoint Root Certificate into the Trusted Root Certificate store as described in KB2625048. I reconfigured the Search app using powershell post-install.
Sep 30, 2014 at 3:18 AM
@ecorreale, while I'm not sure how much of an effect this can have on the original "Activating Search Topology" issue, but wanted to thank you for the reminder about disabling CRL checks via local group policy in the way you described... Turns out I needed something like this today in an environment without outbound Internet access, and your post came just in time!

Mar 20, 2015 at 2:02 PM
Edited Mar 20, 2015 at 2:06 PM
A colleague and I spent an afternoon troubleshooting the cause of this in a least privileged SharePoint 2013, Server 2012 R2 multi-server farm. This article was the key to solving it.

What is happening is that there are 3 Windows services:
  • NetTcpActivator
  • NetPipeActivator
  • NetTcpPortSharing
These 3 services cache group permissions when the server boots up. Then when you install SharePoint, it creates a group called WSS_WPG, into which the account running the search service gets added. This group "should" have access to these 3 services, but it doesn't, because the permissions for it were cached before this group was even created (during the SharePoint install). This is why some people have been able to fix the problem by just rebooting and retrying!

So we were able to fix this issue by adding the following code early in the search service creation function:

Net stop NetTcpActivator
Net stop NetPipeActivator
Net stop NetTcpPortSharing
Net start NetTcpActivator
Net start NetPipeActivator
Net start NetTcpPortSharing

This completely negates the need for the workaround currently in the code, that performs an unprovision / provision($true), if the search host service is stuck in a starting/provisioning state. This solution also solves the issue mentioned here: