Development .Net

[SP2013] – Accéder aux données du Secure Store Service en C#

Posted on Updated on

Bonjour à tous,

Aujourd’hui un article technique pour vous montrer comment accéder aux données stockées dans le Secure Store Service de SharePoint Server 2013.

A quoi sert ce service ? Il suffit de suivre le lien : https://technet.microsoft.com/fr-fr/library/Ee806866.aspx

1/ Contexte général

Le but étant de stocker des données de type login, mot de passe, domaine, Pin, etc. afin d’accéder à des systèmes externe à SharePoint.

Habituellement, on utilise le Secure Store Service (SSS) de SharePoint pour enregistrer les credentials utilisés pour la mise en œuvre de listes externes dans SharePoint par le biais du Business Connectivity Service (BCS, ex-BDC). imaginons le cas où l’on souhaite afficher dans SharePoint une base de clients/fournisseurs qui provient d’une base de données SQL Server. Cette base peut utiliser un mode d’authentification SQL (et non Annuaire AD) et il faut donc envoyer un login/mot de passe pour pouvoir se connecter et requêter la base depuis SharePoint. C’est donc un SSO (Single Sign-On) mais Inter-Domaine (Cross-Domain) que nous propose Microsoft. Les données de cette base d’identifiants sont chiffrées via une clé générée par SharePoint lui-même (à partir d’une phrase secrète qu’il ne faut pas perdre !).

Dans le cas présent, le but est d’accéder à ce Secure Store Service afin de stocker, lire, mettre à jour les données d’un utilisateur, et proposer par exemple un formulaire de connexion, de mise à jour de ces données directement depuis un portail SharePoint.

2/ Architecture du service

Le Secure Store Service est une Application de Service proposée par SharePoint Server 2013 (Standard ou Enterprise). Elle peut se déployer par la console d’administration centrale ou PowerShell (voir l’article Technet précédent).

La clé de chiffrement permet de chiffrer les données stockées dans la base de données associée à l’application de service.

Les données sont stockées dans des Target Applications (Applications cibles). Chaque Target application stocke les données pour 1 application, par exemple :

  • Une Target Application pour la connexion à une base SQL Server
  • Une Target Application pour la connexion à une ferme Dynamics CRM
  • Une Target Application pour la connexion à SAP
  • Une Target Application pour la connexion à une base Oracle

Chacune de ces Target Application est définie par l’administrateur SharePoint où il doit fournir :

  1. ID de l’application cible : identifiant unique de la Target Application
  2. Nom complet : nom d’affichage de la Target Application
  3. Messagerie de contact : adresse e-mail de contact pour l’administrateur de cette Target Application
  4. Url de la page d’application cible : voir article Technet
  5. Type d’application cible : il s’agit ici d’indiquer si chaque utilisateur aura sa propre identification ou si l’on va définir une identification pour tout un groupe de personnes (individual ou group).

Ensuite vous devrez spécifier les champs que vous souhaitez enregistrer : champs d’identification Windows, champs d’identification standards (login/mot de passe), code Pin, domaine, etc.

Et enfin les administrateurs de la Target Application. Bref, tout cela est plutôt bien défini dans l’article Technet.

3/ Lire des credentials depuis mon code en C#

Voici enfin le cœur du problème. Comment accéder aux données stockées dans le SSS depuis mon code ?

J’ai tout d’abord défini une classe métier pour stocker quelques informations : Login, password, Login SharePoint, Nom Complet et E-mail de l’utilisateur :


namespace MonDev.LogMe.Utils
{
   public class SSSCredentials
   {
      public string Login { get; set; }
      public string Password { get; set; }
      public string SPLogin { get; set; }
      public string SPFullName { get; set; }
      public string SPEmail { get; set; }
   }
}

