SharePoint 2013 : How to repair a broken Search component at low cost

sharepoint 2013
sharepoint 2013

Once upon a time, after a whole server farm reboot, one of my search component was broken. Content crawling was taking forever, and the ULS were not very explicit. In the central administration, I could see this :

SharePoint Components
SharePoint Components

My application server was unable to run the « Content Processing Component », even if I restart the whole search service (net stop / start OSearch15).
I noticed 2 things that drove me to the solution :
– First, a noderunner.exe process was missing. This confirmed the red cross in the central administration. There was 2 processes instead of 3 (the crawler doesn’t spawn a noderunner.exe process) :

SharePoint Search Processes
SharePoint Search Processes

– On the second hand, there was strictly no logs in the « 15.0DataOffice ServerApplicationsSearchNodesContentProcessingComponent » directory !
It was like the search topology was ignoring this component. So I decided to re-install the search topology, just by cloning it, and activating it :

$searchApp = Get-SPEnterpriseSearchServiceApplication
$initialTopology = Get-SPEnterpriseSearchTopology -SearchApplication $searchApp -Active
$cloneTopology = New-SPEnterpriseSearchTopology -SearchApplication $searchApp -Clone -SearchTopology $initialTopology
Set-SPEnterpriseSearchTopology -Identity $cloneTopology -SearchApplication $searchApp

And it works, without any service interruption !

SharePoint Components
SharePoint Components

SharePoint 2010 / 2013 : La recherche ne fonctionne plus (sur aucun site)

SPDesigner Il y a de multiples définitions pour « la recherche ne fonctionne plus ». Il n’est pas question ici d’indexation, mais de l’impossibilité pour tous les utilisateurs de tous les sites de lancer une recherche.

 

Contexte : Ferme SharePoint 2010 ou 2013, Windows Server 2008 / 2008 R2.
Symptôme : Le lancement d’une recherche sur un site web aboutit à une erreur (Exception). Dans les fichiers de logs SharePoint, il y a des entrées du type :
« Tentative d’opération non autorisée sur une clé du Registre marquée pour suppression »
Dans le journal des événements Windows, il y a :
« Windows a détecté que votre fichier de Registre est toujours utilisé par d’autres applications ou services. Le fichier va être déchargé… »
Diagnostic : le compte de service de recherche essaie d’accéder à une clé de registre, mais il ne peut pas. Une session a pu être ouverte avec ce compte de service sur l’un des serveurs de la ferme (en bureau à distance). Des services ont été redémarrés (ou tentés de l’être). Puis la session a été fermée. Les ouvertures et fermetures de session provoques des ajouts / suppression de clés dans la base de registre. Il SEMBLERAIT que les services qui ont été redémarrés cherchent à accéder à ces clés, alors qu’elles étaient supprimées une fois la session fermée. Cette situation est expliquée ici : blogs.msdn.com.
Solution (Dans le cas du service de recherche) :

  • Dans services.msc : Redémarrer les services « SharePoint Server Search 14 » et “SharePoint Foundation Search V4” (si déjà démarrés)
  • Dans IIS : Recycler le pool d’application « SecurityTokenServiceApplicationPool » sur tous les serveurs SharePoint
  • Dans l’administration centrale de SharePoint : Aller dans « Gérer les services sur le serveur », et redémarrer : « Service de paramètres de site et de requête de recherche ».
  • En dernier recours, un reboot de serveur serait une solution, mais provoquerai une coupure de service, ce qui n’est pas toujours souhaitable.

Comment ne pas réitérer cet incident ?
Ne pas se connecter avec les comptes de service pour relancer les services eux-mêmes.
Il y aurait également une GPO (« Do not forcefully unload the user registry at user logoff ») à modifier (Lien externe), mais ceci nécessite un accord avec les administrateurs du domaine (risque de GPO locales écrasées).