SharePoint Search Service

[SharePoint 2013] – Indexation anormalement longue

Posted on Updated on

 

Bonjour à tous.

Aujourd’hui un article / KB concernant le moteur de recherche de SharePoint Server 2013.

Suite à la mise en place de ce moteur de recherche, j’ai pu constater un problème… que je n’avais jamais eu jusque ici !

Concernant le contexte, il s’agit de l’installation de SharePoint Server 2013 Standard en Français, sur Windows Server 2008R2 en Français également et couplé au moteur SQL Server 2008R2 SP1 en Français, installé sur un second seveur.

 

1/ Le problème

 

Lors du déploiement de l’application de service de recherche, j’ai utilisé l’assistant depuis la page de gestion des applications de service dans l’administration centrale de SharePoint.

J’ai nommé mon service “Application de recherche”, utilisé un pool dédié aux applications de service. Lors de la création, aucun problème constaté, le service est bien créé/configuré, les bases de données sont également ok.

Le problème est survenu lors de l’indexation d’une source de données SharePoint (Site SharePoint locaux par défaut) sur un site vide… La première indexation a duré plus de 25 heures !!!!

Evidemment ce n’est pas normal ! Après investigations, sur l’observateur d’évènements, les logs, etc. et activation du mode ‘Verbose” des logs, il s’est avéré que cette erreur se reproduisait constamment lors de l’indexation des données :

 

System.ArgumentException: La longueur de la valeur de la clé ‘application name’ dépasse sa limite fixée à ‘128’.

