Partager via

Architecture et déploiement d'une collection de sites nommée par l'hôte dans SharePoint Server

  • Article

S’APPLIQUE À :oui-img-132013 oui-img-162016 oui-img-192019 oui-img-seÉdition d’abonnement no-img-sopSharePoint dans Microsoft 365

Les collections de sites nommées par l’hôte sont une approche facultative pour déployer des sites dans SharePoint Server. Les utilisateurs qui souhaitent avoir plusieurs collections de sites, chaque collection de sites ayant son propre nom DNS, peut choisir de déployer des collections de sites nommées par l’hôte. Sinon, les utilisateurs doivent déployer des collections de sites basées sur des chemins d’accès.

Découvrez comment planifier et implémenter des collections de sites nommées par l'hôte, ainsi que comment concevoir et gérer des URL.

Architecture et conception pour les collections de sites nommées par l’hôte

Les collections de sites nommées par l'hôte vous permettent d'attribuer un nom DNS unique aux collections de sites. Par exemple, vous pouvez utiliser http://TeamA.contoso.com et http://TeamB.contoso.com. Cet exemple montre que vous devez déployer de nombreux sites avec des noms DNS uniques dans la même application web. Les hébergeurs peuvent également mettre à l'échelle un environnement pour plusieurs clients.

Cet article explique comment implémenter des collections de sites nommées par l'hôte dans une configuration recommandée avec SharePoint Server. Les informations concernant la configuration avancée se trouvent à la fin de cet article : Utilisation de plusieurs applications Web avec des collections de sites nommées par l'hôte.

La configuration recommandée pour le déploiement de collections de sites nommées par l’hôte consiste à placer toutes les collections de sites nommées par l’hôte dans une seule application web, comme illustré dans le diagramme suivant.

Configuration recommandée pour les collections de sites nommées par l'hôte

Diagram that shows recommended configuration for host-named site collections