Ensuite, voici le code de la méthode GetCredentials que j’utilise. Les paramètres attendus sont :

  • site : collection de sites courante
  • applicationID : identifiant (interne) de la Target Application

   /// Get credentials for current connected user from Secure Store Service.
   /// current site collection, associated to a Secure Store Service at Web Application Level
   /// Target Application ID in Secure Store Service
   /// Returns Credentials if found, null otherwise.
   public static SSSCredentials GetCredentials(SPSite site, string applicationID)
   {
      //Initialize new Credentials structure
      SSSCredentials credentials = new SSSCredentials();
      credentials.SPEmail = site.RootWeb.CurrentUser.Email;
      credentials.SPFullName = !string.IsNullOrEmpty(site.RootWeb.CurrentUser.Name) ? site.RootWeb.CurrentUser.Name : site.RootWeb.CurrentUser.LoginName;
      credentials.SPLogin = site.RootWeb.CurrentUser.LoginName;

      //new SPSite is not mandatory, but it seems to be more efficient than use SPSite from parameters.
      using (SPSite currentSite = new SPSite(site.ID))
      {
         //Initialize a new SecureProvider to access to data into SSS
         ISecureStoreProvider provider = SecureStoreProviderFactory.Create();
         if (provider == null)
            throw new InvalidOperationException("Unable to get an ISecureStoreProvider");

         ISecureStoreServiceContext providerContext = provider as ISecureStoreServiceContext;
         providerContext.Context = SPServiceContext.GetContext(currentSite);

         try
         {
            using (SecureStoreCredentialCollection creds = provider.GetCredentials(applicationID))
            {
               if (creds != null)
               {
                  foreach (SecureStoreCredential cred in creds)
                  {
                     if (cred == null)
                        continue;

                     switch (cred.CredentialType)
                     {
                        case SecureStoreCredentialType.UserName:
                           credentials.Login = GetStringFromSecureString(cred.Credential);
                           break;
                        case SecureStoreCredentialType.Password:
                           credentials.Password = GetStringFromSecureString(cred.Credential);
                           break;
                        default:
                           break;
                     }
                  }
               }
            }
         }
         catch (SecureStoreException)
         {
            //No credentials are found into SSS, so return null
            return null;
         }
         catch (Exception e)
         {
            throw new Exception("A general error occured. Please contact your administrator. Error : " + e.Message);
         }
      }
      return credentials;
   }

La méthode doit être appelée comme suit :


private const string TargetApplicationID = "MaTargetApplication";
SSSCredentials credentials = SSSUtils.GetCredentials(SPContext.Current.Site, TargetApplicationID);

Rien de très compliqué toutefois je suis tombé sur quelques exemples de codes et aucun n’a fonctionné chez moi. A noter ici, pas besoin d’impersonation ou de SPSecurity.RunWithElevatedPrivileges(), bien au contraire. Il faut se connecter au provider avec les identifiants de l’utilisateur connecté au portail pour pouvoir récupérer ses identifiants !

 

4/ Ecrire dans le Secure Store Service

Si nous avons lu, il faut bien parvenir à écrire dans le SSS. Ici la méthode est la même pour l’ajout ou la modification de credentials dans le magasin du Secure Store Service. Les paramètres attendus sont :

  • site : collection de sites courante
  • applicationID : identifiant unique (interne) de la Target Application
  • windowslogin : login Windows ou identifiant de l’utilisateur dans le portail SharePoint
  • userName : nom d’utilisateur à stocker dans le Secure Store Service, dans la Target Application
  • userPassword : mot de passe à stocker dans le Secure Store Service, dans la Target Application

 


public static void SetCredentials(SPSite site, string applicationID, string windowslogin, string userName, string userPassword)
   {
      SPClaim claim = SPClaimProviderManager.CreateUserClaim(windowslogin, SPOriginalIssuerType.Windows);
      SecureStoreServiceClaim ssClaim = new SecureStoreServiceClaim(claim);

      SPServiceContext context = SPServiceContext.GetContext(SPServiceApplicationProxyGroup.Default, SPSiteSubscriptionIdentifier.Default);

      SecureStoreServiceProxy ssp = new SecureStoreServiceProxy();
      ISecureStore iss = ssp.GetSecureStore(context);

      IList applicationFields = iss.GetUserApplicationFields(applicationID);

      IList creds = new List(applicationFields.Count);

      using (SecureStoreCredentialCollection credentials = new SecureStoreCredentialCollection(creds))
      {
         foreach (TargetApplicationField field in applicationFields)
         {
            switch (field.CredentialType)
            {
               case SecureStoreCredentialType.UserName:
                  creds.Add(new SecureStoreCredential(GetSecureStringFromString(userName), SecureStoreCredentialType.UserName));
                  break;
               case SecureStoreCredentialType.Password:
                  creds.Add(new SecureStoreCredential(GetSecureStringFromString(userPassword), SecureStoreCredentialType.Password));
                  break;
               default:
                  break;
            }
         }
         iss.SetCredentials(applicationID, credentials);
      }
   }

