Configure Sharepoint Services

[SP2013] – Déployer le Machine Translation Service de SharePoint Server 2013

Posted on Updated on

Bonjour à tous.

Dans cet article je vais tenter de vous expliquer ce qu’est le Machine Translation Service de SharePoint Server 2013 mais également comment le déployer sur votre ferme SharePoint.

J’ai choisi de déployer et configurer un maximum de choses avec PowerShell dans le but d’automatiser le déploiement.

1/ Machine Translation Service : qu’est-ce que c’est ?

Le Machine Translation Service est une nouvelle application de service, apparue avec SharePoint 2013 et disponible dans les versions Standard et Enterprise.

Il permet de traduire automatiquement non seulement les sites (colonnes, listes, pages) mais également le contenu des documents qui seront stockés dans ce site, et ce à la demande des utilisateurs. D’ailleurs ce contenu peut être pré-traduit (via une planification et un TimerJob) ou bien à la volée sur la demande d’un utilisateur.

On comprendra rapidement l’intérêt de ce service lors du déploiement de portails de publication SharePoint utilisant les Variantes.

Plutôt intéressant sur le principe !

Vous trouverez également sur Technet quelques exemple d’appels à API du Machine Translation Service via du code client ou serveur : http://msdn.microsoft.com/fr-fr/library/office/jj163145(v=office.15).aspx.

De plus, ce service limite la taille des fichiers qui pourront être convertis :

Type de fichier / extensions Limite de taille (en Ko)
Texte (txt) 15 360
HTML (html, xhtml, xhtm, htm, aspx) 15 360
Word (doc, docx, docm, dot, dotx, dotm, rtf) 524 288
XLIFF (xlf) 15 360

2/ Prérequis avant le déploiement

Le déploiement de ce service impose quelques prérequis qu’il vous faudra valider ou mettre en œuvre au préalable.

A. Application de service : Gestion des applications

Effectivement, cette application de service Gestion des applications ‘'(App Management Service Application) doit être déployée et configurée sur votre ferme. Pour cela, je vous invite à suivre le guide de déploiement sur Technet : http://technet.microsoft.com/fr-fr/library/fp161236(v=office.15).aspx

B. Application de service : SharePoint Token Service

Le service d’authentification serveur à serveur (STS) doit être déployé et configuré dans le cas où vous travaillez sur une architecture Multi-Tenant. Pour cela, je vous invite à suite le guide de déploiement sur Technet : http://technet.microsoft.com/fr-fr/library/jj655400(v=office.15).aspx

C. Application de service : User Profile

Peut-être un peu plus étonnant, votre ferme doit avoir le Proxy de l’application de service User Profile déployé sur votre ferme SharePoint, et l’application de service correspondante doit être déployée, configurée et démarrée. Pour cela, je vous invite à suivre le guide de déploiement sur Technet : http://technet.microsoft.com/fr-fr/library/ee721052(v=office.15).aspx

D. Accès à internet

Evidemment, ce n’est pas SharePoint qui va effectuer les traductions demandées par les utilisateurs mais bien envoyées et traduites par Microsoft Translation Service. Et donc pour cela, une connexion Internet sur les serveurs SharePoint est requise (ceux où le service de traduction est démarré).

E. Compte de déploiement du service

Evidemment, pour pouvoir déployer et configurer le service, il faut avoir suffisamment de droits. Dans mon cas j’utilise le compte système (compte d’installation de la ferme SharePoint).

De manière générale, ce compte doit avoir les droits :

  • securityadmin sur l’instance SQL Server de votre ferme SharePoint
  • db_owner sur l’instance SQL Server de votre ferme SharePoint
  • Dans le groupe Administrateurs local de vos serveurs SharePoint où on lancera le déploiement

F. Compte du pool d’application

Dans l’exemple que je vais développer ci-après, j’utilise un nouveau pool d’application pour ce service. Il est nécessaire que le compte utilisé par ce pool ait accès au service User Profile avec le contrôle total. Pour cela, il faut se rendre dans la page de gestion du service de profil utilisateur dans la central admin et ajouter le compte avec contrôle total :

12

3/ Déploiement du service avec PowerShell

Ma ferme SharePoint est simple, elle est composée :

  • D’un serveur Controleur de Domaine (AD, windows server 2008R2 + DNS)
  • D’un serveur SharePoint Server 2013 Enterprise EN (+ language pack FR) sans SP1 (Windows Server 2012)

Voici les applications de service déployées sur ma ferme :

02

Une fois les prérequis vérifiés, nous pouvons lancer le SharePoint Management Shell en s’étant au préalable loggé sur le serveur avec le compte qui a les bons droits :

01

Nous allons commencer par créer un nouvel application pool (possible d’utiliser un existant)  et positionner les variables utiles :

#Variables
$servicename = "Machine Translation Service"
$serviceproxyname = $servicename + " Proxy"
$databasename = "SharePoint_MTS"
$databaseserver = "SP2013\SQL2012"
$apppoolname = "SharePoint_MTS_AppPool"
$apppoolaccount = "demo\spappservice"

$apppool = New-SPServiceApplicationPool -Name $apppoolname -Account $apppoolaccount

03

