Archives de catégorie : Non classé

Erreur trompeuse lors de l’installation de SharePoint 2016 avec AutoSPInstaller

Introduction

Si vous avez déjà monté vous même vos serveurs SharePoint 2010/2013/2016, vous connaissez sans doute le projet Open Source AutoSPInstaller. Idéalement, il est préférable d’installer SharePoint en anglais puis d’ajouter les différents Language Packs. Vous rencontrerez également certaines erreurs si votre système d’exploitation est installé dans une autre langue que l’anglais comme expliqué dans ce billet.

Symptômes

Vous obtenez le message suivant : – Managed Metadata Service Application Proxy already provisioned.
– Granting rights to Metadata Service Application:
– DOMAIN\NomDuCompte…
PS>Erreur de terminaison (Grant-SPObjectSecurity) : « L’argument Rights n’est pas valide. Les valeurs valides sont : Magasin de termes avec accès en lecture, Magasin de termes avec accès en lecture et accès limité en écriture, Magasin de termes avec accès total »
Grant-SPObjectSecurity : L’argument Rights n’est pas valide. Les valeurs valides sont: Magasin de termes avec accès en
lecture, Magasin de termes avec accès en lecture et accès limité en écriture, Magasin de termes avec accès total
Au caractère E:\AutoSPInstaller\SP\AutoSPInstaller\AutoSPInstallerFunctions.ps1:2536 : 21
+ … Grant-SPObjectSecurity $metadataServiceAppSecurity -Princ …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument : (Microsoft.Share…tObjectSecurity:SPCmdletGrantObjectSecurity) [Grant
-SPObjectSecurity], SPException
+ FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletGrantObjectSecurityPS>Erreur de terminaison () : «  – Error provisioning the Managed Metadata Service Application »
>> Erreur de terminaison () : «  – Error provisioning the Managed Metadata Service Application »
————————————————————–
– Script halted!
– Error provisioning the Managed Metadata Service Application
Press any key to exit…

Cause

À première vue, l’erreur semble indiquer un problème de d’autorisations puisque l’applet de commande utilisé est Grant-SPObjectSecurity et que l’erreur semble être l’argument « Rights ».

Cependant, si on regarde attentivement le fichier AutoSPInstallerFunctions.ps1 qui s’occupe de créer le service Managed Metadata Service Application à la ligne suivante :
Grant-SPObjectSecurity $metadataServiceAppSecurity -Principal $accountPrincipal -Rights « Full Access to Term Store »
On voit que l’argument « Rights » est en anglais « Full Access to Term Store » alors que dans le message d’erreur on voit que les valeurs valides sont : « Magasin de termes avec accès en lecture, Magasin de termes avec accès en lecture et accès limité en écriture, Magasin de termes avec accès total »

Résolution

Première résolution:

Modifier la langue d’affichage de Windows afin de mettre l’anglais par défaut :

Langue

Deuxième résolution :

Modifier les lignes « Grant-SPObjectSecurity » du fichier AutoSPInstallerFunctions.ps1 afin de mettre la valeur du paramètre « Rights » correspondant à la langue d’affichage de votre système d’exploitation.

Exemple :

En-Us
Grant-SPObjectSecurity $profileServiceAppPermissions -Principal $currentUserAcctPrincipal -Rights « Full Control »

Fr-Ca

Grant-SPObjectSecurity $profileServiceAppPermissions -Principal $currentUserAcctPrincipal -Rights « Contrôle total »

Microsoft Most Valuable Professional (MVP) pour 2016

J’ai été très heureux de recevoir ce courriel m’informant qu’on m’octroyait le titre de MVP dans la catégorie Office Servers and Services (Anciennement SharePoint Server). 

unnamed

Congratulations! We are pleased to present you with the 2016 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in Office Servers and Services technical communities during the past year.

C’est la première fois qu’on m’accorde ce titre alors je tiens à remercier Microsoft, mes collègues et amis de Victrix ainsi que la communauté SharePoint qui sont pour moi une source d’inspiration me permettant de m’améliorer.