La méthode doit être appelée comme suit :


SSSUtils.SetCredentials(SPContext.Current.Site, TargetApplicationID, SPContext.Current.Site.RootWeb.CurrentUser.LoginName, "LOGIN_A_STOCKER", "PASSWORD_A_STOCKER");

A savoir, il est important d’exécuter le code avec le compte de l’utilisateur connecté à SharePoint afin de pouvoir lire ses credentials ou écrire/mettre à jour ses credentials. Lorsque j’essayais d’écrire le code pour faire ces manipulations, je suis tombé sur pas mal de bouts de code où ils essayaient d’exécuter cela avec le compte système via de l’impersonation ou bien SPSecurity.RunWithElevatedPrivileges(). Cela n’a pas marché pour moi !

5/ Fonctions annexes

Dans les extraits de codes précédents, j’ai utilisé quelques méthodes supplémentaire pour encoder/décoder les chaines de caractères envoyées ou reçues depuis le Secure Store Service. Pour être totalement complet, les voici.

Cette première méthode permet de décoder une chaine encodée (SecureString) dans une chaine standard (String)


internal static string GetStringFromSecureString(SecureString secStr)
{
   if (secStr == null)
      return null;

   IntPtr pPlainText = IntPtr.Zero;
   try
   {
      pPlainText = Marshal.SecureStringToBSTR(secStr);
      return Marshal.PtrToStringBSTR(pPlainText);
   }
   finally
   {
      if (pPlainText != IntPtr.Zero)
         Marshal.FreeBSTR(pPlainText);
   }
}

Et bien sûr la méthode effectuant la manipulation inverse :


internal static SecureString GetSecureStringFromString(string str)
{
   if (str == null)
      return null;
   var str2 = new SecureString();
   char[] chArray = str.ToCharArray();
   for (int i = 0; i < chArray.Length; i++)
   {
      str2.AppendChar(chArray[i]);
      chArray[i] = '0';
   }
   return str2;
}

6/ Usings…

J’ai un peu oublié d’en parler au début, mais certains peuvent avoir des difficultés pour inclure les bonnes références et using nécessaires au projet (je ne parlerai pas des assemblies standards…).

Références :

  1. Microsoft.BusinessData (à aller cherche dans) : C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\ISAPI\Microsoft.BusinessData.dll
  2. Microsoft.Office.SecureStoreService (à aller rechercher dans le GAC) : C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.Office.SecureStoreService\v4.0_15.0.0.0__71e9bce111e9429c\Microsoft.Office.SecureStoreService.dll
  3. Microsoft.Office.SecureStoreService.Server.Security (à aller cherche dans) : C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\ISAPI\Microsoft.Office.SecureStoreService.Server.Security.dll

Il ne nous reste plus qu’à trouver un usage à tout ceci ! 🙂

Florent.

Advertisements

[WebCast] – OneDrive Entreprise : Mobilité et partage de documents à l’extérieur de l’entreprise

Posted on

Bonjour à tous.

Aujourd’hui, pour changer de mes habitudes :-), je vous propose un webcast que j’ai réalisé hier et il est déjà en ligne sur Youtube !

Je traite ici de mobilité et de la solution apportée par Microsoft grâce à OneDrive Entreprise et ses différents usages entre les devices de type pc, tablette et smartphone. C’est un sujet qui me tient à coeur (je crois qu’on le comprend en écoutant la vidéo 😉 ), je me déplace quasiment tous les jours et je retrouve mon environnement au travers des différents devices que j’ai en ma possession ou que le client peut me fournir (et qu’on ne maitrise pas malheureusement !).

A venir pour la fin mai, un nouveau webcast qui traitera de la nouvelle offre/solution Office Video & Azure Media Services.

De plus, Neos-SDI organise pas mal de webcast sur le même format, n’hésitez pas à regarder les vidéos sur Youtube. Elle se trouvent sur la chaine de Neos-SDI France : https://www.youtube.com/channel/UCr_0Kc0e1Ul8fE6eofjV15Q.

 

Bonne journée à tous !

[eBooks] – Collection d’ebooks gratuits

Posted on Updated on

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 !

Ca se passe par ici : http://blogs.msdn.com/b/mssmallbiz/archive/2013/06/18/huge-collection-of-free-microsoft-ebooks-for-you-including-office-office-365-sharepoint-sql-server-system-center-visual-studio-web-development-windows-windows-azure-and-windows-server.aspx

 

