Administration
[SP2013] – Déployer le Machine Translation Service de SharePoint Server 2013
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 :
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 :
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 :
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
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
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
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
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
Les paramètres sont bien appliqués dans les paramètres de l’application de service :
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 :
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 :
Lors de la création du label français, on propose d’utiliser les service du Machine Translation Service : 
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 :
Et nous pouvons maintenant aller sur les deux variations EN / FR :
Dans le ruban, dans l’onglet VARIANTES, on a maintenant le bouton “Traduire automatiquement” :
Un message apparait nous informant que quelques configurations sont encore nécessaires et nous seront notifiés par e-mail :
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) :
Vous pouvez également suivre l’avancement de la traduction via le bouton “Etat de la traduction” dans l’onglet VARIANTES
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” :
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 :
La traduction démarre :
La traduction est terminée, le champ Etat de la traduction est maintenant à la valeur “Traduction effectuée” :
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 :
Vous pouvez également suivre l’état d’avancement de la traduction en utilisant le bouton “Etant de la traduction” dans l’onglet VARIANTES :
Voilà, c’est tout pour aujourd’hui !
[SharePoint 2013] – Installation des Office Web Apps 2013 avec SharePoint Server 2013
Bonjour à tous.
Un nouvel article pour vous montrer comment installer et configurer les Office Web Apps 2013 couplées à SharePoint Server 2013.
Pour l’histoire, les Office Web Apps sont arrivées dans leur deuxième version : nous avons les Office Web Apps 2010 et 2013 à ce jour. Ces OWA vont nous permettre, couplées à SharePoint, d’ouvrir des documents Word, Excel, PowerPoint et OneNote directement dans le navigateur, sans utiliser les composants clients Office. Ce qui peut être évidemment très pratique lors les collaborateurs utilisent des plateformes hétérogènes de types tablettes iPad, Android, des téléphones mobiles ou encore des postes de travail sous MacOS ou une distribution Linux.
Il faut bien intégrer pour commencer qu’à chaque version de SharePoint correspond une version des Office Web Apps :
- SharePoint 2010 (Foundation ou Server) => Office Web Apps 2010
- SharePoint 2013 (Foundation ou Server) => Office Web Apps 2013
Coté Licencing, vous pourrez installer ces OWA (2010 ou 2013) suivant le type de licences que vous possédez pour le pack Office. Si vous possédez les packs Office (en volumes) version 2010 vous pourrez éditer les fichiers Office. Si vous ne les possédez pas, vous pourrez seulement lire des documents Office via les OWA.
De plus, avec la version 2010 des OWA, il était possible d’installer ce composant logiciel sur le même serveur que le serveur SharePoint (en le boostant un peu…). Avec la version 2013, ce n’est plus possible et ces composants s’installe sur un serveur dédié, rattaché au même domaine que SharePoint. Il y a quelques contraintes supplémentaires comme de ne pas avoir installé le pack Office sur ce serveur. Pour plus de renseignements : http://technet.microsoft.com/fr-fr/library/jj219458.aspx
Pour l’architecture utilisée pour cet article, j’ai 3 machines virtuelles (VM) :
- 1 contrôleur de domaine : DOMAIN
- 1 serveur SharePoint Server 2013 Enterprise (EN) : SP2013-DEV
- 1 serveur Office Web Apps 2013 : SPOWA2013
Ces trois serveurs sont rattachés au même domaine : DEMO, sont installés sous Windows Server 2012 ou Windows Server 2008R2 (EN) et à jour :
Et oui… une belle débauche de mémoire et de processeurs… 
Je précise que mes machines Active Directory & SharePoint étaient déjà installées et fonctionnelles avant l’installation d’Office Web Apps.
Première étape installer et configurer Windows Server 2012 (et mettre à jour !), je ne détaillerai pas cela dans cet article.
1/ Préparation du serveur pour Office Web Apps 2013
Lorsque le serveur a été installé et configuré, il faut commencer par télécharger les Office Web Apps 2013. Pour cela, vous pouvez télécharger la Preview ici : http://www.microsoft.com/en-us/download/details.aspx?id=30358 ou ici http://www.microsoft.com/fr-fr/download/details.aspx?id=35489. Vous pourrez également télécharger l’iso depuis votre compte MSDN ou Technet.
Connectez vous ensuite à votre serveur OWA avec un compte du domaine qui est administrateur local du serveur (dans mon cas, c’est le même que le compte d’installation de SharePoint : DEMO\spadmin).
Il faut ensuite exécuter un script PowerShell sur le serveur OWA en lançant la commande en administrateur. Pour cela, rendez-vous sur les “tuiles” de Windows Server 2012, repérez la tuile Windows PowerShell :
Faites un clic-droit sur la tuile :
Et cliquez sur “Run as administrator” :
Vous pouvez avoir l’UAC qui se déclenche, on clique sur “Yes” :
Et PowerShell 3.0 :
Nous allons lancer un script permettant d’installer et de configurer les rôles et services nécessaires sur le serveur pour OWA 2013. Vous trouverez des informations complémentaires ici : http://technet.microsoft.com/fr-fr/library/jj219455.aspx.
On copie / colle le script :
Add-WindowsFeature Web-Server,Web-Mgmt-Tools,Web-Mgmt-Console,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Static-Content,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-Filtering,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,InkandHandwritingServices
Le script d’installation se lance et devrait durer… moins de 3 minutes :
Mais que fait ce script me direz-vous ? Il se charge d’installer le rôle Web Server de Windows Server 2012 (installer IIS), et active sur ce rôle les différents protocoles, utilitaires qu’utiliseront les OWA 2013.
Lorsque le script est terminé, redémarrer le serveur OWA 2013. En allant dans le gestionnaire du serveur, on voit tout de suite le nouveau rôle IIS qui apparait :
Les extensions et fonctionnalités activées :
2/ Installation des Office Web Apps 2013
Maintenant que les prérequis sont installés, il va falloir installer les binaires des Office Web Apps 2013. Pour cela il faut monter l’iso téléchargé précédemment sur la machine virtuelle et lancer le setup d’installation :
Pour cela, on se rend dans l’explorateur de fichier et on fait un clic-droit sur le lecteur DVD avec l’iso monté, puis “Install or run program from your media” (s’il ne démarre pas tout seul).
Encore une fois, l’UAC peut s’activer, on clique sur “Yes” :
Le contrat de licence apparait, on sélectionne la case à cocher en bas, puis on clique sur “Continue” :
On nous demande ensuite d’indiquer l’emplacement d’installation des binaires. Je conserve l’emplacement par défaut : C:\Program Files\Microsoft Office Web Apps et on clique sur “Install Now” :
L’installation débute… on patiente :
L’installation est terminée, on clique sur “Close” :
En option, vous pouvez également installer les languages packs pour OWA 2013. Pour plus de renseignements, visitez ceci : http://technet.microsoft.com/fr-fr/library/jj219455.aspx => Etape 3.
3/ Déploiement des Office Web Apps
L’étape suivante consiste à créer l’application Web qui permettra d’afficher nos documents. Il existe plusieurs types de configurations suivant votre besoin : http ou https, équilibrage de charge, etc.
Dans mon cas, je reste dans un périmètre interne, tous les utilisateurs se connectent en http. Pour corser un peu le tout, nous allons créer l’application en PowerShell. Pour cela, on reprend notre console PowerShell lancée en administrateur et on exécute :
New-OfficeWebAppsFarm –InternalURL "http://servername" –AllowHttp -EditingEnabled
Où :
- New-OfficeWebAppsFarm : permet de créer la ferme OWA 2013
- InternalURL : adresse du serveur courant, dans mon cas http://spowa2013
- AllowHttp : puisque je reste en http
- EditingEnabled : puisque je veux permettre de lire / modifier les documents
Cela donne :
New-OfficeWebAppsFarm –InternalURL http://spowa2013 –AllowHttp -EditingEnabled
Un avertissement vous stipule que pour utiliser le mode édition de document des OWA 2013, il faut que vos utilisateur aient les licences adéquates. Pour savoir si vous pouvez utiliser le mode édition, je vous renvoie vers : http://technet.microsoft.com/fr-fr/library/ff431682.aspx#license.
Pour faire simple, vous avez les licences pour Office 2013, vous pouvez éditer. Sinon la lecture des fichiers est “offerte” par Microsoft.
Pour configurer les licences à utiliser, reportez vous à : http://technet.microsoft.com/fr-fr/library/jj219627.aspx.
Dans mon cas, je choisis donc “Yes” (Y) :
La configuration se poursuit. A la fin, un résumé apparait :
Remarque MSDN : Si des composants de .NET Framework 3.5 ont été installés puis supprimés, il est possible que vous rencontriez des messages de type « Exceptions de service web (500) » ou « Erreur interne du serveur (500.21) » lorsque vous exécutez des applets de commande OfficeWebApps. Pour résoudre ces problèmes, exécutez les exemples de commandes suivants à partir d’une invite de commandes avec élévation de privilèges afin de supprimer les paramètres susceptibles de gêner le fonctionnement normal d’Office Web Apps Server :
%systemroot%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe –iru iisreset /restart /noforce
4/ Vérification que tout est ok…
Pour cela, nous allons utiliser le service de discovery des Office Web Apps en se connectant tout simplement sur une URL :
http://servername/hosting/discovery
Dans mon cas :
http://spowa2013/hosting/discovery
Je lance donc simplement un navigateur (IE 10 ici) et on entre l’adresse ci-dessus. Si Office Web Apps Server fonctionne comme prévu, vous verrez s’afficher un flux XML de découverte WOPI (Web app Open Platform Interface). Les premières lignes de ce fichier doivent se présenter comme dans l’exemple suivant : :
Et ce n’est pas fini…
5/ Configurer SharePoint Server 2013 pour Office Web Apps 2013
Il nous reste maintenant à faire le lien entre notre ferme SharePoint Server 2013 et les Office Web Apps 2013. Et encore une fois… une bonne dose de PowerShell !
Cependant, nous n’allons pas utiliser la console PowerShell 3.0 de Windows Server 2012, mais le SharePoint Management Shell de SharePoint Server 2013… un outil bien connu des administrateurs SharePoint !
Lançons donc la console SharePoint Management Shell, sur le serveur SharePoint bien entendu !
Puis toujours dans cette console, on lance la commande :
New-SPWOPIBinding -ServerName <WacServerName> -AllowHTTP
Dans mon cas (attention aux paramètres suivant ceux fixés lors de la configuration des OWA : http / https en particulier) :
New-SPWOPIBinding –ServerName SPOWA2013 -AllowHTTP
Le Shell vous liste un ensemble de connections WOPI disponibles :
Puis on exécute :
Get-SPWOPIZone
Dans les résultats vous devez avoir absolument :
Internal-https
Et bien sûr nous voudrions avoir du http ! Nous allons donc modifier cette zone avec la commande :
Set-SPWOPIZone –zone “internal-http”
Et on relance avec Get-SPWOPIZone pour vérifier que cela a bien été pris en compte :
Maintenant nous avons :
Internal-http
Ca sent la fin… mais pas tout de suite. Il nous reste à autoriser l’authentification OAuth sur http pour que cela fonctionne. Pour cela on éxécute :
(Get-SPSecurityTokenServiceConfig).AllowOAuthOverHttp
Si cela renvoie “False” dans la console, alors il faut forcer la valeur à “True” :
$config = (Get-SPSecurityTokenServiceConfig) $config.AllowOAuthOverHttp = $true $config.Update()
On relance une petite vérification :
(Get-SPSecurityTokenServiceConfig).AllowOAuthOverHttp
La valeur renvoyée doit être maintenant à “True” :
Pour plus d’informations : http://technet.microsoft.com/fr-fr/library/ff431687.aspx.
6/ Vérification de la configuration globale
Pour vérifier… il faut tester ! Nous allons donc nous connecter sur un de nos sites SharePoint avec un compte utilisateur / collaborateur (pas d’administrateur, super admin etc.)
J’ajoute quelques documents de type Office… dans une bibliothèque de documents :
On clique sur un des fichiers (PowerPoint pour ma part)… et ça marche !
Et du Word :
Et de l’Excel :
Et un OneNote :
Notez à chaque fois la présence des boutons dans le ruban pour éditer les documents, les sauvegarder etc. Ca marche plutôt bien !
Grâce aux Office Web Apps 2013, nous avons aussi la prévisualisation des documents (dans la bibliothèque de documents et dans la recherche) :
Si vous avez activé l’édition / création des documents depuis OWA 2013, lorsque vous cliquez sur le bouton Nouveau document Word, vous pourrez créer vos document directement en Web !
Voilà, c’est fini !
Florent Cazenave 