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

 

**Sapplique à :**SharePoint Foundation 2013, SharePoint Server 2013, SharePoint Server 2016

**Dernière rubrique modifiée :**2017-08-18

Résumé : Planifiez et implémentez des collections de sites nommées par l’hôte dans SharePoint 2013 et SharePoint Server 2016 et découvrez en quoi les collections de sites basées sur des chemins d’accès peuvent avoir une incidence sur votre environnement.

Les collections de sites nommées par l’hôte représentent la méthode recommandée pour déployer des sites dans SharePoint Server. Étant donné que l’environnement Office 365 utilise des collections de sites nommées par l’hôte, les nouvelles fonctionnalités sont optimisées pour ces collections de sites et devraient être plus fiables. 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.

Dans cet article :

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

  • Architecture recommandée pour les 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

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

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

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

  • 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

• 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

  • Création d’une collection de sites racine

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

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

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

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

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

  • Activation d'applications dans des environnements à plusieurs zones

• 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

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

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

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

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

  • Ajout d’adresses IP virtuelles dans IIS

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. Vous pouvez ainsi déployer plusieurs sites portant des noms DNS uniques dans la même application Web. Les hébergeurs peuvent également mettre à l’échelle un environnement pour plusieurs clients. Si vous n’utilisez pas de collections de sites nommées par l’hôte, votre application Web SharePoint comporte plusieurs collections de sites basées sur des chemins d’accès qui partagent le même nom d’hôte (nom DNS). Par exemple, l’équipe Team A dispose d’une collection de sites sur https://contoso.com/sites/teamA et l’équipe Team B dispose d’une collection de sites sur https://contoso.com/sites/teamB.

Nous recommandons les collections de sites nommées par l’hôte à moins que des exigences imposent l’utilisation de sites basés sur des chemins d’accès avec mappage des accès de substitution (voir plus loin dans cet article). 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.

Architecture recommandée pour les collections de sites nommées par l’hôte

Pour le déploiement de sites, il est recommandé d’utiliser des collections de sites nommées par l’hôte avec tous les sites situés dans une même application Web, comme illustré dans le diagramme suivant.

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

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

• Une 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 HR, Facilities et Purchasing.

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

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

Le nombre de sites dans l’application Web et les URL des sites n’ont pas d’importance pour cet exemple.

Lorsque vous créez 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 sera http://< webapp.contoso.com>/.

Cette architecture est recommandée pour déployer des sites car elle possède la même architecture que l’environnement Office 365. Par conséquent, il s’agit de 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 désormais de la configuration la plus fiable.

La configuration recommandée ne comprend 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 un grand nombre de collections de sites nommées par l’hôte vers une application Web unique, vous augmentez l’extensibilité de la batterie de serveurs 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, mais vous ne pouvez pas utiliser l’Administration centrale.	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. Il peut s’agir d’une collection de sites à laquelle les utilisateurs n’ont pas accès.	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 gérés pour créer des collections de sites supplémentaires dans 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 sites 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 : ajoutez ou modifiez un mappage d’URL pour un site.

• Remove-SPSiteUrl : supprimez un mappage d’URL d’un site.

• Get-SPSiteUrl : affichez toutes les URL et les 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 via toute zone ; elles 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.

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. En effet, 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 :

• www.Contoso.com

• www.Contoso.uk

• www.Contoso.ca

• www.Contoso.au

• www.Contoso.ie

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). Cette contrainte ne devrait pas avoir d’incidence sur les autres contraintes d’authentification, car l’authentification basée sur les revendications autorise plusieurs types d’authentification dans une même zone.

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, https://www.Contoso.com/sites/Site1 et http://www.Fabrikam.com/sites/Site1 peuvent pointer tous les deux vers la même collection de sites, contrairement à https://www.Contoso.com/sites/Site1 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 https://www.Contoso.com. Ces applets de commande ne fonctionnent pas sur une collection de sites à chemin d’accès géré sous la racine, par exemple https://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, voir Utilisation de collections de sites nommées par l'hôte avec arrêt de SSL hors zone plus loin dans cet article.

Le protocole utilisé pour une collection de sites nommée par l’hôte dépend de la valeur du paramètre d’URL que vous avez indiqué lorsque vous avez utilisé l’applet de commande Set-SPSiteURL pour mapper l’URL avec 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 ?

