PowerShell
PeoplePicker qui ne trouve personne dans l’annuaire
Bonjour,
Suite à une migration entre SharePoint 2013 > 2016 > 2019, et passant de Kerberos à Claims, j’ai observé un comportement étrange sur les PeoplePickers (sélecteur de personnes dans SharePoint, associé à une métadonnée de type Personne ou Groupe). En effet, ces derniers ne résolvaient plus les noms !
Dans l’usage classique, lorsque l’on commence à taper le nom d’un collaborateur dans une métadonnée de type Personne, une requête est lancée en direction de l’annuaire (ou des annuaires) afin de récupérer les identités des personnes dont le nom ou le prénom contient les lettres recherchées. Au retour de la requête, les propositions concordantes sont affichées à l’utilisateur qui pourra choisi celle qui l’intéresse.
Lors de cette migration, les PeoplePickers ne résolvaient plus rien, ne proposaient plus rien. Cependant la validation des noms en entrant l’adresse e-mail (UPN) suivi de Ctrl + K validait bien le champ. Etrange !
J’ai tout d’abord pensé à un problème sur la requête ou autour, plus précisément à un port bloqué par le firewall. Non dans mon cas ce n’était pas ca.
Dans les Logs ULS, j’avais peu d’éléments mais quelques erreurs remontaient toutefois, du type :
- Exception from site settings manager. Using default value. Key: ‘EveryoneClaimEnabled’, Default: ‘True’
- Error in resolving user. User: ‘Michel’, ResolverInformation: ‘SPActiveDirectoryPrincipalResolver, DomainName: ‘tatooine.local’, DomainIsForest: ‘True’, DomainLoginName: ”, CustomSearchQuery: ”, CustomSearchFilter: ”, Timeout: ’00:00:30′, IncludeDistributionList: ‘True”, Exception: ‘System.Runtime.InteropServices.COMException (0x8007203A): The server is not operational. at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) at System.DirectoryServices.DirectoryEntry.Bind() at System.DirectoryServices.DirectoryEntry.get_AdsObject() at System.DirectoryServices.DirectorySearcher.FindAll(Boolean findMoreThanOne) at Microsoft.SharePoint.WebControls.PeopleEditor.SearchFromGC(SPActiveDirectoryDomain domain, String strFilter, String[] rgstrProp, Int32 nTimeout, Int32 nSizeLimit, SPUserCollection spUsers, ArrayList& rgResults) at Microsoft.SharePoint.Utilities.SPUserUtility.SearchAgainstAD(String input, Boolean useUpnInResolve, SPActiveDirectoryDomain domainController, SPPrincipalType scopes, SPUserCollection usersContainer, Int32 maxCount, String customQuery, String customFilter, TimeSpan searchTimeout, Boolean& reachMaxCount) at Microsoft.SharePoint.Utilities.SPActiveDirectoryPrincipalResolver.SearchPrincipals(String input, SPPrincipalType scopes, SPPrincipalSource sources, SPUserCollection usersContainer, Int32 maxCount, Boolean& reachMaxCount) at Microsoft.SharePoint.Utilities.SPUtility.SearchPrincipalFromResolvers(List1 resolvers, String input, SPPrincipalType scopes, SPPrincipalSource sources, SPUserCollection usersContainer, Int32 maxCount, Boolean& reachMaxCount, Dictionary2 usersDict)’, ExceptionStackTrace: ‘ at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) at System.DirectoryServices.DirectoryEntry.Bind() at System.DirectoryServices.DirectoryEntry.get_AdsObject() at System.DirectoryServices.DirectorySearcher.FindAll(Boolean findMoreThanOne) at Microsoft.SharePoint.WebControls.PeopleEditor.SearchFromGC(SPActiveDirectoryDomain dom… 0094b8a0-2951-e0fc-8428-cb70dfc9d300
Je vous passe les recherches infructueuses, les tests, le parcours de centaines de lignes de logs etc. Alors la solution à mon problème… C’est quoi ?
En fait, il m’a fallu modifier un paramètre dans la WebApplication, accessible en PowerShell pour aller implémenter un objet forçant la recherche sur l’annuaire (sa forêt en l’occurence), et qui finalement est relativement simple :
$wa = Get-SPWebApplication | ? { $_.displayname -eq "Intranet" }
$SearchAD = $wa.PeoplePickerSettings.SearchActiveDirectoryDomains
$domain = New-Object Microsoft.SharePoint.Administration.sppeoplepickersearchactivedirectorydomain
$domain.DomainName = "tatooine.local"
$domain.IsForest = $true
$SearchAD.Add($domain)
$wa.Update()
Et c’est tout, enfin pensez à faire un petit IISReset /noforce sur tous les frontaux Web.
NB : Pensez à vérifier :
- le nom du domain, on parle du haut de la forêt et le paramètre IsForest vous permettra de rechercher partout ($true = partout ; $false = sur le niveau supérieur seulement)
- Le nom de votre WebApp, j’ai mis Intranet ici, à vous d’adapter dans votre contexte
A bientôt !
Sources :
[SharePoint Online] – Modifier la Timezone sur une collection de sites
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.
[SPOnline] – Verrouiller un site en lecture seule
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) :
Puis accéder au menu “Site Policies” :
Et enfin créer une nouvelle Policy :
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 :
On revient dans les paramètre du site :
Et cette fois-ci on va dans le menu “Site Closure and Deletion” :
On choisit dans la liste déroulante notre nouvelle policy et on valide la page :
On revient de nouveau dans le même menu :
Et cette fois-ci on clique sur le bouton “Fermer le site maintenant” (Close this site now) :
Immédiatement, un bandeau rouge apparaît en haut de la page nous informant que le site est bien en ReadOnly :
En espérant que cela vous soit utile !
[SharePoint] – Script PowerShell pour afficher les tailles des bases de données
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 :
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 :
Puis on lance l’exécution du script (sauvegardé dans un fichier PS1) ou avec le bouton “Play” de PowerShell ISE :
Et voilà !
[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 !
[SP2010 – SP2013] – Modifier la période de rétention des corbeilles
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 :
Et pour changer le quota appliqué à la corbeille de niveau 2 (pour le fixer à 30% par exemple) :
$Webapp.SecondStageRecycleBinQuota = 30
$Webapp.Update()
Et voilà !
[SP2010 & SP2013] – Envoyer les résultats de l’analyseur de santé et d’intégrité par e-mail
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 :
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"
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")
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) :
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."
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
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 :
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 :
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) :
Aller dans l’onglet Triggers (déclencheur) et fournir une planification (schedule), dans mon cas chaque jour à 2h00 du matin :
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
Enregistrer le tout, l’assistant vous demande le mot de passe du compte utilisé pour lancer la tâche :
La tâche est créée :
Faites un clic droit, Démarrer pour tester :
Les résultats de l’exécution sont présentés dans la fenêtre en bas :
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”)
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
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
Nous allons commencer par renseigner quelques variables nécessaires :
- $siteurl = ” http://sp2010-dev:82/sites/florent” ==> 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
Puis on créé la Target Application :
$target = New-SPSecureStoreTargetApplication -Name $ta_name -FriendlyName $ta_friendlyName -ContactEmail $ta_contactEmail -ApplicationType Group
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
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
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
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
On peut verifier dans l’administration centrale, la Target Application est bien créée :
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…
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.
[SharePoint 2010 & 2013] – Migrer un service de Métadonnées Gérées de l’intégration à la production
Bonjour à tous.
Tout développeur, et même de manière générale, tout collaborateur intervenant sur un projet SharePoint s’est déjà frotté à des problématiques de migration. Ces migration peuvent être soit d’une version précédente vers la suivante (2007 vers 2010, 2010 vers 2013… ou même 2007 vers 2013). Mais on rencontre plus souvent le cas où l’on veut migrer des développements, des contenus, des services d’un environnement de qualification, d’intégration vers l’environnement de production.
Aujourd’hui un petit script PowerShell “sympa” pour migrer le contenu du service de métadonnées gérées (Managed Metadata Application Service) d’un environnement vers un autre.
1/ Exporter le contenu du service de Métadonnées gérées source
Première chose à faire, lancer le Management Shell de SharePoint sur le serveur source en s’étant au préalable loggé en administrateur de la ferme :
Puis nous allons entrer les commandes :
$managedMetadataGuid = “abcdefgh-ijkl-mnop-qrst-uvwxyzabcdef”
En remplaçant bien sur “abcdefgh-ijkl-mnop-qrst-uvwxyzabcdef” par le GUID de votre application de service de métadonnées gérées. Vous pourrez le trouver en vous connectant sur l’administration centrale de votre ferme, en allant dans la section “Gérer les applications de service”, et en cliquant sur votre application de service de métadonnées (attention il ne faut pas sélectionner la ligne mais bien cliquer sur le lien (le nom) du service).
Dans l’url, vous trouverez un paramètre appelé “tsid” : c’est avec cette valeur qu’on va remplacer la chaine précédente.
Puis dans notre Management Shell, nous allons entrer la commande :
$mmProxy = Get-SPServiceApplicationProxy | ?{$_.TypeName -eq “Managed Metadata Service Connection”}
Cette commande permet de récupérer une référence vers le proxy de l’application de métadonnées gérées (documentation Technet : http://technet.microsoft.com/fr-fr/library/ff607727.aspx).
Puis nous allons exporter le contenu du service dans un fichier :
Export-SPMetadataWebServicePartitionData -Identity $managedMetadataGuid -ServiceProxy $mmProxy -Path \\[SERVEUR]\MMexportfile.bak;
Cette commande permet d’export le contenu du service, donc l’intégralité du TermStore, des TermGroups, des TermSets et des Terms en conservant les GUID (références uniques) de chacun de ces éléments !
Les paramètres utilisés sont :
-
Identity : Guid unique de l’application de service récupéré précédemment
-
ServiceProxy : référence vers le proxy de cette application récupéré précédemment
-
Path : chemin de sortie pour le fichier généré. Dans la documentation Technet (http://technet.microsoft.com/fr-fr/library/ff607847.aspx), il est dit qu’on peut utiliser un chemin vers un disque local ou un chemin UNC. Pour ma part, le chemin sur un disque local n’a pas fonctionné, la commande PowerShell ne remonte aucune erreur mais le fichier n’est pas généré. J’ai donc choisi un chemin UNC.
Au préalable, j’ai donc créé un répertoire réseau partagé (à tout le monde, lecture/écriture) sur ce même serveur (mais on pourrait utiliser n’importe quel chemin UNC).
Le fichier est généré (17ko…). Maintenant vous pouvez soit conserver le fichier dans cet emplacement, soit le déplacer sur l’environnement de destination (target).
J’ai choisi de le conserver dans son emplacement initial.
2/ Importer le contenu du service source dans le service de destination
Il nous reste maintenant à restorer ce contenu sur le service de destination. Pour cela, on se connecte au serveur SharePoint de destination avec le compte administrateur de la ferme SharePoint. On lance le Management Shell SharePoint sur ce serveur, et on entre les commandes suivantes :
$managedMetadataGuid = “abcdefgh-ijkl-mnop-qrst-uvwxyzabcdef”
Même commande que précédemment (sur la source) en récupérant le GUID de l’application de service de métadonnées gérées (avec la même méthode que sur la source), on remplace le paramètre “abcdefgh-ijkl-mnop-qrst-uvwxyzabcdef”.
On récupère ensuite une référence sur le proxy du service de métadonnées gérées sur la ferme de destination (même méthode que sur la source) :
$mmProxy = Get-SPServiceApplicationProxy | ?{$_.TypeName -eq “Managed Metadata Service Connection”};
Puis on lance l’import :
Import-SPMetadataWebServicePartitionData -Identity $managedMetadataGuid -ServiceProxy $mmProxy -Path “\\[SERVEUR]\MMexportfile.bak” -OverwriteExisting;
Cette commande permet l’import des données à partir du fichier source, vous trouverez la documentation ici : http://technet.microsoft.com/fr-fr/library/ff607667.aspx.
Les paramètres utilisés sont :
-
Identity : Guid unique de l’application de service récupéré précédemment
-
ServiceProxy : référence vers le proxy de cette application récupéré précédemment
-
Path : chemin du fichier généré. J’utilise aussi ici un chemin UNC vers le répertoire réseau partagé lors de l’export (pour m’éviter la copie du fichier…).
-
OverwriteExisting : pour écraser les données éventuellement présentes sur l’application de service de destination.
Il ne vous reste plus qu’à vous connecter sur l’application de service de destination, via l’administration centrale de SharePöint, et vérifier que la procédure ait bien été exécutée et que les données sont bien importées.
NB : il peut arriver que vous ayez une erreur de type : Cannot bulk load because the file “\\[SERVEUR]\MMexportfile.bak” could not be opened.
Pour résoudre cette erreur, il vous suffiera de déplacer le fichier d’export sur le serveur SQL Server utilisé par votre ferme SharePoint, de partager le répertoire qui le contient (partage réseau, pour tout le monde en lecture / écriture) et de retenter l’opération d’import en indiquant ce chemin. N’oubliez pas ensuite de retirer ce partage réseau !!!
Si cela ne résoud pas le problème, vous pouvez essayer de donner les droits en bulkadmin sur votre serveur SQL Server pour le compte de service de l’application de service de Métadonnées gérées. N’oubliez pas ensuite de retirer ce droit !!! (attention également, on ne donne pas les droits au compte administrateur de la ferme mais bien au compte de service de l’application).
Bonne migration !
[eBooks] – Collection d’ebooks gratuits
Bonjour à tous.
Aujourd’hui, pas d’article technique mais une collection d’ebooks gratuits à télécharger (en anglais) de tous types :
- Office & Office 365
- SharePoint
- SQL Server
- System Center
- Visual Studio
- Web development
- Windows
- Windows Azure
Et en plusieurs formats pour la plupart : PDF, EPUB, MOBI. On ne va pas se priver !
Bonne lecture !
Florent Cazenave 