Ce sera une année très intéressante avec les dernières annonces concernant Office 365 et SharePoint. Je me réjouis des défis et des opportunités qui en découleront.

SharePoint 2016 – Les types de contenu, les colonnes de site ainsi que d’autres éléments de sites sont finalement multilingue!

Les éléments suivants prennent maintenant en charge le multilingue dans SharePoint 2016 Preview (et les versions suivantes) :

  • Titre d’un site
  • Description d’un site
  • Titre d’une liste
  • Description d’une liste
  • Nom d’un type de contenu
  • Description d’un type de contenu
  • Titre d’une colonne de site
  • Description d’une colonne de site

Ceci avait été annoncé pour Office 365 en 2014 cependant ce n’était pas disponible pour les versions On-Premise. L’article est donc encore une excellent source de référence.

Dans l’exemple suivant je vais modifier la description d’un site pour la culture « en-US » et « fr-FR » avec du PowerShell.

Avant l’exécution (Affichage en-US) :

MultilangualDescriptionBefore

MultilangualDescriptionPowerShell


$web = get-spweb http://sp2016preview
$web.DescriptionResource.SetValueForUICulture("en-US", "Support multilangual")
$web.DescriptionResource.SetValueForUICulture("fr-FR", "Supporte le multilangue")
$web.Update()
$web.DescriptionResource.GetValueForUICulture("en-US")
Support multilangual
$web.DescriptionResource.GetValueForUICulture("fr-FR")
Supporte le multilangue

Après l’exécution (Affichage en-US) :

MultilangualDescriptionAfter

Pour l’instant, nous sommes un peu dans le néant en ce qui concerne les nouveautés au niveau de l’API de SharePoint alors je n’ai pas eu le choix de d’ouvrir la DLL avec Reflector. Il est possible de voir que la propriété « DescriptionResource » est disponible sur plusieurs éléments :

DescriptionResourceClient

Maintenant, les fonctions pour obtenir ou modifier cette propriété :

GetValueForUICulture

SetValueForUICulture

De plus, les fonctions se retrouvent autant au niveau de Microsoft.SharePoint.DLL que dans Microsoft.SharePoint.Client.DLL.

Ceci permet l’appel de ces fonctions avec du code serveur ainsi qu’avec du code client (Ex : CSOM)

Conclusion

Cette amélioration est des plus apprécié pour les entreprises qui désirent offrir une interface multilingue sans avoir à dupliquer les sites, les colonnes, les types de contenu, etc…

Problème de redirection lors de l’enregistrement d’une page Wiki dans SharePoint 2013 Foundation

Introduction

Tout juste avant les vacances, un de mes collègues Achraf Loudiy m’a demandé assistance avec un problème lorsqu’il ajoutait des pages Wiki contenant des caractères accentués dans le URL de la page. Puisqu’on a passé un nombre considérable d’heures sur cette problématique, j’ai décidé d’en faire une SharePointerie.

Détail de la problématique

Dans SharePoint Foundation 2013, suite à l’enregistrement d’une page Wiki dans la bibliothèque «Pages de site» , une redirection est effectué vers une page qui n’existe pas.

Pour reproduire le problème :

  1. Créer une page Wiki contenant au moins un caractère accentué (Ex : PageAccentué).
  2. Sauvegarder la page.
  3. Naviguer vers Contenu du site -> Bibliothèque « Pages de site ».
  4. Accéder à la page Wiki en mode « Édition ».
  5. Sauvegarder la page. (Vous serez alors redirigé vers une page inexistante).

Début des investigations

Lorsqu’on m’a énoncé cette problématique, j’ai immédiatement fais le test sur mon environnement O365 ainsi que sur ma VM SharePoint 2013 On-Premise. Cependant je n’ai pas réussi à reproduire le problème.