Bonne lecture !

[Skydrive Pro]–Sortie du client standalone pour Windows !

Posted on Updated on

 

Bonjour à tous.

Le travail en mobilité est devenu un vrai besoin à l’heure actuelle. A l’époque de SharePoint 2010 (pas encore révolu Sourire ), nous avions le client SharePoint Workspace 2010 qui permettait d’emporter ses documents en synchronisant le client avec SharePoint 2010.

Avec l’avènement de SharePoint 2013, Microsoft nous proposait le client Skydrive Pro… mais seulement avec le pack Office 2013 (et Office 365 Pro Plus ou Office 365 Small Business Premium). Il était impossible de se procurer ce client séparément ! Ce qui compliquait légèrement ce travail itinérant…

C’est maintenant chose faite, il est possible de le télécharger gratuitement ! par ici : http://www.microsoft.com/en-US/download/details.aspx?id=39050.

Il vous suffira de l’installer sur chacun des postes clients concernés et de lancer la synchronisation depuis le bouton “Sync” dans SharePoint 2013 :

image

 

Le client se lancera alors et vous demandera d’indiquer où il devra effectuer la synchronisation (répertoire local de la machine cliente) :

image

 

Le répertoire local sera alors synchronisé avec SharePoint 2013 dès que celui-ci sera accessible via le réseau :

image

 

Bonne installation !

[SharePoint 2013] – Installation des Office Web Apps 2013 avec SharePoint Server 2013

Posted on Updated on

 

Bonjour à tous.

Un nouvel article pour vous montrer comment installer et configurer les Office Web Apps 2013 couplées à SharePoint Server 2013.

Pour l’histoire, les Office Web Apps sont arrivées dans leur deuxième version : nous avons les Office Web Apps 2010 et 2013 à ce jour. Ces OWA vont nous permettre, couplées à SharePoint, d’ouvrir des documents Word, Excel, PowerPoint et OneNote directement dans le navigateur, sans utiliser les composants clients Office. Ce qui peut être évidemment très pratique lors les collaborateurs utilisent des plateformes hétérogènes de types tablettes iPad, Android, des téléphones mobiles ou encore des postes de travail sous MacOS ou une distribution Linux.

Il faut bien intégrer pour commencer qu’à chaque version de SharePoint correspond une version des Office Web Apps :

  • SharePoint 2010 (Foundation ou Server) => Office Web Apps 2010
  • SharePoint 2013 (Foundation ou Server) => Office Web Apps 2013

Coté Licencing, vous pourrez installer ces OWA (2010 ou 2013) suivant le type de licences que vous possédez pour le pack Office. Si vous possédez les packs Office (en volumes) version 2010 vous pourrez éditer les fichiers Office. Si vous ne les possédez pas, vous pourrez seulement lire des documents Office via les OWA.

 

De plus, avec la version 2010 des OWA, il était possible d’installer ce composant logiciel sur le même serveur que le serveur SharePoint (en le boostant un peu…). Avec la version 2013, ce n’est plus possible et ces composants s’installe sur un serveur dédié, rattaché au même domaine que SharePoint. Il y a quelques contraintes supplémentaires comme de ne pas avoir installé le pack Office sur ce serveur. Pour plus de renseignements : http://technet.microsoft.com/fr-fr/library/jj219458.aspx

 

Pour l’architecture utilisée pour cet article, j’ai 3 machines virtuelles (VM) :

  • 1 contrôleur de domaine : DOMAIN
  • 1 serveur SharePoint Server 2013 Enterprise (EN) : SP2013-DEV
  • 1 serveur Office Web Apps 2013 : SPOWA2013

Ces trois serveurs sont rattachés au même domaine : DEMO, sont installés sous Windows Server 2012 ou Windows Server 2008R2 (EN) et à jour :

 

image

Et oui… une belle débauche de mémoire et de processeurs… Sourire

 

Je précise que mes machines Active Directory & SharePoint étaient déjà installées et fonctionnelles avant l’installation d’Office Web Apps.

Première étape installer et configurer Windows Server 2012 (et mettre à jour !), je ne détaillerai pas cela dans cet article.

 

1/ Préparation du serveur pour Office Web Apps 2013

 

