Bewise recrute… encore !

Bonjour à tous.

Un message rapide… Bewise recherche maintenant un Infographiste/Designer d’applications. L’offre d’emploi est en ligne ici : http://www.bewise.fr/fr-FR/presentation/Pages/Designer012012.aspx.

Je rappelle également que nous recrutons toujours à Toulouse et à Aix en Provence des ingénieurs .Net & SharePoint : http://www.bewise.fr/fr-FR/presentation/Pages/jobs.aspx.

Rejoingnez nous !

SP2010 – Configurer Search Server avec PowerShell – Part 2

Voici donc la suite logique des choses, comment configurer des étendues dans SharePoint 2010 Search Server à l’aide de PowerShell !

La première partie expliquant comment créer des sources de contenu se trouve ici : http://kazoumoulox.wordpress.com/2011/10/06/confsearchpowershell-part1/

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 :

Ensuite, il faut récupérer l’instance du service de recherche avec la ligne (Entre les quotes, c’est le nom de l’application de service qui a été créée dans les précédents articles):

• $searchapp = Get-SPEnterpriseSearchServiceApplication “Service de Recherche de SharePoint 2010 créé par Powershell”

Nous allons ensuite créer une étendue (Scope en Anglais) toujours à l’aide de Powershell :

• $MyScope = New-SPEnterpriseSearchQueryScope -Name “Première Etendue PowerShell” -Description “Première étendue créée avec Powershell” -SearchApplication $searchapp -DisplayInAdminUI $true

=> La variable $true est une variable globale de PowerShell, pas besoin de la déclarer

Dans l’administration centrale, dans les étendues de recherche associées à l’application de service “Service de Recherche de SharePoint 2010 créé par Powershell”, on retrouve bien la nouvelle étendue (pas de règles pour le moment) :

Nous allons à présent ajouter des règles sur cette nouvelle étendue, par exemple lui indiquer quel contenu nous voulons inclure à l’étendue. Dans mon cas, tout le contenu se trouvant dans l’étendue créée précédemment :

• New-SPEnterpriseSearchQueryScopeRule -RuleType PropertyQuery -ManagedProperty ContentSource -PropertyValue “Nouvelle Source” -FilterBehavior Include -url http://labs-sp2010 -scope $MyScope -SearchApplication $searchapp
  

Je voudrais ensuite ajouter une nouvelle règle me permettant de ne remonter que les éléments de certains types de contenu. Pour cela, il faut utiliser la méthode de Glyn Clough que vous trouverez ici : http://www.glynblogs.com/2011/01/create-a-content-type-search-refinement-panel-in-sharepoint-2010.html afin de pouvoir ajouter une propriété gérée pointant sur le type de contenu de chaque élément stocké dans SharePoint (autant documents que items).

En suivant ce tutorial, on obtient dans notre cas :

Création de la propriété gérée :

On la nommera ContentTypeForSearch, on pourra ajouter une petit description et on conservera le type texte pour la propriété. Ensuite, on veillera à ce que “Inclure les valeurs à partir de toutes les propriétés analysées mappées” soit bien sélectionné. Puis il faudra cliquer sur le bouton “Ajouter un mappage” :

Dans la popup modale qui apparaît, on recherchera la propriété ows_ContentType et on cliquera sur OK :

Sélectionner ensuite “Autoriser l’utilisation de cette propriété dans les zones” ainsi que “Ajoutez la propriété gérée au jeu de résultats personnalisé récupéré sur chaque requête. Remarque : par défaut, seuls les 2 premiers kilo-octets de données sont disponibles à l’affichage.” et enfin valider la page en cliquant sur OK :

On voit alors cette nouvelle propriété apparaître dans la liste avec les propriétés suivantes :

J’ai donc une nouvelle propriété gérée mappée sur la propriété ows_ContentType. il me reste à présent à lancer une indexation complète des données par le moteur de recherche de SharePoint. Cela se fait en utilisant le lien “Sources de contenu” sur la gauche puis en utilisant le menu contextuel sur la source de contenu et “Démarrer l’analyse complète” tel que suit :

L’analyse peut être un peu longue suivant le volume d’informations à indexer et suivant la configuration de votre serveur (Processeurs/RAM en particulier). Il faut donc attendre la fin de l’indexation :

OU ALORS…. On peut le faire en Powershell (vous y avez cru hein !!! genre on ne peut pas faire ça en PowerShell…)  !!!

Rappelez-vous, au début de l’exercice nous avions : $searchapp = Get-SPEnterpriseSearchServiceApplication “Service de Recherche de SharePoint 2010 créé par Powershell”.

