Configuration SharePoint

[SharePoint 2016] – Services dans la Ferme

Posted on Updated on

Bonjour,

Une autre page qui a pris un petit lifting de la part de l’équipe de développement de SharePoint 2016, c’est la page Services in Farm (Services de la ferme).

01

Pas de grosse révolution mais des informations utiles.

Premièrement la colonne Auto Provision. En effet celle-ci vous informe (Yes) si le service est démarré dans la ferme ou pas (No), sur les serveurs concernés par rapport à leur rôle (MinRoles : https://technet.microsoft.com/EN-US/library/mt346114%28v=office.16%29.aspx). Microsoft ne vous dit plus sur quel serveur le service est démarré mais bien s’il est démarré dans la ferme. Tout est donc bien basé sur la gestion des Roles.

Pratique également, un lien direct vers la/les page(s) de gestion de l’Application de Service dans la colonne Action. Vu le nombre de clic qu’il faut parfois pour arriver à cette page d’administration des Applications de Service, je vais peut être me mettre cette page en favoris 🙂

Cette colonne Action peut contenir 3 types de boutons d’action :

  1. Manage Service Application (service associé à une Application de service, il est activé/déployé)
  2. Disable Auto Provision (Désactiver le service dans la Ferme, les instances sont stoppées sur tous les serveurs)
  3. Enable Auto Provision (Activer le service dans la Ferme, des instances sont démarrées sur les serveurs adéquats par rapport au rôle qui leur a été attribué)

Puis enfin la colonne In Compliance qui devient “tendance” dans SharePoint 2016 Preview , tout comme je vous l’ai présenté dans le post https://kazoumoulox.wordpress.com/2015/08/27/sp-2016-services-on-server/

Ici il s’agit de savoir si le services est en respect des rôles attribués sur l’ensemble de la ferme (pas sur 1 serveur). Un bouton Fix est affiché si ce n’est pas le cas et proposera un assistant (comme expliqué dans le post cité précédemment) pour reconfigurer avec les risques associés… (Vive PowerShell).

 

 

[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 – SP2013] – Modifier la période de rétention des corbeilles

Posted on Updated on

 

Bonjour à tous,

Un petit article aujourd’hui pour apprendre à modifier la période de rétention de la corbeille utilisateur, sur une Web Application spécifique.

Petit rappel au passage, 2 niveaux de corbeilles sont proposés dans SharePoint (Server ou Foundation), et ce depuis…. presque toujours !

Ces deux niveaux de corbeilles ont des particularités :

Le premier niveau est aussi appelée “corbeille utilisateur” et est donc personnelle à chaque utilisateur. Pour faire le parallèle cela correspond à la corbeille “Windows” de l’utilisateur. Les documents supprimés par un utilisateur dans SharePoint sont déplacés dans cette corbeille où ils resteront pour une durée définie. Par défaut, SharePoint limite cette période à 30 jours et les documents supprimés y sont donc conservés durant cette période. C’est ce paramètre que nous allons apprendre à modifier.

Le second niveau de corbeille est aussi appelé “Corbeille de l’administrateur”. Les documents ayant atteint la période de rétention du premier niveau de corbeille sont déplacés dans cette corbeille (et non pas supprimés définitivement). Ils y sont conservés… non pas dans le temps mais par rapport au quota fixé sur la collection de sites. Par défaut, le ratio est fixé à 50%. Par exemple, si le quota de la collection de sites est fixé à 1Go, l’administrateur pourra conserver 500Mo de documents supprimés. Ensuite les plus anciens documents sont collectés puis supprimés.

 

Nous allons donc voir comment modifier la période de conservation du niveau 1 de la corbeille. Pratique pour automatiser le paramétrage de vos Web Applications par exemple. Oui, parce que ce paramètre est bien disponible sur la Web Application.

Première chose à faire, charger les Cmdlets pour SharePoint. :

If ((Get-PSSnapIn -Name Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue) -eq $null )
{ Add-PSSnapIn -Name Microsoft.SharePoint.PowerShell }
$host.Runspace.ThreadOptions = “ReuseThread”

 

Puis fixer les quelques paramètres nécessaires : Url de la Web Application et rétention souhaitée :

$webAppUrl = “http://URL DE VOTRE WEB APPLICATION”
$ConservationInDays = 90

 

Puis on récupère et on affiche la rétention actuellement appliquée sur la Web Application :

$Webapp = Get-SPWebApplication -Identity $webAppUrl $days = $Webapp.RecycleBinRetentionPeriod

Write-Host(“Conservation actuelle ” + $days + ” jours”) -ForegroundColor Yellow

 

Et enfin modifier la période de rétention si elle est différente de celle fixée :

if($days -ne $ConservationInDays)

{

$Webapp.RecycleBinRetentionPeriod = $ConservationInDays $Webapp.Update()

Write-Host(“La période de conservation a été fixée à ” + $ConservationInDays + ” jours”) -ForegroundColor Green

}

Ce qui donne :

01

02

 

Et pour changer le quota appliqué à la corbeille de niveau 2 (pour le fixer à 30% par exemple) :

$Webapp.SecondStageRecycleBinQuota = 30

$Webapp.Update()

03

 

Et voilà !

SP2010 – Configurer Search Server avec PowerShell – Part 3

Posted on Updated on

Et enfin… la troisième partie !

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

La seconde partie expliquant comment créer les étendues personnalisées, des des propriétés gérées se trouve ici : https://kazoumoulox.wordpress.com/2012/01/17/confsearchpowershell-part2/

Cette troisième partie permettra d’ajouter des règles d’inclusion/exclusion dans l’étendue personnalisée en utilisant les propriété gérées de la partie 2.

Rappelons-nous tout d’abord dans quel état était notre ferme SharePoint 2010. Nous avons créé le service de recherche de SharePoint, créé une source de contenu, une étendue personnalisée, une propriété gérée pointant sur la propriété indexée Type de Contenu des enregistrements SharePoint (Document ou Items). Bien sûr le tout à l’aide du Management Shell de SharePoint !

L’objectif est presque rempli… il nous reste toutefois quelques petites choses à faire !

Vous en souvenez peut-être, mais voici l’état dans lequel nous avons laissé l’étendue personnalisée après nos précédentes et trépidantes aventures :

Nous avons une étendue avec une seule règle, celle limitant les résultats inclus dans la source de contenu “Nouvelle Source”. Nous allons donc en ajouter une nouvelle qui sera cette fois-ci requise et limitera les résultats aux documents et enregistrements dont le type de contenu est “Demande de congés” (qui a été au préalable déclaré dans une collection de sites inclue dans la source de contenu).

Première étape (si ce n’est déjà fait), 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”
Puis récupérer l’étendue personnalisée avec :
  • $MyScope = GetSPEnterpriseSearchQueryScope -SearchApplication $searchapp -Identity “Première Etendue en PowerShell”
  • $MyScope
Nous avons déja vu, dans la partie 2 qu’il fallait utiliser le cmdlet New-SPEnterpriseSearchQueryScopeRule pour ajouter une nouvelle règle à une étendue personnalisée. On reprend donc cette commande :
  • New-SPEnterpriseSearchQueryScopeRule -RuleType PropertyQuery -ManagedProperty ContentTypeForSearch2 -PropertyValue “Demande de congés” -FilterBehavior Require  -scope $MyScope -SearchApplication $searchapp -url http://labs-sp2010/
Voici le résultat dans SharePoint :
Nous avons donc bien créé une nouvelle règle requise, utilisant la propriété gérée ContentTypeForSearch2 (=”Demande de congés”).
Mais pour le moment, il y a 0 éléments remontés… peut être parce qu’il n’y a pas de demande de congés déposées ! …
Dernière opération, lancer la mise à jour des étendues, pour cela, rien de plus simple !
  • $searchapp.StartScopesCompilation()

Cette commande lance la compilation comme on peut le voir dans l’administration centrale de SharePoint :

Et à la fin de la mise à jour :

Donc tout à l’air prêt… y’a plus qu’à tester ! Pour cela je vais ajouter quelques documents utilisant le type de contenu “Demande de congés” dans une bibliothèque de documents de la collection de sites http://labs-sp2010/.

Il faudra bien sûr relancer l’indexation du contenu (incrémentielle ou complète) et vérifier que l’étendue personnalisée contient bien nos documents. Allez c’est parti ! (ça sent la fin ;))

 

