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,...).
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!
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
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),
Aucun commentaire:
Enregistrer un commentaire