J’ai donc recommandé à mon collègue de procéder à l’installation du Service Pack 1 ainsi que des derniers CU dans son environnement SharePoint 2013 Foundation. Malheureusement, toujours le même problème suite à l’installation des mise à jours et Google ne nous est pas d’une grande utilité peu importe les mots-clés utilisés.

C’est là qu’on a commencé à déboguer avec Fiddler. Plus en détail voici le détail des traces :

fiddler_MDS

(200 – OK) http://sp2013/sites/sharepointerie/SitePages/PageAccentu%C3%A9.aspx

(200 – OK) http://sp2013/sites/sharepointerie/_layouts/15/start.aspx

(404 – Page Not found) http://sp2013/sites/sharepointerie/_layouts/15/start.aspx#/SitePages/PageAccentu%C3%83%C2%A9.aspx

Il y a clairement un changement au niveau de l’encodage du URL une fois que la page est redirigé par /_layouts/15/start.aspx.

Avant : PageAccentu%C3%A9.aspx

Après : PageAccentu%C3%83%C2%A9.aspx

Jusqu’à maintenant on sait que :

  • Lorsqu’on passe par la bibliothèque via le menu de gauche pour accéder à la page, une section « /_layouts/starts.aspx » est ajouté au URL.
  • Lorsqu’on accède directement à la page sans passer par le menu de gauche, la page s’ouvre correctement.

On a alors un « workaround » mais malgré tout, j’ai continué d’investiguer pour trouver une meilleure solution.

Cette fois-ci Google a été mon ami après avoir recherché « /_Layouts/15/Start.aspx redirect problem » je suis tombé sur cette page qui parle de la fonctionnalité Minimal download strategy (MDS).

MDS_Enabled

Cette fameuse fonctionnalité de site m’avait déjà causé des problèmes alors on a décidé de la désactiver pour voir si ça corrigerait le problème (Paramètres de site – Fonctionnalités de site).

MDS_Disabled

Une fois désactivé, voici le résultat des traces dans Fiddler :

fiddler_MDS_Disabled

(200 – OK) http://sp2013/sites/sharepointerie/SitePages/PageAccentu%C3%A9.aspx

Lors de la sauvegarde de la page, le URL ne comprend plus la section « /_layouts/starts.aspx » et on est maintenant redirigé vers la bonne page.

Fonctionnalité Minimal Download Strategy (MDS)

Minimal Download Strategy (MDS) est une nouvelle technologie dans SharePoint 2013 qui réduit la quantité de données ayant le navigateur pour télécharger lorsque les utilisateurs naviguer d’une page à une autre dans un site SharePoint. Lorsque les utilisateurs accèdent à un site prenant en charge MDS, le client traite uniquement les différences (ou delta) entre la page actuelle et à la page demandée.