Une fois quelques documents ajoutés, il faut bien sûr relancer une indexation (complète pour ma part) afin que le composant crawler (indexeur) parcoure ces documents et indexe le contenu & les méta-données du document… et en particulier notre type de contenu !

Après donc quelques minutes/heures d’indexation, alors voir dans notre nouvelle étendue combien de documents ont été indexés avec le type de contenu souhaité :

 

 

Les données sont donc bien indexée et l’on retrouve nos documents ajoutés dans l’étendue de recherche de SharePoint. Cette étendue pourra alors être utilisée soit dans la liste déroulante des étendues juste devant la searchbox (barre de recherche des sites SharePoint) soit dans les centres de recherche (SharePoint 2010 Server Editions Standard ou Enterprise) et permettront de filtrer à priori ou à posteriori les données. Ces filtres amélioreront l’expérience utilisateur avec le moteur de recherche et leur permettront de trouver plus rapidement les documents recherchés au travers du moteur de recherche de SharePoint.

Cette suite d’articles est donc terminée, en espérant avoir été clair, concis et efficace. Je recherche des sujets pour mes prochains posts… donc si vous avez des idées, laissez moi un message !

[SP2010] – Limitation à 2000 enregistrements dans le BCS SharePoint 2010

Posted on Updated on

Lorsqu’on réalise un BCS (Business Connectivity Service) à l’aide de SharePoint Designer 2010 par exemple, il arrive qu’on se heurte à une limitation imposée par l’application de service BCS. Cette limitation ne permet par de retourner plus de 2000 éléments lors de l’exécution de la méthode “Read List”.

Pour augmenter cette limite, rien de tel qu’un petit script PowerShell !

$appbcs = Get-SPServiceApplicationProxy | where{$_.GetType().FullName -eq (‘Microsoft.SharePoint.BusinessData.SharedService.’ + ‘BdcServiceApplicationProxy’)}

$BCSLimit = Get-SPBusinessDataCatalogThrottleConfig -ServiceApplicationProxy $appbcs -Scope database -ThrottleType items

Set-SPBusinessDataCatalogThrottleConfig -Identity $BCSLimit -Maximum 100000 -Default 20000

On vérifie que cela fonctionne : $BCSLimit = Get-SPBusinessDataCatalogThrottleConfig -ServiceApplicationProxy $appbcs -Scope database -ThrottleType items

$BCSLimit

Le Management Shell doit vous afficher la limite par défaut à 20000 et le maximum à 100000.

Et voilà !