SharePoint 2010

[SharePoint 2016] – Quelques nouveautés annoncées à l’Ignite

Posted on Updated on

Bonjour,

Il y a quelques jours se déroulait la conférence Ignite à Chicago au cours de laquelle on apprenait l’arrivée de quelques nouveautés sur la prochaine mouture de SharePoint : SharePoint 2016 !

A priori pas de renommage de produit comme on avait pu le connaitre entre 2007 et 2010, Microsoft reste sur SharePoint Foundation et SharePoint Server.

On apprend aussi, même si cela paraissait évident, que Microsoft s’appuie sur le développement de la version Online / Office 365 pour guider les développements de la version OnPremise. Bien sûr la version Online conservera de l’avance et un lot de fonctionnalités que ne seront à priori pas proposées dans la version OnPremise.

Concernant les dates de sorties, Microsoft tablerait pour une sortie en Public Release pour Q4 2015 et une sortie officielle pour Q2 2016 avec une Release Candidate entre les deux. Donc pas tout de suite malheureusement.

Concernant les nouveautés, Microsoft frappe fort au niveau des limitations connues avec SharePoint 2010 et 2013 :

  • Taille des bases de données de contenu : supérieures à 1To
  • Nombre de collections de sites par base de contenu : 100 000
  • Seuil des listes : supérieur à 5000
  • Taille max par fichier : 10Go
  • Suppression des limitations sur les restrictions de caractères spéciaux
  • Elements indexés : 500 millions

Il est certain que d’autres limitations vont être revues à la hausse ! 🙂

Microsoft annonce aussi un Zero downtime lors les opérations de patch des fermes SharePoint, le but étant bien sûr d’éviter toute coupure de service durant ces opérations.

Toujours dans l’infra, Microsoft revoit sa copie pour la mise en œuvre d’environnements hybrides et pousse dans cette direction (par le passé, les scénarios hybrides étaient principalement évoqués pour des phases transitoires de migration). On peut donc s’attendre à un ensemble d’outils/wizard/scripts permettant d’accélérer le déploiement et la configuration des composants.

Et encore pour l’infra… la possibilité de mieux cibler les rôles de chaque serveur dans la ferme, avec sans doute à la clé une optimisation de l’adhérence des fichiers d’installation (réduction de l’empreinte disque, utilisation optimisée des ressources) :

  • Special load : applications tierces, application/service devant être isolé
  • Web Front End : serveur frontaux Web pour la navigation des utilisateurs optimisés pour réduire le temps de latence
  • Application : serveurs d’application (Applications de services SharePoint)
  • Search : serveurs Crawl, index etc. spécialisés pour le service de recherche de SharePoint 2016
  • Distributed Cache : cache distribué pour “load balancer” les requêtes entre les WFE et optimisation/cache de la navigation des utilisateurs

La configuration Single Server Farm est toujours d’actualité (Sandbox), mais j’ai entendu dire que SQL Server Express ne serait plus de la partie… il faudra donc installer SQL Server indépendamment de SharePoint.

Les versions d’OS supportés devraient être Windows Server 2012R2 et Windows Server 10 et du coté base de données, probablement SQL Server 2014 (peut être également SQL Server 2012 avec Service Pack dans sa dernière release).

Pour les méthodes de migrations, elles devraient rester les mêmes : attach/detach ou inPlace, avec l’obligation de passer par SP2013 pour ceux qui viendraient de SP2010 (et oui… toujours).

Dans les nouvelles fonctionnalités, Microsoft propose les Durable Links qui permettrait d’avoir une URL unique pour un document (associé à un ResourceID) avec un redirecteur permettant de retrouver le fichier (un peu à la manière des DocumentID de SharePoint 2010 & 2013). Ce qui permet de renommer, déplacer le fichier sans que son url ne soit modifiée.

Dans la partie Compliance, le DLP (Data Loss Prevention) qui permettra de protéger les données sensibles, et respecter les politiques d’entreprises, l’encryption etc. Un mix entre les audits, AzureRMS, eDiscovery ? à suivre.

Coté services, et plus particulièrement User Profile, FIM (ForeFront Identity Manager) déployé par le service disparaîtrait mais pourrait être couplé à un FIM installé séparément.

Coté recherche, on parle d’un mix entre FAST de SharePoint 2013 et Office Graph (en hybride donc, onPremise indexes et Cloud indexes).

Plus d’infos sur la roadmap de SharePoint 2016 : http://blogs.office.com/2015/04/16/sharepoint-server-2016-update/.

