SHAREPOINT 2013 : Fusion des logs

Lors de phases de debug ou de problèmes sur une plateforme SharePoint, vous pouvez être amené à vouloir rechercher la source du problème dans les logs.

 

Cette opération peut rapidement devenir fastidieuse dans le cas de topologies multi-serveurs car il est alors nécessaire d'aller rechercher dans les fichiers  de logs sur chacun des serveurs de votre ferme.

 

Il existe une solution basique nommée le "Developer Dashboard" (disponible uniquement sous SP2013). Cet outil des développeurs permet de récupérer les logs ULS (voir plus de détails dans un post précédent : http://rmatayron.blogspot.fr/2013/04/sharepoint-2013-developer-dashboard.html).

Cette solution implique néanmoins que le problème soit reproductible.

 

 

Pour les autres cas, une commande PowerShell permet de simplifier cette recherche : "MergeSPLog". Cette commande permet de fusionner les logs présents sur chaque serveur selon divers critères.

 

L'utilisation suivante permettra par exemple de sélectionner les logs du 27 août compris entre 16h00 et 16h15:

Merge-SPLogFile -Path "E:\Temp\FusionLog-20130827-1600-1615.log" -StartTime "27/08/2013 16:00:00" -EndTime "27/08/2013 16:15:00"

Cette commande peut de même être utile  pour réaliser du monitoring sur votre SharePoint. Par exemple, vous pourrez tracer tous les évènements avec une haute importance détectés dans les logs:

Merge-SPLogFile -Path "E:\Temp\FusionLogHigh.log" -Overwrite -Level High

 

Note : Cette commande fonctionne également sur SharePoint 2010.

SharePoint 2013 : Host Name Site Collection - HNSC

Aujourd'hui un petit article sur une fonctionnalité très intéressante dans SharePoint 2013 nommée le Host-Name Site Collections (où HNSC).
A vrai dire, ce HNSC n'est pas une nouveauté puisqu'il pouvait déjà être utilisé avec SharePoint 2010. Malgré tout celui-ci n'était pas utilisé du fait de ces nombreuses limitations (pas de chemin gérés sur la web application,...).

 

Le principe :

Les HNSC permettent d'assigner un alias DNS différent à différentes collections de sites dans une même web application.
La granularité de nommage est donc modifiée. Vous pourrez par exemple pouvoir utiliser les alias contosoUK, contosoFR, contosoIT, contosoES pour ces 4 collections de sites sur une même web application!

 

Voila de quoi repenser aisément de nombreuses architectures mises en place jusqu'à présent! L'une des plus grandes limitations de SharePoint vient de tomber. Cette nouvelle fonctionnalité assure donc une grande liberté de nommage.

Dixit Microsoft, son utilisation avec succès dans O365 a permis d'optimiser les fonctionnalités pour cette topologie : Host-named site collections are the preferred method to deploy sites in SharePoint 2013. Because the Office 365 environment uses host-named site collections, new features are optimized for these site collections and they are expected to be more reliable.

 

Microsoft recommande donc officiellement l'utilisation des HNSC pour la configuration de nos fermes SharePoint 2013.
Voir le technet officiel : http://technet.microsoft.com/en-us/library/cc424952.aspx

Avantages :

• Optimisation des serveurs web (resources liberées) du fait de la réduction du nombre de pool et de site web IIS.
• Plus grande flexibilité car chaque collection de sites peut avoir son propre alias. En réfléchissant comme auparavant Microsoft supporte uniquement 20 applications web par fermes (avec 5 zones par web application maximum pour être précis). Cela ne laissait pas beaucoup d'alias disponible. A présent, vous pourrez créer des milliers de collections de sites dans une seule web application avec leur propre alias.

Inconvénients :

• Toutes les commandes doivent être réalisées en PowerShell (pas d'interface),
• Les sites libre service ne fonctionnent pas nativement avec cette fonctionnalité. Il faudra pour cela s'orienter vers le provider personnalisé de "Wictor Wilen" : http://www.wictorwilen.se/sharepoint-specifying-content-database-for-new-site-collections-when-using-host-named-site-collections

 

 

Prudence: 

• Il faudra penser à appliquer le fameux best practice de SharePoint : Créer une collection de site à la racine de votre application web. Si cela n'est pas réalisé, la recherche ne fonctionnera pas correctement.
• Pour passer d'une "Path Based Site Collection" (ancienne méthode) à une "Host Named Site Collection", il faudra réaliser un backup de chaque site et le restaurer via une commande PowerShell.
• En théorie donc, il serait possible de regrouper tout les contenu dans une seule application web SharePoint. Cela n'est que de la théorie, car en pratique il faut prendre compte dans votre architecture des éléments suivants:
• Modifications dans le web.config entrainant un indisponibilité pour toute l'application web,
• Pas de possibilité d'utiliser différents providers d'authentification car ceux-ci sont positionnés au niveau de l'application web,
• Sécurité pour les pools d'application (par exemple pool différent pour les sites personnels),

INFOPATH 203 : Personnalisation formulaire de liste

Aujourd'hui un petit post relatif à InfoPath 2013 dans SharePoint suite à un problème remonté par un utilisateur.

 

Problème :

Une liste personnalisée est créée dans une collection de sites dans SharePoint 2013.

Ensuite, le formulaire de liste est modifiée via InfoPath 2013 (via l'action "Customize form" dans le ruban de la liste). Le formulaire est publié dans la bibliothèque afin de prendre en compte la publication.

Lors de la tentative suivante de modification du formulaire de liste à l'aide d'InfoPath, le message d'erreur suivant apparait à l'ouverture du formulaire:

 

InfoPath cannot open the following form:

http://intranet/sites/Processus/Lists/MaListeCustom/Item/template.xsn

The file is not a valid XML document.
DTD is prohibited.

 

Solution :

Techniquement, cette erreur survient lorsque vous utilisez une collection de sites SharePoint (ici "sites/Processus") non située à la racine de la web application.

Si vous souhaitez corriger cette erreur, il faudra obligatoirement créer une collection de sites à la racine de la web application ("/"). Cela vous permettra de pouvoir modifier à nouveau le formulaire de liste (même si cette collection de sites racine ne sert à rien).

Cela fait partie du comportement par défaut d'InfoPath Forms Services depuis SharePoint 2007, qui nécessite pour la publication de disposer d'une collection de sites racine.
La résolution est simple mais vous permettra d'économiser de nombreuses heures de debug...