NB : (source Technet) Le compte utilisé par le pool d’applications doit également disposer d’autorisations de contrôle total sur l’application de service de profil utilisateur. Si vous créez un pool d’applications et un compte, veillez à ajouter le compte à la liste des comptes qui peuvent utiliser l’application de service de profil utilisateur, puis accordez les autorisations de contrôle total à ce compte. Pour plus d’informations, voir Limiter ou activer l’accès à une application de service (SharePoint 2013).

Puis l’on va créer l’application de service avec la commande :

New-SPTranslationServiceApplication -Name $servicename -DatabaseName $databasename -DatabaseServer $databaseserver -ApplicationPool $apppoolname –Default

04

05

L’application de service est maintenant créée, il faut démarrer le service sur le serveur :

Get-SPServiceInstance | where-object {$_.TypeName -eq "Machine Translation Service"} | Start-SPServiceInstance

06

07

4/ Configuration du service avec PowerShell

L’application de service étant créée, nous pouvons maintenant la configurer avec PowerShell.

Pour cela, toujours dans le SharePoint Management Shell, nous allons fixer :

  • La fréquence d’exécution du TimerJob de traduction : 15min
  • Le nombre maximal d’essais pour la traduction : 5
  • Le nombre de jours de conservation des travaux de traduction terminés (historique) : 30
  • Le nombre maximal de demandes de traductions synchrones : 100
  • Le nombre maximal de documents à convertir avant le redémarrage de la conversion : 300

Pour cela, nous allons utiliser la commande suivante :

Set-SPTranslationServiceApplication -Identity $servicename -EnableAllFileExtensions -UseDefaultlnternetSettings -TimerJobFrequency 15 -MaximumTranslationAttempts 5 -JobExpirationDays 30 -MaximumSyncTranslationRequests 100 -RecycleProcessThreshold 300 -DisableBinaryFileScan 1

08

Notez bien qu’il faut redémarrer le service juste après, comme précisé dans le Management Shell. Et donc :

Get-SPServiceInstance | where-object {$_.TypeName -eq "Machine Translation Service"} | Stop-SPServiceInstance

Get-SPServiceInstance | where-object {$_.TypeName -eq "Machine Translation Service"} | Start-SPServiceInstance

09

Les paramètres sont bien appliqués dans les paramètres de l’application de service :

10

11

Voilà, c’est bon pour la configuration !

5/ Vérification de la traduction

Pour vérifier le bon fonctionnement de tout cela, j’ai créé une nouvelle collection de sites de type Publishing portal, en Anglais :

13

Sur la page d’accueil du site, on propose directement un lien “Make your site multilingual”. Nous allons pouvoir créer les variantes et leurs étiquettes directement depuis cette page (ou depuis les paramètres du site). Je définis donc une variante par défaut en anglais et une en français :

14

Lors de la création du label français, on propose d’utiliser les service du Machine Translation Service : 15

16

17

Lorsque les étiquettes de variations sont créées, il faut patienter quelques minutes afin que le TimerJob qui créée les hiérarchies soit exécuté. Pour forcer la chose, il vous suffira de lancer ce job manuellement depuis la console d’administration centrale de SharePoint, dans la section “Monitoring” > “Review job definitions” et de trouver le job appelé “Variations Create Hierarchies Job Definition” associé à la WebApplication sur laquelle le portail de publication est créé. Puis de cliquer sur le bouton “Run Now”.

Les variations sont maintenant créées :

18

Et nous pouvons maintenant aller sur les deux variations EN / FR :

19

20

Dans le ruban, dans l’onglet VARIANTES, on a maintenant le bouton “Traduire automatiquement” :

21

 

Un message apparait nous informant que quelques configurations sont encore nécessaires et nous seront notifiés par e-mail :22

A noter au passage que la traduction n’est pas possible depuis le site anglais, puisque c’est la variation “maitre” (pas d’onglet VARIANTES) :

23

Vous pouvez également suivre l’avancement de la traduction via le bouton “Etat de la traduction” dans l’onglet VARIANTES

24

 

Et avec des documents ?  Je me rends donc sur le site Français et j’upload dans la bibliothèque de documents Documents un fichier Word (docx) contenant la recette du cheesecake en anglais. Ce fichier s’appelle cheesecake.docx, et volontairement j’utilise un compte collaborateur sur ma collection de sites appelé “Lenny” :

29

25

A noter la présence du champ “Etat de la traduction” qui est par défaut à la valeur “Traduction effectuée”. J’ai modifié la valeur pour mettre “Traduction demandée”. Pour autant la traduction ne sera pas lancée automatiquement.

Je sélectionne alors l’élément et je clique sur VARIANTES dans le ruban, et je clique sur Traduire automatiquement > Elements sélectionnés uniquement :

26

La traduction démarre :

27

La traduction est terminée, le champ Etat de la traduction est maintenant à la valeur “Traduction effectuée” :

28

Ouvrons le fichier pour voir ce qu’il en est ! Le fichier est “bien” traduit. En effet, cela ne vaudra jamais une belle traduction littéraire, mais cela dit ça reste compréhensible :

30

Vous pouvez également suivre l’état d’avancement de la traduction en utilisant le bouton “Etant de la traduction” dans l’onglet VARIANTES :

31

32

 

Voilà, c’est tout pour aujourd’hui !

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 !