Planifier des collections de sites nommées par l’hôte (SharePoint Server 2010)

  • Article

 

S’applique à : SharePoint Foundation 2013, SharePoint Server 2013

Dernière rubrique modifiée : 2016-11-30

Dans cet article :

  • À propos des collections de sites nommées par l’hôte

  • À propos des en-têtes de l’hôte

  • Créer une collection de sites nommée par l’hôte

  • Créer par programme une collection de sites nommée par l’hôte

  • Utiliser des chemins d’accès gérés avec des collections de sites nommées par l’hôte

  • Exposer des sites nommés par l’hôte via HTTP ou SSL

  • Configurer SSL pour des collections de sites nommées par l’hôte

  • Utiliser des collections de sites nommées par l’hôte avec l’arrêt de SSL hors zone

Microsoft SharePoint Server 2010 prend en charge les collections de sites basées sur le chemin d’accès et les collections de sites nommées par l’hôte. La principale différence entre les collections de sites basées sur le chemin d’accès et les collections de sites nommées par l’hôte réside dans le fait que toutes les collections de sites basées sur le chemin d’accès dans une application Web partagent le même nom d’hôte (nom DNS), tandis qu’un nom DNS unique est affecté à chaque collection de sites nommée par l’hôte dans une application Web.

Les collections de sites basées sur le chemin d’accès offrent une solution d’hébergement d’entreprise dans laquelle toutes les collections de sites partagent le même nom d’hôte de l’application Web. Dans un déploiement basé sur le chemin d’accès, il peut y avoir une seule collection de sites à la racine de l’application Web et, au sein de celle-ci, d’autres collections de sites sous les chemins d’accès gérés.

Les collections de sites nommées par l’hôte fournissent une solution d’hébergement Web évolutive dans laquelle chaque collection de sites est affectée à un nom DNS unique. Dans un déploiement d’hébergement Web, chaque collection de sites nommée par l’hôte possède sa propre URL de nom d’hôte de redirection vers un microsite, telle que http://customer1.contoso.com, http://customer2.contoso.com ou http://www.customer3.com.

SharePoint Server 2010 apporte deux améliorations significatives aux collections de sites nommées par l’hôte : la possibilité d’utiliser des chemins d’accès gérés avec les collections de sites nommées par l’hôte et la possibilité d’utiliser un arrêt de SSL hors zone avec les collections de sites nommées par l’hôte.

À propos des collections de sites nommées par l’hôte

Les fournisseurs d’hébergement Web fournissent à leurs clients un espace de serveur Web permettant d’héberger leurs propres sites Web. En règle générale, dans un environnement SharePoint Server 2010 basé sur le chemin d’accès, ces sites seraient affectés à https://www.contoso.com/sites/customer1, https://www.contoso.com/sites/customer2, etc. Toutefois, les clients d’hébergement Web souhaitent généralement que leurs sites Web soient disponibles sur un nom de domaine de redirection vers un microsite, tel que http://customer1.contoso.com, http://customer2.contoso.com, etc.

Une façon de prendre en charge cette demande des clients consiste à fournir à chaque client sa propre application Web et à affecter le nom DNS unique du client à l’application Web. Toutefois, les applications Web SharePoint Server 2010 ne sont pas aussi évolutives que les collections de sites SharePoint Server 2010. SharePoint Server 2010 prend en charge les collections de sites nommées par l’hôte, ce qui évite de créer des applications Web individuelles pour chaque client. L’étendue des collections de sites nommées par l’hôte peut atteindre plusieurs milliers d’unités, car elles peuvent toutes exister dans une même application Web tout en offrant des fonctionnalités de dénomination de redirection vers un microsite.

