Search

SP2013–Mise en place du centre de recherche & configuration

Posted on Updated on

 

Bonjour à tous. Dans le précèdent article : SP2013–Création de l’application de service de recherche & overview, nous avons configuré l’application de service de recherche (Search Service Application) sur notre plateforme SharePoint 2013. Nous avons également parcouru l’ensemble des menus permettant de configurer notre moteur de recherche d’entreprise.

Dans cette exploration, certains changements sont apparu, en particulier au niveau des scopes qui ont disparu au profit des “Result sources”.

Nous allons essayer, dans cet article, de mettre en place un centre de recherche et de configurer l’application de service de recherche pour centraliser les recherches dans ce search center.

Commençons par créer une collection de sites de type “Centre de recherche d’entreprise”.

1/ Création de la collection de sites. Nous nous rendons dans l’administration centrale de SharePoint, cliquer sur le lien “Create site collections” :

01

 

Nous allons remplir le nom de la collection de sites (“Search Center” dans mon cas), la description, l’url (“search” dans mon cas) et sélectionner le modèle de site : Enterprise > Enterprise Search Center. Il faut bien sûr compléter le nom de l’administrateur de cette nouvelle collection (labs\spfarm pour moi) et cliquer sur “OK” :

02

03

 

Et bien sûr… nous patientons… :

04

 

Le résultat apparait enfin, le centre de recherche est créé. On clique sur le lien, la page d’accueil de ce nouveau centre de recherche se charge :

05

06

 

On tente une recherche et bien sûr aucun résultat n’apparait puisque le composant de crawl et ses sources de contenu n’ont pas été paramétrés et qu’aucune indexation n’a été lancée :

07

 

2/ Pour pouvoir tester l’indexation des PDF, native dans SharePoint 2013, j’ai préalablement ajouté un document PDF dans une bibliothèque de documents “Documents” sur ma collection de sites principale. J’ai utilisé ce document : http://download.microsoft.com/download/2/6/2/26253C22-D8EC-4230-A3ED-E2DEED9E8EBE/Microsoft%20SharePoint%20Workspace%202010%20Product%20Guide_Final.pdf.

 

3/ Paramétrage des sources de contenu. Dans le précédent article, nous avons créé l’application de service de recherche. Nous nous rendons donc sur la page d’administration de cette application, dans l’administration centrale de SharePoint 2013 :

08

 

On clique sur “Manage service applications” et on clique sur notre application de service de recherche (Search Service Application) :

09

 

Nous voila sur la page d’accueil de l’application, sur la gauche on sélectionne “Content Sources” :

10

 

Nous arrivons sur la page permettant de gérer les sources de contenu. Une source est déjà disponible “Local SharePoint sites”. Elle est en “Idle” (en attente, arrêtée) et aucune indexation n’a encore été lancée. On clique sur le lien “Local SharePoint Sites”, la page de ses propriétés apparaissent :

11

 

Dans les paramètres de cette source de contenu, nous voyons principalement les paramètres de la dernière indexation (type, début, durée), les url qui ont été indexées (sites SharePoint, profils, etc.) :

12

 

Ainsi que les paramètres des planifications (schedules) des indexations, qu’elles soient complètes (Full Crawl) ou incrémentielles (Incremental Crawl). Une petite nouveauté fait son apparition ici, le “Continuous Crawl” qui nous permettra d’indexer en continu cette source de données. Attention toutefois à la charge consommée par ce type de crawl qui peut être certes lissée mais consommera en continu des ressources que ce soit en terme de CPU, mémoire, disque mais également réseau. En terme d’architecture (topologie), on pourrait par exemple penser à un serveur dédié aux indexations.

On retrouve également la notion de priorité des sources de contenu (pour l’indexation) comme dans SharePoint 2010 :

13

 

On tente de lancer une indexation complète :

14

 

Un message d’avertissement nous demande de confirmer, nous confirmons :

15

 

L’indexation complète se lance (Starting). Il nous faudra patienter jusqu’à ce que la source de contenu repasse en Idle :

16

17

 

4/ L’indexation est terminée, nous pouvons vérifier que ce PDF a bien été indexé en copiant son adresse (url) dans SharePoint et en utilisant le Crawl Log. Nous commençons donc par copier cette adresse et on utilise le menu contextuel sur la source de contenu :

18

19

 