• Nous allons donc commencer par $metadatacategory = Get-SPEnterpriseSearchMetadataCategory –Identity SharePoint -SearchApplication $searchapp
• Puis $metadatacategory pour vérifier le contenu :

On voit donc qu’il y a 156 propriété indexées dans le magasin de cette application de service de recherche. Nous allons maintenant récupérer celle concernant les types de contenu : ows_ContentType :

• $crawledproperty = Get-SPEnterpriseSearchMetadataCrawledProperty -SearchApplication $searchapp -Name ows_ContentType
• Puis $crawledproperty 

On peut comparer avec les valeurs indiqués lorsque l’on regarde les propriétés de la propriété indexée :

Nous avons donc bien récupéré la propriété indexée “ows_content”. Il va maintenant falloir créer notre propriété gérée, mappée sur cette propriété indexée. Pour cela, toujours grâce à Powershell on créée une propriété gérée nommée ContentTypeSearch2 (on conserve la première pour pouvoir comparer) :

• $managedproperty = New-SPEnterpriseSearchMetadataManagedProperty -SearchApplication $searchapp -Name ContentTypeForSearch2 -Type 1
• $managedproperty
• Voir documentation ici pour le paramètre Type en particulier : http://technet.microsoft.com/en-us/library/ff608089.aspx et également ici : http://www.sharepointstudio.com/Blog/Lists/Posts/Post.aspx?ID=38

Et dans SharePoint, la nouvelle propriété gérée apparaît bien mais il y a deux soucis. Le premier est que cette propriété ne référence pas encore la propriété indexée “ows_ContentType” et également nous avions positionné “Ajoutez la propriété gérée au jeu de résultats personnalisé récupéré sur chaque requête. Remarque : par défaut, seuls les 2 premiers kilo-octets de données sont disponibles à l’affichage.” et cela n’est pas sélectionné dans notre cas.

Première chose donc, mapper la propriété gérée et la propriété indexée :

• New-SPEnterpriseSearchMetadataMapping -SearchApplication $searchapp -ManagedProperty $managedproperty -CrawledProperty $crawledproperty

Dans la page SharePoint des propriétés de cette propriété gérée, on a alors :

La propriété gérée est bien mappée à la propriété indexée… Magique !  Par contre pour trouver comment cocher l’option “Ajoutez la propriété gérée au jeu de résultats personnalisé récupéré sur chaque requête. Remarque : par défaut, seuls les 2 premiers kilo-octets de données sont disponibles à l’affichage.”… sacré challenge !

En effet, aucune propriété ne permet de le faire directement (par exemple un attribut de $managedproperty qu’il faudrait mettre à True). Pas aussi simple.

Comment faire… ??? Le plus simplement que j’ai trouvé est d’ouvrir la page http://labs-sp2010:65000/_admin/search/managedproperty.aspx?property=ContentTypeForSearch2&appid={50762837-130c-4346-b7d8-f5432de62ad4} avec le bloc note et identifier dans quelle “assembly” (DLL) est situé le “code behind” exécuté lorsque l’on clique sur OK. J’ouvre donc ”C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI\Microsoft.Office.Server.Search.dll” à l’aide de ILSpy ou Reflector afin de décompiler le code de cette DLL.

Je parcours alors les namespace et classes de cette assembly pour trouver la bonne classe : Microsoft.Office.Server.Search.Internal.UI.ManagedPropertyPage et la bonne méthode appelée sur le clic bouton : OkButtonClicked :

Et on localise un bout de code où l’on teste que la case à cocher (checkbox) en question est cochée ou pas :

Et on voit que deux propriétés sont mises à jour !!! QueryPropertyBlob et PutInPropertyBlob (à True pour les deux). Il faudra donc sans doutes mettre ces deux propriétés à jour par PowerShell. Je me lance alors dans le test :

• $managedproperty.QueryPropertyBlob = $true
• $managedproperty.PutInPropertyBlob = $true
• $managedproperty.Update()

Et le grand test :

CA MARCHE !!! WAAAAAAAAOUUUUUUUU

Maintenant, il suffit de lancer une indexation complète, bien sûr par PowerShell (je vous rappelle) :

• $contentsource = Get-SPEnterpriseSearchCrawlContentSource ”Nouvelle Source” -SearchApplication $searchapp
• $contentsource.StartFullCrawl()

Lorsque l’indexation sera terminée, la dernière opération consistera à ajouter une règle sur notre étendue de recherche permettant de filtrer les résultat sur le type de contenu (pour rappel, nous voulions tous les documents remontés par la source de contenu “Nouvelle Source” et qui sont du type de contenu “TOTO” (c’est un exemple… :p )).