Étant donné que les collections de sites nommées par l’hôte possèdent une URL unique, elles ne prennent pas en charge les mappages des accès de substitution et sont toujours censées se trouver dans la zone Par défaut. Si vous devez prendre en charge des collections de sites répondant à plusieurs URL de nom d’hôte, songez à utiliser des collections de sites basées sur le chemin d’accès avec les mappages des accès de substitution au lieu de collections de sites nommées par l’hôte. Vous devez envisager plusieurs options de configuration supplémentaires lors de la mise en service d’un nouveau site SharePoint Server 2010. La spécification du modèle de site approprié pendant la création du site détermine les composants WebPart préconfigurés et les autres éléments d’interface utilisateur disponibles sur le nouveau site. Dans un scénario d’hébergement, il est probable que vous souhaitiez sélectionner un modèle de site d’équipe (valeur « STS#0 » lors de la création du site) ou un site vide dépourvu de composants WebPart ou de listes prédéfinies (valeur « STS#1 »). En outre, pensez à spécifier des quotas de site sur chaque collection de sites nouvellement mise en service.

À propos des en-têtes de l’hôte

Les en-têtes de l’hôte désignent la partie du protocole HTTP qui indique au serveur Web le nom DNS du site auquel le client se connecte. Vous pouvez appliquer des en-têtes de l’hôte à deux niveaux différents dans SharePoint Server 2010 :

  • niveau de l’application Web (site Web IIS) ;

  • niveau de la collection de sites.

Il est important de comprendre la différence entre ces deux niveaux. Les en-têtes de l’hôte au niveau du site Web IIS sont uniquement destinés aux collections de sites basées sur le chemin d’accès. Les en-têtes de l’hôte au niveau de la collection de sites sont uniquement destinés aux collections de sites nommées par l’hôte. Dans la plupart des cas, l’application d’une liaison d’en-tête de l’hôte au niveau du site Web IIS empêche d’accéder aux collections de sites nommées par l’hôte par le biais du site Web IIS. En effet, les services Internet (IIS) ne répondent pas aux demandes liées aux noms d’hôte qui diffèrent de la liaison d’en-tête de l’hôte.

Les collections de sites basées sur le chemin d’accès et les collections de sites nommées par l’hôte peuvent coexister dans la même application Web et peuvent se trouver dans plusieurs applications Web. Pour que les deux types de collections de sites soient accessibles aux utilisateurs, ne placez pas de liaisons d’en-tête de l’hôte sur le site Web IIS affecté à la zone Par défaut de votre application Web si celle-ci comporte des collections de sites nommées par l’hôte. Vous pouvez appliquer des liaisons d’en-tête de l’hôte aux sites Web IIS dans les autres zones de votre application Web. Cela vous permet d’utiliser la zone Par défaut avec les collections de sites nommées par l’hôte tout en recourant à la fonctionnalité de mappage des accès de substitution dans les autres zones pour les collections de sites basées sur le chemin d’accès.

Vous pouvez modifier manuellement les liaisons d’en-tête de l’hôte sur le site Web IIS à partir du Gestionnaire IIS, mais cela n’est pas recommandé. Aucune modification apportée à l’aide du Gestionnaire IIS n’est enregistrée dans SharePoint Server 2010. Si SharePoint Server 2010 essaie de mettre en service un site Web IIS sur un autre ordinateur dans la batterie de serveurs pour les mêmes application Web et zone, la liaison d’en-tête de l’hôte d’origine est utilisée à la place de la liaison modifiée. Si vous souhaitez modifier une liaison existante pour un site Web IIS, supprimez l’application Web de la zone, puis étendez de nouveau l’application Web dans la zone avec la liaison à utiliser.

Créer une collection de sites nommée par l’hôte

Vous devez utiliser Windows PowerShell pour créer une collection de sites nommée par l’hôte. Vous ne pouvez pas utiliser l’application Web Administration centrale de SharePoint Server 2010 pour créer une collection de sites nommée par l’hôte, mais vous pouvez recourir à l’Administration centrale pour gérer la collection de sites après l’avoir créée.

Vous pouvez créer une collection de sites nommée par l’hôte à l’aide de l’applet de commande New-SPSite Windows PowerShell avec le paramètre -HostHeaderWebApplication, comme indiqué dans l’exemple suivant :

  1. Pour créer une collection de sites nommée par l’hôte à l’aide de Windows PowerShell, vérifiez que la configuration minimale requise suivante est satisfaite : Voir Add-SPShellAdmin.

  2. Dans le menu Démarrer, cliquez sur Tous les programmes.

  3. Cliquez sur Produits Microsoft SharePoint 2010.

  4. Cliquez sur SharePoint 2010 Management Shell.

  5. Depuis l’invite de commandes Windows PowerShell (PS C:\>), tapez la commande suivante :

New-SPSite http://host.header.site.url -OwnerAlias DOMAIN\username - 
HostHeaderWebApplication https://servername

Cette opération crée une collection de sites nommée par l’hôte dont l’URL est http://host.header.site.url dans l’application Web SharePoint Server 2010 dont l’URL est https://servername.

Créer par programme une collection de sites nommée par l’hôte

Outre utiliser Windows PowerShell pour créer des sites nommés par l’hôte, vous pouvez recourir au modèle objet SharePoint Server 2010. L’exemple de code suivant crée la collection de sites nommée par l’hôte dont l’URL est http://host.header.site.url dans l’application Web SharePoint Server 2010 dont l’URL est https://servername :

SPWebApplication webApp = SPWebApplication.Lookup(new
Uri("https://www.contoso.com"));
SPSiteCollection sites = webApp.Sites;
SPSite Site = null;
Site = sites.Add("http://hoster.contoso.com", "Site_Title",
"Site_Description", 1033, "STS#0", "contoso\owner",
"Owner_Display_Name", "Owner_Email", "contoso\secondaryowner,
"Secondary_Owner_Display_Name", "Secondary_Owner_Email", true);

SharePoint Server 2010 comprend un ensemble de services Web permettant d’effectuer différentes tâches utilisateur et administratives. L’une de ces tâches administratives consiste à créer une collection de sites. La méthode de service Web CreateSite ne prend pas en charge la création de collections de sites nommées par l’hôte. Une solution de contournement consiste à écrire un service Web qui encapsule l’exemple de code API.

Utiliser des chemins d’accès gérés avec des collections de sites nommées par l’hôte

SharePoint Server 2010 autorise la prise en charge des chemins d’accès gérés avec des collections de sites nommées par l’hôte. Les hébergeurs peuvent fournir au même client plusieurs collections de sites partageant le nom d’hôte unique du client, mais différenciées par le chemin d’URL après le nom d’hôte.

Les chemins d’accès gérés pour les collections de sites nommées par l’hôte diffèrent des chemins d’accès gérés pour les collections de sites basées sur le chemin d’accès. Les chemins d’accès gérés pour les collections de sites nommées par l’hôte ne s’appliquent pas aux collections de sites basées sur le chemin d’accès ; de même, les chemins d’accès gérés pour les collections de sites basées sur le chemin d’accès ne s’appliquent pas aux collections de sites nommées par l’hôte. Les chemins d’accès gérés créés pour les collections de sites nommées par l’hôte sont disponibles pour toutes les collections de sites nommées par l’hôte dans la batterie de serveurs, quelle que soit l’application Web dans laquelle se trouve la collection de sites nommée par l’hôte. Vous devez créer une collection de sites racine nommée par l’hôte pour un nom d’hôte avant de créer pour celui-ci une collection de sites à chemin d’accès géré nommée par l’hôte.

Vous pouvez créer un chemin d’accès géré à utiliser avec les collections de sites nommées par l’hôte à l’aide de l’applet de commande New-SPManagedPath Windows PowerShell avec le paramètre -HostHeader, comme indiqué dans l’exemple suivant :

New-SPManagedPath pathname -HostHeader

L’exemple suivant illustre une collection de sites nommée par l’hôte créée au niveau d’un chemin d’accès géré :

New-SPSite http://host.header.site.url/pathname/sitename -OwnerAlias DOMAIN\username -HostHeaderWebApplication https://servername

Exposer des sites nommés par l’hôte via HTTP ou SSL

Les collections de sites nommées par l’hôte utilisent le même schéma de protocole que l’URL publique dans la zone Par défaut de leur application Web. Si vous souhaitez fournir les collections de sites nommées par l’hôte dans votre application Web via HTTP, vérifiez que l’URL publique dans la zone Par défaut de votre application Web est une URL basée sur HTTP. Si vous souhaitez fournir les collections de sites nommées par l’hôte dans votre application Web via SSL, vérifiez que l’URL publique dans la zone Par défaut de votre application Web est une URL basée sur HTTPS.

À la différence d’une version antérieure, SharePoint Server 2010 ne prend pas en charge une collection de sites nommée par l’hôte utilisant simultanément des URL basées sur HTTP et sur SSL. Si certaines collections de sites nommées par l’hôte doivent être accessibles via HTTP, tandis que d’autres doivent être accessibles via SSL, séparez les collections de sites nommées par l’hôte en deux applications Web différentes dédiées au type d’accès correspondant. Dans ce scénario, les collections de sites nommées par l’hôte basées sur HTTP doivent se trouver dans une application Web dédiée à l’accès HTTP et les collections de sites nommées par l’hôte basées sur SSL doivent se trouver dans une application Web dédiée à l’accès SSL.

Configurer SSL pour des collections de sites nommées par l’hôte

Dans les scénarios d’hébergement, les hébergeurs peuvent configurer une application Web unique avec SSL, puis créer plusieurs collections de sites nommées par l’hôte dans cette application Web. Pour qu’un site soit accessible via SSL, un certificat de serveur doit être installé et affecté au site Web IIS. Chaque collection de sites nommée par l’hôte dans une application Web partagera le certificat de serveur unique affecté au site Web IIS.

Les hébergeurs doivent acquérir un certificat générique ou un certificat de nom de substitution lié au sujet, puis utiliser une stratégie d’URL de collection de sites nommée par l’hôte qui correspond à ce certificat. Par exemple, si un hébergeur acquiert un certificat générique *.contoso.com, il doit générer des URL de collection de sites nommée par l’hôte, telles que https://site1.contoso.com, https://site2.contoso.com, etc., pour que ces sites passent avec succès la validation de la navigation via SSL. Toutefois, si les clients requièrent des noms de domaine de second niveau uniques pour leurs sites, l’hébergeur doit créer plusieurs applications Web plutôt que plusieurs collections de sites nommées par l’hôte.

Pour configurer SSL pour des collections de sites nommées par l’hôte, activez SSL lors de la création de l’application Web. Cette opération crée un site Web IIS avec une liaison SSL plutôt qu’avec une liaison HTTP. Une fois l’application Web créée, ouvrez le Gestionnaire IIS et affectez un certificat à cette liaison SSL. Vous pouvez ensuite créer des collections de sites dans cette application Web.

Utiliser des collections de sites nommées par l’hôte avec l’arrêt de SSL hors zone

Étant donné que SharePoint Server 2010 utilise l’URL publique dans la zone Par défaut de l’application Web pour déterminer si les collections de sites nommées par l’hôte seront restituées via HTTP ou SSL, vous pouvez désormais utiliser des collections de sites nommées par l’hôte avec l’arrêt de SSL hors zone. Trois contraintes sont associées à l’utilisation de l’arrêt de SSL avec les collections de sites nommées par l’hôte :

  • L’URL publique dans la zone Par défaut de l’application Web doit être une URL basée sur HTTPS.

  • Le proxy inverse ou l’arrêt de SSL doit conserver l’en-tête de l’hôte HTTP d’origine du client.

  • Si la demande SSL du client est envoyée au port SSL par défaut (443), le proxy inverse ou l’arrêt de SSL doit transférer la demande HTTP déchiffrée au serveur Web frontal sur le port HTTP par défaut (80). Si la demande SSL du client est envoyée à un port SSL autre que le port SSL par défaut, le proxy inverse ou l’arrêt de SSL doit transférer la demande HTTP déchiffrée au serveur Web frontal sur le même port.

Pour utiliser des collections de sites nommées par l’hôte avec l’arrêt de SSL hors zone, configurez votre application Web comme vous le feriez normalement pour l’arrêt de SSL et vérifiez qu’elle satisfait aux contraintes décrites ci-dessus. Dans ce scénario, SharePoint Server 2010 restitue les liens de ses collections de sites nommées par l’hôte dans cette application Web en utilisant HTTPS au lieu de HTTP.