SharePoint Foundation 2010

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

Advertisements

[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 2013] – Configurer SSL pour SharePoint 2013

Posted on Updated on

 

Bonjour à tous.

Aujourd’hui un article pour vous montrer comment configurer SSL pour utiliser SharePoint 2013 avec des url https et sécuriser l’accès à vos contenus.

Je précise que dans mon cas, je vais utiliser un certificat de type “Self Signed” et donc à utiliser exclusivement pour des plateformes de développement. Pour les environnements de production, il faudra utiliser un certificat “commercial” acquis par exemple auprès de Verisign ou un autre organisme.

Dans ma configuration, j’ai un serveur d’annuaire (Windows Server 2008 avec le Rôle Active Directory) et mon serveur SharePoint (Windows Server 2008R2 SP1, SQL Server 2012 et SharePoint Server 2013 Enterprise).

Voici comment faire pour configurer les différents éléments :

 

1/ Créer un certificat Self Signed & l’exporter

 

Pour cela, nous allons utiliser une fonctionnalité de IIS (7 dans mon cas) permettant de générer des certificats auto-signés.

Nous allons commencer par lancer la console d’administration de IIS (sur le serveur SharePoint), soit en explorant le menu démarrer, soit en exécutant la commande “inetmgr”. Pennons le second cas : cliquer sur “Démarrer > Exécuter > inetmgr” :

image

Puis nous allons cliquer sur le nœud dans l’arborescence portant le nom du serveur SharePoint (SP2013-DEV dans mon cas), et enfin double-cliquer sur l’icône “Server Certificates” dans la zone centrale :

image

 

Sur cet écran, nous allons cliquer sur “Create Self-Signed Certificate…” :

image

 

Dans l’écran suivant, nous allons donner un nom à notre certificat, ici “SharePointCertificate” et cliquer sur OK :

image

Le certificat est maintenant créé. Nous allons maintenant l’exporter dans un fichier. Pour cela, on double-clique sur le nouveau certificat dans la zone centrale :

image

 

Nous allons cliquer sur l’onglet “Details” :

image

 

Et cliquer sur le bouton “Copy To File…” en bas :

image

L’écran d’accueil apparait. On clique sur “Next” :

image

 

Dans l’écran suivant, on conserve le paramètre “No, do not export the private key” et on clique sur “Next” :

image

Ici encore on conserve le paramètre par défaut “DER encoded binary X.509 (.CER)” et on clique sur “Next” :

image

Nous allons ensuite indiquer le chemin où sauvegarder le fichier généré. Dans mon cas je le place sur le Bureau, dans un répertoire nommé “SharePoint Certificate” et le fichier sera nommé “SharePointCertificate.cer”. On clique sur “Next” :

image

 

L’assistant nous affiche le récapitulatif. On clique sur “Finish” :

image

 

L’export est terminé :

image

 

2/ Importer le certificat dans le magasin

 

L’étape suivante consiste à importer le certificat tout juste exporté dans le magasin de certificats du serveur SharePoint.

Pour cela, nous allons lancer une nouvelle console pour les Snap-ins de Windows Server 2008R2 : “Démarrer > Exécuter”. Taper “mmc” et cliquer sur “OK” :

image

La console se lance. Dans “File”, sélectionner “Add/Remove Snap-in…” :

image

Dans la fenêtre apparaissant, sélectionner “Certificates”, et cliquer sur “Add >” :

image

Une fenêtre se lance, sélectionnez “Computer Account” et cliquer sur “Next” :

image

 

Dans l’écran suivant, conserver les paramètres et cliquer sur “Finish” :

image

 

Le Snap-in est bien ajouté, on clique sur “OK” :

image

 

On navigue ensuite dans l’arborescence : Certificates > SharePoint > Certificates :

image

On sélectionne le nœud “Certificates”, clic-droit > All Tasks > Import… :

image

L’assistant se lance, on clique sur “Next” :

image

 

On sélectionne le certificat exporté à l’étape précédente et on clique sur “Next” :

image

 

On conserve les paramètres (vérifier que l’on ait bien “SharePoint” dans le champ “Certificate Store”), “Next” :

image

 

On termine l’import “Finish” :

image

image

On peut maintenant fermer cette console.

 

 

3/ Ajouter le certificat dans l’administration centrale de SharePoint

 

NB : Dans le cas d’un serveur unique, cette étape n’est pas requise.

Nous allons maintenant charger le certificat dans la console d’administration centrale de SharePoint. SharePoint va principalement utiliser ce certificat afin de crypter et signer les échanges entre les serveurs de la ferme (sinon vous aurez des erreurs dans les logs SharePoint).

 

On lance donc le site dans le navigateur et on se rend sur la page : “Security > Manage Trust” :

image

 

Dans la page suivante, on retrouve le certificat utilisé nativement par SharePoint, nous allons ajouter notre certificat en cliquant sur “New” dans le ruban :

image

 

Nous allons ici renseigner le nom (dans mon cas j’ai choisi “SharePointCertificate”) et parcourir le disque local pour retrouver le certificat exporté dans la première étape :

image

On valide le formulaire et le certificat est ajouté :

image

Vous pouvez également automatiser cette configuration avec PowerShell (Management Shell pour SharePoint) :

  • $certificate = new-object system.security.cryptography.x509certificates.x509certificate2(“C:\\User\………\SharePointCertificate.cer”)
  • New-SPtrustedrootauthority –name “SharePointCertificate” –certificate $certificate

 

Etape suivante, configurer les bindings dans IIS

 

4/ Configurer les bindings dans IIS 7

 

Nous allons maintenant indiquer à IIS qu’il doit utiliser un binding https sur l’application Web SharePoint. J’ai bien sûr créé au préalable une Application Web sur le port 80 et une collection de sites.