Même si nous recommandons d’utiliser des collections de sites nommées par l’hôte pour la plupart des architectures, il est préférable d’utiliser des collections de sites traditionnelles basées sur des chemins d’accès et un mappage des accès de substitution dans les situations suivantes :

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

  Cela ne s’applique pas aux solutions de création de sites libre-service personnalisées.

• L’arrêt de SSL est requis, mais votre dispositif d’arrêt de SSL ne peut pas être configuré pour générer l’en-tête HTTP personnalisé nécessaire.

  Vous pouvez néanmoins utiliser le pontage SSL avec les collections de sites nommées par l’hôte à l’aide de ces dispositifs si l’arrêt de SSL n’est pas obligatoire.

• Vous souhaitez utiliser des pools d’applications différents pour la sécurité supplémentaire qu’ils apportent ou vous devez utiliser plusieurs groupes de proxys.

  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 des URL pour les collections de sites nommées par l’hôte sur plusieurs applications Web est bien plus avantageuse que 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 adresse IP/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épondra avec le contenu provenant du site web approprié.

Les en-têtes d’hôte sont configurés au niveau de l’application web (site web IIS) et constituent l’une des propriétés des liaisons 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 responsable de la résolution du site correct pour l’adresse en fonction de la requête entrante envoyée 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 empêche l’accès aux collections de sites nommées par l’hôte via le site web IIS. En effet, IIS ne répond pas aux requêtes correspondant à des noms d’hôte qui diffèrent de la liaison d’en-tête d’hôte.

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 pour les utilisateurs, ne placez pas de liaisons d’en-tête d’hôte sur le site Web Services Internet (IIS) de votre application Web, y compris sur les sites Web Services Internet (IIS) pour les zones étendues à partir de l’application Web. Si une application Web existante dispose d’un jeu de liaisons d’en-tête d’hôte, Services Internet (IIS) ne renverra pas les pages de la collection de sites nommée par l’hôte avant que vous ayez supprimé la liaison d’Services Internet (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’avez pas l’intention de configurer deux sites Web Services Internet (IIS) ou plus partageant 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 Services Internet (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 la cmdlet Add-SPShellAdmin pour accorder des autorisations d’utilisation des cmdlets SharePoint Server.

   Notes

   Si vous ne disposez pas des autorisations, contactez votre administrateur d’installation ou votre administrateur SQL Server afin de les demander. Pour plus d’informations sur les autorisations PowerShell, voir Add-SPShellAdmin.

2. Ouvrez SharePoint Management Shell.

3. À l’invite de commandes PowerShell (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 toutes les applications web, ainsi que pour l’analyse du 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.

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. Bien que toutes les autres collections de sites nommées par l’hôte dans l’application web n’apparaissent pas dans la source de contenu, par défaut, la recherche 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 SharePoint Server de l’Administration centrale pour créer une collection de sites nommée par l’hôte, mais vous pouvez utiliser l’Administration centrale pour la gérer une fois 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, tel qu’indiqué dans l’exemple suivant :

Pour créer des 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 la cmdlet Add-SPShellAdmin pour accorder des autorisations d’utilisation des cmdlets SharePoint Server.

   Notes

   Si vous ne disposez pas des autorisations, contactez votre administrateur d’installation ou votre administrateur SQL Server afin de les demander. Pour plus d’informations sur les autorisations PowerShell, voir Add-SPShellAdmin.

2. Ouvrez SharePoint Management Shell.

3. À l’invite de commandes PowerShell (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'
   

Vous créez ainsi une collection de sites nommée par l’hôte dont l’URL est http://webapp.contoso.com, dans l’application web SharePoint Server dont l’URL est http://webapp.contoso.com.

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 Web application limits.

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 géré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 géré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 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 nommée par l’hôte, les mappages des accès de substitution par défaut existent toujours mais ne peuvent plus ê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

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 disposez du certificat générique *.contoso.com, vous devez 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., afin de permettre à ces sites d’obtenir 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. Vous créerez ainsi un site Web Services Internet (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 chaque site Services Internet (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 :

• 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. Il s’agit de l’en-tête personnalisé utilisé par Outlook Web Access (OWA) : Front-End-Https: On/Off. 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. Les serveurs proxy inverses doivent alors insérer un en-tête HTTP supplémentaire dans la demande de l’utilisateur lors du transfert de la demande au serveur web frontal SharePoint. Cet en-tête HTTP supplémentaire indique à SharePoint Server le type de connexion que l’utilisateur final a lancé pour 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
On	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 des collections de sites basées sur des chemins 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 http://portal.contoso.com, dans l’application web SharePoint Server dont l’URL est http://webapp.contoso.com.

Activation d’applications dans des environnements à plusieurs zones

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 ne pouviez pas utiliser le domaine d’application sur des mappages des accès de substitution ou des configurations d’application Web d’en-tête d’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

Lorsque vous effectuez une migration de SharePoint Server 2010 vers SharePoint Server, nous vous recommandons d’identifier le mode de création des sites SharePoint Server 2010. S’ils ont été créés en tant que sites basés sur des chemins d’accès, pensez à effectuer la migration de ces sites vers des collections de sites nommées par l’hôte. Si des sites nommés par l’hôte et des sites basés sur des chemins d’accès ont été implémentés ensemble, identifiez les sites qui ont été créés en tant que sites basés sur des chemins d’accès et pensez à migrer ces sites vers des collections de sites nommées par l’hôte. Pour ce faire, recherchez l’indicateur « HostHeaderIsSiteName ».

L’exemple suivant détermine si un site dans une application Web donnée est créé sous forme de site nommé par l’hôte ou basé sur des chemins d’accès :

$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 inversement. Vous devez utiliser les applets de commande de sauvegarde et de restauration PowerShell pour convertir les collections de sites. Vous ne pouvez pas utiliser les applets de commande du le site Web Administration centrale de SharePoint ou PowerShell qui attachent et détachent, ou montent et démontent, les bases de données de contenu pour convertir les collections de sites.

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

Backup-SPSite -Identity 'http://portalOld.contoso.com' -Path 'c:\Backup\portalContoso.bak' -Force -UseSQLSnapShot
Restore-SPSite -Identity 'http://portal.contoso.com' -Path 'c:\Backup\portalContoso.bak' -DatabaseName 'portal_content' -Force -HostHeaderWebApplication 'http://webapp.contoso.com' -Confirm:$false

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 en raison du travail de configuration supplémentaire que cela entraîne. 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 des étapes de configuration supplémentaire pour garantir le mappage des demandes avec les applications Web appropriées. Vous devez configurer manuellement les mappages sur chaque serveur Web de la batterie de serveurs en paramétrant une adresse IP par application Web, puis créer et gérer des liaisons d’en-tête d’hôte pour affecter des adresses IP uniques pour chaque site. Des scripts peuvent gérer et répliquer cette configuration d’un serveur à l’autre ; toutefois, cela rend la solution plus complexe. En outre, chaque URL unique nécessite un mappage dans le DNS. En général, si plusieurs applications Web sont obligatoires, nous vous recommandons de privilégier l’utilisation de collections de sites basées sur des chemins d’accès avec mappage des accès de substitution.

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	Toutes les collections de sites peuvent être mappées dans le DNS afin de pointer vers une adresse IP unique représentant 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 requise afin que les demandes pour des sites qui partagent le même port soient mappées avec 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.
URL supplémentaires	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 sur plusieurs zones. Si une zone n’est pas implémentée, la zone par défaut est utilisée.	Le nombre d’URL pour une collection de sites est limité à cinq, soit le nombre de zones autorisé.	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 sur 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 plusieurs 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 plusieurs 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éer une collection de sites racine inaccessible aux utilisateurs (par exemple, https://HNSC01.fabrikam.com). Créer les collections de sites nommées par l’hôte avec l’en-tête d’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éer l’application Web avec l’en-tête d’hôte (par exemple, https://intranet.fabrikam.com). Éventuellement configurer le mappage des accès de substitution. Dans les exemples de conception, c’est inutile, 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éer une collection de sites racine inaccessible aux utilisateurs (par exemple, https://HNSC01.fabrikam.com). Créer les collections de sites nommées par l’hôte avec l’en-tête d’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. Modifier la liaison de site Web Services Internet (IIS) manuellement pour supprimer la liaison d’en-tête d’hôte qui a été créée en même temps que l’application Web et la remplacer par une liaison d’adresse IP.

Si vous utilisez plusieurs applications Web sur plusieurs adresses IP, vous aurez peut-être besoin d’effectuer une configuration supplémentaire pour les cartes réseau, le DNS et le programme d’équilibrage 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.

Le processus de création de plusieurs applications Web pour des collections de sites nommées 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

See also

Planifier des architectures logiques pour SharePoint Server

Get-SPSiteUrl
Set-SPSiteUrl
Remove-SPSiteUrl