Lorsque le serveur a été installé et configuré, il faut commencer par télécharger les Office Web Apps 2013. Pour cela, vous pouvez télécharger la Preview ici : http://www.microsoft.com/en-us/download/details.aspx?id=30358 ou ici http://www.microsoft.com/fr-fr/download/details.aspx?id=35489. Vous pourrez également télécharger l’iso depuis votre compte MSDN ou Technet.

 

Connectez vous ensuite à votre serveur OWA avec un compte du domaine qui est administrateur local du serveur (dans mon cas, c’est le même que le compte d’installation de SharePoint : DEMO\spadmin).

 

Il faut ensuite exécuter un script PowerShell sur le serveur OWA en lançant la commande en administrateur. Pour cela, rendez-vous sur les “tuiles” de Windows Server 2012, repérez la tuile Windows PowerShell :

image

 

Faites un clic-droit sur la tuile :

image

 

Et cliquez sur “Run as administrator” :

image

 

Vous pouvez avoir l’UAC qui se déclenche, on clique sur “Yes” :

image

 

Et PowerShell 3.0 :

image

 

Nous allons lancer un script permettant d’installer et de configurer les rôles et services nécessaires sur le serveur pour OWA 2013. Vous trouverez des informations complémentaires ici : http://technet.microsoft.com/fr-fr/library/jj219455.aspx.

On copie / colle le script :

 

Add-WindowsFeature Web-Server,Web-Mgmt-Tools,Web-Mgmt-Console,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Static-Content,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-Filtering,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,InkandHandwritingServices

 

Le script d’installation se lance et devrait durer… moins de 3 minutes :

image

 

Mais que fait ce script me direz-vous ? Il se charge d’installer le rôle Web Server de Windows Server 2012 (installer IIS), et active sur ce rôle les différents protocoles, utilitaires qu’utiliseront les OWA 2013.

Lorsque le script est terminé, redémarrer le serveur OWA 2013. En allant dans le gestionnaire du serveur, on voit tout de suite le nouveau rôle IIS qui apparait :

 

image

 

image

 

Les extensions et fonctionnalités activées :

image

 

2/ Installation des Office Web Apps 2013

 

Maintenant que les prérequis sont installés, il va falloir installer les binaires des Office Web Apps 2013. Pour cela il faut monter l’iso téléchargé précédemment sur la machine virtuelle et lancer le setup d’installation :

image

 

Pour cela, on se rend dans l’explorateur de fichier et on fait un clic-droit sur le lecteur DVD avec l’iso monté, puis “Install or run program from your media” (s’il ne démarre pas tout seul).

Encore une fois, l’UAC peut s’activer, on clique sur “Yes” :

image

 

Le contrat de licence apparait, on sélectionne la case à cocher en bas, puis on clique sur “Continue” :

image

 

On nous demande ensuite d’indiquer l’emplacement d’installation des binaires. Je conserve l’emplacement par défaut : C:\Program Files\Microsoft Office Web Apps et on clique sur “Install Now” :

image

 

L’installation débute… on patiente :

image

image

 

L’installation est terminée, on clique sur “Close” :

image

 

En option, vous pouvez également installer les languages packs pour OWA 2013. Pour plus de renseignements, visitez ceci : http://technet.microsoft.com/fr-fr/library/jj219455.aspx => Etape 3.

 

 

3/ Déploiement des Office Web Apps

 

L’étape suivante consiste à créer l’application Web qui permettra d’afficher nos documents. Il existe plusieurs types de configurations suivant votre besoin : http ou https, équilibrage de charge, etc.

Dans mon cas, je reste dans un périmètre interne, tous les utilisateurs se connectent en http. Pour corser un peu le tout, nous allons créer l’application en PowerShell. Pour cela, on reprend notre console PowerShell lancée en administrateur et on exécute :

New-OfficeWebAppsFarm –InternalURL "http://servername" –AllowHttp -EditingEnabled

 

Où :

  • New-OfficeWebAppsFarm : permet de créer la ferme OWA 2013
  • InternalURL : adresse du serveur courant, dans mon cas http://spowa2013
  • AllowHttp : puisque je reste en http
  • EditingEnabled : puisque je veux permettre de lire / modifier les documents

Cela donne :

New-OfficeWebAppsFarm –InternalURL http://spowa2013 –AllowHttp -EditingEnabled

 

Un avertissement vous stipule que pour utiliser le mode édition de document des OWA 2013, il faut que vos utilisateur aient les licences adéquates. Pour savoir si vous pouvez utiliser le mode édition, je vous renvoie vers : http://technet.microsoft.com/fr-fr/library/ff431682.aspx#license.