Bien sûr, des infos ont été révélées à l’Ignite, d’autres sont mes suppositions (mes espoirs !). Pour vérifier tout cela, rendez-vous au Q2 2016… VIVEMENT !

Advertisements

[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à !

[SP2010 – SP2013] – Stocker des données de configuration

Posted on Updated on

Bonjour à tous,

Lorsque nous développons des applications pour SharePoint, il nous arrive bien souvent de vouloir sauvegarder des données de configuration. Ces données peuvent être de simples valeurs (texte, nombre, heure, timestamp, URL, etc.) mais également des données plus complexes comme des objets métiers.

SharePoint 2010 et 2013 (et 2007) nous offrent un certain nombre de possibilités, plus ou moins adaptées suivant les cas. Je vais essayer d’être exhaustif, mais il y en a certainement d’autres !

1/ Liste de configuration

La première solution est de stocker les paramètres de configuration dans une liste de configuration, hébergée sur un site web SharePoint et même sur la console d’Administration centrale de SharePoint.

Pour cela, l’idée et de créer une définition de liste avec Visual Studio qui comprend principalement 2 colonnes :

  • Une colonne Key (clé) : permettant d’identifier uniquement le paramètre, afin de le retrouver plus facilement via une requête CAML par exemple. Sa configuration pourrait être : type Texte, obligatoire
  • Une colonne Value (valeur) : permettant de stocker la valeur au format texte. Sa configuration pourrait être : type Texte (ou texte multiligne), obligatoire
  • Des colonnes supplémentaires comme une description du paramètre, une langue, etc. peuvent être également de la partie.

L’avantage de créer une définition de liste mais également directement une instance (déployées et créées par une Feature, à la racine de la collection de site généralement) et que l’on connait l’identifiant unique du modèle (souvent 10000, 10001, …) que nous fixons nous-même ainsi que l’URL de l’instance créée. Il nous sera donc plus facile de retrouver cette instance par code.

Nous pourrons aussi déployer des données via la création de l’instance via les Rows proposées dans la déclaration de l’instance.

Un autre avantage est de proposer une interface graphique, via le navigateur pour éditer les données… l’’’interface standard de SharePoint !

Et bien sûr, la sécurité et la gestion des droits seront de la partie pour gérer plus finement ces ensembles de clés/valeurs stockées dans la liste.

On peut également penser à développer une classe de service permettant d’accéder à cette instance de liste, récupérer une valeur, ajouter, supprimer, mettre à jour.

Un inconvénient reste l’accès à cette instance de liste depuis un autre site où il faudra recourir à de l’impersonation, des accès Cross-Site et surtout entre WebApplication etc.

Mais également qu’on ne pourra stocker que des types simples ou bien il faudra sérialiser / désérialiser des objets pour les stocker.

Donc pour résumer :

  • Une solution Visual Studio
  • Une définition de liste
  • Une instance de liste
  • Une colonne clé unique
  • Une colonne valeur
  • Des colonnes supplémentaires
  • Des données poussées lors du déploiement
  • Une classe de service pour les accès par code

Voici un extrait d’une classe de service permettant de récupérer l’instance de la liste en question, il vous restera à développer le Get / Update / Add / Delete :

public class ListHelper
{
public static SPList GetParamsList(SPWeb web)
{
SPList resultList = null;
if (web != null)
{
try
{
SPSecurity.RunWithElevatedPrivileges(() =>
{
using (SPSite currentSite = new SPSite(web.Site.ID))
{
using (SPWeb currentWeb = currentSite.OpenWeb(currentSite.RootWeb.ID))
{
SPList list = currentWeb.GetList(ListConstants.ListUrl);

if (list != null)
resultList = list;
}
}
});
return resultList;
}
catch (Exception ex)
{
throw new SPException(“An error has occured. Please contact your administrator : ” + ex.Message);
}
}
else
return null;
}
}

NB : ListConstants est une classe qui contient des paramètres de configuration de ma solution Visual Studio.

2/ Property Bags

Cette seconde solution est également souvent envisagée par les développeurs. Elle permet de stocker des paramètres à plusieurs niveaux :

  • Farm (SPFarm)
  • Web Application (SPWebApplication)
  • Site Collection (SPSite)
  • Site web (SPWeb)
  • Liste (SPList)

Pour faire simple, le property bag est une Hashtable (clé/valeur), sans paramètre supplémentaire, où l’on pourra stocker des types simples sous forme de texte (ou bien en sérialisant / désérialisant les objets).

Les données sont stockées soit dans la base de données de configuration soit dans la base de données de contenu (suivant objet).

Par contre, SharePoint ne propose aucun accès graphique à ces données (pour l’édition par exemple). Toutefois on peut penser au projet SharePoint Property Bag Settings 2010 disponible sur Codeplex : http://pbs2010.codeplex.com/.

Ici également, il faut penser à l’accessibilité des données à partir d’un autre site, d’une autre WebApplication et donc utiliser de l’impersonation, une classe de service pour accéder aux données.

Voici comment mettre à jour une propriété dans le property bag d’un objet SPWeb :

if(web.Properties[“Key”] == null)
{
web.Properties.Add(“Key”, “Value”);
web.Properties.Update();
}

string storedValue = web.Properties[“Key”];
web.Properties[“Key”] = “NewValue”;
web.Properties.Update();

3/ Session / cookie

La troisième solution est de recourir au stockage de données dans la session de l’utilisateur ou dans un cookie ou dans le Viewstate.

Ici, les objets ne sont donc pas stockés dans SharePoint mais bien dans des objets spécifiques à chaque utilisateur et ne pourront pas être partagés entre-eux. Il faudra donc charger les données, les mettre à jour pour chaque utilisateur.

Cela ne correspond donc pas exactement aux cas fonctionnels précédents, mais il est bon de le citer car c’est parfois bien pratique de stocker des données temporaires et qui peuvent permettre d’accélerer le chargement des pages.

Pour le cas de la session, il vous faudra penser à activer la session ASP.Net sur les serveurs IIS hébergeant SharePoint (http://technet.microsoft.com/fr-fr/library/ff607857(v=office.15).aspx).

La session permet de stocker des type simples sous forme de string et nous devrons sérialiser/désérialiser les objets.

Pour stocker une valeur dans la session de l’utilisateur, on peut utiliser le script suivant :

if(HttpContext.Current.Session[“MyKEY”] == null)
{
HttpContext.Current.Session.add (“MyKEY”, “MyVALUE”);
}

4/ Fichiers de configuration

Quatrième option, utiliser le fichier de configuration de la WebApplication : web.config pour stocker des paramètres, ici aussi de type texte. Pour cela, Microsoft fournit une API permettant d”insérer des clés, de le lire, supprimer. En général, on stocke ces paramètres dans la section AppSettings du fichier, ou en créant une section spécifique (qu’il faudra également penser à créer).

Le simple fait de déployer des paramètres à cet emplacement redémarrera le pool IIS afin qu’ils soient pris en compte. Ce redémarrage se fera automatiquement grâce à un Handler positionné par IIS sur le fichier web.config et donc aucune action du développeur ne sera demandée. Attention que cela ne pose pas de problème aux utilisateurs (indisponibilité de quelques secondes / minutes, le temps du redémarrage).

Quelques bugs ont été constatés lors de l’utilisation de cette méthode. Je vous invite à faire une petite recherche à ce sujet.

Généralement, le développeur déploie ces modifications lors de l’activation d’une Feature :

public override void FeatureActivated(SPFeatureReceiverProperties properties) {

SPWebApplication webApp = properties.Feature.Parent as SPWebApplication;

SPWebConfigModification myModification = new SPWebConfigModification();

myModification.Path = “configuration/appSettings”;    myModification.Name = “add [@key=’mySetting’] [@value=’myValue’]”;

myModification.Sequence = 0;

myModification.Owner = “DOMAIN\OWNERLOGIN”;

myModification.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;

myModification.Value = “”;    webApp.WebConfigModifications.Add(myModification);

webApp.Update();

webApp.Farm.Services.GetValue().ApplyWebConfigModifications();

}

Il faut bien sur penser à nettoyer lors de la désactivation de la Feature !

 

5/ Objets persistés : SPPersistedObject

Cette cinquième méthode, de mémoire, est arrivée avec SharePoint 2010. Elle permet de stocker des objets complexes, de manière hiérarchique, dans une source de données globale à la plateforme, et peut donc être partagée entre les utilisateurs. Ces objets seront stockés dans la base de données de configuration de la plateforme SharePoint (base de donnée SharePoint_Config).

C’est donc une méthode évoluée en regard des précédentes ! Quelques contraintes sont toutefois à remarquer. En effet, les objets stockés doivent hériter de la classe SPPersistedObject, une annotation (GUID) doit être précisée sur la classe (identifiant unique de l’objet), un constructeur par défaut et un constructeur avec deux paramètres (string => nom de l’objet, SPPersistedObject => l’objet en lui-même). et enfin vos propriétés personalisées. Rien d’insurmontable donc !

Quelques avertissement cependant : le hierarchical store n’est accessible qu’au Farm Account de la ferme SharePoint, et donc pas à tous les utilisateurs. Pensez donc à utiliser l’impersonation pour accéder aux données !

NB : les timerjobs SharePoint sont exécutés avec ce Farm Account, c’est donc un moyen pratique de stocker les données de configuration pour ces TimerJobs !

[Guid(“4DB9AF54-1339-424A-BE2D-648940610283”)]
public class MyPersistedClass : SPPersistedObject
{
public MyPersistedClass()
{
}
public MyPersistedClass(string name, SPPersistedObject parent) : base(name, parent)
{
}
[Persisted]
string Value1;
[Persisted]
string Value2;
[Persisted]
int Value3;
}

Et pour accéder aux données :

SPFarm farm = SPFarm.Local;
PersistedClass rootClass = new PersistedClass(“MyFirstItem”, farm);
rootClass.Value1 = “BLA BLA BLA”;
rootClass.Value2 = “PLOP PLOP PLOP”;
rootClass.Value3 = 8;
rootClass.Update(); PersistedClass childClass = new PersistedClass(“MyFirstItemChild”, rootClass);
childClass.Value1 = “YOUPI”;
childClass.Update(); SPFarm farm = SPFarm.Local;
PersistedClass retrievedValue = farm.GetChild(“MyFirstItem”);

 

6/ Cache Distribué (SP2013)

Dans cette sixième méthode, nous allons aborder une nouveauté de SharePoint 2013 : le Cache Distribué (Distributed Cache) qui peut être une bonne alternative pour le stockage d’objets complexes.

En effet ce dernier propose de maintenir en cache des données / objets sur une durée fixée et paramétrable lors de l’ajout des données dans ce cache et de partager ces données entre les différents serveurs de la ferme SharePoint, entre les utilisateurs.

Pour utiliser ce cache, je suis tombé sur une classe toute prête (et testée dans un projet) qui vous permet d’ajouter, lire, supprimer et modifier les données stockées. Vous la trouverez ici : https://github.com/Almond-Labs/SP2013-Starter/blob/master/Source/AL.Sharepoint.Core/Cache/CacheManager.cs

Il vous suffira de recréer cette classe dans votre projet Visual Studio, de référencer les assemblies nécessaires (recherchez les dans le répertoire 15) et de compiler. Ca fait gagner du temps…

Avantage également de cette source, l’auteur fournit des méthodes génériques pour stocker des objets… et donc nous pourrons stocker des objets complexes dans le cache, sans les sérialiser.

A noter dans la méthode Put qu’un TimerSpan est passé en paramètre. Il permet de fixer la durée de conservation des données dans le cache distribué :

public static void Put<T>(string key, T value, TimeSpan timeSpan)

Par exemple, nous appelerons la méthode Put qui permettra de stocker l’objet MyObjectInstance de type MyObject pendant 1h30. :

CacheManager.Put<MyObject> (“MyKEY”, MyObjectInstance, 1,30,0);

Cette méthode a donc l’avantage de stocker directement des objets durant une période fixée, partageable entre les utilisateurs.

 

7/ Application de Service

Cette dernière méthode est un peu bourrine plus complexe. Elle demande le développement d’une application de service (Service Application) pour SharePoint, proposant un magasin de données centralisé à toute la ferme SharePoint. (et même entre fermes avec du multi-tenant).

Pour cela, je vous conseille de vous tourner vers Technet : http://msdn.microsoft.com/en-us/library/gg193964(v=office.14).aspx ou encore http://msdn.microsoft.com/fr-fr/library/gg543112(v=office.14).aspx.

Ce n’est pas chose aisée, mais dans certains cas cela peut répondre à votre besoin. Par exemple nous pourrions imaginer que nous souhaitons stocker un catalogue important de données de configuration, spécifiques à chaque utilisateur.

Nous utiliserons pour cela une base de données spécifique déployée par l’application de  services, des WebServices afin d’accéder aux données depuis chacun de sites, WebParts, composants personnalisés ou même des applications SharePoint (Apps). Sans oublier la possibilité de requêter ce service depuis une application métier, sur des terminaux mobiles, etc.

[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.