Exemples de conception SharePoint Server : sites de portail d’entreprise et extranet

Article
03/08/2023

S’APPLIQUE À : oui-img-13 2013 oui-img-16 2016 oui-img-19 2019 oui-img-se Édition d’abonnement no-img-sop SharePoint dans Microsoft 365

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.

Importante

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.

Remarque

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 Host-named site collection architecture and deployment (SharePoint 2013)). Cette conception est recommandée, car il s’agit de la même architecture que celle utilisée par l’environnement Microsoft 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.	Collections de sites basées sur des chemins d’accès Authentification basée sur les revendications Fournisseurs d’authentification multiples et types d’authentification implémentés dans une zone unique
Portail d’entreprise avec sites nommés par l’hôte	Principaux types de sites déployés dans une organisation.	Collections de sites nommées par l’hôte Authentification basée sur les revendications Fournisseurs d’authentification multiples et types d’authentification implémentés dans une zone unique
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.	Collections de sites nommées par l’hôte Authentification basée sur les revendications Zone différente pour chaque méthode d’authentification

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

Sites intranet

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 avec SQL Server installés et configurés pour prendre en charge SQL Server clustering, mise en miroir ou Always On. Always On nécessite SQL Server 2012.

Le concept de serveur frontal et de serveur d’applications est différent dans SharePoint Server 2016. Voir Vue d’ensemble des rôles de serveur MinRole dans SharePoint Server

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

Les revendications sont le mode d’authentification par défaut dans SharePoint Server et chaque exemple de conception incorpore l’authentification basée sur les revendications. Vous pouvez utiliser Windows PowerShell pour implémenter l’authentification en mode classique. Toutefois, 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 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

Approche	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 : Annuaire LDAP utilisant l’authentification basée sur les formulaires Forêt AD DS (Active Directory Domain Services) tournée vers l’extérieur avec une approbation à sens unique vers la forêt interne et l’authentification Windows intégrée Fournisseur d’identité approuvé avec authentification SAML
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

Architecture des services

Le déploiement de services partitionnés ajoute de la complexité à l’architecture et complique la migration des sites vers Microsoft 365 ultérieurement. 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 différents. Un pool d’applications héberge du contenu collaboratif (Mes sites et sites d’équipe). Un pool d’applications distinct héberge le contenu intranet publié. Cette configuration fournit une isolation des processus pour le contenu intranet publié dans lequel les connexions de données métiers sont plus susceptibles d’être 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 des sites, car il s’agit de la même architecture que celle utilisée par l’environnement Microsoft 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, 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 (SharePoint 2013).

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

Sites d’équipe

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.

Mes sites

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 Mes sites incorpore un site de niveau supérieur avec l’URL de 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://mynom_utilisateur. Le diagramme ci-dessous illustre les sites Mon site.

Hiérarchie de site Mes sites

Mes 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 des 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	Créer une collection de sites pour chaque produit en cours de développement. Autoriser les équipes contributives à créer des sites dans la collection de sites. Pour chaque projet de développement à long terme, créer une collection de sites pour chaque grosse équipe qui contribue au produit. Vous pouvez par exemple créer une collection de sites pour chacune des équipes suivantes : concepteurs, ingénieurs et développeurs de contenu.
Recherche	Créer une collection de sites pour chaque projet de recherche à long terme. Créer une collection de sites pour chaque catégorie de projets de recherche.
Établissements d’enseignement supérieur	Créer une collection de sites pour chaque département universitaire.
Bureau législatif	Créer une collection de sites pour chaque parti politique. Les membres officiels du gouvernement qui partagent une affiliation à un parti peuvent partager des modèles et la navigation. Créer une collection de sites pour chaque comité. Ou créer une collection de sites pour tous les comités.
Cabinet d’avocats d’entreprise	Créer une collection de sites pour chaque entreprise cliente.
Fabrication	Créer une collection de sites pour chaque gamme de produits