Exemples de conception SharePoint Server : sites de portail d’entreprise et extranet
**Sapplique à :**SharePoint Foundation 2013, SharePoint Server 2013, SharePoint Server 2016
**Dernière rubrique modifiée :**2017-08-21
Résumé : Décrit des choix de conception d’architecture logique pour les exemples de conception SharePoint 2013 et SharePoint Server 2016 les plus courants.
Cet article présente plusieurs exemples de conception qui peuvent servir de point de départ pour l’architecture des sites SharePoint. Les exemples de conception décrits dans cet article illustrent des architectures standard des principaux types de site SharePoint déployés au sein d’une entreprise ou d’une organisation.
Dans cet article :
À propos des exemples de conception
Sites inclus dans les exemples de conception
Objectifs globaux de conception
Batteries de serveurs
Utilisateurs, zones et authentification
Services
Sites d’administration
Pools d’applications
Applications Web
Collections de sites
Bases de données de contenu
Zones et URL
Stratégies de zone
Important
Les informations contenues dans cet article s’appliquent à SharePoint Foundation 2013 et à SharePoint Server. Toutefois, l’article aborde certaines fonctionnalités, telles que les sites Mon site et la recherche de contenu d’entreprise, qui ne sont pas disponibles dans SharePoint Foundation 2013.
À propos des exemples de conception
Les exemples de conception suivants sont décrits dans cet article :
Les exemples de conception illustrent des sites pour une entreprise fictive nommée Fabrikam, Inc. Ils appliquent la plupart des composants d’une architecture logique et montrent la manière dont ils sont incorporés dans la conception globale. Cet article décrit les objectifs de conception pour les exemples et explique la façon dont les composants de l’architecture logique illustrés dans les exemples ont répondu à ces objectifs.
Notes
Les modèles comportent SharePoint 2013 dans le titre, mais s’appliquent toujours à SharePoint Server 2016
Exemple de conception Portail d’entreprise : deux versions
Les collections de sites nommées par l’hôte dans SharePoint Server permettent de gérer les URL et l’extensibilité des sites au sein d’une même application web. Les deux versions de l’exemple de conception Portail d’entreprise illustrent des implémentations basées sur l’utilisation des collections de sites nommées par l’hôte ou des collections de sites basées sur le chemin d’accès traditionnelles. Ces deux exemples de conception utilisent l’authentification basée sur les revendications avec une zone unique. Ces exemples font l’objet d’une présentation plus détaillée plus loin dans cet article.
Nous vous recommandons d’utiliser la conception basée sur des 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 (pour plus d’informations, voir Architecture et déploiement d’une collection de sites nommée par l’hôte dans SharePoint Server). Cette conception est recommandée 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.
Extranet avec des zones dédiées pour l’authentification
L’exemple de conception Extranet avec des zones dédiées à l’authentification comprend uniquement le site web partenaire. Il offre une configuration particulière pour la collaboration entre partenaires dans laquelle des zones dédiées sont utilisées pour chaque méthode d’authentification. Chaque exemple de conception utilise l’authentification en mode Revendications pour les applications web. La différence entre les exemples de conception Portail d’entreprise et l’exemple de conception Extranet réside dans la configuration des zones. L’exemple de conception Extranet avec des zones dédiées à l’authentification utilise plusieurs zones, pour chacune desquelles est configurée une méthode d’authentification. Les exemples de conception Portail d’entreprise utilisent une zone, et plusieurs méthodes d’authentification sont configurées pour différentes classes d’utilisateurs.
En outre, l’exemple de conception Extranet avec des zones dédiées à l’authentification introduit une nouvelle recommandation pour l’accès des employés distants : accès direct avec Windows Server 2012. À défaut de suivre cette recommandation, il est possible de créer un réseau privé virtuel. Vous pouvez également utiliser l’authentification par formulaire sur le produit de pare-feu ou de passerelle pour collecter et transmettre les informations d’identification, si vous le souhaitez.
Mise en œuvre des collections de sites dans les exemples de conception
Tandis que les versions antérieures de l’exemple de conception Portail d’entreprise utilisaient des collections de sites basées sur le chemin d’accès, les collections de sites nommées par l’hôte sont dorénavant recommandées, sauf si l’utilisation des sites basés sur le chemin d’accès traditionnels avec mappage des accès de substitution est absolument nécessaire. Les exemples de conception traduisent cela des manières suivantes :
Portail d’entreprise avec collections de sites basées sur le chemin d’accès : cet exemple propose une illustration traditionnelle des collections de sites basées sur le chemin d’accès, avec une organisation des sites en applications web dédiées et une collection de sites de niveau supérieur unique par application web. Utilisez cette approche si vous souhaitez bénéficier de la sécurité supplémentaire procurée par plusieurs applications web avec différents pools d’applications.
Portail d’entreprise avec collections de sites nommées par l’hôte : cet exemple propose une illustration de l’utilisation des collections de sites nommées par l’hôte dans laquelle tous les sites sont déployés dans une application web unique sur la batterie de serveurs. Cette méthode est très extensible et fournit davantage de souplesse en termes de gestion d’URL.
Extranet avec des zones dédiées à l’authentification : cet exemple illustre de nombreux sites de projet de niveau supérieur avec des URL de redirection vers un microsite en utilisant des sites nommés par l’hôte pour chaque site de projet (au lieu d’organiser les sites de projet sous une collection de sites de niveau supérieur). L’utilisation de collections de sites nommées par l’hôte de cette manière permet notamment de créer une isolation supplémentaire entre les URL de domaine, ce qui peut s’avérer souhaitable dans une solution de collaboration entre partenaires. Toutefois, la contrepartie de cette approche réside dans les coûts supplémentaires liés à la gestion d’un plus grand nombre de noms d’hôte, notamment à la gestion des certificats SSL. En outre, si l’authentification SAML est utilisée, une procédure de configuration supplémentaire est requise (voir « Utilisation de l’authentification SAML avec des sites nommés par l’hôte » plus loin dans cet article).
Authentification basée sur les revendications pour SharePoint Server
Le fonctionnement de l’authentification dans SharePoint Server peut influer sur les décisions de conception liées à l’implémentation des choix représentés par ces exemples de conception. Voici quelques exemples :
Dans SharePoint Server, l’authentification basée sur les revendications est le mode par défaut et constitue la seule option disponible par le biais de l’Administration centrale. L’authentification en mode classique peut être implémentée à l’aide de PowerShell.
Dans SharePoint Server, vous n’avez pas besoin de configurer l’affinité du serveur dans l’équilibreur de charge pour utiliser l’authentification par revendications SAML. SharePoint Server prend totalement en charge l’équilibrage de charge sans affinité.
Dans SharePoint Server, 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 par revendications autorise plusieurs types d’authentification dans une même zone.
Résumé des fonctionnalités des exemples de conception
Le tableau suivant récapitule les trois exemples de conception présentés dans cet article.
Tableau : Résumé des exemples de conception
| Exemple de conception | Contenu | Éléments de conception clés |
|---|---|---|
Portail d’entreprise avec sites basés sur des chemins d’accès |
Principaux types de sites déployés dans une organisation. |
|
Portail d’entreprise avec sites nommés par l’hôte |
Principaux types de sites déployés dans une organisation. |
|
Extranet avec des zones dédiées pour l’authentification |
Uniquement le site web partenaire. Offre une configuration particulière pour la collaboration entre partenaires. |
|
Sites inclus dans les exemples de conception
Cette section décrit les sites de niveau supérieur inclus dans les exemples de conception.
Sites intranet
Le portail d’entreprise comprend les sites suivants pour l’utilisation de l’intranet :
Contenu intranet publié (comme HRweb)
Sites de collaboration des équipes
Sites Mon site
Réunis, ces sites forment les sites de contenu et de collaboration que les employés utilisent quotidiennement. Individuellement, chacune de ces applications représente un contenu distinct. Chaque type de contenu présente les propriétés suivantes :
Il met l’accent sur différentes fonctionnalités de SharePoint Server.
Il héberge des données aux caractéristiques différentes.
Il est soumis à un profil d’utilisation différent.
Il nécessite une stratégie de gestion des autorisations différente.
Ainsi, les choix de conception au niveau de chacune de ces applications visent à optimiser les performances et la sécurité de l’application.
La conception des applications de service réunit ces trois applications afin de fournir les fonctionnalités suivantes :
la recherche à l’échelle de l’entreprise ;
des données de profil et des métadonnées d’entreprise partagées.
L’illustration suivante, tirée de l’exemple de conception Portail d’entreprise avec collections de sites basées sur le chemin d’accès, montre les trois types de site qui composent l’intranet d’entreprise.
Types de site qui composent l’intranet d’entreprise
.gif "Intranet sites")
Application Web partenaire
L’application web partenaire héberge des sites disponibles en externe en vue de la collaboration sécurisée avec les entreprises partenaires et les partenaires individuels. Cette application doit permettre aux employés de facilement créer des sites pour une collaboration sécurisée. Les partenaires ne peuvent pas accéder aux autres types de contenus hébergés par la batterie de serveurs. La conception de zones et d’applications de service permet de répondre à cet objectif. En outre, les différents propriétaires de site gèrent les autorisations de leurs sites et invitent uniquement les participants nécessaires à collaborer.
Dans l’exemple de conception d’extranet, seul ce type de site est représenté.
Objectifs globaux de conception
Les exemples de conception proposent des implémentations concrètes des fonctionnalités de SharePoint Server dans divers types courants de site. L’implémentation de chacune des applications individuelles est étudiée dans cet article. Les objectifs de conception clés de ces exemples de conception sont les suivants :
Créer une infrastructure pour la conception d’un environnement évolutif.
Les choix de conception pour les types de site individuels n’empêchent pas l’ajout de nouveaux types de site. Par exemple, un déploiement initial peut inclure uniquement les sites de collaboration des équipes ou uniquement les trois types de site qui composent un intranet (sites d’équipes, sites Mon site et contenu intranet publié). Si vous utilisez un modèle d’architecture logique similaire, vous pouvez ajouter des sites à la solution sans affecter la solution initiale. En d’autres termes, la conception n’intègre aucun choix de conception limitant l’utilisation de l’environnement.
Autoriser l’accès de différents groupes d’utilisateurs sans compromettre la sécurité du contenu dans les différents types de sites.
Les utilisateurs de différentes zones du réseau (interne et externe) qui recourent à des fournisseurs d’authentification différents peuvent participer à une collaboration. Par ailleurs, les utilisateurs peuvent uniquement accéder au contenu qui leur est destiné. Si vous suivez un modèle d’architecture logique similaire, vous pouvez donner l’accès aux utilisateurs qui sont situés à différents emplacements et qui poursuivent des objectifs distincts. Par exemple, votre conception initiale peut être uniquement destinée à l’accès des employés internes. Pourtant, si vous utilisez une conception similaire, vous pouvez aussi autoriser les employés distants, les employés partenaires, les entreprises partenaires et les clients.
Faire en sorte que la conception puisse être utilisée dans un environnement extranet.
Faites des choix de conception délibérés pour vous assurer que la solution peut être déployée de manière sécurisée dans un réseau de périmètre.
Le reste de cet article présente chacun des composants logiques de l’exemple de conception (de haut en bas) et explique les choix de conception qui sont appliqués au modèle de conception. Le but de cette approche est de montrer les différentes configurations possibles des composants de l’architecture logique en fonction de l’application.
Batteries de serveurs
Cette section décrit les topologies des batteries de serveurs illustrées dans l’exemple de conception et étudie la montée en puissance au-delà d’une seule batterie de serveurs.
Topologie des batteries de serveurs
Chaque batterie de serveurs de l’exemple de conception est composée de six serveurs présentant la topologie à tolérance de panne suivante :
Deux serveurs Web frontaux.
Deux serveurs d’applications.
Deux serveurs de base de données sur lesquels SQL Server est installé et configuré afin de prendre en charge la mise en miroir, le clustering SQL Server ou AlwaysOn. AlwaysOn nécessite SQL Server 2012.
Le concept de serveur frontal et d’application est différent dans SharePoint Server 2016, voir Vue d’ensemble des rôles serveur MinRole dans SharePoint Server 2016
L’exemple de conception illustre l’architecture logique de SharePoint Server en montrant les points suivants :
Tous les sites sont mis en miroir sur les serveurs Web frontaux.
Le site Administration centrale est installé sur un serveur d’applications pour le protéger contre l’accès direct par les utilisateurs.
Dans les faits, le nombre d’ordinateurs serveurs et la topologie de la batterie de serveurs ne sont fondamentaux pour l’architecture logique que pour augmenter la capacité et améliorer les performances si nécessaire. Vous pouvez concevoir l’architecture logique indépendamment de la topologie de la batterie de serveurs. Le processus de planification des performances et de la capacité vous aide à planifier la taille de la batterie de serveurs en fonction de vos objectifs de performances et de capacité. Pour plus d’informations, voir Planifier les performances de planification dans Microsoft SharePoint Server 2013.
Utilisateurs, zones et authentification
Le mode « Revendications » est le mode d’authentification par défaut dans SharePoint Server et chaque exemple de conception intègre l’authentification basée sur les revendications. Vous pouvez utiliser Windows PowerShell pour implémenter l’authentification en mode classique. Cependant, certaines fonctionnalités de SharePoint Server ne sont pas disponibles en mode classique. Pour plus d’informations sur les exemples de conception qui intègrent l’authentification en mode classique, voir l’exemple de conception : déploiement d’entreprise (SharePoint Server 2010).
Le tableau suivant indique les différences entre les deux approches représentées par l’exemple de conception Portail d’entreprise et l’exemple de conception Extranet.
Tableau : Comparaison des approches pour les configurations des zones dans les exemples de conception
| Portail d’entreprise avec sites nommés par l’hôte et portail d’entreprise avec sites basés sur des chemins d’accès | Extranet avec des zones dédiées pour l’authentification | |
|---|---|---|
Mode d’authentification |
Revendications |
Revendications |
Configuration des zones |
Une zone avec plusieurs méthodes d’authentification configurées pour les différentes classes d’utilisateurs. |
Plusieurs zones avec une méthode d’authentification configurée par zone. |
URL |
Toutes les classes d’utilisateurs recourent à la même URL pour chaque site. Les employés utilisent la même URL, qu’ils soient connectés au réseau d’entreprise ou qu’ils travaillent à distance. |
Chaque classe d’utilisateur recourt à une URL différente pour accéder à un site. Les employés utilisent une URL différente selon qu’ils sont connectés au réseau d’entreprise ou qu’ils travaillent à distance. |
Demandes internes |
Les demandes démarrées à l’intérieur du réseau d’entreprise sont routées hors de celui-ci, puis réacheminées par le biais de la passerelle ou du serveur proxy. Ces demandes sont sécurisées à l’aide du protocole SSL (Secure Sockets Layer). Une autre méthode consiste à utiliser un environnement DNS scindé pour router les demandes directement vers l’interface interne des serveurs. |
Les demandes initiées à l’intérieur du réseau d’entreprise n’en sortent pas. |
Expérience utilisateur |
Tous les utilisateurs sont invités à choisir le type de compte dont ils se servent pour se connecter. |
La méthode d’authentification est prédéterminée. Les utilisateurs ne sont pas obligés de sélectionner le type de compte en utilisant une page d’ouverture de session. |
Les sections qui suivent étudient spécifiquement la manière dont l’authentification est incorporée au moyen des deux approches.
Exemple de conception d’extranet avec des zones dédiées
L’exemple de conception d’extranet illustre trois classes d’utilisateurs différentes, chacune étant affectée à une zone distincte. Dans chaque application web, vous pouvez créer jusqu’à cinq zones à l’aide de l’un des noms de zone disponibles : Par défaut, Intranet, Internet, Personnalisée ou Extranet. Le compte d’analyse de recherche nécessite l’accès à la zone Par défaut à l’aide de l’authentification Windows intégrée (NTLM ou le protocole Kerberos), ce dont tient compte l’exemple de conception. Le tableau suivant illustre la configuration des zones dans l’exemple de conception d’extranet.
Tableau : Zones, utilisateurs et type d’authentification préconisés par l’exemple de conception d’extranet
| Zone | Utilisateurs | Authentification |
|---|---|---|
Intranet |
Employés internes et distants Compte d’analyse de recherche |
Protocole NTLM Kerberos Employés distants utilisant l’accès direct ou un VPN pour se connecter |
Par défaut |
Partenaires individuels |
Options :
|
Extranet |
Sociétés partenaires |
Fournisseur d’identité de partenaire approuvé avec authentification SAML |
Exemples de conception de portail d’entreprise
L’authentification basée sur les revendications autorise plusieurs types d’authentification dans la même zone. Les deux versions de l’exemple de conception de portail d’entreprise utilisent la zone Par défaut pour tous les types d’authentification.
Le tableau suivant illustre les zones, les utilisateurs et les types d’authentification préconisés par les exemples de conception.
Tableau : Zones, utilisateurs et authentification pour les exemples de conception de portail d’entreprise
| Zone | Utilisateurs | Fournisseur et type d’authentification |
|---|---|---|
Par défaut |
Employés internes et distants |
Magasin AD DS (Active Directory Domain Services) ou LDAP avec authentification basée sur les formulaires ou authentification SAML |
Par défaut |
Partenaires individuels |
Fournisseur d’identité approuvé avec authentification SAML ou base de données SQL Server avec authentification basée sur les formulaires |
Par défaut |
Sociétés partenaires |
Fournisseur d’identité de partenaire approuvé avec authentification SAML |
Par défaut |
Compte d’analyse de recherche |
AD DS avec authentification Windows NTLM |
Dans l’exemple de conception, le site de contenu Intranet publié, les sites d’équipe et les sites Mon site sont uniquement accessibles par les employés, qu’ils se trouvent à l’intérieur ou à l’extérieur du réseau. L’exemple de conception implémente une seule URL (en utilisant le protocole SSL) pour chacun de ces sites qui peut être utilisée en interne comme en externe. Des comptes AD DS sont utilisés. Au besoin, l’authentification basée sur les formulaires ou l’authentification basée sur les jetons SAML peut utiliser le protocole LDAP, ce qui nécessite une configuration supplémentaire.
Dans l’exemple de conception, l’application web partenaire représente un site extranet accessible par les employés partenaires et les entreprises partenaires. L’authentification basée sur les revendications dans ce scénario vous oblige à configurer une relation d’approbation avec un ou plusieurs fournisseurs d’identité externes. Vous pouvez utiliser l’une deux approches suivantes :
Vous pouvez configurer la batterie de serveurs SharePoint afin qu’elle approuve un fournisseur d’identité externe, tel que le fournisseur qui réside dans une société partenaire (pour l’authentification directe par rapport à l’annuaire du partenaire).
Vous pouvez configurer le fournisseur d’identité à l’intérieur de l’environnement d’entreprise afin qu’il approuve un fournisseur d’identité externe. Les administrateurs dans les deux organisations doivent établir cette relation explicitement. Dans ce scénario, la batterie de serveurs SharePoint approuve le fournisseur d’identité depuis son propre environnement d’entreprise. Quand le fournisseur d’identité émet un jeton, la batterie de serveurs utilise le certificat de signature de jetons qui a été spécifié lors de l’établissement de l’approbation pour confirmer la validité du jeton. Nous recommandons cette approche.
Plutôt qu’un environnement basé sur des revendications, vous pouvez utiliser l’authentification par formulaire pour authentifier les partenaires. Vous utilisez un magasin distinct, comme une base de données, pour gérer ces comptes.
Zones
Lorsque vous créez des zones, plusieurs décisions fondamentales déterminent la réussite du déploiement. Ces décisions concernent la conception et la configuration des zones suivantes :
Zone Par défaut
Zones pour l’accès externe
Les sections qui suivent décrivent les décisions intégrées dans l’exemple de conception.
Configuration requise pour la zone Par défaut
La zone Par défaut nécessite la plus grande réflexion. SharePoint Server exige que vous configuriez la zone Par défaut de la manière suivante :
Lorsqu’une demande utilisateur ne peut pas être associée à une zone, l’authentification et les stratégies de la zone Par défaut sont utilisées. Par conséquent, la zone Par défaut doit être la zone la plus sécurisée.
Des messages électroniques d’administration contiennent des liens à partir de la zone Par défaut. Cela inclut les messages envoyés aux propriétaires de sites qui approchent les limites de quota. Ainsi, les utilisateurs qui reçoivent ces types de message et d’alertes doivent pouvoir accéder aux liens via la zone Par défaut. Ceci est particulièrement important pour les propriétaires de sites.
Dans SharePoint Server, les collections de sites nommées par l’hôte sont accessibles depuis n’importe quelle zone.
Configuration des zones pour un environnement extranet
Dans un environnement extranet, la conception des zones est essentielle pour les deux raisons suivantes :
Plusieurs réseaux différents peuvent démarrer les demandes des utilisateurs. Dans les exemples de conception, les utilisateurs démarrent des demandes depuis le réseau interne, Internet et les entreprises partenaires.
Les utilisateurs consomment le contenu à travers plusieurs applications web. Dans l’exemple de conception, l’intranet se compose de trois applications web. Par ailleurs, les employés internes et distants peuvent éventuellement contribuer au contenu ou l’administrer dans l’application web partenaire.
Si un environnement extranet comprend plusieurs zones, veillez à adopter les principes de conception suivants :
Configurez les zones dans différentes applications web de façon à les mettre en miroir les unes des autres. La configuration de l’authentification et les utilisateurs prévus doivent être identiques. Toutefois, les stratégies associées aux zones peuvent différer d’une application web à l’autre. Par exemple, veillez à utiliser la zone Intranet pour les mêmes employés dans toutes les applications web. En d’autres termes, ne configurez pas la zone Intranet pour les employés internes dans une application web et pour les employés distants dans une autre application web.
Si vous utilisez des collections de sites basées sur le chemin d’accès, configurez les mappages des accès de substitution de manière appropriée et avec précision pour chaque zone et chaque ressource. Les mappages des accès de substitution sont automatiquement créés quand vous créez une zone. Toutefois, vous pouvez configurer SharePoint Server pour analyser le contenu dans des ressources externes, comme un partage de fichiers. Vous devez créer des liens vers ces ressources externes manuellement pour chaque zone en utilisant des mappages des accès de substitution.
Si vous utilisez des collections de sites nommées par l’hôte, veillez à utiliser PowerShell pour mapper les URL vers les zones appropriées.
Si les zones des applications Web ne sont pas mises en miroir les unes avec les autres et que les liens vers les ressources externes ne sont pas appropriés, les risques suivants sont encourus :
Les noms de serveur, les noms DNS et les adresses IP peuvent potentiellement être exposés à l’extérieur du réseau interne.
Les utilisateurs peuvent être dans l’incapacité d’accéder aux sites Web et à d’autres ressources.
Utilisation de l’authentification SAML avec des sites nommés par l’hôte
Si une conception comprend l’utilisation de l’authentification SAML avec des sites nommés par l’hôte, chaque URL de redirection vers un microsite nécessite les éléments suivants :
un nouveau domaine sur SPTrustedIdentityTokenIssuer ;
une partie de confiance correspondante dans le fournisseur d’identité.
Services
Les architectures des services varient d’un exemple de conception à l’autre. L’exemple de conception Portail d’entreprise avec des sites nommés par l’hôte comprend l’architecture la plus simple pour les services. En effet, il utilise une application web, qui ne peut prendre en charge qu’un seul groupe d’applications de service (également appelé groupe de proxys).
L’exemple Portail d’entreprise avec des sites basés sur le chemin d’accès utilise des services partitionnés pour les sites partenaires afin d’isoler les données entre les projets. Cet exemple de conception comprend deux groupes de services : un pour les sites intranet, l’autre pour les sites de collaboration entre partenaires. Des instances distinctes du service de métadonnées gérées et du service de recherche sont déployées pour les sites partenaires et ces services sont partitionnés. Les services partitionnés nécessitent le service des paramètres d’abonnement, qui ne peut être déployé qu’à l’aide de PowerShell.
Architecture des services pour le portail d’entreprise avec sites basés sur des chemins d’accès
.gif "Services architecture")
Le déploiement de services partitionnés rend l’architecture plus complexe et complique la migration future des sites vers Office 365. Une option plus simple pour les sites partenaires consiste à déployer des instances dédiées, mais non partitionnées, du service de métadonnées gérées et du service de recherche si ceux-ci doivent être séparés. De nombreuses organisations s’en remettent à la fonctionnalité de filtrage de sécurité de la recherche, au lieu de déployer des instances dédiées du service de recherche.
L’exemple de conception d’extranet ne comprend qu’un seul groupe de proxys, mais il utilise par ailleurs des services partitionnés pour les applications de service de métadonnées gérées et de recherche.
La principale décision de conception à prendre pour le déploiement d’applications de service concerne la largeur de diffusion de la taxonomie de l’entreprise. Pour simplifier l’architecture des services, partagez les services de métadonnées gérées, de profil utilisateur et de recherche à travers toutes les applications web et laissez le filtrage de sécurité gérer l’accès au contenu. Dans l’exemple de conception Portail d’entreprise avec des sites basés sur le chemin d’accès, une instance du service de métadonnées gérées est partagée à travers tous les sites. Toutefois, tous les utilisateurs peuvent accéder à la taxonomie de l’entreprise avec cette configuration. Les architectes de solutions doivent décider si plusieurs instances du service de métadonnées gérées doivent ou non être implémentées. Ils devront également décider du niveau de partage des données de profil utilisateur.
Dans l’exemple Portail d’entreprise avec des collections de sites basées sur le chemin d’accès, le site web partenaire est configuré pour utiliser des applications de service de recherche et de métadonnées gérées dédiées à l’aide d’un groupe de services personnalisé. D’autres applications de service sont ajoutées au groupe personnalisé et sont partagées avec le groupe par défaut. L’exemple de conception ne comprend pas l’application de service de profil utilisateur pour empêcher les utilisateurs partenaires d’explorer les données sur les employés de l’entreprise.
Dans l’architecture simplifiée du portail d’entreprise avec des collections de sites nommées par l’hôte (un groupe de services), les partenaires peuvent accéder à la taxonomie complète de l’entreprise et peuvent parcourir les données sur les employés de l’entreprise. Toutefois, la recherche limite les résultats aux sites et contenus auxquels les partenaires peuvent accéder.
Si vos sites partenaires ont besoin que le contenu de chaque projet soit isolé, le déploiement d’applications de service dédiées est approprié, comme illustré dans cet article. Cela rend plus complexe l’architecture des services, mais garantit que les partenaires ne peuvent pas accéder aux métadonnées associées au contenu Intranet ni à d’autres projets dans le site web partenaire. L’exemple de conception d’extranet utilise également des services partitionnés.
Sites d’administration
Dans l’exemple de conception, un serveur d’applications héberge le le site Web Administration centrale de SharePoint pour chaque batterie de serveurs. Le site est ainsi protégé contre l’accès direct des utilisateurs. Si les serveurs web frontaux ne sont pas disponibles en raison d’un goulet d’étranglement au niveau des performances ou d’une faille de sécurité, le le site Web Administration centrale de SharePoint reste disponible.
L’exemple de conception et cet article ne mentionnent pas les URL à charge équilibrée des sites d’administration. Les recommandations suivantes doivent être suivies :
Si les URL d’administration utilisent des numéros de port, employez des ports non standard. Les URL incluent des numéros de port par défaut. Alors que les URL présentées aux clients ne comprennent généralement pas de numéros de port, l’utilisation de numéros de port pour les sites d’administration peut améliorer la sécurité en limitant l’accès à ces sites aux ports non standard.
Créez des entrées DNS distinctes pour les sites d’administration.
Outre ces recommandations, vous pouvez équilibrer la charge du le site Web Administration centrale de SharePoint sur des serveurs d’applications multiples afin d’assurer une redondance.
Pools d’applications
Des pools d’applications de service Internet (IIS) sont généralement implémentés afin d’isoler les processus entre contenus. Avec les pools d’applications, plusieurs sites peuvent s’exécuter sur le même ordinateur serveur, mais chacun conserve ses propres processus de travail et sa propre identité. Cela permet d’empêcher un attaquant qui injecte du code sur un site d’affecter d’autres serveurs ou sites sur d’autres sites.
Si un seul pool d’applications et une seule application web sont utilisés conjointement avec des collections de sites nommées par l’hôte, l’isolation est fournie entre les URL de domaine, mais uniquement au niveau des scripts.
Si vous choisissez d’implémenter plusieurs pools d’applications, envisagez un pool d’applications dédié dans chacun des scénarios suivants :
Pour séparer le contenu authentifié du contenu anonyme. Si la même batterie de serveurs héberge le site Internet de l’entreprise, placez ce site dans une application web et dans un pool d’applications dédiés.
Pour isoler les sites qui stockent des mots de passe pour des systèmes de données principaux et qui interagissent avec ces systèmes (même si le service Banque d’informations sécurisé peut être utilisé à cette fin).
L’exemple de conception Portail d’entreprise avec des sites nommés par l’hôte et l’exemple de conception Extranet avec des zones dédiées à l’authentification implémentent un pool d’applications et une application web uniques pour tout le contenu. Des pools d’applications distincts sont requis pour les applications de service et le le site Web Administration centrale de SharePoint.
L’exemple de conception Portail d’entreprise avec sites basés sur des chemins d’accès implémente l’isolation de processus entre les contenus en utilisant des pools d’applications distincts comme suit :
Le site d’administration est hébergé dans un pool d’applications dédié. Ceci est requis par SharePoint Server.
Toutes les applications de service sont déployées sur un même pool d’applications. Sauf si le déploiement des applications de service sur différents pools d’applications est absolument nécessaire, nous vous recommandons cette configuration. Un même pool d’applications pour toutes les applications de service optimise les performances et réduit le nombre de pools d’applications à gérer.
Le contenu intranet est divisé en deux pools d’applications distincts. Un pool d’applications héberge le contenu collaboratif (sites Mon site et sites d’équipe), tandis qu’un autre pool d’applications héberge le contenu intranet publié. Cette configuration permet d’isoler les processus pour le contenu intranet publié dans lequel des connexions aux données métier sont le plus généralement utilisées.
Un pool d’applications dédié héberge l’application Web partenaire.
Applications Web
Une application web est un site web IIS que SharePoint Server crée et utilise. Chaque application web est représentée par un site web différent dans les services Internet (IIS).
Si vous choisissez d’implémenter plusieurs applications Web, envisagez les cas d’utilisation suivants :
Séparer le contenu anonyme du contenu authentifié
Si la même batterie de serveurs héberge le site Internet de l’entreprise, placez ce site dans une application Web et un pool d’applications dédiés.
Isoler les utilisateurs
Dans l’exemple de conception, une application web et un pool d’applications dédiés hébergent le site web partenaire pour garantir que les partenaires n’ont pas accès au contenu intranet.
Appliquer des autorisations
Vous pouvez implémenter des stratégies sur les zones d’une application web dédiée pour appliquer des permissions. Par exemple, vous pouvez créer des stratégies sur le site Internet de l’entreprise afin de refuser explicitement l’accès à un ou plusieurs groupes d’utilisateurs. Les stratégies sont appliquées indépendamment des autorisations configurées sur les différents sites ou documents dans l’application web.
Optimiser les performances
Les applications sont plus performantes si vous les placez dans des applications web avec d’autres applications ayant des caractéristiques de données similaires. Par exemple, les caractéristiques de données des sites Mon site incluent un grand nombre de sites de petite taille. À l’inverse, les sites d’équipe regroupent généralement un plus petit nombre de très grands sites. En plaçant ces deux types différents de site dans des applications web distinctes, les bases de données ainsi créées sont composées de données ayant des caractéristiques similaires, ce qui optimise les performances des bases de données. Dans l’exemple de conception, les sites Mon site et les sites d’équipe n’ont aucune exigence spécifique en matière d’isolation des données ; ils partagent le même pool d’applications. Néanmoins, ils sont placés dans des applications web distinctes pour optimiser les performances.
Faciliter la gestion
Dans la mesure où la création d’applications web distinctes conduit à des sites et des bases de données distincts, vous pouvez implémenter des limites de site différentes (corbeille, expiration et taille) et négocier des contrats de niveau de service différents. Par exemple, vous pouvez accorder plus de temps à la restauration du contenu du site Mon site s’il ne s’agit pas du contenu le plus critique de votre entreprise. Cela vous permet de restaurer du contenu plus critique avant de restaurer le contenu du site Mon site. Dans l’exemple de conception, les sites Mon site sont placés dans une application web distincte pour permettre aux administrateurs de gérer de manière plus agressive l’expansion par rapport aux autres applications.
Si vous implémentez des collections de sites nommées par l’hôte avec une application web unique, chaque site de niveau supérieur constitue un domaine distinct qui vous permet d’atteindre certains de ces objectifs, tels que la facilitation de la gestion en implémentant différentes limites de site.
Collections de sites
Pour le déploiement des sites, nous vous recommandons d’utiliser les collections de sites nommées par l’hôte avec tous les sites situés dans une même application Web. Cette configuration est recommandée pour déployer les sites car son architecture est identique à celle que l’environnement Office 365 utilise. Elle est donc 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, qui est actuellement la plus fiable.
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 2016.
Cela ne s’applique pas aux solutions de création de sites libre-service personnalisées.
Une application Web nécessite des inclusions explicites ou des inclusions génériques uniques.
Vous créez des inclusions pour les collections de sites nommées par l’hôte au niveau de la batterie de serveurs, et elles sont disponibles pour tous les sites nommés par l’hôte. Toutes les collections de sites nommées par l’hôte dans une batterie de serveurs partagent les mêmes inclusions, mais elles ne sont pas obligées de les utiliser. À l’opposé, les inclusions créées pour les collections de sites basées sur des chemins d’accès ne s’appliquent qu’à une seule application Web.
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.
Pour plus d’informations sur les collections de sites nommées par l’hôte, notamment pour obtenir une comparaison avec les collections de sites basées sur des chemins d’accès, voir Architecture et déploiement d’une collection de sites nommée par l’hôte dans SharePoint Server.
Objectifs de conception pour les collections de sites
Les collections de sites représentent le lien entre l’architecture logique et l’architecture des informations. Les collections de sites ont pour objectif de répondre aux exigences en matière de conception d’URL et de créer des divisions logiques du contenu. Pour chaque collection de sites, des chemins d’accès gérés incorporent un second niveau de collections de sites de niveau supérieur. Pour plus d’informations sur les exigences en matière d’URL et sur l’utilisation de chemins d’accès gérés, voir Zones et URL plus loin dans cet article. Au-delà du second niveau de collections de sites, chaque site est un sous-site.
Le diagramme ci-dessous illustre la hiérarchie des sites d’équipe.
Hiérarchie des sites d’équipe
.gif "Team sites")
Pour les collections de sites basées sur le chemin d’accès et les collections nommées par l’hôte, l’architecture des informations s’articule autour du second niveau de collections de sites. La section suivante explique comment les exemples de conception incorporent des choix basés sur la nature des sites.
Contenu intranet publié
L’application web de contenu intranet publié présume que plusieurs services de l’entreprise hébergeront du contenu publié. Dans l’exemple de conception, une collection de sites distincte héberge le contenu de chaque service. Cela présente divers avantages :
Chaque service peut gérer le contenu et administrer les autorisations indépendamment.
Chaque service peut stocker son contenu dans une base de données dédiée.
Les collections de sites multiples présentent les inconvénients suivants :
Vous ne pouvez pas partager les pages maîtres, les mises en page, les modèles, les composants WebPart et la navigation entre collections de sites.
La coordination des personnalisations et de la navigation entre collections de sites nécessite davantage d’efforts.
En fonction de l’architecture des informations et de la conception des sites intranet, le contenu publié peut apparaître à l’utilisateur comme une expérience transparente. Sinon, chaque collection de sites peut sembler un site web distinct.
Sites Mon site
Les sites Mon site présentent des caractéristiques distinctes et les recommandations de déploiement pour les sites Mon site sont simples. Dans les exemples de conception, la collection de sites Mon site intègre un site de niveau supérieur avec l’URL http://my. La première collection de sites de niveau supérieur créée utilise le modèle Hôte de sites Mon site. Un chemin d’accès géré est intégré (à l’aide de l’inclusion générique), ce qui permet un nombre infini de sites créés par l’utilisateur. Tous les sites sous le chemin d’accès géré sont des collections de sites indépendantes qui utilisent le modèle Site personnel. Le nom d’utilisateur est ajouté à l’URL sous la forme http://my/personal/nom_utilisateur. Le diagramme ci-dessous illustre les sites Mon site.
Hiérarchie des sites Mon site
.gif "My Sites")
Sites d’équipe
Vous pouvez utiliser l’une des deux approches suivantes pour concevoir des collections de sites dans une application Site d’équipe :
Autoriser les équipes à créer des collections de sites via la création de sites libre-service. L’avantage de cette approche est que les équipes peuvent facilement créer un site, en fonction de leurs besoins, sans l’assistance d’un administrateur. Les inconvénients de cette approche sont les suivants :
Vous perdez la possibilité d’implémenter une taxonomie complète.
Vous ne pouvez pas partager des modèles et la navigation avec d’autres projets et équipes, qui pourraient sinon partager une collection de sites.
Créer un nombre limité de collections de sites pour votre entreprise en fonction de son mode de fonctionnement. Dans cette approche, un administrateur SharePoint crée les collections de sites. Une fois une collection de sites créée, les équipes peuvent créer des sites dans la collection de sites. Cette approche laisse la possibilité d’implémenter une taxonomie complète qui permet de structurer la manière dont les sites d’équipe sont gérés et se développent. Elle laisse par ailleurs davantage de possibilités de partager des modèles et la navigation entre les projets et les équipes qui partagent une collection de sites. Toutefois, cette approche présente également certains inconvénients.
Les exemples de conception utilisent cette seconde approche, laquelle permet d’obtenir une collection de sites similaire pour les sites d’équipe et le contenu intranet publié. Le défi pour les architectes des informations est de créer un second niveau de collections de sites qui ait du sens pour l’organisation. Le tableau suivant suggère différents types d’organisations.
Tableau : Taxonomies de collection de sites suggérées
| Type d’organisation | Taxonomies de collection de sites suggérées |
|---|---|
Développement de produits |
|
Recherche |
|
Établissements d’enseignement supérieur |
|
Bureau législatif |
|
Cabinet d’avocats d’entreprise |
|
Fabrication |
|
Application Web partenaire
Une application web partenaire est destinée à être utilisée pour la collaboration avec des partenaires externes sur des projets dont l’objet est bien défini ou la durée limitée. De par leur conception, les sites de l’application web partenaire ne sont pas destinés à être liés. Parmi les exigences d’une application web partenaire, vous devez veiller à ce que :
les propriétaires des projets puissent facilement créer des sites pour la collaboration entre les partenaires ;
les partenaires et autres contributeurs ne puissent accéder qu’au projet sur lequel ils travaillent ;
les propriétaires de site gèrent les autorisations ;
les résultats de recherche au sein d’un projet n’exposent pas le contenu d’autres projets ;
les administrateurs puissent facilement identifier les sites qui ne sont plus utilisés et les supprimer.
Pour répondre à ces exigences, l’exemple de conception intègre une collection de sites pour chaque projet. Les deux exemples de conception de portail d’entreprise utilisent un chemin d’accès géré pour créer un second niveau de collections de sites sous une collection de sites racine. Pour sa part, l’exemple de conception d’extranet convertit chaque site partenaire en collection de sites de niveau supérieur en utilisant des collections de sites nommées par l’hôte. Dans un cas comme dans l’autre, les différentes collections de sites offrent le niveau approprié d’isolation entre les projets.
Si vous envisagez d’utiliser la fonctionnalité de création de sites libre-service qui fait partie de l’installation par défaut de SharePoint Server (par opposition à une solution personnalisée développée pour votre organisation), utilisez des collections de sites basées sur le chemin d’accès. Les collections de sites nommées par l’hôte ne fonctionnent pas encore avec cette fonctionnalité.
Bases de données de contenu
Vous pouvez utiliser les deux approches suivantes pour incorporer des bases de données de contenu dans la conception (l’exemple de conception intègre ces deux approches) :
Établir des tailles cibles pour les bases de données de contenu avec des seuils d’avertissement de taille appropriés. Créer une base de données lorsqu’une base de données atteint les seuils d’avertissement de taille. Avec cette approche, les collections de sites sont automatiquement ajoutées aux bases de données disponibles, en fonction uniquement des objectifs de taille. Cette approche est la plus courante.
Associer des collections de sites à des bases de données de contenu spécifiques. Cette approche vous permet de placer une ou plusieurs collections de sites dans une base de données dédiée que les administrateurs peuvent gérer indépendamment du reste.
Si vous choisissez d’associer des collections de sites à des bases de données de contenu spécifiques, vous pouvez utiliser les méthodes suivantes pour y parvenir :
Utilisez PowerShell pour créer une collection de sites dans une base de données spécifique.
Dédiez une base de données à une collection de sites unique en appliquant les paramètres de capacité de base de données suivants :
Nombre de sites avant qu’un événement d’avertissement ne soit généré = 1
Nombre maximal de sites pouvant être créés dans cette base de données = 1
Ajoutez un groupe de collections de sites à une base de données dédiée en procédant comme suit :
Dans l’application Web, créez la base de données et définissez son état sur Prêt.
Définissez l’état de toutes les autres bases de données sur Hors connexion. Lorsque les bases de données de contenu sont hors connexion, aucune nouvelle collection de sites ne peut être créée. Toutefois, les collections de sites existantes dans les bases de données hors connexion sont accessibles à la fois pour les opérations de lecture et d’écriture.
Créer les collections de sites. Elles sont automatiquement ajoutées aux bases de données.
Rétablissez l’état de toutes les autres bases de données sur Prêt.
Contenu intranet publié
Pour le contenu intranet publié, les exemples de conception de portail d’entreprise intègrent une base de données unique pour faciliter la gestion. Ajoutez si nécessaire des bases de données reposant sur des objectifs de taille cible.
Sites Mon site
Pour les sites Mon site, les exemples de conception de portail d’entreprise font des économies d’échelle en gérant les bases de données jusqu’à la taille cible maximale. Les paramètres suivants sont configurés pour atteindre cet objectif :
Limiter le stockage du site à une valeur maximale de : ce paramètre, configuré dans la page Modèles de quotas de l’Administration centrale, limite la taille d’un site personnel.
Corbeille secondaire : ce paramètre, configuré dans la page Paramètres généraux de l’application web, détermine la quantité d’espace supplémentaire allouée à la corbeille secondaire.
Nombre maximal de sites pouvant être créés dans cette base de données : ce paramètre est configuré lors de la création d’une base de données. Calculez la taille totale des sites pouvant être allouée en utilisant les nombres spécifiés dans les deux valeurs précédentes. Ensuite, en fonction de l’objectif de taille de chaque base de données, déterminez combien de sites la base de données pourra contenir.
Les exemples de conception donnent les exemples de paramètres de taille suivants reposant sur une taille de base de données cible de 175 gigaoctets (Go) et une taille de site Mon site cible d’1 Go :
Limite de taille de chaque site = 1 Go
Taille cible de la base de données = 175 Go
Réservé pour la corbeille secondaire = 15 %
Nombre maximal de sites = 180
Avertissements relatifs au niveau du site = 150
Quand l’avertissement relatif au niveau du site est atteint, créez une base de données. Une fois cette opération effectuée, les nouveaux sites Mon site sont ajoutés à la base de données de contenu qui contient le plus petit nombre de collections de sites.
Sites d’équipe
Dans la plupart des organisations, les sites d’équipe seront beaucoup plus volumineux que les sites Mon site. Ils sont créés sous un chemin d’accès géré, ce qui autorise une base de données de contenu par collection de sites d’équipe. L’exemple de conception propose des paramètres de base de données reposant sur une limite de 30 Go pour les collections de sites. Choisissez une limite appropriée pour les sites d’équipe dans votre organisation.
Site Web partenaire
Comme les sites Mon site, le site Web partenaire réalise des économies d’échelle en gérant les bases de données jusqu’à la taille cible maximale.
Les exemples de conception proposent les paramètres de taille suivants :
Taille cible de la base de données = 200 Go
Quota de stockage par site = 5 Go
Nombre maximal de sites = 40
Collection de sites de création hébergée dans une base de données dédiée
Zones et URL
Les exemples de conception illustrent la manière de coordonner les URL à travers plusieurs sites au sein d’un déploiement en entreprise. Les objectifs suivants influent sur les décisions de conception au niveau des URL :
Les conventions en matière d’URL ne limitent pas les zones via lesquelles les utilisateurs peuvent accéder au contenu.
Les ports HTTP et HTTPS standard (80 et 443) peuvent être utilisés dans toutes les applications de l’exemple de conception.
Les numéros de port ne sont pas inclus dans les URL. En pratique, les numéros de port ne sont généralement pas utilisés dans les environnements de production.
Conception d’URL à charge équilibrée
Quand vous créez une application web, vous devez choisir l’URL avec équilibrage de la charge réseau qui est affectée à l’application. L’URL que vous choisissez s’applique à la zone Par défaut. Vous devez par ailleurs créer une URL avec équilibrage de la charge réseau pour chaque zone supplémentaire que vous créez dans une application web. Les URL avec équilibrage de la charge réseau incluent le protocole, le schéma, le nom d’hôte et le port, le cas échéant. L’URL avec équilibrage de la charge réseau doit être unique dans toutes les applications web et dans toutes les zones. Ainsi, chaque application et chaque zone de chaque application nécessitent une URL unique dans l’ensemble du modèle de conception.
Intranet
Chacune des trois collections de sites qui composent l’intranet nécessite une URL unique. Dans les exemples de conception de portail d’entreprise, l’audience cible du contenu intranet est constituée des employés internes et des employés distants. Les employés utilisent les mêmes URL pour chacun de ces sites qu’ils soient sur site ou à distance. Cette approche ajoute une couche de sécurité à la conception SharePoint (tout le trafic utilise le protocole SSL). Toutefois, elle vous oblige à affiner la configuration en effectuant, au choix, l’une des deux tâches suivantes :
Router le trafic interne via le produit de pare-feu ou de passerelle avec le trafic distant.
Créer un environnement DNS scindé pour résoudre les demandes internes dans le réseau interne.
Site Web partenaire
Dans les exemples de conception, les employés internes, les employés distants et les employés partenaires accèdent au site web partenaire. Dans les exemples de conception de portail d’entreprise, tous les utilisateurs entrent la même URL indépendamment de la méthode d’authentification. Dans l’exemple de conception d’extranet, chaque type différent d’utilisateur entre une URL spécifique. Même si les partenaires individuels et les sociétés partenaires utilisent le protocole SSL (HTTPS) pour accéder au site web partenaire depuis l’extérieur, chaque groupe nécessite une URL différente pour profiter des avantages liés aux zones distinctes ; autrement dit, des méthodes d’authentification différentes et des stratégies de zone différentes.
Les employés distants et les employés internes utilisent les mêmes URL, car l’exemple de conception d’extranet utilise l’accès direct ou le réseau privé virtuel pour l’accès des employés distants. Si l’accès des employés distants est configuré par le biais d’un dispositif de proxy inverse, les employés distants nécessitent une URL distincte utilisant le protocole SSL, ce qui suppose l’utilisation d’une zone supplémentaire. Enfin, l’exemple de conception d’extranet comporte des collections de sites nommées par l’hôte au lieu d’une collection de sites de niveau supérieur unique. Ainsi, chaque site de projet possède une URL différente.
Le tableau suivant indique des exemples d’URL utilisées par les employés internes, les employés distants et les partenaires pour accéder au site web partenaire, comme indiqué dans l’exemple de conception d’extranet.
Tableau : Exemples d’URL tirés de l’exemple de conception d’extranet
| Zone | Exemple d’URL |
|---|---|
Employés internes et distants |
http://project1 |
Partenaires individuels |
https://project2.fabrikam.com |
Sociétés partenaires |
https://TrustedPartnerProject1.fabrikam.com |
Utilisation d’inclusions explicites et génériques pour les chemins d’URL
Les chemins d’accès gérés vous permettent de spécifier les chemins de l’espace de noms d’URL d’une application web qui sont utilisés pour les collections de sites. Vous pouvez spécifier qu’une collection de sites ou plus existent au niveau d’un chemin distinct sous le site racine. Sans les chemins d’accès gérés, tous les sites sous la collection de sites racine font partie de la collection de sites racine.
Vous pouvez créer les deux types de chemins d’accès gérés suivants :
Inclusion explicite : une collection de sites avec l’URL explicite que vous lui affectez. Une inclusion explicite est appliquée à une seule collection de sites. Vous pouvez créer de nombreuses inclusions explicites sous une collection de sites racine. http://intranet/hr est un exemple d’URL pour une collection de sites créée à l’aide de cette méthode. Les chemins d’accès explicites ont un impact sur les performances. Il est donc recommandé de limiter à environ 20 le nombre de collections de sites créées avec une inclusion explicite.
Inclusion générique : un chemin qui est ajouté à l’URL. Ce chemin indique que tous les sites spécifiés directement après le nom du chemin sont des collections de sites uniques. Cette option est généralement utilisée pour les collections de sites prenant en charge la création de sites self-service, comme les sites Mon site. http://my/personal/user1 est un exemple d’URL pour une collection de sites créée à l’aide de cette méthode.
Quand des chemins d’accès gérés pour des collections de sites nommées par l’hôte sont implémentés, ils sont créés au niveau de la batterie de serveurs et s’appliquent à l’ensemble des applications web, si plusieurs applications web sont incluses dans la solution. Quand des chemins d’accès gérés pour des sites basés sur le chemin d’accès sont implémentés, ils ne s’appliquent qu’à l’application web dans laquelle ils ont été créés.
L’exemple de conception intègre l’utilisation de ces deux types de chemins d’accès gérés (inclusions explicites et inclusions génériques), comme décrit dans les sections qui suivent.
Inclusions explicites : contenu intranet publié
Dans les exemples de conception, la collection de sites de contenu intranet publié comporte des inclusions explicites pour chaque sous-site, par exemple, HR, Facilities et Purchasing. Chacune de ces collections de sites peut être associée à une base de données de contenu distincte si nécessaire. Sauf si des collections de sites nommées par l’hôte sont utilisées, l’utilisation d’inclusions explicites dans cet exemple suppose qu’aucun autre type de site n’est créé dans l’application web, y compris des inclusions génériques.
L’utilisation d’inclusions explicites donne les URL suivantes :
Dans cet exemple, la collection de sites racine, http://intranet.fabrikam.com, représente la page d’accueil par défaut de l’intranet. Ce site est destiné à héberger le contenu pour les utilisateurs.
Inclusions génériques : sites d’équipe, sites Mon site et application Web partenaire
Les sites d’équipe, les sites Mon site et l’application web partenaire intègrent l’utilisation d’une inclusion générique. Les inclusions génériques sont idéales pour les applications permettant aux utilisateurs de créer leurs propres collections de sites et pour les applications web qui incluent de nombreuses collections de sites. Une inclusion générique indique que l’élément qui suit le caractère générique est un site racine d’une collection de sites.
Sites d’équipe
Dans l’application Sites d’équipe, l’inclusion générique est utilisée pour chaque collection de sites d’équipe. Il est recommandé de maintenir le nombre de sites d’équipe de niveau supérieur à un nombre gérable. Par ailleurs, la taxonomie des sites d’équipe doit être logique pour le fonctionnement de votre entreprise.
L’utilisation d’inclusions génériques donne les URL suivantes :
Dans cet exemple, la collection de sites racine, https://teams.fabrikam.com, n’héberge pas nécessairement du contenu pour les utilisateurs.
Sites Mon site
Les sites Mon site proposent la création de sites libre-service. Lorsqu’un utilisateur qui navigue sur l’intranet clique pour la première fois sur Mon site, un site Mon site est automatiquement créé pour l’utilisateur. Dans l’exemple de conception, les sites Mon site intègrent une inclusion générique nommée /personal (http://my/personal). La fonctionnalité Mon site ajoute automatiquement le nom d’utilisateur à l’URL.
Cela donne des URL au format suivant :
Site Web partenaire
Si des collections de sites basées sur le chemin d’accès sont utilisées, vous pouvez implémenter la fonctionnalité de création de sites libre-service pour permettre aux employés de créer des sites sécurisés pour la collaboration avec des partenaires externes. Si des collections de sites nommées par l’hôte sont utilisées, vous pouvez implémenter une fonctionnalité de création de sites libre-service personnalisée, ou les administrateurs peuvent créer des sites de projet partenaires sur demande.
Dans les exemples de conception de portail d’entreprise, l’application web partenaire intègre une inclusion générique nommée /sites (http://partnerweb/sites). Cela donne des URL au format suivant :
Coordination des URL avec le mappage des accès de substitution et le DNS
Si des collections de sites basées sur le chemin d’accès sont implémentées, configurez des mappages des accès de substitution pour chaque URL de site dans la batterie de serveurs. Ainsi, les demandes web sont mappées sur le site correct, notamment dans les environnements qui utilisent l’équilibrage de charge ou des technologies de proxy inverse.
Les URL à nom unique, telles que http://teams, peuvent être configurées pour l’accès intranet. Un ordinateur client résout ces URL en ajoutant son suffixe DNS, tel que fabrikam.com, puis en émettant une recherche de DNS portant sur le nom suivi du suffixe. Par exemple, lorsqu’un ordinateur client dans le domaine fabrikam.com demande http://teams, il envoie une demande au DNS portant sur http://teams.fabrikam.com.
Le DNS doit être configuré pour utiliser un enregistrement A, ou AAAA pour IPv6, pour chaque nom de domaine complet. L’enregistrement pointe sur l’adresse IP à charge équilibrée des serveurs web qui hébergent un site. Dans un déploiement de production typique, les serveurs sont configurés pour utiliser des adresses IP affectées statiquement, outre des enregistrements A ou AAAA affectés statiquement dans le DNS.
Dès qu’un navigateur client reçoit l’adresse IP à charge équilibrée, il se connecte à un serveur web frontal dans la batterie de serveurs, puis envoie une requête HTTP qui comporte l’URL à nom unique initiale, http://teams. IIS et SharePoint Server déterminent qu’il s’agit d’une demande pour la zone Intranet, grâce aux paramètres configurés dans les mappages des accès de substitution. Par contre, si un utilisateur demande https://teams.fabrikam.com, le processus est similaire, mais IIS et SharePoint Server reçoivent ce nom de domaine complet et en concluent que la demande concerne la zone Par défaut.
Dans les environnements qui comportent plusieurs domaines, entrez des enregistrements CNAME pour le DNS dans les domaines qui n’hébergent pas les sites. Par exemple, si l’environnement réseau Fabrikam comprend un second domaine nommé europe.fabrikam.com, les enregistrements CNAME sont entrés pour ces sites dans le domaine Europe. Pour le site intranet des sites d’équipe (http://teams), un enregistrement CNAME nommé teams pointant vers teams.fabrikam.com est ajouté au domaine europe.fabrikam.com. Ensuite, quand le suffixe DNS d’un ordinateur client est ajouté à des demandes de recherche de DNS, une demande portant sur http://teams à partir du domaine Europe émet une recherche de DNS pour teams.europe.fabrikam.com et est redirigée par l’enregistrement CNAME vers teams.fabrikam.com.
Notes
Un problème connu concernant la résolution des enregistrements CNAME affecte certains clients qui utilisent l’authentification Kerberos. Pour plus d’informations, voir Kerberos configuration known issues (SharePoint Server 2010).
Stratégies de zone
Vous pouvez configurer des stratégies pour une ou plusieurs zones afin d’appliquer des autorisations pour tout le contenu d’une application web. En mode Revendications, une stratégie ne peut être définie que pour une zone spécifique (non pour l’application web en général). Une stratégie applique les autorisations à l’ensemble du contenu auquel les utilisateurs accèdent par le biais d’une zone. Les autorisations d’une stratégie remplacent tous les autres paramètres de sécurité qui sont configurés pour les sites et pour le contenu. Vous pouvez configurer la stratégie en fonction d’utilisateurs ou de groupes d’utilisateurs, mais pas en fonction de groupes SharePoint. Si vous ajoutez ou modifiez une stratégie de zone, la recherche doit réanalyser les sites pour appliquer les nouvelles autorisations.
Les exemples de conception n’utilisent pas de stratégies, car plusieurs types d’authentification sont activés sur une zone unique et/ou tous les sites appartiennent à la même application web.