MDS utilise un fichier .aspx (start.aspx) pour vos page, avec le URL courant encodé dans le texte suivi du hashmark (‘#’).

Donc en gros, cette fonctionnalité a pour but d’optimiser l’expérience de l’utilisateur en gagnant du temps de traitement.

Cependant, comme on a pu le voir dans les traces de Fiddler, le URL encodé final est différent lorsque la fonctionnalité MDS est activé.

Solution

On a donc créé un modèle de site avec la fonctionnalité MDS désactivé par défaut afin de ne plus avoir cette fâcheuse redirection.

Je n’ai pas réussi à trouver pourquoi l’encodage des URL est différent lorsque cette fonctionnalité est activé.

Sans MDS: PageAccentu%C3%A9.aspx (PageAccentué.aspx)

Avec MDS : PageAccentu%C3%83%C2%A9.aspx (PageAccentué.aspx)

Vous avez des idées ?

Conclusion

Je l’ai dit souvent et je vais probablement le dire encore, SharePoint c’est avant tout une application Web alors il ne faut pas hésiter à la déboguer avec des outils de développement Web (Fiddler, IE Toolbar, etc…). Bien que la fonctionnalité MDS a pour but d’améliorer les performances, dans le cas suivant, je crois que la meilleure alternative est de la désactiver.

Références

Minimal Download Strategy (MDS)

Redirection avec le MDS

À quoi sert /_layouts/starts.aspx dans SharePoint 2013

Déployer une page contenant une webpart via un module (XML déclaratif)

Introduction

Il y a plusieurs façon de créer une page avec une WebPart mais bien souvent cela requiert plusieurs lignes de codes. C’est pourtant si simple avec un module XML et cela comporte de nombreux avantages.

Comment faire?

1 – Ajout du module

Pour commencer, on crée un projet vide SharePoint 2013 et on y ajoute un module.

ModuleDeployerPage

On retrouve alors dans le fichier elements.xml du module le contenu suivant :

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
 <Module Name="ModuleDeployerPage">
 <File Path="ModuleDeployerPage\Sample.txt" Url="ModuleDeployerPage/Sample.txt" />
 </Module>
</Elements>

Au lieu de copier le contenu d’une page, on va réutiliser un modèle de page natif (viewpage.aspx) alors peut tout simplement supprimer le fichier Sample.txt.

Dans la balise <Module> on ajoute le paramètre SetupPath= »pages\ » 

Ce paramètre permet d’indiquer le chemin d’accès physique à un dossier dans le répertoire d’installation de SharePoint Foundation (%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE) qui contient un fichier à inclure dans le module.

Par la suite dans la balise <File> on ajoute deux paramètres très important soit Url et Path  :

Url= »PageDeployeParModuleXML.aspx » Path= »viewpage.aspx »

Le paramètre Url permet d’indiquer le chemin d’accès virtuel pour le fichier.

Le paramètre Path permet d’indiquer le chemin d’accès physique au fichier par rapport au fichiers template contenu dans le répertoire d’installation de SharePoint Foundation (%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE\SiteTemplates\Site_Definition)

Il y a plusieurs autres modèles de pages natives que l’on peut utiliser.

Ex : spstd1.aspx

ModuleDeployerPageTemplate

Ces autres fichiers se retrouvent sous : C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\1033\STS\DOCTEMP\SMARTPG

Jusqu’à maintenant, notre fichier elements.xml devrait ressembler à ceci :

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Module Name="ModuleDeployerPage" <strong>SetupPath="pages\">
<File Url="PageDeployeParModuleXML.aspx" Path="viewpage.aspx">
</File>
</Module>
</Elements>

2 – Ajout d’une webpart

Pour les besoins de cet exemple, j’utilise une Visual WebPart mais il est aussi possible de le faire avec les autres types de Webpart.

ModuleDeployerPageWebPart

Si on ouvre le fichier VisualWebPart.webpart on peut voir le contenu XML suivant :

<?xml version="1.0" encoding="utf-8"?>
<webParts>
 <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
 <metaData>
 <type name="POC.SharePoint.Module.VisualWebPart.VisualWebPart, $SharePoint.Project.AssemblyFullName$" />
 <importErrorMessage>$Resources:core,ImportErrorMessage;</importErrorMessage>
 </metaData>
 <data>
 <properties>
 <property name="Title" type="string">POC.SharePoint.Module - VisualWebPart</property>
 <property name="Description" type="string">My Visual Web Part</property>
 </properties>
 </data>
 </webPart>
</webParts>

On peut alors copier le contenu XML de la balise <WebParts> dans la balise  <File> du fichier Elements.xml du Module créé précédemment.

Ensuite, il reste seulement à ajouter une balise  <AllUsersWebPart> afin de spécifier l’ordre et la zone dans laquelle se retrouvera la WebPart.

Votre fichier Elements.xml devrait finalement ressembler à ceci :

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
 <Module Name="ModuleDeployerPage" SetupPath="pages\" RootWebOnly="FALSE">
 <File Url="PageDeployeParModuleXML.aspx" Path="viewpage.aspx">
 <AllUsersWebPart WebPartOrder="0" WebPartZoneID="Main" ID="g_2afba91e_8dab_4004_bb10_feddbb8a1cd3">
 <![CDATA[<webParts>
 <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
 <metaData>
 <type name="POC.SharePoint.Module.VisualWebPart.VisualWebPart, $SharePoint.Project.AssemblyFullName$" />
 <importErrorMessage>$Resources:core,ImportErrorMessage;</importErrorMessage>
 </metaData>
 <data>
 <properties>
 <property name="Title" type="string">POC.SharePoint.Module - VisualWebPart</property>
 <property name="Description" type="string">My Visual Web Part</property>
 </properties>
 </data>
 </webPart>
</webParts>]]>
 </AllUsersWebPart>
 </File>
 </Module>
</Elements>

3 – On déploie et on test

Lorsqu’on déploie on obtient notre page avec la WebPart à l’intérieur :

ModuleDeployerPageWebPartFinal

Conclusion

À partir d’un module, on a déployé une page basé sur un modèle natif de SharePoint sans dupliquer son contenu. Ensuite on a tout simplement ajouté une WebPart dans cette page. Dans l’ensemble, c’est relativement simple une fois qu’on s’est familiarisé avec les différentes balises XML. De plus, on utilise seulement du code XML en comparaison à utiliser plusieurs lignes de code pour faire le travail.

Le code source de ce billet est disponible ici et la référence complète sur les différentes balises d’un module est disponible sur MSDN.

Un bottin dans SharePoint qui s’alimente de l’AD?

Introduction

Dans tout bon intranet, il y a un bottin téléphonique pour permettre aux utilisateurs de rechercher leur collègues soit par leur nom ou prénom à l’intérieur d’une même entreprise. Les gens de communications vous le dirons, c’est une des fonctionnalités les plus utilisées si l’information est fiable et que le tout est simple d’utilisation. Trop souvent, une liste SharePoint est créé et utilisé comme un bottin téléphonique et malheureusement cette liste n’est pas mise-à-jour régulièrement. En plus de dupliquer le contenu entre l’AD et SharePoint, cela peut créer une incohérence lorsque l’information diffère entre les deux endroits. L’idéal c’est d’avoir l’information à jour dans l’AD et de s’en servir comme source principale. Ensuite, on peut s’alimenter de l’AD ou se synchroniser à partir de l’AD pour avoir un bottin téléphonique mis-à-jour régulièrement.

Il existe plusieurs solutions pour y arriver et dans ce billet que je vais tenter d’éclairer vos lanternes en vous proposant 2 solutions :

1. En utilisant la recherche de personne et en s’alimentant du service des profils utilisateurs (UPS)

C’est probablement la meilleure solution car elle est évolutive et native. En plus de cela, il y a la possibilité d’avoir d’autres propriétés propres à chaque individu (ex. : compétences, langues, expertises, etc.). De plus, on peut alimenter les profils utilisateurs avec l’information provenant d’autres systèmes (ex. : Système de RH).

En quoi ça consiste ?

  • Mise en place du service de profil utilisateur (UPS);
  • Synchronisation du service de profil utilisateur avec l’AD;
  • Configuration de la recherche de personnes;
  • Création des pages du bottin qui effectuent des requêtes sur le service de profil utilisateur via le service de recherche.

Exemple :

sharepoint-people-directory

2. En utilisant une WebPart pour l’affichage et en s’alimentant de l’AD

Si vous n’envisagez pas d’avoir un site MySite et de configurer les services applicatifs requis, cette solution est probablement votre meilleure alternative. Elle est peu coûteuse mais elle n’offre pas tout les avantages de la première solution avec le service des profils utilisateurs et la recherche.

En quoi ça consiste ?

  • Installation d’une WebPart gratuite;
  • Configuration de la WebPart pour se connecter à l’AD;
  • Personnalisation de l’affichage de la WebPart (Au besoin).

Exemple :

UsersADBrowser

Source :  http://usersadbrowser.codeplex.com/