On s’aperçoit qu’il y a des “success”, des “warnings” et des “errors”. En cliquant sur le nombre en dessous de “success”, la page résumant les documents et pages indexées apparaissent. On entre l’adresse du document dans la textbox en haut (“Type a URL or host name. Use the * character as a wildcard.”) et on valide en cliquant sur “Search” :

20

 

Le document apparait bien (en “success”), le pdf est donc bien indexé :

21

 

5/ Nous pouvons dorénavant lancer une recherche sur notre collection de sites ou le search center. J’utilise le texte : “SharePoint Workspace Synchronization Details” qui apparait dans le PDF (dans le contenu), le document PDF remonte bien !

22

23

Au passage, on peut noter les nouveautés coté présentation des résultats du plus bel effet, avec au survol l’apparition des métadonnées du document, et des actions :

  • Follow => j’ai eu une erreur, alors que le UserProfile est configuré…
  • Send => mailto : envoie un mail formaté avec l’url de ce document
  • Open => ouvre le document
  • View Library => ouvre la bibliothèque contenant ce document

Ou encore sur la gauche des slicers permettant de filtrer par exemple sur la date de modification du document (tous, plus de 1 an, plus de 1 mois, etc.) et une représentation graphique synthétisant le nombre de documents sur les périodes proposées :

29

 

6/ L’indexation fonctionne donc correctement. Il nous faut maintenant vérifier que cela fonctionne. Sur la page d’accueil de notre collection de sites principale, une liste déroulante (dropdown) est apparu dans la zone de recherche. Lorsque nous sélectionnons “This Site”, les recherches sont redirigées vers la page OSSSearchResults.aspx :

30

31

 

Et si l’on sélectionne “Everything”, les recherches sont automatiquement redirigées vers le centre de recherche défini dans l’administration de l’application de service de recherche :

32

33

 

Durant cette phase de configuration, il n’a que très peu de nouveautés abordées. On notera les indexations continues, l’url de Search Center globale définie dans l’administration de l’application de service… et bien sûr une toute nouvelle présentation ! On sent toutefois un gros travail qui a été réalisé avec la “fusion” de la recherche d’entreprise de SharePoint et FAST Search et des nouveautés qui n’ont pas encore été abordées (voir l’article précédent). Nous verrons tout cela dans une configuration avancée de cette nouvelle recherche SharePoint… Il reste du travail ! Stay Tuned Sourire

SP2010 – Afficher les document Office dans Office WebApps depuis la page de résultat de recherche

Posted on Updated on

Bonjour à tous.

L’une des grandes forces de SharePoint 2010 (et d’autres produits Microsoft bien entendu) est de proposer la visualisation des documents Office (en particulier Word, PowerPoint, Excel, OneNote) directement dans la page Web (dans le navigateur), sans utiliser les applications clientes de la suite Office, le tout grâce aux Office Web Apps.

A quoi servent ces Office Web Apps… et surtout à qui ?

Dans l’entreprise, il est parfois pratique d’utiliser ces Office Web Apps pour visualiser rapidement des documents stockés dans SharePoint (mais également Hotmail, SkyDrive, etc.) dans le navigateur, sans la nécessité d’avoir la bonne version d’Office client installé (2003, 2007, 2010 sans parler des Office XP).

C’est donc très pratique pour s’affranchir des limitations dues à la compatibilité non ascendante des produits Office. Un utilisateur d’Office XP ou 2003 ne pourra pas exemple pas ouvrir un fichier produit avec Office 2010. Effectivement le format de fichier a changé depuis (passage à l’OpenXML depuis Office 2007, et du coup changement d’extension des fichiers pour tous les produits : doc vers docx, xls vers xlsx, ppt vers pptx…).

Et d’expérience, on a souvent cohabitation des toutes les versions de la suite bureautique au sein même d’un même société. Dur dur de collaborer !!! C’est là que les Office Web Apps interviennent, permettant d’afficher mais également de produire ces types de fichier depuis le navigateur, et alors plus de problème avec les versions d’Office !

