0. Déploiement de Sharepoint 2019 – Partie 1

0.1 Résumé de la publication

Mettez à jour vers une version de SharePoint qui offre le meilleur à la fois sur site et dans le cloud à l’aide de SharePoint 2019, la dernière version de cette technologie clé de Microsoft. Enfilez votre chapeau d’apprentissage technique pour vous familiariser avec les nouvelles fonctionnalités modernes de gain de temps sur site et les nombreux nouveaux paramètres de sécurité et hybrides.

Le déploiement de SharePoint 2019 commence par une introduction générale à SharePoint 2019, couvrant de nouvelles fonctionnalités et élargissant systématiquement vos connaissances et capacités avec la technologie. Vous en apprendrez plus sur le nouveau monde de SharePoint et comment il est «né dans le cloud» d’Office 365. À partir de là, vous découvrirez comment concevoir une architecture physique pour SharePoint Server 2019 et vous familiariser avec les concepts clés de la haute disponibilité (HA) et de reprise après sinistre (DR).

0.2 Objectifs de la publication

  • Installer, configurer et optimiser SharePoint 2019
  • Comprendre SharePoint 2019 comme un cadre hybride
  • Familiarisez-vous avec de nouveaux outils, tels que Flow, PowerApps et Power BI
  • Configurer des systèmes connectés à SharePoint, tels que Office Online Server et Workflow Manager
  • Migrer les bases de données de contenu et de service des versions précédentes de SharePoint vers SharePoint 2019
  • Mettre en œuvre des topologies HA et DR avec SharePoint 2019 pour répondre aux exigences de continuité des activités

0.3 Lien vers la partie 2

1 CHAPITRE 1 Introduction à SharePoint 2019

Dans ce chapitre, nous présenterons SharePoint 2019, un peu d’histoire sur la provenance de SharePoint et les objectifs de Microsoft pour la version 2019. Nous aurons également un aperçu de haut niveau des nouvelles fonctionnalités de SharePoint 2019 ainsi que quelques fonctionnalités obsolètes ou qui ne sont plus disponibles.

1.1 Un peu d’histoire SharePoint

SharePoint 2019 est la septième version de SharePoint Server que Microsoft a livrée au public. Lancé pour la première fois en 2001, SharePoint Portal Server (le nom à l’époque) n’était nulle part aussi populaire qu’aujourd’hui. Il a fallu quelques versions, mais à partir d’Office SharePoint Server 2007 (MOSS), SharePoint est passé d’un CD que Microsoft a donné, y compris 25 licences utilisateur, à l’un des produits les plus lucratifs de Microsoft. Après avoir innové SharePoint avec chaque version depuis, il y a maintenant plus de 250 000 organisations, dont 85% du Fortune 500.

Alors que ces dernières années, l’objectif principal de Microsoft a été d’innover SharePoint Online, une partie d’Office 365, de nombreux clients utilisent encore SharePoint Server pour leurs besoins de collaboration, et Microsoft ne les a pas oubliés. Microsoft apporte toujours de nouvelles fonctionnalités au cloud en premier, et parfois uniquement au cloud, et avec chaque version sur site depuis SharePoint 2016, la plupart des fonctionnalités sont intégrées dans une version de SharePoint sur site.

SharePoint Server 2016 est la première version de SharePoint Server qui est «née dans le cloud» et a apporté de nombreuses améliorations aux applications locales qui ont été créées et testées dans le cloud. Certaines de ces fonctionnalités incluent la topologie MinRole, Zero Downtime Patching, les binaires communs et les mises à jour avec Project Server et plus encore. SharePoint 2016 a apporté de nombreuses améliorations de performances et de stabilité sur site, mais de nombreux utilisateurs professionnels n’ont pas été impressionnés par le petit nombre de nouvelles fonctionnalités destinées aux utilisateurs professionnels.

Avant de parler des nouveautés de SharePoint 2019, remontons le temps et examinons les principales fonctionnalités publiées dans chaque version de SharePoint depuis le début. Dans la figure 1-1, vous pouvez afficher un peu de l’historique SharePoint et les fonctionnalités importantes introduites par chaque version.

Figure 1-1. Un petit historique des nouvelles fonctionnalités dans chaque version de SharePoint

Bien que SharePoint Server 2019 apporte encore de nouvelles fonctionnalités pour les professionnels de l’informatique, la plupart des nouvelles fonctionnalités de cette version sont destinées aux utilisateurs finaux. Voyons plus en détail ce que cette version de SharePoint a à offrir !

1.2 Nouveautés de SharePoint Server 2019

Si vous avez suivi de grandes annonces dans Office 365 au cours des dernières années, il sera assez facile de comprendre ce que Microsoft nous a préparé dans SharePoint Server 2019 !

1.2.1 Expériences SharePoint modernes

Après avoir été utilisé par des millions d’utilisateurs dans Office 365, l’évolution la plus importante de SharePoint au cours des dernières années l’a finalement fait sur site. Les expériences SharePoint modernes incluent les sites d’équipe SharePoint modernes et les sites de communication, ainsi que la nouvelle expérience dans les listes et les bibliothèques de documents. Jetons un regard plus approfondi sur chacune de ces expériences

1.2.1.1 Sites d’équipe SharePoint modernes

Le premier pilier des expériences SharePoint modernes est les sites d’équipe modernes illustrés à la figure 1-2. Les sites d’équipe modernes sont réactifs par défaut, incluent un moteur de publication de nouveau prêt à l’emploi, permettant aux utilisateurs de partager des nouvelles avec le reste de l’équipe. Contrairement à Office 365 où la plupart des sites d’équipe modernes sont connectés à un groupe Office 365, les sites d’équipe modernes sur site n’ont besoin d’aucune intégration avec Exchange pour fonctionner correctement.

Figure 1-2. Sites d’équipe modernes

1.2.1.2 Sites de communication SharePoint modernes

Le prochain pilier des expériences SharePoint modernes est les sites de communication modernes. Les sites de communication sont des sites qui sont principalement utilisés pour partager des nouvelles, des politiques et des informations avec les utilisateurs inclus. SharePoint Server 2019 comprend trois modèles différents de sites de communication : vierge, sujet et vitrine. Vous pouvez afficher un site de communication moderne dans la figure 1-3.

Figure 1-3. Site de communication moderne

1.2.1.3 Listes et bibliothèques modernes

En approfondissant nos sites, SharePoint Server 2019 prend également en charge les listes et bibliothèques SharePoint modernes. Les bibliothèques SharePoint modernes, illustrées à la figure 1-4, permettent aux utilisateurs d’afficher rapidement des informations sur leurs documents, y compris les autorisations et les métadonnées. Une autre fonctionnalité utile d’Office 365 ajoutée à SharePoint 2019 est les actions « Déplacer vers » et « Copier vers », permettant aux utilisateurs de changer rapidement l’emplacement d’un document en un emplacement plus approprié.

Figure 1-4. Bibliothèque de documents moderne

Les listes SharePoint modernes dans SharePoint 2019 incluent également la fonctionnalité de mise en forme conditionnelle illustrée à la figure 1-5. La mise en forme conditionnelle permet aux utilisateurs expérimentés de configurer différentes règles d’affichage pour des colonnes spécifiques, afin de visualiser rapidement l’état de cet élément.

Figure 1-5. Mise en forme conditionnelle

1.2.1.4 Expérience de recherche moderne

La dernière pièce de SharePoint moderne pour en faire sur site dans SharePoint Server 2019 est la recherche moderne. L’expérience de recherche moderne, illustrée à la figure 1-6, permet aux utilisateurs de trouver plus facilement des documents, des éléments de liste et des personnes dans l’environnement SharePoint.

Figure 1-6. Recherche moderne dans SharePoint 2019

1.2.2 La maison SharePoint

Notre prochaine nouvelle fonctionnalité importante dans SharePoint sur site est le SharePoint Home.

Le SharePoint Home, illustré à la figure 1-7, rassemble toutes les nouvelles des sites d’équipe et des sites de communication en un seul endroit. Tous les sites que vous suivez sont également regroupés, y compris l’activité de chaque site et un accès rapide à vos sites préférés.

Figure 1-7. Accueil SharePoint

1.2.3 Prise en charge améliorée de SharePoint Framework

Une autre nouvelle fonctionnalité de cette version de SharePoint est que SharePoint Server 2019 prend désormais en charge SharePoint Framework 1.4.1 pour permettre aux développeurs de créer des composants WebPart modernes qui fonctionnent à la fois pour SharePoint Online et pour SharePoint sur site. Avec SharePoint Server 2019, les développeurs peuvent utiliser des Webhooks pour les éléments de liste, les composants WebPart et extensions SharePoint Framework côté client dans les expériences modernes, ainsi que le regroupement d’actifs et l’hébergement de fichiers JavaScript automatique à partir du catalogue d’applications.

1.2.4 Synchronisation OneDrive avec le nouveau client OneDrive

SharePoint Server 2019 permet aux organisations qui exécutent SharePoint sur site de bénéficier des dernières améliorations dans OneDrive et Windows 10. SharePoint 2019 fonctionne avec la dernière version de OneDrive, également connue sous le nom de client de synchronisation de nouvelle génération (NGSC) et prend en charge les dernières innovations dans des fenêtres telles que Files on Demand

1.3 Fonctions obsolètes et supprimées

Alors que SharePoint Server 2019 nous apporte de nouvelles fonctionnalités fantastiques, nous en avons également perdu quelques-unes.

La plupart de ces fonctionnalités que nous avons pu voir arriver à l’avance, car elles ont déjà été dépréciées ou supprimées d’Office 365. Dans cette section, nous ne présenterons que la liste des fonctionnalités et spécifierons le chapitre dans lequel leurs implications seront expliquées plus en détail.

Remarque En termes de logiciel, la dépréciation est un statut appliqué aux fonctionnalités pour indiquer qu’elles doivent être évitées, généralement parce qu’il existe une meilleure façon de faire la même fonctionnalité. Ces fonctionnalités sont toujours disponibles dans Sharepoint Server 2019, principalement pour des raisons de compatibilité descendante, afin de donner aux entreprises le temps de les remplacer par de nouveaux outils. Ces fonctionnalités seront finalement entièrement supprimées des futures versions de Sharepoint.

1.3.1 Services d’accès 2010 et 2013

Access Services 2010 et 2013 a permis aux utilisateurs de visualiser les fichiers de la base de données Access directement dans le navigateur. Access Services 2013 a également permis aux utilisateurs de créer des applications d’accès personnalisées pouvant être utilisées via SharePoint comme celle illustrée à la figure 1-8. Alors que dans Office 365, ces services ne sont plus pris en charge, ils sont obsolètes, mais font toujours partie de SharePoint Server 2019.

Figure 1-8. Services d’accès dans SharePoint 2016

1.3.2 Services InfoPath

InfoPath permet aux utilisateurs avancés et aux développeurs de créer des formulaires personnalisés pour les listes SharePoint. InfoPath 2013 étant la dernière version d’InfoPath, les services InfoPath associés dans SharePoint 2019 sont désormais également obsolètes.

1.3.3 Traduction automatique et variations

Le service de traduction automatique qui permettait aux utilisateurs de traduire automatiquement des sites et des pages dans une autre langue est désormais déconseillé dans SharePoint Server 2019. Les variantes sont également toujours prises en charge mais déconseillées dans cette version de SharePoint.

1.3.4 Services PerformancePoint

PerformancePoint a permis aux spécialistes de la Business Intelligence de créer des tableaux de bord et des rapports puissants et de les afficher dans SharePoint. Avec la plate-forme reposant fortement sur Silverlight et sur des options plus modernes disponibles telles que Power BI Server, PerformancePoint Services est devenu obsolète dans SharePoint 2019.

1.3.5 Boîte aux lettres du site

La boîte aux lettres de site a permis aux sites d’équipe SharePoint d’avoir une boîte aux lettres partagée pouvant être consommée par les membres du site directement à partir de SharePoint, comme illustré à la figure 1-9. Cette fonctionnalité a été supprimée d’Office 365 et elle est toujours incluse, mais déconseillée, dans SharePoint Server 2019.

Figure 1-9. Boîte aux lettres du site

1.3.6 Solutions Sandbox avec code

Les solutions sandbox qui incluent du code ont été supprimées dans SharePoint Online depuis 2016, et la limitation s’applique désormais également à SharePoint Server 2019. SharePoint 2019 vous permet toujours de créer des solutions sandbox déclaratives.

1.3.7 Multi-location

Introduite pour la première fois dans SharePoint 2013, l’hébergement multiclient vous a permis d’utiliser SharePoint sur site en tant que plateforme à locataires multiples. Cette fonctionnalité a été complètement supprimée de SharePoint Server 2019, et les clients qui en ont besoin devront rester sur SharePoint Server 2016.

1.3.8 Galerie PowerPivot

Avec la sortie d’options plus modernes telles que Power BI Server On-Premises disponibles pour les utilisateurs, Microsoft a complètement supprimé la galerie PowerPivot dans SharePoint Server 2019.

1.3.9 Mode intégré SSRS

Les installations SSRS en mode intégré SharePoint ne sont plus disponibles dans SharePoint Server 2019. Vous pouvez toujours installer SSRS en mode natif avec une meilleure intégration qu’auparavant.

1.3.10 Rendu Silverlight dans Visio Services

Silverlight étant une plate-forme du passé et la prise en charge prenant fin le 12 octobre 2021, le rendu basé sur Silverlight dans Visio Services est désormais entièrement supprimé de SharePoint Server 2019.

1.4 Quelques notes et prochaines étapes

Maintenant que nous connaissons les améliorations que SharePoint Server 2019 peut offrir, dans le chapitre suivant, nous allons apprendre à concevoir notre topologie de batterie de serveurs SharePoint 2019 pour obtenir des performances et une stabilité maximale avec une variété d’options potentielles.

2 CHAPITRE 2 Conception d’une architecture physique

Dans ce chapitre, nous examinerons les architectures physiques pour SharePoint Server 2019, ainsi que la mise en réseau, la virtualisation et d’autres considérations sur la batterie de serveurs.

Les décisions sur les architectures dépendent de la taille du contenu, de la prise en charge simultanée des utilisateurs, du nombre total d’utilisateurs et bien sûr des considérations monétaires. Bien que cet article couvre une architecture hautement disponible avec reprise après sinistre, de nombreuses architectures restent valables pour une variété de cas d’utilisation et doivent être conçues en fonction de votre cas d’utilisation et de vos exigences.

2.1 Architecture de la batterie de serveurs SharePoint Server 2019

Le choix d’une architecture de batterie de serveurs est une décision difficile, d’autant plus que SharePoint n’a jamais été précédemment déployé dans l’environnement.

Décider d’une architecture de ferme repose en grande partie sur ces facteurs :

  • Investissements monétaires disponibles pour les licences matérielles et logicielles
  • Exigences de haute disponibilité et de reprise après sinistre (RTO / RPO)
  • Taille de contenu prévue
  • Nombre total d’utilisateurs
  • Nombre d’utilisateurs simultanés prévu
  • Services fournis

Tous ces éléments jouent un rôle dans la détermination des exigences matérielles et logicielles. Pour les entreprises qui implémentent une batterie de serveurs SharePoint pour la première fois, la taille de contenu prévue et le nombre d’utilisateurs simultanés peuvent ne pas être facilement déterminés, mais il existe des outils de génération de charge que ce chapitre abordera pour vous aider à déterminer ce qui peut être approprié.

SharePoint Server peut représenter un coût monétaire important. Les exigences matérielles sont à l’extrémité supérieure de nombreux systèmes de gestion de documents. Chaque serveur SharePoint doit disposer d’une licence, ainsi que chaque utilisateur SharePoint. Un autre point de licence à considérer est SQL Server, et comme SharePoint Server 2019 ne prend pas en charge SQL Express, la seule option est les éditions sous licence de SQL Server.

La création d’une batterie de serveurs SharePoint hautement disponible augmentera également les coûts non seulement d’investissement initial, mais également de coûts opérationnels. Plus il y a de serveurs et de services à gérer, plus la batterie de serveurs devient chère au fil du temps.

Les services fournis dans la batterie auront également un impact sur les performances. Dans une batterie de serveurs où vous avez plus de 500 millions d’éléments à analyser, il est nécessaire de provisionner une nouvelle application de service de recherche. Si vous avez des applications de service de recherche supplémentaires, vous souhaiterez peut-être également configurer des serveurs SharePoint supplémentaires pour gérer cette charge.

Microsoft a introduit le concept de patch MinRole et Zero Downtime. Avec MinRole, les clients peuvent se concentrer sur les applications de service à déployer sans avoir à se soucier de l’emplacement de démarrage de ses instances de service dépendantes. Il démarre également automatiquement ces services lorsqu’ils sont arrêtés accidentellement. MinRole offre le meilleur placement de service basé sur l’expérience de Microsoft avec SharePoint Online. L’emplacement du service MinRole ne peut pas être modifié car il est défini dans le code. Cela peut être une considération importante si vous souhaitez exécuter des services personnalisés au sein de la batterie de serveurs. L’application de correctifs Zero Downtime permet d’appliquer des correctifs à une batterie de serveurs SharePoint sans mettre la batterie hors ligne, mais l’application de correctifs Zero Downtime n’empêche aucun serveur particulier de la batterie de se déconnecter ; par exemple, un correctif SharePoint peut nécessiter un redémarrage. Cela signifie que pour une haute disponibilité efficace, tous les services de la batterie doivent être alloués à au moins deux serveurs.

Astuce Des informations sur chaque MinRole et les services associés peuvent être trouvées sur https://docs.microsoft.com/en-us/sharepoint/administration/ description-of-minrole-and-associated-services-in-sharepoint- server-2016 .

Avec ces données en main, vous pouvez déterminer à quoi devrait ressembler votre ferme.

Lorsqu’un serveur n’est pas conforme à un MinRole spécifique, il sera noté dans l’Administration centrale sous Gérer les serveurs de la batterie, comme illustré à la figure 2-1 , ainsi que pour le service spécifique dans Gérer les services de cette batterie.

Figure 2-1. Informations sur les rôles conformes dans l’administration centrale

MinRole dédié nécessite un minimum de huit serveurs au sein de la batterie de serveurs SharePoint pour maintenir tous les services hautement disponibles, tandis que MinRole partagé nécessite quatre serveurs. La haute disponibilité sera traitée plus en détail au chapitre 17.

Avec les concepts de base de l’architecture de batterie de serveurs, la prochaine étape du processus d’architecture consiste à examiner les exigences matérielles et logicielles pour SharePoint Server 2019.

2.2 Configuration matérielle et logicielle requise

La configuration matérielle requise pour SharePoint Server 2019 reste largement inchangée par rapport à SharePoint Server 2013 et 2016, et tout matériel de production provisionné pour SharePoint Server 2013 ou 2016 peut être utilisé avec SharePoint Server 2019, comme indiqué dans le tableau 2-1 . Ce sont des exigences minimales. Les déploiements en production nécessitent souvent des spécifications beaucoup plus élevées.

Tableau 2-1. Exigences matérielles

Serveur Processeur Mémoire Disque principal Disque secondaire
Serveur SharePoint 4 cœurs, 64 bits 12–24 gB 80 Go 80 Go
Serveur SQL 4 cœurs, 64 bits 12 à 16 Go 80 Go n / a
Batterie de serveurs unique SharePoint 4 cœurs, 64 bits 12–24 gB 80 Go 100 Go

SharePoint Server 2019 peut être installé sur Windows Server 2016 Standard ou Datacenter, ainsi que Windows Server 2019 Standard ou Datacenter. SharePoint Server 2019 nécessite une expérience de bureau ; Windows Server Core et les conteneurs ne sont pas pris en charge.

Chaque serveur SharePoint nécessite les conditions préalables suivantes :

  • Client 2.1 des services de gestion des droits Active Directory
  • Mise à jour cumulative 7 pour AppFabric 1.1 pour Windows Server
  • Microsoft .NET Framework 4.7
  • Extensions d’identité Microsoft
  • Client de protection et de contrôle des informations Microsoft
  • Pilote Microsoft ODBC 11 pour SQL Server
  • Microsoft Sync Framework Runtime v1.0 SP1 (x64)
  • Client natif SQL Server 2012 SP4
  • Package d’exécution Visual C ++ pour Visual Studio 2012
  • Package d’exécution Visual C ++ pour Visual Studio 2017
  • WCF Data Services 5.6
  • Windows Server AppFabric 1.1

Les versions prises en charge de SQL Server sont SQL Server 2016 et SQL Server 2017, éditions Standard et Enterprise.

Le choix de l’utilisation de SQL Server Standard ou Enterprise dépendra en grande partie de la méthode de haute disponibilité de SQL Server qui sera utilisée pour la batterie de serveurs.

La virtualisation joue un rôle important dans le centre de données d’aujourd’hui ainsi que dans le cloud ; nous examinerons ensuite les options de virtualisation, ainsi que les restrictions concernant SharePoint Server 2019.

2.3 Virtualisation

Microsoft prend entièrement en charge la virtualisation de SharePoint Server et SQL Server sur Hyper-V et d’autres hyperviseurs, tels que VMware ESXi, via le programme de validation de virtualisation de serveur à l’adresse www.windowsservercatalog.com/svvp.aspx . Pour SharePoint Server, il existe des restrictions sur les technologies de virtualisation prises en charge.

La virtualisation est une technologie importante dans le monde d’aujourd’hui, offrant une plus grande densité dans l’environnement d’entreprise. Il est important de tester minutieusement les performances du matériel hôte sous-jacent afin de planifier correctement la disposition et la configuration des machines virtuelles. Par exemple, le placement de disques virtuels SQL Server sur le même LUN qu’un SharePoint Server peut ne pas être approprié, ou l’allocation d’un grand nombre de vCPU lorsqu’un SharePoint Server peut ne nécessiter que quatre vCPU, provoquant ainsi une sursouscription du processeur et réduisant les performances globales.

2.3.1 Limitations et restrictions de virtualisation

Les techniques de mémoire dynamique, qui ajustent la quantité de RAM virtuelle allouée en fonction de la charge de la machine virtuelle, telles que la mémoire dynamique Hyper-V ou la mémoire ballon VMware, ne sont pas prises en charge par SharePoint Server. Le service de cache distribué et le service de serveur de recherche créent des allocations de mémoire en fonction de la mémoire disponible au démarrage de ces services respectifs. Si la mémoire est supprimée du système en dessous de la quantité de mémoire allouée au démarrage de SharePoint Server, ces deux services ne seraient pas au courant de ce changement d’allocation et ne pourraient pas ajuster leurs quotas de mémoire de manière appropriée.

Les disques de différenciation sont des disques virtuels que plusieurs machines virtuelles peuvent utiliser comme « base ». Par exemple, un disque virtuel avec Windows Server 2016 et le périphérique approprié

La configuration requise de SharePoint Server 2019 installée pourrait servir de base, et chaque machine virtuelle SharePoint Server aurait son propre disque virtuel séparé où les modifications auraient lieu. Cela peut entraîner des pénalités de performances pour SharePoint Server, donc Microsoft ne les prend pas en charge.

Les sauvegardes de machine virtuelle « en ligne » sont des sauvegardes d’une machine virtuelle entière, y compris la configuration de la machine virtuelle ainsi que tous les disques virtuels. Le système d’exploitation de la machine virtuelle, ainsi que toutes les applications, ignore la sauvegarde en ligne. Microsoft ne prend pas en charge ces opérations avec SharePoint Server car les sauvegardes en ligne ne se produisent pas exactement au même moment dans la batterie de serveurs. Cela pourrait entraîner des incohérences entre les membres de la batterie si les sauvegardes devaient être restaurées, notamment des incohérences entre les serveurs SharePoint et les bases de données SQL Server.

Comme les sauvegardes de machines virtuelles en ligne, les points de contrôle en ligne, également appelés instantanés, ne sont pas non plus pris en charge par Microsoft pour la même raison. Non seulement les points de contrôle présentent le même problème de cohérence de la batterie lors d’une restauration de point de contrôle, mais ils peuvent entraîner des problèmes de performances, car les points de contrôle génèrent un nouveau disque virtuel de différenciation pour toutes les modifications après la prise de point de contrôle.

La réplication des machines virtuelles SharePoint Server n’est pas prise en charge. Cela inclut toute forme de réplication, telle que la réplique Hyper-V, la réplication VMware vSphere ou même la réplication au niveau du bloc ou du niveau de stockage SAN (Storage Area Network).

Les services de synchronisation de l’heure au niveau de la machine virtuelle doivent être désactivés. La machine virtuelle Windows exploitera ensuite une source de temps faisant autorité au sein du domaine, soit le contrôleur de domaine Active Directory avec le rôle FSMO de l’émulateur PDC, soit un autre serveur membre du contrôleur de domaine. Cela garantit la cohérence du temps entre les serveurs SharePoint au sein de la batterie de serveurs.

La mise en réseau joue un rôle très important avec SharePoint, puis nous examinerons les ports requis pour SharePoint ainsi que les limitations de bande passante et de latence du réseau.

2.4 Configuration réseau requise

Microsoft recommande l’utilisation du pare-feu Windows lorsque cela est possible. Dans cette optique, et avec le potentiel d’autres pare-feu entre les membres de la batterie de serveurs SharePoint, les serveurs SQL et / ou les contrôleurs de domaine, il est important de s’assurer que les ports appropriés sont ouverts pour que SharePoint fonctionne correctement. SharePoint crée automatiquement les règles du pare-feu Windows lorsque SharePoint est installé. Consultez le tableau 2-2 pour les ports requis par SharePoint et les services associés.

Tableau 2-2. Ports requis pour SharePoint

Un service Port TCP Port UDP Protocoles
Cache distribué 22233, 22236 n / a ICMp type 0 (ping)
sélecteur de personnes 53, 88, 135, 137–139, 389, 445,

636, 749, 750, 3268, 3269

53, 88, 137-139,

389, 445, 749

n / a
service bac à sable 32846 n / a n / a
recherche Crawler Ports d’application Web utilisés

(par exemple, 80, 443)

n / a n / a
Index de recherche 16500–16519 n / a n / a
applications de service 32843, 32844 n / a n / a
Serveur SQL 1433 (par défaut) 1434 (par défaut) n / a
Services WCF 808 n / a n / a
service de profil utilisateur 53, 88, 389, 5725, 1025–5000,

49152–65536

53, 88, 389, 464 n / a
SMTP 25 (par défaut), 587 (tls par défaut) n / a n / a

SharePoint Server nécessite que tous les serveurs de la batterie soient connectés avec au moins une connectivité réseau de 1 Gbit / s et un temps de réponse de 1 ms sur une moyenne de dix minutes. La latence peut être mesurée à l’aide de n’importe quel outil préféré, y compris ping, Psping, Hrping et autres. Microsoft s’attend à une latence supérieure à 1 ms en raison de divers facteurs, notamment l’utilisation de la virtualisation ou de commutateurs de tissus ajoutant de la latence. La latence limite le placement d’un serveur membre SharePoint à 186 miles (299 km) les uns des autres dans le vide ; cependant, étant donné que nous ne vivons pas dans le vide, la distance peut être considérablement réduite. Microsoft décourage fortement les batteries de serveurs SharePoint étendues, bien que si vous remplissez cette condition, elles sont prises en charge.

Comme les serveurs SharePoint de la batterie de serveurs, les serveurs SQL doivent également avoir une latence de 1 ms ou moins pour chaque serveur SQL Server s’exécutant dans une forme de réplication synchrone, ainsi que les serveurs SharePoint pris en charge par les serveurs SQL. Cela signifie qu’un serveur SQL utilisant des groupes de disponibilité AlwaysOn en mode synchrone devra probablement être à une très courte distance les uns des autres.

SharePoint dépend fortement d’une forêt Active Directory saine. Les contrôleurs de domaine pour tous les domaines à partir desquels les utilisateurs et les services SharePoint résident doivent être proches de la batterie de serveurs SharePoint, de préférence à moins de 1 ms RTT et connectés avec une connectivité d’au moins 1 Gbit / s. Chaque domaine Active Directory doit avoir au moins deux contrôleurs de domaine pour une haute disponibilité.

Le chapitre 3 expliquera plus en détail la façon dont Active Directory est sécurisé pour la batterie de serveurs SharePoint Server 2019.

Remarque: psping est un utilitaire Microsoft sysinternals disponible sur https: // docs. microsoft.com/en-us/sysinternals/downloads/psping . hrping est disponible à partir du logiciel directeurs financiers à www.cfos.de .

2.4.1 Équilibreurs de charge réseau

Les équilibreurs de charge réseau sont essentiels pour fournir une haute disponibilité à SharePoint pour vos utilisateurs finaux. Bien que de nombreux équilibreurs de charge proposent le déchargement SSL, cela doit être évité dans la mesure du possible. L’utilisation du déchargement SSL supprime le chiffrement sur l’équilibreur de charge et envoie la demande résultante en texte clair aux services cibles, tels que SharePoint. SharePoint utilise des jetons OAuth à diverses fins, telles que la communication avec Office Online Server, Workflow Manager et les compléments SharePoint. Les jetons OAuth sont en texte brut et reposent sur la sécurité du transport, comme SSL, afin de rester sécurisés. Bien que le déchargement SSL n’offre plus d’avantage en termes de performances en termes d’utilisation du processeur sur un serveur doté d’un processeur AMD ou Intel moderne, il peut réduire l’impact de la négociation SSL, qui peut ajouter jusqu’à quelques centaines de millisecondes. Les navigateurs réutilisent la session HTTP, ce qui peut réduire la probabilité qu’une autre négociation SSL soit nécessaire. Le déchargement SSL peut également être utilisé pour l’inspection du trafic, la recherche d’exploits, la validation des données, etc.

Dans les deux cas, explorez l’utilisation du pontage SSL au lieu du déchargement SSL. Le pontage SSL déchiffre la session SSL de l’utilisateur final sur l’équilibreur de charge et rechiffre la session SSL de l’équilibreur de charge sur le serveur SharePoint. Cela permet à l’équilibreur de charge de réutiliser les sessions SSL et de réduire l’impact de toute négociation SSL.

Avec les restrictions des exigences de mise en réseau et les options d’équilibrage de charge couvertes, nous examinerons les comptes de service Active Directory dont SharePoint a besoin.

2.5 Comptes de service

Les directives pour les comptes de service varient. Dans cet article, nous adopterons l’approche minimaliste, qui a démontré des avantages en termes de performances et aucun risque de sécurité connu. Il existe quatre comptes gérés recommandés pour SharePoint ; le compte de batterie de serveurs, l’application de service, le compte de pool d’applications Web et le compte de revendications de service de jeton Windows. De plus, les comptes non gérés incluent un compte d’exploration (pour la recherche), la synchronisation du profil utilisateur (pour la connexion de synchronisation AD Import), le superutilisateur Portal (pour la publication) et le super lecteur Portal (pour la publication). SQL Server doit tirer parti d’un compte de service géré. À ne pas confondre avec un compte de service géré SharePoint, les comptes de service géré Active Directory offrent des avantages importants, tels que le basculement automatique du mot de passe, le verrouillage du compte à utiliser avec des serveurs particuliers et la prévention de l’utilisation des informations d’identification pour se connecter de manière interactive.

Astuce Trouver plus d’ informations sur les comptes de services gérés du groupe à l’ adresse https: // docs.microsoft.com/en-us/windows-server/security/group- managed- services-comptes / groupe géré par le service des comptes aperçu .

Chaque compte a un objectif spécifique et prend en charge divers services de l’environnement SharePoint, comme indiqué dans le tableau 2-3.

Tableau 2-3. Droits du compte de service

Compte de service Système / Service Autorisation / Rôle Remarques
Compte de service agricole (minuterie) Serveur SQL dbcreator securityadmin Les rôles sont facultatifs mais recommandés ; la création / sécurité de la base de données peut être gérée par DBa.
Compte ferme Serveur SharePoint Administrateur shell administrateur de batterie de serveurs

Groupe local Wss_aDMIn_Wpg Groupe local Wss_ RestRICteD_Wpg_V4 Groupe local Wss_Wpg

Lors de la création d’une batterie de serveurs, ces autorisations sont attribuées automatiquement.
Compte serveur SQL Serveur SQL sysadmin effectue les pages de verrouillage des tâches de maintenance du volume en mémoire Le rôle fixe est ajouté automatiquement lorsque le service serveur sQl est configuré pour s’exécuter en tant qu’utilisateur de domaine. Effectuer des tâches de maintenance de volume et verrouiller des pages en mémoire sont des droits d’utilisateur de politique de sécurité locale. Ceux-ci permettront l’initialisation instantanée des fichiers de base de données et empêcheront Windows de paginer la mémoire utilisée par le serveur SQL, respectivement.
Compte de pool d’applications Web Serveur SharePoint Groupe local Wss_Wpg D’autres autorisations peuvent varier.
compte de pool d’applications de service Serveur SharePoint Groupe local Wss_Wpg D’autres autorisations peuvent varier.
Compte de service Système / Service Autorisation / Rôle Remarques
Revendications du compte de service de jeton Windows (C2Wts) Serveur SharePoint Attribution des droits d’utilisateur administrateur local :

Faire partie du

Système d’exploitation Emprunter l’identité d’un client après l’ouverture de session d’authentification en tant que service

Ces droits doivent être attribués sur tout serveur sharepoint exécutant le service C2Wts, en plus de configurer la délégation Kerberos contrainte pour les services externes si nécessaire. Ce service n’est souvent pas requis.
compte d’exploration Applications Web SharePoint Politique d’utilisation en lecture complète
compte de synchronisation de profil utilisateur Active Directory Droits délégués :

Répertoire répliqué

Changements

Peut-être configuré via des utilisateurs et des ordinateurs Active Directory ou une modification aDsI.
compte superutilisateur du portail Applications Web SharePoint Politique utilisateur de contrôle total
compte Super Reader du portail Applications de SharePoint Politique d’utilisation en lecture complète

Il convient de noter que le compte de compte de ferme ne nécessite plus de droits d’administrateur local sur n’importe quel serveur SharePoint. Cela est dû au fait que le service de synchronisation de profil utilisateur (Forefront Identity Manager) ne fait plus partie du produit SharePoint Server 2019. Le compte Revendications to Windows Token Service est désormais le seul compte qui continue à nécessiter des droits d’administrateur local, mais selon les fonctionnalités déployées sur la batterie, il n’est pas nécessaire de le provisionner.

Avec toutes les exigences de base pour SharePoint Server 2019 couvertes, examinons les différentes options de topologie disponibles.

2.6 Options de topologie de batterie de serveurs SharePoint

Les stratégies de topologie SharePoint sont nombreuses. Ici, nous allons passer en revue les topologies les plus courantes, ainsi que la topologie minimale requise pour la nouvelle fonctionnalité de correction « Zero Downtime ».

2.6.1 Batterie de serveurs unique

Une batterie de serveurs unique, comme illustré à la figure 2-2, se compose d’un seul serveur SharePoint avec SQL Server installé sur le même serveur. Il est possible que SQL Server s’exécute également sur son propre serveur. Cette architecture de batterie de serveurs a un rôle d’installation spécifique nommé « batterie de serveurs unique ». Avec ce rôle, il n’est pas possible d’ajouter des serveurs SharePoint supplémentaires à la batterie de serveurs, bien qu’il soit possible de modifier le rôle après l’installation pour prendre en charge une extension de batterie de serveurs.

Figure 2-2. Batterie de serveurs unique

Les batteries de serveurs à un seul serveur présentent l’inconvénient de nécessiter une mémoire élevée pour fonctionner efficacement, en particulier lorsque SQL Server est installé sur le même serveur. Une gestion minutieuse de la mémoire avec SQL Server est la clé de performances acceptables.

Les batteries de serveurs uniques sont adaptées à des rôles spécialisés, tels que le portail Microsoft Identity Manager ou l’intégration de Team Foundation Server, mais ne sont pas recommandées autrement à des fins de production en raison d’une charge potentielle importante et d’un manque de haute disponibilité.

Si une batterie de serveurs unique est envisagée, il peut être utile d’envisager de tirer parti de SharePoint Online pour réduire le coût de possession.

2.6.2 Ferme à trois niveaux

La batterie de serveurs à trois niveaux est l’un des types de batterie de serveurs les plus courants. Ces batteries se composent d’un seul serveur Web frontal, d’un seul serveur d’applications et d’un seul serveur SQL. Le frontal Web est simplement défini comme le serveur SharePoint qui gère le trafic des utilisateurs finaux, tandis que le serveur d’applications est défini comme un serveur SharePoint qui ne gère pas le trafic destiné aux utilisateurs finaux tout en gérant généralement la plupart des services SharePoint, tels que les services de connectivité des données métiers, Service de métadonnées gérées, etc.

Lors de l’installation de SharePoint Server avec l’architecture de batterie de serveurs à trois niveaux, illustrée à la figure 2-3, vous pouvez choisir d’utiliser soit le cache de distribution + le mini-rôle Web frontal pour le frontal, tandis que le niveau intermédiaire utilise Application + Recherche ou la fourniture à l’aide de la personnalisation. L’option personnalisée est la même approche de déploiement d’une batterie de serveurs SharePoint que celle utilisée avec SharePoint Server 2010 et 2013.

Pour l’architecture de batterie de serveurs à trois niveaux, il est recommandé d’exécuter le cache distribué, l’application Web Microsoft SharePoint Foundation, le rôle de traitement des requêtes de recherche et le rôle de partition d’index de recherche sur le Web Front End. Cela offre la meilleure expérience utilisateur final pour ces services, bien que vous souhaitiez peut-être envisager d’exécuter des services supplémentaires sur le Web Front End pour améliorer les performances. Voir la section Architecture rationalisée plus loin dans ce chapitre.

Figure 2-3. Ferme à trois niveaux

Le serveur frontal Web est l’endroit où tous les autres services s’exécuteront, tels que les services de connectivité des données métiers, le service de métadonnées gérées, le service de profil utilisateur et tout autre service qui ne s’exécutera pas sur le Web frontal mais est requis dans la batterie de serveurs. Cela peut réduire les besoins en mémoire du serveur d’applications par rapport au serveur Web frontal.

2.6.3 Fermes traditionnelles à haute disponibilité

D’autres topologies offrent une haute disponibilité de base, comme le montre la figure 2-4. Ces topologies peuvent subir la perte d’un ou plusieurs serveurs SharePoint et serveurs SQL tout en servant les utilisateurs.

Figure 2-4. Ferme de topologie traditionnelle hautement disponible

Par exemple, deux serveurs Web frontaux, deux serveurs d’applications et deux serveurs SQL utilisant une forme de haute disponibilité, tels que le clustering SQL, la mise en miroir de bases de données ou les groupes de disponibilité AlwaysOn avec clustering avec basculement.

Les Web Front Ends seraient derrière un équilibreur de charge, tel qu’un F5 Big-IP, HAProxy ou KEMP LoadMaster. Les équilibreurs de charge détecteraient une défaillance du serveur et achemineraient automatiquement le trafic vers le Web Front End disponible. Pour les applications de service, SharePoint fonctionne dans un équilibrage de charge à tour de rôle lorsque deux serveurs SharePoint ou plus de la batterie de serveurs exécutent une instance de service particulière. Par exemple, si deux serveurs SharePoint exécutent le service de métadonnées gérées et qu’un serveur SharePoint échoue, le service de topologie SharePoint supprimera automatiquement le serveur SharePoint défaillant de l’équilibrage de charge à tour de rôle et le service de métadonnées gérées continuera d’être disponible dans la batterie de serveurs. Vous trouverez plus d’informations sur le service de topologie et l’équilibrage de charge à tour de rôle plus loin dans ce chapitre.

2.6.4 Fermes MinRole

Microsoft a introduit le nouveau concept de « MinRole » dans SharePoint Server 2016. Il s’agit de la méthode de déploiement préférée pour les batteries de serveurs SharePoint car elles placent automatiquement les services sur les serveurs appropriés en fonction de leur rôle. Avec SharePoint Server 2019, les rôles n’ont pas changé par rapport à SharePoint Server 2016 avec Feature Pack 1. MinRole dédié est un ensemble de rôles SharePoint Server qui sont définis par les services requis pour ce rôle. Les rôles sont appliqués via le code SharePoint. Par exemple, si un serveur SharePoint est déployé avec le MinRole « Cache distribué », SharePoint provisionnera automatiquement le service de cache distribué. Si d’autres services démarrés qui ne sont pas conformes au MinRole sélectionné, tels que le service de métadonnées gérées, le serveur SharePoint avec le MinRole de cache distribué seront considérés comme non conformes et notés comme tels dans l’Administration centrale.

MinRole comprend les nouveaux rôles d’installation suivants :

  • Cache distribué : ce rôle exécute le cache distribué, mais ne gère pas directement le trafic des utilisateurs finaux.
  • Web Front End : ce rôle gère non seulement le trafic des utilisateurs finaux, mais exécute de nombreux services qui nécessitent une faible latence pour les utilisateurs finaux, tels que le service de métadonnées gérées ou le service de profil utilisateur.
  • Application : le rôle Application exécute ce qui est considéré comme des services non sensibles à la latence, tels que le workflow ou le service de conversion PowerPoint.
  • Recherche : la recherche exécute les rôles de recherche spécifiques tels que les rôles Admin ou Traitement du contenu.

Les batteries de serveurs MinRole dédiées peuvent être déployées avec un minimum de quatre serveurs SharePoint dans la batterie, bien que cela n’offre aucune haute disponibilité pour SharePoint. Les batteries de serveurs MinRole dédiées sont conformes à la topologie rationalisée, décrite plus loin dans ce chapitre.

Microsoft a également introduit le concept d’une batterie de serveurs MinRole partagée. Ces services consolidés permettent le déploiement d’un minimum de 4 serveurs SharePoint dans une batterie de serveurs hautement disponible. Les rôles disponibles sont les suivants :

  • Cache distribué avec Web Front End : ce rôle exécute le cache distribué et traite les demandes des utilisateurs. Ce rôle exécute également diverses instances de service qui bénéficient aux performances de l’utilisateur final, telles que l’instance de service de métadonnées gérées.
  • Application avec recherche : le rôle Application exécute ce qui est considéré comme des services non sensibles à la latence, tels que le workflow ou le service de conversion PowerPoint. Ce rôle exécute également tous les rôles de recherche.

L’utilisation du MinRole partagé peut réduire considérablement les coûts tout en maintenant une haute disponibilité.

2.6.5 Fermes sans interruption de service

Le patch Zero Downtime nécessite que la batterie de serveurs SharePoint soit hautement disponible pour tous les services, comme le montre la figure 2-5. Cela signifie qu’il doit y avoir au moins huit serveurs SharePoint dans la batterie de serveurs lors de l’utilisation de MinRole dédié et quatre serveurs lors de l’utilisation de MinRole partagé.

Une batterie MinRole Zero Downtime serait prise en charge par une ou plusieurs configurations SQL Server hautement disponibles, telles qu’un ou plusieurs clusters SQL ou groupes de disponibilité AlwaysOn avec clustering avec basculement.

SharePoint Server 2016 Feature Pack 1 a introduit le concept de MinRoles partagés. Il s’agit des nouveaux rôles d’installation suivants :

  • Cache distribué et Web Front End
  • Application et recherche

Les options MinRole améliorées permettent des fermes plus petites que les options MinRole d’origine. Cet article utilisera les MinRoles partagés avec un déploiement de quatre serveurs SharePoint.

Comme avec les MinRoles précédents, il est possible de convertir un serveur des MinRoles dédiés en MinRoles partagés ou vice versa.

Les correctifs Zero Downtime peuvent également être utilisés avec des batteries de serveurs plus traditionnelles, telles qu’une configuration de batterie de serveurs hautement disponible à trois niveaux. Chaque serveur utiliserait le rôle personnalisé, tous les services restants hautement disponibles dans la batterie de serveurs.

Figure 2-5. MinRole hautement disponible avec prise en charge des correctifs sans interruption

2.6.6 Topologie d’application de service traditionnel

Bien que la topologie traditionnelle soit une topologie qui a été utilisée pendant de nombreuses années et qui a souvent été déployée avec SharePoint Server 2013, il est désormais recommandé d’utiliser un déploiement MinRole bien qu’il soit toujours possible d’obtenir ce type de topologie à l’aide de l’option MinRole personnalisé.

Ce modèle suit l’installation du service Web Microsoft SharePoint Foundation sur le serveur Web frontal. La topologie peut également ajouter le cache distribué au Web Front End.

Le serveur d’applications exécute tous les autres services de cette topologie. Cela place une charge plus élevée sur le serveur d’applications par rapport à d’autres topologies, tout en réduisant potentiellement la charge du Web Front End. L’augmentation du trafic réseau peut résulter de cette topologie en raison des services communiquant du serveur d’applications au Web Front End ; par exemple, un appel à un champ de métadonnées gérées se déplacerait du Web Front End vers le serveur d’applications, puis reviendrait via le Web Front End avant d’atteindre le navigateur de l’utilisateur.

2.6.7 Topologie d’application de service rationalisée

La topologie rationalisée est née de l’expérience de Microsoft avec SharePoint Online et est la topologie préférée. Cette topologie a été introduite environ un an dans le cycle de vie de SharePoint Server 2013.

Services hiérarchisés Microsoft dans la topologie rationalisée en fonction de la latence pour les utilisateurs finaux. Les services nécessitant une latence plus faible, c’est-à-dire un accès plus rapide aux demandes des utilisateurs finaux, ont été placés sur les Web Front Ends. Les services qui n’étaient pas interactifs pour l’utilisateur final, tels que le service de workflow, ont été placés sur des serveurs d’applications dorsaux (également appelés serveurs « batch »).

Dans certaines conditions, cette topologie de batterie de serveurs a fourni de meilleures performances et une meilleure réactivité pour les utilisateurs finaux par rapport à la topologie de batterie de serveurs traditionnelle. Les batteries de serveurs utilisant MinRole exploitent cette topologie.

2.6.8 Service de topologie

L’équilibreur de charge du service Round Robin, la fonction principale du service de topologie, est responsable de l’ajout et de la suppression des points de terminaison d’application de service disponibles, ainsi que de la disponibilité des points de terminaison.

L’équilibreur de charge de service Round Robin énumérera tous les proxys d’application de service dans la batterie de serveurs et déterminera les points de terminaison disponibles. Chaque instance de service sur un serveur SharePoint est exposée via un point de terminaison.

Dans SharePoint Server 2013 avec la configuration de topologie rationalisée (et dans certains scénarios, la topologie traditionnelle), car l’équilibreur de charge du service Round Robin ajouterait des points de terminaison à l’équilibreur de charge à tour de rôle interne, il était possible que même si un point de terminaison particulier était disponible sur le serveur SharePoint auquel l’utilisateur final était connecté, leur demande peut être acheminée vers un autre serveur SharePoint dans la batterie de serveurs. C’est loin d’être idéal, car l’idée derrière la topologie rationalisée était de conserver les demandes des utilisateurs finaux sur le serveur SharePoint local.

Avec SharePoint Server 2016, Microsoft a introduit la possibilité pour l’équilibreur de charge de service Round Robin de conserver les demandes des utilisateurs finaux sur le même serveur lorsque MinRole est activé. Cela fournit la meilleure latence et les meilleures performances pour les demandes des utilisateurs finaux et réduit la charge réseau entre les serveurs membres de la batterie SharePoint. Cette amélioration se poursuit avec SharePoint Server 2019.

2.6.9 Considérations hybrides

À partir de SharePoint Server 2013 avec la mise à jour cumulative d’août 2015, la recherche hybride a été proposée, où l’index de recherche est unifié avec un index de recherche de locataire SharePoint Online. Si la recherche hybride est utilisée, la batterie de serveurs sur site n’utilise pas d’index de recherche local. Cela peut être pris en compte dans les plans visant à réduire le nombre de serveurs de recherche dans la batterie de serveurs.

L’utilisation de OneDrive Entreprise dans une configuration hybride (redirection) peut également aider à réduire le matériel sur site requis pour SharePoint et SQL Server en déchargeant toutes les activités et le stockage liés à MySite sur SharePoint Online. Le chapitre 14 abordera plus en détail l’hybride.

2.7 Architecture de SQL Server

SQL Server joue un rôle très important pour les performances, la disponibilité et la récupération après sinistre de SharePoint Server 2019. Les mesures des performances de SQL Server avant le déploiement sont cruciales pour évaluer les limites du système et déterminer quand une mise à l’échelle ou une mise à l’échelle de SQL Server est requise.

2.7.1 Performance

La première étape consiste à mesurer les performances potentielles de SQL Server est le sous-système d’E / S disque. Microsoft a créé un outil, Diskspd, pour mesurer les performances du disque. Cet outil fournira des données précieuses en termes de nombre d’E / S par seconde que le sous-système de disques est capable de prendre en charge. Notez que le test des performances d’écriture (le commutateur DiskSpd -w) entraînera une perte de données. Testez uniquement les performances d’écriture sur un disque sans données.

Remarque Diskspd est disponible auprès de Microsoft à l’adresse https://aka.ms/diskspd .

En plus du disque, la quantité de mémoire disponible pour SQL Server joue un rôle essentiel dans les performances de SharePoint Server. Plus SQL Server dispose de mémoire, plus les ensembles de données peuvent contenir de mémoire et plus SQL Server peut conserver ces ensembles de données en mémoire.

Enfin, les performances du processeur sont cruciales. Les serveurs SQL physiques modernes auront généralement deux sockets avec quatre cœurs ou plus par CPU. Cependant, dans un environnement virtuel, assurez-vous d’allouer deux ou plusieurs vCPU, en fonction des exigences de performances. Un seul processeur virtuel peut entraîner de très mauvaises performances dans tous les environnements, sauf le plus petit.

Il est important de définir une valeur de mémoire maximale appropriée pour SQL Server afin de réserver de la mémoire pour le système d’exploitation et tous les programmes auxiliaires exécutés sur SQL Server. Cela aidera à empêcher la pagination de la mémoire SQL Server ou d’une autre mémoire de processus sur le disque, ce qui peut réduire les performances globales de SQL Server.

2.7.2 Haute disponibilité et reprise après sinistre

SharePoint Server prend en charge la haute disponibilité SQL Server, y compris le clustering SQL Server, la mise en miroir de bases de données et les groupes de disponibilité SQL Server AlwaysOn. Étant donné que la mise en miroir de bases de données SQL Server est obsolète, cet article se concentrera sur l’utilisation optimale des bases de données AlwaysOn avec SharePoint Server. Nous examinerons les groupes de disponibilité AlwaysOn en mode synchrone avec basculement automatique pour un site local. Le clustering SQL Server est également une option valide ; cependant, le clustering SQL Server ne fournit pas de haute disponibilité pour le stockage. Inversement, AlwaysOn double les exigences de stockage.

Comme pour les tests de performances de disque pour SQL Server, nous devons effectuer des tests de charge pour SharePoint, traités dans la section suivante.

2.8 Génération de charge / test de charge

Il est important d’avoir une architecture décrite, tout comme la tester ! Microsoft dispose de deux outils principaux pour les tests, Visual Studio 2013 Ultimate, Visual Studio 2015/2017 Enterprise et l’outil de génération de charge SharePoint. Ces éditions de Visual Studio incluent l’enregistrement d’actions spécifiques prises dans un navigateur, avec la possibilité d’exécuter plusieurs contrôleurs simultanément pour tester de nombreux utilisateurs accédant à une batterie de serveurs en même temps.

L’outil de génération de charge SharePoint est un complément pour Visual Studio 2013 Ultimate et Visual Studio 2015 Enterprise qui effectue les tests suivants :

• Test de charge de lecture et d’écriture de liste CSOM

• Test de charge MySite en lecture et en écriture

• Test de charge de lecture et d’écriture MySiteHost

L’outil de génération de charge SharePoint dispose également d’options supplémentaires pour l’authentification et le nombre de serveurs à tester, et enregistre automatiquement les compteurs de performances pertinents pour examen post-test.

Notez que l’outil de génération de charge de point de partage est disponible sur la galerie Visual studio à l’adresse https://marketplace.visualstudio.com/items?itemName=Sh arePointTemplates.SharePointLoadGenerationTool .

Nous allons examiner l’architecture de SharePoint Server, SQL Server, Workflow Manager et Office Online Server utilisée dans cet article. Cette architecture de batterie de serveurs illustre l’architecture MinRole haute disponibilité.

2.9 L’architecture en action

L’architecture de la ferme choisie pour cet article, illustrée à la figure 2-6, nous utiliserons la ferme viable minimale pour une configuration MinRole hautement disponible et un correctif « Zero Downtime ».

Figure 2-6. L’architecture de la ferme choisie pour cet article

Les serveurs SQL feront partie d’un groupe de disponibilité utilisant le clustering de basculement pour fournir un groupe de disponibilité AlwaysOn pour les bases de données SharePoint Server. En outre, le quorum du cluster de basculement sera un témoin Azure Cloud pour fournir un basculement automatique. Les serveurs SharePoint remplissant le rôle Front-end résideront derrière un équilibreur de charge. Cet équilibreur de charge offre la détection des hôtes défaillants pour fournir la plus haute disponibilité possible aux clients. En plus de la batterie de serveurs SharePoint, une batterie de serveurs SharePoint Workflow Manager sera également provisionnée avec l’architecture suivante, illustrée à la figure 2-7.

Figure 2-7. Ferme SharePoint Workflow Manager

SharePoint Workflow Manager sera traité plus en détail au chapitre 10 ; cependant, SharePoint Workflow Manager peut être configuré avec un, trois ou cinq serveurs. Aucune autre configuration valide n’est disponible. De plus, Workflow Manager prend en charge SQL Server 2016 et SQL Server 2017, d’où l’ajout de deux serveurs SQL configurés avec un groupe de disponibilité AlwaysOn.

Enfin, l’environnement illustré à la figure 2-8 comprend un serveur Active Directory Rights Management Services, Exchange Server 2016, Microsoft Identity Manager 2016 et Office Online Server dans un environnement hautement disponible à trois serveurs.

Figure 2-8. L’environnement CobaltAtom.com

2.10 Prochaines étapes

Nous avons couvert certaines des décisions de base nécessaires pour déterminer la topologie de batterie de serveurs adaptée à votre configuration et abordé une variété de topologies de batterie de serveurs viables, ainsi que la révision des fonctionnalités de correction MinRole et Zero Downtime.

Dans le chapitre suivant, nous passerons par une installation de bout en bout de SQL Server 2017 sur Windows Server 2016 avec une installation Core, ainsi que SharePoint Server 2019 dans une batterie de serveurs MinRole hautement disponible. Le chapitre couvrira également les principes de base de la sécurité pour Active Directory, SQL Server et SharePoint Server.

3 CHAPITRE 3 Installation de SharePoint Server 2019

Dans ce chapitre, nous apprendrons les étapes nécessaires à l’installation et à la configuration, depuis Active Directory, SQL Server et enfin vers SharePoint Server 2019. Nous examinerons également le déploiement et la configuration de base des applications de service, des applications Web et de la collection de sites. Ce chapitre vous fournira les connaissances nécessaires pour parcourir chaque composant à l’aide de PowerShell comme langage de script de déploiement et de configuration principal. Une fois ce chapitre terminé, vous disposerez d’une batterie de serveurs MinRole SharePoint Server 2019 entièrement fonctionnelle et hautement disponible. Dans ce chapitre, certaines des configurations décrites sont des exigences de Microsoft tandis que d’autres sont des recommandations de Microsoft et de l’auteur.

3.1 Configuration d’Active Directory

Votre domaine Active Directory doit comprendre au moins deux contrôleurs de domaine à l’emplacement physique où la batterie de serveurs SharePoint et les serveurs SQL résideront. Cela fournira les performances d’authentification et de recherche DNS les plus rapides à SharePoint. Les contrôleurs de domaine doivent également avoir un certificat d’authentification de serveur (par exemple, SSL) afin de crypter le trafic LDAP entre SharePoint et le contrôleur de domaine. Ces certificats sont généralement déployés via les services de certificats Active Directory, mais vous pouvez également utiliser une autorité de certification publique.

La sécurisation d’Active Directory se fera principalement via la stratégie de groupe. SharePoint est provisionné dans le domaine LAB, qui possède un nom de domaine complet (FQDN) de lab. cobaltatom.com. Tous les ordinateurs de domaine, à l’exception des contrôleurs de domaine, relèvent de la stratégie de domaine par défaut.

Consultez les tableaux 3-1 et 3-2 pour les options de sécurité de stratégie de groupe appliquées.

Tableau 3-1. Options de sécurité de stratégie de domaine par défaut

Nom de la politique de sécurité Définition de la politique
Sécurité réseau: configurer les types de chiffrement autorisés pour Kerberos AES128_HMAC_SHA1, AES256_

HMAC_SHA1, Futurs types de chiffrement

Client réseau Microsoft: envoyer un mot de passe non chiffré à des serveurs SMB tiers Désactivé
Accès réseau: autoriser la traduction anonyme du SID / nom Désactivé
Accès réseau: autoriser tout le monde à s’appliquer aux utilisateurs anonymes Désactivé
Membre du domaine: crypter ou signer numériquement les données des canaux sécurisés (toujours) Activée
Membre de domaine: nécessite une clé de session forte (Windows 2000 ou version ultérieure) Activée
Client réseau Microsoft: communications signées numériquement (toujours) Activée
Serveur réseau Microsoft: communications signées numériquement (toujours) Activée
Accès réseau: ne pas autoriser l’énumération anonyme des

Comptes SAM

Activée
Accès réseau: ne pas autoriser l’énumération anonyme des comptes et partages SAM Activée
Sécurité réseau: ne stockez pas la valeur de hachage LAN Manager lors du prochain changement de mot de passe Activée
Sécurité réseau: sécurité de session minimale pour NTLM 

Clients basés sur SSP (y compris RPC sécurisé)

Exiger la sécurité de session NTLMv2;

Nécessite un cryptage 128 bits

Sécurité réseau: sécurité de session minimale pour NTLM 

Serveurs basés sur SSP (y compris RPC sécurisé)

Exiger la sécurité de session NTLMv2;

Nécessite un cryptage 128 bits

Contrôleur de domaine: exigences de signature du serveur LDAP Exiger la signature
Sécurité réseau: exigences de signature du client LDAP Exiger la signature
Sécurité réseau: niveau d’authentification LAN Manager Envoyer la réponse NTLMv2 uniquement;

Refuser LM & NTLM

 

Tableau 3-2. Options de sécurité de la stratégie de contrôleur de domaine par défaut

Nom de la politique de sécurité Définition de la politique
Sécurité réseau: configurer les types de chiffrement autorisés pour Kerberos AES128_HMAC_SHA1, AES256_

HMAC_SHA1, Futurs types de chiffrement

Client réseau Microsoft: envoyer un mot de passe non chiffré à des serveurs SMB tiers désactivé
Accès réseau: autoriser la traduction anonyme du SID / nom désactivé
Accès réseau: autoriser tout le monde à s’appliquer aux utilisateurs anonymes désactivé
Membre du domaine: crypter ou signer numériquement les données des canaux sécurisés (toujours) Activée
Membre de domaine: nécessite une clé de session forte (Windows 200 ou version ultérieure) Activée
Client réseau Microsoft: communications signées numériquement (toujours) Activée
Serveur réseau Microsoft: communications signées numériquement (toujours) Activée
Accès réseau: ne pas autoriser l’énumération anonyme des

Comptes SAM

Activée
Accès réseau: ne pas autoriser l’énumération anonyme des

Comptes et partages SAM

Activée
Sécurité réseau: ne stockez pas la valeur de hachage LAN Manager lors du prochain changement de mot de passe Activée
Sécurité réseau: sécurité de session minimale pour les clients basés sur NTLM SSP (y compris RPC sécurisé) Exiger la sécurité de session NTLMv2;

Nécessite un cryptage 128 bits

Sécurité réseau: sécurité de session minimale pour les serveurs basés sur NTLM SSP (y compris RPC sécurisé) Exiger la sécurité de session NTLMv2;

Nécessite un cryptage 128 bits

Contrôleur de domaine: exigences de signature du serveur LDAP Exiger la signature
Sécurité réseau: exigences de signature du client LDAP Exiger la signature
Sécurité réseau: niveau d’authentification LAN Manager Envoyer la réponse NTLMv2 uniquement; Refuser

LM & NTLM

Enfin, SharePoint Server se voit attribuer une stratégie de groupe pour désactiver les mises à jour Windows. Vous pouvez également choisir de déployer une solution de gestion des correctifs d’entreprise, telle que Windows Software Update Services et désactiver le déploiement des mises à jour liées à SharePoint sur les serveurs SharePoint, mais autoriser toutes les autres formes de mises à jour.

Tous les ordinateurs du domaine ont le pare-feu Windows avec sécurité avancée activé. SharePoint fera automatiquement des exceptions dans le pare-feu lors de l’installation, mais des exceptions manuelles peuvent être faites. Pour SQL Server, une exception pour

TCP / 1433 et TCP / 5022 doivent être créés pour l’instance SQL par défaut et le groupe de disponibilité AlwaysOn. Si vous utilisez une instance nommée SQL, UDP / 1434 doit également être ouvert.

Enfin, si la connexion d’administration dédiée est souhaitée, ouvrez TCP / 1434.

À ce stade, nous avons configuré la sécurité de base pour Active Directory et les stratégies clés pour SharePoint. Dans la section suivante, nous couvrirons les comptes de service exploités par SQL Server et SharePoint.

3.2 Comptes de service

SharePoint et SQL Server nécessitent quelques comptes de service pour fonctionner. Il existe une variété de stratégies disponibles pour le nombre de comptes de service à utiliser et pour quelle fonction. Cet article utilisera un nombre minimal de comptes de service pour maintenir les meilleures performances possibles en créant le moins de pools d’applications dans SharePoint. En utilisant un seul compte de service pour les applications Web, par exemple, nous pouvons déployer un seul pool d’applications pour toutes les applications Web. Cela permet de réduire le temps de démarrage des applications Web secondaires après le démarrage de la première application Web et permet également à chaque application Web de «partager» la mémoire. Avec .NET, il y a très peu de mémoire partageable entre les processus, même s’ils contiennent le même code. Étant donné que les processus SharePoint peuvent consommer une quantité importante de mémoire, cela permet une économie de mémoire très importante.

SQL Server utilisera un compte de service géré de groupe (gMSA) qui est un type de compte spécial dans Active Directory. Cette fonctionnalité nécessite des contrôleurs de domaine Windows Server 2012 ou supérieur. De plus, la clé racine KDS doit être créée avant de créer un gMSA. Si aucune clé racine KDS n’a été créée, exécutez le PowerShell suivant.

Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

Pour créer le compte, vous aurez besoin du module Active Directory pour PowerShell installé qui peut être trouvé dans le cadre des outils d’administration à distance Active Directory ainsi que les droits nécessaires dans Active Directory pour provisionner les comptes. Dans ce scénario, nous allons créer un compte nommé «s-sql» et accorder l’accès au compte à partir des serveurs SQL associés. La dernière partie du script ajoute également les noms principaux du service au compte.

New-ADServiceAccount -Name s-sql -DNSHostName s-sql.lab.cobaltatom.

com -Enabled:$true -PrincipalsAllowedToRetrieveManagedPassword

‘calsql01,’calsql02 -ServicePrincipalNames ‘MSSQLSvc/ calsql01:1433′,’MSSQLSvc/calsql01.lab.cobaltatom.com:1433′,’MSSQLSvc/ calsql02:1433′,’MSSQLSvc/calsql02.lab.cobaltatom.com:1433′,’MSSQLSvc/ calspag.lab.cobaltatom.com:1433’

Le mot de passe de ce compte est automatiquement recyclé tous les 30 jours. De plus, ce compte ne peut pas être utilisé pour se connecter de manière interactive sur n’importe quel serveur et les informations d’identification du compte ne sont exposées qu’aux serveurs spécifiés lors de la création ou de la mise à jour du gMSA. La gMSA ne peut être créée qu’avec le module Active Directory PowerShell comme la commande PowerShell ci-dessus. Notez que les noms SQL Server doivent déjà être définis. En outre, cette commande montre comment définir les noms de principe de service, éliminant la nécessité d’utiliser setspn.exe.

Les comptes de service du tableau 3-3 ont été configurés dans Active Directory pour exécuter SQL Server et SharePoint et seront utilisés tout au long de ce guide.

Tableau 3-3. Comptes SQL Server et SharePoint Service

Nom du compte Objectif du compte
LAB \ s-sql compte de service géré de groupe pour SQL Server
LAB \ s-farm Compte de batterie de serveurs SharePoint
LAB \ s-svc Compte de pool d’applications SharePoint Service
LAB \ s-web Compte de pool d’applications Web SharePoint
LAB \ s-c2wts Revendications sur le compte du service de jeton Windows
LAB \ s-spsync Compte d’importation de profil utilisateur
LAB \ s-su Compte superutilisateur du portail
LAB \ s-sr Compte Super Reader du portail
LAB \ s-crawl Rechercher un compte d’exploration

Avec les comptes de service provisionnés dans Active Directory, nous examinerons les options de gestion de l’alimentation qui peuvent améliorer les performances pour SQL Server et SharePoint Server 2019.

3.3 Sécurité du compte de service

Les comptes de service ne doivent pas pouvoir se connecter au serveur localement ou à distance. Pour définir cela, sur chaque serveur SharePoint, exécutez secpol.msc. Accédez à Stratégies locales, puis Attribution des droits utilisateurs. Sous les stratégies « Refuser la connexion localement » et « Refuser la connexion via les services Bureau à distance », ajoutez tous les comptes de service alloués à SharePoint.

3.4 Gestion de l’alimentation du BIOS et de Windows

Il existe quelques modifications qui peuvent être effectuées sur n’importe quel serveur avant d’installer SQL Server et SharePoint pour augmenter les performances.

Jetant un œil aux options BIOS / UEFI pour le matériel exécutant SharePoint (que SharePoint soit installé sur le matériel physique ou si vous déployez un hôte de virtualisation qui exécutera une machine virtuelle SharePoint), désactivez Intel C-States (SpeedStep) / AMD Cool ‘ n’Quiet empêchera le processeur de revenir en arrière lorsqu’il n’est pas sous charge. De plus, désactivez la prise en charge C1E (« état d’arrêt amélioré »), qui est disponible sur les processeurs Intel et AMD. Étant donné que SharePoint peut augmenter la charge du processeur, cela peut provoquer un effet de bascule lorsque cette technologie de processeur est activée. Une option spécifique aux OEM, comme le HP

Le mode régulateur de puissance peut également aider à améliorer les performances – pour HP, le réglage de la puissance

Mode régulateur à haute performance statique, et pour Dell, le mode de gestion de l’alimentation à performance maximale. Enfin, la désactivation de la gestion de l’alimentation QPI empêchera la limitation des voies entre plusieurs processeurs et la mémoire physique.

Le BIOS / UEFI n’inclut généralement pas d’option pour désactiver ce que l’on appelle le « Core Parking ». Le stationnement de base est lorsqu’un cœur spécifique au sein d’un CPU est arrêté car il n’a pas de travail. Le stationnement de base est géré par le système d’exploitation, et sur les systèmes d’exploitation pris en charge pour SharePoint Server 2019 et SQL Server, il peut être désactivé en définissant l ‘« État minimal du processeur » à 100% ou en définissant le profil d’alimentation sur «Haute performance». Les profils de gestion de l’alimentation peuvent être définis via la stratégie de groupe.

Avec le BIOS / UEFI ajusté pour de meilleures performances, nous examinerons brièvement la configuration antivirus pour SQL Server et SharePoint Server 2019. N’oubliez pas d’ajuster les paramètres de gestion de l’alimentation pour SQL Server et SharePoint une fois Windows installé!

3.5 Antivirus basé sur l’hôte

De nombreuses entreprises utilisent ou nécessitent un antivirus basé sur l’hôte. SharePoint Server nécessite de nombreuses exclusions antivirus afin d’éviter le verrouillage de fichiers et les problèmes de performances. Par exemple, l’analyse antivirus basée sur l’hôte du cache de configuration du service du minuteur peut entraîner la suspension du travail du service du minuteur en raison d’une activité élevée inattendue dans le dossier. Microsoft décrit les exclusions requises sur https://support.microsoft.com/help/952167.

Pour SQL Server, excluez les processus SQL Server, les types de fichiers MDF, LDF et NDF, ainsi que les emplacements où SQL Server écrit les journaux ou conserve les données.

De nombreux fournisseurs d’antivirus d’entreprise proposent une gestion et une configuration centralisées. Si disponible, créez des règles généralisées pour SQL Server et SharePoint Server 2019 pour éviter d’avoir à configurer ces options localement.

Ensuite, commençons le processus d’installation et de configuration de notre batterie de serveurs MinRole hautement disponible, en commençant par la configuration Windows pour SQL Server !

3.6 Configuration de Windows Server pour SQL Server

Bien que SQL Server soit souvent configuré par un administrateur de base de données, l’administrateur SharePoint peut parfois être responsable du provisionnement de l’environnement complet. Ici, nous couvrirons les étapes nécessaires pour provisionner l’environnement SQL Server. Chaque section sera divisée entre les serveurs SQL exécutés sur Windows Core et Windows avec Desktop Experience. Nous vous recommandons fortement d’utiliser Windows Core, mais nous reconnaissons que les organisations informatiques peuvent ne pas avoir adopté Windows Core.

Cette batterie utilisera SQL Server 2017 exécuté sur Windows Server 2016 à l’aide d’une installation Core (pas d’interface graphique); cependant, ce guide vous fournira également les étapes d’installation d’un Windows Server 2016 avec Desktop Experience. Les installations Windows Core offrent une sécurité accrue grâce à une surface d’attaque réduite, une charge de gestion réduite et un encombrement nettement plus réduit avec jusqu’à 75% d’économie d’espace disque. Bien que les installations Windows Core soient prises en charge pour SQL Server, il n’est pas possible d’utiliser les installations Windows Core avec SharePoint Server.

SQL Server sera configuré pour utiliser les groupes de disponibilité AlwaysOn et le basculement automatique via un témoin Azure.

Chaque serveur SQL dispose des volumes suivants :

  • C: Système d’exploitation et composants partagés SQL
  • M: Fichiers de données de base de données (MDB)
  • L: Fichiers journaux de base de données (LDF)
  • T: fichiers de données et journaux TempDb

Les volumes M :, L: et T: ont été formatés à l’aide de ReFS (NTFS est également pris en charge) avec une taille d’allocation (cluster) de 64 Ko. Les lectures d’étendue SQL Server ont souvent une taille de huit pages, chaque page étant de 8 Ko, la lecture d’une seule étendue est donc de 64 Ko. Faire correspondre la taille du cluster à la mesure de la taille de lecture des données offre les meilleures performances.

Chaque serveur SQL dispose de deux adaptateurs réseau. Le principal est pour l’accès client et la synchronisation des données sur le groupe de disponibilité. Le second est pour une pulsation entre les serveurs SQL.

Comme les serveurs SQL utilisent une installation Core, PowerShell sera la méthode de configuration principale pour chaque serveur SQL.

3.6.1 Configuration de l’adaptateur réseau

Les étapes impliquent l’obtention de la carte réseau appropriée dans PowerShell, l’attribution d’une adresse IP, d’un sous-réseau et d’une passerelle; désactiver DHCP et enfin définir les adresses des clients DNS. L’adaptateur côté client sera renommé «Intranet» tandis que l’adaptateur de pulsation entre les serveurs SQL sera nommé «Heartbeat». La carte réseau Heartbeat se verra attribuer un sous-réseau privé non utilisé par d’autres appareils généraux sur le réseau. Adaptateur «Intranet» principal :

  • Adresse IP CALSQL01: 172.16.5.105
  • Adresse IP CALSQL02: 172.16.5.106

Utilisez Get-NetAdapter pour afficher toutes les cartes réseau disponibles sur le système. Ces étapes doivent être répétées pour le serveur SQL secondaire.

$adapter = Get-NetAdapter “Ethernet 2”

$adapter | New-NetIPAddress -AddressFamily IPv4 -IPAddress 172.16.5.105

-PrefixLength 16 -Type Unicast -DefaultGateway 172.16.0.1

Set-DnsClientServerAddress -InterfaceAlias $adapter.Name -ServerAddresses 172.16.5.1

Rename-NetAdapter -Name “Ethernet 2” -NewName “Intranet”

Adaptateur secondaire «Heartbeat»:

  • Adresse IP CALSQL01: 192.168.5.1
  • Adresse IP CALSQL02: 192.168.5.2

$adapter = Get-NetAdapter “Ethernet”

$adapter | New-NetIPAddress -AddressFamily IPv4 -IPAddress 192.168.5.1

-PrefixLength 24 -Type Unicast

Rename-NetAdapter -Name “Ethernet” -NewName “Heartbeat” These settings may also be set via the Network and Sharing center.

Désactivez l’enregistrement DNS sur l’adaptateur Heartbeat pour les deux serveurs à l’aide des éléments suivants:

Set-DnsClient -RegisterThisConnectionAddresss $false -InterfaceAlias “Heartbeat”

Cela empêche le réseau Heartbeat d’effectuer un enregistrement DNS dynamique, ce qui peut entraîner une perte de connectivité car AlwaysOn s’appuie sur les enregistrements DNS A. Pour définir cela via l’interface graphique, dans le centre Réseau et partage, recherchez l’adaptateur de pulsation. dans les propriétés «Internet Protocol Version 4 (TCP / IPv4)», cliquez sur Avancé, puis DNS, et désélectionnez «Enregistrer l’adresse de cette connexion dans DNS».

3.6.2 Configuration du stockage

La prochaine étape sera de provisionner le stockage pour chaque serveur SQL. Pour les disques «M:», «L:» et «T:», les disques utiliseront ReFS avec une taille d’allocation de 64 Ko. Utilisez Get-Disk pour afficher tous les disques du système.

Initialize-Disk 1 -PartitionStyle GPT

New-Partition 1 -UseMaximumSize -DriveLetter M

Format-Volume -DriveLetter M -FileSystem ReFS -AllocationUnitSize 65536

Répétez ce processus pour chaque disque, en remplaçant le numéro de disque («1» dans le précédent) par le disque non initialisé suivant et les paramètres de lettre de lecteur.

Cela peut également être accompli dans le Gestionnaire de serveur sous Services de fichiers et de stockage, puis en sélectionnant Volumes et en configurant les disques. À partir de là, utilisez l’assistant Nouveau volume en utilisant les paramètres précédents pour provisionner un nouveau lecteur.

3.6.3 Configuration d’identité

L’étape suivante du processus consiste à renommer le serveur, à redémarrer pour que le changement de nom prenne effet, enfin à joindre le serveur à Active Directory et à redémarrer à nouveau.

Rename-Computer -NewName <value> -Restart

$cred = Get-Credential #User credentials to join the computer to the domain

Add-Computer -Credential $cred -DomainName LAB -Restart

Cela peut également être accompli via le Panneau de configuration du système.

3.6.4 Configuration du cluster de basculement

La dernière étape consiste à installer le service de cluster de basculement et les outils de gestion. À l’aide de PowerShell, sur chaque serveur, exécutez les éléments suivants :

Install-WindowsFeature Failover-Clustering,NET-Framework-45-Core -IncludeManagementTools

Pour créer le cluster de basculement via PowerShell, le paramètre «-IncludeManagementTools» est requis.

Avant de créer le cluster, testez d’abord le cluster à partir de l’un des serveurs SQL en exécutant l’applet de commande Test-Cluster et en résolvant tous les problèmes qui peuvent apparaître. Comme ce cluster ne partage pas le stockage, comme le ferait un cluster de basculement traditionnel, aucun avertissement lié au stockage ne s’applique.

Test-Cluster -Node CALSQL01,CALSQL02

Créez le cluster. Le nom du cluster dans cet exemple est «CALSQLClus» avec une adresse IP de 172.16.5.200, ignorant le réseau de pulsation et ignorant le stockage local.

New-Cluster -Name “CALSQLClus” -Node CALSQL01,CALSQL02 -StaticAddress 172.16.5.200 -IgnoreNetwork 192.168.5.0/24 -NoStorage

Une fois le cluster créé, il est judicieux de renommer les adaptateurs réseau du cluster pour plus de clarté lors de l’administration du cluster. Obtenez d’abord une liste des réseaux de clusters ainsi que le sous-réseau de chaque réseau de clusters. En fonction de la valeur d’adresse de chaque adaptateur réseau de cluster, renommez l’adaptateur de manière appropriée.

Get-ClusterNetwork | fl *

$clusadapt = Get-ClusterNetwork -Cluster CALSQLClus -Name “Cluster Network

1”

$clusadapt.Name = “Intranet”

$clusadapt = Get-ClusterNetwork -Cluster CALSQLClus -Name “Cluster Network

2”

$clusadapt.Name = “Heartbeat”

Pour ce faire via l’interface graphique, exécutez le Gestionnaire de cluster de basculement sur l’un des serveurs SQL. Cliquez avec le bouton droit sur Gestionnaire de cluster de basculement et sélectionnez Créer un cluster. Sous Sélectionner les serveurs, ajoutez les serveurs SQL appropriés, comme illustré à la figure 3-1.

Figure 3-1. Affectation de nouveaux serveurs à un cluster de basculement

L’étape suivante consiste à définir le nom du cluster et l’adresse IP. En utilisant les mêmes paramètres que le PowerShell précédent, définissez les valeurs comme indiqué dans la figure 3-2.

Figure 3-2. Définition du nom et de l’adresse IP du cluster

À l’étape suivante, décochez « Ajouter tout le stockage éligible au cluster » et terminez l’assistant. Une fois terminé, vous verrez un avertissement attendu car l’assistant n’a pas trouvé de témoin de disque éligible.

La dernière étape consiste à configurer le témoin de quorum du cluster de basculement. Pour ce cluster, nous avons choisi d’utiliser un témoin cloud Azure pour réduire les coûts et la complexité de l’administration, bien qu’un partage de fichiers SQL Server ou Windows standard puisse également être utilisé comme témoin de cluster. Pour utiliser un témoin de cloud Azure, vous devez provisionner un abonnement Azure si celui-ci n’est pas déjà disponible. Nous supposerons qu’un abonnement a été créé.

Pour créer les ressources nécessaires, nous allons provisionner un groupe de ressources Azure et un compte de stockage Azure. Pour illustrer ces deux méthodes, installez d’abord le

Module AzureRM. Cela peut être fait à partir de n’importe quel ordinateur exécutant Windows PowerShell 5 (Windows 10 et Windows Server 2016 contiennent PowerShell 5 prêt à l’emploi). Les commandes suivantes installent le module AzureRM, se connectent au locataire Azure, créent un nouveau groupe de ressources nommé «SqlClusterWitness» et enfin un compte de stockage Azure nommé «calsql» dans US West 2 en utilisant un stockage redondant local standard.

Install-Module -Name AzureRM

Login-AzureRmAccount

$rg = New-AzureRmResourceGroup -Name ‘SqlClusterWitness’ -Location ‘westus2’

$sa = New-AzureRmStorageAccount -ResourceGroupName $rg.ResourceGroupName -Name ‘calspag’ -Location ‘westus2’ -SkuName Standard_LRS

Pour créer la même ressource via https://portal.azure.com , connectez-vous à votre abonnement Azure. Cliquez sur Créer une ressource et recherchez le compte de stockage. Cela fera apparaître le résultat pour “Compte de stockage – blob, fichier, table, file d’attente.” Entrez le nom du compte de stockage, emplacement, définissez la réplication sur le stockage localement redondant (LRS) et créez un nouveau groupe de ressources comme indiqué dans la figure 3-3.

Figure 3-3. Création d’un nouveau compte de stockage pour un témoin de cloud Azure

Remarque La réplication du compte de stockage doit être définie sur Stockage redondant localement (LRS) pour un témoin de cloud Azure.

Une fois le témoin Azure créé, il devrait ressembler à la figure 3-4 .

Figure 3-4. Un témoin Azure terminé

Enregistrez le nom du compte de stockage, dans ce cas, «calsql», et récupérez la clé primaire. La clé peut être trouvée via PowerShell à l’aide de l’applet de commande suivante.

Get-AzureRmStorageAccountKey -ResourceGroupName ‘SqlClusterWitness’ -Name

‘calsql’

Cela fournira la sortie de deux clés. Nous allons sélectionner la valeur de «key1».

Copiez la valeur de key1.

La clé peut également être trouvée via le portail Azure. Accédez à votre groupe de ressources et cliquez sur le compte de stockage («calsql»). Sous Clés d’accès, copiez la valeur de clé pour key1, comme illustré dans la figure 3-5 .

Figure 3-5. Recherche des clés d’accès pour le compte de stockage

Sur le serveur SQL, exécutez le PowerShell suivant pour définir le témoin de quorum de cluster sur un témoin cloud.

Set-ClusterQuorum -CloudWitness -AccountName ‘calsql’ -AccessKey ‘0lyupsH/Sp14l3NImUHq/OaOLH5GTWlVw9Ld3wVMtLr5m90m+kEEHvVmYcs4J39zpeM1U7a67HceyQf3bs3 uVA==’ -Endpoint core.windows.net

Cela peut également être accompli via le gestionnaire de cluster de basculement. Cliquez avec le bouton droit sur le SQL

Grappe. Sous Plus d’actions, sélectionnez Configurer les paramètres de quorum de cluster. Dans le Configure

Assistant de quorum de cluster, choisissez l’option «Sélectionner le témoin de quorum», puis sélectionnez «Configurer un témoin cloud». Saisissez le nom du compte de stockage, la valeur de key1 pour la clé du compte de stockage, comme illustré à la figure 3-6 . Le point de terminaison du service au moment de la rédaction de cet article n’a pas besoin d’être modifié par rapport à la valeur par défaut de core.windows.net.

Figure 3-6. Configuration d’un témoin de cloud Azure comme quorum

La configuration du cluster est terminée et prête pour l’installation de SQL Server 2017.

3.7 Installation de SQL Server 2017

Cette section couvre l’installation de SQL Server 2017 sur Windows Server 2016 via la ligne de commande ainsi que via l’interface graphique.

Pour SQL Server, nous utiliserons l’édition Enterprise. Le compte de service SQL Server sera un compte de service géré de groupe, LAB \ s-sql $.

3.7.1 Installation de SQL Server

L’installation de SQL Server elle-même est configurée via un fichier .ini, tandis que l’installation est traitée via un fichier de commandes. Les paramètres du fichier .ini doivent être ajustés en conséquence pour l’environnement spécifique.

[OPTIONS]

ACTION=”Install”

FEATURES=SQLENGINE,REPLICATION

INSTANCENAME=”MSSQLSERVER”

SQLSVCACCOUNT=LAB\s-sql$

SQLSYSADMINACCOUNTS=”LAB\Domain Admins”

IAcceptSQLServerLicenseTerms=”True”

QUIET=”True”

UpdateEnabled=”False”

ERRORREPORTING=”False”

INSTANCEDIR=”M:\Program Files\Microsoft SQL Server”

AGTSVCACCOUNT=LAB\s-sql$

AGTSVCSTARTUPTYPE=Automatic

SQLSVCINSTANTFILEINIT=True

SQLSVCSTARTUPTYPE=Automatic

SQLTEMPDBDIR=T:\Data

SQLTEMPDBLOGDIR=T:\Data

SQLUSERDBDIR=M:\Data

SQLUSERDBLOGDIR=L:\Logs

TCPENABLED=1

SQLCOLLATION=Latin1_General_CI_AS_KS_WS

Une fois le fichier Configuration.ini créé, créez un fichier SQLInstall.bat dans le même répertoire, en spécifiant les paramètres d’installation spécifiques à l’environnement.

@ECHO OFF set CDRoot=D:

@ECHO ON

%CDRoot%\Setup.exe /ConfigurationFile= Configuration.ini /Q

Exécutez SQLInstall.bat sur les deux serveurs SQL pour installer SQL en mode sans assistance.

Pour ce faire via l’Assistant Installation de SQL Server, suivez les invites suivantes. Exécutez setup.exe et dans le Centre d’installation de SQL Server, sous Installation, sélectionnez «Nouvelle installation autonome SQL Server ou ajoutez des fonctionnalités à une installation existante». Pour terminer les parties initiales de l’assistant, sous Sélection des fonctionnalités, sélectionnez la fonctionnalité suivante:

Database Engine Services

Définissez le répertoire racine de l’instance sur «M:\Program Files\Microsoft SQL Server\» et laissez les répertoires de fonctionnalités partagés sur les chemins par défaut. Dans la configuration d’instance, laissez les paramètres par défaut de « Default instance » et un ID d’instance de « MSSQLSERVER ». Utilisez le compte de service géré de groupe (LAB \ s-sql $) pour les services configurables et sélectionnez l’option Grant Perform Volume Maintenance Task, comme illustré à la figure 3-7. Dans l’onglet Classement, cliquez sur Personnaliser. Sélectionnez « Indicateur de classement Windows et ordre de tri ». Sélectionnez « Latin1_Général » dans le menu déroulant, puis cochez Sensible à l’accent, Sensible à Kana et enfin Sensible à la largeur. Cela définira le classement SQL Server sur Latin1_General_CI_AS_KS_WS.

Remarque Latin1_general_CI_AS_KS_WS n’est pas requis, mais recommandé pour les bases de données système, ce que nous définissons ici. Latin1_general_CI_ AS_KS_WS est requis pour les bases de données SharePoint et est défini par défaut lorsque SharePoint provisionne les bases de données. Voir https://support.microsoft.com/ help / 2008668 / pour plus d’informations.

Figure 3-7. Configuration des paramètres de compte pour SQL Server

Dans la configuration du moteur de base de données, ajoutez un ou plusieurs utilisateurs et / ou groupes aux administrateurs SQL Server. Dans cet exemple, nous avons utilisé le groupe Administrateurs de domaine, mais vous souhaiterez peut-être utiliser un groupe moins privilégié.

Sous répertoires de données, laissez le répertoire racine de données par défaut. Définissez le répertoire de la base de données utilisateur sur M:\Data\ et le répertoire du journal de la base de données utilisateur sur L:\Logs\. Enfin, sous TempDB, définissez le répertoire Data et le répertoire Log sur T :\Data\.

3.7.2 Configuration du groupe de disponibilité SQL Server AlwaysOn

Cette section montre comment activer SQL Server AlwaysOn d’abord via SQL PowerShell, puis graphiquement via le gestionnaire de configuration SQL Server.

Pour commencer, nous pouvons rapidement activer AlwaysOn via PowerShell sur chaque serveur SQL. Pour ce faire, exécutez le script suivant.

Import-Module -Name SqlServer

Enable-SqlAlwaysOn -Path SQLSERVER:\SQL\$env:COMPUTERNAME\DEFAULT -Force

Ce script redémarrera automatiquement l’instance de service SQL Server pour que la modification prenne effet.

Si vous utilisez Windows Server avec Desktop Experience installé, AlwaysOn peut être activé via le Gestionnaire de configuration SQL Server. En exécutant Configuration Manager, cliquez sur SQL Server Services, puis cliquez avec le bouton droit sur «SQL Server (MSSQLSERVER)» et accédez à Propriétés. Dans l’onglet AlwaysOn High Aavailbility, cochez la case «Enable AlwaysOn Availability Groups», comme illustré à la figure 3-8 .

Figure 3-8. Activation de SQL Server AlwaysOn via le gestionnaire de configuration

Une fois activé dans Configuration Manager, redémarrez l’instance de service SQL Server.

Le prochain ensemble de tâches sera effectué à l’aide de SQL Server Management Studio (SSMS) sur un poste de travail distant.

Remarque SQL Server Management Studio peut être téléchargé à partir de https: // docs. microsoft.com/en-us/sql/ssms/download-sql-server-management studio- ssms .

Connectez-vous au serveur SQL principal à l’aide de l’authentification Windows. Nous allons créer une base de données temporaire pour initialiser le groupe de disponibilité AlwaysOn. Cela peut être accompli via T-SQL en utilisant ce qui suit :

CREATE DATABASE [aoagseed] ON PRIMARY

(NAME = N’aoagseed’, FILENAME = N’M:\Data\aoagseed.mdf’, SIZE = 8192KB,

FILEGROWTH = 65536KB)

LOG ON

(NAME = N’aoagseed_log’, FILENAME = N’L:\Logs\aoagseed_log.ldf’,

SIZE = 8192KB, FILEGROWTH = 65536KB)

ALTER DATABASE [aoagseed] SET RECOVERY FULL

GO

USE [aoagseed]

IF NOT EXISTS (SELECT name FROM sys.filegroups WHERE is_default=1 AND name

= N’PRIMARY’)

ALTER DATABASE [aoagseed] MODIFY FILEGROUP [PRIMARY] DEFAULT

Vous pouvez également cliquer avec le bouton droit sur le nœud Bases de données du serveur SQL principal et sélectionner Nouvelle base de données. Donnez un nom et cliquez sur OK. Aucune option ne doit être définie.

Ensuite, créez une sauvegarde complète de la base de données. Le T-SQL suivant utilise notre emplacement de sauvegarde par défaut, mais peut être ajusté à n’importe quel emplacement requis.

BACKUP DATABASE aoagseed TO DISK=’M:\Program Files\Microsoft SQL Server\

MSSQL14.MSSQLSERVER\MSSQL\Backup\aoagseed.bak’

Sur chaque serveur SQL, nous devons créer une connexion pour le compte de service géré de groupe avant de créer le groupe de disponibilité AlwaysOn via T-SQL. Pour ce faire, exécutez ce qui suit dans SSMS lorsque vous êtes connecté à chaque serveur SQL:

CREATE LOGIN [LAB\s-sql$] FROM Windows

L’étape suivante consiste à créer l’AOAG nommé «CALAG». Ce script spécifie les deux serveurs SQL, en utilisant Synchronious Commit, une préférence de sauvegarde du serveur SQL principal, en utilisant le mode d’amorçage automatique, et crée enfin l’écouteur de groupe de disponibilité AlwaysOn nommé «caspag» avec une adresse IP de 172.16.5.201. Ce script nécessite l’utilisation du mode SQLCMD qui peut être défini dans SSMS sous le menu Requête en sélectionnant «Mode SQLCMD».

Pour créer l’AOAG via SSMS, cliquez avec le bouton droit sur le nœud AlwaysOn High Availability et sélectionnez l’Assistant Nouveau groupe de disponibilité. Comme le montre la figure 3-9, définissez le nom AOAG et laissez les autres options à leurs valeurs par défaut.

Figure 3-9. Nommer le groupe de disponibilité AlwaysOn

Ensuite, sélectionnez la base de données aoagseed comme le montre la figure 3-10. Vérifiez que l’état est «Répond aux prérequis», sinon effectuez l’action appropriée indiquée par l’état.

Figure 3-10. Sélection de la base de données des semences

Dans l’étape suivante, choisissez Ajouter une réplique et connectez-vous au serveur SQL secondaire, CALSQL02 dans cet exemple. Vérifiez le basculement automatique et vérifiez que le mode de disponibilité est défini sur Validation synchrone. SharePoint Server n’utilise pas de fichiers secondaires lisibles, nous la laissons donc non cochée. Lorsque les options sont définies correctement, cela ressemblera à la figure 3-11.

Figure 3-11. Ajout de la réplique et définition des options de réplique

Sous Préférence de sauvegarde, sélectionnez le principal comme indiqué dans la figure 3-12. Le secondaire prend uniquement en charge les sauvegardes de copie uniquement. Ces sauvegardes ne peuvent pas tronquer le journal des transactions, nous devons donc prendre nos sauvegardes uniquement à partir du serveur principal.

Figure 3-12. Définition de la préférence de sauvegarde

La dernière option que nous devons spécifier est l’écouteur. Dans l’onglet Listener, définissez le nom DNS du listener sur un nom d’hôte unique. Définissez le port sur 1433 et fournissez une adresse IP inutilisée pour l’écouteur, comme illustré à la figure 3-13.

Figure 3-13. Définition des options d’écoute

La dernière étape avant de créer l’AOAG consiste à définir la préférence de synchronisation, comme illustré à la figure 3-14. Dans cet exemple, nous utiliserons l’amorçage automatique. L’amorçage automatique nous permet d’avoir SQL Server ajouter des bases de données à l’AOAG sans effectuer de sauvegarde explicite des bases de données au préalable.

Figure 3-14. Choix de la préférence de synchronisation

Terminez l’assistant et l’AOAG sera créé. La dernière étape que nous prendrons consiste à définir la valeur HostRecordTTL sur l’enregistrement AOAG DNS A; cela définit la durée de vie sur l’enregistrement A à une valeur inférieure qui indique aux clients de regarder l’IP de l’enregistrement sur une base plus fréquente. Cela peut être accompli via PowerShell sur l’un des serveurs SQL ou à distance sur un poste de travail client avec les outils de gestion du cluster de basculement installés, comme illustré dans la figure 3-15.

#Récupérez les ressources du cluster et sélectionnez le nom de réseau appartenant au groupe de disponibilité.

Get-ClusterResource -Cluster CALSQLClus

#Définissez la propriété sur le nom du réseau

Get-ClusterResource -Cluster CALSQLClus -Name ‘CALAG_caspag’ | Set-

ClusterParameter HostRecordTTL 300

#Rapportez le nom de réseau hors ligne et en ligne

Stop-ClusterResource -Cluster CALSQLClus -Name ‘CALAG_caspag’

Start-ClusterResource -Cluster CALSQLClus -Name ‘CALAG_caspag’

Start-ClusterResource -Cluster CALSQLClus -Name ‘CALAG’

Figure 3-15. Définition de la valeur HostRecordTTL sur le nom de réseau AOAG

À ce stade, vous pouvez supprimer la base de données aoagseed temporaire du groupe de disponibilité AlwaysOn et supprimer la base de données des serveurs SQL principal et secondaire. Ceci termine le groupe de disponibilité AlwaysOn.

3.7.3 Base de données de modèles

La base de données modèle dans SQL Server est le modèle de toutes les futures bases de données créées sur SQL Server. Les valeurs initiales de la base de données modèle ne sont pas toujours optimales et peuvent être ajustées avec T-SQL. La taille de fichier initiale variera en fonction de l’utilisation intensive de l’environnement, et pour cet environnement, elle sera définie à 100 Mo conservateurs pour modeldev (fichier de données) et modellog (fichier journal). Pour cela, sur le réplica principal et secondaire, exécutez la commande T-SQL suivante :

ALTER DATABASE [model] MODIFY FILE (NAME = modeldev, SIZE = 100MB, MAXSIZE = UNLIMITED)

ALTER DATABASE [model] MODIFY FILE (NAME = modellog, SIZE = 100MB, MAXSIZE = UNLIMITED)

Notez que nous ne spécifions pas la propriété FILEGROWTH car SharePoint ignore cette valeur lors de la création de bases de données.

3.7.4 MAXDOP

À condition que le compte qui installe SharePoint ait le rôle fixe sysadmin dans l’instance SQL Server, MAXDOP (Max Degree of Paralellism) sera automatiquement défini.

SharePoint Server 2019 refusera de se déployer si MAXDOP n’est pas défini sur 1. La valeur de MAXDOP est le nombre de processeurs qui seront utilisés pour exécuter une seule instruction SQL. SharePoint a été testé pour fonctionner correctement avec un MAXDOP de 1 uniquement. Si l’utilisateur qui installe SharePoint ne dispose pas des droits appropriés sur SQL Server, l’administrateur SQL Server peut définir cette valeur via T-SQL ou via SQL Server Management Studio. Il peut également être nécessaire de définir manuellement cette valeur sur tous les serveurs secondaires du groupe de disponibilité.

sp_configure ‘show advanced options’, 1;

GO

RECONFIGURE WITH OVERRIDE;

GO

sp_configure ‘max degree of parallelism’, 1;

GO

RECONFIGURE WITH OVERRIDE;

GO

3.7.5 Verrouiller les pages en mémoire

SQL Server offre des fonctionnalités pour verrouiller les pages en mémoire. Le verrouillage des pages en mémoire permet à SQL Server d’indiquer à Windows qu’il ne doit pas libérer de mémoire allouée par SQL Server. Cette étape est facultative.

Nous examinerons trois façons d’accomplir cette tâche.

NTRights.exe est fourni avec les outils du Kit de ressources Windows 2003. Cette application de ligne de commande peut être installée sur les versions modernes de Windows et de Windows Server 2016, fonctionne toujours correctement. Exécutez la ligne de commande suivante pour accorder le droit de verrouillage des pages en mémoire à LAB \ s-sql $.

Ntrights.exe -u LAB \ s-sql $ + r SeLockMemoryPrivilege

Remarque Les outils du Kit de ressources Windows 2003 peuvent être téléchargés à partir de www. microsoft.com/en-us/download/details.aspx?id=17657 .

La deuxième méthode consiste à utiliser un module PowerShell UserRights.psm1 disponible sur https://gallery.technet.microsoft.com/scriptcenter/Grant-Revoke-Query-user 26e259b0 . Téléchargez le script sur le serveur SQL et exécutez-le à l’aide de la méthode suivante:

Import-Module UserRights.psm1

Grant-UserRight -Account ‘LAB\s-sql -Right SeLockMemoryPrivilege

La dernière étape consiste à utiliser la stratégie de sécurité locale MMC. Si vous avez installé SQL Server sur Windows Server avec Desktop Experience, ouvrez le menu Démarrer et recherchez «Politique de sécurité locale». Sous Stratégies locales, Attribution des droits utilisateur, recherchez le paramètre Verrouiller les pages en mémoire. Ajoutez LAB \ s-sql $.

Si vous avez installé Windows Server à l’aide de l’option d’installation Core, vous devez d’abord définir cette valeur de verrouillage des pages en mémoire sur un serveur Windows exécutant Desktop Experience, exporter la stratégie vers un fichier INF, puis l’importer sur le serveur exécutant Windows Core.

Dans la console de gestion de la stratégie de sécurité locale, exportez la stratégie sous Actions vers un fichier INF. Copiez cet INF sur le système Windows Server Core. À partir de là, exécutez ce qui suit:

secedit.exe /configure /db secedit.sdb /cfg C:\export.INF

Ceci termine l’installation de SQL Server. Avec une configuration SQL Server AlwaysOn entièrement fonctionnelle, nous sommes prêts à enfin installer SharePoint Server 2019!

3.8 Installation de SharePoint Server 2019

SharePoint sera installé sur quatre serveurs. Le processus de configuration consistera à exécuter le programme d’installation prérequis en mode silencieux. Une fois le programme d’installation prérequis terminé, les fichiers binaires SharePoint seront installés. Un certificat générique pour * .cobaltatom.com a été déployé sur tous les serveurs SharePoint pour être utilisé pour les applications Web.

3.8.1 Désactiver les protocoles de sécurité de transport non sécurisés

SharePoint Server 2019 prend en charge TLS 1.2. Pour cette raison, il est fortement recommandé de désactiver les protocoles précédents, notamment SSL 3.0, TLS 1.0 et TLS 1.1. Par défaut, SSL 2.0 est désactivé dans Windows Server 2016.

Pour désactiver les protocoles précédents, exécutez le script PowerShell suivant sur chaque serveur SharePoint. Cette modification de configuration nécessite un redémarrage pour prendre effet.

#Disable PCT 1.0

ni “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\

Protocols\” -Name “PCT 1.0” -Value “DefaultValue” -Force

ni “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\

Protocols\PCT 1.0\” -Name “Server” -Value “DefaultValue” -Force

New-ItemProperty “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\ SCHANNEL\Protocols\PCT 1.0\Server\” -Name Enabled -Value 0 -PropertyType

“DWord” -Force

#Disable SSL 2.0

ni “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\

Protocols\” -Name “SSL 2.0” -Value “DefaultValue” -Force

ni “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\

Protocols\SSL 2.0\” -Name “Server” -Value “DefaultValue” -Force

New-ItemProperty “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\ SCHANNEL\Protocols\SSL 2.0\Server\” -Name Enabled -Value 0 -PropertyType

“DWord” -Force

#Disable SSL 3.0

ni “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\

Protocols\” -Name “SSL 3.0” -Value “DefaultValue” -Force

ni “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\

Protocols\SSL 3.0\” -Name “Server” -Value “DefaultValue” -Force

New-ItemProperty “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\ SCHANNEL\Protocols\SSL 3.0\Server\” -Name Enabled -Value 0 -PropertyType

“DWord” -Force

#Disable TLS 1.0

ni “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\

Protocols\” -Name “TLS 1.0” -Value “DefaultValue” -Force

ni “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\

Protocols\TLS 1.0\” -Name “Server” -Value “DefaultValue” -Force

New-ItemProperty “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\ SCHANNEL\Protocols\TLS 1.0\Server\” -Name Enabled -Value 0 -PropertyType

“DWord” -Force

#Disable TLS 1.1

ni “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\

Protocols\” -Name “TLS 1.1” -Value “DefaultValue” -Force

ni “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\

Protocols\TLS 1.1\” -Name “Server” -Value “DefaultValue” -Force

New-ItemProperty “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\ SCHANNEL\Protocols\TLS 1.1\Server\” -Name Enabled -Value 0 -PropertyType

“DWord” -Force

3.8.2 Installation silencieuse préalable

Pour installer tous les prérequis en mode silencieux, ils doivent être téléchargés depuis

Microsoft et placé dans un répertoire sur le serveur SharePoint. Dans cet exemple, les fichiers binaires SharePoint ont été copiés dans C: \ SharePoint2019, où PrerequisiteInstaller.exe réside.

Start-Process “C:\SharePoint2019\ISO\PrerequisiteInstaller.exe”

-ArgumentList “/SQLNCli:`”C:\SharePoint2019\ISO\PrerequisiteInstallerFiles\ sqlncli.msi`” `

/Sync:`”C:\SharePoint2019\ISO\PrerequisiteInstallerFiles\Synchronization.msi`” `

/AppFabric:`”C:\SharePoint2019\ISO\PrerequisiteInstallerFiles\

WindowsServerAppFabricSetup_x64.exe`” `

/IDFX11:`”C:\SharePoint2019\ISO\PrerequisiteInstallerFiles\

MicrosoftIdentityExtensions-64.msi`” `

/MSIPCClient:`”C:\SharePoint2019\ISO\PrerequisiteInstallerFiles\setup_ msipc_x64.exe`” `

/KB3092423:`”C:\SharePoint2019\ISO\PrerequisiteInstallerFiles\AppFabric- KB3092423- x64-ENU.exe`” `

/WCFDataServices56:`”C:\SharePoint2019\ISO\PrerequisiteInstallerFiles\

WcfDataServices.exe`” `

/DotNet472:`”C:\SharePoint2019\ISO\PrerequisiteInstallerFiles\NDP472- KB4054531- Web.exe`” `

/MSVCRT11:`”C:\SharePoint2019\ISO\PrerequisiteInstallerFiles\vcredist_x64.exe`” `

/MSVCRT141:`”C:\SharePoint2019\ISO\PrerequisiteInstallerFiles\VC_redist.x64.exe`””

Le programme d’installation prérequis nécessitera un redémarrage unique. Lorsque vous vous reconnectez à SharePoint Server après un redémarrage, le programme d’installation prérequis démarre automatiquement pour valider l’installation.

Remarque Le téléchargement de chaque prérequis est disponible à partir des liens suivants :

Les fichiers binaires SharePoint sont installés via setup.exe. Selon la figure 3-16, lors de l’installation de SharePoint Server, vous serez invité à indiquer l’emplacement d’installation de SharePoint ainsi que l’emplacement de l’index de recherche. Si vous déployez un serveur de recherche, vous souhaiterez peut-être localiser l’index sur un autre volume dédié à l’index de recherche. Envisagez de modifier le chemin d’accès à un autre volume car l’analyse et la création de fichiers temporaires pour le traitement du contenu seront utilisées pour cet emplacement, quel que soit l’emplacement de l’index de recherche. À la fin de l’installation, décochez «Exécuter l’Assistant Configuration des produits SharePoint maintenant». , car cet article vous guidera à travers l’utilisation de SharePoint Management Shell pour déployer SharePoint.

Figure 3-16. Spécification de l’installation et de l’emplacement de l’index de recherche pour SharePoint

SharePoint Server 2019 est désormais installé sur les quatre membres de la batterie. Nous sommes maintenant prêts à démarrer la configuration de SharePoint Server 2019.

Conseil Il est possible de diffuser les mises à jour publiques dans l’installation de base de SharePoint Server. Voir https://go.microsoft.com/fwlink/?linkid=2003452   pour plus d’informations sur la façon d’effectuer cette tâche.

3.9 Configuration de SharePoint Server 2019

Au lieu d’exécuter l’Assistant Configuration de SharePoint, cet article fournira des scripts PowerShell pour configurer SharePoint.

Exécutez SharePoint Management Shell en tant qu’administrateur sur le serveur qui hébergera l’administration centrale. Dans cet exemple, il s’agit de CALSP03. Le paramètre -FarmCredential sera le compte de service d’utilisateur de domaine, LAB \ s-farm.

New-SPConfigurationDatabase -DatabaseName Configuration

-AdministrationContentDatabaseName Administration -DatabaseServer caspag. lab.cobaltatom.com -Passphrase (ConvertTo-SecureString “FarmPassphrase1” -AsPlainText -Force) -FarmCredentials (Get-Credential) -LocalServerRole

ApplicationWithSearch -SkipRegisterAsDistributedCacheHost

Notez l’utilisation de l’écouteur de groupe de disponibilité pour le paramètre -DatabaseServer. Au lieu d’utiliser un alias SQL configuré via cliconfg.exe sur le serveur SharePoint, l’écouteur de groupe de disponibilité est utilisé. Comme nous pouvons ajouter et supprimer des serveurs SQL du groupe de disponibilité, ou même déplacer complètement le nom de l’écouteur du groupe de disponibilité vers un autre groupe de disponibilité, il n’est plus nécessaire de spécifier un alias SQL.

Conseil Si vous utilisez cliconfg.exe pour créer un alias SQL, assurez-vous d’exécuter cliconfig.exe sur tous les serveurs SharePoint de la batterie de serveurs. Chaque serveur SharePoint doit avoir le même alias SQL configuré.

En outre, notez le nouveau paramètre, -LocalServerRole, qui prend une valeur de

Application, DistributedCache, WebFrontEnd, Search, Custom, ApplicationWithSearch, WebFrontEndWithDistributedCache ou SingleServerFarm. Cela spécifie le MinRole utilisé pour le serveur particulier. Comme il hébergera l’administration centrale à l’aide d’un MinRole partagé, le rôle ApplicationWithSearch est le choix approprié.

La prochaine série d’autorisations d’applet de commande sécurisées sur les fichiers et les entrées de registre utilisés par SharePoint, provisionne les fonctionnalités, les services et l’aide de SharePoint.

Initialize-SPResourceSecurity

Install-SPFeature -AllExistingFeatures

Install-SPService

Install-SPApplicationContent

Remarque Install-SPHelpCollection n’est plus requis car l’aide est maintenant en ligne.

Astuce Vous pouvez trouver la définition des ACL Initialize-SPResourceSecurity qui s’applique en consultant le registre! Accédez à HKEY_LoCAL_MACHINE \

SoFTWARE \ Microsoft \ Shared Tools \ Web Server Extensions \ 16.0 \ WSS \

ResourcesToSecure \. Chaque ressource est définie par un gUID, mais sous la clé au format d’un gUID se trouve un ResourceName qui est le chemin d’accès à l’élément à sécuriser, ainsi que les autorisations (lecture (R), écriture (W), exécution (E ), Contrôle total (FC) et Autorisation de modification (D)).

3.9.1 Administration centrale

Pour configurer l’administration centrale pour utiliser Kerberos comme mécanisme d’authentification, un nouveau SPN doit être défini sur le compte de la batterie. Le SPN prendra le format HTTP / CentralAdminFQDN.

Setspn -U -S HTTP/cal.lab.cobaltatom.com LAB\s-farm

Conseil Le SPN d’un site Web commencera toujours par «HTTP» même si le site utilise le protocole SSL, car HTTP est un service Kerberos, pas une description de protocole.

Créez l’administration centrale à l’aide de Kerberos et SSL.

New-SPCentralAdministration -Port 443 -WindowsAuthProvider Kerberos

-SecureSocketsLayer:$true

L’étape suivante consiste à modifier le mappage d’accès alternatif par défaut pour l’aligner sur le certificat SPN et SSL. Utilisez Get-SPWebApplication -IncludeCentralAdministration pour voir quelle est l’URL actuelle de l’administration centrale, puis modifiez-la.

Set-SPAlternateUrl -Identity https://calsp03 -Url https://cal.lab.cobaltatom.com

Si une URL personnalisée a été définie pour l’Administration centrale qui n’inclut pas le nom de l’ordinateur, assurez-vous de créer un enregistrement A dans DNS pour résoudre le nouveau nom d’hôte. En outre, vérifiez que les liaisons de sites IIS pour le site Administration centrale de SharePoint sont définies correctement, comme illustré à la figure 3-17 . Étant donné que ce serveur n’aura qu’une seule adresse IP mais devra prendre en charge plusieurs certificats SSL, l’indication du nom du serveur sera utilisée. SNI est compatible avec tous les navigateurs pris en charge par SharePoint Server 2019.

Figure 3-17. Validation de la liaison de sites IIS de l’administration centrale

L’étape suivante consiste à rendre les bases de données d’administration et de configuration hautement disponibles.

Afin d’obtenir une haute disponibilité pour les bases de données, lorsqu’une base de données SharePoint est créée, vous devez l’ajouter au groupe de disponibilité. Cela peut être réalisé via SQL Server Management Studio à partir d’un ordinateur client. La première étape consiste à effectuer une sauvegarde complète de la base de données. Dans cet exemple, nous utiliserons la base de données de configuration, bien qu’elle doive être effectuée avec toutes les bases de données créées pour la batterie de serveurs.

Sur le réplica principal, à l’aide de T-SQL, la sauvegarde de la base de données ainsi que du journal des transactions en tant que groupe de disponibilité nécessite l’utilisation du modèle de récupération complète pour chaque base de données faisant partie du groupe de disponibilité. Spécifiez le chemin du fichier. Chaque fichier doit avoir un nom unique. Ajoutez la base de données au groupe de disponibilité, nommé SPHADR dans ce scénario.

BACKUP DATABASE Configuration TO DISK=’M:\Program Files\Microsoft SQL

Server\MSSQL14.MSSQLSERVER\MSSQL\Backup\Configuration.bak’;

BACKUP DATABASE Administration TO DISK=’M:\Program Files\Microsoft SQL

Server\MSSQL14.MSSQLSERVER\MSSQL\Backup\Administration.bak’;

ALTER AVAILABILITY GROUP CALAG ADD DATABASE Configuration;

ALTER AVAILABILITY GROUP CALAG ADD DATABASE Administration;

Étant donné que nous avons configuré l’AOAG pour utiliser l’amorçage automatique, nous n’avons pas besoin d’effectuer d’autres actions préalables pour ajouter les bases de données au groupe de disponibilité.

Pour ajouter une base de données via l’assistant de groupe de disponibilité, effectuez d’abord une sauvegarde complète via l’assistant, illustré à la figure 3-18 . Cliquez avec le bouton droit sur la base de données et accédez au nœud Tâches, puis sur Sauvegarder. Spécifiez l’emplacement de sauvegarde partagé et un nom de fichier, dans cet exemple, Administration.bak.

Figure 3-18. Faire une sauvegarde de la base de données de contenu de l’administration centrale à partir de SQL Server Management Studio

Pour terminer l’ajout de la base de données au groupe de disponibilité, cliquez avec le bouton droit sur le groupe de disponibilité dans SQL Server Management Studio sous le nœud AlwaysOn High Availability \ Availability Groups, puis cliquez sur Ajouter une base de données. L’état de l’écran Sélectionner une base de données doit se lire «Répond aux prérequis» pour la base de données à ajouter, comme illustré à la figure 3-19 . Les étapes suivantes consistent à ajouter la base de données au groupe de disponibilité en utilisant l’amorçage automatique comme synchronisation des données, illustré ici dans la figure 3-20 .

Figure 3-19. Ajout de la base de données de contenu de l’administration centrale via l’assistant Ajouter une base de données au groupe de disponibilité

Figure 3-20. Sélection de l’option d’amorçage automatique pour ajouter le Central

Base de données de contenu d’administration à l’AOAG

Connectez-vous à la réplique secondaire. L’étape de validation vous avertira de toute erreur empêchant l’ajout de la base de données au groupe de disponibilité. Un résumé des étapes sera fourni et la dernière étape ajoutera la base de données au groupe de disponibilité. Les bases de données étant initialement petites, ce processus devrait être rapide.

Cela termine la configuration du groupe de disponibilité pour les bases de données de configuration et d’administration, mais n’oubliez pas que toutes les bases de données nouvellement créées pour SharePoint, à l’exception notable que vous trouverez dans ce chapitre, doivent être ajoutées au groupe de disponibilité lors de leur création.

3.9.2 Validation SQL Kerberos

Afin de valider que SharePoint se connecte à SQL Server à l’aide de Kerberos, exécutez le script suivant dans SQL Server Management Studio tout en étant connecté au groupe de disponibilité. Notez la clause WHERE spécifiant la première partie du nom de tous les serveurs SharePoint de cette batterie. Cette clause WHERE peut être supprimée, si nécessaire.

SELECT

s.session_id,

c.connect_time,

s.login_time,

s.login_name,

c.protocol_type,

c.auth_scheme,

s.HOST_NAME,

s.program_name

FROM sys.dm_exec_sessions s

JOIN sys.dm_exec_connections c

ON s.session_id = c.session_id

WHERE HOST_NAME like ‘CALSP%’

Si les serveurs se connectent via Kerberos, la valeur auth_scheme affichera KERBEROS, comme le montre la figure 3-21 .

Figure 3-21. Le service SharePoint Timer se connectant à SQL Server via Kerberos

Si Kerberos n’a pas été configuré correctement sur SQL Server, l’auth_scheme affichera NTLM. Notez qu’il est normal que certaines connexions s’affichent en NTLM, comme si vous êtes connecté à SQL Server localement.

Remarque Si votre auth_scheme continue de s’afficher en tant que «NTLM» après avoir défini le SPN, vérifiez que vous avez redémarré vos serveurs SharePoint ainsi que le service SQL Server.

3.9.3 Ajout de serveurs SharePoint

L’ajout des serveurs SharePoint restants à la batterie de serveurs est simple. En fonction de leur rôle, un seul paramètre changera, -LocalServerRole.

Pour le serveur suivant, CALSP04, un serveur d’applications et de recherche, nous devons exécuter l’applet de commande suivante à partir de SharePoint Management Shell:

Connect-SPConfigurationDatabase -DatabaseName Configuration -DatabaseServer caspag.lab.cobaltatom.com -Passphrase (ConvertTo- SecureString “FarmPassphrase1” -AsPlainText -Force) -LocalServerRole ApplicationWithSearch

Comme CALSP04 exécutera également l’administration centrale, assurez-vous d’installer le certificat SSL de l’administration centrale sur CALSP04.

Ensuite, les serveurs frontaux, CALSP01 et CALSP02 avec le paramètre -LocalServerRole WebFrontEndWithDistributedCache.

Connect-SPConfigurationDatabase -DatabaseName Configuration -DatabaseServer caspag.lab.cobaltatom.com -Passphrase (ConvertTo- SecureString “FarmPassphrase1” -AsPlainText -Force) -LocalServerRole WebFrontEndWithDistributedCache -SkipRegisterAsDistributedCacheHost

Pour chaque serveur, nous devrons également exécuter des applets de commande pour provisionner les services, les fonctionnalités et définir la sécurité sur le système de fichiers et les objets de registre. Si le serveur a un rôle de recherche, vous n’avez pas besoin d’exécuter Install-SPApplicationContent; cependant, tous les serveurs de cette batterie de serveurs utilisent des MinRoles partagés qui nécessitent l’exécution de cette applet de commande.

Initialize-SPResourceSecurity

Install-SPService

Install-SPFeature -AllExistingFeatures

Install-SPApplicationContent

Une fois les applets de commande terminées, si le service du minuteur SharePoint n’est pas démarré, démarrez-le via Services.msc ou utilisez l’applet de commande PowerShell suivante:

Start-Service SPTimerV4

Une fois que tous les serveurs ont été joints à la batterie de serveurs, vérifiez qu’ils disposent des services appropriés. Cela peut être fait dans l’Administration centrale en allant dans «Gérer les serveurs dans la batterie» selon la figure 3-22.

Figure 3-22. Administration centrale Gérer les serveurs dans la batterie de serveurs, affichant tous les serveurs et rôles

3.9.4 Haute disponibilité de l’administration centrale

Pour rendre l’administration centrale hautement disponible, nous devons la démarrer sur le deuxième serveur d’applications, CALSP04. Pour ce faire, dans l’Administration centrale, accédez à Gérer les services sur le serveur. Sélectionnez le deuxième serveur d’applications dans la liste déroulante Serveur, puis démarrez le service Administration centrale. Une fois le service démarré, modifiez la liaison IIS et sélectionnez le certificat SSL de l’administration centrale de SharePoint installé précédemment, en spécifiant le nom d’hôte de cal.lab.cobaltatom.com et en cochant la case SNI.

Nous pouvons également démarrer l’administration centrale via PowerShell. Nous devons transmettre le nom d’hôte du serveur SharePoint sur lequel nous allons le démarrer pour obtenir une référence à l’instance de service spécifique.

$si = Get-SPServiceInstance -Server CALSP04 | ?{$_.TypeName -eq ‘Central

Administration’}

Start-SPServiceInstance $si

À ce stade, l’administration centrale est prête à être placée derrière un équilibreur de charge. L’enregistrement A du nom de domaine complet de l’administration centrale peut maintenant être dirigé vers l’équilibreur de charge lorsqu’il est configuré.

3.9.5 Fourniture automatique de service

Les services peuvent être automatiquement provisionnés dans la batterie de serveurs, mais chaque service doit être configuré pour le faire. Dans l’Administration centrale, sous Gérer les services dans la batterie, notez que quelques-uns, par défaut, sont définis sur Provisionnement automatique comme le montre la figure 3-23. Cela peut être modifié en cliquant sur le lien Activer la mise à disposition automatique (par exemple, si vous n’avez pas l’intention d’utiliser un service tel que le service de jeton de réclamation Windows). D’autres services sont automatiquement provisionnés lors de la création de l’application de service.

Figure 3-23. Services dans la batterie indiquant quels services sont définis sur Auto Provision

Le service apparaîtra initialement comme Traitement, avant d’afficher le résultat dans le

Colonne Action, telle que « Désactiver la mise à disposition automatique » si le service a été défini sur Mise à disposition automatique. Définissez uniquement la provision automatique pour les services qui seront utilisés dans la batterie de serveurs.

3.9.6 Courriel sortant

Le courrier électronique sortant peut désormais être configuré à l’aide de l’authentification TLS et Windows.

Le courrier électronique sortant peut être configuré à partir de l’Administration centrale sous Paramètres système, Configurer les paramètres du courrier électronique sortant, conformément à la figure 3-24. SharePoint 2019 peut utiliser l’authentification Windows pour se connecter à l’hôte SMTP.

Figure 3-24 Paramètres des e-mails sortants dans l’Administration centrale

Il peut également être défini via SharePoint Management Shell. Avant de configurer le courrier électronique sortant avec l’authentification, vous devez d’abord définir une clé d’identification d’application. Cela peut désormais être effectué avec une seule applet de commande PowerShell dans SharePoint 2019.

Set-SPApplicationCredentialKey -Password (ConvertTo-SecureString ‘AppCredSecret1!’ -AsPlainText -Force)

Remarque Cette applet de commande doit être exécutée sur tous les serveurs SharePoint de la batterie de serveurs. L’applet de commande définit une valeur de Registre qui ne se propage pas aux autres serveurs SharePoint.

Avec la clé d’identification de l’application en place, il est désormais possible de configurer l’authentification pour le courrier SMTP sortant.

$ca = Get-SPWebApplication -IncludeCentralAdministration | ?{$_.

IsAdministrationWebApplication -eq $true}

$senderAddr = “sharepoint@cobaltatom.com”

$replyAddr = “sharepoint@cobaltatom.com”

$smtpServer = “mail.cobaltatom.com”

$enableTls = $true

$authUser = “LAB\s-mailrelay”

$password = Read-Host -AsSecureString

$ca.UpdateMailsettings($smtpServer, $senderAddr, $replyAddr, 65001,

$enableTls, 587, $authUser, $password)

65001 est la page de codes par défaut. La valeur $ true est d’activer TLS et le port spécifié est 587.

Pour valider que les paramètres de messagerie fonctionnent correctement, le courrier peut être envoyé via le modèle d’objet SharePoint dans SharePoint Management Shell. Remplissez simplement les blancs en utilisant l’URL de l’administration centrale comme site spécifié.

$email = “recipient@cobaltatom.com”

$subject = “Email through SharePoint OM”

$body = “Message body.”

$site = Get-SPSite http://centralAdministrationUrl

$web = $site.OpenWeb()

[Microsoft.SharePoint.Utilities.SPUtility]::SendEmail($web,0,0,$email,$subj ect,$body)

Si le résultat renvoie True, le courrier a été envoyé avec succès. Sinon, recherchez dans le journal des connecteurs de réception du serveur de messagerie toute erreur potentielle. En outre, vous pouvez également utiliser l’applet de commande Send-MailMessage.

Send-MailMessage -To “recipient@cobaltatom.com” -From “sharepoint@ cobaltatom.com” -Subject “Testing Smtp Mail” -Body “Message Body”

-SmtpServer “mail.cobaltatom.com” -UseSsl -Port 587 -Credential (Get-

Credential -UserName “LAB\s-mailrelay”)

Cette applet de commande contourne le modèle d’objet SharePoint et peut fournir des informations de diagnostic supplémentaires.

3.9.7 Gestion des droits relatifs à l’ information

Les paramètres de gestion des droits relatifs à l’information se trouvent dans l’Administration centrale sous Sécurité, Configurer la gestion des droits relatifs à l’information. Si un point de connexion de service a été créé dans Active Directory pour Rights Management Services (paramètre par défaut), spécifiez «Utiliser le serveur RMS par défaut spécifié dans Active Directory»; sinon, sélectionnez «Utiliser ce serveur RMS» et entrez le nom de domaine complet du cluster RMS. Si une erreur se produit, vérifiez que le nom de domaine du cluster RMS peut être résolu à partir du serveur SharePoint et que le compte de batterie et tous les comptes du pool d’applications Web sont membres du groupe local du groupe de services AD RMS sur le ou les serveurs RMS.

Les paramètres IRM peuvent également être activés via SharePoint Management Shell.

Pour définir le paramètre «Utiliser le serveur RMS par défaut spécifié dans Active Directory», exécutez ce qui suit:

$webSvc = [Microsoft.SharePoint.Administration.

SPWebService]::ContentService

$webSvc.IrmSettings.IrmRMSEnabled = $true

$webSvc.IrmSettings.IrmRMSUseAD = $true

$webSvc.Update()

Pour spécifier un serveur spécifique, exécutez ce qui suit:

$webSvc = [Microsoft.SharePoint.Administration.

SPWebService]::ContentService

$webSvc.IrmSettings.IrmRMSEnabled = $true

$webSvc.IrmSettings.IrmRMSUseAD = $false

$webSvc.IrmSettings.IrmRMSCertServer = “https://rms.cobaltatom.com”

$webSvc.Update()

Lors de l’utilisation de SharePoint Management Shell, l’affichage des résultats dans l’Administration centrale peut prendre quelques secondes.

3.9.8 Comptes gérés

Les comptes gérés sont les comptes de service qui exécutent les services SharePoint. Le compte de compte de batterie est ajouté par défaut lors de la création de la batterie de serveurs SharePoint. Dans cette batterie de serveurs, nous avons trois comptes gérés supplémentaires qui doivent être enregistrés, s-svc pour exécuter les applications de service, s-web pour exécuter les applications Web et s-c2wts pour le service de jeton de revendications à Windows.

Notez que vous ne devez provisionner un compte pour le service de jetons de réclamation vers Windows que si ce service est requis dans votre batterie de serveurs. C2WTS n’est pas requis dans la plupart des déploiements.

Pour enregistrer des comptes gérés, exécutez ce qui suit:

$cred = Get-Credential -UserName “LAB\s-svc” -Message “Managed Account”

New-SPManagedAccount -Credential $cred

Répétez le processus pour LAB \ s-web et LAB \ s-c2wts.

3.9.9 Pool d’applications de service

Étant donné que nous utiliserons le nombre minimal de pools d’applications possibles dans la batterie de serveurs, nous ne créerons qu’un seul pool d’applications pour toutes les applications de service. Cela se fait via PowerShell et peut également être effectué lors de la création de la première application de service dans la batterie de serveurs. L’utilisation d’un seul pool d’applications réduit les frais généraux car les processus .NET ne peuvent pas partager la mémoire même si les mêmes fichiers binaires ont été chargés dans le processus (par exemple, Microsoft.SharePoint.dll ne peut pas être partagé entre deux processus w3wp.exe).

New-SPServiceApplicationPool -Name “SharePoint Web Services Default”

-Account (Get-SPManagedAccount “LAB\s-svc”)

Lors de la création d’applications de service, nous allons maintenant sélectionner le pool d’applications «SharePoint Web Services par défaut».

3.9.10 Enregistrement des diagnostics

Dès la sortie de la boîte, SharePoint se connecte au service de journalisation unifiée (journalisation de diagnostic) dans «C: \ Program Files \ Fichiers communs \ microsoft shared \ Web Server Extensions \ 16 \ LOGS \». La journalisation sur le lecteur C: peut ne pas être idéale, non seulement pour des raisons d’espace, mais également pour des performances en raison du fait qu’elle se trouve sur le même volume que toutes les autres ressources Web SharePoint auxquelles les utilisateurs accèdent. L’emplacement ULS peut être déplacé via l’Administration centrale sous Surveillance, Configurer la journalisation des diagnostics. Définissez le chemin d’accès à un emplacement spécifique, tel que «E: \ ULS». Notez que ce chemin doit être sur tous les serveurs SharePoint de la batterie de serveurs. En outre, vous pouvez spécifier le nombre maximal de jours pour conserver les fichiers journaux ainsi que l’espace maximal que les fichiers journaux d’espace disque peuvent consommer. Il est conseillé de définir l’espace de stockage maximal que les fichiers journaux peuvent utiliser en dessous de la taille de volume sur laquelle ils résident.

À partir de SharePoint Management Shell, cela peut être défini en exécutant ce qui suit à l’aide de tout ou partie des paramètres.

Remarque : pour limiter l’espace disque maximal que les fichiers journaux peuvent utiliser, vous devez spécifier les paramètres -LogDiskSpaceUsageGB et -LogMaxDiskSpaceUsageEnabled: $ true.

Set-SPDiagnosticConfig -DaysToKeepLogs 7 -LogDiskSpaceUsageGB 150 -LogMaxDi skSpaceUsageEnabled:$true -LogLocation E:\ULS

Si vous déplacez les journaux ULS vers un autre emplacement, il est également recommandé de déplacer également les journaux d’utilisation. Dans l’Administration centrale, sous Surveillance, Configurer la collecte des données d’utilisation et d’intégrité, spécifiez le chemin du journal vers le même répertoire racine que les journaux ULS, par exemple, E: \ ULS.

La définition via SharePoint Management Shell s’effectue via les éléments suivants:

Set-SPUsageService -UsageLogLocation E:\ULS

3.9.11 Revendications au service de jeton Windows

Comme indiqué précédemment, le service de revendications de jetons Windows n’est souvent pas requis dans la plupart des déploiements SharePoint. Réfléchissez bien si vous aurez besoin de cette fonctionnalité ou si vous l’utiliserez.

Le service de revendications de jetons Windows doit toujours s’exécuter sous un compte dédié. Ce compte est le seul compte qui nécessite des droits d’administrateur local sur les serveurs SharePoint sur lesquels il s’exécute. Pour une configuration MinRole, le service de jetons de réclamation vers Windows s’exécute sur tous les MinRoles. Ne configurez pas les revendications au service de jeton Windows, sauf si cela est nécessaire. De nombreuses fermes n’ont pas besoin de ce service.

Ajoutez manuellement les revendications au service de jeton Windows au groupe Administrateurs locaux sur chaque serveur SharePoint. En outre, à l’aide de la stratégie de sécurité locale MMC (secpol.msc), ajoutez les revendications au service de jeton Windows aux attributions de droits utilisateur suivantes, sous Stratégies locales.

  • Agir en tant que partie du système d’exploitation
  • Emprunter l’identité d’un client après l’authentification
  • Connectez-vous en tant que service

Les revendications au service de jeton Windows doivent se connecter aux sources de données avec la délégation Kerberos contrainte avec la transition de protocole activée. Pour que l’onglet Délégation apparaisse dans les utilisateurs et ordinateurs Active Directory pour le compte de service de jeton de revendications à Windows, créez un SPN « factice » à l’aide de setspn.exe.

Setspn.exe -U -S C2WTS/Dummy LAB\s-c2wts

Pour définir le compte Service de jetons Windows sur les revendications, utilisez SharePoint Management Shell.

$account = Get-SPManagedAccount “LAB\s-c2wts”

$farm = Get-SPFarm

$svc = $farm.Services | ?{$_.TypeName -eq “Claims to Windows Token Service”}

$svcIdentity = $svc.ProcessIdentity $svcIdentity.CurrentIdentityType = [Microsoft.SharePoint.Administration.

IdentityType]::SpecificUser

$svcIdentity.UserName = $account.Username

$svcIdentity.Update()

$svcIdentity.Deploy()

Une fois terminé, le service de réclamation de jeton s’exécutera sous la nouvelle identité sur tous les serveurs SharePoint de la batterie de serveurs exécutant le service de jeton de réclamation vers Windows.

3.9.12 Service de cache distribué

Le service de cache distribué nécessite deux modifications. La première modification consiste à remplacer le compte d’administrateur de batterie de serveurs exécutant le service de mise en cache AppFabric par le compte de services. La deuxième tâche consiste à ajuster la quantité de mémoire allouée à la mise en cache distribuée.

Conseil Il n’est plus nécessaire de définir l’élément backgroundgc = true dans DistributedCacheService.exe.config car il s’agit désormais du paramètre par défaut.

Pour exécuter le service de cache distribué en tant que compte de pool d’applications de service ou LAB \ s-svc, exécutez les commandes suivantes. Le cache distribué s’exécutera autrement en tant que compte de compte de ferme (LAB \ s-farm). Nous exécuterons cette modification sur CALSP01.

$acct = Get-SPManagedAccount “LAB\s-svc”

$farm = Get-SPFarm

$svc = $farm.Services | ?{$_.TypeName -eq “Distributed Cache”}

$svc.ProcessIdentity.CurrentIdentityType = “SpecificUser”

$svc.ProcessIdentity.ManagedAccount = $acct

$svc.ProcessIdentity.Update()

$svc.ProcessIdentity.Deploy()

Si vous avez ajouté le serveur en tant qu’hôte de cache distribué, vous devez d’abord arrêter le service de cache distribué, supprimer l’instance de cache distribué et enfin ajouter l’instance de cache distribué. Cela mettra à jour le compte vers LAB \ s-svc.

Stop-SPDistributedCacheServiceInstance

Remove-SPDistributedCacheServiceInstance

Add-SPDistributedCacheServiceInstance

Si plusieurs serveurs de la batterie de serveurs exécutent déjà le cache distribué, utilisez Stop-SPD istributedCacheServiceInstance avant de mettre à jour la valeur de la mémoire. La valeur peut être mise à jour via PowerShell.

Update-SPDistributedCacheSize -CacheSizeInMB 3096

Sur un seul hôte de cache distribué, exécutez cette applet de commande avec une valeur maximale de 16384 pour un serveur avec 34 Go ou plus de RAM. Dans de nombreux cas, l’allocation par défaut est suffisante. Microsoft recommande une valeur de 1 Go pour les fermes de moins de 10 000 utilisateurs; 2,5 Go pour les fermes comptant plus de 10 000 utilisateurs et moins de 10 000 utilisateurs; et enfin, pour les batteries de plus de 10 000 utilisateurs, 16 Go par allocation de serveur (cela nécessite 34 Go de RAM pour le cache distribué et 2 Go de surcharge).

Ajoutez le cache distribué sur tous les serveurs restants de la batterie de serveurs hébergeant le rôle WebFrontEndWithDistributeCache ou le rôle DistributedCache. Cela peut être accompli via PowerShell.

Add-SPDistributedCacheServiceInstance

$si = Get-SPServiceInstance -Server CALSP01 | ?{$_.TypeName -eq

‘Distributed Cache’}

Start-SPServiceInstance $si

Conseil Si vous utilisez le pare-feu Windows, vérifiez que les règles «AppFabric Caching Service (TCP-In)» et «Remote Service Management (NP-In)» sont activées. En outre, vérifiez que le service Registre distant dans services.msc est en cours d’exécution.

Cela terminera les modifications de base requises pour le service de cache distribué. Le service de cache distribué sera traité plus en détail au chapitre 19 en ce qui concerne les redémarrages de service.

Une fois les services de base configurés, nous sommes prêts à passer à la configuration et à la configuration de base de l’application de service.

3.10 Applications de service

La création d’une application de service se fera principalement via la gestion SharePoint

Shell, mais à quelques exceptions près, les applications de service peuvent également être créées via l’administration centrale. Toutes les applications de service ne doivent pas être provisionnées sur chaque batterie de serveurs. La meilleure stratégie consiste à déterminer, via les besoins de l’entreprise, de ne fournir que les applications de service selon leurs besoins. Les applications de service ajoutent ou activent généralement des tâches de minuteur, ce qui augmente la charge dans la batterie de serveurs.

Dans cette section, nous approvisionnerons les applications de service suivantes. Certaines applications de service seront traitées en détail dans les chapitres suivants.

  • Service d’État
  • Application de service de collecte de données d’utilisation et de santé
  • Service de gestion des applications
  • Service de magasin sécurisé
  • Service de connectivité des données d’entreprise
  • Service de métadonnées gérées
  • Service de recherche d’entreprise SharePoint
  • Service de profil utilisateur

Lorsque les applications de service sont provisionnées, celles qui nécessitent des bases de données doivent avoir ces bases de données ajoutées au groupe de disponibilité AlwaysOn. Les étapes sont les mêmes que celles mentionnées précédemment dans ce chapitre et ne seront pas traitées ici.

3.10.1 Service d’État

Le service d’état est utilisé pour la gestion de l’état de session pour remplir le service InfoPath Forms. Si InfoPath Forms Services n’est pas requis, cette application de service n’est pas requise. Cette application de service ne peut être configurée que via PowerShell.

$db = New-SPStateServiceDatabase -Name “StateService”

$sa = New-SPStateServiceApplication -Name “State Service” -Database $db

New-SPStateServiceApplicationProxy -Name “State Service” -ServiceApplication $sa -DefaultProxyGroup

3.10.2 Application de service de collecte de données d’utilisation et de santé

L’application de service de collecte de données d’utilisation et d’intégrité fournit une collecte de données qui peut être utilisée pour l’analyse de la santé et des performances de la batterie de serveurs via la base de données d’utilisation. Notez qu’il s’agit d’une base de données qui ne doit pas faire partie du groupe de disponibilité. Les données sont transitoires. Si la base de données devient indisponible en raison d’une défaillance de SQL Server où réside la base de données, il n’y a aucun impact sur l’utilisateur final. Les autres applications de service et les sites SharePoint continueront de fonctionner correctement. Si un groupe de disponibilité est requis, un nouveau groupe de disponibilité s’exécutant en mode asynchrone doit être utilisé car la base de données d’utilisation peut submerger le groupe de disponibilité avec le grand nombre d’écritures dans cette base de données. Si cette base de données est membre d’un groupe de disponibilité, elle empêchera l’assistant de configuration de s’exécuter et la base de données doit être supprimée du groupe de disponibilité jusqu’à ce que l’assistant de configuration se soit terminé avec succès sur tous les serveurs SharePoint de la batterie de serveurs.

La base de données d’utilisation sera créée automatiquement lors de la création de l’application de service de recherche; cependant, le nom de la base de données sera défini sur «WSS_ UsageApplication_ <GUID>», ce qui peut ne pas être souhaité.

Cette base de données sera créée en ciblant le réplica principal.

New-SPUsageApplication -Name “Usage and Health Data Collection Service Application” -DatabaseServer CALSQL01 -DatabaseName Usage

3.10.3 Service de gestion des applications

Le service de gestion des applications est requis pour les compléments SharePoint et les scénarios hybrides. Il s’agit de la première application de service où nous allons spécifier le nouveau pool d’applications IIS d’application de service.

$ sa = New-SPAppManagementServiceApplication -Name “App Management Service Application” -DatabaseName “AppManagement” -ApplicationPool “SharePoint Web

Services par défaut ”

Service de gestion d’applications New-SPAppManagementServiceApplicationProxy -Name ”

Application “-ServiceApplication $ sa -UseDefaultProxyGroup

3.10.4 Service de banque sécurisée

Le service Banque d’informations sécurisé fournit la délégation d’informations d’identification et l’accès à d’autres services à l’intérieur et à l’extérieur de SharePoint. La valeur -AuditlogMaxSize est exprimée en jours.

$sa = New-SPSecureStoreServiceApplication -Name “Secure Store Service Application” -ApplicationPool “SharePoint Web Services Default” -AuditingEnabled:$true -AuditlogMaxSize 7 -DatabaseName “SecureStore” New-SPSecureStoreServiceApplicationProxy -Name “Secure Store Service Application” -ServiceApplication $sa

Une fois le proxy créé, définissez la clé principale et conservez-la dans un endroit sûr à des fins de récupération après sinistre. La clé principale peut être définie via l’Administration centrale, gérer les applications de service. Gérez l’application de service Banque d’informations sécurisé et cliquez sur Générer une nouvelle clé.

3.10.5 Service de connectivité des données d’entreprise

Le service Business Data Connectivity fournit une connectivité aux sources de données externes, telles que les bases de données SQL, pour les exposer en tant que listes externes.

New-SPBusinessDataCatalogServiceApplication -Name “Business Data

Connectivity Service Application” -DatabaseName “BCS” -ApplicationPool

“SharePoint Web Services Default”

Remarque Le proxy du service Business Data Connectivity est créé pour vous lors de la création de l’application de service, mais vous pouvez modifier le nom du proxy après le déploiement.

3.10.6 Service de métadonnées gérées

Le service de métadonnées gérées fournit des taxonomies pour la consommation des utilisateurs finaux et des services SharePoint, tels que la recherche, le service de profil utilisateur, etc. Le service de métadonnées gérées doit être créé avant le profil utilisateur ou le service de recherche.

$sa = New-SPMetadataServiceApplication -Name “Managed Metadata Service”

-DatabaseName “MMS” -ApplicationPool “SharePoint Web Services Default”

-SyndicationErrorReportEnabled

New-SPMetadataServiceApplicationProxy -Name “Managed Metadata Service”

-ServiceApplication $sa -DefaultProxyGroup -ContentTypePushdownEnabled

-DefaultKeywordTaxonomy -DefaultSiteCollectionTaxonomy

Un paramètre facultatif pour New-SPMetadataServiceApplication est -HubUri, qui est une collection de sites pour le concentrateur de type de contenu. Si une collection de sites a été créée précédemment, cette option peut être spécifiée. Lorsque cette option est spécifiée, un paramètre supplémentaire sur New-SPMetadataServiceApplicationProxy est disponible, -ContentTypeSyndicationEnabled. La configuration de HubUri sera traitée plus loin dans ce chapitre.

3.10.7 Service de recherche d’entreprise SharePoint

La configuration de la recherche d’entreprise est un script complexe et est souvent plus facile à réaliser via l’administration centrale. Cependant, lorsqu’elles sont créées via l’Administration centrale, les bases de données du serveur de recherche sont associées à des GUID et la topologie de recherche ne correspondra probablement pas à vos besoins. Comme l’ajustement de la topologie de recherche nécessite PowerShell, il est avantageux de créer l’application de service de recherche via PowerShell pour commencer.

Ce PowerShell doit être exécuté à partir d’un serveur SharePoint exécutant le MinRole Search ou ApplicationWithSearch. Dans ce cas, la topologie sera créée sur CALSP03.

Get-SPEnterpriseSearchServiceInstance -Local | Start- SPEnterpriseSearch ServiceInstance Get-SPEnterpriseSearchQueryAndSiteSettingsServiceInstance -Local | Start- SPEnterpriseSearchQueryAndSiteSettingsServiceInstance

$sa = New-SPEnterpriseSearchServiceApplication -Name “Search Service Application” -DatabaseName “Search” -ApplicationPool “SharePoint Web Services Default” -AdminApplicationPool “SharePoint Web Services Default”

New-SPEnterpriseSearchServiceApplicationProxy -Name “Search Service Application” -SearchApplication $sa

$si = Get-SPEnterpriseSearchServiceInstance -Local

$clone = New-SPEnterpriseSearchTopology -SearchApplication $sa

Créez la topologie initiale.

New-SPEnterpriseSearchAdminComponent -SearchTopology $clone

-SearchServiceInstance $si

New-SPEnterpriseSearchContentProcessingComponent -SearchTopology $clone

-SearchServiceInstance $si

New-SPEnterpriseSearchAnalyticsProcessingComponent -SearchTopology $clone

-SearchServiceInstance $si

New-SPEnterpriseSearchCrawlComponent -SearchTopology $clone

-SearchServiceInstance $si

New-SPEnterpriseSearchIndexComponent -SearchTopology $clone

-SearchServiceInstance $si -IndexPartition 0 -RootDirectory F:\

SearchIndex\0

New-SPEnterpriseSearchQueryProcessingComponent -SearchTopology $clone

-SearchServiceInstance $si

Créez la topologie pour le deuxième serveur de recherche, CALSP04.

Get-SPEnterpriseSearchServiceInstance | ?{$_.Server -match “CALSP04”} |

Start-SPEnterpriseSearchServiceInstance

Get-SPEnterpriseSearchQueryAndSiteSettingsServiceInstance | ?{$_.Server -match

“CALSP04”} | Start- SPEnterpriseSearchQueryAndSiteSettingsServiceInstance

$si2 = Get-SPEnterpriseSearchServiceInstance | ?{$_.Server -match “CALSP04”}

New-SPEnterpriseSearchAdminComponent -SearchTopology $clone

-SearchServiceInstance $si2

New-SPEnterpriseSearchAnalyticsProcessingComponent -SearchTopology $clone

-SearchServiceInstance $si2

New-SPEnterpriseSearchContentProcessingComponent -SearchTopology $clone

-SearchServiceInstance $si2

New-SPEnterpriseSearchCrawlComponent -SearchTopology $clone

-SearchServiceInstance $si2

New-SPEnterpriseSearchIndexComponent -SearchTopology $clone

-SearchServiceInstance $si2 -IndexPartition 0 -RootDirectory F:\

SearchIndex\0

New-SPEnterpriseSearchQueryProcessingComponent -SearchTopology $clone

-SearchServiceInstance $si2

Set-SPEnterpriseSearchTopology -Identity $clone

Supprimez les topologies inactives.

$sa = Get-SPEnterpriseSearchServiceApplication

foreach($topo in (Get-SPEnterpriseSearchTopology -SearchApplication $sa | ?{$_.State -eq “Inactive”})){Remove-SPEnterpriseSearchTopology -Identity

$topo -Confirm:$false}

Définissez le compte d’exploration pour l’application de service de recherche.

$sa = Get-SPEnterpriseSearchServiceApplication $content = New-Object Microsoft.Office.Server.Search.Administration.

Content($sa)

$content.SetDefaultGatheringAccount(“LAB\s-crawl”, (ConvertTo-SecureString

“<Password>” -AsPlainText -Force))

Configurez la même source de contenu pour utiliser les analyses continues. Bien que les analyses continues puissent augmenter l’utilisation du processeur, de la mémoire et / ou du disque, vous n’aurez pas à vous soucier de synchroniser correctement les analyses incrémentielles.

$source = Get-SPEnterpriseSearchCrawlContentSource -SearchApplication $sa

-Identity “Local SharePoint sites”

$source.EnableContinuousCrawls = $true

$source.Update()

La dernière étape consiste à modifier le compte de service exécutant les services de recherche. Cela peut être fait via l’Administration centrale sous Sécurité. Cliquez sur Configurer les comptes de service.

Remplacez le compte de service par LAB \ s-svc pour les services «Service Windows – Service de contrôleur d’hôte de recherche» et «Service Windows – Recherche SharePoint Server».

3.10.8 Service de profil utilisateur

Le service de profil utilisateur synchronise les objets utilisateur et groupe d’Active Directory dans le service de profil SharePoint. Ce service est également responsable de la gestion des audiences et de la configuration de MySites (OneDrive). La création de l’application de service peut être effectuée via PowerShell.

$sa = New-SPProfileServiceApplication -Name “User Profile Service Application” -ApplicationPool “SharePoint Web Services Default”

-ProfileDBName “Profile” -SocialDBName “Social” -ProfileSyncDBName “Sync”

New-SPProfileServiceApplicationProxy -Name “User Profile Service

Application” -ServiceApplication $sa -DefaultProxyGroup

Une chose que vous remarquerez est que nous spécifions un nom pour la base de données de synchronisation même si la base de données n’est pas utilisée car le service de synchronisation de profil utilisateur ne fait plus partie de SharePoint. Cela est dû au fait que SharePoint le créera malgré tout, bien que la base de données soit vide sans tables.

Ajoutez le compte d’accès au contenu par défaut, LAB \ s-crawl, aux autorisations d’administrateur de la nouvelle application de service de profil utilisateur afin d’énumérer les données de personnes pour la recherche.

$user = New-SPClaimsPrincipal “LAB\s-crawl” -IdentityType

WindowsSamAccountName

$security = Get-SPServiceApplicationSecurity $sa -Admin

Grant-SPObjectSecurity $security $user “Retrieve People Data for Search Crawlers”

Set-SPServiceApplicationSecurity $sa $security -Admin

Vous pouvez également envisager d’ajouter des comptes supplémentaires, tels que SharePoint

Les administrateurs, qui devront gérer l’application de service de profil utilisateur à partir de

PowerShell. Dans cet exemple, nous accordons à un utilisateur des droits de contrôle total sur l’application de service de profil utilisateur. Le commutateur «-Admin» indique le bouton «Administrateurs» dans le ruban, tandis que l’absence du commutateur «-Admin» indique le bouton «Permissions» dans le ruban.

$user = New-SPClaimsPrincipal “LAB\userName” -IdentityType

WindowsSamAccountName

$security = Get-SPServiceApplicationSecurity $sa -Admin

Grant-SPObjectSecurity $security $user “Full Control”

Set-SPServiceApplicationSecurity $sa $security -Admin

$security = Get-SPServiceApplicationSecurity $sa

Grant-SPObjectSecurity $security $user “Full Control”

Set-SPServiceApplicationSecurity $sa $security

Mettez à jour la source de contenu du service de serveur de recherche pour utiliser le protocole SPS3S: // (les gens explorent sur SSL, si vous utilisez HTTP, utilisez le protocole SPS3: //).

$sa = Get-SPEnterpriseSearchServiceApplication

$source = Get-SPEnterpriseSearchCrawlContentSource -SearchApplication $sa

-Identity “Local SharePoint sites”

$source.StartAddresses.Add(“sps3s://sp-my.cobaltatom.com”)

$source.Update()

3.10.9 Fin de la configuration de l’application de service

Lorsque toutes les applications de service sont créées, n’oubliez pas d’ajouter les bases de données d’application de service, à l’exception de la base de données d’utilisation, au groupe de disponibilité.

En outre, ajoutez manuellement les comptes gérés SharePoint, LAB \ s-farm, LAB \ s-svc, LAB \ s-c2wts et LAB \ s-web aux connexions SQL sur le réplica secondaire ou scriptez les connexions à l’aide de sp_help_revlogin stocké procédure. Les connexions ne sont pas répliquées automatiquement; cependant, lors d’un basculement de base de données, les connexions SQL auront les droits appropriés sur les bases de données.

Conseil Des informations sur la façon de créer un script pour les connexions pour le transfert vers la réplique secondaire sont disponibles sur le site Microsoft KB918992: https://support.microsoft.com/en us / help / 918992 . Une autre applet de commande PowerShell utile est Copy-DbaLogin du module PowerShell disponible sur https://dbatools.io/ .

3.10.10 Configuration de l’application Web

La configuration de l’application Web est simple avec PowerShell. Nous allons parcourir la création de deux applications Web, https://sp.cobaltatom.com , qui contiendra les sites d’équipe, les portails, etc., et https://sp-my.cobaltatom.com , qui contiendra l’hôte MySite et MySites de l’utilisateur, également connu sous le nom de sites OneDrive Entreprise.

Avec la première application Web, nous allons créer le pool d’applications IIS nommé «SharePoint» que les deux applications Web exploiteront. Les deux applications Web seront également configurées pour utiliser Kerberos. Cela nécessite l’enregistrement de deux SPN:

Setspn -U -S HTTP/sp.cobaltatom.com LAB\s-web

Setspn -U -S HTTP/sp-my.cobaltatom.com LAB\s-web

Créez le fournisseur d’authentification, en activant Kerberos, puis créez le Web

Application.

$ap = New-SPAuthenticationProvider -DisableKerberos:$false

New-SPWebApplication -Name “SharePoint” -HostHeader sp.cobaltatom. com -Port 443 -ApplicationPool “SharePoint” -ApplicationPoolAccount

(Get-SPManagedAccount “LAB\s-web”) -SecureSocketsLayer:$true

-AuthenticationProvider $ap -DatabaseName SharePoint_CDB1

Cela prendra quelques minutes ; ensuite, nous pouvons créer l’application Web MySite.

New-SPWebApplication -Name “SharePoint MySites” -HostHeader sp- my.cobaltatom.com -Port 443 -ApplicationPool “SharePoint” -SecureSocketsLayer:$true -AuthenticationProvider $ap -DatabaseName SharePoint-My_CDB1

Validez que les liaisons IIS sont correctes sur tous les serveurs et que le certificat SSL a été correctement sélectionné. SharePoint ne peut pas définir le certificat SSL pour vous.

Cette opération doit être effectuée sur tous les serveurs exécutant l’application Web Microsoft SharePoint Foundation. Pour MinRole, cela inclut les rôles DistributedCache, WebFrontEnd, Application, ApplicationWithSearch et WebFrontEndWithDistributedCache.

Pour prendre en charge la publication de sites, ajoutez le Portal Super User et Portal Super Reader à l’application Web SharePoint. Ces comptes sont utilisés uniquement à des fins de comparaison des autorisations et le mot de passe de ces comptes n’est pas requis. S’il est possible qu’un site de publication soit créé sur l’application Web SharePoint MySite, ajoutez-y également les comptes. Nous devons définir les propriétés initiales sur l’application Web SharePoint via SharePoint Management Shell.

$wa = Get-SPWebApplication https://sp.cobaltatom.com

$wa.Properties[“portalsuperuseraccount”] = “i:0#.w|LAB\s-su”

$wa.Properties[“portalsuperreaderaccount”] = “i:0#.w|LAB\s-sr”

$wa.Update()

L’ajout des utilisateurs à la stratégie d’application Web peut se faire via Gérer les applications Web sous Administration centrale ou via SharePoint Management Shell.

$wa = Get-SPWebApplication https://sp.cobaltatom.com

$zp = $wa.ZonePolicies(“Default”)

$policy = $zp.Add(“i:0#.w|LAB\s-su”, “Portal Super User”)

$policyRole = $wa.PolicyRoles.GetSpecialRole(“FullControl”)

$policy.PolicyRoleBindings.Add($policyRole)

$policy = $zp.Add(“i:0#.w|LAB\s-sr”, “Portal Super Reader”)

$policyRole = $wa.PolicyRoles.GetSpecialRole(“FullRead”)

$policy.PolicyRoleBindings.Add($policyRole)

$wa.Update()

Le compte de compte de ferme figurera dans la stratégie de chaque application Web, car il était précédemment défini comme compte d’accès au contenu par défaut dans le service de recherche. Cela peut être supprimé.

Lorsque la stratégie de zone a été modifiée, il faudra un IISReset pour prendre effet. Pour ce faire, à partir de SharePoint Management Shell, exécutez ce qui suit:

foreach($server in (Get-SPServer | ?{$_.Role -ne “Invalid” -and $_.Role -ne

“Search”}))

{

Write-Host “Resetting IIS on $($server.Address)…” iisreset $server.Address /noforce

}

Ajoutez le chemin géré requis, «personnel» à l’application Web SharePoint MySite et supprimez le chemin géré «sites» par défaut.

New-SPManagedPath -RelativeUrl “personal” -WebApplication https://sp-my.cobaltatom.com

Remove-SPManagedPath -Identity “sites” -WebApplication https://sp-my. cobaltatom.com

Ensuite, activez la création de sites libre-service.

$wa = Get-SPWebApplication https://sp-my.cobaltatom.com

$wa.SelfServiceSiteCreationEnabled = $true

$wa.Update()

Ces deux étapes sont nécessaires pour activer la création de MySite par les utilisateurs. Voir Création d’un site libre-service moderne plus loin dans ce chapitre pour des options supplémentaires.

3.10.11 Collections de sites racine

Les applications Web doivent posséder une collection de sites racine. Il s’agit de la collection de sites qui réside sur le chemin «/». Pour l’application Web SharePoint, nous déploierons un modèle de site de communication moderne et pour l’application Web SharePoint MySite, nous déploierons le modèle d’hôte MySite.

New-SPSite -Url https://sp.cobaltatom.com -Template SITEPAGEPUBLISHING#0

-Name “Communications Site” -OwnerAlias “LAB\trevor.seward”

New-SPSite -Url https://sp-my.cobaltatom.com -Template SPSMSITEHOST#0 -Name

“OneDrive for Business” -OwnerAlias “LAB\trevor.seward”

3.10.12 Configuration du concentrateur de type de contenu et du centre de recherche d’entreprise

En plus de ces collections de sites, nous allons également créer un hub de type de contenu et un centre de recherche d’entreprise. Le concentrateur de type de contenu sera créé puis configuré dans le service de métadonnées gérées, et le centre de recherche d’entreprise sera créé et défini comme URL du centre de recherche.

Le concentrateur de type de contenu peut être un modèle de site d’équipe classique standard.

New-SPSite -Url https://sp.cobaltatom.com/sites/contentTypeHub -Template STS#0 -Name “Content Type Hub” -OwnerAlias “LAB\trevor.seward”

Définissez l’URL du concentrateur de type de contenu du service de métadonnées gérées.

Set-SPMetadataServiceApplication -Identity “Managed Metadata Service”

-HubUri https://sp.cobaltatom.com/sites/contentTypeHub

Ensuite, créez l’Enterprise Search Center à l’aide du modèle SRCHCEN # 0.

New-SPSite -Url https://sp.cobaltatom.com/sites/search -Template SRCHCEN#0

-Name “Enterprise Search Center” -OwnerAlias “LAB\trevor.seward”

Enfin, définissez le Centre de recherche d’entreprise dans le service de recherche SharePoint.

$sa = Get-SPEnterpriseSearchServiceApplication

$sa.SearchCenterUrl = “https://sp.cobaltatom.com/sites/search/Pages”

$sa.Update()

Des informations supplémentaires sur l’application de service de recherche figurent au chapitre 6 .

3.10.13 Configuration de MySite

Pour configurer MySites pour le service de profil utilisateur, la seule option que nous devons définir est l’hôte MySite. Tous les autres paramètres sont facultatifs, mais peuvent être trouvés dans l’Administration centrale sous Gérer les applications de service dans l’application de service de profil utilisateur. Dans le lien Configuration de MySites, vous trouverez une variété d’options pour contrôler la configuration de MySite.

$sa = Get-SPServiceApplication | ?{$_.TypeName -eq “User Profile Service Application”}

Set-SPProfileServiceApplication -Identity $sa -MySiteHostLocation https:// sp-my.cobaltatom.com

3.10.14 Création d’un site libre-service moderne

SharePoint Server 2019 introduit une nouvelle fonctionnalité pour permettre aux utilisateurs de provisionner des sites d’équipe et de communication modernes à partir de l’hôte MySite.

Activez la création de sites libre-service sur l’application Web principale, https: // sp.cobaltatom.com .

$wa = Get-SPWebApplication https://sp.cobaltatom.com

$wa.SelfServiceSiteCreationEnabled = $true

$wa.Update()

En outre, vous devez fournir aux utilisateurs au moins un accès en lecture à la collection de sites racine sur https://sp.cobaltatom.com . Par exemple, vous pouvez ajouter le groupe Tout le monde au groupe de visiteurs de la collection de sites racine.

L’étape suivante consiste à configurer la création de sites libre-service sur l’application Web hôte MySite.

$wa = Get-SPWebApplication https://sp-my.cobaltatom.com

$wa.ShowStartASiteMenuItem = $true

$wa.SelfServiceCreationAlternateUrl = “https://sp.cobaltatom.com”

$wa.Update()

Cela permettra aux utilisateurs de créer une équipe moderne et des sites de communication sur l’application Web principale à partir de l’application Web hôte MySite.

3.10.15 Importation de profil utilisateur

L’importation d’utilisateur de profil utilisateur prend en charge le mode «Importation Active Directory» de SharePoint.

Bien que cette méthode d’importation soit très rapide, elle ne prend pas en charge l’exportation de propriétés depuis

SharePoint vers d’autres systèmes ou importation d’images depuis Active Directory. L’application de service de profil utilisateur prend également en charge la «synchronisation externe», cette méthode nécessite Microsoft Identity Manager 2016.

Pour plus d’informations sur l’importation des utilisateurs du profil utilisateur et la configuration de Microsoft Identity Manager 2016, consultez le chapitre 7 .

Une fois toutes les applications de service de base provisionnées, nous examinerons brièvement les modèles de machines virtuelles, qui permettront un déploiement plus rapide de SharePoint Server 2019.

3.11 Modèles de machines virtuelles

De nombreuses étapes initiales de l’installation de SharePoint Server peuvent être basées sur des technologies de virtualisation. Lors de la planification de l’utilisation de modèles, un modèle de machine virtuelle pour SharePoint Server peut avoir les prérequis SharePoint installés, ainsi que les binaires SharePoint (setup.exe) et toutes les mises à jour publiques requises. Vous ne pouvez pas exécuter l’Assistant Configuration SharePoint, psconfig.exe ou PowerShell (New-SPConfigurationDatabase ou Connect-SPConfigurationDatabase) avant de créer un modèle sur la machine virtuelle. Les processus de création de modèles, tels que Sysprep, doivent être exécutés sur la machine virtuelle avant de créer le modèle.

3.12 Prochaines étapes

Dans ce chapitre, nous avons suivi un processus avancé étape par étape pour installer SQL Server 2017 sur SharePoint Server 2019 dans une configuration hautement disponible. Cela devrait vous fournir les outils nécessaires pour développer vos propres scripts et processus afin de provisionner une batterie de serveurs hautement disponible.

Ensuite, nous discuterons de l’authentification et de la sécurité, couvrant l’authentification NTLM, Kerberos et SAML. De plus, nous couvrirons la sécurité du transport et les règles d’accès au pare-feu et le proxy d’application Azure AD.

4 CHAPITRE 4 Configuration de l’authentification et de la sécurité

Dans ce chapitre, nous couvrirons les différents mécanismes d’authentification, d’autorisation et de sécurité pour votre batterie de serveurs SharePoint. NTLM, Kerberos et SAML seront couverts, ainsi que leurs avantages et inconvénients dans l’ensemble de la batterie de serveurs. Nous verrons également la sécurité du transport via TLS (SSL) et IPsec. Enfin, nous allons jeter un œil au pare-feu Windows et quelles sont les meilleures pratiques pour l’environnement SharePoint.

4.1 Méthodes d’authentification

SharePoint Server prend en charge diverses méthodes d’authentification. Nous couvrirons chaque méthode d’authentification et leurs avantages et inconvénients. L’authentification, également appelée AuthN, est effectuée par IIS ou les services; SharePoint lui-même n’effectue pas AuthN.

4.1.1 Basique

L’authentification de base est l’endroit où le nom d’utilisateur et le mot de passe de l’utilisateur sont envoyés en texte clair au serveur SharePoint. IIS effectue l’authentification auprès d’Active Directory en fonction du nom d’utilisateur et du mot de passe fournis. Cette forme d’authentification est l’une des moins utilisées et n’est généralement pas nécessaire avec les autres options dont nous disposons. Il est également déconseillé d’utiliser l’authentification de base sans utiliser SSL pour chiffrer le transport des informations d’identification.

4.1.2 NTLM

L’authentification via NTLM est l’une des formes d’authentification les plus courantes utilisées dans les environnements SharePoint. Il ne nécessite aucune configuration supplémentaire de la part des administrateurs SharePoint ou des administrateurs de domaine. «Cela fonctionne tout simplement», cependant, n’est pas la forme d’authentification la plus sûre ou la plus performante à notre disposition. Comme le Web, y compris SharePoint, est sans état, l’authentification doit être effectuée pour chaque demande. Cette méthode d’authentification doit effectuer plusieurs trajets entre l’utilisateur, SharePoint (IIS) et Active Directory, ce qui augmente le temps d’authentification. Ce flux est illustré à la figure 4-1 .

Figure 4-1. Flux de défi et de réponse NTLM

NTLMv1 et NTLMv2 sont considérés comme des protocoles d’authentification non sécurisés. NTLMv1 peut prendre quelques minutes à quelques heures pour casser un hachage NTLM, tandis que NTLMv2 peut prendre jusqu’à 4 à 5 fois plus longtemps. Pour les mots de passe NTLMv2 très complexes, il existe des tables arc-en-ciel qui sont des fichiers qui sont des fonctions de hachage cryptographiques précalculées, réduisant le temps nécessaire pour inverser un mot de passe haché NTLM dans sa variante en texte brut. Microsoft inclut désormais des stratégies de groupe pour désactiver NTLM sur les ordinateurs membres d’Active Directory.

4.1.3 Kerberos

Kerberos est un protocole d’authentification moderne utilisé dans chaque implémentation Active Directory. Au lieu de transmettre des hachages de mot de passe vers et depuis les services, Kerberos transmet ce que l’on appelle des tickets. Certains tickets sont créés lors de la connexion de l’utilisateur à la machine cliente et sont récupérés à partir du centre de distribution Kerberos (KDC), qui est un contrôleur de domaine Active Directory. Comme le montre la figure 4-2 , ces tickets sont les étapes un et deux. Lorsqu’un utilisateur fait une demande à un service externe, tel que SharePoint, les étapes trois et quatre sont exécutées pour récupérer un ticket TGS (Ticket Granting Service). L’utilisateur envoie ensuite le TGS au service cible. Ce service voit que le ticket est valide et, dans un scénario d’authentification mutuelle, le service renvoie des informations au client confirmant l’identité du service. Chaque ticket a une durée de vie spécifique, mais celles-ci sont généralement suffisamment longues pour que les utilisateurs n’aient pas à se réauthentifier auprès du KDC pour récupérer un nouveau ticket. Dans un scénario avec des clients joints à un domaine Active Directory, cette réauthentification ou la récupération d’un nouveau ticket valide se produirait automatiquement.

Figure 4-2. Flux de tickets Kerberos

Les administrateurs ont généralement l’impression que Kerberos est difficile à configurer et à installer. Heureusement, c’est assez facile pour IIS (et SharePoint). Cela implique simplement la création d’un nom principal de service (SPN) pour le service HTTP pour le compte d’utilisateur de domaine exécutant le pool d’applications IIS. Pour le dire simplement, créez un SPN pour HTTP / <FQDN> pour le compte Pool d’ applications Web et définissez l’application Web SharePoint pour utiliser Kerberos. Par défaut, cela nécessite des privilèges d’administrateur de domaine. Pour utiliser l’exemple de cet article, sp.cobaltatom.com est le nom de domaine complet de notre application Web et le compte de service qui lui est attribué est LAB \ s-web.

À l’aide d’une console à partir de n’importe quelle machine jointe à un domaine, exécutez la commande suivante pour affecter le service (HTTP) au principal (LAB \ s-web):

setspn.exe -U -S HTTP/sp.cobaltatom.com LAB\s-web

Le commutateur -S ajoute le SPN après la recherche de SPN en double. Des SPN en double empêcheront le service de fonctionner correctement. Le commutateur -U indique à setspn.exe que le compte auquel nous attribuons le service HTTP est un compte d’utilisateur. Enfin, pendant que nous utilisons SSL, le nom du service est simplement «HTTP». Si vous utilisez un numéro de port autre que 80 ou 443, spécifiez le numéro de port après le FQDN, au format FQDN: nnnn.

De plus, nous avons créé des SPN pour SQL Server. Le service pour SQL Server est

«MSSQLSvc». Comme notre implémentation SQL est représentée par deux serveurs SQL et un groupe de disponibilité SQL AlwaysOn, nous devons définir cinq SPN. Nous indiquons également le numéro de port sur lequel SQL Server écoute. Comme nous utilisons un compte de service géré de groupe pour le compte de service SQL Server, nous utilisons le module Active Directory pour PowerShell et la cmdlet Set-ADServiceAccount au lieu de setspn.exe.

Set-ADServiceAccount -Name s-sql @{Add=’MSSQLSvc/calsql01:1433′,’MSSQLSvc/ calsql01.lab.cobaltatom.com:1433′,’MSSQLSvc/calsql02:1433′,’MSSQLSvc/ calsql02.lab.cobaltatom.com:1433′,’MSSQLSvc/calspag.lab.cobaltatom.com’}

Astuce dans l’exemple précédent, l’opérateur d’ajout a été utilisé pour les noms principaux du service. vous pouvez également utiliser un opérateur de remplacement pour remplacer les Spns existants sur le compte de service par ceux que vous définissez dans le paramètre d’applet de commande.

L’avantage de Kerberos est que la demande d’authentification n’a pas besoin d’effectuer l’aller-retour entre l’utilisateur, Active Directory, vers l’utilisateur, puis vers le service cible. Les billets sont considérés comme valides jusqu’à leur expiration par le service auquel l’utilisateur accède. Cela limite également le potentiel d’interception et de décryptage des tickets. Active Directory propose également, via la stratégie de groupe, des algorithmes de chiffrement qui n’ont actuellement aucune attaque pratique connue. Cela inclut les tickets cryptés AES256. Contrairement à NTLM, qui peut être forcé par une brute en quelques heures, les tickets chiffrés AES128 ou AES256 mettraient des milliards d’années à forcer la force pour récupérer le mot de passe en clair.

Kerberos présente un inconvénient important car il nécessite que le client puisse accéder au KDC. Si le KDC est inaccessible, le client ne peut pas récupérer un ticket Kerberos. Ceci est mieux représenté dans un scénario d’authentification externe, tel que l’utilisateur s’authentifiant sur un site SharePoint sur Internet. Sans mise en œuvre supplémentaire de la pré-authentification des proxys inverses, SharePoint ou IIS plus précisément se replieront pour permettre au client de s’authentifier sur NTLM, ce qui n’est pas souhaitable.

Enfin, certains clients peuvent ne pas pouvoir se connecter à une application Web à l’aide de Kerberos si des ports non standard (TCP / 80 ou TCP / 443) sont utilisés pour l’application Web. Les exemples incluent le Search Crawler ainsi que certains navigateurs. Il s’agit principalement d’un problème lorsque l’application Web est configurée à l’aide de TCP / 88, le même port que Kerberos, bien qu’il soit fortement recommandé de n’utiliser que les ports TCP / 80 ou TCP / 443 standard.

4.1.4 Langage de balisage d’assertion de sécurité

Le langage de balisage d’assertion de sécurité, ou SAML, est une forme moderne d’authentification qui présente les revendications d’un utilisateur à un service. Sur la base de la revendication d’identité contenue dans l’assertion SAML, le service autorisera l’utilisateur au service.

SAML est un favori avec les services modernes en raison de la capacité à se fédérer avec des services disparates qui ne dépendent pas du service d’authentification avec lequel l’utilisateur s’authentifie. Par exemple, un utilisateur peut s’authentifier auprès d’un serveur local de services de fédération Active Directory à l’aide de NTLM ou Kerberos et, en raison de la fédération, peut affirmer son identité à une batterie de serveurs SharePoint exécutée au sein d’une organisation distincte. En fonction des règles de l’approbation de fédération, SharePoint autorisera l’utilisateur à accéder aux ressources SharePoint. Cette configuration est beaucoup plus facile à gérer qu’une approbation de forêt Active Directory sur Internet (qui aurait généralement lieu dans un tunnel VPN).

L’un des inconvénients de SAML, car il est directement lié à SharePoint, n’est pas la validation des informations entrées dans le sélecteur de personnes. La source d’authentification (par exemple, Active Directory) est abstraite de SharePoint, donc SharePoint ne sait pas où «chercher» des comptes lors de l’utilisation de SAML. Cela conduit à une mauvaise expérience utilisateur, car il n’est pas possible pour SharePoint de valider ce qui est une valeur valide ou non valide.

Astuce LdapCp, un projet open source gratuit sur github, implémente des méthodes permettant à Sharepoint de valider les informations entrées dans le sélecteur de personnes. la validation ne fonctionne que lorsque Sharepoint dispose d’un accès Ldap ou LdapS au service d’authentification cible (tel que Active Directory).

https://ldapcp.com/

SharePoint n’est compatible qu’avec SAML 1.1, contrairement à de nombreux autres services compatibles avec SAML 2.0.

4.1.5 Authentification basée sur les formulaires

L’authentification basée sur les formulaires (FBA) est souvent utilisée lors de l’utilisation de fournisseurs d’identité non Active Directory, tels qu’un magasin de données de base de données SQL ou Active Directory Lightweight Directory Services. FBA s’appuie sur des fournisseurs qui mettent en œuvre la logique pour authentifier l’utilisateur par rapport au magasin de données où le nom d’utilisateur et le mot de passe sont conservés. Ceux-ci sont souvent développés sur mesure, bien que Microsoft inclue un fournisseur prêt à l’emploi pour s’authentifier auprès des services LDAP. FBA est souvent choisi dans les scénarios où le service informatique n’utilise pas ou ne peut pas utiliser Active Directory pour les partenaires externes.

Lorsqu’un utilisateur accède à un site SharePoint avec FBA activé, une boîte de dialogue de nom d’utilisateur et de mot de passe lui est présentée pour saisir ses informations d’identification. Le fournisseur d’authentification configuré valide ensuite ces informations d’identification par rapport au magasin d’authentification.

Lorsque vous utilisez FBA, le nom d’utilisateur et le mot de passe sont transmis sur le câble en texte clair. Comme pour l’authentification de base, il est fortement recommandé d’utiliser SSL pour chiffrer le transport des informations d’identification. FBA requiert également une implémentation manuelle dans SharePoint, modifiant les fournisseurs d’appartenance et de rôle dans les fichiers Web.config de l’application Web, du service de jeton de sécurité et de l’administration centrale. Ces fichiers doivent également contenir les mêmes valeurs de configuration pour tous les membres de la batterie de serveurs SharePoint.

4.1.6 Autorisation

SharePoint effectue ce que l’on appelle l’ autorisation ou AuthZ. L’autorisation est lorsqu’un utilisateur a déjà effectué une authentification (AuthN), qui est effectuée par IIS lors de l’utilisation de l’authentification de base, NTLM ou Kerberos, et dans le cas de SAML, le fournisseur d’identité (par exemple, ADFS). AuthN a lieu lorsqu’un utilisateur tente d’accéder à une ressource.

SharePoint évalue les autorisations de la ressource par rapport aux autorisations détenues par l’utilisateur. S’ils disposent des autorisations appropriées, ils sont autorisés à accéder à ce contenu.

Maintenant que nous avons examiné les différentes formes d’authentification prises en charge par SharePoint, ainsi que la différence entre l’authentification et l’autorisation, examinons les options de sécurité de transport disponibles que nous devons utiliser avec SharePoint.

4.2 Sécurité des transports

La sécurité des transports est l’acte de sécuriser ou de chiffrer les informations transmises sur le réseau. SSL, l’une des formes de sécurité de transport les plus utilisées, est maintenant connue sous le nom de TLS.

Cette section présente les protocoles TLS, IPsec et les protocoles de chiffrement modernes disponibles.

4.2.1 TLS

TLS, ou Transport Layer Security, le remplacement de SSL ou Secure Socket Layer, chiffre les données lors de leur envoi entre les services ou entre l’utilisateur final et les services. TLS est très important dans l’implémentation moderne actuelle des services réseau afin de protéger les données en transit sur le réseau.

4.2.2 IPsec

IPsec est une forme de chiffrement de toutes les données sur le réseau sans implémenter spécifiquement un protocole de chiffrement tel que TLS. IPsec, par exemple, chiffrerait les données sur le réseau même si l’utilisateur envoyait des données à un service où le service demandait les informations en texte clair. IPsec a une barrière élevée à l’entrée avec un investissement important dans la planification et la sécurité. IPsec n’est également utile que dans un réseau interne, tandis que TLS serait toujours requis pour crypter les données sur Internet.

4.2.3 Protocoles de chiffrement

TLS, ou SSL, ont des révisions différentes, dont certaines sont désormais considérées comme non sécurisées. SSL a les versions suivantes:

  • SSL 2.0
  • SSL 3.0

SSL 2.0 et SSL 3.0 sont considérés comme non sécurisés et doivent être désactivés côté serveur. TLS a les versions suivantes:

  • TLS 1.0
  • TLS 1.1
  • TLS 1.2

TLS 1.1 et TLS 1.2 sont considérés comme modernes et pour l’instant sécurisés. TLS 1.0 doit être désactivé si possible. SharePoint Server 2019, Office Online Server et SharePoint Workflow Manager prennent en charge la désactivation de tous les protocoles à l’exception de TLS 1.2.

Les protocoles peuvent être désactivés côté serveur via le registre. Lorsque ces paramètres de registre sont modifiés, le serveur doit être redémarré pour que la modification prenne effet. Pour chaque protocole à désactiver, sous le dossier \ Protocols \ <Protocol Version> \ Server, créez un DWORD de «Enabled» égal à 0.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\

SCHANNEL\Protocols][HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\

SCHANNEL\Protocols\PCT 1.0]

@=”DefaultValue”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\

SCHANNEL\Protocols\PCT 1.0\Server]

@=”DefaultValue”

“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\

SCHANNEL\Protocols\SSL 2.0]

@=”DefaultValue”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\

SCHANNEL\Protocols\SSL 2.0\Server]

@=”DefaultValue”

“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\

SCHANNEL\Protocols\SSL 3.0]

@=”DefaultValue”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\

SCHANNEL\Protocols\SSL 3.0\Server]

@=”DefaultValue”

“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\

SCHANNEL\Protocols\TLS 1.0]

@=”DefaultValue”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\

SCHANNEL\Protocols\TLS 1.0\Server]

@=”DefaultValue”

“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\

SCHANNEL\Protocols\TLS 1.1]

@=”DefaultValue”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\

SCHANNEL\Protocols\TLS 1.1\Server]

@=”DefaultValue”

“Enabled”=dword:00000000

Au lieu d’implémenter les modifications du Registre sur des serveurs individuels, envisagez d’utiliser la stratégie de groupe pour implémenter les paramètres.

Un conseil sur un fichier adMX de stratégie de groupe pour implémenter ces modifications est disponible gratuitement sur https://github.com/Nauplius/SchannelConfiguration .

Pour qu’Office Online Server et SharePoint Workflow Manager puissent communiquer avec SharePoint Server 2019 où TLS 1.2 est appliqué, utilisez l’entrée de registre suivante sur le serveur Office Online Server ou Workflow Manager 1.0. Redémarrez le serveur une fois implémenté.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]

“SchUseStrongCrypto”=dword:00000001

4.2.3.1 Sécurité de transport stricte HTTP

HTTP Strict Transport Security (HSTS) est une autre forme d’application de TLS. HSTS a deux fonctions principales:

  • Rediriger les clients de HTTP vers SSL
  • Dire aux clients que le site ne doit être accessible via SSL que pour toutes les demandes futures

Cela aide à prévenir les attaques de l’homme du milieu, où, une fois que le client s’est connecté au site valide, le client est « amené » à se connecter à un site non sécurisé du même nom (par exemple, via l’empoisonnement DNS). Étant donné que HSTS a été activé sur le site valide, le client refusera de se connecter au site non valide, que le site non valide utilise SSL ou HTTP. En effet, HSTS indique également au client de valider le certificat SSL sur le site.

HSTS a une valeur d’âge maximum. Cette valeur indique au client que pour les sessions futures, connectez-vous uniquement via SSL. La valeur d’âge maximale doit être de 18 semaines ou plus et doit être au moins aussi longue que le site devrait prendre en charge SSL. Si le site supprime le support SSL dans le délai maximum, le client refusera de se connecter au site. HSTS peut être défini pour chaque application Web dans SharePoint Server 2019 à l’aide de SharePoint Management Shell.

$wa = Get-SPWebApplication https://sp.cobaltatom.com

$wa.HttpStrictTransportSecuritySettings.IsEnabled = $true

$wa.HttpStrictTransportSecuritySettings.MaxAge = 31536000

$wa.Update()

La propriété MaxAge est une valeur en secondes. La valeur par défaut, 31536000, est de 365 jours.

4.2.3.2 Pont SSL et déchargement SSL

Le pontage SSL est lorsqu’un équilibreur de charge met fin à la session SSL du client sur l’équilibreur de charge. L’équilibreur de charge, à son tour, déchiffre la session, mais la sécurise à nouveau avant de se connecter à la ressource cible, telle qu’un site SharePoint, à l’aide de SSL. Ceci est illustré à la figure 4-3.

Figure 4-3. Pontage SSL

Le pontage SSL peut être utilisé lorsque les administrateurs souhaitent intercepter et inspecter le trafic SSL sur l’équilibreur de charge, accélérer la négociation de session SSL pour les clients (l’équilibreur de charge maintient la session SSL pendant une période plus longue que le client ne le ferait), ou souhaite traduire le protocole SSL ou TLS utilisé par le client en une version plus ou moins stricte du protocole.

Le déchargement SSL consiste à ce que l’équilibreur de charge déchiffre une session cliente puis envoie les informations au service via HTTP, comme illustré à la figure 4-4.

Figure 4-4. Déchargement SSL

Le déchargement SSL est considéré comme non sécurisé car il transmet des informations sensibles en clair. Cela peut inclure des jetons OAuth2, qui contiennent des informations qui peuvent être interceptées sur le réseau et rejouées pour obtenir les mêmes privilèges sur la ressource (ou l’utilisateur) demandée. Étant donné que les jetons OAuth2 sont utilisés entre SharePoint, Office Online Server, Workflow Manager et les compléments SharePoint, il est essentiel que OAuth2 reste chiffré par la sécurité du transport. Si la décision est prise d’utiliser le déchargement SSL, envisagez d’isoler les serveurs SharePoint et tous les serveurs avec lesquels SharePoint utilise OAuth pour communiquer avec d’autres réseaux et services.

4.3 Pare-feu

Les pares-feux sont un aspect important de la sécurité du réseau. Les pares-feux fournissent des règles d’entrée et de sortie pour autoriser ou refuser le trafic en fonction des modèles, des adresses IP source et de destination, etc. Nous couvrirons deux types de pare-feu : les pares-feux basés sur l’hôte et les appliances de pare-feu autonome.

4.3.1 Pare-feu Windows

Le pare-feu Windows est intégré à toutes les versions modernes de Windows. Il fournit un ensemble de règles assez étendu pour autoriser et refuser le trafic en fonction de la connaissance de l’emplacement du réseau (où le serveur détecte s’il se trouve sur un réseau public, privé ou de domaine), de l’adresse IP source et de destination, de l’authentification, etc.

Bien qu’il puisse être rare de l’utiliser dans de nombreux environnements, les services informatiques devraient envisager de l’implémenter sur les serveurs SharePoint. SharePoint crée des règles spécifiques du pare-feu Windows pendant l’installation pour faciliter la gestion. Les règles du pare-feu Windows peuvent également être facilement déployées via une stratégie de groupe sur des ensembles de serveurs. Le pare-feu Windows peut présenter la dernière ligne de défense d’un attaquant qui a déjà obtenu un accès au réseau interne.

4.3.2 Appliances pare-feu

De nombreux fabricants créent des appliances matérielles, ainsi que des pares-feux logiciels fonctionnant sur du matériel standard. Ces pares-feux sont souvent utilisés comme pare-feu périphérique (le pare-feu entre le réseau d’entreprise et la DMZ ainsi que les pares-feux de canal arrière, ou les pares-feux utilisés entre la DMZ et le réseau d’entreprise interne. Ces pares-feux constituent la principale ligne de défense d’un réseau d’entreprise.

4.3.3 DMZ

Placer des serveurs Web dans une zone démilitarisée alors que des serveurs SQL et d’autres services non Web résident dans le réseau interne est courant dans de nombreux environnements et généralement accepté comme une option sécurisée. Cependant, en ce qui concerne SharePoint, cela peut en fait être l’option la moins sécurisée, comme le montre la figure 4-5.

Figure 4-5. SharePoint dans la DMZ avec plusieurs ports ouverts dans le pare-feu du canal arrière

SharePoint doit avoir non seulement un port ouvert vers SQL Server, mais également des ports ouverts entre les serveurs SharePoint et les contrôleurs de domaine Active Directory pour l’authentification, l’autorisation, le sélecteur de personnes, ainsi que le service de profil utilisateur lors de l’utilisation de l’importation AD. Tous les autres services intégrés, tels que SharePoint Workflow Manager, Office Online Server ou les compléments High Trust hébergés doivent également être pris en considération. Cela conduit à un nombre important de ports qui doivent être ouverts dans le pare-feu du canal arrière entre la DMZ et le réseau interne de l’entreprise.

4.3.3.1 Proxys inversés

Les proxys inversés sont des proxys inverses de pré-authentification, tels que le proxy d’application Web de Microsoft, ou ne fournissent aucun mécanisme d’authentification, tel que mod_proxy ou mod_ssl d’Apache. Les proxys inverses sont généralement déployés dans une zone démilitarisée. Leur fonction est de mettre fin à la session de l’utilisateur, tandis que le proxy transmet la session aux services derrière lui. Ceci est illustré à la figure 4-6.

Figure 4-6. Inverser les proxys pour gérer les sessions utilisateur externes

Cela permet à SharePoint et aux services connexes de résider dans le réseau interne de l’entreprise et d’avoir un seul port, tcp / 443 (HTTPS), par exemple, ouvert dans le pare-feu du canal arrière. En général, cela est considéré comme plus sécurisé que de placer des serveurs SharePoint dans la DMZ lorsqu’ils ont besoin d’accéder à des ressources au sein du réseau interne de l’entreprise.

4.3.3.2 Proxy d’application Azure AD

Le proxy d’application Azure AD est un service de Microsoft qui permet la communication avec les services derrière un pare-feu sans ouvrir de port dans le pare-feu. Ce service nécessite un abonnement Azure AD Basic ou Premium (P1 ou P2). Il peut être configuré à l’aide de l’authentification unique, de l’authentification intégrée Windows à l’aide de la délégation contrainte Kerberos ou dans une configuration de connexion unique. Les configurations d’authentification intégrée et de connexion unique Windows nécessitent que vos utilisateurs soient synchronisés avec Azure AD et qu’un service SSO soit en place, tel que Azure AD Connect SSO ou Active Directory Federation Services.

Remarque Plus d’informations sur le proxy d’application sont disponibles sur https: // docs. microsoft.com/en-us/azure/active-directory/manage-apps/ application-proxy-enable .

Pour configurer SharePoint Server 2019 à l’aide du proxy d’application Azure AD avec authentification Windows (délégation Kerberos contrainte) sur SharePoint, nous devons d’abord télécharger et installer le connecteur du proxy d’application. Cela peut être trouvé dans le portail Azure sous Azure Active Directory, puis sous Proxy d’application.

Le connecteur proxy d’application doit être installé sur deux serveurs ou plus sans aucun autre service en cours d’exécution sur eux. Le programme d’installation demandera un compte dans Azure AD qui dispose de droits élevés (tels qu’un administrateur global ou un propriétaire). Aucune configuration supplémentaire n’est requise pour l’installation. Une fois installé, Azure App Proxy Connector s’enregistrera auprès d’Azure AD. Vous pouvez valider l’inscription dans Azure Active Directory sous Proxy d’application, comme illustré dans la figure 4-7.

Figure 4-7. Validation de l’enregistrement des serveurs proxy d’application avec Azure AD

Étant donné que la configuration suivante nécessite une délégation contrainte Kerberos, nous devons déléguer les noms principaux de service appropriés aux comptes d’ordinateur du proxy d’application Azure AD. Pour chaque objet ordinateur du proxy d’application Azure AD dans Active Directory, accédez aux propriétés de l’objet ordinateur. Dans l’onglet Délégation, sélectionnez Approuver cet ordinateur pour la délégation aux services spécifiés uniquement, puis sélectionnez Utiliser n’importe quel protocole d’authentification. Nous devons ensuite ajouter le ou les SPN spécifiques à déléguer. Dans ce cas, nos SPN, HTTP / sp.cobaltatom.com et HTTP / sp-my.cobaltatom.com sont enregistrés auprès de l’utilisateur LAB \ s- web. Cliquez sur le bouton Ajouter et recherchez le compte s-web. Sélectionnez le ou les SPN enregistrés sur le compte et cliquez sur OK. Le résultat ressemblera à la figure 4-8.

Figure 4-8. Enregistrement de SPN avec l’ordinateur exécutant App Proxy Connector

L’étape suivante consiste à créer une application d’entreprise qui pointera vers l’une des applications Web SharePoint. Dans cet exemple, nous allons le configurer pour l’application Web principale, https://sp.cobaltatom.com .

Dans Azure Active Directory, accédez au proxy d’application. Cliquez sur le bouton Configurer une application. Tapez un nom logique pour l’application. C’est ainsi que l’application apparaîtra dans les applications d’entreprise dans Azure Active Directory et peut être la façon dont elle s’affiche dans une vignette pour les utilisateurs finaux (cette option est configurable).

Définissez l’URL interne sur la même valeur que l’URL utilisée pour l’application Web.

Assurez-vous que l’URL externe a la même valeur. Pour la pré-authentification, si vous utilisez la délégation Kerberos contrainte, définissez la valeur sur Azure Active Directory. Cette méthode présentera la même expérience de connexion que vous connaissez peut-être pour les services Office 365 et / ou Azure. Configurez le groupe de connecteurs de manière appropriée; par défaut, il s’agit de Default et correspondra au nom du groupe contenant la liste des serveurs dans le proxy d’application de la figure 4-7. Définissez l’option Traduire les URL dans les en-têtes sur Non. Les autres options resteront à leurs valeurs par défaut. Voir la figure 4-9 comme exemple d’une application entièrement configurée. Notez le message d’information au bas de l’écran. Configurez votre enregistrement DNS externe selon ce message. Cliquez sur Ajouter pour enregistrer la configuration dans Azure AD.

Figure 4-9. Configuration de l’application Web principale pour SharePoint Server 2019 dans le proxy d’application Azure AD

L’étape suivante consiste à modifier l’application que vous venez de créer. Cliquez sur Propriétés et, comme illustré à la figure 4-10, sous Affectation d’utilisateur requise, sélectionnez Non. Si vous ne souhaitez pas que l’application apparaisse dans le portail d’applications utilisateur ou le lanceur d’applications Office 365, sélectionnez Non pour Visible pour les utilisateurs. Cela n’affectera pas leur capacité à accéder à SharePoint sur site.

Figure 4-10. Configuration des propriétés d’accès pour l’application

Cliquez sur Authentification unique. Sous la méthode Select a single sign-on, comme illustré à la figure 4-11, sélectionnez Authentification intégrée Windows.

Figure 4-11. Les options d’authentification unique disponibles

Après avoir sélectionné l’authentification intégrée de Windows, vous serez invité à définir le SPN pour le service, comme illustré à la figure 4-12. Il s’agit du même SPN que celui défini au chapitre 3 ; HTTP / sp.cobaltatom.com pour l’application Web principale.

Figure 4-12. Définition du SPN pour l’application

La dernière étape consiste à accéder au panneau Proxy d’application. Sous les options que nous avons précédemment définies dans la figure 4-9 se trouve une nouvelle option de certificat. Téléchargez le même certificat avec la clé privée (un fichier PFX) utilisé pour l’application Web principale. Cela termine la configuration de l’application dans le proxy d’application Azure AD. Une fois que DNS a été répliqué, vous pourrez utiliser l’URL de votre application Web pour accéder à SharePoint de n’importe où sans avoir à ouvrir de ports entrants dans votre pare-feu d’entreprise.

La configuration d’Office Online Server et du domaine d’application SharePoint diffère légèrement. Lors de la configuration initiale de l’application, sous Pré-authentification, sélectionnez Passthrough au lieu d’Azure Active Directory. Cela est dû au fait qu’Office Online Server n’utilise aucune forme d’authentification (Office Online Server utilise à la place des jetons OAuth) et que SharePoint App Domain ne prend pas en charge Kerberos. Une fois l’application créée, l’option d’authentification unique reste désactivée.

Conseil Assurez-vous que votre dnS interne est correctement configuré pour pointer vers Sharepoint ou un équilibreur de charge si vous utilisez plusieurs serveurs frontaux Sharepoint. le dnS interne sera utilisé par le connecteur proxy de l’application azure installée pour effectuer des recherches.

4.3.4 Règles d’accès

Des règles d’accès strictes doivent être créées, dans la mesure du possible: par exemple, empêcher les réseaux clients de communiquer directement avec les serveurs SharePoint n’exécutant pas de rôles destinés à l’utilisateur final, tels que les serveurs qui ne sont pas le rôle WebFrontEnd.

De même, des règles pour SQL Server doivent également être mises en place. Seuls les serveurs SharePoint, les systèmes de sauvegarde, les systèmes de surveillance et certains systèmes administrateur doivent être autorisés à communiquer avec SQL Server sur différents ports (CIFS, ports SQL standard, comme deux exemples). Le tableau 4-1 fournit les ports entrants essentiels pour chaque type de serveur.

Tableau 4-1. Ports entrants pour les serveurs

Type de serveur Numéro de port Remarques
serveur SQL tCp / 1433 moteur de base de données
serveur SQL tCp / 1434 facultatif (navigateur SQL)
serveur SQL tCp / 5022 facultatif (écouteur de groupe de disponibilité)
Serveur Sharepoint tCp / 80 facultatif (si vous utilisez http)
Serveur Sharepoint tCp / 443 facultatif (si vous utilisez SSL)
serveur en ligne de bureau tCp / 80 facultatif (si vous utilisez http)
serveur en ligne de bureau tCp / 443 facultatif (si vous utilisez SSL)
Gestionnaire de workflow tCp / 12291 facultatif (si vous utilisez http)
Gestionnaire de workflow tCp / 12290 facultatif (si vous utilisez SSL)
Serveur Sharepoint tCp / 32843 Application de service (http)

 

Type de serveur Numéro de port Remarques
Serveur Sharepoint tCp / 32844 Application de service (SSL)
Serveur Sharepoint tCp / 32845 Application de service (net.tcp)
Serveur Sharepoint tCp / 22233 Cache distribué
Serveur Sharepoint tCp / 22234 Cache distribué
Serveur Sharepoint iCMp (0) Cache distribué (ping)
Gestionnaire d’identité Microsoft ports dynamiques rpC Service de synchronisation
Gestionnaire d’identité Microsoft Mappeur de point final rpC Service de synchronisation

4.4 Prochaines étapes

Nous avons examiné les options d’authentification et de sécurité disponibles pour SharePoint Server 2019. Ensuite, nous apprendrons comment installer et configurer les compléments SharePoint.

5 CHAPITRE 5 Configuration des compléments

Afin de personnaliser votre environnement SharePoint 2019, l’une des options recommandées consiste à déployer du code via des compléments (anciennement appelés applications). Avec SharePoint Framework maintenant disponible dans SharePoint 2019 sur site, les compléments seront un peu moins utilisés qu’ils ne l’étaient dans SharePoint 2013 et 2016 ; cependant, de nombreux fournisseurs tiers proposent des produits déployés sous forme de compléments, il est donc très important de comprendre comment configurer l’infrastructure des compléments dans SharePoint Server 2019. En outre, de nombreux fournisseurs tiers proposent des compléments dans le SharePoint Store, qui est comme Apple iTunes ou Google Play, mais pour SharePoint.

Cependant, par rapport à votre smartphone, vous avez besoin de plus qu’une connexion Internet pour installer des compléments dans SharePoint. La possibilité de consommer des compléments dans SharePoint nécessite une configuration non seulement dans SharePoint, mais également dans DNS.

Dans ce chapitre, vous apprendrez à configurer un environnement SharePoint 2019 pour prendre en charge les compléments ainsi qu’à les gérer à l’aide du catalogue d’applications.

5.1 Présentation de l’architecture du complément SharePoint

Avant de commencer à configurer les compléments pour SharePoint 2019, il est important de comprendre l’architecture du complément, pour avoir un aperçu de tous les différents éléments que nous allons configurer dans ce chapitre.

Tout d’abord, techniquement, chaque complément que vous ajoutez à votre batterie de serveurs SharePoint devient un sous-site sous la collection de sites SharePoint sous laquelle vous l’avez ajouté. Dans la figure 5-1, nous pouvons voir un site SharePoint avec deux compléments déployés.

Figure 5-1. Architecture de complément de base dans SharePoint

En outre, les compléments SharePoint s’exécutent sous une zone de recherche différente dans DNS pour des raisons de sécurité. Si votre domaine principal est cobaltatom.com, votre domaine de complément peut être cobaltatomapps.com. Si vous prévoyez d’ouvrir votre site à Internet et autorisez les utilisateurs à s’y connecter sans VPN, vous devrez vous assurer que votre domaine complémentaire est un véritable domaine public, et puisque votre site utilisera probablement SSL (Secure Sockets) Layer), vous aurez également besoin d’un certificat générique sur votre domaine de complément fourni par une autorité de certification publique telle que DigiCert. Le certificat générique est nécessaire car les URL de complément sont générées par SharePoint à l’aide d’un ID aléatoire, comme indiqué plus loin dans ce chapitre.

Remarque Microsoft recommande d’utiliser une toute nouvelle zone de recherche directe et non un sous-domaine tel que apps.cobaltatom.com. Cette recommandation est faite pour empêcher les attaques Cross-Site Scripting (XSS).

L’URL de chaque déploiement de complément reçoit également un ID unique. Par conséquent, même si nous déployons le même complément sur deux collections de sites différentes, chaque déploiement a une URL différente. L’URL est composée d’un préfixe que vous pouvez choisir, de l’ID de complément et du domaine de complément. Dans la figure 5-2, nous pouvons voir le même site SharePoint, avec les URL du site et des compléments. Pour cet article, nous utiliserons le préfixe « app » pour nos compléments.

Figure 5-2. URL de complément dans SharePoint 2019

Nous pouvons choisir le préfixe du complément nous-mêmes, ainsi que le domaine du complément ; cependant, nous ne pouvons pas choisir l’ID affecté au déploiement du complément. Par conséquent, c’est pourquoi nous avons besoin d’une zone de recherche directe dédiée dans notre DNS qui a une entrée générique, donc tout dans notre domaine de complément pointera directement soit sur notre serveur SharePoint, soit sur l’équilibreur de charge réseau qui transmettra la demande à l’un de nos frontaux Web SharePoint. Dans la figure 5-3, vous pouvez voir un exemple du DNS CobaltAtom, qui contiendra la zone de recherche directe CobaltAtom.com contenant tous vos sites SharePoint, ainsi que tous les serveurs et tout dans votre domaine. Nous pouvons également trouver la zone de recherche directe CobaltAtomApps.com qui a simplement une entrée générique, de sorte que tout dans cette zone de recherche directe ira à notre frontal Web SharePoint.

Figure 5-3. Architecture DNS pour les compléments SharePoint

Maintenant que nous savons comment amener nos utilisateurs sur SharePoint Server à partir de DNS, examinons comment SharePoint gère ces demandes. Dans la figure 5-4, nous voyons un utilisateur demandant un complément ; la demande va au DNS qui dirige la demande vers le serveur SharePoint appelé SPWFE. Toutefois, étant donné que nous n’avons aucune application Web portant ce nom, le serveur IIS (Internet Information Services) exécuté sous SharePoint ne saura pas vers quel site envoyer la demande.

Figure 5-4. Que se passe-t-il sur le réseau lorsqu’un utilisateur essaie d’accéder à un complément

L’une des exigences que nous avons sur la batterie de serveurs SharePoint pour les compléments et les collections de sites nommés par l’hôte, qui seront traitées au chapitre 13, est de créer une application Web qui n’a aucun en-tête d’hôte. Les demandes adressées à notre serveur seront automatiquement transmises à cette application Web, qui transmettra la demande à une application de service appelée application de service de gestion des applications. Cette application sait quel complément appartient à quel site et sera en mesure de diriger l’utilisateur vers le bon complément, dans le bon site. Le processus ressemblera alors à la figure 5-5.

Figure 5-5. Que se passe-t-il sur le réseau lorsqu’un utilisateur essaie d’accéder à un complément

Une autre application de service dont nous aurons besoin pour que les compléments fonctionnent est l’application de service des paramètres d’abonnement. Maintenant que nous savons à quoi ressemble l’architecture, commençons à configurer les compléments pour SharePoint 2019.

5.2 Configuration de DNS

Pour configurer DNS, vous devrez être administrateur de domaine et avoir accès à la console du gestionnaire DNS. Tout d’abord, ouvrez la console DNS, cliquez avec le bouton droit sur « zones de recherche directe » et sélectionnez « Nouvelle zone », comme illustré à la figure 5-6.

Figure 5-6. Ajout d’une nouvelle zone à notre DNS

Sur le premier écran, cliquez sur « Suivant » comme le montre la figure 5-7.

Figure 5-7. Assistant Nouvelle zone

La zone doit être de type « zone principale » et également cocher la case « stocker la zone dans AD » comme illustré à la figure 5-8.

Figure 5-8. Sélection du type de zone

Sélectionnez si vous souhaitez que les données soient répliquées sur tous les contrôleurs de domaine de votre domaine ou de votre forêt. Comme nous n’avons qu’un seul domaine dans notre ferme pour cet article, nous choisissons la deuxième option comme le montre la figure 5-9. L’option que vous choisissez ici dépendra de votre infrastructure organisationnelle unique et vous devriez vérifier auprès de vos administrateurs de domaine si vous n’êtes pas sûr de choisir laquelle. Si vous souhaitez rendre les compléments disponibles via Internet, vous devrez également configurer vos enregistrements DNS publics et proxy inverse pour pointer dans la bonne direction.

Figure 5-9. Sélection de l’étendue de réplication de la zone AD

Sur l’écran suivant, vous devez entrer votre nouveau domaine de complément, comme illustré à la figure 5- 10.

Figure 5-10. Saisie du domaine du complément comme nouveau nom de zone

Enfin, sélectionnez le type de mises à jour dynamiques pour votre domaine. Puisqu’il n’y aura pas de nouveaux enregistrements à l’exception de l’enregistrement initial, nous devons sélectionner « Ne pas autoriser les mises à jour dynamiques » comme le montre la figure 5-11.

Figure 5-11. Sélection des propriétés de mise à jour dynamique

Une fois la zone créée, nous devons créer un alias (CNAME) ou un hôte (A) vers nos serveurs SharePoint. Si vous n’avez qu’un seul frontal Web SharePoint, vous pouvez utiliser un CNAME; cependant, si vous utilisez un équilibreur de charge réseau, vous voudrez utiliser un HÔTE car vous transfèrerez probablement vos utilisateurs à une adresse IP virtuelle. Dans notre cas, nous transmettrons toutes les demandes pour notre domaine de complément à 192.168.80.10, une adresse IP virtuelle qui va à l’équilibreur de charge, qui transmet ensuite les demandes à l’un de nos deux frontaux Web.

Tout en restant dans la fenêtre de gestion DNS, cliquez avec le bouton droit sur notre nouvelle zone de recherche directe et sélectionnez un « nouvel hôte (A ou AAAA) », comme illustré à la figure 5-12.

Figure 5-12. Création d’une nouvelle entrée d’hôte dans DNS

Ensuite, entrez un caractère générique (*) dans le nom, ainsi que l’adresse IP vers laquelle vous souhaitez le pointer, comme illustré à la figure 5-13.

Figure 5-13. Saisie de nouvelles propriétés d’enregistrement d’hôte

Pour tester, faites simplement une requête PING à <mot aléatoire> .Add-inDomain.TLD. Dans mon exemple de la figure 5-14, j’ai utilisé ApressRocks.CobaltAtomApps.com et le résultat a réussi car il m’a transmis au 192.168.80.10

Figure 5-14. Test de la configuration avec l’invite de commande

Si le test ping réussit et passe à la bonne adresse IP, cela signifie que le DNS a été configuré avec succès. Nous pouvons maintenant passer à la configuration de notre SharePoint Server 2019 pour accepter les compléments.

5.3 Configuration de SharePoint

La première étape que nous devons effectuer pour préparer notre serveur SharePoint pour les compléments consiste à créer les deux applications de service requises :

  • Application de service de gestion des applications
  • Application de service de paramètres d’abonnement

Si vous effectuez cette procédure dans une batterie de serveurs MinRole complète, les services démarrent automatiquement lors de la création des applications de service. Si vous exécutez sur une batterie de serveurs en mode personnalisé, vous devrez activer manuellement le service de gestion des applications ainsi que le service de paramètres d’abonnement Microsoft SharePoint Foundation sur au moins un serveur SharePoint.

Notez que dans une topologie rationalisée, il est recommandé d’activer ces services sur tous les serveurs Web frontaux de votre batterie de serveurs Sharepoint.

Bien que l’application de service de gestion d’applications puisse être créée à la fois par l’administration centrale et PowerShell, l’application de service de paramètres d’abonnement ne peut être créée qu’à l’aide de PowerShell. Dans cet article, nous allons créer les deux applications de service à l’aide de PowerShell et les exécuter sous notre seul pool d’applications de service appelé SharePoint Web Services Default.

Nous devons d’abord obtenir notre pool d’applications de service et l’enregistrer dans une variable.

$apppool = Get-SPServiceApplicationPool “SharePoint Web Services Default”

Ensuite, nous créons l’application de service de paramètres d’abonnement, ainsi que son proxy.

$SubscriptionSA = New-SPSubscriptionSettingsServiceApplication –

ApplicationPool $apppool –Name “Subscription Settings” –DatabaseName

SubscriptionSettings

$proxySub = New-SPSubscriptionSettingsServiceApplicationProxy –

ServiceApplication $SubscriptionSA

Enfin, nous créons l’App Management Service Application ainsi que son proxy.

$AppManagementSA = New-SPAppManagementServiceApplication -ApplicationPool

$apppool -Name “App Management” -DatabaseName AppManagement

$proxyApp = New-SPAppManagementServiceApplicationProxy -ServiceApplication

$AppManagementSA

Une fois les applications de service créées et opérationnelles, nous devons définir le domaine du complément ainsi que le préfixe du complément. Cela peut être fait dans Administration centrale Applications Configurer les URL des applications comme illustré à la figure 5-15 ou via PowerShell.

Figure 5-15. L’écran Configurer l’URL de l’application dans SharePoint 2019

Pour le faire via PowerShell, commencez par configurer le domaine du complément à l’aide de l’applet de commande suivante:

Set-SPAppDomain CobaltAtomApps.com

Et définissez ensuite le préfixe du complément à l’aide de l’applet de commande suivante.

Set-SPAppSiteSubscriptionName -Name “app” -Confirm:$false

La seule chose dont nous avons besoin maintenant est une application Web sans en-tête d’hôte. Sans cette application Web, les utilisateurs verront une erreur HTTP 404 lorsqu’ils tenteront d’accéder à un complément. Une application Web sans en-tête d’hôte signifie simplement que lorsque vous créez l’application Web, vous laissez le champ «En-tête d’hôte» vide comme le montre la figure 5-16.

Figure 5-16. Création d’une nouvelle application Web dans SharePoint 2019

Si vous avez déjà une application Web utilisant le mappage d’accès alternatif de https://nom_serveur ou un site IIS avec cette liaison, SharePoint ne vous permettra pas de créer la nouvelle application Web sur le port 443. Si vous avez configuré l’administration centrale sur SSL comme nous l’avons fait dans cet article, assurez-vous d’avoir supprimé le mappage d’accès alternatif par défaut, car nous avons créé une nouvelle URL pour celui-ci.

Vous devrez également créer une collection de sites racine sur cette application Web. Aucun modèle ou autorisation spécifique n’est nécessaire ; cependant, il doit exister pour que SharePoint fonctionne correctement.

Puisque nous utilisons SSL, nous devrons également ajouter le certificat dans IIS. Pour ce faire, vous devez d’abord importer le certificat générique pour votre domaine de complément dans IIS, comme illustré à la figure 5-17.

Figure 5-17. Certificats dans IIS Manager

Ensuite, vous devez ajouter une liaison sur le site IIS que nous venons de créer, sur le post 443 (SSL) et sélectionner le certificat que nous venons d’importer, comme illustré à la figure 5-18.

Figure 5-18. Ajout d’une liaison dans IIS

En raison des limitations de l’architecture TLS / SSL, vous ne pouviez généralement pas exécuter plus d’un site SSL sur le même serveur Web car il n’y avait aucun moyen dans TLS de spécifier un « nom d’hôte » pour le trafic. Avec Windows Server 2012 R2 et IIS8, nous avons l’identification de nom de serveur (SNI) sur les autres applications Web, ce qui permet à cela de fonctionner.

Si vous n’utilisez pas SNI, vous devrez ajouter une autre IP au serveur SharePoint et rediriger toutes les demandes de complément vers cette IP.

Remarque Vous devez répéter cette étape sur chaque serveur sur lequel le service d’application Web de base est en cours d’exécution. si vous exécutez dans une configuration Minrole, ces serveurs sont le rôle frontal, le cache distribué et les rôles d’application. Le rôle de recherche autonome n’a pas d’application Web de base activée ; par conséquent, vous ne pouvez effectuer aucune modification sur les serveurs de recherche.

La sécurisation de tous vos sites SharePoint avec SSL est extrêmement importante dans SharePoint, car le jeton OAuth est transmis dans un paquet à la demande, et vous pourriez être soumis à une attaque de l’homme du milieu si ce jeton n’est pas sécurisé.

Après cela, vous pouvez aller dans le magasin et ajouter un complément à partir du magasin SharePoint, et tout devrait fonctionner !

Nous avons maintenant configuré avec succès les compléments, mais il y a quelques paramètres que nous pouvons changer pour rendre l’expérience plus agréable pour nos utilisateurs finaux.

5.4 Paramètres de post-configuration

Une fois que les compléments sont configurés sur notre environnement SharePoint, certaines configurations peuvent être nécessaires dans certains cas pour améliorer l’expérience utilisateur ou activer des fonctionnalités supplémentaires. Le premier est principalement pour l’expérience utilisateur. Habituellement, nous ajoutons notre domaine principal, par exemple * .CobaltAtom.com à la zone Intranet dans Internet Explorer pour tous nos utilisateurs afin qu’ils n’aient pas à entrer leur nom d’utilisateur et mot de passe chaque fois qu’ils se rendent sur un site SharePoint. Cependant, étant donné que nos compléments s’exécutent dans un domaine différent, les utilisateurs seront invités à entrer leur nom d’utilisateur et leur mot de passe chaque fois qu’ils accèdent à un complément, ou ont une partie de complément sur une page SharePoint, comme le montre la figure 5-19.

Figure 5-19. Invite d’authentification sur le domaine du complément

Microsoft recommande de ne pas ajouter le domaine de complément à notre zone Intranet ou Sites de confiance, car ces zones ne fournissent pas un niveau d’isolation suffisant des compléments des données utilisateur dans les sites SharePoint. Les conséquences, comme décrit précédemment, sont d’avoir une invite d’authentification Windows chaque fois qu’un utilisateur accède à un complément ou navigue vers une page avec un composant de complément incorporé.

Pour éviter ce comportement et offrir une expérience transparente à vos utilisateurs, assurez-vous d’ajouter le domaine du complément à la zone Intranet de tous vos utilisateurs, par stratégie de groupe ou tout autre outil dont vous disposez dans votre organisation. En tant qu’administrateur SharePoint, vous devez décider de suivre les meilleures pratiques de sécurité de Microsoft ou d’opter pour le meilleur comportement de l’utilisateur final et les meilleures pratiques UX.

Le deuxième paramètre, un peu plus spécifique à SharePoint, permet aux utilisateurs de déployer des applications qui nécessitent des sites avec des points de terminaison accessibles sur Internet. Ces applications sont grisées par défaut et les utilisateurs ne peuvent pas les déployer. Si votre batterie de serveurs est configurée pour autoriser les points de terminaison accessibles sur Internet, vous pouvez activer les applications qui nécessitent une fonctionnalité de points de terminaison accessibles sur Internet sur chaque application Web sur laquelle vous souhaitez activer cette fonctionnalité. La fonction est désactivée par défaut, comme illustré à la figure 5-20.

Figure 5-20. Activation des fonctionnalités des applications Web

Nous avons maintenant terminé avec succès la configuration des compléments dans notre environnement, et les utilisateurs peuvent ajouter et consommer des compléments à partir du SharePoint Store. Dans la section suivante, nous apprendrons comment contrôler les compléments achetés et comment distribuer des compléments personnalisés à vos utilisateurs.

5.5 Le catalogue d’applications

Le catalogue d’applications est une collection de sites spéciale sur chaque application Web qui permet aux administrateurs SharePoint de gérer et de contrôler les compléments installés sur la batterie de serveurs. En configurant un catalogue d’applications, nous pouvons forcer les utilisateurs à demander à un administrateur d’approuver tous les achats de compléments, ainsi que de télécharger des compléments construits en interne et de les rendre disponibles à tous nos utilisateurs.

5.5.1 Création d’une collection de sites de catalogue d’applications

Le catalogue d’applications peut être créé à partir de l’administration centrale dans les applications ➤ Gérer le catalogue d’applications ou via PowerShell en utilisant le modèle « APPCATALOG # 0 ». Lors de la création du catalogue d’applications via l’administration centrale, nous devons accéder à la section Applications et cliquer sur Gérer le catalogue d’applications, puis sélectionner « Créer un nouveau site de catalogue d’applications », comme illustré à la figure 5-21.

Figure 5-21. La page Gérer le catalogue d’applications dans SharePoint 2019

La page de création de site de catalogue d’applications est très similaire à une page de création de collection de sites normale ; la seule différence est que nous avons une nouvelle boîte appelée « Utilisateurs finaux » dans laquelle nous entrons les utilisateurs autorisés à voir les compléments de ce site de catalogue d’applications. Dans notre scénario, nous voulons que le catalogue d’applications soit ouvert à tous les utilisateurs SharePoint, nous avons donc simplement entré le groupe Utilisateurs du domaine, comme illustré à la figure 5-22.

Figure 5-22. Création d’une nouvelle collection de sites de catalogue d’applications

5.5.2 Configurer les demandes

Pour empêcher les utilisateurs d’acheter eux-mêmes des compléments dans le SharePoint Store et de les forcer à envoyer une demande, nous devons apporter quelques modifications dans la page Administration centrale Applications Configurer les paramètres du magasin. Si nous le définissons sur Non, comme illustré à la figure 5-23, les utilisateurs devront demander un complément avant de pouvoir l’acheter.

Figure 5-23. La page des paramètres de la boutique SharePoint dans SharePoint 2019

Cette modification peut également être effectuée avec PowerShell avec l’applet de commande suivante en remplaçant https://sp.CobaltAtom.com par l’application Web sur laquelle vous souhaitez appliquer la modification.

Set-SPAppAcquisitionConfiguration -WebApplication https://sp.CobaltAtom.com -Enable: $ false

Lorsque vous forcez vos utilisateurs à demander des compléments au lieu qu’ils puissent les installer eux-mêmes, le bouton pour ajouter un complément passera de « Ajouter » comme le montre la figure 5-24 à « Demander » comme le montre la Figure 5-25.

Figure 5-24. Bouton lorsque les utilisateurs sont autorisés à ajouter des compléments eux-mêmes

Figure 5-25. Bouton lorsque les utilisateurs doivent demander l’approbation d’un complément pour pouvoir l’ajouter

Lorsqu’un utilisateur demande un complément, il doit spécifier le nombre de licences dont il a besoin ou s’il s’agit de l’ensemble de l’organisation, comme le montre la figure 5-26. Les utilisateurs doivent également fournir une justification commerciale pour le complément.

Figure 5-26. La demande d’application pour les utilisateurs finaux

Lorsqu’une demande de complément est effectuée, SharePoint Server 2019 place la demande dans la liste « Demandes d’application » du catalogue d’applications de cette application Web, comme illustré à la figure 5-27 .

Figure 5-27. La liste des demandes d’application dans le catalogue d’applications

Une fois que nous avons cliqué sur l’entrée de la liste, nous pouvons voir le titre de l’application, le nombre de sièges requis, la justification ainsi qu’un champ d’état et des commentaires d’approbateur. Changer le statut en « Approuvé » ne permettra pas à l’utilisateur d’installer le complément ; l’administrateur du catalogue d’applications devra obtenir le complément dans la boutique en cliquant sur le lien « Cliquez ici pour afficher les détails de l’application et acheter ou gérer des licences », comme illustré à la figure 5-28.

Figure 5-28. Les détails d’une demande de complément

Une fois que l’administrateur a acquis le complément, les utilisateurs pourront voir le complément dans la section « Applications que vous pouvez ajouter » dans la collection de sites, comme illustré à la figure 5-29.

Figure 5-29. Le complément est disponible sur la collection de sites demandée

Nous avons maintenant configuré avec succès le catalogue d’applications dans notre batterie de serveurs SharePoint 2019.

5.6 Prochaines étapes

Dans ce chapitre, nous avons appris à configurer notre batterie de serveurs SharePoint 2019 pour permettre aux utilisateurs de consommer des compléments à partir du magasin SharePoint ou intégrés. Nous avons également appris ce qu’est le catalogue d’applications et comment nous pouvons demander une approbation administrateur avant d’ajouter des compléments aux sites SharePoint de notre organisation.

Dans le chapitre suivant, nous apprendrons comment créer et configurer l’application de service de recherche !

6 CHAPITRE 6 Configuration de l’application de service de recherche

La recherche est une partie très importante de SharePoint, et de nombreuses entreprises s’appuient sur le puissant moteur de recherche SharePoint pour trouver des documents et des informations pour leurs tâches quotidiennes. Dans ce chapitre, vous apprendrez l’architecture de l’application de service de recherche SharePoint, ainsi que la façon de la configurer à partir de l’administration centrale et de PowerShell.

6.1 Architecture d’application du service de recherche SharePoint

Avant de commencer à configurer l’application de service de recherche, nous devrons mieux comprendre l’architecture et son fonctionnement en interne. Le moteur de recherche SharePoint 2019 est construit sur le moteur de recherche FAST que Microsoft a acquis en 2008 auprès d’une société norvégienne alors appelée Fast Search & Transfer ASA et est entièrement intégré à SharePoint depuis SharePoint 2013. Le moteur de service de recherche SharePoint est divisé en six composants différents :

1. Composant d’exploration

Le composant d’analyse est responsable de l’analyse de différents types de contenu tels que les sites SharePoint locaux, les sites SharePoint distants, les partages de fichiers, etc. Nous appelons ces sources de contenu.

2. Composant de traitement de contenu

Le composant de traitement de contenu reçoit des données du composant d’analyse et les décompose en artefacts pouvant être inclus dans l’index. Certaines personnalisations de recherche telles que les extractions d’entités personnalisées sont effectuées par le composant de traitement de contenu.

3. Composante d’index

Le composant d’index est une représentation logique d’un fichier d’index.

Le composant Index reçoit des éléments du composant de traitement de contenu et les écrit dans un fichier d’index. Pour les systèmes où il y a beaucoup d’éléments analysés, l’index peut être divisé en différentes partitions d’index, une partie logique de l’index de recherche complet.

4. Composant de requête

Le composant de traitement des requêtes est le composant qui interagit avec le serveur frontal SharePoint. Le composant de traitement des requêtes récupère les requêtes effectuées par les utilisateurs, les analyse et les soumet aux composants d’index. Le composant Index renverra ensuite les résultats pertinents au composant Query, qui renverra ensuite les résultats à l’utilisateur final. Le composant de requête est également responsable du filtrage de sécurité dans les résultats de la recherche.

5. Composant de traitement analytique

Le composant de traitement analytique crée des analyses de recherche ainsi que des analyses d’utilisation. Ces analyses sont utilisées pour la pertinence de la recherche, générer des recommandations ainsi que créer des rapports de recherche.

6. Composante d’administration de la recherche

Le composant d’administration de recherche exécute les tâches d’administration ainsi que l’approvisionnement des autres composants de recherche.

Tous ces composants fonctionnent ensemble pour offrir une expérience de recherche de bout en bout à vos utilisateurs. Contrairement à la plupart des applications de service, qui n’ont qu’une seule base de données, l’application de service de recherche a quatre types de bases de données différents, et vous pouvez en avoir plus d’un de chaque type dans votre application de service de recherche, selon vos besoins.

Nous couvrirons ces cas et quand et comment faire évoluer votre application de service de recherche un peu plus loin dans ce chapitre. Les différents types de bases de données que vous trouverez dans l’application de service de recherche sont les suivants :

1. Base de données d’exploration

La base de données d’exploration contient des informations de suivi et d’historique sur les éléments analysés ainsi que des informations sur les derniers temps d’exploration, les types d’analyses et les durées.

2. Rechercher dans la base de données d’administration

La base de données d’administration de recherche stocke des données de configuration telles que la topologie, les propriétés gérées, la requête et les règles d’analyse.

3. La base de données de liens

La base de données de liens stocke des informations extraites par le composant de traitement de contenu ainsi que des informations sur les clics de recherche et la popularité.

4. La base de données de rapports Analytics

La base de données Analytics Reporting stocke des informations statistiques et des résultats d’analyse.

Il existe un autre emplacement de stockage de données, qui n’est pas une base de données, mais des fichiers journaux sur le serveur qui héberge le composant de traitement analytique. C’est ce qu’on appelle le magasin d’événements. Le magasin d’événements contient des événements d’utilisation tels que le nombre d’éléments affichés. Maintenant que nous connaissons les composants d’une application de service de recherche, voyons comment nous pouvons la créer.

Il est important de se rappeler que le composant d’index est également stocké sur le système de fichiers et non dans la base de données. Par conséquent, il est important de prévoir de l’espace disque supplémentaire pour les serveurs exécutant le composant d’index.

Tous ces composants de recherche doivent être hébergés sur un serveur SharePoint configuré comme serveur MinRole « Recherche » ou « Application et recherche », ou serveur MinRole « personnalisé » avec les services de recherche démarrés.

6.2 Limitations des applications du service de recherche

Lors de la planification de notre topologie d’application de service de recherche, nous devons respecter à la fois les exigences métier ainsi que les limites logicielles de SharePoint Server 2019. Les exigences métier peuvent concerner la fraîcheur des index ainsi que la séparation entre les index de deux clients différents hébergés sur le même SharePoint ferme. Le nombre d’éléments que vous prévoyez d’analyser à l’aide de l’application Service de recherche SharePoint peut configurer l’application SearCh ServiCe vous obliger à ajouter plusieurs serveurs à votre topologie de recherche pour contourner les limites du logiciel dans SharePoint.

Conseil Vous pouvez afficher toutes les limites du logiciel Sharepoint Server sur technet via le lien suivant : https://docs.microsoft.com/en-us/SharePoint/ install / software-limits-and-limits-0 # search-limits .

6.3 Création d’une application de service de recherche

L’application de service de recherche peut être créée à la fois à partir de l’interface utilisateur SharePoint et à partir de SharePoint Management Shell. Lors de la création de l’application de service de recherche via l’administration centrale, les bases de données de recherche sont associées à un GUID, contrairement à la création de l’application de service de recherche via PowerShell, où vous contrôlez la convention de dénomination de la base de données. Il est également important de savoir que bien qu’il soit possible de créer l’application de service de recherche avec l’administration centrale, la topologie d’application de service de recherche ne peut être modifiée que via PowerShell. Les applications de service de recherche créées avec l’administration centrale hébergeront tous les composants sur un seul serveur. Pour ces raisons, nous vous recommandons fortement d’utiliser PowerShell pour créer votre application de service de recherche. Nous couvrirons toujours les deux options de création de l’application de service de recherche dans ce chapitre.

6.3.1 Création d’une application de service de recherche à partir de l’administration centrale

Pour créer une application de service de recherche à partir de l’interface utilisateur, à partir de la page Gérer les applications de service dans l’administration centrale, cliquez sur Nouveau et sélectionnez Application de service de recherche comme illustré à la figure 6-1 .

Figure 6-1. Nouvelle application de service de recherche à partir de l’interface utilisateur

Dans la nouvelle fenêtre Créer une nouvelle application de service de recherche illustrée à la figure 6-2, nous devrons d’abord lui donner un nom, sélectionner s’il s’agit d’une application de service de recherche normale ou d’une application de service de recherche dans le cloud, et lui donner le compte de service qui s’exécutera. le service de recherche Windows. Dans ce chapitre, nous ne couvrirons pas l’application de service de recherche cloud, car cela sera traité dans le chapitre 14. Bien qu’il soit possible de définir un compte de service de recherche dédié pour une couche de sécurité supplémentaire, nous vous recommandons d’utiliser le même compte qui exécute les autres services, qui dans notre cas est Lab\s-svc.

Figure 6-2. Nouvelle fenêtre d’application du service de recherche

Dans la deuxième partie de la fenêtre Créer une nouvelle application de service de recherche illustrée à la figure 6-3, nous devons sélectionner si nous voulons créer de nouveaux pools d’applications de service pour le service Web d’administration de recherche et le service Web Paramètres de requête et de site, ou utiliser un service existant. Bien que la création de nouvelles applications puisse augmenter l’isolement des applications du service de recherche, cela entraînera l’utilisation de ressources supplémentaires sur vos serveurs. Dans cet article, nous vous recommandons d’utiliser le même pool d’applications que le reste de vos applications de service, dans ce cas « SharePoint Web Services par défaut », sauf si vous avez des exigences commerciales ou de sécurité spécifique pour isoler cette application de service des autres applications de service.

Figure 6-3. Nouvelle fenêtre d’application du service de recherche

Vous pouvez ensuite cliquer sur OK pour créer l’application de service de recherche. Une fois créé, le

La page d’administration de la recherche illustrée à la figure 6-4 affiche le serveur de recherche sur lequel l’application de service de recherche a activé les six composants, ainsi que les noms de base de données, qui contiennent des GUID, car nous avons créé cette application de service à l’aide de l’interface utilisateur.

Figure 6-4. Rechercher la topologie d’application avec GUID dans les noms de base de données

Avec l’application de service créée à partir de l’interface utilisateur, apprenons également à la créer à partir de PowerShell.

6.3.2 Création d’une application de service de recherche à l’aide de PowerShell

La création d’une application de service de recherche à l’aide de PowerShell donne à l’administrateur SharePoint plus de contrôle. Pour créer une nouvelle application de service de recherche, vous devez ouvrir SharePoint Management Shell en tant qu’administrateur et utiliser l’applet de commande PowerShell New-SPEnterpiseSearchServiceApplication. Les applets de commande devront être exécutées à partir d’un serveur configuré dans le MinRole de recherche ou d’un serveur qui exécute le MinRole personnalisé. Notez que lors de la création d’une application de service de recherche via PowerShell, elle n’aura pas de topologie initiale comme lors de sa création par l’interface utilisateur, elle ne sera donc pas utilisable tant que nous n’aurons pas modifié la topologie d’application de service de recherche, que nous couvrirons un peu plus loin dans ce chapitre.

$sa = New-SPEnterpriseSearchServiceApplication -Name “<Service Application

Name>” -DatabaseName “<Search Database Name Prefix>” -ApplicationPool

“<Name of existing Service Application Pool>” -AdminApplicationPool “<Name of existing Service Application Pool>”

Afin de créer une application de service avec les mêmes paramètres que nous l’avons fait via l’interface utilisateur un peu plus tôt dans le chapitre, nous exécuterions l’applet de commande PowerShell suivante :

$sa = New-SPEnterpriseSearchServiceApplication -Name “Search Service

Application 1” -DatabaseName “SearchDB” -ApplicationPool “SharePoint Web

Services Default” -AdminApplicationPool “SharePoint Web Services Default”

Une fois l’application de service de recherche créée, nous devons créer le proxy d’application de service de recherche en exécutant l’applet de commande roxy New-SPEnterpriseSearchServiceApplicationP. Dans l’applet de commande suivante, nous allons créer un proxy nommé «Search Service Application Proxy» pour l’application de service de recherche que nous avons créée précédemment, à laquelle nous avons enregistré une référence dans la variable $ sa.

New-SPEnterpriseSearchServiceApplicationProxy -Name “Search Service Application Proxy” -SearchApplication $sa

Une fois les deux applets de commande terminées, nous pouvons naviguer dans notre nouvelle application de service de recherche via l’interface utilisateur et vous remarquerez que les noms de base de données ne contiennent plus de GUID. Cependant, étant donné que la création d’une application de service de recherche par PowerShell ne crée pas également une topologie initiale, la topologie d’application de recherche ne peut pas être affichée, comme illustré à la figure 6-5 .

Figure 6-5. Application de service de recherche créée par PowerShell

Une fois l’application de service créée, nous devrons modifier la topologie de l’application de service de recherche pour l’adapter à nos besoins.

6.4 Modification de la topologie d’application du service de recherche

La modification de la topologie de l’application de service de recherche peut être effectuée dans un certain nombre de cas. Vous devrez le faire lors de la première création de votre application de service de recherche, ainsi qu’à chaque fois que vous devrez modifier les composants exécutés sur chaque serveur. Lorsque vous modifiez la topologie d’application de service de recherche à l’aide de la méthode suivante, vous devez savoir que l’index doit être vide lors du changement de la topologie d’application de service de recherche. Plus loin dans cette section, nous apprendrons comment modifier la topologie d’application de service de recherche dans une application de service qui contient déjà des éléments dans l’index.

Pour modifier la topologie de recherche, nous devons d’abord obtenir l’application de service de recherche et l’enregistrer dans une variable.

$sa = Get-SPEnterpriseSearchServiceApplication

Ensuite, nous devons obtenir l’instance de service de recherche de notre premier serveur de recherche, appelée CALSP03, et l’enregistrer dans une variable.

$si = Get-SPEnterpriseSearchServiceInstance | ?{$_.Server -match “CALSP03”}

Si vous souhaitez utiliser un serveur exécutant le MinRole personnalisé pour héberger l’un des composants de recherche, vous devez d’abord démarrer l’instance du service de recherche d’entreprise. Pour ce faire, exécutez la cmdlet Start-SPEnterpriseSearchServiceInstance. Pour démarrer l’instance, nous exécuterions l’applet de commande suivante :

Start-SPEnterpriseSearchServiceInstance -Identity $si

Vous devrez ensuite valider que l’instance de service est en ligne en exécutant l’applet de commande Get-SPEnterpriseSearchServiceInstance. Lorsque vous exécutez l’applet de commande suivante et remplacez CALSP03 par le nom de votre serveur, l’état doit être « En ligne ».

Get-SPEnterpriseSearchServiceInstance | ?{$_.Server -match “CALSP03”}

Nous devons ensuite créer une nouvelle variable, qui sera un clone de la topologie active actuelle dans notre application de service de recherche. L’application de service de recherche peut avoir plusieurs topologies ; cependant, un seul d’entre eux peut être actif. Lors de la modification de notre topologie, nous allons d’abord créer un clone de celui qui est actif, et après avoir spécifié ses propriétés, nous le définirons sur Actif.

$clone = $sa.ActiveTopology.Clone()

Nous pouvons alors décider quels composants nous voulons activer sur notre premier serveur. Voici les applets de commande pour chaque composant d’application de service de recherche:

  • Admin: New-SPEnterpriseSearchAdminComponent
  • Explorer: New-SPEnterpriseSearchCrawlComponent
  • Traitement de contenu: Nouveau – SPEnterpriseSearchContentProcessingCo mponent
  • Index: New-SPEnterpriseSearchIndexComponent
  • Requête: New-SPEnterpriseSearchQueryProcessingComponent
  • Analytics: New-SPEnterpriseSearchAnalyticsProcessingComponent

Pour tous les composants, nous devrons donner un paramètre SearchTopology, qui spécifie la topologie de recherche à laquelle nous voulons ajouter ce composant; dans notre cas, ce sera la topologie de recherche qui se trouve actuellement dans la variable $ clone. Nous devons également lui donner une instance de recherche, en spécifiant sur quel serveur nous voulons activer ce composant de recherche. Dans notre cas, nous spécifierons la variable $ SI dans laquelle nous avons enregistré l’instance du service de recherche du serveur CALSP03. Pour ajouter tous les composants sur Search Server CALSP03, nous exécuterions le code PowerShell suivant:

New-SPEnterpriseSearchAdminComponent -SearchTopology $clone

-SearchServiceInstance $si

New-SPEnterpriseSearchContentProcessingComponent -SearchTopology $clone

-SearchServiceInstance $si

New-SPEnterpriseSearchAnalyticsProcessingComponent -SearchTopology $clone

-SearchServiceInstance $si

New-SPEnterpriseSearchCrawlComponent -SearchTopology $clone

-SearchServiceInstance $si

New-SPEnterpriseSearchIndexComponent -SearchTopology $clone

-SearchServiceInstance $si -IndexPartition 0

New-SPEnterpriseSearchQueryProcessingComponent -SearchTopology $clone

-SearchServiceInstance $si

Notez que par défaut, l’emplacement de l’index se trouve sur le lecteur C dans C: \ Program Files \ Microsoft Office Servers \ 16.0 \ Data \ Office Server \ Applications.

Notez que l’emplacement par défaut peut avoir été modifié lors de l’installation binaire.

Cela peut avoir un impact sur les performances car la recherche peut avoir une exigence d’E / S disque importante. Un impact supplémentaire peut être la taille de l’index, qui peut entraîner un manque d’espace disque sur le disque. Pour créer votre fichier d’index sur un autre lecteur, vous devez spécifier le paramètre RootDirectory à l’applet de commande New- SPEnterpriseSearchInd exComponent, comme nous le ferons dans la suite. Le dossier doit être vide, sinon l’applet de commande échouera.

New-SPEnterpriseSearchIndexComponent -SearchTopology $clone-SearchServiceInstance $si -IndexPartition 0 -RootDirectory F:\SearchIndex\0

Nous avons ajouté tous les composants de recherche sur notre premier serveur de recherche, il est donc temps de les ajouter sur notre deuxième serveur de recherche. La première chose que nous devons faire est d’obtenir l’instance du service de recherche du deuxième serveur et de l’enregistrer dans une variable appelée $ si2.

$si2 = Get-SPEnterpriseSearchServiceInstance | ?{$_.Server -match “CALSP04”}

Notez que si le serveur exécute le rôle personnalisé, vous devrez démarrer l’instance du service de recherche comme nous l’avons appris plus haut dans cette section.

Nous ajouterons ensuite un nouveau composant de recherche de chaque type sur le deuxième serveur de recherche également.

New-SPEnterpriseSearchAdminComponent -SearchTopology $clone -SearchServiceInstance $si2

New-SPEnterpriseSearchAnalyticsProcessingComponent -SearchTopology $clone -SearchServiceInstance $si2

New-SPEnterpriseSearchContentProcessingComponent -SearchTopology $clone -SearchServiceInstance $si2

New-SPEnterpriseSearchCrawlComponent -SearchTopology $clone -SearchServiceInstance $si2

New-SPEnterpriseSearchIndexComponent -SearchTopology $clone

-SearchServiceInstance $si2 -IndexPartition 0 -RootDirectory F:\SearchIndex\0

New-SPEnterpriseSearchQueryProcessingComponent -SearchTopology $clone -SearchServiceInstance $si2

Enfin, nous devons définir la topologie $ clone, comme topologie active afin de voir les résultats dans notre application de service de recherche. Cela se fait avec l’applet de commande PowerShell suivante :

$clone.Activate()

Une fois que le clone a fini de s’activer, lorsque vous accédez à la page Administration de la recherche, la topologie affiche tous les composants sur les deux serveurs avec une case à cocher verte, ce qui signifie qu’ils sont sains, comme illustré à la figure 6-6 .

Figure 6-6. Topologie d’application de service de recherche

À mesure que votre topologie de recherche change en fonction de votre utilisation de l’environnement, l’application de service de recherche conserve un historique de ces topologies comme inactif. Vous pouvez les afficher en exécutant l’applet de commande PowerShell suivante:

Get-SPEnterpriseSearchTopology -SearchApplication $sa

Et comme le montre la figure 6-7 , notre application de service actuelle a trois topologies.

Figure 6-7. Topologies de recherche multiples dans notre application de service de recherche

Cela peut provoquer de la confusion lors de la tentative de gestion de l’application du service de recherche par la suite, nous pouvons donc exécuter l’applet de commande PowerShell suivante qui parcourra toutes les topologies existantes et supprimera toutes les topologies inactives:

foreach($topo in (Get-SPEnterpriseSearchTopology -SearchApplication $sa |

?{$_.State -eq “Inactive”}))

{

Remove-SPEnterpriseSearchTopology -Identity $topo -Confirm:$false

}

Lors de la modification d’une topologie qui contient déjà des éléments dans l’index, nous devons être un peu plus prudents. Pour déplacer votre composant d’index vers un autre serveur, vous devez d’abord ajouter le deuxième composant d’index à votre topologie, attendre que l’index soit répliqué sur le nouveau serveur, puis supprimer l’ancien composant d’index. Pour supprimer un composant de la topologie de l’application de service de recherche, nous devons d’abord obtenir la topologie active et créer un clone à l’aide de l’applet de commande New-SPEnterpriseSearchTopology. Voici un exemple d’applets de commande:

$sa = Get-SPEnterpriseSearchServiceApplication

$active = Get-SPEnterpriseSearchTopology -SearchApplication $sa -Active

$clone = New-SPEnterpriseSearchTopology -SearchApplication $sa -Clone -SearchTopology $active

Nous devons ensuite trouver le ComponentId du composant de recherche que nous voulons supprimer. Pour voir tous les ID de composant, nous devons exécuter l’applet de commande suivante :

Get-SPEnterpriseSearchComponent -SearchTopology $clone

PowerShell affichera une liste de tous les composants et tous les composants auront un ComponentId. Dans l’exemple suivant, l’ IndexComponent2 s’exécutant sur le serveur CALSP04 a le ComponentId « 8bae00ce-2ca3-428d-b0bd-6356d806a23d »:

IndexPartitionOrdinal : 0

RootDirectory : F:\SearchIndex\0

ComponentId : 8bae00ce-2ca3-428d-b0bd-6356d806a23d

TopologyId : 1e435e79-7af3-4ce3-a62f-13205aaf9e08

ServerId : a1b3930e-18de-441c-a867-d3d0af440861

Name : IndexComponent2

ServerName : CALSP04

ExperimentalComponent : False

Maintenant que nous connaissons l’ID, nous pouvons exécuter l’applet de commande Remove-SPEnterpriseSearchComponent, puis activer notre nouvelle topologie. Supprimez le composant que nous avons ciblé précédemment, nous exécuterions les applets de commande PowerShell suivantes:

Remove-SPEnterpriseSearchComponent -Identity ‘8bae00ce-2ca3-428d-b0bd-6356d806a23d’ -SearchTopology $clone

$clone.Activate()

Le composant d’index du serveur CALSP04 sera alors supprimé de la topologie. Vous pouvez ensuite exécuter les applets de commande PowerShell que nous avons vues précédemment dans ce chapitre pour nettoyer les topologies de recherche inactives.

Pour étendre davantage votre application de service de recherche, vous pouvez également ajouter des bases de données d’exploration ou de lien supplémentaires. Si nous voulons ajouter une autre base de données d’ exploration , nous pouvons utiliser l’ applet de commande New-SPEnterpriseSearchCrawlDatabase et lui donner l’application de recherche et le nom de la nouvelle base de données.

New-SPEnterpriseSearchCrawlDatabase -SearchApplication $sa -DatabaseName

SearchDB_CrawlStore_2

Nous pourrions également ajouter des bases de données Link supplémentaires à l’aide de l’applet de commande New-SPEnterpriseSearchLinks Database et en donnant le même ensemble de paramètres que nous l’avons fait pour la base de données d’analyse.

New-SPEnterpriseSearchLinksDatabase -SearchApplication $sa -DatabaseName

SearchDB_LinksStore_2

Ces bases de données apparaîtront alors sur la page Administration de la recherche de l’Administration centrale, sous la topologie illustrée à la figure 6-8 .

Figure 6-8. Plusieurs bases de données dans notre topologie de service de recherche

Avec notre topologie et nos bases de données toutes créées, il est maintenant temps de configurer les paramètres d’application du service de recherche.

6.5 Configuration des paramètres de recherche

Les possibilités de personnaliser votre application de service de recherche selon vos besoins sont infinies. Dans cette section, nous nous concentrerons sur les paramètres que vous devez effectuer lors de la première création de votre application de service de recherche.

6.5.1 Configuration du compte d’accès au contenu par défaut

La première chose que vous devez faire après avoir créé votre application de service de recherche est de configurer votre compte d’accès au contenu par défaut de recherche. Il s’agit du compte de service que le composant d’analyse utilisera pour accéder au contenu SharePoint. Ce compte d’analyse aura un accès en lecture à toutes vos applications Web SharePoint, il est donc important de conserver les informations d’identification dans un emplacement sûr. Par défaut, lors de la création de l’application de service de recherche, SharePoint définira le compte d’accès au contenu par défaut au service qui exécute le service Windows de recherche SharePoint. Pour le modifier, cliquez simplement sur le nom d’utilisateur actuellement dans la ligne du compte d’accès au contenu par défaut, comme illustré à la figure 6-9 . Une fenêtre s’ouvrira vous demandant le nom d’utilisateur et le mot de passe de ce compte.

Figure 6-9. Modifier le compte d’accès au contenu par défaut

Le compte d’accès au contenu par défaut peut également être configuré via PowerShell avec l’applet de commande suivante:

$sa = Get-SPEnterpriseSearchServiceApplication $content = New-Object Microsoft.Office.Server.Search.Administration.

Content($sa)

$content.SetDefaultGatheringAccount(“LAB\s-crawl”, (ConvertTo-SecureString “<Password>” -AsPlainText -Force))

Où Lab \ s-crawl est le compte que vous souhaitez utiliser comme compte d’accès au contenu par défaut. Étant donné que ce compte dispose d’un accès en lecture à tout le contenu SharePoint, nous vous recommandons d’avoir un compte de service dédié à cet effet, indiqué au chapitre 2.

Comme mentionné précédemment, le compte sera ajouté dans la stratégie utilisateur de l’application Web avec des autorisations de lecture complète, comme illustré à la figure 6-10.

Figure 6-10. Rechercher la stratégie d’application Web du compte d’exploration

Le compte d’accès au contenu par défaut doit également disposer du droit « Récupérer les données des personnes pour les robots de recherche » sur l’application de service de profil utilisateur, comme illustré à la figure 6-11.

Pour accéder à la page « Administrateurs de l’application de service de profil utilisateur », dans la page Gérer les applications de service, sélectionnez l’application de service de profil utilisateur, puis cliquez sur le bouton Administrateurs dans le ruban. Cela permettra au compte d’analyse d’explorer les profils utilisateur et de renvoyer ces informations dans la recherche.

Figure 6-11. Récupérer les données des personnes pour les autorisations des robots d’exploration de recherche

Avec le compte d’accès au contenu par défaut configuré, il est maintenant temps de créer nos sources de contenu.

6.5.2 Création de sources de contenu

La prochaine étape pour que notre application de service de recherche soit opérationnelle est de créer nos sources de contenu. Lors de la création d’une application de service de recherche, SharePoint crée une source de contenu appelée sites SharePoint locaux qui contient toutes les applications Web de notre batterie de serveurs, comme illustré à la figure 6-12.

Figure 6-12. Source de contenu des sites SharePoint locaux

Vous souhaiterez peut-être diviser ces applications Web en différentes sources de contenu si vous souhaitez définir différentes planifications d’analyse ou créer des résultats personnalisés basés sur une seule application Web. Pour créer une source de contenu, accédez à la page d’administration de la recherche dans l’administration centrale, puis à la page des paramètres des sources de contenu. Sur la page Gérer les sources de contenu, cliquez sur la page « Nouvelle source de contenu » illustrée à la figure 6-13.

Figure 6-13. Page Gérer les sources de contenu

Une fenêtre s’ouvre dans laquelle vous pouvez spécifier tous les paramètres de la source de contenu. Vous devez d’abord saisir un nom, dans notre exemple illustré à la figure 6-14, le nom est « SharePoint MySites ». Ensuite, nous devons sélectionner le type de contenu inclus dans cette source de contenu. Selon le choix du contenu, les configurations disponibles plus tard dans le processus seront différentes. Étant donné que le type d’élément que nous voulons explorer dans cette source de contenu est un site SharePoint, nous avons sélectionné « Sites SharePoint ».

Figure 6-14. Ajouter une source de contenu

Le contenu que vous entrez dans l’adresse de départ dépendra des paramètres d’analyse que vous sélectionnez dans la case à cocher suivante. La solution la plus simple à gérer consiste à saisir la racine de l’application Web dans l’adresse de démarrage et à sélectionner « Tout explorer sous le nom d’hôte pour chaque adresse de démarrage », comme nous l’avons fait dans la figure 6-15. De cette façon, SharePoint analysera toutes les collections de sites dans cette application Web et, à mesure que de nouvelles collections de sites seront ajoutées, elles seront automatiquement incluses dans cette source de contenu. Si vous utilisez des collections de sites nommées par l’hôte, il vous suffit d’inclure la collection de sites racine de l’application Web et SharePoint sera en mesure d’identifier les autres collections de sites dans les mêmes applications Web. Nous en apprendrons davantage sur les collections de sites nommés par l’hôte au chapitre 13.

Figure 6-15. Adresses de démarrage de la source de contenu et paramètres d’exploration

Si vous souhaitez avoir différentes planifications d’analyse entre les collections de sites dans la même application Web, vous devez sélectionner « Analyser uniquement la collection de sites de chaque adresse de démarrage » dans les paramètres d’exploration et entrer manuellement chaque URL de collection de sites dans les adresses de démarrage.

Enfin, vous aurez la possibilité de sélectionner votre calendrier d’exploration pour cette source de contenu. Votre calendrier d’exploration dépendra des besoins de votre entreprise ainsi que de vos capacités de recherche. Il existe deux types de planification différents pour votre contenu. La première qui existe depuis les dernières versions de SharePoint est l’analyse incrémentielle et complète. Le deuxième type de planification d’analyse est l’analyse continue, qui a été introduite dans SharePoint Server 2013. Examinons les différents types d’analyses :

Exploration complète

L’analyse complète est une analyse qui analysera l’intégralité du contenu de votre source de contenu, que l’élément existe déjà dans l’index ou non. L’analyse complète analysera non seulement le contenu, mais traitera également toutes les modifications apportées aux propriétés gérées, aux iFilters, ainsi qu’au service Web d’enrichissement de contenu, qui est une fonctionnalité de recherche que les développeurs peuvent utiliser pour personnaliser la recherche SharePoint. Étant donné que l’analyse complète analyse tout le contenu d’une source de contenu, sa durée est plus longue et elle est généralement exécutée moins souvent que l’analyse incrémentielle. Une analyse complète peut ne jamais être planifiée et s’exécuter uniquement manuellement pour traiter les modifications apportées aux personnalisations précédentes. Vous pouvez réduire le nombre de fois où une analyse complète est nécessaire en utilisant la fonctionnalité intégrée « Réindexer le site », disponible dans la page Paramètres du site de chaque site, sous Recherche et disponibilité hors ligne. Cela exécutera une analyse complète uniquement sur ce site spécifique, et non sur l’ensemble de votre source de contenu, et peut être utile lorsque vous devez simplement mettre à jour vos propriétés gérées ou le mappage des propriétés analysées.

Exploration incrémentielle

L’analyse incrémentielle est une analyse qui indexera uniquement le contenu qui a été modifié depuis la dernière fois qu’une analyse a été effectuée. La durée de cette analyse dépendra directement du nombre d’éléments modifiés depuis votre dernière analyse et est généralement beaucoup plus courte qu’une analyse complète. Cette analyse est généralement planifiée plusieurs fois au cours d’une journée et peut également être démarrée manuellement.

Exploration continue

L’analyse continue est un type qui vise à garder le contenu aussi frais que possible. Semblable à l’analyse incrémentielle, l’analyse continue n’analysera que les éléments qui ont été modifiés depuis la fin de la dernière analyse. La principale différence entre l’exploration continue et l’exploration incrémentielle est qu’en mode d’exploration continue, une analyse commencera toutes les 15 minutes, même si la dernière exploration ne s’est pas terminée. Si vous le souhaitez, vous pouvez personnaliser l’intervalle d’analyse de 15 minutes en exécutant l’applet de commande PowerShell suivante :

$sa = Get-SPEnterpriseSearchServiceApplication

$sa.SetProperty(“ContinuousCrawlInterval”,<TimeInMinutes>)

Où <TimeInMinutes> est l’intervalle, en minutes, de la fréquence à laquelle les analyses doivent être démarrées. Sachez que l’exploration continue, même avec le délai par défaut de 15 minutes, peut placer une très grosse charge sur votre infrastructure SharePoint. L’analyse continue est souvent utilisée pour les sites basés sur la recherche, où l’activité du site dépend fortement d’un nouvel index. Pour la source de contenu que nous avons créée dans cet exemple, nous avons choisi d’utiliser l’analyse continue comme illustré à la figure 6-16.

Figure 6-16. Horaires d’exploration

Pour créer un calendrier pour l’analyse complète, cliquez sur le lien Créer un calendrier sous la liste déroulante et une fenêtre contextuelle s’ouvrira vous permettant de créer un nouveau calendrier. À titre d’exemple, nous avons créé un calendrier dans la figure 6-17 , où l’analyse complète aura lieu tous les samedis à 2 heures du matin.

Figure 6-17. Calendrier d’exploration complet

Alors que la plupart des analyses complètes ne s’exécutent que très rarement, les analyses incrémentielles s’exécutent probablement plusieurs fois par jour. Pour définir un programme d’exploration à répéter pendant la journée, vous devez cocher la case « Répéter dans la journée ». Vous devrez ensuite saisir la fréquence à laquelle l’analyse doit être répétée et la durée. Dans l’exemple de la figure 6-18, nous démarrons une analyse toutes les 30 minutes, pendant 1440 minutes (24 h). Par conséquent, chaque jour, l’analyse s’exécute toutes les 30 minutes.

Figure 6-18. Horaire incrémentiel toutes les 30 minutes

Certaines entreprises situées sur un seul fuseau horaire peuvent souhaiter que les analyses incrémentielles ne se produisent que pendant les heures ouvrables, car il n’y a généralement pas d’activité pendant les heures creuses. En modifiant l’heure et la durée de début, vous pouvez configurer vos analyses incrémentielles pour qu’elles s’exécutent toutes les 30 minutes, de 6 h à 18 h, comme illustré à la figure 6-19. En définissant le champ Pour à 720 minutes (12 heures), aucune analyse ne démarrera après 18 heures et la prochaine analyse incrémentielle commencera à 6 heures le lendemain.

Figure 6-19. Planification de l’analyse incrémentielle entre 6 h et 18 h

Dans notre exemple de la figure 6-20, nous avons choisi d’activer l’analyse continue et d’effectuer une analyse complète tous les samedis, à partir de 2 heures du matin.

Figure 6-20. Calendrier d’exploration

Une fois la planification de l’analyse configurée, appuyez simplement sur OK et votre nouvelle source de contenu sera créée. Si vous avez choisi d’activer l’analyse continue, l’analyse démarrera immédiatement et si vous avez choisi Incrémentiel et Complet, l’analyse démarrera dans la prochaine période planifiée. Vous pouvez toujours démarrer manuellement l’analyse à partir du menu Source de contenu, comme illustré à la figure 6-21.

Figure 6-21. Menu Source de contenu

Si l’analyse continue est activée, le menu vous permet uniquement de désactiver l’analyse continue, comme illustré à la figure 6-22. Vous ne pourrez pas déclencher manuellement des analyses incrémentielles ou complètes.

Figure 6-22. Menu Source de contenu avec exploration continue activée

Un autre type populaire de source de contenu que vous voudrez peut-être créer est une source de contenu pour analyser les profils utilisateur des utilisateurs, de manière à ce que des informations importantes telles que les noms, les services, les compétences et les projets passés s’affichent dans la recherche. Nous avons déjà autorisé le compte d’analyse sur le service de profil utilisateur ; nous devons maintenant créer une source de contenu pour analyser les données des personnes. Le type de source de contenu sera toujours « Sites SharePoint » comme l’exemple précédent ; cependant, ce qui est un peu différent, c’est l’adresse de départ que nous devons saisir. L’adresse de départ pour la recherche de personnes doit être au format suivant : sps3: // <URL MySites>

Où <URL MySites> est l’URL de votre hôte MySites. Si votre application Web hôte MySites s’exécute sur HTTPS, vous devrez la démarrer avec sps3s au lieu de sps3, comme illustré ci -dessous :

sps3s: // <URL MySites>

Dans les deux cas, vous n’avez pas besoin d’entrer le http:// ou https:// devant le nom d’hôte.

Dans l’environnement de cet article, nous entrerions sps3s: //sp-my.cobaltatom.com comme adresse de départ, comme le montre la figure 6-23 .

Figure 6-23. Configuration de la recherche de personnes

Une fois nos sources de contenu créées, il est recommandé de créer un centre de recherche d’entreprise dans lequel les utilisateurs peuvent effectuer des recherches dans l’ensemble de la batterie de serveurs SharePoint.

6.5.3 Sécurité SharePoint et performances de recherche

La sécurité et la recherche SharePoint sont hautement connectées car les résultats de la recherche SharePoint sont limités par la sécurité. Cela signifie que les utilisateurs ne verront que les résultats de recherche auxquels ils sont autorisés à accéder et ne verront aucun résultat de recherche auquel ils ne sont pas autorisés à accéder. Chaque fois que les autorisations changent sur un élément, le moteur de recherche SharePoint devra effectuer une analyse de cet élément afin de traiter les nouvelles autorisations et de calculer la liste de contrôle d’accès (ACL) de cet élément.

Il existe deux stratégies principales d’attribution d’autorisations à un site SharePoint. La première consiste à ajouter chaque utilisateur individuellement dans un groupe SharePoint lorsqu’ils ont besoin d’accéder, et la deuxième consiste à donner accès à un groupe de sécurité Active Directory directement au site, ou à le placer dans un groupe SharePoint disposant d’autorisations sur le site.

La grande différence dans les performances de recherche est que, chaque fois que vous ajoutez un utilisateur directement à un groupe SharePoint, le robot devra effectuer une analyse de sécurité sur tous les éléments auxquels le groupe a accès afin de recalculer l’ACL du site.

La première fois que vous ajoutez un groupe Active Directory à un site SharePoint, le comportement sera le même ; cependant, lors de l’ajout d’autres utilisateurs à ce groupe Active Directory, SharePoint n’aura pas à recalculer la liste de contrôle d’accès, car aucun utilisateur n’a été ajouté directement dans le site SharePoint. En n’ayant pas à analyser à nouveau chaque élément pour recalculer la liste de contrôle d’accès, vos analyses seront plus courtes et augmenteront la fraîcheur de l’index.

Enfin, lors de la modification des politiques utilisateur au niveau de l’application Web, tout le contenu de cette application Web devra être analysé de nouveau pour les raisons précédentes. Ceci est indiqué en haut de la page Policy for Web Application (Figure 6-24).

Figure 6-24. La mise à jour de la stratégie d’application Web déclenchera une exploration de recherche SharePoint

6.5.4 Sélection du centre de recherche

Avant de sélectionner un centre de recherche d’entreprise, vous devez d’abord créer une collection de sites avec le modèle « Centre de recherche d’entreprise » ou, si vous le créez par PowerShell, le modèle SRCHCEN # 0. Une fois cette collection de sites créée, accédez à la page d’administration de l’application de service de recherche et, à partir de l’état du système, cliquez sur « Définir une URL de centre de recherche », comme illustré à la figure 6-25.

Figure 6-25. Définir un lien URL de centre de recherche

Une fenêtre contextuelle s’ouvre, semblable à la figure 6-26, dans laquelle vous devez saisir l’URL de votre collection de sites Enterprise Search Center que vous avez créée précédemment et ajouter / pages à la fin.

Figure 6-26. URL du centre de recherche

Vous pouvez également définir l’URL du centre de recherche à l’aide de PowerShell et en exécutant l’applet de commande suivante :

$ssa = Get-SPEnterpriseSearchServiceApplication

$ssa.SearchCenterUrl = “<Search Center URL>/pages”

$ssa.Update()

où “<Search Center URL>” est l’URL de votre collection de sites à l’aide du modèle Enterprise Search Center.

Une fois l’application de service de recherche configurée, examinons comment afficher ce qui a été analysé et s’il y a eu des erreurs lors de l’analyse du contenu.

6.6 Analyse des journaux d’analyse

L’application du service de recherche affiche les journaux d’exploration directement dans l’administration centrale, ce qui nous permet de voir si la recherche peut réussir à analyser nos sources de contenu et les erreurs qui pourraient empêcher le contenu d’accéder à l’index. Cela sera utile non seulement lors de la configuration de votre application de service de recherche pour la première fois, mais également comme vérification lors de la maintenance régulière. Les journaux d’exploration sont accessibles à partir du menu de navigation de gauche de la page Administration de la recherche, dans la catégorie Diagnostics, comme illustré à la figure 6-27.

Figure 6-27. Accès au journal d’exploration dans la page d’administration de la recherche

La vue par défaut de la page des paramètres du journal d’exploration de la figure 6-28 nous donne un aperçu de haut niveau de nos sources de contenu et des succès et avertissements. Les réussites sont le nombre d’éléments qui ont été correctement analysés et déplacés vers l’index, tandis que les avertissements sont des éléments qui n’ont pas pu être analysés ou qui ont été analysés, mais qui, pour certaines raisons, n’ont pas été placés dans l’index. La colonne Erreur inclut le nombre d’éléments individuels qui n’ont pas pu être placés dans l’index, tandis que la colonne Erreur de niveau supérieur est réservée aux erreurs critiques qui empêchent le composant d’analyse d’atteindre une source de contenu entière.

Figure 6-28. Page Journaux d’exploration

Lorsque vous cliquez sur l’un des nombres, SharePoint affiche le message ainsi que l’URL des éléments de cette catégorie. Dans la figure 6-29, nous pouvons voir les trois erreurs que nous avons dans le type de contenu SharePoint MySites et combien d’éléments ont été affectés par chaque erreur. Cela nous permettra de corriger facilement les erreurs et d’obtenir des éléments dans l’index lors de la prochaine analyse.

Figure 6-29. Journal d’analyse – Répartition des erreurs pour la source de contenu SharePoint MySites

L’accumulation de nombreuses erreurs au fil du temps augmentera la taille de votre base de données d’analyse, car toutes ces erreurs seront stockées à l’intérieur.

À partir de la page Journaux d’exploration de l’administration centrale, nous pouvons également rechercher des éléments spécifiques pour savoir s’ils ont été explorés ou non. Cela est utile lorsque les utilisateurs signalent que leurs documents n’apparaissent pas dans les résultats de recherche, même s’ils les ont téléchargés avant la dernière analyse. Pour rechercher les journaux d’exploration, à partir de la page Journal d’exploration, accédez à « Affichage URL » dans la barre supérieure. À partir de la page Vue URL, nous pouvons taper une URL ou un nom d’hôte dans la barre supérieure et utiliser des caractères génériques pour nous aider à trouver l’élément que nous recherchons. De plus, nous pouvons utiliser des filtres pour trouver uniquement les documents que nous recherchons. Comme vous le voyez dans la figure 6-30, un document de la bibliothèque que nous avons recherché comportait un avertissement, ce qui pourrait expliquer pourquoi il n’apparaissait pas dans les résultats de la recherche.

Figure 6-30. Journaux d’exploration des applications du service de recherche – Affichage URL

Dans certaines circonstances, pour actualiser nos résultats de recherche ou corriger une erreur, nous devons effectuer une réinitialisation d’index.

6.7 Réinitialisation de l’index

Dans certains cas, la seule façon de « réinitialiser » notre application de service de recherche est de supprimer tous les éléments de l’index et de réanalyser toutes les sources de contenu. C’est ce qu’on appelle une réinitialisation d’index. Pour effectuer une réinitialisation d’index, accédez à la page Administration de la recherche et, dans le menu de navigation de gauche, cliquez sur Réinitialisation d’index, comme illustré à la figure 6-31.

Figure 6-31. Bouton de réinitialisation d’index

Après la réinitialisation de l’index, aucun résultat de recherche ne sera disponible tant que ces éléments n’auront pas été analysés de nouveau ; par conséquent, si vous avez beaucoup de contenu ou si vous avez des sites dépendants de la recherche, exécutez-le de préférence pendant les heures creuses. Avant de réinitialiser l’index, vous aurez la possibilité de désactiver les alertes de recherche, afin de ne pas envoyer d’alertes à vos utilisateurs car de nouveaux éléments sont ajoutés à l’index. Si vous décidez de désactiver les alertes de recherche lors de la nouvelle exploration, n’oubliez pas de les activer manuellement une fois la première analyse complète terminée.

Lors de la gestion d’un index volumineux, la réinitialisation de l’index via l’interface utilisateur peut entraîner son expiration. Le moyen le plus simple d’éviter un délai d’expiration consiste à réinitialiser l’index à l’aide de PowerShell. Une réinitialisation d’index peut être effectuée avec les applets de commande suivantes :

$ sa = Get-SPEnterpriseSearchServiceApplication

$ sa.reset ($ true, $ true)

Où le premier paramètre $ true est de désactiver les alertes, et le deuxième paramètre $ true est d’ignorer une erreur de temporisation.

Pour estimer la durée de l’analyse complète, vous pouvez calculer le nombre d’éléments de votre index (éléments interrogeables) divisé par le taux d’exploration récent. Bien que ce ne soit pas une mesure exacte, c’est une bonne estimation. Dans la figure 6-32 , nous avons 581 éléments dans notre index et un taux d’exploration récent de 0,26 éléments par seconde.

Figure 6-32. Calcul du temps d’exploration complet

6.8 Prochaines étapes

Une fois l’application de service de recherche créée et notre contenu analysé, nous apprendrons dans le chapitre suivant comment configurer l’application de service de profil utilisateur.

7 CHAPITRE 7 Configuration du service de profil utilisateur

Le service de profil utilisateur est l’un des services principaux dans presque tous les déploiements SharePoint Server. Ce service fournit des informations sur les utilisateurs, OneDrive Entreprise, les fonctionnalités sociales et le public, entre autres fonctionnalités. Dans ce chapitre, nous allons passer en revue les options disponibles pour la synchronisation Active Directory, la configuration OneDrive Entreprise sur site, la configuration du public et enfin l’utilisation du client de synchronisation OneDrive Next Gen.

7.1 Configuration initiale

Nous avons effectué une configuration initiale de l’application de service de profil utilisateur au chapitre 3, où nous avons créé l’application de service de profil utilisateur et configuré l’hôte MySite avec un chemin géré / personal / wildcard et activé la création de sites libre-service. Nous devons configurer l’importation du profil utilisateur d’Active Directory dans SharePoint. SharePoint Server 2019 comprend uniquement l’importation Active Directory (importation AD), contrairement à SharePoint Server 2010 et 2013 qui comprenait le service de synchronisation de profil utilisateur. L’UPSS était basé sur Forefront Identity Manager. L’importation AD a quelques limitations, principalement parce qu’elle est uniquement importée, ce qui signifie aucune réécriture des attributs dans Active Directory, aucune suppression des profils utilisateur pour les utilisateurs qui ont été supprimés ou désactivés dans Active Directory, et elle n’importe pas les images de profil utilisateur. Bien que l’importation de photos puisse être effectuée via PowerShell, si l’un de ces scénarios est requis par votre batterie de serveurs, envisagez d’implémenter Microsoft Identity Manager 2016, qui sera abordé plus en détail plus loin dans ce chapitre.

Le compte de service de synchronisation de profil utilisateur, dans ce cas, LAB \ s-spsync, doit disposer de l’autorisation « Réplication des modifications d’annuaire » sur le domaine Active Directory avec lequel nous synchronisons. Pour accorder ce droit, cliquez avec le bouton droit sur la racine du domaine dans la console MMC Utilisateurs et ordinateurs Active Directory, puis procédez au démarrage de l’Assistant Délégation. Dans la première étape, ajoutez le compte de synchronisation (LAB \ s-spsync), puis créez une tâche personnalisée à déléguer. Pour le type d’objet Active Directory, laissez l’option par défaut « Ce dossier, les objets existants dans ce dossier et la création de nouveaux objets dans ce dossier ». À la dernière étape, sélectionnez les autorisations nommées « Réplication des modifications de répertoire », comme illustré à la figure 7-1. Ceci termine le processus de délégation.

Figure 7-1. Ajout des autorisations appropriées dans Active Directory pour le compte de synchronisation

Si le nom de domaine NetBIOS ne correspond pas au nom de domaine complet, c’est-à-dire si le nom NetBIOS était EXEMPLE alors que le nom de domaine complet était CORP. COMPANY.COM, une étape supplémentaire est nécessaire à l’aide de la modification ADSI (adsiedt.msc). Bien que ce ne soit pas le cas pour ce domaine d’environnements, à l’aide d’ADSI Edit, connectez-vous au contexte de dénomination de la configuration. Comme le montre la figure 7-2, cliquez avec le bouton droit sur le noeud Configuration (indiqué comme

«CN = Configuration, DC = LAB, DC = COBALTATOM, DC = COM»), puis sélectionnez Propriétés (notez que si vous utilisez Microsoft Identity Manager, effectuez cette étape indépendamment d’une incompatibilité entre le nom NetBIOS et le FQDN). À partir d’ici, sélectionnez l’onglet Sécurité, ajoutez le compte de synchronisation et accordez les mêmes autorisations, comme illustré à la figure 7-3 .

Figure 7-2. Utilisation d’ADSI Edit en étant connecté au contexte de dénomination de la configuration

Figure 7-3. Ajout du compte de synchronisation avec le « répertoire de réplication

Modifications » autorisation

Une fois terminé, nous pouvons continuer à créer la connexion de synchronisation à partir de l’administration centrale de SharePoint.

En naviguant dans l’Administration centrale pour gérer les applications de service, cliquez sur le

Application de service de profil utilisateur créée précédemment. Allez dans Configurer les connexions de synchronisation et cliquez sur Créer une nouvelle connexion. Il ne doit y avoir qu’une seule connexion par forêt Active Directory. Fournissez un nom de connexion approprié, tel que le nom de la forêt. Vous remarquerez que la seule option disponible pour Type est désormais AD Import. Fournissez le nom de domaine complet pour le domaine racine de la forêt et le nom de compte au format DOMAINE \ Nom d’utilisateur et entrez le mot de passe. Étant donné que nous avons déployé des serveurs de certificats Active Directory et que notre contrôleur de domaine possède un certificat d’authentification de serveur valide, nous changerons le numéro de port en 636 et vérifierons

Utilisez une connexion sécurisée SSL. Si les contrôleurs de domaine n’ont pas de certificats installés, tels qu’un contrôleur de domaine ou un certificat d’authentification Kerberos provenant d’un serveur des services de certificats Microsoft Active Directory, laissez le port par défaut 389 et Utiliser SSL décoché. Nous ne voulons pas non plus que les utilisateurs handicapés soient importés et cocherons également cette case. Ajoutez un filtre LDAP si nécessaire ; par exemple, pour filtrer les objets informatiques, le filtre serait le suivant :

(! objectClass = ordinateur)

La configuration de la connexion est terminée, comme le montre la figure 7-4.

Figure 7-4. La connexion AD Import

Cliquez sur Remplir les conteneurs. Contrairement à l’importation précédente du service de synchronisation de profil utilisateur, AD Import importera tous les objets dans le service de profil utilisateur. Il est recommandé de ne sélectionner que les conteneurs spécifiques dont vous avez besoin, à savoir ceux contenant des utilisateurs et des groupes. Les groupes seront importés pour être utilisés dans Audiences.

Comme la structure de notre unité d’organisation n’est pas compliquée, nous ne sélectionnerons que quelques conteneurs, comme illustré à la figure 7-5.

Figure 7-5. Sélection des unités d’organisation pour importer des utilisateurs et des groupes

Une fois la sélection de l’unité d’organisation terminée, cliquez sur OK et la connexion de synchronisation sera créée. Revenez à la page Gérer le service de profil et cliquez sur Démarrer la synchronisation du profil. Démarrez une synchronisation complète. Le temps nécessaire à cette importation varie en fonction du nombre d’objets que vous synchronisez. La synchronisation commencera sous peu et sous l’état de synchronisation sur le côté droit, vous le verrez passer à la synchronisation lors de l’actualisation de votre navigateur.

Si vous ne voyez pas de profils supplémentaires une fois le processus d’importation terminé, vérifiez les journaux ULS sur le serveur sur lequel le travail du minuteur s’est exécuté. À l’aide de SharePoint Management Shell, nous pouvons obtenir le travail du minuteur et examiner les entrées d’historique.

$job = Get-SPTimerJob | ?{$_.TypeName -like “*.UserProfileADImportJob”}

$job.HistoryEntries | Select -First 1

Ici, examinez la valeur ServerName pour le dernier emplacement sur lequel le travail du minuteur s’est exécuté. Convertissez l’heure de début et de fin UTC dans votre fuseau horaire local.

$historyEntry = $job.HistoryEntries | Select -First 1

$historyEntry.StartTime.ToLocalTime()

$historyEntry.EndTime.ToLocalTime()

Une fois que vous avez rassemblé les entrées ULS appropriées, examinez-les pour « Échec de l’importation DirSync ». Ici, vous verrez une trace de pile qui contiendra le message d’erreur. Par exemple :

ActiveDirectory Import: DirSync import failed: ScanDirSyncChanges: Exception thrown by Dirsync request: page 0, LdapServer ‘CADC01.LAB.COBALTATOM.

COM:636’, rootDn ‘DC=LAB,DC=COBALTATOM,DC=COM’, exception ‘System.

DirectoryServices.Protocols.LdapException: The search filter is invalid.

Dans ce cas particulier, nous savons que nous devons modifier notre filtre LDAP car la syntaxe est incorrecte. D’autres erreurs peuvent inclure des problèmes de connectivité, tels que des délais d’attente ou des autorisations incorrectes. Il existe de nombreux outils gratuits pour valider la syntaxe LDAP disponibles sur Internet que vous pouvez utiliser avant d’ajouter un nouveau filtre.

Une fois le filtre corrigé, réexécutez votre importation AD et validez que les utilisateurs appropriés sont importés dans le service de profil utilisateur.

La connexion de synchronisation peut également être configurée à l’aide de PowerShell, avec la cmdlet Add-SPProfileSyncConnection.

$sa = Get-SPServiceApplication | ?{$_.TypeName -eq “User Profile Service

Application”}

Add-SPProfileSyncConnection-ProfileServiceApplication $sa

-ConnectionForestName “lab.cobaltatom.com” -ConnectionDomain “LAB”

-ConnectionUserName “s-spsync” -ConnectionPassword (ConvertTo-SecureString

“” -AsPlainText -Force) -ConnectionPort 636 -ConnectionUseSSL

$true -ConnectionUseDisabledFilter $true -ConnectionSynchronizationOU

“OU=Employees,DC=LAB,DC=COBALTATOM,DC=COM”

Cela créera la même connexion de synchronisation que celle illustrée ci-dessus; toutefois, si des unités d’organisation supplémentaires sont nécessaires ou si un filtre LDAP supplémentaire est requis, ajoutez-les via l’administration centrale. Notez que le paramètre -ConnectionUserName n’attend que le sAMAccountName, pas la valeur complète DOMAIN \ Username.

Une fois la configuration d’importation AD terminée, examinons la deuxième option pour importer des profils utilisateur.

7.2 Configuration externe d’Identity Manager

La configuration d’un gestionnaire d’identité externe nécessite un investissement en temps beaucoup plus important.

Il existe Microsoft Identity Manager, qui prend en charge Active Directory et le service de profil utilisateur SharePoint, ainsi que de nombreux autres types d’annuaire et solutions personnalisées.

La configuration initiale nécessite de modifier l’application de service de profil utilisateur pour utiliser un gestionnaire d’identité externe. Ceci est défini via les paramètres de synchronisation de configuration dans l’application de service de profil utilisateur, comme illustré à la figure 7-6. Sélectionnez l’option « Activer External Identity Manager ».

Figure 7-6. Activation du gestionnaire d’identité externe pour SharePoint Server 2016

Une fois défini, l’application de service de profil utilisateur affichera qu’elle utilise maintenant un gestionnaire d’identité externe, comme illustré à la figure 7-7.

Figure 7-7. Le gestionnaire d’identité externe est activé pour cette application de service de profil utilisateur

Avec Microsoft Identity Manager, nous avons seulement besoin d’installer le service de synchronisation. Ce service fournit une synchronisation entrante et sortante entre de nombreuses plates-formes d’annuaire et de données d’entreprise différentes.

Microsoft fournit la documentation d’installation de Microsoft Identity Manager (MIM). Si possible, MIM doit être installé sur un serveur dédié.

Remarque La documentation pour l’installation de Microsoft Identity Manager 2016 est disponible sur http://aka.ms/UserProfileMIMSync .

Pour installer MIM sur Windows Server 2016 à l’aide de l’instance de cluster de basculement AlwaysOn SQL Server 2016, le serveur MIM doit d’abord avoir .NET 3.5 Framework et SQL 2008 R2 ou 2012 Native Client installés. En outre, pour prendre en charge le connecteur SharePoint, MIM doit avoir au moins la version 4.3.2064.0, mais envisagez d’utiliser les correctifs Service Pack 1 et postérieurs au Service Pack 1.

Remarque La version 4.3.2064.0 est disponible sur https://support.microsoft.com/ help / 3092179 .

Installez le magasin de profils utilisateur du connecteur Forefront Identity Manager pour SharePoint, disponible sur www.microsoft.com/en-us/download/details.aspx?id=41164 , sur le serveur MIM. Il s’agit de l’agent de gestion, qui se connectera au service de profil utilisateur SharePoint.

La solution MIM de synchronisation de profil utilisateur comprend un module PowerShell, SharePointSync.psm1, pour configurer les agents de gestion Active Directory et SharePoint. Cela s’exécutera sur le serveur MIM.

Notez que la solution de synchronisation de profil utilisateur est disponible sur https://github.com/ OfficeDev / PnP-Tools / tree / master / Solutions / UserProfile.MIMSync .

À partir d’une console PowerShell élevée, accédez à l’emplacement extrait du module. Pour configurer cela, il faudra deux comptes, le compte créé précédemment avec Replicate Directory Changes ainsi que le compte Administrateur de batterie pour se connecter au service de profil utilisateur.

$syncCred = Get-Credential “LAB\s-spsync”

$farmCred = Get-Credential “LAB\s-farm”

Import-Module C:\SharePointSync\SharePointSync.psm1

Install-SharePointSyncConfiguration -Path C:\SharePointSync -ForestDnsName “LAB.COBALTATOM.COM” -ForestCredential $syncCred -OrganizationalUnit “OU=HQ,DC=LAB,DC=COBALTATOM,DC=COM” -SharePointUrl https://cal.lab.cobaltatom.com -SharePointCredential $farmCred

Avant d’exécuter la synchronisation, vous devez définir le mot de passe du compte de synchronisation sur l’agent de gestion «ADMA». À l’aide du gestionnaire de services de synchronisation, accédez à l’onglet Agents de gestion. Double-cliquez sur l’agent de gestion «ADMA». Cliquez sur la section «Se connecter à la forêt Active Directory» et saisissez le mot de passe du compte de synchronisation, comme illustré dans la figure 7-8 . Cliquez sur OK pour enregistrer les machines.

Figure 7-8. Définition du mot de passe pour le compte de synchronisation Active Directory dans l’agent de gestion Active Directory

Comme notre configuration initiale de SharePoint impose l’utilisation de TLS 1.2, nous devons importer les entrées de registre suivantes et redémarrer le serveur MIM avant de démarrer le processus de synchronisation initial.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]

“SchUseStrongCrypto”=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]

“SchUseStrongCrypto”=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]

“SchUseStrongCrypto”=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]

“SchUseStrongCrypto”=dword:00000001

La synchronisation peut être exécutée via PowerShell après l’importation du fichier SharePointSync.psm1.

Start-SharePointSync -Confirm:$false

La surveillance du processus de synchronisation peut être effectuée à partir de la synchronisation

Service Manager, qui est installé dans C: \ Program Files \ Microsoft Forefront Identity Manager \ 2010 \ Synchronization Service \ UIShell \ miisclient.exe. L’onglet Opérations affichera la progression des deux agents de gestion, ADMA (Active Directory) et SPMA (SharePoint). Toutes les erreurs seront notées dans la colonne Statut.

Une fois la synchronisation complète terminée, vous pouvez alors commencer à utiliser la synchronisation delta. Encore une fois, à l’aide du module SharePointSync.psm1, exécutez ce qui suit:

Start-SharePointSync -Delta -Confirm:$false

Le processus delta doit être plus rapide que la synchronisation complète. Notez que, comme pour le service de synchronisation de profil utilisateur précédent, toute modification des propriétés nécessite une synchronisation complète. Dans la figure 7-9, nous voyons un processus d’importation complète terminé avec succès et une importation Delta ultérieure terminée avec succès.

Figure 7-9. Une course complète suivie d’une course Delta

Bien que ce processus importe des photos de profil, les photos de profil devront être converties en petites, moyennes et grandes photos. Pour ce faire, configurez une tâche planifiée qui exécute l’applet de commande suivante sur l’hôte MySite. Cette opération doit être exécutée sur un serveur SharePoint de la batterie de serveurs qui exécute l’instance du service de profil utilisateur par un utilisateur disposant de droits d’administration sur l’application de service de profil utilisateur et de droits d’administrateur de shell.

Add-PSSnapin Microsoft.SharePoint.PowerShell -EA 0

Update-SPProfilePhotoStore -MySiteHostLocation https://sp-my.cobaltatom.com

-CreateThumbnailsForImportedPhotos 1

Cette cmdlet peut prendre un certain temps à compléter en fonction du nombre de photos de profil utilisateur à convertir.

7.2.1 Configuration de propriétés d’importation supplémentaires

Pour configurer des propriétés d’importation supplémentaires à importer dans SharePoint, il faudra modifier le service de profil utilisateur dans SharePoint, l’agent de gestion SharePoint et l’agent de gestion Active Directory dans Microsoft Identity Manager. Nous allons créer une propriété nommée «Société» qui tire de l’attribut Active Directory nommé «société».

Dans l’application de service de profil utilisateur, sous Gérer les propriétés utilisateur, créez la propriété avec les paramètres applicables, ou dans notre cas, une chaîne avec une limite de 64 caractères. La limite de la valeur peut être trouvée dans la console MMC Active Directory Schema Manager. Pour afficher le schéma Active Directory, vous devez d’abord enregistrer schmmgmt.dll.

regsvr32.exe C: \ Windows \ System32 \ schmmgmt.dll

À partir de là, ouvrez mmc.exe et ajoutez le composant logiciel enfichable nommé « Schéma Active Directory ». Dans le nœud Attributs, recherchez l’attribut cible ou la société dans ce cas. La visualisation des propriétés de l’attribut vous indiquera les contraintes de l’attribut, comme le montre la figure 7-10.

Figure 7-10. Utilisation du gestionnaire de schéma Active Directory, montrant l’attribut de l’entreprise

Dans le Gestionnaire de services de synchronisation Microsoft Identity Manager, accédez à l’onglet Agents de gestion. Ouvrez l’agent de gestion des services de domaine Active Directory (nommé ADMA). Sous Sélectionner les attributs, sélectionnez l’attribut Active Directory approprié, ou «société» dans notre cas. L’étape suivante consiste à configurer le flux d’attributs. Sélectionnez le type d’objet approprié ou, dans ce cas, le type d’objet «utilisateur» qui correspond au type d’objet «personne», comme le montre la figure 7-11 .

Figure 7-11. Création d’un flux d’attributs pour « entreprise » dans Active Directory

Agent de gestion

Une fois terminée, l’étape suivante consiste à actualiser le schéma sur l’agent de gestion SharePoint. Sous l’onglet Agents de gestion, cliquez avec le bouton droit sur l’agent de gestion SharePoint et sélectionnez Actualiser le schéma. Vous serez invité à saisir le mot de passe de l’utilisateur configuré pour se connecter à l’administration centrale. La mise à jour du schéma prendra quelques secondes. À ce stade, il est temps de modifier le nouvel attribut de société pour l’importer dans SharePoint. Modifiez donc l’agent de gestion SharePoint et accédez à Sélectionner les attributs. Sélectionnez le nouvel attribut « Société », puis passez à Configurer le flux d’attributs. Nous modifions l’utilisateur de type d’objet à partir de la personne de type d’objet. Ajoutez un nouveau flux pour la société, comme illustré à la figure 7-12. Notez que nous devons sélectionner « Autoriser les valeurs nulles » car cette propriété peut ne pas avoir de valeur pour chaque utilisateur du répertoire.

Figure 7-12. Importation de l’attribut d’entreprise dans SharePoint

Maintenant, lancez une importation complète, et c’est tout ! Le nouvel attribut Société sera rempli pour les utilisateurs qui ont cette propriété remplie dans Active Directory.

7.2.2 Configuration des propriétés d’exportation

Pour exporter des propriétés, nous autoriserons les utilisateurs à entrer leur propre numéro de téléphone personnel. Nous devons créer une nouvelle propriété Service de profil utilisateur d’une chaîne, avec une longueur de 256 caractères, qui correspond à la valeur de l’attribut homePhone telle qu’elle est affichée via le gestionnaire de schéma Active Directory. Comme nous voulons écrire cet attribut, nous devons fournir à notre compte de service de synchronisation, LAB \ s-spsync, la possibilité de réécrire cet attribut aux comptes d’utilisateurs dans Active Directory. Pour cela, nous allons à nouveau démarrer l’Assistant Contrôle de délégation via Utilisateurs et ordinateurs Active Directory, en choisissant le compte de service de synchronisation et une tâche personnalisée à déléguer. Nous déléguerons uniquement le contrôle aux objets Utilisateur et le droit d’écrire sur l’attribut Téléphone personnel, comme illustré à la figure 7-13.

Figure 7-13. Octroi à LAB \ s-spsync d’un accès en écriture à l’attribut Téléphone personnel

En arrière, dans le Gestionnaire de services de synchronisation Microsoft Identity Manager, modifiez l’agent de gestion SharePoint. Sélectionnez l’attribut HomePhone sous Sélectionner un attribut, puis configurez un flux d’attributs pour importer l’attribut HomePhone de SharePoint dans le métaverse des objets utilisateur, comme illustré à la figure 7-14. La flèche directionnelle pointe de l’agent de gestion SharePoint vers le métaverse Microsoft Identity Manager.

Figure 7-14. Importation de l’attribut HomePhone de SharePoint dans le métaverse

Astuce si vous avez créé une propriété de profil utilisateur personnalisé, actualisez le point de partage

Schéma de l’agent de gestion, sinon il n’apparaîtra pas dans la liste des attributs sélectionnés.

En passant à l’agent de gestion Active Directory, sélectionnez à nouveau l’attribut homePhone dans Sélectionner les attributs. Sous Configurer les flux d’attributs, pour le type d’objet d’utilisateur, exportez l’attribut homePhone du métaverse dans l’attribut homePhone dans Active Directory, en autorisant les valeurs nulles (car tous les utilisateurs n’ont peut-être pas rempli le champ), comme le montre la figure 7-15 .

Figure 7-15. Exportation de homePhone du métaverse vers Active Directory

La configuration des agents de gestion ne crée pas de flux d’attributs d’exportation pour Active Directory. Cela signifie que, par défaut, nous ne pouvons pas écrire d’attributs dans Active Directory.

Pour configurer un profil d’exécution d’exportation, sous l’onglet Agents de gestion, mettez en surbrillance l’agent de gestion Active Directory et sélectionnez Configurer les profils d’exécution. Créez un nouveau profil nommé Exporter et pour le type d’étape, sélectionnez Exporter. Complétez le profil d’exécution. Lorsque vous cliquez sur Exécuter pour l’agent de gestion Active Directory, l’exportation est désormais une option. Exécutez l’exportation et si les autorisations sont correctement configurées, l’attribut homePhone sera écrit avec la valeur entrée par un utilisateur à partir de son profil utilisateur dans SharePoint.

Le profil d’exécution d’exportation ADMA peut également être démarré avec PowerShell en important SharePointSync.psm1 et en utilisant Start-ManagementAgent.

Import-Module .\SharePointSync.psm1

Start-ManagementAgent -Name ADMA -RunProfile Export

Maintenant que nous savons comment importer et exporter des profils depuis et vers SharePoint Server, examinons les propriétés personnalisées qui peuvent ne pas exister dans le métaverse.

7.2.3 Propriétés personnalisées

Pour prendre en charge les propriétés personnalisées d’Active Directory ou du service de profil utilisateur SharePoint, il peut être nécessaire de créer un nouvel attribut dans le métaverse Microsoft Identity Manager. Cela peut être accompli sous le concepteur Metaverse. Le type d’objet ne sera très probablement « personne ». Lorsque vous mettez en surbrillance une personne, les attributs existants appartenant à ce type d’objet dans le métaverse apparaissent ci-dessous. À partir de là, il est possible d’ajouter des attributs supplémentaires au métaverse ou de créer de nouveaux attributs dans le métaverse, comme le montre la figure 7-16. Une fois l’attribut ajouté au métaverse, il est traité comme tout autre attribut en termes de synchronisation vers et depuis les agents de gestion.

Figure 7-16. Ajout d’un nouvel attribut au métaverse Microsoft Identity Manager

Une fois notre propriété personnalisée dans Microsoft Identity Manager créée, jetez un coup d’œil aux audiences et comment les configurer dans SharePoint.

7.3 Public

Les audiences sont utilisées pour étendre certains contenus, tels que les composants WebPart SharePoint, à un certain ensemble d’utilisateurs. Le public est puissant en ce qu’il permet de créer diverses règles pour définir qui doit leur appartenir. Une mise en garde du public est qu’il ne s’agit pas de limites de sécurité. Le contenu caché par un public est toujours visible par un client. Par défaut, les audiences ne sont également compilées qu’une fois par semaine le samedi à 1 h du matin. Cela peut être ajusté pour être plus fréquent, bien qu’il ait été défini spécifiquement sur un jour par semaine pour des considérations de performances.

Afin de configurer une audience, l’audience est créée sous Gérer les audiences dans l’application de service de profil utilisateur. Vous définissez ici les règles qui étendent l’audience à des utilisateurs spécifiques. Dans cet exemple, comme le montre la figure 7-17, nous créons une audience de chefs de projet contenant tous les utilisateurs qui ont un titre de poste de « chef de projet ».

Figure 7-17. Un public nouvellement créé

Une fois compilé, comme le montre la figure 7-18, le nombre de membres correspondant aux règles, ainsi que les erreurs survenues lors de la compilation de l’audience, seront affichés. À ce stade, l’audience peut être utilisée sur le contenu SharePoint pour étendre le contenu à l’ensemble spécifique d’utilisateurs.

Figure 7-18. Le public des chefs de projet compilés

7.4 OneDrive Entreprise

OneDrive Entreprise, également connu sous le nom de MySite, est un emplacement où l’utilisateur peut télécharger des documents pour un usage personnel et un partage limité. Il s’agit également d’un emplacement où l’utilisateur peut mettre à jour son profil utilisateur et créer des articles dans son blog. Deux fonctionnalités notables ne sont plus disponibles : le fil d’actualités de la société, qui est désormais en lecture seule, les tâches ou la fonctionnalité d’agrégation de tâches disponible dans SharePoint Server 2013 car l’application de service de gestion du travail n’est plus disponible.

Les paramètres MySite ont été configurés au chapitre 3, mais peuvent être ajustés à partir de l’application de service de profil utilisateur sous Configurer mes sites. Par exemple, vous pouvez ajouter un centre de recherche préféré ou modifier le format de dénomination du site. Notez que la modification du format de dénomination du site entraînera la migration de toutes les collections de sites MySite vers le nouveau format de dénomination, qui peut être une opération lourde d’E / S disque.

Éléments récemment partagés est une nouvelle fonctionnalité pour SharePoint sur site qui affiche les éléments récemment partagés avec vous. Il ne peut être activé que via SharePoint Management Shell. L’URL spécifiée dans cette applet de commande est l’URL de l’hôte MySite.

Enable-SPFeature “RecentSharedItems” -Url https://sp-my.cobaltatom.com

Pour configurer le client OneDrive Next Gen Sync sur les ordinateurs clients, nous devons d’abord obtenir les fichiers de stratégie de groupe (ADMX et ADML) à partir du client de synchronisation OneDrive. Ceux-ci peuvent être trouvés dans% LocalAppData% \ Microsoft \ OneDrive \ \ adm. Copiez OneDrive.admx dans les définitions de stratégie SYSVOL (par exemple \\lab.cobaltatom.com\SYSVOL\lab.cobaltatom.com\Policies\PolicyDefinitions) et OneDrive.adml dans le dossier en-US au même emplacement (copiez une autre langue Fichiers ADML selon les besoins). Une fois les deux fichiers copiés, ouvrez la gestion des stratégies de groupe et modifiez une stratégie existante ou créez une nouvelle stratégie pour appliquer les paramètres OneDrive. Sous Configuration ordinateur, Stratégies, Modèles d’administration, OneDrive, modifiez la stratégie « URL du serveur SharePoint local et nom du dossier du locataire ». Définissez l’URL vers l’emplacement de l’hôte OneDrive (MySite) et fournissez un nom logique pour le dossier tel qu’il apparaîtra dans l’Explorateur Windows (ce nom de dossier peut avoir n’importe quelle valeur), comme illustré dans la figure 7-19.

Figure 7-19. Définition de l’emplacement de l’hôte OneDrive et fourniture d’un nom de dossier

Lorsque OneDrive démarre, au lieu de saisir une adresse e-mail, vous saisissez vos informations de connexion Windows, comme illustré à la figure 7-20.

Figure 7-20. Connexion à OneDrive lorsqu’il est utilisé avec SharePoint Server 2019

Une fois terminé, comme illustré à la figure 7-21, vous verrez l’emplacement où résident vos fichiers OneDrive.

Figure 7-21. L’achèvement de la configuration OneDrive avec SharePoint

Serveur 2019

Comme avec SharePoint Online, il est également possible de synchroniser les bibliothèques de documents à l’aide du client OneDrive Next Gen Sync avec SharePoint Server 2019. Appuyez simplement sur le bouton « Sync » dans la barre de commandes de la bibliothèque de documents et OneDrive configurera automatiquement le processus de synchronisation pour vous.

7.5 Prochaines étapes

Dans ce chapitre, nous avons couvert l’application de service de profil utilisateur, y compris la façon de gérer l’importation AD ainsi que de travailler avec Microsoft Identity Manager. Dans le chapitre suivant, nous examinerons les applications de service de productivité, telles que les services d’accès, les métadonnées gérées et autres.

8 CHAPITRE 8 Configuration des applications du service de productivité

Dans les chapitres précédents, nous avons déjà appris à configurer certaines applications de service telles que la recherche et le profil utilisateur ainsi que les applications de gestion des applications et des services d’abonnement.

SharePoint Server 2019 comprend d’autres applications de service qui ajoutent de nombreuses autres fonctionnalités à SharePoint 2019, ce qui peut augmenter la productivité de vos utilisateurs.

Dans ce chapitre, nous apprendrons à configurer l’application de service de métadonnées gérées, les services de connectivité d’entreprise, les services d’automatisation Word, le service d’automatisation PowerPoint, le service graphique Visio, les services de traduction automatique et enfin les services d’accès.

8.1 Application de service de métadonnées gérées

L’application de service de métadonnées gérées est l’une des applications de service les plus populaires déployées avec SharePoint. Cette application de service permet d’utiliser des métadonnées gérées et de partager des types de contenu entre des collections de sites et des applications Web. Les métadonnées gérées sont un référentiel central qui stocke votre taxonomie des informations dans une vue hiérarchique. Il existe deux façons de créer cette application de service, l’administration centrale ou PowerShell.

Pour créer l’application de service de métadonnées gérées à l’aide de l’administration centrale, dans la page Gérer les applications de service, cliquez sur Nouveau dans le ruban, puis sélectionnez Application de service de métadonnées gérées. Une fenêtre s’ouvre semblable à la figure 8-1, dans laquelle vous devez saisir le nom de votre application de service de métadonnées gérées ainsi que le serveur de base de données et le nom de la base de données sur lesquels vous souhaitez la déployer.

Figure 8-1. Créer un nouveau service de métadonnées gérées, partie 1

En faisant défiler jusqu’à la fin de la fenêtre Nouveau service de métadonnées gérées illustré à la figure 8-2, nous devons sélectionner le pool d’applications sur lequel héberger cette application de service. Sauf si vous avez des exigences commerciales nécessitant que cette application de service soit isolée des autres, nous vous recommandons de la placer dans le même pool d’applications de service que le reste de vos applications de service pour une meilleure gestion des ressources et de meilleures performances du serveur. Dans notre environnement, ce pool d’applications est nommé SharePoint Web Services Default. Enfin, vous pouvez éventuellement saisir l’URL du concentrateur de type de contenu. Le Content Type Hub est un emplacement central où vous pouvez gérer et publier vos types de contenu. D’autres collections de sites peuvent s’abonner à ce hub et dérouler les types de contenu publiés et même recevoir des mises à jour lorsque vous mettez à jour les types de contenu dans le hub de type de contenu. Il n’y a pas de modèle de collection de sites spécial pour le concentrateur de type de contenu, et c’est généralement un modèle de site d’équipe qui est utilisé pour le concentrateur de type de contenu. Le concentrateur de type de contenu peut également être configuré après la création de l’application de service de métadonnées gérées. Les erreurs d’importation de la syndication de rapports à partir des collections de sites utilisant cette application de service signaleront les erreurs d’importation dans le journal des erreurs de publication du type de contenu, accessible à partir de la page Paramètres du site de la collection de sites.

Figure 8-2. Créer une nouvelle application de service de métadonnées gérées, partie 2

Enfin, vous pouvez cliquer sur OK et l’application de service sera créée. L’application de service de métadonnées gérées peut également être créée par PowerShell à l’aide de l’applet de commande New-SPMetadataServiceApplication. Pour créer l’application de service avec les mêmes paramètres que ceux utilisés lors de la création à l’aide de l’Administration centrale, nous exécuterions l’applet de commande suivante dans un environnement de gestion SharePoint élevé :

$sa = New-SPMetadataServiceApplication -Name “Managed Metadata Service”

-DatabaseName “MMS” -ApplicationPool “SharePoint Web Services Default”

-SyndicationErrorReportEnabled

Lors de la création de l’application de service par l’interface utilisateur, SharePoint créera également le proxy d’application de service automatiquement ; cependant, ce n’est pas le cas de PowerShell. L’étape suivante consistera à créer le proxy d’application de service à l’aide de l’applet de commande New-SPMetadataServiceApplicationProxy. Dans notre exemple, nous exécuterions l’applet de commande PowerShell suivante :

New-SPMetadataServiceApplicationProxy -Name “Managed Metadata

Service Proxy” -ServiceApplication $sa -DefaultProxyGroup

-ContentTypePushdownEnabled -DefaultKeywordTaxonomy

-DefaultSiteCollectionTaxonomy

Nous avons ajouté le commutateur -DefaultProxyGroup pour spécifier que ce service

Le proxy d’application fera partie du groupe de proxy par défaut de la batterie de serveurs. Ensuite, le commutateur -ContentTypePushdownEnabled spécifie que les instances existantes des types de contenu modifiés dans les sous-sites et les bibliothèques seront mises à jour. Le commutateur -DefaultKeywordTaxonomy spécifie que les mots clés d’entreprise seront stockés dans cette application de service, et enfin le commutateur -DefaultSiteCollectionTaxonomy spécifie que lorsque les utilisateurs créent des colonnes de métadonnées gérées dans une collection de sites, le terme sera enregistré dans cette application de service.

Notez que les options précédentes ne sont pas dans le formulaire lors de la création de l’application de service de métadonnées gérées à l’aide de l’administration centrale. pour accéder à ces options à partir de l’administration centrale, sélectionnez le proxy du service de métadonnées gérées dans la page d’application Gérer le service, puis cliquez sur les propriétés comme illustré à la figure 8-3 .

Figure 8-3. Gérer les propriétés du proxy du service de métadonnées

Pour les deux options de création de l’application de service, si vous exécutez une batterie de serveurs qui utilise le modèle MinRole, le service de métadonnées gérées sera automatiquement démarré sur tous les serveurs exécutant le Web Front End ou les rôles d’application. Si vous exécutez une batterie en mode personnalisé, assurez-vous de démarrer manuellement le service Web de métadonnées gérées sur au moins un serveur de votre batterie.

Une fois l’application de service de métadonnées gérées créée, vous pouvez désormais créer des termes gérés que les utilisateurs peuvent utiliser dans l’ensemble de votre batterie de serveurs SharePoint. Pour configurer le concentrateur de type de contenu, vous pouvez créer une collection de sites avec un modèle de site d’équipe qui sera utilisé à cette fin. Nous l’avons créé à l’aide de l’applet de commande PowerShell suivante:

New-SPSite -Url https://sp.cobaltatom.com/sites/ContentTypeHub -Template

STS#0 -Name “Content Type Hub ” -OwnerAlias “LAB\vlad.catrinescu”

Ensuite, exécutez Set-SPMetadataServiceApplication pour spécifier l’URL du concentrateur de type de contenu avec le paramètre -HubUri:

Set-SPMetadataServiceApplication -Identity “Managed Metadata Service”

-HubUri https://sp.cobaltatom.com/sites/ContentTypeHub

Une fois l’application de service de métadonnées gérées configurée, nous configurerons ensuite l’application de service de connectivité d’entreprise.

8.2 Service de connectivité des données d’entreprise

Le service Business Data Connectivity, souvent appelé BCS, est une application de service qui permet aux administrateurs SharePoint d’afficher les données d’autres sources de données directement dans SharePoint Server 2019. En utilisant SharePoint Designer, les utilisateurs peuvent se connecter à une source de données externe telle qu’un SQL Server et exposez ces informations en tant que liste externe dans SharePoint. Les développeurs peuvent également créer des types de contenu externe dans Visual Studio qui se connectent à plusieurs types de sources de données, telles qu’une source OData. Une application de service Business Data Connectivity peut être créée à partir de l’administration centrale ou via PowerShell.

Pour créer l’application de service Business Data Connectivity par le central

Administration, à partir de la page Applications de service, cliquez sur Nouveau dans le ruban et Application de service Business Data Connectivity. Une fenêtre s’ouvre semblable à la figure 8-4, dans laquelle vous devez entrer le nom de votre application de service de connectivité des données d’entreprise ainsi que le serveur de base de données et le nom de la base de données sur lesquels vous souhaitez la déployer.

Figure 8-4. Créer une nouvelle application de service de connectivité de données d’entreprise

En faisant défiler jusqu’à la fin de la fenêtre Nouvelle application de service de connectivité de données d’entreprise illustrée à la figure 8-5, nous devons sélectionner le pool d’applications sur lequel héberger cette application de service. Sauf si vous avez des exigences commerciales nécessitant que cette application de service soit isolée des autres, nous vous recommandons de la placer dans le même pool d’applications de service que le reste de vos applications de service pour une meilleure gestion des ressources et de meilleures performances du serveur. Appuyez simplement sur OK pour créer l’application de service.

Figure 8-5. Sélectionnez un pool d’applications pour le service de connectivité des données des Application d’entreprise

Pour créer l’application de service par PowerShell, nous devons utiliser l’applet de commande New-SPBus inessDataConnectivityServiceApplication PowerShell à partir d’un environnement de gestion SharePoint élevé. Nous devons spécifier le nom de l’application de service, le nom de la base de données et le pool d’applications de service. Pour créer une application de service comme celle que nous aurions créée par l’interface utilisateur, nous exécuterions l’applet de commande PowerShell suivante :

New-SPBusinessDataCatalogServiceApplication -Name “BCS” -DatabaseName “BCS”

-ApplicationPool “SharePoint Web Services Default”

Si vous exécutez SharePoint 2019 dans une batterie de serveurs MinRole, le service de connectivité des données d’entreprise sera automatiquement démarré sur tous les serveurs exécutant le Web Front End ou les rôles d’application. Si vous exécutez une batterie de serveurs à l’aide du MinRole personnalisé, vous devrez démarrer le service de connectivité des données d’entreprise sur au moins un serveur de votre batterie de serveurs SharePoint Server.

Vos utilisateurs peuvent désormais créer des types de contenu externe à l’aide de SharePoint Designer pour se connecter à des systèmes externes. Pour un exemple de la façon dont un développeur peut créer un type de contenu externe à l’aide d’un service OData, vous pouvez vous reporter au chapitre 14, la section sur les services de connectivité d’entreprise hybrides. Ensuite, nous allons configurer Word Automation Services.

8.3 Services d’automatisation de mots

L’application de service Word Automation Services est une application de service qui convertit automatiquement les documents pris en charge par l’application cliente Word dans des formats tels que PDF et XPS. D’une manière plus simple pour l’expliquer, les services d’automatisation Word prennent la fonctionnalité « Enregistrer sous » du client Word et réplique la fonctionnalité sur SharePoint. Une application de service d’automatisation Word peut être créée via l’interface utilisateur ou via PowerShell.

Pour créer une application de service Word Automation, dans l’Administration centrale de la page Gérer les applications de service, cliquez sur Nouveau dans le ruban et sélectionnez Services Word Automation. Une fenêtre similaire à la figure 8-6 s’ouvrira dans laquelle vous devrez entrer le nom et le pool d’applications et choisir d’ajouter cette application de service à la liste de proxy par défaut de la batterie. Comme les applications de service précédentes, à moins que vous n’ayez des exigences commerciales pour que cette application de service soit isolée des autres, nous vous recommandons de la déployer dans le même pool d’applications de service que le reste de vos applications de service.

Figure 8-6. Créer une nouvelle application Word Automation Services

Après avoir cliqué sur Suivant, SharePoint vous demandera le serveur de base de données ainsi que le nom de la base de données, comme illustré à la figure 8-7.

Figure 8-7. Option de base de données d’application Word Services

Après avoir cliqué sur OK, l’application de service sera créée. Pour créer une application Word Automation Services avec PowerShell, nous utiliserons l’applet de commande New-SPWordConversio nServiceApplication à partir d’un environnement de gestion SharePoint élevé. Pour créer une application de service comme celle que nous aurions créée dans les captures d’écran précédentes, nous aurions utilisé l’applet de commande PowerShell suivante :

New-SPWordConversionServiceApplication -Name “Word Automation”

-DatabaseName “WordAutomation” -ApplicationPool “SharePoint Web Services

Default” -Default

Les services d’automatisation Word ne peuvent être utilisés que via le code et non par l’interface utilisateur ; par conséquent, il est un peu plus difficile à tester, mais nous pouvons le tester en appelant des fonctions directement à partir de PowerShell. Pour tester Word Automation Services, nous avons téléchargé un document appelé « Document1.docx », que nous voulons convertir en PDF avec le nom « Document1-Final.pdf ». Nous allons d’abord charger l’assembly requis pour appeler les fonctions de Word Automation Services.

Add-Type -Path ‘C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.Office. Word.Server\v4.0_16.0.0.0__71e9bce111e9429c\Microsoft.Office.Word.Server.dll’

Nous créons ensuite un nouvel objet de type ConversionJobSettings spécifiant que le format de sortie est PDF.

$jobSettings = New-Object Microsoft.Office.Word.Server.Conversions.

ConversionJobSettings

$jobSettings.OutputFormat = “PDF”

Nous créons ensuite un nouvel objet de type ConversionJob et lui donnons notre nom de proxy d’application de service, dans notre cas Word Automation, ainsi que l’objet $ jobsettings. Nous définissons ensuite le $ Job.Usertoken sur le SPWeb SharePoint où le document est stocké.

$job = New-Object Microsoft.Office.Word.Server.Conversions.ConversionJob

(“Word Automation”, $jobSettings)

$job.UserToken = (Get-SPWeb https://sp.cobaltatom.com).CurrentUser.UserToken

Enfin, nous ajoutons les propriétés du fichier que nous voulons convertir. Nous lui donnons l’URL du document Word, ainsi que l’URL du futur document PDF, qui n’existe pas encore. Nous commençons ensuite le travail.

$job.AddFile(“https://sp.cobaltatom.com/Shared%20Documents/Document1.docx”,

“https://sp.cobaltatom.com/Shared%20Documents/Document1-Final.pdf”)

$job.Start()

Le travail Word Automation Services s’exécute de manière asynchrone, ce qui signifie que nous ne saurons pas quand il s’exécutera directement à partir de PowerShell ; cependant, nous pouvons forcer l’exécution immédiate du travail en démarrant le travail du minuteur Word Automation.

Start-SPTimerJob “Word Automation”

Si nous mettons tout cela ensemble, le script ressemble à ceci :

Add-Type -Path ‘C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft. Office.Word.Server\v4.0_16.0.0.0__71e9bce111e9429c\Microsoft.Office.Word.

Server.dll’

$jobSettings = New-Object Microsoft.Office.Word.Server.Conversions.

ConversionJobSettings

$jobSettings.OutputFormat = “PDF” $job = New-Object Microsoft.Office.Word.Server.Conversions.

ConversionJob(“Word Automation”, $jobSettings)

$job.UserToken = (Get-SPWeb https://sp.cobaltatom.com).CurrentUser.UserToken

$job.AddFile(“https://sp.cobaltatom.com/Shared%20Documents/Document1.docx”,

“https://sp.cobaltatom.com/Shared%20Documents/Document1-Final.pdf”)

$job.Start()

Start-SPTimerJob “Word Automation”

Pour voir l’état du travail, exécutez l’applet de commande PowerShell suivante où «Word Automation» est le nom de votre application Word Automation Services:

new-object Microsoft.Office.Word.Server.Conversions. ConversionJobStatus(“Word Automation”, $job.JobId,$null);

Initialement, il apparaîtra comme InProgress puisque nous avons forcé le démarrage du travail du minuteur, comme illustré à la figure 8-8.

Figure 8-8. Travail d’automatisation Word en cours

Une fois le travail terminé, il apparaîtra comme Réussi ou Échoué. Si tout a été configuré correctement, il devrait s’afficher comme réussi, comme illustré à la figure 8-9, et vous devriez voir votre document PDF dans votre bibliothèque de documents.

Figure 8-9. Travail d’automatisation de mots réussi

Dans une configuration de batterie de serveurs MinRole, le service Word Automation sera automatiquement démarré sur tous les serveurs qui ont le rôle d’application. Si vous exécutez une batterie de serveurs à l’aide de rôles personnalisés, vous devrez la démarrer manuellement sur au moins un serveur de la batterie de serveurs.

8.4 Service d’automatisation PowerPoint

Le service d’automatisation PowerPoint est très similaire au service d’automatisation Word dont nous venons de parler, mais il concerne les fichiers PowerPoint au lieu des fichiers Word. Le service d’automatisation PowerPoint permet aux développeurs de créer des solutions qui convertiront des fichiers PowerPoint dans des formats tels que PDF, JPG, PNG ou XPS.

Contrairement au service d’automatisation Word, le service d’automatisation PowerPoint ne peut être créé que via PowerShell et non par l’administration centrale. Nous devrons utiliser l’applet de commande New-SPPowerPointConversionServiceApplication à partir d’un environnement de gestion SharePoint élevé. Nous devons lui donner un nom, ainsi que le pool d’applications de service dans lequel il doit être déployé.

$sa = New-SPPowerPointConversionServiceApplication -Name “PowerPoint

Conversion Service” -ApplicationPool “SharePoint Web Services Default”

Une fois l’application de service créée, nous allons créer un proxy d’application de service de conversion PowerPoint en utilisant la cmdlet New- SPPowerPointConversionServiceApplicati onProxy et en l’ajoutant au groupe par défaut avec le commutateur -AddToDefaultGroup.

New-SPPowerPointConversionServiceApplicationProxy “PowerPoint Conversion

Service Proxy” -ServiceApplication $sa –AddToDefaultGroup

Vos développeurs pourront ensuite utiliser les API de conversion PowerPoint pour convertir des fichiers PowerPoint aux formats pris en charge.

Remarque pour en savoir plus sur les API disponibles, consultez les ressources sur MSdn: https://msdn.microsoft.com/en-us/library/office/FP179894.aspx/ .

8.5 Service graphique Visio

L’application de service graphique Visio permet à l’utilisateur de visualiser les diagrammes Visio directement dans le navigateur, sans que l’application cliente soit installée. De plus, les utilisateurs pouvaient consommer ces fichiers Visio directement sur leurs appareils mobiles.

Notez que seul le rendu basé sur png est disponible dans Sharepoint Server 2019 car le rendu Silverlight a été complètement supprimé dans Sharepoint 2019.

L’application de service graphique Visio peut être créée à partir de l’administration centrale ou de PowerShell. Pour créer une application de service graphique Visio à partir de l’administration centrale, accédez à la page Gestion des applications de service, cliquez sur Nouveau dans le ruban et sélectionnez application de service graphique Visio. Une fenêtre similaire à la figure 8-10 s’ouvrira, dans laquelle vous devrez saisir le nom de l’application de service, choisir de créer un nouveau pool d’applications ou utiliser un existant, et enfin créer un proxy d’application de service Visio Graphics. Nous vous recommandons d’utiliser le même pool d’applications de service que le reste de l’application de service, sauf si vous avez une exigence métier pour isoler cette application de service des autres.

Figure 8-10. Nouvelle application de service graphique Visio

L’application de service graphique Visio peut également être créée à l’aide de l’applet de commande New-SPVisioServiceApplication à partir d’un environnement de gestion SharePoint élevé. Pour créer un service graphique Visio, nous devons spécifier le nom de l’application de service, le pool d’applications et le commutateur pour l’ajouter au groupe de proxy par défaut.

$sa = New-SPVisioServiceApplication -Name “Visio Graphics” -ApplicationPool

“SharePoint Web Services Default” -AddToDefaultGroup

Pour tester l’application de service, téléchargez simplement un diagramme Visio dans SharePoint et lorsque vous cliquez sur le document, il s’ouvrira dans le navigateur, au lieu de le télécharger sur l’ordinateur.

8.6 Services de traduction automatique

L’application de service des services de traduction automatique est une application de service qui permet aux utilisateurs et aux développeurs de traduire non seulement des sites, mais aussi leur contenu, dans d’autres langues. Les services de traduction automatique sont interagis via des API et les utilisateurs n’ont pas de bouton « Traduire le document », à moins bien sûr que leurs développeurs n’aient créé une action personnalisée pour eux.

Notez que l’application Service de traduction automatique est déconseillée dans Sharepoint 2019. Vous ne devez l’utiliser que pour des raisons de compatibilité descendante si vous l’utilisiez dans des versions antérieures de Sharepoint, mais nous ne recommandons pas de démarrer de nouveaux projets qui en dépendent !

Avant de créer l’application de service de traduction automatique, vous devez vous assurer que les applications de service suivantes existent dans la batterie de serveurs SharePoint 2019 :

  • Application du service de gestion des applications (vue au chapitre 5)
  • Un proxy d’application de service de profil utilisateur dans le groupe par défaut de la batterie de serveurs
  • La batterie de serveurs SharePoint a accès à Internet

L’application de service de traduction automatique peut être créée à partir de l’administration centrale ou par PowerShell. Pour créer l’application de service de traduction automatique via l’administration centrale, accédez à la page Gérer l’application de service, dans le ruban, cliquez sur Nouveau, puis sélectionnez Service de traduction automatique.

Une fenêtre s’ouvrira similaire à la figure 8-11, dans laquelle vous devrez saisir le nom de l’application de service et choisir de créer ou non un nouveau pool d’applications de service. Nous vous recommandons d’utiliser le même pool d’applications que pour les applications de service précédentes, sauf s’il existe une exigence métier pour isoler cette application de service.

Figure 8-11. Nouveau nom d’application de service de traduction automatique et

Pool d’applications

Enfin, nous devons entrer le serveur de base de données et le nom de notre base de données de traduction automatique, comme illustré à la figure 8-12.

Figure 8-12. Nouvelle application de service de traduction automatique

Pour créer l’application de service de traduction automatique via PowerShell, vous devez utiliser l’applet de commande New-SPTranslationServiceApplication à partir d’un environnement de gestion SharePoint élevé. Pour créer l’application de service de traduction automatique avec les mêmes paramètres que dans la capture d’écran précédente, nous exécuterions la commande PowerShell suivante :

New-SPTranslationServiceApplication -Name “Machine Translation”

-DatabaseName “MachineTranslation” -ApplicationPool “SharePoint Web

Services Default” -Default

Une fois l’application de service de traduction automatique créée, vos développeurs peuvent désormais créer du code utilisant le service de traduction automatique.

Astuce pour en savoir plus sur les API des services de traduction automatique, visitez la page sur MSdn: https://docs.microsoft.com/en-us/sharepoint/dev/general development / machine-translation-services-in-sharepoint .

8.7 Services d’accès 2010

SharePoint Server 2019 comprend deux applications de service Access différentes. Le premier est appelé « Access Services 2010 », tandis que le second est « Access Services 2013 ».

Remarque Les services d’accès 2010 et 2013 sont considérés comme obsolètes dans Sharepoint Server 2019 et ne sont inclus qu’à des fins de compatibilité. vous ne devez l’utiliser pour la compatibilité descendante que si vous l’utilisiez dans des versions antérieures de Sharepoint, mais nous ne recommandons pas de démarrer de nouveaux projets qui en dépendent!

Access Services 2010 est une application de service qui permet aux utilisateurs de modifier et de publier dans SharePoint 2019, une base de données Web d’accès précédemment créée dans SharePoint 2010. Les utilisateurs peuvent afficher la base de données Web publiée sans qu’Access soit installé localement ; cependant, ils ont besoin de l’application Office pour modifier la structure de la base de données.

Pour créer l’application de service Access Services 2010 à partir de l’administration centrale, accédez à la page Gérer les applications de service, cliquez sur Nouveau dans le ruban et sélectionnez Access Services 2010. Comme le montre la figure 8-13, vous devrez entrer un nom pour le service Application, sélectionnez le pool d’applications de service que nous avons créé précédemment pour ces applications de service et indiquez si cette application de service figurera dans la liste de proxy par défaut.

Figure 8-13. Nouvelle application de service Access Services 2010

Cela peut également être effectué par PowerShell avec la cmdlet New-SPAccessServiceApplication à partir d’un environnement de gestion SharePoint élevé. Afin de créer un service

Application avec les mêmes paramètres que précédemment, nous exécuterions l’applet de commande suivante :

New-SPAccessServiceApplication -Name “Access Services 2010”

-ApplicationPool “SharePoint Web Services Default” –Default

Une fois l’application de service Access 2010 créée, examinons la version d’Access App Services 2013.

8.8 Services d’accès 2013

Access Apps for SharePoint est un type de base de données que vous créez dans Access et que vous utilisez et partagez avec d’autres en tant qu’application dans SharePoint directement dans le navigateur. Access Services 2013 est une application de service plus avancée qui vous permet de créer des applications Access et de suivre les données telles que les contacts, les commandes, etc. Access Services 2013 est un peu plus compliqué à configurer par rapport aux autres applications de service et nécessitera l’installation de prérequis supplémentaires.

Avant de commencer à configurer les services d’accès, les applications de service suivantes doivent être configurées :

  • Service de magasin sécurisé
  • Service de gestion des applications
  • Service de paramètres d’abonnement Microsoft SharePoint Foundation
  • Services d’accès 2010

Votre environnement d’application doit également être configuré comme nous l’avons vu au chapitre 5.

Tout d’abord, étant donné que le compte exécutant Access Services 2013 nécessite plus d’autorisations SQL que les autres applications de service, nous allons créer un nouveau compte de service dédié à cette application de service. Dans notre environnement, le compte que nous avons créé a le nom d’utilisateur LAB \ s-access. Étant donné que ce compte sera utilisé pour exécuter un pool d’applications, nous l’enregistrerons en tant que compte géré en exécutant l’applet de commande PowerShell suivante :

$cred = Get-Credential -UserName “LAB\s-access” -Message “Managed Account”

New-SPManagedAccount -Credential $cred

Nous allons ensuite créer un nouveau pool d’applications de service appelé « SharePoint Access App Services » dans lequel nous exécuterons l’application de service.

New-SPServiceApplicationPool -Name “SharePoint Access App Services”

-Account (Get-SPManagedAccount “LAB\s-access”)

Une fois l’application de service créée, nous devons modifier un paramètre dans IIS qui sera unique à cette application de service. Accédez aux pools d’applications IIS et, dans Paramètres avancés, définissez « Charger le profil utilisateur » sur True, comme illustré à la figure 8-14.

Figure 8-14. Charger le paramètre de profil utilisateur dans IIS

Remarque n’oubliez pas de faire ce changement sur tous les serveurs où le pool d’application est présent.

Ensuite, nous devons nous assurer que notre nouveau compte de service a des droits sur les autres bases de données de contenu, car c’est là que les applications d’accès seront créées. Cette opération est effectuée par les applets de commande PowerShell suivantes :

$w = Get-SPWebApplication https://sp.cobaltatom.com

$w.GrantAccessToProcessIdentity(“LAB\s-access”)

$w.Update()

N’oubliez pas de répéter cette étape pour chaque application Web sur laquelle vous souhaitez héberger des applications d’accès. Enfin, le compte de service doit disposer d’une autorisation de lecture / écriture sur le dossier de cache de configuration situé dans C:\ProgramData\Microsoft\SharePoint\Config sur chaque serveur. Une fois ces autorisations accordées, nous devons installer les prérequis du pack de fonctionnalités SQL Server sur nos serveurs SharePoint. Cela n’est requis que sur les serveurs sur lesquels vous exécuterez le service Access Services SharePoint ; cependant, nous vous recommandons d’installer ces prérequis sur tous les serveurs de votre batterie. Cela rendra votre ferme plus flexible si vous décidez de changer de rôle à l’avenir. Dans une configuration MinRole, les services d’accès sont automatiquement démarrés sur tous les serveurs exécutant le rôle Web Front End. Les prérequis sont

  • Base de données locale Microsoft SQL Server (SQLLocalDB.msi)
  • Cadre d’application de niveau de données Microsoft SQL Server (Dacframework.msi)
  • Client natif Microsoft SQL Server (sqlncli.msi)
  • Microsoft SQL Server Transact-SQL ScriptDom (SQLDOM.MSI)
  • Types Microsoft System CLR pour Microsoft SQL Server (SQLSysClrTypes.msi)

Une fois les prérequis installés, nous devons configurer SQL Server pour Access Services. Le serveur SQL que vous utilisez doit disposer des fonctionnalités d’instance suivantes :

  • Services du moteur de base de données
  • Extractions de texte intégral et sémantique pour la recherche
  • Connectivité des outils client

Si ces fonctionnalités n’étaient pas installées lors de la création initiale de l’instance, vous pouvez les ajouter par la suite à partir du Centre d’installation de SQL Server.

Ensuite, nous devons créer une nouvelle connexion dans votre serveur SQL à partir de SQL Server Management Studio, comme illustré à la figure 8-15.

Figure 8-15. Nouvelle connexion dans SQL Server

Dans l’onglet Général, écrivez le nom d’utilisateur du compte de service Access et dans l’onglet Rôles du serveur , sélectionnez dbcreator ainsi que securityadmin comme illustré à la figure 8-16 .

Figure 8-16. Accéder aux rôles de serveur de compte de service

Étant donné que ce compte devra également exécuter certaines procédures stockées sur la base de données de configuration, dans l’onglet Mappage utilisateur, accordez à ce compte l’autorisation SPDataAccess comme illustré à la figure 8-17.

Figure 8-17. SPDataAccess sur la base de données de configuration

Nous devons ensuite aller dans les propriétés de SQL Server et, à partir de l’onglet Sécurité, activer le mode d’authentification mixte (SQL Server et Windows) comme le montre la figure 8-18.

Figure 8-18. Mode d’authentification SQL mixte

Ensuite, à partir de l’onglet Avancé, nous devons changer « Activer les bases de données contenues » et « Autoriser les déclencheurs à déclencher d’autres » sur Vrai et définir la langue par défaut sur l’anglais, comme illustré à la figure 8-19.

Figure 8-19. Propriétés avancées de SQL Server

Enfin, nous devons configurer les protocoles SQL Server. Les protocoles TCP / IP et Named Pipes doivent être activés. Cela peut être fait à partir du Gestionnaire de configuration SQL Server, comme illustré à la figure 8-20.

Figure 8-20. Protocoles pour SQL Server

Pour que ces modifications prennent effet, vous devez redémarrer le service Moteur SQL Server.

Une fois SQL Server configuré, vous devez activer les ports suivants via le pare-feu :

  • TCP 1433
  • TCP 1434
  • UDP 1434

Avec toutes les conditions préalables configurées, il est temps de créer l’application de service d’accès.

Astuce pensez à effectuer les changements de configuration sur tous vos serveurs SQl partie de la ferme.

Pour créer l’application de service Access Services 2013, nous utiliserions l’applet de commande New-SPAccessServicesApplication, notez les s supplémentaires dans les services par rapport à l’applet de commande PowerShell pour l’application de service Access 2010. Pour créer une application de service avec le nom Access App Services dans notre pool d’applications de service dédié aux services d’accès, nous exécuterions l’applet de commande suivante :

New-SPAccessServicesApplication -Name “Access App Services”

-ApplicationPool “SharePoint Access App Services” –Par défaut

La dernière étape consiste à accéder à l’Administration centrale, dans l’application de service Access App Services 2013. Au bas de la fenêtre de configuration, ouvrez le groupe de configuration Nouveau serveur de base de données d’application et tapez le serveur SQL que vous souhaitez utiliser pour les bases de données d’application Access Services, comme illustré à la figure 8-21.

Figure 8-21. Nouveau serveur de base de données d’application

Une fois le serveur de bases de données d’application configuré, nous pouvons tester l’application de service à partir d’un client sur lequel Access 2013 ou une version ultérieure est installée. Depuis Access, créez une nouvelle application Web personnalisée, comme illustré à la figure 8-22. À l’invite, entrez l’URL d’une collection de sites à laquelle vous avez accès.

Figure 8-22. Nouvelle application Web personnalisée

Dans notre exemple illustré à la figure 8-23, nous avons créé une application Access en utilisant le modèle de commandes par défaut.

Figure 8-23. Base de données Access Orders

Lorsque vous êtes prêt à publier, cliquez sur « Lancer l’application » dans le ruban, et l’application devrait s’ouvrir dans SharePoint 2019, comme illustré à la figure 8-24.

Figure 8-24. Accéder à l’application dans SharePoint

Les services d’accès ont été correctement configurés. En tant qu’administrateur SharePoint, il est important de comprendre que chaque application crée sa propre base de données dans SQL Server ; par conséquent, il est important de vous assurer que de nouvelles bases de données d’application sont ajoutées à votre plan de maintenance SQL et à votre groupe de disponibilité ou mise en miroir SQL AlwaysOn.

8.9 Prochaines étapes

Dans ce chapitre, nous avons appris à déployer les applications de service de productivité dans SharePoint Server 2019 à la fois par l’administration centrale et à l’aide de PowerShell. Dans le chapitre suivant, nous verrons comment installer et configurer Office Online Server pour permettre à nos utilisateurs d’afficher, de modifier et de créer des documents Office directement dans le navigateur.