Pour faire simple, vous avez les licences pour Office 2013, vous pouvez éditer. Sinon la lecture des fichiers est “offerte” par Microsoft.

image

 

Pour configurer les licences à utiliser, reportez vous à : http://technet.microsoft.com/fr-fr/library/jj219627.aspx.

Dans mon cas, je choisis donc “Yes” (Y) :

image

 

La configuration se poursuit. A la fin, un résumé apparait :

image

 

Remarque MSDN : Si des composants de .NET Framework 3.5 ont été installés puis supprimés, il est possible que vous rencontriez des messages de type « Exceptions de service web (500) » ou « Erreur interne du serveur (500.21) » lorsque vous exécutez des applets de commande OfficeWebApps. Pour résoudre ces problèmes, exécutez les exemples de commandes suivants à partir d’une invite de commandes avec élévation de privilèges afin de supprimer les paramètres susceptibles de gêner le fonctionnement normal d’Office Web Apps Server :

%systemroot%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe –iru
iisreset /restart /noforce

 

 

4/ Vérification que tout est ok…

 

Pour cela, nous allons utiliser le service de discovery des Office Web Apps en se connectant tout simplement sur une URL :

http://servername/hosting/discovery

 

Dans mon cas :

http://spowa2013/hosting/discovery

 

Je lance donc simplement un navigateur (IE 10 ici) et on entre l’adresse ci-dessus. Si Office Web Apps Server fonctionne comme prévu, vous verrez s’afficher un flux XML de découverte WOPI (Web app Open Platform Interface). Les premières lignes de ce fichier doivent se présenter comme dans l’exemple suivant : :

image

 

Et ce n’est pas fini…

 

 

5/ Configurer SharePoint Server 2013 pour Office Web Apps 2013

 

Il nous reste maintenant à faire le lien entre notre ferme SharePoint Server 2013 et les Office Web Apps 2013. Et encore une fois… une bonne dose de PowerShell !

Cependant, nous n’allons pas utiliser la console PowerShell 3.0 de Windows Server 2012, mais le SharePoint Management Shell de SharePoint Server 2013… un outil bien connu des administrateurs SharePoint !

Lançons donc la console SharePoint Management Shell, sur le serveur SharePoint bien entendu !

image

 

Puis toujours dans cette console, on lance la commande :

New-SPWOPIBinding -ServerName <WacServerName> -AllowHTTP

 

Dans mon cas (attention aux paramètres suivant ceux fixés lors de la configuration des OWA : http / https en particulier) :

New-SPWOPIBinding –ServerName SPOWA2013 -AllowHTTP

 

image

 

Le Shell vous liste un ensemble de connections WOPI disponibles :

image

 

Puis on exécute :

Get-SPWOPIZone

 

image

Dans les résultats vous devez avoir absolument :

 

Internal-https

 

Et bien sûr nous voudrions avoir du http ! Nous allons donc modifier cette zone avec la commande :

Set-SPWOPIZone –zone “internal-http”

 

Et on relance avec Get-SPWOPIZone pour vérifier que cela a bien été pris en compte :

image

Maintenant nous avons :

 

Internal-http

 

 

Ca sent la fin… mais pas tout de suite. Il nous reste à autoriser l’authentification OAuth sur http pour que cela fonctionne. Pour cela on éxécute :

(Get-SPSecurityTokenServiceConfig).AllowOAuthOverHttp

image

Si cela renvoie “False” dans la console, alors il faut forcer la valeur à “True” :

$config = (Get-SPSecurityTokenServiceConfig)
$config.AllowOAuthOverHttp = $true
$config.Update()

 

On relance une petite vérification :

 

(Get-SPSecurityTokenServiceConfig).AllowOAuthOverHttp

La valeur renvoyée doit être maintenant à “True” :

image

Pour plus d’informations : http://technet.microsoft.com/fr-fr/library/ff431687.aspx.

 

 

6/ Vérification de la configuration globale

 

Pour vérifier… il faut tester ! Nous allons donc nous connecter sur un de nos sites SharePoint avec un compte utilisateur / collaborateur (pas d’administrateur, super admin etc.)

image

 

J’ajoute quelques documents de type Office… dans une bibliothèque de documents :

image

 

On clique sur un des fichiers (PowerPoint pour ma part)… et ça marche !

