Tagged: search

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.0\Data\Office Server\Applications\Search\Nodes\\ContentProcessingComponent” 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).