Mais ce sera pour la prochaine partie !  J’ai commencé cet article en octobre… il est temps qu’il sorte enfin. A bientôt donc !

Bewise recherche un stagiaire !

Bonjour à tous.

Bewise recherche actuellement un stagiaire à Toulouse. Vous trouverez tous les détails ici : http://www.bewise.fr/fr-FR/presentation/Pages/Stagiaire-Developpement-Q1-2012-Toulouse.aspx

SP2010 – Configurer Search Server avec PowerShell – Part 1

Dans deux articles précédents, j’expliquais comment configurer le service de recherche de SharePoint Server à l’aide de Powershell. Le but principal était de pouvoir automatiser la configuration de ce service afin de rejouer ce scénario sur plusieurs environnements.

Dans la continuité, nous allons voir comment créer les sources de contenu ainsi que les étendues de recherche, toujours avec l’aide de Powershell (SharePoint Management Shell).

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 :

Ensuite, il faut récupérer l’instance du service de recherche avec la ligne (Entre les quotes, c’est le nom de l’application de service qui a été créée dans les précédents articles):

• $searchapp = Get-SPEnterpriseSearchServiceApplication “Service de Recherche de SharePoint 2010 créé par Powershell”

On va ensuite créer une source de contenu (vous trouverez de la documentation ici : http://technet.microsoft.com/fr-fr/library/ff607867.aspx) :

• $contentsource = New-SPEnterpriseSearchCrawlContentSource -Name “Nouvelle Source” -SearchApplication $searchapp -Type SharePoint -StartAddresses “http://labs-sp2010/,http://labs-sp2010:60000/”

Ou récupérer une source de contenu existante, par exemple :

• $contentsource = Get-SPEnterpriseSearchCrawlContentSource ”Sites SharePoint locaux” -SearchApplication $searchapp
  

On peut afficher le contenu de la source de contenu :

Et dans l’administration du service de recherche (dans l’administration centrale, gestion des applications de service) :

Et dans les détails de cette nouvelle source de contenu, on peut vérifier que les adresses de départ sont bien fixées. Par contre les planifications ne sont pas mises en place :

A noter qu’à partir des objets déclarés dans la console PowerShell, et en particulier $contentsource, vous pouvez démarrer les analyses (complète et incrémentielle) :

• $contentsource.StartFullCrawl()
• $contentsource.StartIncrementalCrawl()

Ou encore changer la priorité de l’analyse de cette source de contenu (Pensez à appeler la méthode update !!!) :

Mais qu’en est-il des planifications ??

Il est également possible de créer ces planifications pour la source de contenu… voici comment faire. Dans mon cas, il s’agit premièrement de positionner une planification incrémentielle toutes les 30 minutes, à partir d’aujourd’hui à 22h00 :

•  Set-SPEnterpriseSearchCrawlContentSource -Identity $contentsource -ScheduleType Incremental -DailyCrawlSchedule -CrawlScheduleStartDateTime “06/10/2011 22:00″ -CrawlScheduleRunEveryInterval 1 -CrawlScheduleRepeatDuration 1440 -CrawlScheduleRepeatInterval 30

Et pour la planification de l’indexation complète, une fois par semaine, le dimanche à 3h00 :

• Set-SPEnterpriseSearchCrawlContentSource -Identity $contentsource -ScheduleType Full -WeeklyCrawlSchedule -CrawlScheduleDaysOfWeek 1 -CrawlScheduleDateTime “03:00″

Si on vérifie dans le paramétrage du service de recherche :

Donc tout est ok côté sources de contenu… reste maintenant les étendues de recherche (scopes)… dans un prochain épisode !

SP2010 – Créer le service de taxonomie par PowerShell

Dans la lignée des deux précédents billets, un nouvel article concernant la création du service de taxonomie (Managed Metadata Service) de SharePoint Server 2010 (non disponible dans la version Foundation).

Mais pourquoi tout ce script/PowerShell ?? A quoi ça sert ??

Bien sûr à pouvoir scripter l’installation/paramétrage de SharePoint Server 2010 sans avoir à utiliser l’administration centrale et avoir les pages d’attente etc. (oui au bout d’un moment on en a marre de les voir !). D’autant plus quand on fait beaucoup d’installations.

Voici donc quelques lignes de Powershell vous permettant de créer le service de métadonnées gérées, dans une configuration simple. En effet on utilise le serveur SQL par défaut, un compte géré existant (LABS\SP_APPPOOL), déjà utilisé lors des précédents billets.

Première chose, déclarer dans la session Powershell les paramètres, les comptes et les constantes utilisés avant de lancer la création :

• Nom du serveur SharePoint qui supportera l’application de service dans la ferme : $taxoservername = “labs-sp2010″
• Nom de la base SQL stockant les données provenant de cette application de service : $taxosqldbname = “SP2010_ManagedMetadataService_DB”
• Nom de l’application de service : $taxoappservicename = “Service de métadonnées gérées de SP2010″
• Nom du proxy de l’application de service : $taxoappserviceproxyname = “Proxy du ” + $taxoappservicename
• Nom du pool d’application de l’application de service : $taxoappservicename = “SP2010ManagedMetadataServiceAppPool”

Voici ce que cela donne dans la console :

Puis il faudra créer un Application Pool supportant cette application de service, mais avant il faut récupérer le Compte géré permettant de faire tourner ce pool d’application. Pour cela, on utilise (où LABS\SP_APPPOOL est le nom du compte) :

• Compte du domaine supportant le pool d’application (récupéré dans les “Managed Accounts” de SharePoint) : $taxoapppoolaccount = Get-SPManagedAccount -identity LABS\SP_APPPOOL

(Il se peut que le compte géré ne soit pas encore déclaré dans SharePoint, vous pourrez l’ajouter avec New-SPManagedAccount.)

• New-SPServiceApplicationPool -Name $taxoappservicename -Account $taxoapppoolaccount

Ensuite créer l’application de service :

• $taxoappservice = New-SPMetadataServiceApplication -Name $taxoappservicename -ApplicationPool $taxoappservicename -DatabaseName $taxosqldbname

Puis le proxy cette dernière :

• $taxoappserviceproxy = New-SPMetadataServiceApplicationProxy -Name $taxoappserviceproxyname -ServiceApplication $taxoappservice -DefaultProxyGroup

En utilisant le manager de IIS, on ne retrouve pas le pool d’application par son nom. En effet, SharePoint le remplace par un GUID… et ça c’est pas forcément sympa. On peut toutefois le retrouver dans mon cas grâce au compte qui est utilisé pour faire fonctionner ce pool (LABS\SP_APPPOOL) :

Et dans l’administration centrale… ça donne quoi ? Dans la page de gestion des applications de service :

L’application de service est bien créée, elle apparait dans la liste des applications de service disponibles. Mais si on clique sur le lien, on s’aperçoit que le service n’est démarré sur aucun des serveurs de la ferme :

Si on vérifie donc sur la page de gestion des services sur le serveur, on remarque que le service n’est démarré sur aucun serveur de la ferme SharePoint :

Il faut donc lancer ce service sur un serveur (il n’y a qu’un seul serveur SharePoint dans ma ferme + un serveur SQL). On utilisera pour récupérer l’instance du service (attention à la langue !!!) :

• $taxoserviceinstance = $(Get-SPServiceInstance | where {$_.TypeName -ilike “Service Web de métadonnées gérées”} | where {$_.Server -match “SPServer Name=$taxoservername“}).ID

Puis ceci pour démarrer ce service :

• Start-SPServiceInstance $taxoserviceinstance

On va donc vérifier dans l’administration centrale que le service est bien démarré :

Et donc lorsque que l’on clique sur l’application de service :

Et voilà, terminé !

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

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) !