à System.Data.SqlClient.SqlConnectionString..ctor(String connectionString)     à System.Data.SqlClient.SqlConnectionFactory.CreateConnectionOptions(String connectionString, DbConnectionOptions previous)     à System.Data.ProviderBase.DbConnectionFactory.GetConnectionPoolGroup(DbConnectionPoolKey key, DbConnectionPoolGroupOptions poolOptions, DbConnectionOptions& userConnectionOptions)     à System.Data.SqlClient.SqlConnection.ConnectionString_Set(DbConnectionPoolKey key)     à System.Data.SqlClient.SqlConnection.set_ConnectionString(String value)     à System.Data.SqlClient.SqlConnection..ctor(String connectionString, SqlCredential credential)     à Microsoft.Office.Server.Data.SqlSession.OpenConnection()     à Microsoft.Office.Server.Data.TransactionalSqlSession.RetrySqlConnectionInitialization(Action`1 initializer)     à Microsoft.Office.Server.Data.TransactionalSqlSession.OpenConnection()     à Microsoft.Office.Server.Data.SqlSession.ExecuteNonQuery(SqlCommand command) à Microsoft.Office.Server.Search.ManagedSqlSession.ExecuteNonQuery()

SqlCommand: ‘SET XACT_ABORT ON’     CommandType: Text CommandTimeout: 0

 

 

Bon évidemment premier réflexe… un coup de moteur de recherche… pas vraiment concluant. J’ai donc supprimé l’application de service, recréé… et même erreur !

 

 

La solution

 

En fait… ce n’est pas si compliqué que ça ! En nommant mon application de service de recherche “Application de recherche”, l’assistant nomme les bases de données :

“Application_de_recherche_[UN MEGA GUID PAS BEAU]”.

Et il semblerait que la connectionstring soit trop longue !!!!!!! (dépasse les fameux 128 caractères stipulés dans le log de l’erreur)

 

La solution peut donc être de deux formes. Soit on recréé une application de service de recherche à l’aide de l’assistant, en choisissant un nom plus court… et en priant pour qu’il soit assez court.

Soit on déploie le service avec notre ami PowerShell / Management Shell pour SharePoint.

Et vous l’aurez compris… je préfère largement la seconde option.

Voici donc le script que j’ai utilisé pour recréer ce service :

 

Création du pool d’application pour notre service :

  • $appPoolName = Nom du pool : SharePointSearchAppPool
  • $appPool = Pool d’application créé
    • Compte : DEMO\spapppool ==> domaine : Demo, compte utilisé : spapppool

 

$appPoolName = “SharePointSearchAppPool”
$appPool = New-SPServiceApplicationPool -Name $appPoolName -Account “DEMO\spapppool”

 

 

Divers paramètres :

  • $searchServerName  = Nom du serveur de recherche
  • $serviceAppName = Nom du service d’application
  • $searchDBName = Nom de la base de données du service

 

$searchServerName = (Get-ChildItem env:computername).value
$serviceAppName = “Application de recherche”
$searchDBName = “SPSearch_DB”

 

 

Démarrage des services sur le serveur :

 

Start-SPEnterpriseSearchServiceInstance $searchServerName
Start-SPEnterpriseSearchQueryAndSiteSettingsServiceInstance $searchServerName

 

 

Création de l’application de service de recherche et récupération de l’instance :

 

$searchServiceApp = New-SPEnterpriseSearchServiceApplication -Name $serviceAppName -ApplicationPool $appPoolName -DatabaseName $searchDBName
$searchProxy = New-SPEnterpriseSearchServiceApplicationProxy -Name “$serviceAppName Proxy” -SearchApplication $searchServiceApp

$searchServiceInstance = Get-SPEnterpriseSearchServiceInstance

 

 

Clonage de la Topologie de recherche par défaut :

 

$clone = $searchServiceApp.ActiveTopology.Clone()

New-SPEnterpriseSearchAdminComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance

New-SPEnterpriseSearchContentProcessingComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance

New-SPEnterpriseSearchAnalyticsProcessingComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance

New-SPEnterpriseSearchCrawlComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance

New-SPEnterpriseSearchIndexComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance

New-SPEnterpriseSearchQueryProcessingComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance

$clone.Activate()

 

 

Et voilà !

Advertisements

SP2013–Création de l’application de service de recherche & overview

Posted on Updated on

 

Bonjour à tous. Je reviens une fois de plus pour vous parler de configuration d’applications de service (Service Applications), et cette fois-ci je vais m’appuyer sur le scénario comprenant la création de cette application à partir de l’administration centrale de SharePoint.

 

Voyons donc comment nous allons nous y prendre pour créer cette application.

 

1/ Rendons nous sur la page d’accueil de l’administration centrale de SharePoint 2013, et cliquons sur “Manage service applications” :

01

02

 

2/ L’application de service de recherche n’est pas créée. Nous allons donc commencer par créer cette application de la même manière qu’avec SharePoint 2010. On utilise le ruban : New > Search Service Application :

03

 

L’assistant permettant de créer cette application de service apparait. Cette fenêtre reprend complètement les paramètres demandés pour la création de ce service avec SharePoint 2010. On nous demande en effet :

  • Un nom de service : “Search Service Application”
  • Search Service account : compte qui sera utilisé pour lancer le service Windows associé à cette application de service (dans mon cas, j’ai un compte de domaine spécialisé pour les applications de services : Labs\spserviceapps)
  • Un pool d’application pour l’administration de l’application de service de recherche, avec une identité (compte géré)
  • Un pool d’application pour le WebService associé à l’application de service de recherche avec une identité (compte géré)

04

 

05

 

06

 

On lance la création de l’application de service de recherche grâce au bouton “OK” en bas de page. Cela peut prendre quelques minutes…

07

…voir même carrément planter ! Ca a été le cas lors de ma configuration, le processus de création ne s’est jamais terminé => PREVIEW !

Pourtant en relançant l’administration centrale de SharePoint 2013, l’application de service été bien créé et démarrée :

08

 

Et en cliquant sur cette ligne, on arrive sur la page résumant l’état du service, tout à l’air ok à première vue :

09

 

3/ Pourtant, on remarque tout de suite un message “pas normal” dans le bas de page : “Unable to retrieve topology component health states. This may be because the admin component is not up and running” :

11

 

Voyant ce message, j’ai pensé à l’instance d’une application de service qui ne serait pas démarrée, sans succès. Après analyse du log, de l’observateur d’évènement et un coup de google, je me suis aperçu que je n’étais pas le seul à avoir ce problème. J’ai donc suivi un workaround proposé ici : http://sharepointstruggle.blogspot.fr/2012/07/sharepoint-2013-unable-to-retrieve.html

Il suffit de télécharger les 3 updates pour Windows Server 2008R2, les installer, faire les Windows Update et redémarrer.

=> Windows Updates à installer :

    Une fois le serveur redémarré, tout à l’air de fonctionner, le message d’erreur n’apparait plus. A la place, on a un tableau résumant la topologie de la recherche. Dans mon cas, tout les composants sont sur le même serveur :

15

 

4/ Faisons maintenant le tour des liens proposés dans le “Quicklaunch”…

1. Premier lien “Farm Search Administration” :

10

Il n’y a pas grand chose dans cette page, on y retrouve principalement des informations sur la topologie.

 

2. Second lien “Crawl Log”. Les administrateur SharePoint connaissent déjà cette page qui leur permettait d’accéder aux différentes erreurs, warning lancées par l’indexation (le crawl) des sources de données :

16

 

3. Troisième lien “Crawl Health Reports”. Ici encore, on retrouve des informations que nous proposait déjà SharePoint 2010 avec des statistiques concernant l’indexation des informations/fichiers avec des filtres proposés dans le haut de page : source de contenu, composant, dates de début/fin. Ces données sont présentées sous formes de graphes (courbes). On retrouvait ce graphique dans les “Search Administratives Reports” dans SharePoint 2010 :

17

 

4. Quatrième lien “Query Health Reports”. Toujours dans le même sens que la page précédente, on nous propose ici des statistiques mais sur les recherches lancées par les utilisateurs ce coup-ci. On retrouve des filtres (date de début/fin, type de client), les données sont présentées sous forme de graphes :

18

 

5. Cinquième lien, “Usage Reports”. Ici c’est nouveau ! SharePoint 2013 nous propose de télécharger des fichiers Excel (xlsx) contenant des informations sur :

  • Nombre de requêtes
  • Requêtes les plus utilisées par jour
  • Requêtes les plus utilisées par mois
  • Requêtes sans résultats par jour/mois

C’est nouveau mais cela a un gout de déjà vu… En effet ces données étaient disponibles à travers les rapports proposés par l’application de service de recherche de SharePoint 2010.

 

6. Sixième lien “Content Sources”. Ce menu est bien connu de tous les administrateurs, c’est ici que nous allons définir du contenu qui sera indexé par l’application de service en question :

20

Ici rien n’a changé, la présentation reste la même et les informations également.

 

7. Septième lien “Crawl Rules”… rien de nouveau :

21

 

8. Huitième lien “ Server Name Mappings”… rien de nouveau :

22

 

9. Neuvième lien “File Types”… rien de nouveau :

23

 

10. Dixième lien “Index Reset”… rien de nouveau :

24

 

11. Onzième “Crawler Impact Rules”… rien de nouveau :

25

 

12. Douzième lien “Authoritative Pages”… rien de nouveau :

26

 

13. Jusqu’ici, nous n’avons pas remarque de nouveautés notables sur ces divers lien. Le treizième quant à lui, est totalement nouveau. Il s’appelle “Result sources”. Cette page va nous permettre de définir de sources de provenance pour les résultats de recherche en particulier dans le cas de fédération de diverses sources de contenu (SharePoint, Web, DFS, Exchange public folders, etc.). Ce système est dédié à remplacer les Scopes (effectivement ils n’apparaissent plus à aucun endroit dans cette administration de la recherche).

Ils ont l’avantage d’être localisés au niveau des collections de sites et plus au niveau même de l’administration de l’application de service de recherche. On peut donc les déclarer (et les rendre disponibles) au niveau des collections de sites. On devine dès à présent que certaines options doivent être disponibles au niveau de l’administration des collections de site… :

27

 

14. Quatorzième lien, “Query Rules”. Cette page va nous permettre d’établir des règles concernant les sources établies au menu précédent (les fameuses result sources). On pourra ainsi construire des règles complexe afin que nos résultats de recherches ne concordent pas seulement avec le terme entré par un utilisateur mais plutôt à un ensemble de termes. Par exemple si l’utilisateur entre “SP” ou “SharePoint” ou “SharePoint Online” ou “Office 365”, on proposera un bloc présenté différemment avec un lien pointant vers la page consacrée à SharePoint sur le site de Microsoft.

28

 

15. Quinzième lien “Query Client Types”. Ce menu reste un peu obscur pour le moment, il s’agit de prioriser le renvoi de résultats suite au lancement d’une recherche et ce suivant le type de client (et donc de fixer un seuil à atteindre avant que cette fonctionnalité soit atteinte, ils l’appellent le “query throttling”). Aucune trace dans le SDK, Technet ou MSDN…

29

 

16. Seizième lien “Search Schema”. Il s’agit ici en fait d’une fonctionnalité qui existait avec SharePoint 2010 (et 2007) qui s’appelait les “Managed Properties”. SharePoint (ou l’administrateur) vont déclarer ici des propriétés gérées, mappées sur des champs créés dans nos listes/bibliothèques de document afin de promouvoir ces propriétés et de pouvoir, par exemple, les utiliser comme paramètre ou filtre dans une recherche avancée :

  • Searchable : inclu le contenu de cette propriété gérée dans l’index et est donc recherchable comme terme en lui-même
  • Queryable : la propriété gérée peut être utilisée dans les requêtes complexes de type “[nom de la propriété]:[Valeur]” => recherches avancées
  • Retrievable : la propriété gérée peut être retournée dans les résultats de recherche
  • Refinable : la propriété peut être utilisée dans les WebPart de raffinement
  • Sortable : la propriété gérée peut être utilisée pour le tri des résultats

30

 

17. Dix-septième lien “Query Suggestions”. Ce menu va vous permettre de paramétrer des suggestion (le fameux “Did you mean XXXXX ?”) qui apparaissent dans SharePoint 2010. Ici vous pourrez exporter les suggestions actuelles dans un fichier TXT, les enrichir et ré-importer le fichier. Ce fichier est bien-sûr différent en fonction de la langue de l’interface de SharePoint.

Petite nouveauté également, le possibilité d’interdire certaines suggestions (une sorte de “noise words” appliqué aux suggestions) avec ici aussi la possibilité d’utiliser un fichier d’export/import :

31

 

18. Dix-huitième lien “Search Dictionaries”. Le lien nous renvoie vers le service de métadonnées gérées (Managed Metadata Service : MMS) :

32

 

19. Dix-neuvième lien “Search Result Removal”. Ce menu (comme avec SharePoint 2010) vous permettra d’exclure automatiquement des résultat provenant des urls (à partir de la racine de l’url que vous fournirez), ces résultats ne remonteront donc pas dans les résultats de recherche :

33

 

Dernière petite chose, à partir de la page d’accueil de l’administration de cette application de service, vous avez la possibilité de définir un “Search Center” global pour votre plateforme SharePoint. Plus besoin de le déclarer sur chacune des collections de sites, tout est centralisé dans l’administration de ce service.

35

 

Voila, nous avons fait un tour rapide de cette “nouvelle” application de service. Nous y retrouvons pas mal de concepts déjà présents avec SharePoint 2010 mais également de nouveaux (en particulier les “result sources” qui devraient nous simplifier la présentation des résultats suivant leur type, et remplaceront les “Scopes”).

On peut également ajouter, qu’avec cette mouture de SharePoint 2013, Microsoft supporte nativement l’indexation de PDF (ce que nous faisions avec un iFilter auparavant) . De plus, le crawler supporte également l’indexation de mailboxes Exchange.

 

Il nous reste maintenant à mettre tout cela en œuvre… peut être au prochain épisode !

La recherche SharePoint 2010 ne remonte pas le titre d’un document Word 2003 ou 2007

Posted on Updated on

Il peut arriver, qu’après avoir configuré votre service de recherche dans SharePoint 2010 Server, vous tentiez une recherche… qui remonte des documents Word 2003 ou 2007 et que dans la page de résultats, le titre de ce document soit : “Titre”.

C’est en fait une optimisation cachée du moteur de recherche de Search Server… qui remonte les quelques premiers mots du document ou une mauvaise métadonnée du document !

Pour corriger ceci :

  1. Ouvrir l’éditeur de registre du serveur hébergeant le service de recherche : Démarrer > Exécuter > Regedit
  2. Chercher la clé : [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\Search\Global\Gathering Manager\EnableOptimisticTitleOverride]
  3. Changer la valeur de 1 à 0
  4. Relancer le service de recherche soit depuis la console de management des services ou net stop osearch puis net start osearch
  5. Relancer une indexation complète des sources de contenu
La page de résultats affichera correctement le titre de votre document !