Nous reprenons donc la console d’administration IIS (inetmgr) et on se rend sur l’application Web du port 80, et on clique sur “Bindings” dans la zone de droite :

image

La fenêtre des Bindings apparait, on clique sur “Add…” :

image

 

Nous allons ajouter un binding en https sur le port 443 (par défaut) et utilisant notre certificat. On clique sur “OK” :

image

Le nouveau binding est ajouté :

image

On ferme la fenêtre avec le bouton “Close”.

 

Dernière étape, configurer les Alternate Access Mapping (Mappage d’Accès de Substitution) dans l’administration centrale de SharePoint.

 

 

5/ Configurer les Alternate Access Mappings

 

Pour configurer ces AAM, on se rend dans la console d’administration centrale de SharePoint, sur la page d’accueil sur “Configure Alternate Access Mapping” :

image

La liste des AAM apparait. On utilise le contrôle permettant de sélectionner une Web Application sur la droite et on choisit celle sur le port 80 :

image

image

On clique ensuite sur “Add Internal Urls” et on ajoute notre url en https, sur la zone default (dans mon cas https://sp2013-dev) et on valide :

image

image

NB : Les deux urls : http et https cohabitent sur la même zone, cela nous permettra d’accéder en http au contenu depuis le réseau local (LAN) et en https depuis l’extérieur (WAN) moyennant d’avoir configurer le reverse proxy (ForeFront Threat Management Gateway, ISA, F5, etc.)… mais ça c’est une autre histoire !

Si vous n’avez qu’un mode d’accès souhaité (https pour tout le monde, vous pouvez ajouter l’url en https dans les Public Urls, sur la zone Extranet par exemple.

 

 

6/ Tests !

 

Nous allons maintenant tester notre configuration. Pour cela, j’utilise un navigateur en entrant l’adresse en https de ma collection de site : https://sp2013-dev :

image

Non ce n’est pas une erreur ! En effet, nous utilisons un certificat Self-Signed, et le navigateur ne fait pas l’approbation par défaut. On clique sur “Continue to this website…” dans le centre de la page :

image

Voila ça fonctionne !

[Visual Studio & SharePoint]–Paramètres remplaçables

Posted on Updated on

Bonjour à tous.

Si vous développez des projets SharePoint 2010 ou 2013 avec Visual Studio 2010 ou 2012, vous devez connaitre les paramètres remplaçable. En effet, Visual Studio vous permet d’utiliser des sortes de “Pragmas” remplacés à la compilation par Visual Studio lui-même.

Vous reconnaitrez ces paramètres remplaçables rapidement car ils sont entourés par des “$”, du type : $SharePoint.Project.FileName$

Vous retrouverez ces paramètres par exemple dans les pages d’application (Applications Pages), dans l’entête de chacune des pages :

<%@ Assembly Name=”$SharePoint.Project.AssemblyFullName$” %>

Lorsque on lancera la compilation du projet dans Visual Studio, ces paramètres seront remplacés par :

<%@ Assembly Name=”MonProjet.SharePoint, Version=X.X.X.X, Culture=neutral, PublicKeyToken=XXXXXXXXXXXX” %>

Voici le tableau des paramètres remplaçables que vous pourrez utiliser :

Nom du paramètre Description
$SharePoint.Package.Name$ Nom du package
$SharePoint.Package.FileName$ Nom du fichier de définition du package
$SharePoint.Package.FileNameWithoutExtension$ Nom sans extension du fichier de définition du package
$SharePoint.Package.Id$ ID unique SharePoint du package
$SharePoint.Feature.FileName$ Nom du fichier de définition d’une fonctionnalité
$SharePoint.Feature.FileNameWithoutExtension$ Nom du fichier de définition d’une fonctionnalité sans l’extension du nom de fichier
$SharePoint.Feature.Id$ ID unique SharePoint de la fonctionnalité
$SharePoint.Feature.DeploymentPath$ Nom du dossier de la fonctionnalité dans le package
$SharePoint.Project.FileName$ Nom du projet
$SharePoint.Project.FileNameWithoutExtension$ Nom du projet sans l’extension
$SharePoint.Project.AssemblyFullName$ Nom complet de l’assembly du projet
$SharePoint.Project.AssemblyFileName$ Nom de l’assembly du projet
$SharePoint.Project.AssemblyFileNameWithoutExtension$ Nom de l’assembly du projet sans l’extension
$SharePoint.Project.AssemblyPublicKeyToken$ PublicKeyToken de l’assembly
$SharePoint.ProjectItem.Name$ Nom de l’élément de projet
$SharePoint.Type.[GUID].AssemblyQualifiedName$ Nom qualifié de l’assembly
$SharePoint.Type.[GUID].FullName$ Nom complet de l’assembly

Microsoft précise également que l’on peut utiliser ces paramètres remplaçables dans les fichiers de type :

  • XML
  • ASPX
  • ASCX
  • WebPart
  • DWP

Il est possible d’étendre ces possibilités en modifiant le fichier : Microsoft.VisualStudio.SharePoint.targets qui se trouve dans : …\<program files>\MSBuild\Microsoft\VisualStudio\v10.0\SharePointTools

01

On l’édite avec NotePad par exemple :

02

On ajoute des extensions de fichier supportées si besoin. Par contre, si on change de machine, on prendra cette configuration !!! Donc attention, ces paramètres ne seront plus remplacés.

En résumé, ces paramètres sont vraiment très pratiques, et on les utilise très souvent (Visual Studio en utilise lui aussi fréquemment lorsque l’on créé une page d’application par exemple).

Pensez-y !