Los Angeles à Toulouse !

Venez vivre la Build Microsoft à Toulouse ! Le 13 septembre à 17h30 Bewise organise SA Build dans les locaux de Microsoft Toulouse rue Marie Curie à Ramonville.

Au programme Windows 8 et ses nouveautés !

Venez partagez ce moment d’échange et de convivialité avec nos équipes. La Build est l’évènement incontournable pour découvrir toutes les futures orientations technologiques de Microsoft. On vous attend nombreux ! Inscriptions et renseignements : sonia.desport@bewise.fr»

 

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

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 :

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

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 :

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 !

SharePoint 2010 : En finir avec l’erreur 7043 du taxonomy Picker

Toute personne ayant installé un SharePoint Server 2010 a dû voir remonter dans l’observateur d’évènement du serveur SharePoint l’erreur 7043. Cette erreur nous informe que SharePoint ne parvient pas à compiler le contrôle utilisateur TaxonomyPicker (/_controlTemplates/TaxonomyPicker.ascx).

En effet, si l’on ouvre ce contrôle depuis l’arborescence (dans le répertoire 14), on s’aperçoit que le code behind lié à ce contrôle utilisateur est sensé être dans la classe : Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker. Or ce n’est pas le cas, il est dans : Microsoft.SharePoint.Taxonomy.TaxonomyFieldEditor.

Pour voir la solution complète, c’est sur le site de Laurent Cotton : http://laurentcotton.wordpress.com/2011/06/15/sharepoint-2010-comment-corriger-lerreur-7043-taxonomypicker-une-bonne-fois-pour-toute/