SHAREPOINT 2013 : Contrôle des développements

 

L'utilisation massive de SharePoint dans les entreprises impose aux sociétés de s'assurer de la bonne santé de leur environnement SharePoint 2013.
Cela commence par une infrastructure qui tient la route, une topologie adaptée mais aussi et surtout par un contrôle des développements réalisés.

 

En effet 90% des dégradations des performances sur des environnements SharePoint proviennent de développements ne respectant pas les guidelines et bonnes pratiques de Microsoft (objets SP non disposés, requêtes CAML sans RowLimit,...).

Après l'essai de divers outils du marché, il me semble que l'outil "SPCAF" (SharePoint Code Analysis Framework) est parfaitement adapté à ce genre de besoins. Le site de l'éditeur est disponible à l'adresse suivante : http://www.spcaf.com/

 

Cet outil se décompose en 2 axes principaux :

• Une application cliente permettant d'inspecter un WSP. Cette partie est plutôt orienté chef de projet avant livraison ou client final,
• Un add-in pour Visual Studio permettant de contrôler le code tout au long de la phase de conception de la solution VS. Cette partie est donc plutôt orientée développeur SP.

 

Les contrôles de qualité sont réalisés selon diverses catégories :  bonnes pratiques, sécurité, design, déploiement, ressources, interface utilisateur. Les règles sont prédéfinies mais peuvent être étendues si besoin. Après utilisation, je peux vous assurer que les règles natives sont très largement suffisantes!
Chacun des éléments remontés par l'analyse sont classés selon leur criticité : critique, sévérité haute, sévérité moyenne, sévérité faible.

 

Pour compléter le tout, ce produit permet aussi de générer:

• des métriques de code (XML, ASPX, HTML, CSS, JS),
• des inventaires (champs, types de contenus, définitions de listes, WebParts),

 

Il est très rare de faire de la promotion pour des outils commerciaux mais la qualité de ce produit en fait un élément incontournable dans la trousse à outils SharePoint!

INFOPATH 2013 : Gestion des pièces jointes

Aujourd'hui un post sur un problème récurrent rencontré par les utilisateurs d'InfoPath et plus généralement InfoPath Forms Services : La gestion des pièces jointes.

 

Nativement, les pièces jointes téléchargées via le formulaire sont stockées dans le XML de l'instance. 

Cela implique généralement une quadruple problématique pour les utilisateurs :

1. Le formulaire est alourdi par cette pièce jointe encodée dans le XML,
2. Le temps de chargement du formulaire est grandement dégradé,
3. La gestion de la sécurité du document (droit de modification, lecture ou confidentiel) ne peut pas être décorrélée de celle du formulaire,
4. Les pièces jointes insérées dans le formulaire ne sont pas indexées via le moteur de recherche.

Note : Les formulaires de "liste" modifiés via  InfoPath ne sont pas concernés par le sujet car ils héritent du fonctionnement natif des listes SharePoint.

 