image

 

Et du Word :

image

 

Et de l’Excel :

image

 

Et un OneNote :

image

 

Notez à chaque fois la présence des boutons dans le ruban pour éditer les documents, les sauvegarder etc. Ca marche plutôt bien !

 

Grâce aux Office Web Apps 2013, nous avons aussi la prévisualisation des documents (dans la bibliothèque de documents et dans la recherche) :

image

 

image

 

Si vous avez activé l’édition / création des documents depuis OWA 2013, lorsque vous cliquez sur le bouton Nouveau document Word, vous pourrez créer vos document directement en Web !

image

image

 

image

 

Voilà, c’est fini !

[SharePoint 2013]–Nouvel outil : SharePoint Color Palette Tool

Posted on Updated on

Avec la sortie de la nouvelle version de SharePoint 2013, nous avons vu (encore) son design général changé. Ce design reprend les principes de Modern UI dictés par Microsoft et repris sur l’intégralité des plateformes : Windows 8, Windows Phone, Xbox.

Nous retrouvons donc dans SharePoint en particulier les Tuiles bien connues, et d’autres un peu moins “Visibles” au premier abord.

SharePoint 2013 apporte également son lot de nouveau thèmes graphiques natifs sur lesquels on peut personnaliser le jeu de couleurs, l’icône, et même la navigation latérale via les materpages oslo.master & seattle.master. Cet éditeur de thèmes permet quand même bien des personnalisations, mais il se peut que cela ne suffise pas !

Dans ces cas là, on peut utiliser le Design Manager permettant d’importer des découpages html pour les convertir en masterpages, les canaux, etc. (voir mon article : SP2013–Design Manager).

 

Pour nous permettre d’aller plus loin, mais sans recourir à SharePoint Designer, aux CSS, aux masterpages, Microsoft nous propose un nouvel outil fraichement releasé : SharePoint Color Palette Tool ! Les prérequis sont Internet Explorer 8 ou supérieur et le Framework 4.5.

Pour ceux qui le connaitraient, pour SharePoint 2010 nous avions Theme Builder renommé Open XML Theme Builder et disponible récemment sur CodePlex : Open XML Theme Builder.

 

Voyons ensemble à quoi cela ressemble !

 

On télécharge l’outil ici : SharePoint Color Palette Tool (1,1Mb).

Et on l’installe (ici sur une machine Windows 8 Enterprise x64 en anglais) :

 

On lance le setup, “Next” :

01

 

On accepte les termes du contrat de licence et “Next” :

02

 

On choisit l’emplacement d’installation, puis “Next” :

03

 

Résumé des information, “Next” :

04

 

L’installation est terminée, on coche “Launch the program”, “Finish” :

05

 

Le programme se lance :

06

 

Premières impressions… plutôt bonnes ! On retrouve sur la gauche un ensemble de contrôles “couleur” avec prévisualisation et code couleur RGB. Au centre, une prévisualisation du résultat (on reprend le thème général de SharePoint 2013) et tout en haut le choix du layout (oslo ou seattle), en dessous un affichage des warnings & erreurs. Sur la droite, un contrôle permet de placer une image en fond, de choisir un jeu de couleurs originel, et au centre un outil permettant de tester le contraste appliqué…

 

Première chose que je vérifie… qu’est-ce que génère cet outil ? En faisant File > Save, on me propose de sauvegarder un fichier *.spcolor :

07

 

Ce fichier spcolor n’est autre qu’un fichier XML :

08

 

Qu’il faudra importer dans SharePoint 2013, pour en savoir plus, direction MSDN : http://msdn.microsoft.com/en-us/library/jj945889.aspx

En fait on retrouve une certaine analogie entre ce fichier spcolor et les css, mais seulement pour la partie couleurs. En effet, on ne retrouve dans ce fichier aucun information sur la masterpage, le layout etc. Donc les paramètres dans l’outil Color Palette ne servent qu’à la prévisualisation, pas au paramétrage du thème en lui-même.

Notons également que dans la zone de gauche, on a des sous items sur lesquels on pourra modifier les couleurs :

09

 

A mon avis, cela va être difficile de faire un jeu de couleur correct dès le premier essai ! Il y a beaucoup de couleurs à paramétrer…

 

Avec 3 ou 4 clics, on arrive à quelque chose… ou pas ! (Notez les warnings…)

10

 

A bientôt !

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