C’est également bien pratique pour les postes qui ne sont pas sous Windows (ou Mac OS avec la suite Office) : les distributions linux par exemple, tablettes (et j’en passe). Ils utilisent directement le navigateur pour produire les fichiers (attention au navigateur, certains ne sont pas supportés (détail) :

Word, Excel, et PowerPoint peuvent être affichés en utilisant de nombreux périphériques mobiles. Navigateurs mobiles supportés par les Office Web Apps sur SharePoint 2010 : Internet Explorer sur Windows Mobile 5/6/6.1/6.5; Safari 4 sur iPhone 3G et 3GS; BlackBerry 4.x et supérieur ; Nokia S60; NetFront 3.4, 3.5, et supérieur; Opera Mobile 8.65 et supérieur; et Openwave 6.2, 7.0 et supérieur. Navigateurs mobiles supportés par les Office Web Apps sur Windows Live : Safari 4 sur iPhone 3G et 3GS, et Internet Explorer 7 sur Windows Phone 7. Afficher des documents Excel dans un navigateur mobile est uniquement possible avec les Office Web Apps sur SharePoint 2010.

Attention également, tout n’est pas possible avec les Office Web Apps (création d’entêtes / pieds de page, sommaires, …).

Voilà pour l’introduction !

Maintenant le sujet : dans SharePoint Server 2010 (ou SharePoint Foundation + Search Server Express 2010 par exemple), on utilise bien souvent le centre de recherche pour concentrer les recherches des utilisateurs sur un seul site qui fait office de portail de recherche (recherche de documents, personnes).

En installant les Office Web Apps sur votre ferme, les utilisateurs deviennent capable d’ouvrir les documents dans le navigateur (et on peut même modifier le comportement par défaut d’ouverture des documents pour que les ficihers Office soient ouverts dans Office Web Apps et pas dans le client installé.

Mais que se passe-t’il si on ouvre un fichier Office depuis la page des résultats de recherche ? de la même manière si on a fixé le comportement par défaut de la bibliothèque pour que SharePoint ouvre les fichiers dans Office Web Apps ?

Réponse… SharePoint quand même d’ouvrir le fichier dans Word ou de télécharger le fichier si Office n’est pas installé !!! on s’y attend pas…

Mais du coup comment faire pour que la page des résultats de recherche ouvre les document Office dans Office Web Apps ?? Tout simplement en modifiant le template de rendu du WebPart affichant les résultats de recherche. Ce template est du xsl-t, transformant le flux récupéré lors de l’exécution de la recherche (XML) en HTML avec application de Styles.

Il faut donc éditer ce template (propriétés du WebPart, Modèle de rendu) et ajouter juste après :

          <div class=”srch-Title2″>

<div class=”srch-Title3″>

<!– links with the file scheme only work in ie if they are unescaped. For

this reason here we will render the link using disable-output-escaping if the url

begins with file.–>

<xsl:choose>

Ceci :

<xsl:when test=”substring($url,string-length($url) – 4,5) =’.docx’ or substring($url,string-length($url) – 3,4) =’.doc’ or substring($url,string-length($url) – 4,5) =’.pptx’ or substring($url,string-length($url) – 3,4) =’.ppt’ and $IsDesignMode = ‘False'”>

<xsl:text disable-output-escaping=”yes”>&lt;a href=”</xsl:text>

<xsl:value-of disable-output-escaping=”yes” select=”serverredirectedurl” />

<xsl:text disable-output-escaping=”yes”>” id=”</xsl:text>

<xsl:value-of disable-output-escaping=”yes” select=”srwrt:HtmlAttributeEncode(concat($currentId,’_Title’))” />

<xsl:text disable-output-escaping=”yes”>” title=”</xsl:text>

<xsl:value-of disable-output-escaping=”yes” select=”srwrt:HtmlAttributeEncode(title)” />

<xsl:text disable-output-escaping=”yes”>”&gt;</xsl:text>

<xsl:choose>

<xsl:when test=”hithighlightedproperties/HHTitle[. != ”]”>

<xsl:call-template name=”HitHighlighting”>

<xsl:with-param name=”hh” select=”hithighlightedproperties/HHTitle” />

</xsl:call-template>

</xsl:when>

<xsl:otherwise>

<xsl:value-of select=”srwrt:HtmlEncode(title)”/>

</xsl:otherwise>

</xsl:choose>

<xsl:text disable-output-escaping=”yes”>&lt;/a&gt;</xsl:text>

</xsl:when>

Vous l’aurez compris, ce bout de transformation xsl-t teste l’extension du fichier (si docx, doc, pptx, ppt et on pourrait ajouter Excel…) et si le résultat courant est d’un de ces types, on affiche un lien HTML (serverredirectedurl) mis en forme et redirigeant vers la page Office Web apps affichant le type de fichier trouvé. Simple comme bonjour (ou presque) !

SP2010 – Créer le service de recherche par Powershell – Part 2

Posted on Updated on

Voici la suite du précédent post concernant la configuration du service de recherche de SharePoint Server 2010 avec Powershell : Part 1.

L’application de service était donc créée, le composant d’administration également… il nous restait à créer :

  • Une partition
  • Un composant d’analyse
  • Un composant de requête
Nous allons donc voir comment faire avec Powershell, et plus particulièrement le Management Shell de SharePoint 2010. Tout comme dans la partie 1, il faut lancer le Management Shell : depuis le menu Démarrer > Tous les programmes > Microsoft SharePoint 2010 Products > SharePoint 2010 Management Shell :


Launch management shell



Si vous reprenez la partie précédente, vous aurez déjà les variables créées dans la console PowerShell, sinon il faudra les recréer. Pour cela, reprenez la partie 1 et ajoutez les variables (il faudra aussi récupérer les instances des services grâce à Powershell. Pour faciliter la compréhension, je continuerai cet article comme si vous enchaîniez partie 1 et partie 2.


Nous allons commencer par créer une topologie pour le composant d’analyse : $CrawlComp = $SearchServiceApplication | New-SPEnterpriseSearchCrawlTopology
(Vous pouvez entrer $CrawlComp pour vérifier que la topologie est bien créé) :


Nous allons maintenant créer un Crawl Store : $CrawlStore = $SearchServiceApplication | Get-SPEnterpriseSearchCrawlDatabase
(Vous pouvez entrer $CrawlStore pour vérifier que le composant est bien créé) :


Puis enfin créer le composant d’analyse : New-SPEnterpriseSearchCrawlComponent -CrawlTopology $CrawlComp -CrawlDatabase $CrawlStore -SearchServiceInstance $SearchAppServiceInstance


Notez que l’état est “Uninitialized”… il faut donc l’activer. Pour cela (attention cela peut prendre du temps) :  $CrawlComp | Set-SPEnterpriseSearchCrawlTopology -Active
Et vérifiez l’état une fois que vous aurez récupéré la main avec : $CrawlComp.State => Le statut doit être Actif


Maintenant, sur le même principe, nous passons au composant de requête.
Créons la topologie pour ce composant avec : $QueryComp =  $SearchServiceApplication | New-SPenterpriseSEarchQueryTopology -partitions 1
Vous pouvez entrer $QueryComp et vérifier que le composant de topologie est bien créé :


On récupère la partition créée avec : $Partition = ($QueryComp | Get-SPEnterpriseSearchIndexPartition)
Vous pouvez entrer $Partition pour vérifier les attributs de la partition :


On créé le composant de requête : New-SPEnterpriseSearchQueryComponent -indexpartition $Partition -QueryTopology $QueryComp -SearchServiceInstance $SearchAppServiceInstance


On récupère ensuite le nom de la Property Store DB : $PropStoreDB = $SearchServiceApplication | Get-SPEnterpriseSearchPropertyDatabase
Vous pouvez entrer $PropStoreDB pour vérifier que vous l’avez bien récupéré :


Il faut ensuite associer cette Property Store DB avec la partition de requête que nous avons récupérer auparavant : $Partition | Set-SPEnterpriseSearchIndexPartition -PropertyDatabase $PropStoreDB


Et enfin (!!!) associer tous ces composants en démarrant le service de requête de SharePoint (cela peut prendre un moment) : $QueryComp | Set-SPEnterpriseSearchQueryTopology -Active
Lorsque vous aurez récupéré la main, vous pourrez contrôler l’état en utilisant $QueryComp.State et vérifier que ce soit actif :


Tous les composants sont créés… reste à vérifier ce qui a été fait depuis la console d’administration centrale de SharePoint. Pour cela, rendez vous dans la central administration, dans la gestion des application de service. Sur le service de recherche précédemment créé, allez dans l’administration de la recherche dans la batterie. Vous aurez :


Les composant d’analyse, requête ont bien été créés grâce à Powershell !! et en plus ils ont des noms sans Guid…


SP2010 – Créer le service de recherche par Powershell – Part 1

Posted on Updated on

Bonjour à tous.

Le but de ce post : créer une application de service de recherche dans SharePoint 2010.

Vous me direz facile ! Par l’administration centrale oui… mais par Powershell ??? pas si compliqué que ça !

Mais pourquoi utiliser Powershell alors qu’on peut y arriver par la console d’administration centrale de SharePoint ??? Tout simplement afin d’avoir le contrôle sur les noms des bases de données associées au service de recherche !! fini les GUID 😉

Comment s’y prendre ?

Première étape, lancer le Management Shell pour SharePoint 2010, depuis le menu Démarrer > Tous les programmes > Microsoft SharePoint 2010 Products > SharePoint 2010 Management Shell :

Launch management shell

Etape suivante, les commandes Powershell !

Nous aurons besoin de plusieurs variables qui contiendront des chaines de caractères que nous utiliserons plusieurs fois, par exemple : le nom du service, compte de service, nom du pool d’application pour l’application de service, etc.

On commence donc par cela :

Nom du service : $SearchAppServiceName = “Service de Recherche de SharePoint 2010 créé par Powershell”

Nom du pool d’application pour le service de recherche : $SearchAppPoolName = “SearchAppPool”

Compte du domaine qui supportera le service de recherche (remplacez par le compte de domaine qui supportera le service) : $SearchAppAccount = “domaine\compte” 

Nom de la base de données d’administration de la recherche : $SearchAppAdminDBName = “SP2010_Search_AdminDB”

Nom du proxy de l’application de service de recherche : $SearchAppProxyName = “Proxy du Service de Recherche de SharePoint 2010 créé par Powershell”

Une fois toutes ces variables créées, il faut récupérer l’instance du service de recherche et la démarrer (si ce n’est pas déjà fait) : $SearchAppServiceInstance = get-spenterprisesearchserviceinstance -local

On pourra également entrer $SearchAppServiceInstance pour vérifier que l’instance est bien récupérée (Notez la ligne Status : Online => l’instance du service est déjà démarrée sur mon serveur, donc la commande suivante n’est pas nécessaire)

Et on démarre l’instance : Start-SPEnterpriseSearchServiceInstance -Identity $SearchAppServiceInstance

On va maintenant créer le pool d’application qui supportera l’application de service de recherche : $AppPool = new-SPServiceApplicationPool -name $SearchAppPoolName -account $SearchAppAccount 

(On pourra entrer $AppPool afin de vérifier que le pool est bien créé avec le compte demandé)

A l’aide du pool d’application créé, du nom de la base d’administration, nous allons créer l’application de service de recherche (cette étape peut prendre plusieurs minutes) : $SearchServiceApplication = New-SPEnterpriseSearchServiceApplication -Name $SearchAppServiceName -applicationpool $AppPool -databasename $SearchAppAdminDBName

(On pourra entrer $SearchServiceApplication pour vérifier que l’instance de l’application de service est bien créée)

Il faut maintenant créer le proxy de l’application de service, pour cela : $SearchAppServiceProxy = new-spenterprisesearchserviceapplicationproxy -name $SearchAppProxyName -Uri $SearchServiceApplication.Uri.AbsoluteURI (On pourra entrer $SearchAppServiceProxy afin de vérifier que le proxy est bien créé) :

Si on lance la console centrale d’administration de SharePoint 2010, et qu’on parcourt les applications de service, on voit bien que le nouveau service de recherche est créé, le proxy est également créé.

Par contre si on clique sur le lien (sur l’application de service que l’on vient de créer), on a un message d’erreur dans la rubrique “Etat du système ” : Le service de recherche ne peut pas se connecter à l’ordinateur hébergeant le composant d’administration. Vérifiez que le composant d’administration 2d013e71-6b6f-4871-839d-41ddcbceaba0 de l’application de recherche Service de Recherche de SharePoint 2010 créé par Powershell fonctionne correctement et réessayez. 

C’est normal, car cous n’avons pas encore fini la création de ce service de recherche. Maintenant il faut créer le composant d’administration… Pour cela : set-SPenterprisesearchadministrationcomponent -SearchApplication $SearchServiceApplication  -searchserviceinstance $SearchAppServiceInstance

Et si on rafraîchit la page de la console d’administration centrale (application de service de recherche précédemment créée), l’erreur sur le composant d’administration n’apparaît plus !

A partir de cet instant vous pourrez reprendre la main depuis la console d’administration de SharePoint 2010 et créer vos sources de contenu, étendues, managed properties, règles d’analyses, etc.

Histoire conclure, voici quelques captures d’écran permettant de comparer un service de recherche créé avec l’assistant de la console d’administration centrale de SharePoint 2010 et un autre créé avec Powershell :

Les noms de composants, bases de données, etc. sont plus simples (fini les GUID  :p )

Notez également que je n’ai pas encore créé de partition ni de composant d’analyse ou encore de composant de requête, c’est également possible avec Powershell… d’ailleurs je le ferai dans un prochain article). Il faudra également associer cette application de service de recherche aux Web Application de ma ferme qui auront à utiliser ce service. Il reste du boulot !