La configuration recommandée dans le diagramme comprend les éléments suivants :

  • Un pool d'applications pour les collections de sites

  • Une application Web pour les collections de sites hébergées dans le pool d'applications

  • Collection de sites racine (http://webapp.contoso.com).

  • Plusieurs collections de sites nommées par l'hôte pour héberger du contenu avec des exemples de sites :

    • Contenu intranet publié (http://intranet.contoso.com) avec des sous-sites pour les ressources humaines, les installations et les achats.

    • Sites d’équipe (http://teams.contoso.com) avec des sous-sites pour l’équipe 1, l’équipe 2 et l’équipe 3.

    • Mes sites avec des URL de site au format suivant : http://my.contoso.com/personal/<site_name>.

Le nombre de sites dans l’application web et les URL des sites ne sont pas importants pour cet exemple.

Lors de la création d’une application web pour les collections de sites nommées par l’hôte, l’URL de l’application web et la collection de sites racine sont http://<_webapp.contoso.com_>/.

URL de l’application web et de la collection de sites racine.

Cette architecture est recommandée pour déployer des collections de sites nommées par l’hôte, car il s’agit de la même architecture que celle utilisée par l’environnement Microsoft 365. Cette configuration est donc la configuration la plus testée. Les nouvelles fonctionnalités, notamment le modèle d’application et la gestion des demandes, sont optimisées pour cette configuration, et il s’agit de la configuration la plus fiable à l’avenir.

La configuration recommandée n’inclut pas les éléments suivants :

  • Activation d'applications dans des environnements à plusieurs zones

  • Combinaison de collections de sites nommées par l'hôte et de collections de sites basées sur des chemins d'accès (à l'exception de la collection de sites racine).

  • Applications Web multiples avec collections de sites nommées par l’hôte

Collections de sites nommées par l’hôte et collections de sites basées sur des chemins d’accès

Lorsque vous utilisez des collections de sites nommées par l’hôte, un nom DNS unique est affecté à chaque collection de sites dans une application Web. Lorsque vous déployez de nombreuses collections de sites nommées par l’hôte dans une seule application web, vous augmentez la scalabilité de la batterie, car les ressources ne sont pas utilisées pour prendre en charge plusieurs pools d’applications et applications web.

SharePoint Server prend en charge les collections de sites basées sur des chemins d'accès et les collections de sites nommées par l'hôte. Le tableau suivant détaille les différences entre les deux et fournit davantage d'informations sur les collections de sites nommées par l'hôte.

Tableau : Comparaison des collections de sites nommées par l'hôte et des collections de sites basées sur des chemins d'accès

  Collections de sites nommées par l’hôte Collections de sites basées sur des chemins d’accès
Création de sites Vous pouvez utiliser Microsoft PowerShell pour créer des collections de sites nommées par l’hôte. Vous ne pouvez pas utiliser l’Administration centrale pour créer des collections de sites nommées par l’hôte. Vous pouvez utiliser l'Administration centrale ou PowerShell pour créer des collections de sites basées sur des chemins d'accès.
URL Un nom DNS unique est attribué à chaque collection de sites nommée par l'hôte dans une application Web.
Vous pouvez utiliser des zones pour affecter jusqu'à cinq URL aux sites nommés par l'hôte, y compris des URL de redirection vers un microsite.		 Toutes les collections de sites basées sur des chemins d'accès d'une application Web partagent le même nom d'hôte (nom DNS) que l'application Web. Vous pouvez étendre une application Web pour implémenter jusqu'à cinq zones et créer des noms d'hôte différents pour chaque zone. Cependant, le nom d'hôte pour une zone s'applique à toutes les collections de sites dans l'application Web.
Recherche et collection de sites racine Une collection de sites racine est nécessaire pour analyser le contenu dans une application web. Une collection de sites racine peut être une collection de sites à laquelle les utilisateurs ne peuvent pas accéder. En règle générale, une collection unique de sites basée sur des chemins d'accès fait office de collection de sites racine dans une application Web. Vous pouvez utiliser des chemins d’accès managés pour créer d’autres collections de sites au sein de l’application web.
Mappage d’URL Utilisez les commandes PowerShell pour gérer les URL (Set-SPSiteUrl, Remove-SPSiteUrl, Get-SPSiteUrl). Utilisez des mappages des accès de substitution pour gérer les URL.
Création de sites libre-service Vous devez utiliser une solution personnalisée pour la création de sites libre-service avec des collections de sites nommées par l'hôte.
La fonctionnalité de création de site libre-service qui fait partie de l’installation par défaut de SharePoint Server ne fonctionne pas avec les collections de sites nommées par l’hôte.		 Lorsque vous utilisez la fonctionnalité de création de sites libre-service qui fait partie de l'installation par défaut de SharePoint Server, vous créez des sites basés sur des chemins d'accès.
Chemins d'accès gérés Les chemins d'accès gérés pour les collections de sites nommées par l'hôte s'appliquent au niveau de la batterie de serveurs et sont disponibles pour toutes les applications Web.
Vous devez utiliser PowerShell pour créer des chemins d'accès gérés pour les collections de sites nommées par l'hôte.		 Les chemins d'accès gérés pour les sites basés sur des chemins d'accès s'appliquent au niveau de l'application Web.
Vous pouvez utiliser l'Administration centrale ou Microsoft PowerShell pour créer des chemins d'accès gérés pour les collections de sites basées sur des chemins d'accès.

Conception et gestion des URL pour les collections de sites nommées par l’hôte

Les applets de commande PowerShell gèrent les mappages d'URL pour les collections de sites nommées par l'hôte et vous permettent de mapper des URL avec une collection de sites unique :

  • Set-SPSiteUrl — Ajouter ou modifier un mappage d’URL pour un site.

  • Remove-SPSiteUrl — Supprimer un mappage d’URL d’un site.

  • Get-SPSiteUrl— Voir toutes les URL et zones associées pour une collection de sites.

Ces applets de commande fournissent, pour les collections de sites nommées par l’hôte, une fonctionnalité de mappage d’URL semblable au mappage des accès de substitution.

Zones et collections de sites nommées par l’hôte

Les collections de sites nommées par l’hôte sont disponibles dans n’importe quelle zone. Les collections de sites nommées par l’hôte ne sont pas limitées à la zone par défaut. Si nécessaire, vous pouvez implémenter plusieurs zones et utiliser des zones et des collections de sites nommées par l’hôte pour configurer différents paramètres ou stratégies d’authentification.

Notes

Pour utiliser différentes zones, vous devez étendre l’application web existante dans les nouvelles zones.

Vous pouvez attribuer jusqu'à cinq URL à une collection de sites unique en affectant une URL par zone. Même si vous suivez l'architecture recommandée et n'implémentez qu'une seule zone, vous pouvez toujours attribuer jusqu'à cinq URL aux collections de sites nommées par l'hôte. Cette configuration est due au fait que si une zone n’est pas implémentée en étendant l’application web, SharePoint Server utilise la zone par défaut.

Par exemple, les URL suivantes pourraient donner accès au même site Internet :

Le compte d'analyse de recherche nécessite l'accès au contenu par le biais de la zone Par défaut à l'aide de l'authentification Windows intégrée (NTLM ou Kerberos). Étant donné que l’authentification par revendications autorise plusieurs types d’authentification dans une zone, cette exigence ne doit pas affecter les autres exigences d’authentification.

Chemins d’accès gérés et collections de sites nommées par l’hôte

Les URL configurées pour la même collection de sites peuvent présenter différents modèles et domaines, mais elles doivent posséder les mêmes chemins d'accès gérés ; concrètement, tout ce qui suit le caractère « / » après le nom de domaine doit être identique. Par exemple, et http://www.Fabrikam.com/sites/Site1 peuvent tous deux pointer vers la même collection de sites, http://www.Contoso.com/sites/Site1 mais http://www.Contoso.com/sites/Site1 pas et http://www.bar.com/sites/Project1 .

Les applets de commande permettant de gérer les URL ne fonctionnent que sur la collection de sites racine pour un nom d'hôte, par exemple http://www.Contoso.com. Ces applets de commande ne fonctionnent pas sur une collection de sites de chemin d’accès managé qui se trouve sous la racine, telle que http://www.Contoso.com/sites/Project1. Les sites sous la racine d’une collection de sites nommée par l’hôte en héritent leurs paramètres d’URL.

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

L’arrêt de SSL hors zone intervient lorsqu’un serveur proxy met fin à une demande SSL, puis la transfère à un serveur Web à l’aide du protocole HTTP. Pour permettre l'arrêt de SSL hors zone avec des collections de sites nommées par l'hôte, le dispositif qui met fin à la connexion SSL, tel qu'un serveur proxy inverse, doit être capable de générer un en-tête HTTP personnalisé : Front-End-Https: On. Pour plus d’informations, consultez Utiliser des collections de sites nommées par l’hôte avec arrêt SSL désactivé.

L’arrêt non sécurisé du protocole SSL est pris en charge, mais il n’est pas recommandé, car il entraîne l’envoi du trafic non chiffré du serveur proxy au serveur web.

Le protocole utilisé pour une collection de sites nommée par l’hôte dépend de la valeur du paramètre URL que vous avez spécifié lorsque vous avez utilisé l’applet Set-SPSiteUrl de commande pour mapper l’URL à une zone particulière : http ou https. Assurez-vous que les liaisons Services Internet (IIS) pour l'application Web, les certificats SSL, la configuration de proxy inverse et les autres configurations requises sont terminées.

Quand utiliser des collections de sites basées sur des chemins d’accès ?

Utilisez les collections de sites basées sur des chemins d’accès traditionnels et le mappage d’accès alternatif si l’une des conditions suivantes s’applique :

  • Vous devez utiliser la fonctionnalité de création de sites libre-service qui fait partie de l'installation par défaut de SharePoint Server.

    Cette condition ne s’applique pas aux solutions de création de site en libre-service personnalisées.

  • L’arrêt SSL est obligatoire, mais votre appareil d’arrêt SSL ne peut pas être configuré pour produire l’en-tête HTTP personnalisé nécessaire.

    Vous pouvez toujours utiliser le pontage SSL avec des collections de sites nommées par l’hôte avec ces appareils si l’arrêt SSL n’est pas obligatoire.

  • Vous envisagez d’utiliser différents pools d’applications pour la sécurité supplémentaire que ces groupes fournissent ou vous devez utiliser plusieurs groupes proxy.

    Dans ces cas-là, vous pouvez utiliser des collections de sites nommées par l'hôte. Toutefois, la configuration supplémentaire requise pour mapper les URL des collections de sites nommées par l’hôte dans plusieurs applications web l’emporte largement sur les avantages de l’utilisation de collections de sites nommées par l’hôte. Pour plus d'informations, voir Utilisation de plusieurs applications Web avec des collections de sites nommées par l'hôte. Pour plus d'informations concernant la création de collections de sites basées sur des chemin d'accès, voir Créer une collection de sites dans SharePoint Server.

Utilisation des en-têtes d’hôte et des collections de sites nommées par l’hôte

Les en-têtes d’hôte permettent au serveur web d’héberger plusieurs sites web sur la même combinaison d’adresse IP et de port. Si la requête HTTP entrante inclut un nom d’en-tête d’hôte et qu’un en-tête d’hôte correspondant est configuré dans IIS, IIS répond avec le contenu du site web approprié.

Les en-têtes d’hôte sont configurés au niveau de l’application web (site web IIS), il s’agit de l’une des propriétés de liaison de site web.

Il est important de comprendre la distinction entre les en-têtes d’hôte dans IIS et les collections de sites nommées par l’hôte. Les en-têtes d’hôte au niveau du site web IIS sont uniquement destinés aux collections de sites basées sur le chemin d’accès.

Lors de l’utilisation de collections de sites nommées par l’hôte, SharePoint est chargé de résoudre le site approprié pour l’adresse en fonction de la requête entrante transmise via IIS. Dans la plupart des cas, l’application d’une liaison d’en-tête d’hôte au niveau du site web IIS rend impossible l’accès aux collections de sites nommées par l’hôte via le site web IIS. Cette inaccessibilité est due au fait qu’IIS ne répond pas aux demandes de noms d’hôte qui diffèrent de la liaison d’en-tête d’hôte.

Vous pouvez utiliser une liaison d’en-tête d’hôte générique dans IIS, mais vous devez vous assurer que toutes les collections de sites au sein de l’application web sont conformes au modèle d’en-tête de l’hôte générique.

Importante

Si une application web existante a un jeu de liaisons d’en-tête d’hôte, IIS ne retourne pas les pages de la collection de sites nommée par l’hôte tant que vous n’avez pas supprimé la liaison d’IIS. Pour plus d'informations, voir Mettre à jour les liaisons IIS et l'URL d'une application web pour SharePoint Server.

Combinaison de collections de sites nommées par l’hôte et de collections de sites basées sur des chemins d’accès dans la même application Web

Vous pouvez utiliser des collections de sites nommées par l’hôte et basées sur des chemins d’accès dans la même application Web. Pour vous assurer que les deux types de collections de sites sont accessibles aux utilisateurs, ne placez pas de liaisons d’en-tête d’hôte sur le site web IIS de votre application web, y compris les sites web IIS pour les zones étendues à partir de l’application web. Si une application web existante a un jeu de liaisons d’en-tête d’hôte, IIS ne retourne pas les pages de la collection de sites nommée par l’hôte tant que vous n’avez pas supprimé la liaison d’IIS.

Mes sites

Lorsque vous utilisez les deux types de collections de sites avec des Mes sites, pensez à implémenter votre propre processus de mise en service pour créer des Mes sites en tant que sites nommés par l'hôte plutôt qu'en tant que sites basés sur des chemins d'accès.

Déploiement et configuration pour les collections de sites nommées par l’hôte

Création d’une application Web pour les collections de sites nommées par l’hôte

Si vous n’envisagez pas de configurer au moins deux sites web IIS qui partagent le même numéro de port sur le même serveur, créez une application web dans la zone Par défaut. N’appliquez pas de liaison d’en-tête d’hôte au niveau du site web IIS.

Pour créer une application Web pour les collections de sites nommées par l'hôte

  1. Vérifiez votre statut de membre pour les éléments suivants :

    • Rôle serveur fixe securityadmin sur l'instance SQL Server

    • Rôle de base de données fixe db_owner sur toutes les bases de données à mettre à jour

    • Groupe Administrateurs sur le serveur sur lequel vous exécutez l’applet de commande Microsoft PowerShell.

    Un administrateur peut utiliser l’applet de Add-SPShellAdmin commande pour accorder des autorisations d’utilisation des applets de commande SharePoint Server.

    Notes

    Si vous n’avez pas d’autorisations, contactez votre administrateur d’installation ou l’administrateur SQL Server pour demander des autorisations. Pour plus d’informations sur les autorisations PowerShell, consultez Add-SPShellAdmin.

  2. Ouvrez SharePoint Management Shell.

  3. À l’invite de commandes PowerShell (autrement dit, PS C :\>), tapez la syntaxe suivante :

New-SPWebApplication -Name 'Contoso Sites' -port 80 -ApplicationPool ContosoAppPool -ApplicationPoolAccount (Get-SPManagedAccount 'Contoso\JDoe') -AuthenticationProvider (New-SPAuthenticationProvider -UseWindowsIntegratedAuthentication)

Création d’une collection de sites racine

Une collection de sites racine est requise pour toute application web. Il est également nécessaire pour analyser le contenu. Cette collection de sites doit avoir la même URL que l’application web. Actuellement, SharePoint empêche la création d’une collection de sites nommée par l’hôte avec la même URL qu’une application web. Par conséquent, la collection de sites racine est créée en tant que collection de sites basée sur le chemin d’accès.

A web application with a root site.

L'exemple suivant permet de créer une collection de sites vide correspondant à la collection de sites racine :

New-SPSite 'http://<servername>' -Name 'Portal' -Description 'Portal on root' -OwnerAlias 'contoso\administrator' -language 1033 -Template 'STS#0'

Seule la collection de sites racine de l'application web apparaît dans la source de contenu. Même si toutes les autres collections de sites nommées par l’hôte dans l’application web n’apparaissent pas dans la source de contenu, la recherche par défaut analyse automatiquement les autres collections de sites nommées par l’hôte.

Création de collections de sites nommées par l’hôte

Vous devez utiliser Microsoft 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 pour créer une collection de sites nommée hôte, mais vous pouvez utiliser 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 Microsoft PowerShell New-SPSite avec le paramètre -HostHeaderWebApplication , comme illustré dans l’exemple suivant :

Pour créer des collections de sites nommées par l’hôte :

  1. Vérifiez que vous êtes membre :

    • Rôle serveur fixe securityadmin sur l'instance SQL Server

    • Rôle de base de données fixe db_owner sur toutes les bases de données à mettre à jour

    • Groupe Administrateurs sur le serveur sur lequel vous exécutez l’applet de commande Microsoft PowerShell.

    Un administrateur peut utiliser l’applet de Add-SPShellAdmin commande pour accorder des autorisations d’utilisation des applets de commande SharePoint Server.

    Notes

    Si vous n’avez pas d’autorisations, contactez votre administrateur d’installation ou l’administrateur SQL Server pour demander des autorisations. Pour plus d’informations sur les autorisations PowerShell, consultez Add-SPShellAdmin.

  2. Ouvrez SharePoint Management Shell.

  3. À l’invite de commandes PowerShell (autrement dit, PS C :\>), tapez la syntaxe suivante :

    New-SPSite 'http://portal.contoso.com' -HostHeaderWebApplication (Get-SPWebApplication 'Contoso Sites') -Name 'Portal' -Description 'Customer root' -OwnerAlias 'contoso\administrator' -language 1033 -Template 'STS#0'

    Cette syntaxe crée une collection de sites nommée par l’hôte qui a l’URL dans https://portal.contoso.com l’application web SharePoint Server nommée « Contoso Sites ».

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

Vous pouvez implémenter des chemins d'accès gérés avec des collections de sites nommées par l'hôte. Les hébergeurs peuvent fournir plusieurs collections de sites au même client, chacun 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. Le nombre de chemins d'accès gérés pour les collections de sites nommées par l'hôte est limité à 20 par batterie de serveurs. Pour plus d’informations, voir Limites et limites logicielles pour SharePoint Server.

Les chemins d'accès gérés pour les collections de sites nommées par l'hôte se comportent différemment des chemins d'accès gérés pour les collections de sites basées sur des chemins d'accès. Les chemins d'accès gérés pour les collections de sites nommées par l'hôte sont disponibles pour l'ensemble des collections de sites nommées par l'hôte de la batterie de serveurs, quelle que soit l'application Web dans laquelle se trouve la collection de sites nommée par l'hôte. À l'inverse, les chemins d'accès gérés pour les collections de sites basées sur des chemins d'accès s'appliquent uniquement aux sites se trouvant dans la même application Web. Les chemins d’accès managés pour les collections de sites basées sur des chemins d’accès ne s’appliquent pas aux collections de sites basées sur des chemins d’accès dans d’autres applications web. Les chemins d’accès managés pour un type de collection de sites ne s’appliquent pas à l’autre type de collection de sites.

Pour créer un chemin d'accès géré, vous devez d'abord créer une collection de sites avec l'URL de base désirée. Par exemple, pour créer http://teams.contoso.com/finance , vous devez d’abord créer la collection de sites pour http://teams.contoso.com.

Pour créer un chemin d'accès géré à utiliser avec des collections de sites nommées par l'hôte, utilisez la cmdlet PowerShell New-SPManagedPath avec le paramètre HostHeader, tel qu'indiqué dans l'exemple suivant :

New-SPManagedPath 'departments' -HostHeader

Vous pouvez également utiliser le paramètre Explicit-explicit pour créer des chemins d'accès gérés explicites.

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

New-SPSite 'http://portal.contoso.com/departments/marketing' -HostHeaderWebApplication (Get-SPWebApplication 'Contoso Sites') -Name 'Marketing' -Description 'Portal Marketing' -OwnerAlias 'contoso\administrator' -language 1033 -Template 'STS#0'

Pour supprimer un chemin d'accès géré existant, utilisez la cmdlet PowerShell Remove -SPManagedPath, tel qu'indiqué dans l'exemple suivant :

Remove-SPManagedPath 'departments' -HostHeader

Vous pouvez utiliser PowerShell pour supprimer un chemin d'accès géré même si une collection de sites existe. Si vous supprimez un chemin d'accès géré, la collection de sites n'est plus accessible. Pour accéder à la collection de sites existante, utilisez PowerShell pour recréer le chemin d'accès géré.

Mappage d’URL avec les collections de sites nommées par l’hôte

Lorsque vous créez une collection de sites de nom d’hôte, les mappages d’accès alternatif par défaut existent toujours, mais ne peuvent pas être utilisés. Utilisez les commandes PowerShell pour gérer les mappages d'URL des collections de sites nommées par l'hôte.

Ajouter un mappage à un site existant :

Set-SPSiteUrl (Get-SPSite 'http://teams.contoso.com') -Url 'http://teamsites.contoso.com' -Zone Intranet

Chaque mappage d'URL s'applique à une zone unique. Utilisez l'un des noms de zone suivants lorsque vous mappez des URL :

  • Par défaut

  • Intranet

  • Internet

  • Personnalisé

  • Extranet

Si vous ne spécifiez pas le paramètre Zone et que l’entrée de mappage d’URL est nouvelle, la zone par défaut est utilisée. Vous avez tout de même limité à 5 URL pour une collection de sites unique.

Supprimer un mappage pour un site :

Remove-SPSiteUrl 'http://teamsites.contoso.com'

Afficher tous les mappages d’URL pour un site :

Get-SPSiteUrl -Identity (Get-SPSite 'http://teams.contoso.com')

Configuration des certificats SSL pour les collections de sites nommées par l’hôte

Importante

Si vous utilisez SharePoint Server Édition d’abonnement, utilisez la nouvelle fonctionnalité de gestion des certificats pour installer et affecter des certificats SSL à vos applications web. Cette fonctionnalité vous permet d’installer et de gérer vos certificats SSL directement dans SharePoint au lieu de configurer manuellement des certificats SSL dans IIS.

Vous pouvez configurer une application Web unique qui utilise SSL, puis créer plusieurs collections de sites nommées par l'hôte dans cette application Web. Pour accéder à un site via SSL, vous devez installer et attribuer un certificat de serveur au site Web Services Internet (IIS). Chaque collection de sites nommée par l'hôte dans une application Web partagera le certificat de serveur unique que vous avez affecté au site Web Services Internet (IIS).

Vous devez acquérir un certificat générique ou un certificat SAN, puis utiliser un format d'URL de collection de sites nommée par l'hôte correspondant à ce certificat. Par exemple, si vous achetez un certificat générique *.contoso.com, vous devez générer des URL de collection de sites nommées par l’hôte, telles que https://site1.contoso.com, https://site2.contoso.com, et ainsi de suite, pour permettre à ces sites de passer la validation SSL du navigateur. Toutefois, si vous avez besoin de noms de domaine uniques de second niveau pour les sites, vous devez créer plusieurs applications Web plutôt que plusieurs collections de sites nommées par l'hôte.

Pour configurer SSL pour les collections de sites nommées par l'hôte, activez SSL lorsque vous créez l'application Web. Ce paramètre crée un site web IIS avec une liaison SSL au lieu d’une liaison HTTP. Après avoir créé l'application Web, ouvrez le Gestionnaire des services Internet (IIS) et attribuez un certificat à cette liaison SSL. Vous pouvez ensuite créer des collections de sites dans cette application Web.

Si vous implémentez plusieurs zones avec des collections de sites nommées par l’hôte, assurez-vous que la configuration des certificats et des liaisons (SSL ou HTTP) est appropriée pour chaque zone et le site IIS correspondant.

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

Vous pouvez utiliser des collections de sites nommées par l’hôte avec arrêt de SSL hors zone. Il existe plusieurs conditions préalables pour utiliser l'arrêt de SSL avec des collections de sites nommées par l'hôte :

Notes

L’arrêt non sécurisé du protocole SSL est pris en charge, mais il n’est pas recommandé, car il entraîne l’envoi du trafic non chiffré du serveur proxy au serveur web.

  • Au moins un site Services Internet (IIS) doit disposer d'une liaison sur le port 80 (ou n'importe quel port auquel le terminateur transfère la demande). Microsoft recommande l'utilisation du site Services Internet (IIS) d'une application Web (ou du site Services Internet (IIS) d'une zone pour une application Web) avec HTTP/80.

  • Le terminateur SSL ou le proxy inverse doit conserver l'en-tête d'hôte HTTP d'origine du client.

  • Si la demande SSL du client est envoyée au port SSL par défaut (443), le terminateur SSL ou le proxy inverse 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 vers un port SSL autre que le port par défaut, le terminateur SSL ou le proxy inverse doit transférer la demande HTTP déchiffrée au serveur Web frontal sur le même port (autre que celui par défaut).

  • Le dispositif qui met fin à la connexion SSL, tel qu'un serveur proxy inverse, doit être capable de générer un en-tête HTTP personnalisé : Front-End-Https: On. Cet en-tête est le même que celui utilisé par Outlook Web Access (OWA) : Front-End-Https : Activé/Désactivé. Vous trouverez plus d'informations sur cet en-tête personnalisé plus loin dans cette section.

Pour utiliser des collections de sites nommées par l'hôte avec arrêt de SSL hors zone, configurez votre application Web comme vous le feriez normalement pour l'arrêt de SSL et assurez-vous qu'elle répond aux exigences décrites ci-dessus. Dans ce scénario, SharePoint Server utilise le protocole HTTPS au lieu du protocole HTTP pour afficher les liens de ses collections de sites nommées par l'hôte dans cette application Web.

Les serveurs proxy inverses peuvent publier des collections de sites nommées par l'hôte SharePoint Server et effectuer l'arrêt de SSL hors zone. Dans ce scénario, le serveur proxy inverse bascule le type de connexion entre l'utilisateur final et le serveur web frontal SharePoint de SSL/TLS sur HTTP ou inversement. Dans ce scénario, les serveurs proxy inverses doivent insérer un en-tête HTTP supplémentaire dans la requête de l’utilisateur lorsqu’il transfère la requête au serveur web frontal SharePoint. Cet en-tête HTTP supplémentaire indique à SharePoint Server le type de connexion initié par l’utilisateur final afin que SharePoint Server affiche les URL de manière appropriée dans sa réponse. Le nom d'en-tête HTTP est « Front-End-Https » et ses valeurs possibles sont les suivantes :

Tableau : Valeurs d'en-tête Front-End-Http

Valeur Description
Activé Le serveur proxy inverse a reçu la demande de l'utilisateur final via une connexion HTTPS (SSL ou TLS) chiffrée. Par exemple, Front-End-Https: On.
Off Le serveur proxy inverse a reçu la demande de l'utilisateur final via une connexion HTTPS non chiffrée.

Les valeurs ne respectent pas la casse. Par exemple, on, ON et oN sont acceptables.

Cet en-tête personnalisé fonctionne uniquement avec des collections de sites nommées par l'hôte. Il ne fonctionne pas avec les collections de sites basées sur le chemin d’accès.

L'exemple suivant montre une collection de sites nommée par l'hôte des sites créée sur https :

New-SPSite 'https://portal.contoso.com' -HostHeaderWebApplication  (Get-SPWebApplication 'Contoso Sites') -Name 'Portal' -OwnerAlias 'contoso\administrator' -language 1033 -Template 'STS#0'

Cet exemple permet de créer une collection de sites nommée par l'hôte dont l'URL est https://portal.contoso.com, dans l'application web SharePoint Server dont l'URL est https://webapp.contoso.com.

Activation d’applications dans des environnements à plusieurs zones

Notes

Cette section s’applique uniquement à SharePoint Server 2013.

La mise à jour publique de mars 2013 vous permet de configurer un domaine d'application pour chaque zone d'application Web et d'utiliser des mappages des accès de substitution et une configuration d'application Web d'en-tête d'hôte. Avant la publication de cette mise à jour, vous ne pouviez héberger qu'un seul domaine d'application et celui-ci devait se trouver dans la zone par défaut. Vous n’avez pas pu utiliser le domaine d’application sur des mappages d’accès de substitution ou des configurations d’application web d’en-tête hôte.

Pour résoudre ce problème, appliquez le package de correctifs logiciels serveur SharePoint Server de la mise à jour cumulative : 12 mars 2013 (voir Mises à jour pour SharePoint 2013).

Migration des collections de sites basées sur des chemins d’accès vers les collections de sites nommées par l’hôte

Identification des collections de sites nommées par l’hôte dans les applications Web existantes

Vous pouvez utiliser le script suivant pour identifier les collections de sites existantes basées sur le chemin et celles nommées par l’hôte, afin de pouvoir décider ultérieurement si vous souhaitez convertir l’une d’elles d’un type à un autre.

$webApp = Get-SPWebapplication 'http://webapp.contoso.com'
foreach($spSite in $webApp.Sites)
{
if ($spSite.HostHeaderIsSiteName)
{ Write-Host $spSite.Url 'is host-named' }
else
{ Write-Host $spSite.Url 'is path based' }
}

Conversion des collections de sites basées sur des chemins d’accès en collections de sites nommées par l’hôte

Vous pouvez convertir des collections de sites basées sur des chemins d’accès en collections de sites nommées par l’hôte et des collections de sites nommées par l’hôte en collections de sites basées sur des chemins à l’aide de l’applet de commande PowerShell Set-SPSite. Une fois le site renommé, un recyclage du pool d’applications est recommandé pour forcer l’actualisation du cache. Vous ne pouvez pas utiliser le site web Administration centrale de SharePoint ou les applets de commande Windows PowerShell qui attachent et détachent, ou montent et démontent des bases de données de contenu pour convertir des collections de sites.

L'exemple suivant permet de convertir une collection de sites standard en collection de sites nommée par l'hôte :

Get-SPSite https://SP2013content.contoso.com/sites/PathBasedSiteCollection|Set-SPSite -url https://HostNamedSiteCollection.contoso.com

Utilisation de plusieurs applications Web avec des collections de sites nommées par l’hôte

Si vous utilisez plusieurs applications Web, vous induisez une surcharge opérationnelle et rendez le système plus complexe. Nous vous recommandons d'utiliser une application Web pour les collections de sites. Toutefois, les raisons suivantes peuvent vous inciter à implémenter des collections de sites dans plusieurs applications Web :

  • Les stratégies de sécurité d'une organisation exigent des applications Web ou des pools d'applications distincts.

  • Les applications Web doivent être configurées différemment.

  • Une organisation exige l'utilisation de plusieurs groupes de proxys.

Il est plus complexe d’implémenter des collections de sites nommées par l’hôte avec plusieurs applications web dans une batterie de serveurs, car vous devez effectuer d’autres étapes de configuration. Par exemple, les URL avec des sites nommés par l’hôte peuvent être réparties sur plusieurs applications web qui partagent le même port dans une même batterie de serveurs. Ce scénario nécessite d’autres étapes de configuration pour s’assurer que les demandes sont mappées aux applications web appropriées. Vous devez configurer manuellement les mappages sur chaque serveur web de la batterie en configurant une adresse IP distincte pour représenter chaque application web. Vous devez également créer et gérer des liaisons d’en-tête d’hôte pour affecter des adresses IP uniques pour chaque site. Les scripts peuvent gérer et répliquer cette configuration sur plusieurs serveurs ; Toutefois, cette réplication de la configuration ajoute de la complexité à la solution. Chaque URL unique nécessite également un mappage dans DNS. En règle générale, si plusieurs applications web sont requises, nous vous recommandons de créer des collections de sites basées sur des chemins d’accès avec un mappage d’accès de remplacement.

Importante

SharePoint Server Édition d’abonnement version 23H1 permet aux utilisateurs d’affecter des liaisons d’en-tête d’hôte génériques à leurs applications web. Cette nouvelle fonctionnalité peut vous aider à utiliser plusieurs applications web avec des collections de sites nommées par l’hôte des manières suivantes :

  1. Les utilisateurs n’ont plus besoin d’attribuer manuellement des liaisons d’adresse IP uniques à leurs applications web sur chacun de leurs serveurs SharePoint. Les utilisateurs exécutant SPSE Version 23H1 peuvent à la place attribuer des en-têtes d’hôte génériques à chacune de leurs applications web, ce qui est plus simple à gérer.

  2. Les en-têtes d’hôte génériques attribués à chaque application web doivent être uniques. Par exemple, l’application web 1 peut être *.internal.example.com, l’application web 2 peut être *.external.example.com, etc.

  3. Les collections de sites nommées par l’hôte dans ces applications web doivent être conformes au modèle d’en-tête d’hôte générique de son application web. Par exemple, si une application web a un en-tête d’hôte générique de , elle peut héberger des *.external.example.comcollections de sites nommées par l’hôte avec des noms DNS tels que site1.external.example.com, site2.external.example.com, etc.

  4. Les liaisons d’en-tête d’hôte générique ne peuvent avoir qu’un seul caractère générique comme étiquette la plus à gauche dans le nom DNS. Par exemple, un en-tête d’hôte générique valide peut être *.external.example.com, mais pas external.*.example.com, *.*.example.com, external*.example.com, *external.example.com, etc.

Les deux tableaux suivants comparent trois options de conception différentes pour implémenter les collections de sites. Ils sont destinés à vous aider à comprendre les conséquences de chaque approche et les différences de configuration en fonction de l'architecture.

Tableau : Résultats des différentes options de conception pour la mise en service de collections de sites

  Collections de sites nommées par l’hôte avec tous les sites d’une batterie de serveurs consolidés en une seule application Web Collections de sites basées sur des chemins d’accès avec mappage des accès de substitution et plusieurs applications Web Collections de sites nommées par l’hôte avec plusieurs applications Web dans une batterie de serveurs
Mise en service des collections de sites Utilisez Microsoft PowerShell ou une solution personnalisée de mise en service des collections de sites pour mettre des sites en service. Utilisez l'Administration centrale ou Microsoft PowerShell pour déployer des sites. Utilisez Microsoft PowerShell ou une solution personnalisée de mise en service des collections de sites pour mettre des sites en service.
Gestion des URL Vous pouvez mapper toutes les collections de sites dans DNS pour qu’elles pointent vers une seule adresse IP qui représente l’application web. Si plusieurs zones sont implémentées, le mappage des accès de substitution est configuré pour chaque URL de site. Chaque zone nécessite un mappage dans le DNS. Une configuration supplémentaire est nécessaire pour garantir que les demandes de sites qui partagent le même port sont mappées à l’application web appropriée. En outre, chaque nom d'hôte unique nécessite un mappage dans le DNS. Cette configuration est manuelle et doit être effectuée sur chaque serveur Web d'une batterie de serveurs, pour chaque site.
Autres URL Vous pouvez attribuer jusqu'à cinq URL à une collection de sites nommée par l'hôte, soit une par zone. Il n’est pas nécessaire d’étendre l’application web à plusieurs zones. Si une zone n’est pas implémentée, la zone par défaut est utilisée. Le nombre d’URL d’une collection de sites est limité à cinq, car le nombre autorisé de zones est de cinq. Vous pouvez attribuer jusqu'à cinq URL à une collection de sites nommée par l'hôte, soit une par zone. Il n’est pas nécessaire d’étendre l’application web à plusieurs zones. Si une zone n’est pas implémentée, la zone par défaut est utilisée.
Applications de service Tous les sites de la batterie de serveurs utilisent un groupe d'applications de service unique. Vous pouvez implémenter des groupes d'applications de service personnalisés pour plusieurs applications Web. Vous pouvez implémenter des groupes d'applications de service personnalisés pour plusieurs applications Web.
Zones Vous n’avez pas besoin d’implémenter plusieurs zones pour implémenter différentes URL pour la même collection de sites. Si une zone n’est pas implémentée, la zone par défaut est utilisée. Des zones sont nécessaires pour l'implémentation de différentes URL pour la même collection de sites. Vous n’avez pas besoin d’implémenter plusieurs zones pour implémenter différentes URL pour la même collection de sites. Si une zone n’est pas implémentée, la zone par défaut est utilisée.
Authentification Avec une seule application Web, les options d'authentification sont limitées à cinq zones. Toutefois, de nombreuses méthodes d'authentification peuvent être implémentées sur une même zone. Vous pouvez implémenter plusieurs conceptions d'authentification et de zone pour chaque application Web. Vous pouvez implémenter plusieurs conceptions d'authentification et de zone pour chaque application Web.
Authentification Fournit une isolation par script côté client entre les URL de domaine. Les applications Web peuvent être isolées dans des pools d'applications dédiés si vous voulez mettre en place une isolation des processus.
Fournit une isolation entre les URL de domaine.		 Les applications Web peuvent être isolées dans des pools d'applications dédiés si vous voulez mettre en place une isolation des processus.
Fournit une isolation entre les URL de domaine.
Stratégie Vous pouvez utiliser des zones pour attribuer plusieurs stratégies aux sites nommés par l'hôte. Les stratégies peuvent être utilisées au niveau de l'application Web pour appliquer des autorisations, indépendamment des autorisations configurées sur les différents sites ou documents. En outre, différentes stratégies peuvent être implémentées pour différentes zones. Différentes stratégies peuvent être implémentées pour différentes applications Web pour appliquer des autorisations, indépendamment des autorisations configurées sur les différents sites ou documents.
En outre, vous pouvez implémenter plusieurs stratégies pour différentes zones.

Les critères d'extensibilité susceptibles d'avoir une incidence sur les décisions de conception comprennent les maximums recommandés pour les collections de sites, les bases de données de contenu et les chemins d'accès gérés.

Le tableau suivant récapitule la configuration nécessaire pour gérer les URL en fonction des trois options de conception présentées dans cet article.

Tableau : Configuration requise pour les différentes conceptions de collection de sites

  Collections de sites nommées par l’hôte avec tous les sites d’une batterie de serveurs consolidés en une seule application Web Collections de sites basées sur des chemins d’accès avec mappage des accès de substitution et plusieurs applications Web Collections de sites nommées par l’hôte avec plusieurs applications Web dans une batterie de serveurs
Dans SharePoint Server Créer l'application Web.
Créez une collection de sites racine qui n’est pas accessible aux utilisateurs (par exemple, https://HNSC01.fabrikam.com).
Créez les collections de sites nommées par l’hôte avec l’en-tête de l’hôte (par exemple, https://intranet.fabrikam.com).
Vous pouvez ajouter d'autres URL pour chaque collection de sites et configurer les zones avec Set-SPSiteUrl. (Dans les exemples de conception de portail d'entreprise, c'est inutile, car il n'y a qu'une seule zone.)		 Créez l’application web avec l’en-tête hôte (par exemple, https://intranet.fabrikam.com).
Éventuellement configurer le mappage des accès de substitution. Dans l’exemple de conception, il n’est pas nécessaire, car il n’y a qu’une seule zone).
Créer la collection de sites basée sur des chemins d'accès racine.		 Créer l'application Web.
Créez une collection de sites racine qui n’est pas accessible aux utilisateurs (par exemple, https://HNSC01.fabrikam.com).
Créez les collections de sites nommées par l’hôte avec l’en-tête de l’hôte (par exemple, https://intranet.fabrikam.com).
Vous pouvez ajouter d'autres URL pour chaque collection de sites et configurer les zones avec Set-SPSiteUrl. (Dans les exemples de conception de portail d'entreprise, c'est inutile, car il n'y a qu'une seule zone.)
Dans IIS Associer un certificat SSL (certificat générique ou certificat SAN) pour tous les sites nommés par l'hôte (domaine) dans l'application Web. Associer un certificat SSL dans Services Internet (IIS) pour chaque zone (chaque zone est une application Web distincte dans Services Internet (IIS)). Associer un certificat SSL (certificat générique ou certificat SAN) pour un site nommé par l'hôte (domaine) dans les applications Web.
Sur chaque serveur Web de la batterie et pour chaque application Web partageant un port :
Configurer une adresse IP distincte pour représenter chaque application Web.
Modifiez manuellement la liaison de site web IIS pour supprimer la liaison d’en-tête d’hôte qui a été créée lors de la création de l’application web et remplacez cette liaison par une liaison d’adresse IP.

Si vous utilisez plusieurs applications web sur différentes adresses IP, vous devrez peut-être effectuer une configuration supplémentaire pour la carte réseau, le DNS et l’équilibreur de charge pour chaque serveur.

Création de plusieurs applications Web avec des collections de sites nommées par l’hôte

Pour exécuter plusieurs applications Web sur le même serveur et le même port conjointement avec des collections de sites nommées par l’hôte, vous devez attribuer plusieurs adresses IP aux applications Web. Ce type d'architecture exige que vous ajoutiez des adresses IP aux serveurs Web et que vous configuriez le routeur réseau pour qu'il pointe les noms d'hôte vers l'adresse IP de son application Web.

Notes

Vous pouvez créer une application web qui n’a pas d’en-tête d’hôte. Si vous créez une application web qui n’a pas d’en-tête d’hôte, vous ne pouvez pas créer plusieurs applications web avec des collections de sites nommées par l’hôte sur le même serveur web.

Le processus qui crée plusieurs applications web pour une collection de sites nommée par l’hôte comprend les tâches suivantes :

  • Créer les différentes applications Web

  • Ajouter une nouvelle adresse IP virtuelle dans Services Internet (IIS) sur chaque serveur Web de la batterie de serveurs

Création de plusieurs applications Web pour des collections de sites nommées par l’hôte

L’exemple suivant permet de créer une application Web :

New-SPWebApplication -Name 'webapp' 'webapp.contoso.com' -port 80 -ApplicationPool ContosoAppPool -ApplicationPoolAccount (Get-SPManagedAccount 'Contoso\JDoe') -AuthenticationProvider (New-SPAuthenticationProvider -UseWindowsIntegratedAuthentication)

Répétez cette tâche pour chaque application Web.

Ajout d’adresses IP virtuelles dans IIS

Les liaisons IP doivent être appliquées sur tous les serveurs qui hébergeront l’application Web. Définissez la commande de veille sur 60 secondes pour vous assurer que les liaisons IP sont définies pour tous les serveurs de la batterie de serveurs avant que l'en-tête d'hôte existant sur l'application Web soit supprimé. Les scripts distants peuvent être utilisés pour ce travail.

Utilisez les commandes suivantes pour ajouter des liaisons IP uniques pour chacune des applications Web que vous avez créées, puis supprimer la liaison d'en-tête d'hôte de ces applications Web.

Import-Module WebAdministration
#add empty binding to webapp on IP 192.168.10.20
New-WebBinding -Name 'webapp' -IPAddress '192.168.10.20' -HostHeader ''
Sleep 60
# remove existing binding webapp.contoso.com from existing web application
Get-WebBinding -Name 'webapp' -HostHeader 'webapp.contoso.com'|Remove-WebBinding

Voir aussi

Autres ressources

Get-SPSiteUrl

Set-SPSiteUrl

Remove-SPSiteUrl

Planifier des architectures logiques pour SharePoint Server