En tant que solution de contournement à ces problématiques, je conseille généralement (lorsque le besoin s'y prête) de réaliser un peu de code managé permettant de changer légèrement le fonctionnement du contrôle.

Le fonctionnement devient ainsi le suivant:

1. La pièce jointe est téléchargée dans le formulaire,
2. L'évènement "Changed" est déclenché dans le code managé dès l'ajout du fichier dans le contrôle,
3. Le code associé à cet évènement dépose la pièce jointe dans une bibliothèque de document SharePoint (possibilité de stocker dans un fichier dédié, nettoyage du nom de fichier, gestion des autorisations,...),
4. Alimentation d'une section extensible pour afficher la liste des fichiers associés à l'intérieur du formulaire,
5. Suppression du fichier dans le contrôle de pièce jointe du formulaire.

 

 

Voici le rendu:

 

Nous pouvons voir que :

• Le contrôle des pièces jointes reste vide. Le données ne sont pas stockées dans l'instance de formulaire elle-même => Optimisation du temps d'ouverture et de traitement,
• Les fichiers sont ajoutés dans une bibliothèque SharePoint (ce qui permet de les regrouper, gérer leur sécurité, les rendre indexable,...) => Plus grande flexibilité sur les règles de gestion métier,
• La suppression de fichiers depuis le formulaire via le petit bouton rouge (nécessitant quelques lignes de code managé sur le clic du bouton) est aussi prévue.

N'hésitez pas à me contacter si besoin.

SHAREPOINT 2010 : Erreur aléatoire sur la recherche

Aujourd'hui, un article sur un nouveau problème remonté sur la recherche dans SharePoint 2010. Je crois que c'est ce qu'on appelle la loi des séries (voir article précédent).

Cette fois-ci, un message d'erreur apparaît sporadiquement lors de l'utilisation du moteur de recherche par les utilisateurs de la ferme SharePoint...
Le genre d'erreurs bien sympa sur lequel on est content d'être appelé pour intervention! D'autant plus lorsque la plateforme d'intégration, strictement identique à celle de production, ne présente pas ce problème.

 

Une fois le dysfonctionnement reproduit, il est nécessaire de rechercher l'ID de corrélation dans les logs SharePoint afin d'obtenir plus d'informations.

L'erreur détectée est la suivante : "Illegal operation attempted on a registry key marked for deletion".
 

Après quelques recherches, il s’avère que cela peut provenir d’un problème sur le profil utilisateur Windows. Pour corriger ce dysfonctionnement, il faudra aller modifier une clé dans la group policy de chaque serveur :

• Se connecter sur le serveur avec un compte 'Administrateur',
• Taper "gpedit.msc" dans la fenêtre exécuter du serveur,
• Se positionner dans la section "Computer configuration",
• Administrative template,
• System,
• User profiles,
• Modifier la clé « Do not forcefully unload the registry at user logoff » en l’activant,
• Redémarrer le serveur en dehors des horaires d'activités.

Suite à cette modification rapide, votre recherche fonctionnera à nouveau correctement sans cette fameuse erreur alternative.

SHAREPOINT 2010 : La recherche ne renvoie pas les titres des documents

Lors de l'utilisation de la recherche sur une ferme SharePoint 2010, vous pouvez être amené à rencontrer un problème majeur : Le moteur de recherche SharePoint ne renvoie pas le titre des documents Office. En lieu et place, seule la première ligne du document est renvoyée en tant que titre.
Cette erreur survient essentiellement sur des documents Office 2007 mais pas que! Les documents Word 2010 et PowerPoint 2010 sont aussi impactés.
En revanche, tout semble fonctionner correctement avec des documents Office 2013.

 

Si votre ferme SharePoint est concernée, il faudra suivre les étapes suivantes afin de corriger ce dysfonctionnement:

• Ouvrir la base de registre du serveur en tapant regedit.exe dans une fenêtre cmd,
• Se positionner à l'emplacement suivant : [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\Search\Global\Gathering Manager],
• Modifier la clé de registre "EnableOptimisticTitleOverride"  et la positionner à "0".
• Redémarrer le service de recherche à l'aide des 2 commandes suivantes : "net stop osearch14", puis "net start osearch14",
• Enfin, attendre le prochain full crawl ou le relancer manuellement.

 

 

SHAREPOINT 2013 : Test des bases de contenu d'une application web

Aujourd'hui un article sur un point qui devrait être essentiel dans une gouvernance SharePoint! Il s'agit de la surveillance de la santé de votre web application à travers l'état des bases de données de contenu qui y sont rattachées.

J'ai conçu un petit script PowerShell permettant de réaliser un "Test-SPContentDatabase" sur toutes les bases de contenu associées à votre application web. puis d'exporter le résultat vers un fichier CSV.
Le parcours de toutes les bases n'est pas négligeable sachant que sur de grandes  fermes GED, vous pouvez atteindre rapidement une centaine de bases de contenus rattachées à une seule web application.

Voici le script:

$URL_WebApp="http://mawebapplicationSP";
$CSV_SaveLocation="E:\ResultTestMaWebApp.csv";
$DBErrors=@();

$webApp = Get-SPWebApplication $URL_WebApp;
Write-Host -foregroundcolor Green "WebApplication: " $webApp.Url;
$webApp.ContentDatabases|%{
                $contentDBName = $_.Name;
                Write-Host -foregroundcolor Green "Parcours de la base de contenu : "$_.Name;
                $errors = Test-SPContentDatabase -ServerInstance $_.Server  -WebApplication $webApp -Name $contentDBName;
                if($errors)
                {
                               $errors|%{$_|Add-Member -membertype NoteProperty -Name "Database" -Value $contentDBName;}
                               $DBErrors += $errors;
                }
}
$DBErrors | Select-Object "Database","Category","Error","UpgradeBlocking","Message","Remedy"| Export-CSV $CSV_SaveLocation -Delimiter ";" -encoding "UTF8"

Selon moi, pour bien faire, ce genre de script devrait être lancé tous les mois sur les environnements SharePoint. Ceci permettra de vous assurer régulièrement de ne pas avoir d'erreurs (missingsetupfile, missingfeature, missingassembly,...) liées à vos solutions SharePoint.
Ainsi, le travail de mise à jour de votre ferme SharePoint (Cumulative Update, Public update, Service Pack) n'en sera que simplifié et permettra de gagner en sérénité.

Note : Cet article s'applique aussi à SharePoint 2010.

SharePoint 2010 : Politique de rétention

Aujourd'hui un article rapide sur les politiques de rétention dans SharePoint 2010.
Cette fonctionnalité permet de répartir l'information (supprimer, déplacer, enlever le versioning) selon divers critères (Date de création ou de modification, Fin de publication).

 

 

Elle permet par exemple de veiller à ce que les préconisations de Microsoft soient respectées en ce qui concerne les limitations du nombre d'éléments dans les listes et bibliothèques.
Ceci est clairement à utiliser dans le cadre de sites comprenant des informations saisies et mises à jour régulièrement. Dans un cas concret, il sera ainsi possible de déplacer des actualités d'un site vers une liste "Actualités-Archive" en les conditionnant sur le nombre de jours, mois ou années après leur création.

Pour activer la rétention au niveau d'une liste ou bibliothèque, il suffit de suivre les étapes suivantes:

• Se placer sur une liste ou bibliothèque,
• Aller dans les paramètres de celle-ci via le ruban,
• Cliquer sur "Paramètres de la stratégie de gestion des informations",

Note : Si vous souhaitez mettre en place une politique de rétention globale, il existe une interface au niveau de l'administration de la collection de sites nommée "Stratégie de la collection de sites".

Par contre, dans un site de publication par défaut, il est uniquement possible de positionner cette rétention sur un type de contenu.
Afin de pouvoir l'utiliser au niveau site ou bibliothèque/liste, il faudra activer la fonctionnalité de collection de sites nommée "Rétention basée sur des bibliothèques et des dossiers":

Il sera à présent possible de définir une politique de rétention au niveau bibliothèque ou dossiers:

 

Puis de créer la rétention qui convient sur ce contenu:

 

SHAREPOINT 2010 : Event ID 6482 - Application server administration job failed for service instance

Aujourd'hui, un court article sur un problème rencontré chez un client lors de la suppression d'une solution SharePoint 2010 fournie par un éditeur tierce.

De nombreuses erreurs pas très rassurantes sont apparues dans le journal d'évènement d'un des serveurs frontaux.

 

Après quelques recherches, le problème provient de la définition des timer qui est en erreur sur le frontal incriminé. Pour corriger ce problème, il faudra purger la définition des timer en suivant la méthodologie suivante: 

• Arrêter le service Windows nommé « SharePoint 2010 Timer »,
• Se placer dans le répertoire C:\ProgramData\Microsoft\SharePoint\Config\{GUID} (sur un Windows Server 2008). Si vous avez plusieurs GUID, entrez dans le répertoire ayant pour date de modification celle de l'arrêt du service de Timer SharePoint,
• Copier le fichier « cache.ini » pour en garder une trace au cas où cela se passerait mal,
• Supprimez tous les fichiers XML compris dans ce répertoire (correspondant aux définitions des timerjob),
• Ouvrez le fichier « cache.ini » avec Notepad et positionner « 1 » à l’intérieur,
• Relancer le service Windows nommé « SharePoint 2010 Timer ».

Lorsque le service de timer sera relancé, la liste des définitions sera aussitôt redescendue dans le répertoire et le fichier cache.ini sera modifié automatiquement. Vous pourrez vérifier que le "1" n'est plus présent dans ce fichier.

SHAREPOINT 2010 : Modification claims provider

Cette semaine je suis tombé sur un petit problème lors de l'utilisation d'un custom claim provider dans SharePoint 2010.

 

Contexte
Disposant, d'une authentification par ADFS sur une web application, je souhaitais tester le très bon provider disponible sur CodePlex nommé "LDAPCP".

Pour ceux qui ne connaissent pas, il est disponible pour SP2010 et SP2013 à l'adresse suivante : http://ldapcp2010.codeplex.com/.
L'avantage de ce custom provider est qu'il permet de pouvoir résoudre les noms dans les people picker  de SharePoint lorsque vous utilisez un provider ADFS (ce qui n'est pas possible nativement...).

 

Problème
Pour l'installation, aucun problème, il suffit de suivre la documentation et ainsi de modifier votre "SPTrustedIdentityTokenIssuer" dans SharePoint en mettant à jour le "ClaimProviderName".
Par contre, le problème survient lorsque vous souhaitez désinstaller un custom claim provider et revenir sur le natif de SharePoint...Il semble que vous soyez obligé de supprimer votre "SPTrustedIdentityTokenIssuer" puis de le recréer.
Autant dire, dans le meilleur des cas, cela fera quelques minutes à s'amuser!

 

Solution de contournement
Heureusement, il est possible de modifier votre "SPTrustedIdentityTokenIssuer" sans pour autant le recréer à chaque fois que vous voulez changer de claims provider.
Pour cela, il faudra utiliser les commandes PowerShell pour SharePoint suivantes qui utilisent la reflection pour réutiliser le claim provider standard de SharePoint :

$issuer = Get-SPTrustedIdentityTokenIssuer XXXX
$tissuerGetType().GetField("m_ClaimProviderName","NonPublic,Instance").SetValue($ti, $null)
$issuer.Update()

 

J'ai réalisé ceci sur ma plateforme de développement SP2010 et cela a fonctionné à merveille.
Par contre, je ne pense pas que ceci soit supporté sur MS dans le cas d'une plateforme de production chez un client.

 

SHAREPOINT : SPListItem incompatible avec un site de publication

Aujourd'hui un article rencontré sur un site SharePoint utilisant les fonctionnalités natives de publication.

 

Problème : Lors de l'accès à une page du site utilisant la fonctionnalité de publication, l'erreur suivante apparaît: "Invalid SPListItem. The SPListItem provided is not compatible with a Publishing Page."

 

Solution : La solution la plus simple reste de désactiver pour réactiver les fonctionnalités de publication au niveau collection de sites et sites (Scope "Site" et "Web").

Si cette solution ne fonctionne pas, vous pourrez passer les commandes PowerShell pour SharePoint permettant de reparamétrer la publication sur le site:

$web = get-spweb http://monsharepoint/monsite
$correctId = $web.Lists["Pages"].ID
$web.AllProperties["__PagesListId"] = $correctId.ToString()
$web.Update()
$web.AllProperties["__PublishingFeatureActivated"] = "True"
$web.Update()
 

INFOPATH : Filtrer connexion de données

Aujourd'hui un article sur une optimisation de formulaires InfoPath! Dans 90% des cas, les concepteurs de formulaires InfoPath vont chercher des informations dans des listes ou bibliothèques SharePoint (liste des clients, projets, produits, fournisseurs, références,...).

 

Dans la plupart des cas d'utilisation, tout se passe très bien. Mais dans certaines configurations, l'utilisateur peut rencontrer de gros problèmes de performances lors de la récupération de données:

• Connexion internet limitée,
• Très grand nombre d'éléments à récupérer.

 

La solution la plus simple reste de filtrer les résultats à renvoyer à l'aide d'une zone de texte de recherche ou d'une barre de lettre : A, B, C, D,...

 

Une fois la méthode de filtre créée, il sera nécessaire de filtrer la source de données.

Pour se faire, il ne faudra pas utiliser la connexion de données vers une bibliothèque ou liste SharePoint proposée nativement par InfoPath.

Mais plutôt une connexion de données en mode "réception de données" de type "Service web REST" (voir ci-dessous) :

 

 

 

 

Cette méthode de connexion de données permettra d'utiliser le service "listdata.svc" (API Rest) qui est proposé nativement depuis SharePoint 2010.

Pour les novices, ce service permet d'accéder aux données de votre liste  SharePoint nommée par exemple "Produits" en utilisant l'url suivante : http://monsite/_vti_bin/listdata.svc/Produits . Vous pourrez vérifier en tapant l'url dans votre navigateur que SharePoint vous renvoie le résultat au format XML.

 

Techniquement le but sera de modifier l'url de la connexion de données à l'aide des méthodes de filtre proposées par le service REST.

Vous trouverez quelques exemples basiques d'utilisation sur le site de Microsoft : http://msdn.microsoft.com/fr-fr/library/ff521587(v=office.14).aspx

 

Il sera donc nécessaire de modifier l'url de connexion afin de filtrer les valeurs renvoyées. Par exemple, si vous placez un  bouton à côté de votre zone de texte de recherche dans InfoPath, il suffira de rajouter une action sur celui-ci.

Cette action aura pour but de modifier l'url d'accès à la connexion de données de la façon suivante:

concat("http://monsite/_vti_bin/listData.svc/Produits?$filter=substringof('", txtZonedetexteRecherche, "',tolower(NomColonneSharePoint)) eq true")

 

où:

• "txtZonedetexteRecherche" correspond au champ du formulaire InfoPath permettant de réaliser le filtre,
• "NomColonneSharePoint" correspond au nom de la colonne permettant de réaliser le filtre dans la liste "Produits".

INFOPATH : Conversion PDF

Une demande récurrente au niveau des formulaires InfoPath reste la possibilité de convertir simplement les formulaires d'entreprise vers le format PDF.

 

Cette fonctionnalité est incluse nativement dans les formulaires InfoPath client lourd (ouverts via Microsoft Office InfoPath) avec le possibilité de réaliser des exports en XPS ou PDF.

 

Par contre, du côté InfoPath Forms Services (formulaire ouvert depuis une page Web via SharePoint Server), il n'existe pas fonctionnalité offerte par défaut. Mais cela ne veut pas dire pour autant que cela n'est pas possible!

 

Il est possible d'utiliser bien-sûr des composants tiers (notamment Muhimbi) qui réalisent très bien ce genre d'action.

 

Nous allons plutôt nous intéresser à un service souvent méconnu qui est inclus dans SharePoint Server : "Word Automation Service".

Dixit la page MSDN : "Word Automation Services assure la conversion sans assistance du côté serveur de documents dans des formats pris en charge par l’application cliente Microsoft Word.

En d’autres termes, Word Automation Services réplique pour le serveur la fonctionnalité « Enregistrer sous » de l’application cliente Word."

 

Concrètement il permet de convertir des les formats d'entrée suivants:

• Documents au format de fichier Open XML (.docx, .docm, .dotx, .dotm)
• Documents Word 97-2003 (.doc, .dot)
• Fichiers RTF (.rtf).
• Page Web à fichier unique (.mht, .mhtml).
• Documents Word 2003 XML (.xml)
• Document XML Word (.xml)

Les formats de sortie pourront être XPS ou PDF.

 

Il existe notamment une limitation dans SharePoint 2010. Ce service ne peut fonctionner que sur des fichiers qui sont physiquement stockés (pas de pris en compte des flux).

 

Voici un très bon tutorial permettant de convertir un formulaire InfoPath en PDF via le passage par un document Word : http://www.bizsupportonline.net/infopath2010/videos/convert-infopath-word-pdf-sharepoint-2010.htm

 

 

Remarque importante : SharePoint 2013 inclut de nouvelles fonctionnalités intéressantes au niveau de ce service :

• Fonctionnalité de conversion à la demande ajoutée en supplément de la conversion via le travail du minuteur,
• Possibilité de convertir des flux (uniquement dans le cas de la conversion à la demande évidemment).

Ainsi, il est à présent possible de convertir directement le formulaire InfoPath sans passer par son équivalent en modèle Word. Il sera possible de passer le flux HTML du formulaire (via la transformation du XSL et du XML) au service afin de générer la conversion en mode PDF!

 

Bonnes conversion!

SHAREPOINT : ADFS Provider Groupe AD

Aujourd'hui, un post concernant le provider d'authentification ADFS sur un environnement SharePoint. Cette technique est souvent utilisée dans le cadre d'extranet afin de fédérer l'authentification (Google, Facebook, AD externe,...).

Classiquement, certains clients mappent uniquement le champs LDAP sur le claim type "Email" afin que les utilisateurs puissent se connecter.

Seulement, avec du recul, cette configuration n'est pas suffisante car vous vous rendrez compte que les groupes AD ne pourront pas être ajoutés dans SharePoint :

 

Afin de pouvoir ajouter les groupes AD, il vous faudra modifier la partie de confiance ADFS et le trusted issuer associé à SharePoint de la façon suivante:

 

Modification règles sur la partie de confiance ADFS :

 

- Se positionner sur l’interface mappant le champ « Email » au claimtype « Email ».

- Ajouter et mapper le champ LDAP « Token groups unqualified names » sur le claimtype « Role »,

- Ajouter et mapper le champ LDAP « User-Principal-Name » sur le claimtype « UPN ».

 

Le résultat doit être le suivant:

 

 

 

Côté SharePoint 2010– Modification de l’issuer :

Il faudra se connecter sur un des serveurs et lancer la commande PowerShell pour SharePoint suivante :

$issuer = Get-SPTrustedIdentityTokenIssuer
$issuer.ClaimTypes.Add("http://schemas.microsoft.com/ws/2008/06/identity/claims/role")
$map=New-SPClaimTypeMapping "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" –SameAsIncoming
$issuer.AddClaimTypeInformation($map)
$issuer.Update()

Get-SPTrustedIdentityTokenIssuer

 

 

Le résultat sera le suivant:

 

 

 

 

 

A présent, suite à ces modifications, vous aurez accès au "Rôle" dans l'interface de sélection "ADFS Provider" de SharePoint :

 

 

 

Il faudra sélectionner la section rôle pour ajouter le groupe. Vous pourrez ainsi constater que le claims associé aux groupes AD se présente de la façon suivante "c :0-.t|Provider name":

 

 

 

 

SHAREPOINT : Nettoyage comptes profil utilisateur

Le service de profil utilisateur de SharePoint stocke les informations sur les utilisateurs dans un emplacement centralisé. Les fonctionnalités sociales exploitent ces informations pour créer des interactions productives et rendre plus efficace la collaboration entre utilisateurs. Pour mettre en service des sites Mon site, activer des fonctionnalités sociales telles que les liens de mise en réseau et les échanges de News ou bien créer et distribuer des profils entre plusieurs sites et batteries de serveurs, vous devez utiliser l’application de service de profil utilisateur.

 

Techniquement, des synchronisations sont effectuées via FIM (synchro bilatérale ou non) depuis l'Active Directory de l'entreprise (en SP2013, un nouveau mode de synchro en export depuis l'AD est fourni : plus rapide).

 

Lorsque les comptes sont supprimés dans l'AD, le service de profil utilisateur SharePoint supprimera ces comptes après quelques synchronisations. Seulement, ceci c'est la théorie...

Régulièrement, certains profils restent accessibles dans les profils du service.

Après une petite enquête, il s'avère que cela provient du fait que le timer job "My site cleanup job" est souvent désactivé sur les fermes SharePoint afin d'éviter toute suppression intempestive.

 

Il existe néanmoins des commandes PowerShell pour SharePoint permettant de réaliser le ménage dans les comptes de la base de profil:

 

# Récupération de l'ID du service UPS

Get-SPServiceApplication

 

# Sélection du service UPS

$upa = Get-SPServiceApplication "GUID-UserProfileService"

 

# Fournit la liste des utilisateurs qui pourront être supprimés (action en lecture)

Set-SPProfileServiceApplication $upa -GetNonImportedObjects $true

 

# Suppression des profils supprimés de l'AD (action irréversible)

Set-SPProfileServiceApplication $upa -PurgeNonImportedObjects $true

 

 

Après quelques synchronisations de profils, les comptes supprimés de l'AD vont disparaitre de votre base de profil.

Attention néanmoins à bien qualifier ceci sur une plateforme de développement ou de validation car la dernière commande est irréversible.

SHAREPOINT 2010 : Office documents prompt d'authentification

Aujourd'hui, un article concernant SharePoint 2010 et son utilisation en mode claims.

Sur une web application comprenant un fournisseur d'authentification de type ADFS, nous avons récemment rencontré un problème lors de l'ouverture des documents office.

Problématique : la mire d'authentification ADFS était affichée à chaque ouverture des documents.

Afin d'identifier le problème, notre ami "Fiddler" a été d'une grande utilité puisqu'il a permis de détecter une jolie erreur 403 Forbidden dans les requêtes http.

En utilisant un outil de gestion des cookies (cookies manager de FF par exemple), il s’avère que le cookie généré est en mode d'expiration "Fin de session".
A cause de cela, lors de l’ouverture d’un document Office, le contexte est perdu et un nouveau cookie est nécessaire.

Il est donc nécessaire de passer avec cookie FedAuth en expiration fin de date (« End of date ») :
 

 

Pour cela, il faudra lancer les commandes suivantes sur le serveur SharePoint 2010  (puis réaliser un IISRESET sur chaque frontaux) :

 

 

 

Note : Par défaut la durée de validité du cookie est définie à 1h à partir de la connexion. Cette valeur peut être modifiée si nécessaire.
 

Voici un très bon article du Technet sur le STS permettant de le configurer finement : http://msdn.microsoft.com/fr-fr/library/hh147183(v=office.14).aspx

 

SharePoint 2010 : Service tracing ne fonctionne pas

Aujourd'hui un post concernant la configuration du service de logs dans SharePoint 2010.

Si la ferme SharePoint est mal configurée, vous pouvez être amené à rencontrer les dysfonctionnements suivants:

1. Les fichiers de logs sont générés mais restent vides avec une taille de 0Kb,
2. Les rapports Web Analytics ne sont pas générés pour les sites. En fait, les fichiers d'usage ne sont pas générés dans le répertoire du serveur.

 

Pour contourner ce problème, il faudra tout d'abord réaliser les vérifications d'usage:

• Vérifier le compte faisant tourner le service de tracing,
• Vérifier que ce service Windows est démarré sur chaque WFE de votre ferme.

 

Une fois ces vérifications de bon sens réalisées, il faudra s'assurer que le compte utilisé appartient au groupe Windows "Performance Log Users" (ou en bon Français, le groupe "Utilisateurs du journal de performances") . Ceci est obligatoire afin que le service de trace puisse fonctionner correctement.

SharePoint 2010 : Permission groupe AD non immédiat

Lors de l'utilisation quotidienne SharePoint 2010, vous pouvez être amené à vouloir ajouter un groupe AD dans un groupe SharePoint afin de faciliter l'administration des accès aux sites.

Si vous utilisez le mode d'authentification " Claims" sur votre Web application, vous pourrez être surpris du fait qu'un membre de votre groupe AD n'ait pas accès au site immédiatement au site, ni 1h après d'ailleurs...

 

Après quelques recherches, il s'avère que ce fonctionnement provient du "token-timout" utilisé par la méthode d'authentification "Claims".

Par défaut, cette valeur est définie à 1440 minutes (soit 24 heures)... Ce qui signifie que les modifications effectuées sur les membres d'un groupe AD ne sont pas répercutées en temps réel dans notre cher SharePoint.

 

Pour obtenir la valeur en vigueur sur votre ferme:

stsadm -o getproperty -propertyname token-timeout

Pour modifier temporairement cette valeur, vous pouvez utiliser la commande suivante:

stsadm -o setproperty -propertyname token-timeout -propertyvalue

 

 

SHAREPOINT 2010 : Résultat recherche lecture seule

Aujourd'hui, un petit point intéressant sur la recherche SharePoint 2010.

Certains clients remontent un problème contraignant : sur quelques postes, les résultats de recherche fournis par SharePoint ne permettent d'ouvrir les documents Office qu'en mode "Lecture seule".

Ce qui peut-être contraignant dans certains cas d'utilisation!

 

En fait, ceci dépend du paramétrage de Internet Explorer du PC.

Pour corriger ceci, il faut réaliser les actions suivantes:

• Cliquer sur les "options internet",
• Dans l'onglet "Programmes", cliquer sur "Module complémentaire",
• Se positionner sur le module "Office document cache Handler" puis l'activer.
• Fermer et rouvrir IE.

 

 

 

Ainsi les documents de recherche s'ouvriront en mode lecture ou modification.

 

 

Le même problème peut survenir sur Firefox.

Pour pouvoir modifier un document issu de la recherche sur Firefox, il faut réaliser l'action suivante:

• Taper "about:config" dans la barre des tâches et confirmer l'alerte de sécurité,
• Chercher la clé "browser.helperApps.deleteTempFileOnExit". Si celle-ci n'existe pas, il faut faire un clic droit puis "Nouveau" puis valeur booléenne,
• Positionner la valeur à "False"
• Fermer le navigateur puis le rouvrir.

 

 

Attention, ces modifications doivent être réalisées sur chaque poste de travail, ce qui est légèrement contraignant sur un parc machine développé!

Une option reste de modifier le XSL des résultats de recherche afin de modifier le lien renvoyé par la page en appelant la même URL que lors du clic d'un élément depuis une bibliothèque SharePoint.

SHAREPOINT 2010 : Service SharePoint Administration

Aujourd'hui, un post sur un problème rencontré chez un client sur une plateforme SharePoint 2010.

Le service SharePoint Administration s'est retrouvé éteint sur les serveurs de la ferme.

La tentative de démarrage de ce service envoyait une erreur de type 1053. Le service s'était donc arrêté de lui-même.

Pour rappel, ce service doit impérativement être démarré sur les serveurs d'une ferme.

 

Après diverses recherches, il s'avère que ce problème survient sur des serveurs SharePoint ayant le SP1 + la CU de février 2012.

Le problème provient de l'installation de la KB 2677070. Cette mise à jour permet la mise à jour automatique des certificats racines du serveur.

 

Le passage de cette KB sur une ferme SharePoint 2010 en CU de février 2012 n'ayant pas accès à internet entraine ce blocage.

Il existe donc 3 solutions:

1. Modifier les règles du proxy pour autoriser les connexions aux URLs permettant d'actualiser les certificats,
2. Désinstaller la KB 2677070 si vous jugez que les serveurs concernés ne sont pas concernés par la faille de sécurité corrigée par ce patch car les serveurs n'ont pas accès à internet,
3. Si vous considérez que cette mise à jour est nécessaire et que l'ouverture du proxy n'est pas envisageable, il faudra bloquer la mise à jour des certificats racines via  les GPO en décochant la case "Automatically update certificates in the Microsoft Root Certificate Program (recommended)"

 

 

 

INFOPATH : Migration SharePoint 2010

Pour faire écho au post précédent qui traite de la migration de formulaires InfoPath vers SharePoint 2007 (correction des urls de connexions de données), voici à présent un article qui détaille la procédure à suivre pour réaliser ceci sur SharePoint 2010.

Il existe à présent dans SharePoint 2010 des commandes Powershell qui permettent de modifier les URL stockées en dur dans les modèles de formulaire InfoPath ( essentiellement au niveau des connexions de données), les fichiers UDC et les types de contenus afin de garantir que les modèles de formulaire continuent à fonctionner correctement. Ces commandes peuvent être exécutées dans les cas suivants:

• Migration de SharePoint 2007 à SharePoint 2010,
• Changement d'alias de votre ferme SharePoint 2010 ou migration de la collection de sites sur une web application différente.

Il est donc possible de corriger les dysfonctionnements causés par ce genre de modifications en utilisant les commandes suivantes grâce à l'éditeur PowerShell pour SharePoint 2010 :

Get-SPWebApplication http://alias2010 | Update-SPInfoPathUserFileUrl –find http://alias2007 –replace http://alias2010

La commande ci-dessus est lancée sur une application web. Il est possible à l'aide de cette commande de préciser de même une base de contenu ou une collection de sites.

Voici le lien vers la description du technet : http://technet.microsoft.com/en-us/library/ff607651

Vous y trouverez les arguments supplémentaires à cette commande pouvant être utilisés : dont notamment "Confirm" permettant de valider le choix ou "Scan" permettant de réaliser un tour à blanc sur les formulaires à modifier.

SHAREPOINT 2010 : Enregistrer site en tant que modèle

Récemment, il m'est arrivé de vouloir enregistrer un site en tant que modèle sous SharePoint 2010.

Le but de cette manœuvre est de pouvoir utiliser un site dédié à InfoPath sur une autre plateforme SharePoint.

Bizarrement, cette fonctionnalité est parfois absente de certains sites. Cette situation provient du fait qu'une fonctionnalité de collections de sites est activée : "Infrastructure de publication SharePoint Server".

Une fois que cette fonctionnalité est désactivée, le lien réapparait par magie et il est ainsi possible d'enregistrer son site en tant que modèle.

Facile, mais encore fallait-il le savoir...