PowerShell

[SharePoint Online] – Modifier la Timezone sur une collection de sites

Posted on Updated on

Bonjour à tous,

Aujourd’hui un script utile pour modifier la Timezone (fuseau horaire) sur l’ensemble des sites d’une collection sur SharePoint Online (Office 365). J’ai eu ce besoin suite à une migration d’un tenant O365 vers un autre tenant O365 hébergé sur une autre plaque (Europe vers Etats-Unis).

J’ai décidé ici d’utiliser le CSOM de SharePoint Online mais c’est tout à fait réalisable avec du Powershell ou en utilisant le Pattern & Practice (https://dev.office.com/patterns-and-practices).

Voici le script que j’ai utilisé (qui est sans doute perfectible et optimisable !).

Tout d’abord, il vous faudra installer les binaires Microsoft.SharePoint.Client.dll et Microsoft.SharePoint.Client.Runtime.dll via le setup : https://www.microsoft.com/en-US/download/details.aspx?id=35588 (à télécharger & installer donc). Ces dlls seront installées par défaut dans C:\Program Files\SharePoint Online Management Shell\Microsoft.Online.SharePoint.PowerShell\.

Une fois ceci fait, vous pourrez les référencer dans votre script de cette manière :


add-type -Path 'C:\Program Files\SharePoint Online Management Shell\Microsoft.Online.SharePoint.PowerShell\Microsoft.SharePoint.Client.dll'
add-type -Path 'C:\Program Files\SharePoint Online Management Shell\Microsoft.Online.SharePoint.PowerShell\Microsoft.SharePoint.Client.Runtime.dll'

Ensuite, j’initialise la connexion vers la collection de site que je souhaite mettre à jour (remplacer par vos valeurs ce qui est entre [ ]) :

$SiteCollectionUrl = "https://[MONTENANT].sharepoint.com/sites/[MACOLLECTIONDESITES]"
$username = "[LOGIN]@[DOMAIN].com"
$password = "[PASSWORD]"

Puis ensuite, on initialise le contexte :

function GetClientContext($SiteCollectionUrl, $username, $password) {
    $securePassword = ConvertTo-SecureString $password -AsPlainText -Force
    $context = New-Object Microsoft.SharePoint.Client.ClientContext($SiteCollectionUrl)
    $credentials = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($username, $securePassword)
    $context.Credentials = $credentials
    return $context
}

 

Et enfin la fonction qui permet de mettre la Timezone à jour. Pour ma part, je la positionne sur la Timezone “(UTC) Dublin, Edinburgh, Lisbon, London”. Une petite recherche sur le net pour trouver votre zone… (http://blog.jussipalo.com/2013/10/list-of-sharepoint-timezoneid-values.html).

Cette fonction est récursive et permet d’itérer sur l’ensemble des sites de la collection :

function ProcessSites($subsiteurl){
    $clientContext = GetClientContext $subsiteurl $username $password
    $rootWeb = $clientContext.Web
    $childWebs = $rootWeb.Webs
    $clientContext.Load($rootWeb)
    $clientContext.Load($childWebs)
    $clientContext.ExecuteQuery()
 
    write-host $rootWeb.url -ForegroundColor Yellow
    $TimeZones = $rootWeb.RegionalSettings.TimeZones
    $clientContext.Load($TimeZones)
    $clientContext.ExecuteQuery()

    $RegionalSettings = $rootWeb.RegionalSettings
    $clientContext.Load($RegionalSettings)
    $clientContext.ExecuteQuery()
    $TimeZone = $TimeZones| Where {$_.Description -eq "(UTC) Dublin, Edinburgh, Lisbon, London"}

    $TimeZone | Select ID,Description
    Write-Host "TimeZone " $TimeZone.Description -ForegroundColor Yellow
    $RegionalSettings.TimeZone = $TimeZone
    $RegionalSettings.Update()

    $rootWeb.Update()
    $clientContext.ExecuteQuery()
    foreach ($childWeb in $childWebs)
    {
        write-host $childWeb.url -ForegroundColor Yellow
        $clientContext.Load($childWeb)
        $clientContext.ExecuteQuery()

        $TimeZones = $childWeb.RegionalSettings.TimeZones
        $clientContext.Load($TimeZones)
        $clientContext.ExecuteQuery()

        $RegionalSettings = $childWeb.RegionalSettings
        $clientContext.Load($RegionalSettings)
        $clientContext.ExecuteQuery()
        $TimeZone = $TimeZones | Where {$_.Description -eq "(UTC) Dublin, Edinburgh, Lisbon, London"}

        $TimeZone | Select ID,Description
        Write-Host "TimeZone " $TimeZone.Description -ForegroundColor Yellow
        $RegionalSettings.TimeZone = $TimeZone 
        $RegionalSettings.Update()

        $childWeb.Update()
        $clientContext.ExecuteQuery()

        Write-Host "Done :" $childWeb.Title "-" $TimeZone.ID

        ProcessSites $childWeb.url
    }
}


ProcessSites $SiteCollectionUrl

Il ne reste qu’à lancer dans Powershell ou Powershell ISE.

Advertisements

[SPOnline] – Verrouiller un site en lecture seule

Posted on

Bonjour à tous,

Aujourd’hui une astuce toujours utile et en particulier pour lors des migrations de sites ou les fermetures pour maintenance.

Sur SharePoint OnPremise, il est facile de jouer avec le “Lockstate” qui l’on passe en readonly via quelques lignes de PowerShell… Mais sur SharePoint Online, ce statut n’existe pas ! Vous avez juste la possibilité de le passer à “NoAccess” (aucun accès pour personne, sauf les administrateurs de la collection de sites) ou “Unlock” qui déverrouille donc…

L’astuce consiste à utiliser une politique de site (Site Policy) qu’il faut créer à la racine de la collection de sites. Pour cela, il faut se rendre dans les paramètres du site (racine de la collection de sites) :

01

Puis accéder au menu “Site Policies” :

02

Et enfin créer une nouvelle Policy :

03

On lui donne un nom, description et surtout :

  • Ne pas fermer le site automatique et ne pas le supprimer !
  • Cocher la case : le site sera en readonly quand il sera fermé

On enregistre ensuite :

04

On revient dans les paramètre du site :

05 06

Et cette fois-ci on va dans le menu “Site Closure and Deletion” :

07

On choisit dans la liste déroulante notre nouvelle policy et on valide la page :

08

On revient de nouveau dans le même menu :

09

Et cette fois-ci on clique sur le bouton “Fermer le site maintenant” (Close this site now) :

10

Immédiatement, un bandeau rouge apparaît en haut de la page nous informant que le site est bien en ReadOnly :

11

 

En espérant que cela vous soit utile !

 

[SharePoint] – Script PowerShell pour afficher les tailles des bases de données

Posted on Updated on

Bonjour à tous,

Aujourd’hui un petit script bien utile qui vous permettra d’afficher la taille des bases de données d’une ferme SharePoint OnPremise.

Cela permettra à l’administrateur de ferme principalement de suivre l’évolution du stockage dans la ferme SharePoint, afin d’affiner ses quotas, optimiser son serveur / cluster SQL Server.

Le but est donc de créer un petit script qui parcourra les Web Applications, puis les bases de données qui leur sont associées (on ne sélectionne donc pas les bases de données des Applications de Service) et d’afficher le tout dans une GridView par exemple.

Dans cette démo, j’utiliserai l’environnement PowerShell ISE (Integrated Scripting Environment), avec Windows Server 2012 et une plateforme SharePoint Server 2013 Enterprise (Pré-SP1).

Première étape, lancer PowerShell ISE avec le compte Administrateur de la ferme SharePoint :

02

Et entrer le script tout fait 🙂

Ok, je vais détailler un peu son contenu :

Première étape, afin que l’on puisse lancer le script avec PowerShell, sans utiliser le SharePoint Management Shell, on ajoute l’import des Cmdlets SharePoint :

If ((Get-PSSnapIn -Name Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue) -eq $null ) 
{ Add-PSSnapIn -Name Microsoft.SharePoint.PowerShell }

$host.Runspace.ThreadOptions = "ReuseThread"

Puis on démarre un scope pour les objets utilisés dans le script afin qu’ils soient automatiquement “Disposés” à la fin de l’exécution. Pour cela, nous allons utiliser les commandes (au début et à la fin du script) :

Start-SPAssignment –Global
Stop-SPAssignment –Global

Plus de détails ici : http://technet.microsoft.com/fr-fr/library/ff607664(v=office.15).aspx

On commence ensuite la construction dun tableau (Hashtable plus particulièrement) en parcourant les WebApplications, les bases de contenu et en calculant leur taille en GB :

$webApps = Get-SPWebApplication -IncludeCentralAdministration
foreach($WebApp in $spWebApps)
{
    $ContentDBs = $webApp.ContentDatabases
    foreach($ContentDB in $ContentDBs)
    {    
        $size = [Math]::Round(($ContentDB.disksizerequired/1GB),2)

        $DBdetails = New-Object PSObject
        $DBdetails | Add-Member -Name "Web Application Name" -MemberType NoteProperty -Value $WebApp.DisplayName
        $DBdetails | Add-Member -Name "Database Name" -MemberType NoteProperty -Value $ContentDB.Name
        $DBdetails | Add-Member -Name "Database Size (in Gb)" -MemberType NoteProperty -Value $size         $data += $DBdetails
    }
}

Puis pour terminer, on affiche le tout dans une GridView :

$DB = $data | Out-GridView -Title "SharePoint Databases Size" –PassThru

Il nous faut ajouter un try/catch pour gérer les exceptions… ce qui donne au final :

03

Puis on lance l’exécution du script (sauvegardé dans un fichier PS1) ou avec le bouton “Play” de PowerShell ISE :

05

Et voilà !

[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 & SP2013] – Envoyer les résultats de l’analyseur de santé et d’intégrité par e-mail

Posted on Updated on

 

Bonjour à tous.

Cela fait quelques temps que je n’avais rien publié, je reviens avec un script bien pratique permettant d’envoyer les résultats produits par l’analyseur de santé et d’intégrité de SharePoint (SharePoint Health Analyzer) par e-mail, à l’administrateur par exemple.

Le but étant de ne plus avoir à se connecter à l’administration centrale de SharePoint pour consulter et monitorer l’état de la plateforme, mais d’automatiser cela par un envoi de courrier électronique.

Pour cela, nous allons écrire un script permettant de récupérer le contenu des résultats, récupérer les paramètres d’envoi de courrier électronique et enfin automatiser le tout via une tâche planifiée. Et bien sûr compatible avec SharePoint 2010 et SharePoint 2013 !

1/ Récupérer les paramètres d’envoi d’e-mail

NB : le script doit être exécuté avec un compte possédant les droits nécessaires pour effectuer les opérations. Dans mon cas c’est l’administrateur de ferme SharePoint.

Pour cela, c’est très simple. Nous allons écrire un script PowerShell permettant de récupérer l’instance du site d’administration centrale de SharePoint puis récupérer les paramètres de courrier sortant (Outgoing e-mail parameters).

Pour récupérer la Web Application de l’administration centrale, soit on connait l’URL soit on ne la connait pas.

Dans le cas où on la connait (il faudra la modifier lorsque l’on changera de ferme… et si elle change d’url / serveur) :

$w = Get-SPWebApplication http://sitename

Si on ne la connait pas, et si on veut faire un script portable (mon cas) :

$CAWebApp = (Get-SPWebApplication -IncludeCentralAdministration) | ? { $_.IsAdministrationWebApplication -eq $true }

$CARootWeb = Get-SPWeb -Identity $CAWebApp.Url

Ce qui donne :

01

On récupère bien l’adresse du site Web (racine) de la Web Application contenant la centrale d’administration de notre ferme SharePoint.

Ensuite, nous allons récupérer les paramètres :

  • L’adresse de provenance (From)
  • L’adresse (le nom) du serveur d’envoi d’e-mails (renseigné dans la console d’administration centrale de SharePoint).
$from = $CAWebApp.OutboundMailReplyToAddress

$mailserver = $CAWebApp.OutboundMailServiceInstance.Server.Address

Et également fournir l’adresse où l’on souhaite envoyer le courrier électronique :

$to = "admin.sharepoint@demo.local"

02

2/ Récupérer le contenu du SharePoint Health Analyzer

Le SharePoint Health Analyzer enregistre ses résultats dans une liste SharePoint dont l’adresse est statique (toujours la même), dans le site racine de l’administration centrale SharePoint.

Il suffit donc de se connecter à cette liste, d’en récupérer le contenu pour le formater dans le corps du courrier électronique.

Récupérons l’instance de la liste de résultats :

$list = $CARootWeb.GetList("\Lists\HealthReports")

03

Il nous reste ensuite à récupérer le contenu de cette liste et le formater dans un contenu HTML qui deviendra le corps de l’e-mail. Pour récupérer le contenu, rien ne vaut une petite requête CAML !

Ici nous voulons récupérer seulement les cas qui ne sont pas en réussite (succès), c’est-à-dire les problèmes. Il faut donc filtrer sur un champ qui s’appelle “HealthReportSeverity” (internalName, en anglais dans mon ca), en ne récupérant que les items où la valeur est différente de “4 – Success” :

$where = "<Where><Neq><FieldRef Name='HealthReportSeverity' /><Value Type='Text'>4 - Success</Value></Neq></Where>"
$query = New-Object Microsoft.SharePoint.SPQuery
$query.Query = $where
$items = $list.GetItems($query)

Dans mon cas, je récupère 3 items ($items.Count) :

04

3/ Construire le contenu du courrier électronique

Le contenu étant récupéré, il nous faut construire le corps du message en HTML (très basique !). Pour ma part, je suis parti sur quelque chose de simple: un tableau.

Ce tableau contiendra :

  • Le nom de l’erreur avec un lien pointant vers le détail (vers la page DispForm.aspx de SharePoint)
  • Le Type (catégorie) d’erreur
  • Le contenu du message
  • Le type d’erreur : avertissement, erreur, etc.
  • La date d’exécution (de la tâche planifiée SharePoint)

Nous allons également ajouter un peu de texte avant et après le tableau pour préciser :

  • La date et l’heure courante
  • Le nom du rapport
  • Une signature

On construit l’entête et la signature :

NB : Attention à l’encodage des simples et double quotes !!! => Passer par NotePad / Notepad++, ça vous aidera 🙂

$entete = "Bonjour, voici le rapport d’exécution de l’analyseur de santé et d’intégrité de la ferme SharePoint : " + $CAWebApp.Farm.Name

$titre = "<Title>" + $entete + "</Title>"

$signature = "Bonne journée, <br/><br/>L’équipe SharePoint."

05

Puis nous allons construire le tableau en itérant sur la collection d’Items chargée via la requête CAML :

$corps = "<h2>" + $entete + "</h2><br />"

$corps = $corps + "<table cellspacing='5' cellpadding='5' style='width: 100%;border:1px solid #bbbbbb'>" 
foreach ($item in $items)
{
$itemTitle = $item.Title
$itemUrl = $CARootWeb.Url + ($list.Forms | where { $_.Type -eq "PAGE_DISPLAYFORM" }).ServerRelativeUrl + "?ID=" + $item.ID

$itemSeverity = $item["Severity"]
$itemCategory = $item["Category"]
$itemExplanation = $item["Explanation"]
$itemModified = $item["Modified"]

$corps = $corps + "<tr>"
$corps = $corps + "<td><a href=`"" + $itemUrl + "`">" + $item.Title + "</a></td>"
$corps = $corps + "<td>" + $itemCategory + "</td>"
$corps = $corps + "<td>" + $itemExplanation + "</td>"
$corps = $corps + "<td>" + $itemSeverity + "</td>"
$corps = $corps + "<td>" + $itemModified + "</td>"
$corps = $corps + "</tr>"
}

$corps = $corps + "</table><br /><br />" + $signature

$corpshtml = ConvertTo-Html –Head $titre –Body $corps

06

07

4/ Envoyer un e-mail en PowerShell

Ensuite il nous faut envoyer cet e-mail via des cmdlets PowerShell. Pour cela, nous allons recourir à l’API System.Net.Mail bien connue dans le monde Microsoft :

$CARootWeb.Dispose()
Send-MailMessage –From $from –To $to –Subject $titre –BodyAsHtml $corps –SmtpServer $mailserver

Puis fermer la connexion sur la Web Application :

$CARootWeb.Dispose()

Attention, dans cet exemple j’ai configuré le service SMTP sur mon serveur SharePoint, et en renseignant correctement les paramètres d’e-mails sortants dans la console d’administration centrale de SharePoint.

5/ Automatiser l’envoi par une tâche planifiée Windows

Dernière étape, l’automatisation. Pour cela nous allons créer une tâche planifiée Windows, exécutée sur l’un des serveurs SharePoint de la ferme. Dans mon cas ce sera sur le serveur hébergeant l’Administration Centrale de SharePoint.

Cette tâche planifiée devra lancer PowerShell, puis appeler le script. Il nous faut donc modifier à nouveau ce script pour intégrer l’appel du Snap-In permettant de charger le contexte SharePoint dans PowerShell (ce que fait le Management Shell de SharePoint, automatiquement).

Je vous invite à vous reporter à http://technet.microsoft.com/fr-fr/library/ee806878(v=office.15).aspx.

Nous allons alors ajouter en haut du fichier du script PowerShell :

if ((Get-PSSnapin "Microsoft.SharePoint.PowerShell" –ErrorAction SilentlyContinue) -eq $null)
{
Add-PSSnapin "Microsoft.SharePoint.PowerShell"
}

Et enregistrer le tout dans un fichier avec l’extension ps1. Pour moi SPHealthAnalyzerSendMail.ps1, que je tente d’exécuter avec PowerShell (et non pas le Management Shell de SharePoint :

14

 

Voici le fichier obtenu, vous pouvez le télécharger ici : http://1drv.ms/1ot9VJI

Créons donc cette tâche planifiée ! Pour cela, il faut ouvrir l’assistant de création des tâches panifiées de Windows Server :

Dans Démarrer > Outil d’administration > Tâches planifiées :

image

image

 

Cliquer sur “créer une tâche” dans le panneau Actions à droite et donnez-lui un nom, description, et surtout le compte exécutant la tâche (l’administrateur de la ferme dans mon cas) :

image

 

Aller dans l’onglet Triggers (déclencheur) et fournir une planification (schedule), dans mon cas chaque jour à 2h00 du matin :

image

 

Puis aller dans l’onglet Actions et entrer les paramètres :

  • Commande : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  • Arguments : –command “.\\SPHealthAnalyzerSendMail.ps1”
  • Répertoire de démarrage : Répertoire où est enregistré votre fichier sur le serveur, dans mon cas dans le répertoire 14 == C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14

image

 

Enregistrer le tout, l’assistant vous demande le mot de passe du compte utilisé pour lancer la tâche :

image

 

La tâche est créée :

image

 

Faites un clic droit, Démarrer pour tester :

image

 

Les résultats de l’exécution sont présentés dans la fenêtre en bas :

image

 

Voici l’e-mail reçu… C’est simple et épuré dira-t’on. Si vous rencontrez des problèmes d’encodage pour les caractères accentués par exemple, n’hésitez pas à jouer avec la fonction :

[System.Web.HttpUtility]::HtmlEncode(“MON TEXTE A ENCODER”)

15

 

Il n’y a plus qu’à revoir un peu le Html envoyé dans l’e-mail pour peaufiner, et c’est tout bon !

[SharePoint 2010 – 2013] – Créer une Target Application sans le Secure Store Service en PowerShell

Posted on Updated on

 

Bonjour à tous,

Cela faisait un petit moment que je n’avais pas publié. Un petit post aujourd’hui pour vous montrer comment ajouter une TargetApplication dans le Secure Store Service de SharePoint. Allons-y !

 

1/ Secure… quoi ?

Le Secure Store Service, appelé Banque d’Informations Sécurisées en français), est une application de service de SharePoint 2010 et 2013 qui vous permet de stocker des couples d’identifiants login/password dans une base encryptée. Ces couples d’identifiants sont destinés à l’usage d’autres applications de services : Business Connectivity Service, PowerPivot, Excel Services, etc. afin qu’ils soient en capacité à se connecter à des sources de données par exemple, avec des identifiants différents de ceux de l’utilisateur connecté, du pool d’application, du compte administrateur.

Dans mon cas, il s’agit de stocker des identifiants afin qu’une application personnalisée puisse se connecter à un serveur Exchange 2010 via ses WebServices. Je ne voulais pas stocker ces informations dans SharePoint ou dans un fichier de configuration par exemple. L’avantage étant que ces paramètres sont cryptés et modifiables par l’administrateur de la ferme.

 

2/ Prérequis

En prérequis, il faut bien sûr déployer cette application de service qui sera disponible pour :

  • · SharePoint Server 2010 Standard
  • · SharePoint Server 2010 Enterprise
  • · SharePoint Server 2013 Standard
  • · SharePoint Server 2013 Enterprise

Point sur n’importe laquelle des versions Foundation ni SharePoint 2007 donc.

Pour déployer et configurer cette application de service, je vous invite à lire : http://technet.microsoft.com/fr-fr/library/ee806866(v=office.15).aspx

 

3/ Un peu de PowerShell

Cette démo sera réalisée avec SharePoint Server 2010 Enterprise.

Pour commencer, nous allons lancer le Management Shell de SharePoint (PowerShell avec les assemblies/cmdlets nécessaires à l’utilisation avec SharePoint). Pour cela, vous trouverez le raccourci dans Démarrer > Tous les Programmes > Microsoft SharePoint 2010 Products > SharePoint 2010 Management Shell

image

 

Nous allons commencer par renseigner quelques variables nécessaires :

  • $siteurl = ” http://sp2010-dev:82/sites/florent&#8221; ==> Url d’un site pour récupérer le ServiceContext (L’application de service Secure Store Service doit être associée à cette WebApplication !)
  • $ta_name = “ExchangeWS” ==> Nom de ma Target Application
  • $ta_friendlyName = “ExchangeWS for DEMO” ==> Nom “Friendly” de ma Target Application
  • $ta_contactEmail = “admin@sp2010.local” ==> Adresse e-mail de contact
  • $ta_owner = “DEMO\spadmin” ==> Propriétaire de la Target Application
  • $ta_userName = “DEMO\exchangeuser” ==> Login à stocker
  • $ta_password = “P@ssw0rd” ==> Password à stocker

image

Puis on créé la Target Application :

$target = New-SPSecureStoreTargetApplication -Name $ta_name -FriendlyName $ta_friendlyName -ContactEmail $ta_contactEmail -ApplicationType Group

clip_image002

Puis on créé les champs Login et password à stocker :

$usernameField = New-SPSecureStoreApplicationField -name “Exchange Username” -Type WindowsUserName -Masked:$false

$passwordField = New-SPSecureStoreApplicationField -name “Exchange Password” -Type WindowsPassword -Masked:$true

$fields = $usernameField,$passwordField

clip_image004

Puis nous allons créer 2 claims pour l’administrateur et pour le propriétaire :

$adminClaims = New-SPClaimsPrincipal -Identity $a_owner -IdentityType 1

$ownerClaims = New-SPClaimsPrincipal -Identity $a_owner -IdentityType 1

clip_image006

Puis créer la nouvelle Target Application :

New-SPSecureStoreApplication -ServiceContext $contextUrl -TargetApplication $ta -Fields $fields -Administrator $adminClaims -CredentialsOwnerGroup $ownerClaims

$ssa = Get-SPSecureStoreApplication -ServiceContext $contextUrl -Name $ta.Name

clip_image008

Puis on charge les identifiants :

$user = ConvertTo-SecureString $ta_userName -AsPlainText -Force

$password = ConvertTo-SecureString $ta_password -AsPlainText -Force

$credentials = $user,$password

Update-SPSecureStoreGroupCredentialMapping -Identity $ssa -Values $credentials

clip_image010

On peut verifier dans l’administration centrale, la Target Application est bien créée :

clip_image012

clip_image014

clip_image016

On voit ici que les Members (utilisateurs ayant accès à la Target Application) contiennent seulement SPADMIN. Pour ajouter des utilisateurs, on peut modifier les Owner Claims…

clip_image018

Par contre, impossible de valider graphiquement si le login/password est bien ajouté, la fenêtre ne charge pas les valeurs chargées (formulaire vide par défaut). Il faut donc tester… et chez moi ça marche 😉

A bientôt !

Florent.