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).

• 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

CHAPITRE 9 Configuration d’Office Online Server pour SharePoint 2019

Office Online Server, précédemment nommé Office Web Apps, est un serveur qui permet aux utilisateurs d’afficher et de modifier des documents Office tels que Word, Excel, PowerPoint et OneNote directement à partir du navigateur. Office Online Server permet également aux utilisateurs d’afficher des documents PDF dans le navigateur et de convertir des documents Office au format PDF.

Il est important de ne pas se tromper dans le choix du nom de Microsoft pour le produit. Même s’il s’appelle Office Online Server, le produit est entièrement sur site et ne nécessite pas de connexion à Office 365 ni à aucune licence Office 365.

De plus, Office Online Server n’est pas seulement pour SharePoint ! Office Online Server peut ajouter des fonctionnalités à Exchange Server 2016/2019 ainsi qu’à Skype Entreprise Server 2015/2019. Nous ne couvrirons pas ces fonctionnalités, ni comment les activer dans cet article; cependant, il est important de savoir que les investissements que vous effectuez dans Office Online Server ne sont pas uniquement pour SharePoint, mais également pour Exchange et Skype Entreprise.

Il existe plusieurs raisons de déployer Office Online Server autres que la possibilité d’afficher et de modifier des documents Office à partir du navigateur. Avec Excel Services disparu depuis SharePoint Server 2016, vous avez besoin d’Office Online Server pour afficher les tableaux de bord Excel. De plus, Office Online Server permet des fonctionnalités supplémentaires telles que des liens durables. Office Online Server est un produit à feuilles persistantes, nous n’avons donc pas Office Online Server 2016 et Office Online Server 2019 ; il s’agit simplement d’Office Online Server avec une mise à jour disponible tous les trois à quatre mois. La version minimale d’Office Online Server pour SharePoint Server 2019 est novembre 2018 ; cependant, il est toujours recommandé d’installer la dernière version disponible.

Présentation de l’architecture du serveur Office Online

Avant de commencer à configurer Office Online Server, il est important de comprendre l’architecture d’Office Online Server afin de comprendre ce que nous allons installer et configurer dans ce chapitre.

Office Online Server est similaire à SharePoint Server, car nous avons besoin d’un ou de plusieurs serveurs Office Online pour créer une batterie de serveurs Office Online. Cette batterie peut servir un ou plusieurs déploiements SharePoint, Exchange et Skype Entreprise. Dans la figure 9- 1, nous pouvons voir une ferme en ligne Office Server se compose de trois serveurs qui servent deux différentes fermes SharePoint ainsi qu’un déploiement Exchange et un Skype pour le déploiement d’entreprise.

Figure 9-1. Présentation de haut niveau de l’architecture de serveur Office Online

Une batterie de serveurs Office Online peut être rendue accessible via deux URL différentes. Nous appelons le premier l’URL interne et le second l’URL externe comme le montre la figure 9-2. Les URL peuvent être HTTP ou HTTPS, et au moins l’une des URL est obligatoire. Office Online Server vous permet de configurer l’URL interne, l’URL externe ou les deux. Lors de la configuration des URL internes et externes, vous avez le choix de les configurer sur HTTP ou HTTPS. Étant donné que notre serveur SharePoint utilise HTTPS, nous allons configurer Office Online Server pour utiliser également HTTPS. La sécurisation de votre serveur Office Online avec SSL est extrêmement importante, 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é. Vous pouvez configurer Office Online Server sur HTTPS même si vos sites SharePoint s’exécutent sur HTTP.

Figure 9-2. URL interne et externe d’Office Online Server

Office Online Server n’utilise que trois ports pour communiquer entre les serveurs et avec SharePoint, Exchange et Skype Entreprise. Ces ports sont décrits dans le tableau 9-1.

Tableau 9-1. Ports de serveur Office Online

Port	Une fonction
80	trafic http
443	Trafic httpS
809	trafic entre les serveurs de bureau en ligne

Pour améliorer la sécurité, vous pouvez bloquer les ports que vous n’utilisez pas. Par exemple, si votre batterie de serveurs Office Online Server ne sera constituée que d’un seul serveur et sera accessible via SSL, vous n’avez besoin que du port 443.

La configuration matérielle minimale requise pour Office Online Server est la même que pour SharePoint Server 2019 et décrite dans le tableau 9-2.

Tableau 9-2 Configuration   minimale requise pour Office Online Server

CPU	RAM	Disque
64 bits, 4 cœurs	12 Go	80 gB pour lecteur système

Office Online Server prend en charge les versions 64 bits de Windows Server 2012 R2 et Windows Server 2016. La fonctionnalité Server with Desktop Experience doit être activée car Office Online Server ne peut pas s’exécuter sur le noyau Windows Server.

Remarque au moment de la rédaction de cet article, le serveur Office Online fonctionnant sur Windows Server 2019 n’était pas pris en charge. vérifiez toujours les derniers systèmes d’exploitation pris en charge sur https://docs.microsoft.com/en-us/officeonlineserver/ plan-office-online-server . 

Du point de vue de la mise en réseau, tous les serveurs d’une batterie de serveurs Office Online doivent se trouver dans la même forêt et pour utiliser les fonctionnalités de Business Intelligence, ils doivent se trouver dans la même forêt que les utilisateurs qui les utiliseront.

Office Online Server doit être installé sur son propre serveur dédié. Il peut fonctionner à la fois sur un ordinateur physique et sur une machine virtuelle fonctionnant sur Hyper-V ou VMware. Office Online Server ne peut pas être installé sur la même machine que Exchange, SharePoint et Skype Entreprise, SQL, contrôleur de domaine ou tout serveur sur lequel Office est installé.

Remarque au moment de la rédaction de cet article, la licence Office Online Server interdit aux entreprises d’installer Office Online Server sur du matériel physique qui ne leur appartient pas, ce qui rend impossible l’utilisation d’Office Online Server dans Azure, AWS ou tout autre fournisseur. Vérifiez auprès de votre expert en licences Microsoft avant de déployer Office Online Server sur toutes les machines que vous ne possédez pas. 

Si vous prévoyez d’avoir plusieurs serveurs Office Online dans votre batterie, vous aurez besoin d’un équilibreur de charge qui prend en charge les fonctionnalités suivantes :

• Déchargement SSL ou pontage SSL
• Activation de l’affinité client ou de l’affinité frontale
• Routage de couche 7

De plus, si vous prévoyez d’ouvrir Office Online Server sur Internet pour SharePoint ou Exchange, vous aurez également besoin d’un proxy inverse afin de le rendre accessible aux utilisateurs externes en toute sécurité.

Si vous prévoyez d’utiliser SSL, le certificat doit provenir d’une autorité de certification approuvée et inclure le nom de domaine complet (FQDN) de l’URL de votre batterie de serveurs Office Online Server dans le SAN (Subject Alternative Name). En outre, le nom de domaine complet de chaque serveur de votre batterie de serveurs Office Online doit être dans le SAN du certificat. Le certificat que nous avons utilisé dans notre article peut être vu dans la figure 9-3 et a office.cobaltatom.com comme Issued To, qui est à la fois notre URL interne et externe et a également des serveurs CALOS1 et CALOS2 dans le SAN dans leur format FQDN.

Figure 9-3. Certificat de serveur Office Online

Installation d’Office Online Server

Maintenant que nous connaissons l’architecture d’Office Online Server, commençons à l’installer. Nous d’abord besoin d’installer les suivants pré – requis :

• NET Framework 4.5.2
• Visual C ++ redistribuable pour Visual Studio 2015

Ensuite, nous devons activer les fonctionnalités et rôles Windows Server requis. Cela peut être réalisé avec le script PowerShell suivant, qui nécessitera un redémarrage.

Pour Windows Server 2012 R2, exécutez les éléments suivants dans une fenêtre PowerShell élevée:

Add-WindowsFeature Web-Server,Web-Mgmt-Tools,Web-Mgmt-Console,Web-

WebServer,Web-Common-Http,Web-Default-Doc,Web-Static-Content,Web-

Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-

Filtering,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-

ISAPI- Ext,Web-ISAPI-Filter,Web-Includes,InkandHandwritingServices,NET-

Framework- Features,NET-Framework-Core,NET-HTTP-Activation,NET-Non-HTTP- Activ,NET-WCF-HTTP-Activation45,Windows-Identity-Foundation

Pour Windows Server 2016, exécutez les éléments suivants dans une fenêtre PowerShell élevée:

Add-WindowsFeature Web-Server,Web-Mgmt-Tools,Web-Mgmt-Console,Web-

WebServer,Web-Common-Http,Web-Default-Doc,Web-Static-Content,Web-

Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-

Filtering,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-

ISAPI- Ext,Web-ISAPI-Filter,Web-Includes,NET-Framework-Features,NET-

Framework- 45-Features,NET-Framework-Core,NET-Framework-45-Core,NET-HTTP- Activation,NET-Non-HTTP-Activ,NET-WCF-HTTP-Activation45,Windows-Identity-

Foundation,Server-Media-Foundation

Après le redémarrage, les prérequis suivants doivent être installés :

• Microsoft.IdentityModel.Extention.dll

Une fois toutes les conditions préalables installées avec succès, vous pouvez ouvrir Office Online Server Setup.exe à partir des fichiers binaires que vous avez obtenus à partir de MSDN ou du Centre de licences en volume.

Après avoir accepté les termes, sélectionnez l’emplacement où vous souhaitez installer les fichiers binaires Office Online Server, comme illustré à la figure 9-4.

Figure 9-4. Installation du serveur Office Online

L’emplacement des fichiers journaux ainsi que l’emplacement du cache peuvent être spécifiés ultérieurement lors de la création de la batterie de serveurs Office Online Server. Cliquez sur Suivant, jusqu’à ce que vous obteniez un écran similaire à la figure 9-5 indiquant que l’installation est terminée.

Figure 9-5. Confirmation de l’installation d’Office Online Server

Une fois l’installation des fichiers binaires d’Office Online Server terminée, il est maintenant temps d’installer les modules linguistiques que vous souhaitez proposer à vos utilisateurs. Pour que l’interface utilisateur multilingue fonctionne, le module linguistique doit être installé à la fois sur Office Online Server et sur votre hôte (SharePoint, Exchange ou Skype Entreprise).

Étant donné que notre batterie de serveurs n’est pas créée à ce stade, l’installation des mises à jour publiques ou des modules linguistiques est aussi simple que de démarrer le programme d’installation et de cliquer sur Suivant jusqu’à ce qu’il soit terminé. En tant que public

Les mises à jour comprennent également des mises à jour pour les modules linguistiques, assurez-vous d’installer les modules linguistiques de base avant d’installer les mises à jour publiques. En installant les modules linguistiques de base avant les mises à jour publiques, toutes les mises à jour liées à la langue dans les mises à jour publiques seront appliquées.

Une fois que vos serveurs Office Online sont au niveau de mise à jour souhaité et que vous disposez des modules linguistiques requis pour votre entreprise, il est maintenant temps de créer la batterie de serveurs Office Online.

Création de la batterie de serveurs Office Online

Contrairement à la plupart des produits Microsoft, Office Online Server n’a pas du tout d’interface utilisateur et la seule façon de la gérer est d’utiliser Windows PowerShell. De plus, contrairement à d’autres produits Office Server tels que SharePoint, il n’y a pas d ‘« Office Online Management Shell » que vous trouverez sur votre ordinateur; le module requis gérer Office Online Server sera chargé par défaut chaque fois que vous ouvrirez PowerShell.

Pour créer la batterie de serveurs, nous devons exécuter l’applet de commande New-OfficeWebAppsFarm PowerShell. Office Web Apps est l’ancien nom d’Office Online Server dans la suite 2013 des serveurs Office. Vous verrez que la plupart des applets de commande PowerShell pour gérer Office Online Server font toujours référence à Office Web Apps.

Remarque Assurez-vous de toujours exécuter powerShell en tant qu’administrateur lorsque vous modifiez les configurations de serveur Office Online. 

Avant d’exécuter PowerShell pour créer notre batterie de serveurs, nous devons planifier certaines choses. Le premier élément à planifier est l’URL que les services consommateurs (SharePoint, Exchange ou Skype Entreprise) utiliseront pour se connecter à la batterie de serveurs Office Online Server. D’un point de vue uniquement SharePoint, vous ne pouvez avoir qu’une seule URL si vous le souhaitez, car SharePoint ne peut utiliser qu’une seule d’entre elles, mais pas les deux. Si vous prévoyez également de connecter Skype Entreprise et Exchange à votre batterie de serveurs Office Online, ils auront parfois besoin de l’URL externe. Un bon exemple est lorsque vous organisez une réunion Skype Entreprise et partagez une présentation PowerPoint. Skype Entreprise connectera les utilisateurs externes à l’URL externe de votre batterie de serveurs en ligne de bureau. Quelque chose à considérer est que pour activer toutes les fonctionnalités, l’URL externe doit être accessible depuis Internet. Certaines des fonctionnalités sont des aperçus de documents à partir d’Outlook sur le Web (anciennement Outlook Web App), des présentations PowerPoint Skype Entreprise avec des utilisateurs externes et des aperçus de documents dans les résultats de recherche Office 365 lors de l’utilisation de la recherche hybride dans le cloud.

La publication de l’URL interne et externe à l’aide de SSL (Secure Sockets Layers) est fortement recommandée pour des raisons de sécurité ; SharePoint et le serveur Exchange peuvent utiliser Office Online Server via HTTP. Les seules raisons qui vous obligent à le publier sous SSL sont les suivantes :

1. Vous avez au moins un site SharePoint qui utilisera HTTPS. Si vos sites SharePoint utilisent HTTPS, vous en aurez également besoin pour votre serveur Office Online.

2. Vous prévoyez de connecter Office Online Server à Skype Entreprise. Skype Entreprise ne se connecte à Office Online Server que si ce dernier utilise https.

Alors que dans cet article, nous recommandons SSL Bridging pour la sécurité, Office Online Server prend également en charge le déchargement SSL. Le déchargement SSL n’est pas recommandé car le trafic entre l’équilibreur de charge et votre serveur Office Online ne sera pas chiffré et vous pouvez être soumis à une attaque de type intermédiaire. Si vous prévoyez d’utiliser SSL jusqu’au

Office Online Server, soit en utilisant le passage direct ou le pontage SSL sur votre équilibreur de charge réseau, veillez à importer le certificat dans IIS sur chaque serveur de votre batterie de serveurs Office Online. Assurez-vous que le certificat a un nom convivial dans IIS, car c’est ce que nous devrons utiliser dans notre applet de commande PowerShell.

Notez qu’il est obligatoire que le certificat ait un nom convivial et que ce nom convivial ne puisse pas contenir d’astérisque. 

Ce certificat doit également être approuvé par la batterie de serveurs SharePoint. Si le certificat provient d’une autorité de certification telle que DigiCert qui est incluse par défaut dans les autorités de certification racine dans Windows, il fonctionnera sans faire de configurations spéciales. Toutefois, si vous utilisez un certificat auto-signé ou une autorité qui ne se trouve pas dans le magasin de certificats d’autorité racine par défaut, assurez-vous de l’ajouter en tant que certificat approuvé dans Admin Central SharePoint ➤ Sécurité ➤ Gérer la confiance. Assurez-vous d’ajouter le certificat racine et non le certificat de fin. Vous pouvez voir un exemple dans la figure 9-6.

Figure 9-6. Établir une relation de confiance dans l’administration centrale de SharePoint 2019

Vous pouvez également le faire en exécutant les applets de commande PowerShell suivantes à partir d’un environnement de gestion SharePoint élevé :

$trustCert = Get-PfxCertificate <C:\Certs\OOSRootCert.cer>

New-SPTrustedRootAuthority “OOSRootCert” -Certificate $trustCert

Voici l’applet de commande que nous avons utilisée dans notre environnement pour créer la batterie de serveurs Office Online :

New-OfficeWebAppsFarm -InternalUrl “https://office.cobaltatom.com” -ExternalUrl “https://office.cobaltatom.com” -CertificateName “OOSCert” –EditingEnabled

Où

• InternalURL est l’URL interne de la batterie de serveurs Office Online.
• ExternalURL est l’URL externe de la batterie de serveurs Office Online et, comme vous le voyez, vous pouvez sélectionner la même URL pour les URL internes et externes. C’est ce que nous avons fait dans notre laboratoire.
• CertificateName est le nom convivial de mon certificat dans IIS.
• EditingEnabled est un commutateur qui indique à Office Online Server que les utilisateurs sont autorisés non seulement à afficher des documents avec celui-ci, mais également à créer et à modifier des documents dans SharePoint directement dans le navigateur. Dès que vous choisissez ce commutateur, vous serez invité à approuver que vous disposiez des bonnes licences.

Notez que si vous prévoyez d’utiliser Office Online Server sur http, vous devez ajouter le commutateur – AllowHttp . si vous prévoyez d’utiliser le déchargement SSl , vous devez passer le  commutateur – SSLOffloaded . 

L’applet de commande New-OfficeWebAppsFarm possède de nombreux paramètres qui sont importants pour sélectionner les fonctionnalités que vous souhaitez activer dans votre batterie de serveurs Office Online. Vous pouvez afficher ces fonctionnalités sur TechNet à partir du lien suivant: https://docs.microsoft.com/en-us/ powershell / module / officewebapps / new-officewebappsfarm? View = officewebapps-ps ou en exécutant l’applet de commande PowerShell suivante:

Get-Help New-OfficeWebAppsFarm -Online

Après avoir exécuté la commande, PowerShell configurera tout le nécessaire pour configurer la batterie de serveurs. Pour valider que la configuration a réussi, pointez votre enregistrement DNS A ou votre fichier hôte sur le serveur sur lequel vous venez de configurer la batterie de serveurs et accédez à l’interne ou une URL externe + / hébergement / découverte. Dans ce cas, cette URL serait https: // office. cobaltatom.com/hosting/discovery/ . Si tout fonctionne comme prévu, vous devriez voir un fichier XML similaire à la figure 9-7.

Figure 9-7. Fichier XML de découverte

Après avoir correctement configuré notre première machine dans la batterie de serveurs Office Online, vous devez installer les mêmes fichiers binaires sur toutes les autres machines de la batterie de serveurs Office Online, et si vous utilisez un certificat SSL, assurez-vous de l’importer également dans IIS. Une fois les fichiers binaires installés, exécutez simplement l’applet de commande suivante :

New-OfficeWebAppsMachine -MachineToJoin CALOS01.lab.cobaltatom.com

Dans le paramètre MachineToJoin, vous lui attribuez le nom de domaine complet du premier serveur Office Online de la batterie de serveurs. Dans notre cas, ce nom de domaine complet est CALOS01.Lab.cobaltatom.com.

Répétez l’applet de commande New- OfficeWebAppsMachine sur tous les serveurs que vous souhaitez joindre à la batterie de serveurs Office Online. Après avoir ajouté tous les serveurs de la batterie de serveurs, exécutez l’applet de commande suivante pour valider leur état d’intégrité :

(Get-OfficeWebAppsFarm).Machines

La sortie doit être tous les serveurs de votre batterie de serveurs Office Online Server, avec un état d’intégrité sain.

Configuration SSL

Comme nous avons imposé l’utilisation de TLS 1.2 pour SharePoint, nous devons activer le cryptage fort comme indiqué dans l’Avis de sécurité Microsoft 2960358. Selon l’avis, il peut être nécessaire d’activer la prise en charge de TLS 1.2 via une entrée de registre. Enregistrez le texte suivant en tant que UseStrongCrypto.reg et l’importer dans chaque serveur Office Online. Une fois importé, redémarrez chaque serveur Office Online de votre batterie.

Windows Registry Editor Version 5.00

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

“SchUseStrongCrypto”=dword:00000001

Connexion d’Office Online Server à SharePoint 2019

Une fois que notre batterie de serveurs Office Online est opérationnelle, nous devons la connecter à

SharePoint Server 2019. Le processus est assez simple. À partir de n’importe quel serveur SharePoint dans la batterie de serveurs, exécutez l’applet de commande suivante pour créer la liaison de SharePoint 2019 à Office Online Server :

New-SPWOPIBinding -ServerName office.cobaltatom.com

Si vous utilisez Office Online Server sur HTTP, vous devez ajouter le commutateur – AllowHTTP , comme dans l’exemple suivant:

New-SPWOPIBinding -ServerName office.cobaltatom.com –AllowHTTP

En outre, si vous utilisez Office Online Server sur HTTP, vous devez également configurer le service de jeton de sécurité pour autoriser les connexions via HTTP. Pour ce faire, exécutez le script PowerShell suivant :

$config = (Get-SPSecurityTokenServiceConfig)

$config.AllowOAuthOverHttp = $true

$config.Update()

Le nom de serveur que vous devez donner est le nom de domaine complet de l’URL que vous souhaitez que SharePoint Server utilise pour accéder à Office Online Server, sans http ni https devant. Une fois l’opération terminée, nous devrons indiquer à SharePoint comment appeler correctement cette URL. SharePoint Server connaît quatre zones WOPI :

• -Http interne
• -Https interne (par défaut)
• -Http externe
• -Https externes

La différence entre les zones est la façon dont SharePoint appelle l’URL d’Office Online Server que nous lui avons donnée. Dans la zone interne, SharePoint fera un appel sur le nom court. Étant donné que la valeur par défaut est internal-https, il appelle notre serveur Office Online sur https: // office ; cependant, nous pouvons avoir des erreurs car notre certificat SAN est https: // office. cobaltatom.com . C’est pourquoi nous devons le définir sur external-https en utilisant l’applet de commande suivante :

Set-SPWOPIZone -zone “external-https”

Enfin, vous devez activer l’API SOAP Excel pour l’actualisation planifiée des données avec Excel Online. Pour activer l’API SOAP Excel, exécutez l’applet de commande Windows PowerShell suivante et remplacez l’URL par l’URL de votre batterie Office Online Server :

$Farm = Get-SPFarm

$Farm.Properties.Add(“WopiLegacySoapSupport”, “https://office.cobaltatom. com /x/_vti_bin/ExcelServiceInternal.asmx”) $Farm.Update()

Pour tester que la connexion a été correctement configurée, accédez à n’importe quel site SharePoint et ouvrez un document Office. Ce document devrait s’ouvrir dans le navigateur et vous devriez pouvoir parcourir l’intégralité du document. Testez Office Online Server avec tous les types de documents Office pris en charge, y compris la fonctionnalité de modification, s’il est activé.

L’une des fonctionnalités d’Office Online Server est la prévisualisation des documents directement dans les résultats de la recherche, comme illustré à la figure 9-8.

Figure 9-8. Aperçu des documents Office dans Office Online Server

Pour activer cette fonctionnalité, vous devrez effectuer une analyse complète de vos sources de contenu et les aperçus fonctionneront par la suite. Avec tout configuré, apprenons comment maintenir le serveur Office Online et comment le déboguer en cas de problème.

Maintenance du serveur Office Online

En tant qu’administrateur SharePoint, vous pouvez également être chargé de déboguer et d’appliquer des correctifs à Office Online Server. Heureusement, Office Online Server nous permet d’utiliser des outils auxquels nous sommes déjà habitués, car Office Online Server dispose également d’un journal ULS, et il fonctionne presque exactement de la même manière que celui de SharePoint. Pour connaître l’emplacement de votre Office Online, exécutez simplement l’applet de commande PowerShell suivante :

(Get-OfficeWebAppsFarm).LogLocation

Remarque Par défaut, l’emplacement du journal du serveur Office Online se trouve dans C: \ programData \ Microsoft \ officeWebapps \ Data \ logs \ ulS. 

Les outils d’affichage des journaux ULS tels que UlsViewer fonctionneront également avec Office Online Server, comme illustré à la figure 9-9 .

Figure 9-9. Affichage des journaux ULS avec UlsViewer

Vous pouvez également obtenir plus de détails dans les fichiers journaux ULS en modifiant la verbosité du journal.

Le niveau le plus bas est VerboseEX , qui produira tout, et le niveau le plus élevé est inattendu, qui n’affichera que les erreurs critiques. Pour modifier la verbosité du journal dans votre batterie Office Online Server, exécutez l’applet de commande suivante :

Set-OfficeWebAppsFarm -LogVerbosity Verbose

Notez qu’un redémarrage de chaque machine de la batterie de serveurs Office Online est requis pour que la verbosité du journal soit modifiée. 

Application de correctifs au serveur Office Online

L’application de correctifs au serveur Office Online est très différente de l’application de correctifs à SharePoint Server. Pour appliquer des correctifs à une machine Office Online Server, il doit être supprimé de la batterie de serveurs Office Online dont il fait partie. Si vous corrigez une batterie de serveurs Office Online Server à serveur unique, vous devez simplement supprimer le serveur de la batterie de serveurs à l’aide de l’applet de commande PowerShell suivante :

Remove-OfficeWebAppsMachine

Une fois la machine supprimée, vous pouvez appliquer le correctif, puis recréer la batterie de serveurs Office Online Server en utilisant New-OfficeWebAppsFarm et les mêmes paramètres que ceux que vous avez utilisés initialement pour créer cette batterie de serveurs Office Online.

L’application de correctifs à une batterie de serveurs Office Online multiserveurs ajoute une couche supplémentaire de complexité. Pour conserver la disponibilité d’Office Online Server, vous devez d’abord supprimer l’un des serveurs du pool d’équilibrage de charge, puis le supprimer de la batterie de serveurs Office Online à l’aide de la cmdlet Remove-OfficeWebAppsMachine.

Remarque Vous ne pouvez pas commencer par supprimer la machine principale du serveur Office Online car elle ne peut être supprimée que s’il ne reste aucune autre machine dans la ferme pour savoir quel serveur est votre machine maîtresse, il suffit de lancer le Get- OfficeWebAppsMachine | Sélectionnez l’applet de commande MasterMachineName sur n’importe quel serveur de votre batterie de serveurs Office Online.

Une fois que vous avez supprimé un serveur de la batterie de serveurs, appliquez-y les correctifs, puis recréez la batterie de serveurs à l’aide de l’applet de commande New-OfficeWebAppsFarm et des mêmes paramètres que vous avez initialement utilisés pour créer cette batterie de serveurs Office Online. Pointez l’équilibreur de charge uniquement vers ce serveur, afin que les utilisateurs utilisent le serveur avec la version corrigée d’Office Online Server.

Supprimez les autres serveurs Office Online de l’ancienne batterie de serveurs, appliquez les correctifs, puis joignez-les à ce serveur en exécutant l’applet de commande New-OfficeWebAppsMachine.

Enfin, ajoutez les serveurs restants dans l’équilibreur de charge pour équilibrer la charge.

Prochaines étapes

Avec Office Online Server correctement configuré, dans le chapitre suivant, nous apprendrons comment configurer Workflow Manager afin de fournir des flux de travail modernes dans SharePoint 2019.

CHAPITRE 10 Gestionnaire de workflow

Workflow Manager est un système externe à SharePoint Server mais est utilisé pour les flux de travail avancés créés via SharePoint Designer 2013 ou Visual Studio. Workflow Manager est conçu pour s’exécuter dans une « batterie » Workflow Manager distincte, bien qu’il puisse être colocalisé sur SharePoint.

Configuration initiale

Dans notre conception de topologie, Workflow Manager 1.0 sera installé sur CALWFM01, CALWFM02 et CALWFM03 pour une batterie de serveurs hautement disponible. Workflow Manager prend en charge une architecture d’un, trois ou cinq serveurs dans une batterie de serveurs Workflow Manager. Aucune autre configuration de batterie de serveurs n’est valide.

La batterie de serveurs SharePoint consommera Workflow Manager via le nom DNS « calwfm. lab.cobaltatom.com », qui est une adresse IP virtuelle sur un équilibreur de charge devant les trois serveurs Workflow Manager. L’équilibreur de charge doit écouter sur le port TCP 12290.

Un certificat SSL approuvé, dans ce cas un certificat générique, est utilisé lors de la configuration de Workflow Manager. Ce certificat doit contenir un nom commun du domaine DNS générique qui sera utilisé pour le point de terminaison Workflow Manager ainsi que les autres noms de sujet des serveurs Workflow Manager et enfin, le dernier autre nom de sujet doit correspondre au nom commun du certificat. Installez ce certificat sur tous les serveurs Workflow Manager. Le certificat doit également être approuvé par la batterie de serveurs SharePoint. Workflow Manager 1.0 prend en charge SQL Server 2016 et SQL Server 2017. Cette installation utilisera SQL Server 2017 avec l’écouteur AlwaysOn de «caspag». lab.cobaltatom.com ».

Workflow Manager est installé via Web Platform Installer (WebPI), qui est exécuté sur chacun des serveurs Workflow Manager.

Astuce WebPI nécessite une connexion Internet pour télécharger les produits applicables. WebPI peut être téléchargé à partir de www.microsoft.com/web/ Downloads / Platform.aspx . Ce chapitre ne traite pas d’une installation hors ligne 

de Workflow Manager. Les instructions d’installation hors ligne sont disponibles sur https: //

docs.microsoft.com/en-us/previous-versions/dotnet/workflow- manager / jj906604 ( v% 3dazure.10).

Dans cette installation, nous allons commencer avec Service Bus. Recherchez et sélectionnez « Windows Azure Pack : Service Bus 1.1 avec prise en charge TLS 1.2» uniquement, comme illustré dans la figure 10-1. Cela va également installer d’autres dépendances, comme nécessaire.

Figure 10-1. Installation de Service Bus 1.1

Une fois l’installation des composants Service Bus 1.1 terminée, recherchez « Workflow Manager » dans Web Platform Installer. Recherchez et sélectionnez « Actualisation de Workflow Manager 1.0 (CU2) », comme illustré à la figure 10-2.

Figure 10-2. Installation de l’actualisation de Workflow Manager

Une fois l’installation du package d’actualisation de Workflow Manager 1.0 (CU2) terminée, vous pouvez être invité à exécuter l’assistant de Workflow Manager. Fermez plutôt l’assistant, puis fermez et rouvrez le programme d’installation de la plateforme Web. Cette opération est effectuée afin que le programme d’installation de la plateforme Web détecte que Service Bus 1.1 et Workflow Manager 1.0 sont installés.

Encore une fois, recherchez « Workflow Manager ». Recherchez et sélectionnez « Workflow Manager 1.0 Cumulative Update 5 » comme indiqué dans la figure 10-3 et installez-le. Fermez l’assistant Workflow Manager, si vous y êtes invité, ainsi que le programme d’installation de la plateforme Web.

Figure 10-3. Workflow Manager 1.0 CU3

Pendant le processus d’installation, les composants Windows Fabric V1 RTM et IIS seront également installés automatiquement.

Répétez les étapes d’installation pour les deux serveurs Workflow Manager restants.

Avant de déployer Workflow Manager, ajoutez le compte de service en tant qu’administrateur local à chaque serveur Workflow Manager.

Pour créer la batterie de serveurs Workflow Manager, nous utiliserons le script PowerShell suivant, CreateWFMFarm.ps1 :

$ErrorActionPreference = “Stop”

$ra = ConvertTo-SecureString “Password1!” -AsPlainText -Force

$certThumbprint = ‘8E6DC4D0A2DEA825EA49AF2C3BEA5ABE46AEC432’$admins =

‘BUILTIN\Administrators’

$svcAcct = ‘s-wfm@LAB’

$mgUsers = ‘s-wfm@LAB’,’trevor.seward@LAB’,’vlad.catrinescu@LAB’

$baseConnectionString = ‘Data Source=caspag.lab.cobaltatom.com;Integrated

Security=True;Encrypt=False;Initial Catalog=’

$sbConnString = $baseConnectionString + ‘SbManagementDB;’

$sbGateConnString = $baseConnectionString + ‘SbGatewayDatabase;’

$sbMsgConnString = $baseConnectionString + ‘SBMessageContainer01;’

$wfConnString = $baseConnectionString + ‘WFManagementDB;’

$wfInstConnString = $baseConnectionString + ‘WFInstanceManagementDB;’

$wfResConnString = $baseConnectionString + ‘WFResourceManagementDB;’

Les variables qui doivent être ajustées dans ce script pour votre déploiement particulier sont les suivantes :

• $ ra
• Cette variable contient le mot de passe du compte RunAs. Notez que ce script utilise le même compte RunAs pour les batteries Service Bus et Workflow Manager.
• $ certThumbprint
• Il contient l’empreinte numérique du certificat du certificat SSL valide utilisé par la batterie de serveurs Workflow Manager.

Conseil Vous pouvez trouver l’empreinte numérique du certificat en exécutant dir cert: \ LocalMachine \ My dans PowerShell. 

• $ svcAcct
  • Il s’agit du RunAs ou du compte de service des batteries Service Bus et Workflow Manager. Notez que ce script utilise un seul compte pour exécuter les deux services.
• $ mgUtilisateurs
  • Il s’agit d’une liste d’utilisateurs séparés par des virgules au format nom d’utilisateur @ DOMAIN qui disposeront de droits d’administration sur les batteries de serveurs Service Bus et Workflow Manager.
• $ baseConnectionString
  • Cette variable contient le nom de domaine complet du groupe de disponibilité SQL Server AlwaysOn . Il peut également être ajusté pour utiliser un alias SQL ou un nom SQL Server, ainsi que le nom de l’instance si nécessaire.

Toutes les autres variables peuvent être laissées telles quelles.

Add-Type -Path “C: \ Program Files \ Workflow Manager \ 1.0 \ Workflow \ Artifacts \

Microsoft.ServiceBus.dll ”

Write-Host “Creating Service Bus farm…”

New-SBFarm -SBFarmDBConnectionString $sbConnString `

-InternalPortRangeStart 9000 -TcpPort 9354 -MessageBrokerPort 9356

-RunAsAccount $svcAcct -AdminGroup $admins `

-GatewayDBConnectionString $sbGateConnString -FarmCertificateThumbprint

$certThumbprint `

-EncryptionCertificateThumbprint $certThumbprint

-MessageContainerDBConnectionString $sbMsgConnString

New-SBFarm creates the ServiceBus farm and ServiceBus databases.

Write-Host “Creating Workflow Manager farm…”

New-WFFarm -WFFarmDBConnectionString $wfConnString `

-RunAsAccount $svcAcct -AdminGroup $admins -HttpsPort 12290 -HttpPort 12291 `

-InstanceDBConnectionString $wfInstConnString `

-ResourceDBConnectionString $wfResConnString

-OutboundCertificateThumbprint $certThumbprint `

-SslCertificateThumbprint $certThumbprint `

-EncryptionCertificateThumbprint $certThumbprint

Write-Host “Adding host to Service Bus farm…”

Add-SBHost -SBFarmDBConnectionString $sbConnString -RunAsPassword $ra

-EnableFirewallRules $true

De même, New-WFFarm crée la batterie de serveurs et les bases de données Workflow Manager. L’étape suivante, Add-SBHost, ajoute ce serveur à la batterie ServiceBus.

Try

{

New-SBNamespace -Name ‘WorkflowDefaultNamespace’ -AddressingScheme

‘Path’ -ManageUsers $mgUsers

Start-Sleep -s 90

}

Catch [system.InvalidOperationException] {}

$SBClientConfiguration = Get-SBClientConfiguration -Namespaces

‘WorkflowDefaultNamespace’

Write-Host “Adding host to Workflow Manager Farm…”

Add-WFHost -WFFarmDBConnectionString $wfConnString -RunAsPassword $ra

-EnableFirewallRules $true `

-SBClientConfiguration $SBClientConfiguration

Write-Host “Completed.”

$ErrorActionPreference = “Continue”

Ces derniers éléments du script créent l’espace de noms ServiceBus et ajoutent ce serveur à la batterie de serveurs Workflow Manager.

Une fois la batterie de serveurs créée, un par un, nous ajouterons les deux serveurs Workflow Manager restants à la batterie de serveurs à l’aide du script ConnectWFMFarm.ps1. Pour ces deux serveurs, le script PowerShell est légèrement plus court. Le script ajoute le serveur à la batterie ServiceBus, puis à la batterie Workflow Manager.

$ErrorActionPreference = “Stop”

$ra = ConvertTo-SecureString “Password1!” -AsPlainText -Force

$mgUsers = ‘s-wfm@LAB’,’trevor.seward@LAB’,’vlad.catrinescu@LAB’

$baseConnectionString = ‘Data Source=caspag.lab.cobaltatom.com;Integrated

Security=True;Encrypt=False;Initial Catalog=’

$sbConnString = $baseConnectionString + ‘SbManagementDB;’

$wfConnString = $baseConnectionString + ‘WFManagementDB;’

Add-Type -Path “C:\Program Files\Workflow Manager\1.0\Workflow\Artifacts\

Microsoft.ServiceBus.dll”

Write-Host “Adding host to Service Bus Farm…”

Add-SBHost -SBFarmDBConnectionString $sbConnString -ExternalBrokerUrl “sb://$($farmDomain)” -RunAsPassword $ra -EnableFirewallRules $true

-Verbose

$ErrorActionPreference = “Continue”

try {

ChaPter 10 WOrkflOW MaNager

$SBClientConfiguration = Get-SBClientConfiguration -Namespaces

‘WorkflowDefaultNamespace’ -Verbose

}

Catch [system.InvalidOperationException] {}

Write-Host -ForegroundColor Yellow “Adding host to Workflow Manager Farm…”

Add-WFHost -WFFarmDBConnectionString $wfConnString -RunAsPassword $ra

-EnableFirewallRules $true `

-SBClientConfiguration $SBClientConfiguration -Verbose

Write-Host -ForegroundColor Green “Completed.”

$ErrorActionPreference = “Continue”

Comme pour le script CreateWFMFarm.ps1, les mêmes variables peuvent être ajustées, à l’exception de $ svcAcct et $ certThumbprint. Notez que lors de l’ajout de serveurs supplémentaires, il arrêtera et démarrera le Service Bus et les services dépendants sur tous les serveurs Workflow Manager existants qui font partie de la batterie de serveurs.

La sortie de Get-SBFarm sera similaire à la figure 10-4 et Get-WFFarm sera similaire à la figure 10-5 .

Figure 10-4. La sortie de l’applet de commande Get-SBFarm

Figure 10-5. La sortie de l’applet de commande Get-WFFarm

Une fois le déploiement terminé, vérifiez que les services suivants sont en cours d’exécution sur chaque membre de la batterie :

• Passerelle de bus de service
• Courtier de messages de bus de service
• Fournisseur de ressources de bus de service
• Service hôte Windows Fabric
• Back-end de Workflow Manager

En outre, vérifiez l’état des services via Get-SBFarmStatus, comme illustré à la figure 10-6 , et Get-WFFarmStatus, comme illustré à la figure 10-7 .

Figure 10-6. La sortie de Get-SBFarmStatus

Figure 10-7. La sortie de Get-WFFarmStatus

La dernière étape de la configuration de Workflow Manager consiste à ajouter les bases de données au groupe de disponibilité sur le groupe de disponibilité SQL Server 2016 AlwaysOn. Effectuez une sauvegarde complète de trois bases de données Service Bus et de trois bases de données Workflow Manager :

• SbGatewayDatabase
• SbManagementDB
• SBMessageContainer01
• WFInstanceManagementDB
• WFManagementDB
• WFResourceManagementDB

Ajoutez les bases de données aux répliques restantes, puis ajoutez le compte de service Service Bus et Workflow Manager aux connexions de noeud secondaire.

Configuration SSL

Comme nous avons imposé l’utilisation de TLS 1.2 pour SharePoint, nous devons activer le cryptage fort via une entrée de registre. Enregistrez le texte suivant en tant que UseStrongCrypto.reg et importez-le dans chaque serveur Workflow Manager. Une fois importé, redémarrez chaque serveur Workflow Manager.

Éditeur de registre Windows version 5.00

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

“SchUseStrongCrypto” = dword: 00000001

Maintenant que la configuration de la batterie de serveurs Workflow Manager est terminée, nous allons passer à la configuration et au test de l’intégration de SharePoint Server 2019 avec Workflow Manager.

Intégration de SharePoint Server Workflow Manager

Avant de configurer l’intégration avec Workflow Manager dans la batterie de serveurs SharePoint, vous devez installer le client Workflow Manager. Le client peut être téléchargé directement à partir de Microsoft sans WebPI. La version actuellement disponible à la date de publication de cet article est la mise à jour cumulative de Workflow Manager Client 4. Cette mise à jour peut être installée sans déployer les versions précédentes de Workflow Manager Client.

Notez que la mise à jour cumulative 4 du client Workflow Manager est disponible sur www. microsoft.com/en-us/download/details.aspx?id=55643 . Téléchargez le fichier WorkflowManagerClient_x64.msi.

Étant donné que Workflow Manager devra communiquer avec SharePoint via des requêtes HTTPS, nous devons accorder au compte de service Workflow Manager, LAB \ s- wfm dans ce cas, avec un contrôle total sur les applications Web SharePoint où Workflow Manager sera utilisé. Parce que nous n’avons qu’une seule application Web pour l’équipe, la publication et d’autres sites, nous n’accorderons ce droit que sur https://sharepoint.learn-sp2016.com. À l’aide de SharePoint Management Shell, accordez au compte de service le contrôle total via la stratégie utilisateur.

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

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

$policy = $zp.Add(“i:0#.w|LAB\s-wfm”, “Workflow Manager”)

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

$policy.PolicyRoleBindings.Add($policyRole)

$wa.Update()

Workflow Manager ne peut être configuré qu’avec SharePoint via SharePoint Management Shell. À partir de SharePoint Management Shell, enregistrez Workflow Manager à l’aide de l’URL à charge équilibrée sur le port 12290 (port SSL par défaut pour Workflow Manager).

Register-SPWorkflowService -SPSite https://sp.cobaltatom.com

-WorkflowHostUri https://calwfm.lab.cobaltatom.com:12290

Notez que bien que Register-SPWorkflowService ait besoin d’un site SharePoint de validation pour s’enregistrer, une fois que Workflow Manager a été enregistré avec succès, il sera enregistré pour la batterie de serveurs entière, pas seulement pour la collection de sites spécifiée.

Remarque Il peut être nécessaire de redémarrer les serveurs SharePoint afin d’enregistrer complètement les binaires de Workflow Manager. 

Maintenant que Workflow Manager a été intégré à SharePoint, la prochaine étape consistera à effectuer un test simple avec SharePoint Designer 2013.

Test de Workflow Manager avec SharePoint Designer 2013

Pour tester Workflow Manager avec SharePoint Designer 2013, provisionnez une nouvelle collection de sites à l’aide du modèle de site d’équipe classique. Si vous utilisez un site existant, assurez-vous que la fonction de site “Fonctionnalité de type de contenu de tâche de workflow” a été activée.

Sur le site, créez une nouvelle liste nommée WorkflowTest. Aucune configuration supplémentaire sur la liste ne doit être effectuée pour ce test.

À l’aide de SharePoint Designer 2013 à partir d’un ordinateur client, connectez-vous à la collection de sites et créez un nouveau flux de travail de liste. Donnez un nom au flux de travail et sélectionnez le flux de travail SharePoint 2013 sous Type de plate-forme, comme illustré à la figure 10-8.

Figure 10-8. Création d’un nouveau flux de travail SharePoint 2013 pour les tests

Insérez une action de « Log to History List » et ajoutez du texte à l’action. Sous Transition vers la scène, sélectionnez Fin du workflow. Dans la figure 10-9, le texte de la connexion à la liste d’historique est « Test de flux de travail ».

Figure 10-9. Les étapes de l’exemple de workflow

Sous Paramètres du flux de travail, cochez la case en regard de « Démarrer ce flux de travail automatiquement lorsqu’un élément est créé », comme le montre la figure 10-10. Lorsque nous créons une entrée sur la nouvelle liste, elle démarre automatiquement le workflow pour nous. Cliquez sur le bouton Publier pour publier le flux de travail sur SharePoint.

Figure 10-10. Activation du workflow pour démarrer automatiquement lorsqu’un nouvel élément est créé

À partir de SharePoint, accédez à la liste personnalisée. Créez un nouvel élément, en spécifiant une valeur pour le titre. Le workflow démarre automatiquement. Surveillez l’état en cliquant sur le bouton Afficher les actions à côté de l’élément de liste et accédez à Plus et Workflows. Cette page affiche l’état du flux de travail et vous permet de le démarrer manuellement si nécessaire, comme le montre la figure 10-11.

Figure 10-11. Le workflow s’est terminé sans erreur

En cliquant sur le lien ExampleWF de la figure 10-11, vous obtiendrez des détails supplémentaires sur le flux de travail, y compris les éventuelles erreurs lors de l’exécution. La figure 10-12 affiche une exécution de workflow réussie, mais en cas d’erreur, une icône d’information s’affiche à côté de l’état interne. Le survol de l’icône affiche une fenêtre contextuelle avec l’erreur rencontrée.

Figure 10-12. Détails sur la bonne exécution du workflow

Il peut également être utile de surveiller les journaux ULS dans la batterie de serveurs. Utilisation du filtre ULSViewer de Microsoft dans la catégorie « Services de workflow », qui fournira des informations détaillées sur les éventuelles erreurs. Les erreurs sont également enregistrées dans la base de données Workflow Manager WFInstanceManagementDB . À l’aide de SQL Server Management Studio, connectez-vous à l’instance SQL Server qui héberge WFInstanceManagementDB . Exécutez la requête suivante pour récupérer les informations supplémentaires qui seront principalement contenues dans la colonne Message :

Use [WFInstanceManagementDB]

SELECT * FROM DebugTraces (NoLock)

ORDER BY CreationTime DESC

Ceci termine le déploiement de l’intégration de Workflow Manager et de SharePoint Server 2016.

Prochaines étapes

Avec Workflow Manager configuré pour permettre la création de flux de travail SharePoint 2013, le chapitre suivant examinera l’intégration de SharePoint Server 2019 et Exchange Server 2016.

CHAPITRE 11 Intégration SharePoint et Exchange

Bien que SharePoint Server 2019 à lui seul offre une grande valeur à chaque entreprise qui décide de l’installer, il peut offrir plus de fonctionnalités lorsqu’il est intégré à d’autres serveurs de la suite Office tels qu’Exchange Server 2019.

En intégrant Exchange Server 2019 à SharePoint Server 2019, vous activez des fonctionnalités telles que la boîte aux lettres du site et les pièces jointes modernes. Si vous êtes sur SharePoint Server 2013 et avez sauté 2016, notez que le service de gestion du travail de SharePoint 2013 n’existe pas dans SharePoint Server 2019 car il a été supprimé depuis SharePoint Server 2016 !

Présentation de la boîte aux lettres du site

La boîte aux lettres de site a été introduite pour la première fois dans Exchange 2013 / SharePoint 2013 et vise à accroître la collaboration ainsi que la productivité des utilisateurs lorsqu’ils traitent à la fois des documents et des e-mails pour la même tâche. Traditionnellement, les e-mails sont stockés dans Exchange Server et consommés dans Outlook, tandis que les documents sont stockés et consommés dans SharePoint. Cela crée deux silos différents où les utilisateurs doivent vérifier les informations. En implémentant la boîte aux lettres de site, vous pouvez créer une boîte aux lettres Exchange pour des sites SharePoint spécifiques, permettant à vos utilisateurs de consommer à la fois des documents SharePoint et des e-mails Exchange au même endroit.

Remarque Les boîtes aux lettres de site sont obsolètes dans SharePoint Server 2019 mais sont toujours prises en charge. 

Une fois la configuration réussie, la boîte aux lettres de site devient une application (comme une liste ou une bibliothèque de documents) qui peut être ajoutée dans la collection de sites, comme illustré à la figure 11-1.

Figure 11-1. Ajouter une boîte aux lettres de site à un site SharePoint

Il est important de savoir qu’une seule boîte aux lettres de site peut être ajoutée par site SharePoint. Une fois créée, la boîte aux lettres du site se verra attribuer une adresse de messagerie suivant la convention de dénomination suivante : SM-SiteName@domain.tld. La boîte aux lettres de site que nous avons créée dans un site appelé Site d’équipe est nommée « Site d’équipe » et peut être envoyée par courriel à « SM-TeamSite@cobaltatom.com ». La boîte aux lettres du site est accessible à partir du navigateur, comme illustré à la figure 11-2.

Figure 11-2. Affichage de la boîte aux lettres du site dans le navigateur

La boîte aux lettres du site est également accessible directement à partir d’Outlook. Lorsqu’un utilisateur a accès à une boîte aux lettres de site, celle-ci est automatiquement ajoutée au client Outlook de cet utilisateur, comme illustré à la figure 11-3.

Figure 11-3. La boîte aux lettres du site « Site d’équipe » dans Outlook 2019

Un autre avantage de la boîte aux lettres du site est que les bibliothèques de documents affichées dans le lancement rapide seront également disponibles sous forme de dossier dans votre client Outlook. Les utilisateurs pourront ouvrir rapidement des documents dans leurs applications clientes, ainsi que glisser-déposer des documents dans Outlook, qui seront automatiquement téléchargés dans leur bibliothèque de documents SharePoint. La figure 11-4 montre la bibliothèque de documents « Présentations » dans Outlook 2019.

Figure 11-4. Une bibliothèque de documents dans Outlook 2019

Maintenant que nous savons ce qu’est une boîte aux lettres de site, dans la section suivante, nous allons apprendre à la configurer.

Configurer la boîte aux lettres du site SharePoint Server 2019

Le processus de configuration de la boîte aux lettres du site SharePoint Server 2019 est assez

simple. Nous devrons d’abord installer l’API managée Exchange Web Services (EWS) 2.2 sur tous les serveurs de notre batterie de serveurs. Cela installera les outils requis que SharePoint utilisera pour communiquer avec Exchange Server 2019. L’étape suivante consistera ensuite à créer une approbation entre nos SharePoint Server 2019 et Exchange Server 2019 afin qu’ils puissent échanger des informations en toute sécurité. Enfin, nous devrons activer la fonctionnalité de boîte aux lettres du site sur les sites sur lesquels nous voulons utiliser cette fonctionnalité.

Il est important de savoir que les boîtes aux lettres du site ne fonctionneront que sur les applications Web qui utilisent SSL sur leur zone par défaut. De plus, pour que les boîtes aux lettres de site fonctionnent, l’application de service de profil utilisateur doit fonctionner et les utilisateurs doivent être synchronisés à partir d’Active Directory. Enfin, l’application App Management Service doit être configurée. Nous avons couvert ces deux exigences dans les chapitres précédents.

Installation de l’API gérée des services Web Exchange

Pour préparer nos serveurs SharePoint, nous devons télécharger l’API gérée des services Web Exchange (EWS) sur chaque serveur de notre batterie de serveurs SharePoint. Vous pouvez télécharger EWS Managed API 2.2 à partir du Centre de téléchargement Microsoft :

• API gérée par les services Web Microsoft Exchange 2.2 (www.microsoft. Com/en-ca/download/details.aspx?Id=42951)

Une fois téléchargé, exécutez la commande suivante à partir d’une invite de commandes élevée ou d’une fenêtre PowerShell :

msiexec /i EwsManagedApi.msi addlocal=”ExchangeWebServicesApi_Feature, ExchangeWebServicesApi_Gac”

Une fois l’installation terminée, vous devrez effectuer une réinitialisation IIS sur chaque serveur de la batterie. Une fois les prérequis configurés, il est temps de configurer SharePoint 2019 pour approuver Exchange Server.

Établir la confiance et les autorisations OAuth sur SharePoint

Dans cette section, nous allons configurer notre serveur Exchange en tant que nouvel émetteur de jetons de sécurité de confiance SP, ainsi que d’ajouter une propriété dans le sac de propriétés de l’application Web. Nous le ferons en utilisant des scripts PowerShell fournis par Microsoft. Il existe deux scripts que nous devons créer sur l’un de nos serveurs SharePoint. Le premier script est nommé Set-SiteMailboxConfig.ps1 et peut le deuxième script est appelé Check-SiteMailboxConfig.ps1.

Remarque Les deux scripts peuvent être téléchargés à partir de technet sur le lien suivant : https://docs.microsoft.com/en-us/sharepoint/administration/ configure-site-mailboxes-in sharepoint .

Le script Set-SiteMailboxConfig est le script qui configurera tout, tandis que Check-SiteMailboxConfig.ps1 vérifiera simplement que la configuration est valide avant d’activer la fonction de batterie de serveurs CollaborationMailbox.

Pour exécuter Set-SiteMailboxConfig, ouvrez SharePoint Management Shell en tant qu’administrateur et exécutez l’applet de commande suivante :

.\Set-SiteMailboxConfig.ps1 -ExchangeSiteMailboxDomain

-ExchangeAutodiscoverDomain

Où le est le nom de domaine dans lequel vos adresses de boîte aux lettres Exchange doivent être créées et le est le nom de domaine complet de votre serveur Exchange. Le paramètre -ExchangeAutodiscoverDomain n’est requis que si la découverte automatique n’est pas correctement configurée dans votre DNS. Si le paramètre est laissé vide, le script le définira par défaut sur la découverte automatique. . . Un moyen simple de le tester consiste à naviguer vers https://autodiscover./autodiscover/metadata/ json/1. Par exemple, dans notre environnement, nous l’avons validé en accédant à https:// autodiscover.cobaltatom.com/autodiscover/metadata/json/1.

Voici l’applet de commande que nous avons exécutée dans notre environnement et nous n’avons pas spécifié ExchangeAutodiscoverDomain car la découverte automatique est correctement configurée dans le DNS :

.\Set-SiteMailboxConfig.ps1 -ExchangeSiteMailboxDomain cobaltatom.com

Si vous ne souhaitez l’activer que sur une certaine application Web, vous pouvez ajouter le paramètre – WebApplication au script, par exemple :

.\Set-SiteMailboxConfig.ps1 -ExchangeSiteMailboxDomain cobaltatom.com –WebApplication https://sp.cobaltatom.com

Avec tout ce qui est configuré côté SharePoint, nous devons également configurer Exchange Server.

Configurer Exchange Server 2019 pour les boîtes aux lettres de site

La dernière partie de la configuration de la boîte aux lettres de site consiste à configurer Exchange Server 2019 pour les boîtes aux lettres de site. Les scripts requis pour la configuration sont inclus dans chaque installation d’Exchange Server et vous les trouverez dans le chemin suivant : «C: \ Program Files \ Microsoft \ Exchange Server \ V15 \ Scripts».

Comme nous avons imposé l’utilisation de TLS 1.2 pour SharePoint, nous devons activer le cryptage fort comme indiqué dans l’Avis de sécurité Microsoft 2960358. Selon l’avis, il peut être nécessaire d’activer la prise en charge de TLS 1.2 sur Windows Server via une entrée de registre. Enregistrez le texte suivant en tant que UseStrongCrypto.reg et importez-le dans chaque serveur Office Online. Une fois importé, redémarrez chaque Exchange dans votre organisation Exchange. Un redémarrage est nécessaire pour que la modification prenne effet.

Windows Registry Editor Version 5.00

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

“SchUseStrongCrypto”=dword:00000001

Après le redémarrage, ouvrez Exchange Management Shell en tant qu’administrateur et assurez-vous que vous vous trouvez dans cet emplacement de script et exécutez l’applet de commande PowerShell suivante :

.\Configure-EnterprisePartnerApplication.ps1 -ApplicationType Sharepoint -AuthMetadataUrl https:///_layouts/15/metadata/json/1

Où est la collection de sites racine de l’application Web sur laquelle vous avez activé la boîte aux lettres de site. Dans notre environnement, l’applet de commande que nous avons exécutée était

.\Configure-EnterprisePartnerApplication.ps1 -ApplicationType Sharepoint

-AuthMetadataUrl https://sp.cobaltatom.com/_layouts/15/metadata/json/1

Le script doit indiquer que la configuration a réussi. Pour tester la fonctionnalité de boîte aux lettres de site, accédez à un site SharePoint et essayez d’ajouter une nouvelle boîte aux lettres de site à partir de la page « Ajouter une application ». Après avoir ajouté la boîte aux lettres de site, SharePoint affiche une note indiquant que la création de la boîte aux lettres de site peut prendre jusqu’à 30 minutes, comme illustré à la figure 11-5 .

Figure 11-5. La boîte aux lettres du site a été créée

Une fois que la boîte aux lettres du site est prête à être utilisée, chaque propriétaire de site recevra un e-mail l’informant de l’adresse électronique de la boîte aux lettres du site ainsi qu’un lien pour en savoir plus sur ce qu’est une boîte aux lettres du site. Un exemple de cet e-mail de bienvenue est illustré à la figure 11-6.

Figure 11-6. Site Mailbox Bienvenue e-mail

Par défaut, tous les propriétaires du site et les membres du site auront accès à la boîte aux lettres du site et pourront consulter et envoyer des e-mails.

Avec la boîte aux lettres du site configurée, une autre fonctionnalité que nous pouvons activer en intégrant ensemble SharePoint Server et Exchange Server est la synchronisation de photos Exchange.

Synchronisation de photos Exchange

Le service de profil utilisateur est capable de synchroniser des photos d’Exchange Server 2013, Exchange Server 2016 ou Exchange Server 2019 au lieu de l’attribut thumbnailPhoto dans Active Directory. Cela permet d’obtenir des images de qualité nettement supérieure.

Comme nous avons déjà effectué les conditions préalables précédentes en installant l’API des services Web Exchange sur SharePoint et en configurant OAuth entre Exchange Server et SharePoint à l’aide du script Configure-EnterprisePartnerApplication.ps1, ces étapes ne seront pas répétées ici. À la place, seules les étapes nécessaires à la synchronisation des photos Exchange seront présentes.

Tout d’abord, validez le domaine de découverte automatique pour Exchange Server. Cela peut être fait à l’aide de la console de gestion Exchange. Dans cet exemple, le nom du serveur Exchange est CAEXCH02.

(Get-AutodiscoverVirtualDirectory -Server CAEXCH02).InternalUrl.AbsoluteUri

Cela fournira le chemin complet de l’URL de découverte automatique.

Sur SharePoint, à l’aide de SharePoint Management Shell, configurez le service de jeton de sécurité, en définissant la propriété HybridStsSelectionEnabled sur true.

$sts=Get-SPSecurityTokenServiceConfig

$sts.HybridStsSelectionEnabled = $true

$sts.AllowMetadataOverHttp = $false

$sts.AllowOAuthOverHttp = $false

$sts.Update()

L’étape suivante consiste à récupérer l’émetteur de jeton de sécurité sécurisé Exchange et à appliquer le principal de l’application à notre hôte MySite. Dans cette batterie, l’hôte MySite est https: // sp-my. cobaltatom.com .

$exchange = Get-SPTrustedSecurityTokenIssuer -Identity “Exchange”

$app = Get-SPAppPrincipal -Site https://sp-my.cobaltatom.com

-NameIdentifier $exchange.NameId

$site = Get-SPSite https://sp-my.cobaltatom.com

Set-SPAppPrincipalPermission -AppPrincipal $app -Site $site.RootWeb -Scope

SiteSubscription -Right FullControl -EnableAppOnlyPolicy

En continuant à utiliser SharePoint Management Shell, placez l’application Web MySite dans une variable, définissez la propriété ExchangeAutodiscoverDomain sur l’URL de découverte automatique, les propriétés d’expiration des photos et enfin activez l’importation de photos utilisateur.

$wa.Properties[“ExchangeAutodiscoverDomain”] = https://autodiscover.

cobaltatom.com

$wa.UserPhotoErrorExpiration = 1

$wa.UserPhotoExpiration = 12

$wa.UserPhotoImportEnabled = $true

$wa.Update()

Une fois cette opération terminée, chaque utilisateur doit visiter la page À propos de moi pour établir la session OAuth entre Exchange et SharePoint pour importer l’image dans l’hôte MySite.

Il peut y avoir une variété d’erreurs présentes dans le journal ULS pour l’importation d’image. Pour filtrer uniquement les erreurs spécifiques, définissez la catégorie sur « Intégration Exchange ». Cela réduira la portée du processus d’importation lorsqu’un utilisateur visite sa page À propos de moi.

Comme mentionné précédemment, les images sont importées lorsqu’un utilisateur visite sa propre page À propos de moi (profil). Si le processus d’importation rencontre une erreur, SharePoint ne réessayera pas pendant le nombre d’heures spécifié dans UserPhotoErrorExpiration. De même, si l’importation de photos réussit, SharePoint ne recherchera pas de nouvelle photo pendant le nombre d’heures spécifié dans UserPhotoExpiration. La valeur du moment où la dernière importation a eu lieu est l’horodatage de la photo dans l’hôte MySite. Cela inclut l’image de personne générique lorsqu’une importation de photo échoue.

Lorsqu’une photo a été importée avec succès, elle s’affiche pour cet utilisateur. Si vous recherchez le profil de l’utilisateur dans l’application de service de profil utilisateur, comme le montre la figure 11-7 , l’image ne peut pas être modifiée par l’administrateur via la modification du profil utilisateur.

Figure 11-7. La propriété Image lorsque la photo de profil d’un utilisateur est synchronisée à partir d’Exchange

De plus, si l’utilisateur modifie son propre profil via l’hôte MySite pour modifier sa photo, il sera redirigé vers Outlook sur le Web.

Prochaines étapes

L’intégration entre Exchange et SharePoint étant maintenant terminée, dans le chapitre suivant, nous apprendrons comment déployer les services de Business Intelligence dans SharePoint 2019.

CHAPITRE 12 Business Intelligence avec SharePoint 2019

Business Intelligence est l’une des catégories qui a vu le plus de fonctionnalités supprimées dans SharePoint Server 2019. Alors que SharePoint Server était la plate-forme recommandée pour publier des rapports Business Intelligence, la plupart des technologies dépendaient de Silverlight pour afficher les résultats, et les rapports n’étaient pas conviviaux à construire. La prise en charge de Silverlight prenant officiellement fin en octobre 2021, la plupart des fonctionnalités de Business Intelligence auxquelles nous sommes habitués dans SharePoint ne sont plus disponibles. Le tableau 12-1 présente un résumé des fonctionnalités obsolètes et supprimées de SharePoint Server 2019.

Tableau 12-1. Fonctionnalités supprimées et obsolètes dans SharePoint Server 2019

Fonctionnalité	Statut
Tableau de bord de gestion PowerPivot	Supprimé
Galerie PowerPivot	Supprimé
Power Pivot pour SharePoint	Supprimé
Vue de puissance	Supprimé
Connexions aux fichiers BISM	Supprimé
PerformancePoint – Arbres de décomposition	Supprimé
Prévue classeur données rafraîchissement	Supprimé
Classeur comme source de données	Supprimé
Mode intégré de SQL Server Reporting Services	Supprimé
PerformancePoint	Obsolète

Bien que certaines fonctionnalités soient obsolètes, nous pouvons toujours publier des rapports de Business Intelligence dans SharePoint pour intégrer des rapports importants, avec le reste de notre espace de travail numérique. Voyons les deux options principales !

Configuration de SQL Server Reporting Services

Bien que SQL Server Reporting Services (SSRS) – Mode intégré ait été supprimé, vous pouvez toujours installer SSSRS en mode natif et l’intégrer à SharePoint. Une limitation majeure du composant WebPart que Microsoft fournit pour intégrer SSRS dans SharePoint 2019 ne prend en charge que les pages classiques et ne fonctionnera pas sur les pages modernes trouvées dans une équipe moderne ou des sites de communication. Une autre exigence est que le service de jetons de réclamation vers Windows (C2WTS) doit être démarré et configuré pour la délégation Kerberos contrainte.

Conseil Vous pouvez en savoir plus sur la configuration des revendications pour le service de jetons Windows (C2WTS) et Reporting Services en cliquant sur le lien suivant: https: // docs. 

microsoft.com/en-us/sql/reporting-services/install-windows/ claims-to-windows-token-service-c2wts-and-reporting- services? view = sql-server-2017 .

Microsoft SQL Server 2017 Reporting Services peut être téléchargé à partir du Centre de téléchargement Microsoft à l’ adresse www.microsoft.com/en-us/download/details.

aspx? id = 55252 . Une fois les fichiers binaires téléchargés, ouvrez l’exécutable et cliquez sur Installer Reporting Services comme illustré à la figure 12-1.

Figure 12-1. Écran de démarrage de SQL Server 2017 Reporting Services

L’installation de SQL Server 2017 Reporting Services Server est assez facile et ne nécessite que quelques clics ainsi que la clé de produit qui peut être obtenue auprès de votre centre de licences. Une fois l’installation binaire terminée, vous devrez peut-être redémarrer le serveur comme vous pouvez le voir sur la figure 12-2.

Figure 12-2. Avertissement de redémarrage

Une fois le serveur redémarré, vous devez ouvrir le Report Server

Configuration Manager et configurez SQL Report Server comme illustré à la figure 12-3.

Figure 12-3. Gestionnaire de configuration de SQL Report Server

Étant donné que cet article se concentre sur SharePoint, nous ne passerons pas en revue toutes les différentes configurations possibles de SSRS en mode natif. Avant de poursuivre, vous devez vous assurer que le serveur SSRS est opérationnel et que les URL du service Web et du portail Web sont accessibles à partir des clients et des serveurs SharePoint. Nous vous recommandons également de configurer les URL des services Web et du portail Web SSRS pour utiliser https.

La prochaine tâche consistera à installer la solution de ferme Report Viewer sur notre ferme. Étant donné que cela sera déployé en tant que solution de batterie de serveurs, il est recommandé de procéder à l’installation pendant une période de maintenance.

Remarque Le composant WebPart Visionneuse de rapports Microsoft pour Microsoft SharePoint peut être téléchargé à partir du Centre de téléchargement Microsoft à l’ adresse www.microsoft.com/en- us / download / details.aspx? Id = 55949 . 

Une fois que vous avez téléchargé le fichier WSP sur le serveur, exécutez l’applet de commande PowerShell suivante à partir d’un environnement SharePoint Management Shell élevé pour ajouter la solution de batterie de serveurs à la batterie de serveurs :

Add-SPSolution -LiteralPath “{path to file}\ReportViewerWebPart.wsp”

Ensuite, nous installerons la solution sur les applications Web requises avec l’applet de commande PowerShell comme suit :

Install-SPSolution -Identity ReportViewerWebPart.wsp -GACDeployment

-WebApplication {URL to web application}

Vous pouvez ensuite activer le composant WebPart Visionneuse de rapports manuellement sur chaque collection de sites dans l’application Web, ou vous pouvez également le faire via PowerShell avec l’applet de commande Enable-SPFeature PowerShell, comme illustré ci-dessous :

Enable-SPFeature -identity “ReportViewerWebPart” -URL {Site Collection URL}

Une fois la fonctionnalité activée, le composant WebPart Report Viewer sera disponible dans une nouvelle catégorie de composants WebPart appelée SQL Server Reporting Services (mode natif), comme illustré à la figure 12-4.

Figure 12-4. Le composant WebPart Visionneuse de rapports

Une fois le composant WebPart ajouté, à partir des propriétés du composant WebPart illustrées à la figure 12-5 , vous devez ajouter les informations pour le serveur SSRS ainsi que le rapport, ainsi que toute autre information telle que les paramètres nécessaires pour afficher correctement le rapport .

Figure 12-5. Configuration du composant WebPart Visionneuse de rapports

C’est pour SQL Server Reporting Services en mode natif ! Voyons maintenant Power BI Server.

Serveur Power BI

Une autre option pour créer des rapports Business Intelligence sur site est Power BI Server, une version du service Power BI de Microsoft d’Office 365 qui s’exécute complètement sur site. L’installation de Power BI Server est très similaire à SQL Server Reporting Services et partage la plupart des mêmes configurations. Une fois installé, il faudra un redémarrage du serveur comme le montre la figure 12-6.

Figure 12-6. Installation de Power BI Report Server

Une fois configuré, les utilisateurs peuvent utiliser Power BI Desktop pour créer de beaux rapports réactifs et les publier dans Power BI Report Server. Dans SharePoint, vous pouvez utiliser le composant WebPart incorporé dans les sites modernes ou l’éditeur de contenu dans les sites classiques pour incorporer un iframe de rapport Power BI dans une page SharePoint. Dans la figure 12-7, j’utilise le code iframe suivant afin d’incorporer un rapport PowerBI dans un site de communication SharePoint moderne à l’aide du composant WebPart incorporé:

Figure 12-7. Rapport Power BI Server dans SharePoint Server 2019

Le composant WebPart intégré dans les sites SharePoint modernes ne prend en charge que les iframes sécurisés.Par conséquent, votre serveur de rapports Power BI doit être configuré avec HTTPS et la batterie de serveurs SharePoint et les clients de l’organisation doivent faire confiance au certificat.

Prochaines étapes

Dans ce chapitre, nous avons appris quels services de Business Intelligence ont été supprimés de SharePoint Server 2019, ainsi que comment configurer SQL Server Reporting Services en mode natif et comment intégrer des rapports Power BI Server dans des sites SharePoint modernes ! Dans le chapitre suivant, nous apprendrons à créer des applications Web et des collections de sites.

CHAPITRE 13 Création d’applications Web et de collections de sites

Dans les chapitres précédents, nous avons appris à créer des applications de service afin d’activer des fonctionnalités supplémentaires pour nos utilisateurs. Dans ce chapitre, nous apprendrons comment créer des applications Web et des collections de sites nommées basées sur des chemins ainsi que des hôtes et comment personnaliser les mappages d’accès alternatif, créer des bases de données de contenu pour nos collections de sites et activer la création rapide de collections de sites.

Architecture Web SharePoint

Lorsque nous parlons de sites SharePoint, nous parlons généralement de trois niveaux différents : applications Web, collections de sites et sites Web. Les deux premiers sont en fait simplement des conteneurs ; étant donné qu’aucun contenu n’est stocké directement dans l’application Web et la collection de sites, tout le contenu est stocké dans le Web réel, qui peut être le site Web racine de votre collection de sites.

Les applications Web ne peuvent être créées que par des administrateurs SharePoint qui ont des privilèges d’administrateur de batterie ainsi que des autorisations d’administrateur local sur les serveurs SharePoint. La création d’une application Web créera un nouveau site dans IIS sur chaque serveur exécutant le service d’application Web Microsoft SharePoint Foundation, ainsi qu’une nouvelle base de données dans SQL. Bien que deux applications Web SharePoint puissent être hébergées dans le même pool d’applications IIS, elles ne peuvent pas avoir la même URL ou être hébergées dans la même base de données. Une application Web peut être associée à une ou plusieurs bases de données de contenu. Toutes les collections de sites créées dans cette application Web iront à l’une de ces bases de données de contenu. Chaque application Web doit avoir une collection de sites racine, qui est une collection de sites avec la même URL que l’application Web. Ce n’est pas créé automatiquement, mais c’est une exigence pour la prise en charge et la stabilité de votre système SharePoint. Une collection de sites peut être placée dans sa propre base de données de contenu et peut être déplacée entre des bases de données de contenu attachées dans la même application Web. Sous la collection de sites, nous trouvons des sites Web. Ces sites Web peuvent être à la racine de la collection de sites, ce qui signifie qu’ils ont la même URL que la collection de sites, ou ils peuvent être un sous-site du site Web racine. Ces sites Web ne peuvent pas être déplacés individuellement dans une autre base de données de contenu ; ils résident tous dans le même conteneur Site Collection. Dans la figure 13-1, vous pouvez voir en exemple l’architecture Web SharePoint.

Figure 13-1. Architecture Web SharePoint

Sites modernes et architecture plate

Si vous avez suivi les dernières nouvelles d’Office 365, vous devez déjà avoir une bonne base de connaissances sur les sites d’équipe SharePoint modernes et les sites de communication. Avec les sites SharePoint modernes, Microsoft recommande de ne rester qu’au niveau de la collection de sites et de ne créer aucun sous-site, car ils ne sont pas aussi flexibles que les collections de sites. Cependant, dans Office 365, le concept de site Hub nous permet de « lier » des collections de sites et de partager la même image de marque, la même sécurité et la même navigation dans plusieurs collections de sites. Malheureusement, le concept de site Hub n’est pas disponible dans SharePoint Server 2019, au moins au lancement, ce qui rend la conception de votre architecture d’information moderne plus difficile. La décision d’opter pour une architecture d’information standard ou plate dépendra en fin de compte des besoins de votre entreprise.

Non pas que nous en sachions un peu plus sur l’architecture derrière, commençons à créer des applications Web dans SharePoint 2019.

Applications Web

Les applications Web dans SharePoint 2019 peuvent être créées à partir de l’administration centrale de SharePoint ou par PowerShell. Avant de créer une application Web, vous devez connaître les exigences commerciales pour créer cette application Web et disposer de ces informations. Étant donné que les applications Web consomment des ressources importantes sur le serveur SharePoint, il est recommandé de limiter le nombre d’applications Web au minimum. Selon les limites et limites logicielles pour SharePoint Server 2019, une limite prise en charge de 20 applications Web par batterie SharePoint est prise en charge.

Vous aurez d’abord besoin des informations pour le site IIS présentées dans la figure 13-2.

Figure 13-2. Informations sur le site Web IIS lors de la création d’une nouvelle application Web

• URL de l’application Web

Ce sera l’en-tête de l’hôte de l’application Web, par exemple intranet.company.com. Ces informations doivent être extraites des exigences de l’entreprise et peuvent être modifiées ultérieurement si nécessaire.

• Port

Port sur lequel le site sera accessible. Port généralement 80 pour les sites HTTP et port 443 pour les sites utilisant HTTPS. Bien qu’il soit possible de choisir n’importe quel port, nous vous recommandons de conserver 80 ou 443 pour une expérience utilisateur améliorée, car les utilisateurs n’auront pas à spécifier le port lors de la saisie de l’URL lors de l’utilisation de ces deux. Vous pouvez avoir plusieurs applications Web en utilisant le même port.

Dans la partie suivante du processus de création d’application Web, vous devrez saisir les informations sur la sécurité et l’authentification de l’application Web, comme illustré à la figure 13-3.

Figure 13-3. Informations de configuration de sécurité lors de la création d’un nouveau site Web

Application

• Autoriser anonyme

Sélectionnez Oui si vous souhaitez que cette application Web serve un site public, où les utilisateurs n’auront pas à se connecter pour voir les informations.

• Utiliser Secure Sockets Layer (SSL)

Sélectionnez Oui si votre application Web utilisera HTTPS.

• Types d’authentification des revendications

Il s’agit de la méthode d’authentification que vos utilisateurs utiliseront pour s’authentifier auprès de SharePoint. Ces possibilités ont été expliquées au chapitre 4.

Remarque Nous vous recommandons d’utiliser ssl dans toutes les applications Web que vous créez pour augmenter la sécurité de votre déploiement de sharepoint. 

Dans la prochaine partie du processus de création d’une application Web, nous devons spécifier l’URL de la page de connexion ainsi que l’URL publique, comme illustré à la figure 13-4. L’URL de la page de connexion serait modifiée lors de la création d’une page de connexion personnalisée pour vos utilisateurs, par exemple un Extranet, et vous souhaitez qu’ils utilisent cette page personnalisée plutôt que la page de connexion SharePoint prête à l’emploi. L’URL publique sera automatiquement remplie à partir de l’en-tête d’hôte que vous avez spécifié précédemment, ainsi que de la case à cocher SSL.

Figure 13-4. Connexion URL de la page et URL publique

Nous devrons ensuite sélectionner si nous créons un nouveau pool d’applications Web pour cette application Web, ou si nous en utilisons un existant. Sauf si vous avez des exigences commerciales ou de sécurité spécifique pour créer un nouveau pool d’applications, nous vous suggérons d’utiliser le même que le reste de vos applications Web. Dans la figure 13-5, nous avons sélectionné le pool d’applications SharePoint existant, qui s’exécute sous le compte LAB \ S-Web.

Figure 13-5. Sélection du pool d’applications

L’étape suivante consiste à saisir les informations sur le serveur de base de données et le nom de la base de données, comme illustré à la figure 13-6. Le serveur de base de données sera automatiquement rempli avec votre serveur SQL principal à partir de la configuration de votre batterie de serveurs. Le serveur de basculement est uniquement requis lors de l’utilisation de la mise en miroir SQL et non lors de l’utilisation des groupes de disponibilité AlwaysOn ou du clustering SQL Server. Dans les groupes de disponibilité AlwaysOn et la mise en miroir, vous devez ajouter manuellement la base de données au réplica secondaire ou au groupe de disponibilité après sa création.

Figure 13-6. Informations de base de données pour l’application Web

La dernière étape pour créer l’application Web consiste à sélectionner les connexions d’application de service. C’est ce que les applications de service serviront à cette application Web. Par défaut, l’application Web sera connectée au groupe de proxy par défaut ; cependant, vous pouvez sélectionner personnaliser et sélectionner uniquement les applications de service que vous souhaitez pour cette application Web, comme illustré à la figure 13-7.

Figure 13-7. Connexions d’application de service

Après avoir cliqué sur OK, l’application Web sera créée.

Création d’une application Web avec PowerShell

Les applications Web peuvent également être créées à l’aide de PowerShell. Pour créer une application Web via PowerShell, nous devons utiliser l’applet de commande New-SPWebApplication à partir d’un environnement de gestion SharePoint élevé. Pour créer l’application Web intranet, nous devons d’abord créer un nouveau fournisseur d’authentification afin de créer une application Web de revendications.

$ap = New-SPAuthenticationProvider

Remarque Bien qu’il soit toujours possible de créer une application Web en mode d’authentification classique dans sharepoint 2019, ce mode est obsolète et n’est pas recommandé. 

Nous devons ensuite créer l’application Web et lui donner le nom, l’hôte, l’URL, le port, le pool d’applications et le nom de la base de données, comme nous l’avons fait dans l’interface utilisateur. Nous spécifions également le fournisseur $ ap que nous avons créé juste avant et utilisons le commutateur SecureSocketsLayer pour spécifier qu’il s’exécutera sur SSL.

New-SPWebApplication -Name “Cobalt Atom Intranet” -HostHeader “intranet. cobaltatom.com” -URL “https://intranet.cobaltatom.com” -Port 443

-ApplicationPool “SharePoint” -AuthenticationProvider $ap -DatabaseName

“WSS_Content_Intranet” -SecureSocketsLayer

Puisque nous avons créé une application Web qui utilise SSL, nous devons aller sur IIS et sélectionner le certificat pour cette application Web. Si ce certificat n’est pas encore importé dans IIS, vous devrez d’abord l’importer et ensuite depuis le site IIS, modifier les liaisons et sélectionner le certificat SSL dans la liste déroulante, comme illustré à la figure 13-8. Selon vos configurations, vous devrez peut-être cocher la case « Indication du nom du serveur requis ». L’indication du nom du serveur vous permet d’héberger des sites avec plusieurs certificats SSL, sur la même IP.

Figure 13-8. Modifier les liaisons dans IIS

Notez que cela doit être fait sur tous les serveurs exécutant le service d’application Web Foundation dans une configuration Minrole Farm, ce service s’exécute sur tous les rôles à l’exception de la recherche autonome. 

De plus, si vous ne l’avez pas déjà fait, assurez-vous d’ajouter cette nouvelle entrée au DNS de votre entreprise ainsi que de configurer votre équilibreur de charge si vous disposez de plusieurs frontaux Web. Une fois notre application Web créée, voyons comment ajouter d’autres URL à cette application Web.

Mappages d’accès alternatif

SharePoint comprend une fonctionnalité appelée Mappages d’accès alternatif qui vous permet de créer plusieurs URL pour la même application Web. Une alternative aux mappages d’accès alternatif serait les collections de sites nommés par l’hôte, que nous couvrirons plus loin dans ce chapitre. Les mappages d’accès alternatif sont couramment utilisés pour permettre aux utilisateurs du réseau interne de l’entreprise d’accéder à l’intranet en utilisant simplement https: // intranet, mais en forçant les utilisateurs qui accèdent à partir d’Internet à utiliser le nom de domaine complet, qui est https://intranet.cobaltatom.com. Du point de vue de l’expérience utilisateur, il est préférable d’avoir la même URL à l’intérieur et à l’extérieur de l’organisation.

Pour créer un mappage d’accès alternatif à partir de l’administration centrale, accédez à la page Gestion des applications et choisissez « Configurer les mappages d’accès alternatif ». SharePoint vous montrera tous les mappages d’accès alternatif de toutes les applications Web, comme illustré à la figure 13-9. En utilisant le menu déroulant en haut à droite, vous pouvez sélectionner uniquement l’application Web que vous souhaitez afficher.

Figure 13-9. Mappages d’accès alternatif

Il existe deux types de mappages d’accès alternatif que nous pouvons ajouter dans SharePoint Server 2019 :

• URL interne

L’URL interne est simplement un alias pour le même site. Par exemple, vous pourriez m’appeler Vlad ou Vlad Catrinescu, et je répondrai aux deux noms, car je sais que vous me parlez. Cependant, c’est la même personne (Vlad Catrinescu) qui vous répondra. Lors de la création d’une URL SharePoint interne, les utilisateurs pourront accéder au site SharePoint en tapant cette URL dans le navigateur ; cependant, ils seront redirigés vers l’URL publique de l’application Web.

• URL publique

Une URL publique est une autre URL pour l’application Web. Par exemple, j’aurais une identité Vlad Catrinescu et un autre John Smith. Selon le nom que vous appelez, la même personne répondra toujours ; cependant, l’identité affichée, dans notre cas l’URL, sera celle que vous avez appelée. Chaque URL qu’un utilisateur voit dans son navigateur doit être enregistrée en tant qu’URL publique. Une alternative à la création d’URL publiques, qui nous permettra également de changer les modes d’authentification, est d’étendre l’application Web, que nous couvrirons un peu plus loin dans ce chapitre.

Pour créer une nouvelle URL publique ou modifier les URL existantes, utilisez le bouton « Modifier les URL publiques » en haut à droite. SharePoint propose cinq zones pour cinq URL différentes. Il n’y a aucune différence technique entre les zones Intranet, Internet, Personnalisé et Extranet. L’exception ici est la zone par défaut, qui est utilisée en interne par SharePoint. Un exemple est la recherche, où pour obtenir des résultats affichés avec l’URL correcte, vous devez absolument analyser l’URL publique par défaut de l’application Web. Dans la figure 13-10 , nous avons ajouté une deuxième URL publique https://publishing.cobaltatom.com dans la zone intranet.

Figure 13-10. Nouvelle URL publique

Cela peut également être effectué par PowerShell à l’aide de l’applet de commande New-SPAlternateURL PowerShell à partir d’un environnement de gestion SharePoint élevé. Pour créer une nouvelle URL publique comme nous l’avons fait dans le précédent, nous exécuterions l’applet de commande suivante :

New-SPAlternateURL -Url https://publishing.cobaltatom.com -Zone “Intranet”

-WebApplication https://intranet.cobaltatom.com

Pour créer une URL interne qui redirigerait https: // intranet vers https: // intranet.cobaltatom.com , nous utiliserions toujours la cmdlet New-SPAlternateURL, mais ajouter le commutateur -Internal.

New-SPAlternateURL -Url https://intranet -Zone “Default” -WebApplication https://intranet.cobaltatom.com -Internal

Le résultat illustré à la figure 13-11 sera que cette application Web SharePoint sera accessible par ces trois URL.

Figure 13-11. Mappages d’accès alternatif

Les mappages d’accès alternatif s’appliquent uniquement à SharePoint et les modifications que vous apportez ici n’apportent pas automatiquement des modifications à l’application Web dans IIS. De plus, les nouveaux noms d’hôtes doivent également être ajoutés dans DNS. La figure 13-12 explique mieux où votre nouvelle URL doit être résolue, avant qu’un utilisateur puisse accéder à votre site SharePoint.

1. Lorsque vous demandez une URL, cette URL doit d’abord être résolue dans le système de noms de domaine (DNS). Le DNS indiquera au navigateur à quelle adresse IP ou quel serveur il doit aller. Selon votre topologie, il sera soit directement à un serveur SharePoint, soit à un équilibreur de charge qui transmettra ensuite la demande à l’un de vos serveurs Web.

2. IIS reçoit la demande et recherche une liaison qui correspond. C’est pourquoi il est important de toujours s’assurer de mettre à jour vos URL non seulement dans SharePoint mais aussi dans IIS.

3. Une fois qu’IIS fait correspondre la demande à l’un des sites, la demande est envoyée à SharePoint, qui la compare à l’une des applications Web et renvoie le site SharePoint à l’utilisateur.

Figure 13-12. Résolution du site SharePoint

Il est important de se rappeler que chaque fois que vous ajoutez ou modifiez une URL dans SharePoint, la modification doit être effectuée aux trois endroits : DNS, IIS et SharePoint. Au lieu d’ajouter plusieurs mappages d’accès alternatif, la meilleure pratique serait d’étendre l’application Web.

Extension d’une application Web

Dans la section précédente, nous avons vu comment ajouter une nouvelle URL publique à notre application Web afin de permettre aux utilisateurs d’y accéder sous un autre nom. Une autre manière d’obtenir le même résultat et d’offrir plus d’options consiste à étendre l’application Web. Lorsque vous étendez une application Web, non seulement vous disposez d’une nouvelle URL pour accéder à cette application Web, mais le processus crée également un site IIS différent et vous permet de définir une méthode d’authentification différente.

Prenons, par exemple, une application Web utilisée pour un extranet qui accède à l’utilisateur interne avec http://extranet et utilise l’authentification NTLM. Puisque nous ne voulons pas que les utilisateurs externes aient un compte AD, nous devons activer l’authentification basée sur le formulaire. En étendant l’application Web à https://extranet.cobaltatom.com, nous pouvons obtenir la nouvelle URL, ainsi qu’activer une autre forme d’authentification, dans notre cas, l’authentification par formulaire.

Pour étendre une application Web à partir de l’administration centrale, dans la page Applications Web, sélectionnez l’application Web que vous souhaitez étendre et cliquez sur Étendre, comme illustré à la figure 13-13.

Figure 13-13. Étendre l’application Web

L’écran Étendre illustré à la figure 13-14 est très similaire à la nouvelle application Web.

Nous devons d’abord saisir l’en-tête Port et hôte du nouveau site Web IIS.

Figure 13-14. Étendre l’application Web à un autre site Web IIS

Nous devons ensuite spécifier la configuration de sécurité ainsi que les types d’authentification des revendications que nous voulons utiliser. Dans la figure 13-15, nous avons choisi d’utiliser SSL et de permettre aux utilisateurs de se connecter à l’application Web avec NTLM et FBA.

Figure 13-15. Étendre la configuration de la sécurité des applications Web

Un nouveau site sera créé dans IIS avec la liaison extranet.cobaltatom.com déjà là ; cependant, nous devons définir le certificat manuellement et le saisir dans le DNS. Pour étendre une application Web via PowerShell, nous devons exécuter l’applet de commande New-SPWebApplicationExtension à partir d’un environnement de gestion SharePoint élevé. Pour étendre notre application Web intranet avec l’URL https://extranet.cobaltatom.com sur le port 443 et en utilisant SSL, nous exécuterions l’applet de commande suivante:

Get-SPWebApplication https://intranet.cobaltatom.com | New-

SPWebApplicationExtension -Name “Extranet” -URL “https://extranet. cobaltatom.com” -SecureSocketsLayer -Zone “Extranet” -HostHeader

“extranet.cobaltatom.com” -Port 443

Politique d’utilisation des applications Web

SharePoint nous permet d’accorder certaines autorisations aux utilisateurs, directement au niveau de l’application Web. Ceci est très utile pour les administrateurs SharePoint qui ont besoin d’accéder à toutes les collections de sites dans une application Web, mais ne veulent pas s’ajouter manuellement. Ces autorisations n’apparaissent pas dans la section « Vérifier les autorisations » de chaque collection de sites et s’appliquent avant l’application de toute autorisation de collection de sites. SharePoint utilise également des stratégies d’application Web pour accorder certaines autorisations de compte à l’application Web.

Par exemple, le compte Search Crawl dispose d’autorisations de lecture complète sur toutes les applications Web de la batterie de serveurs qu’il doit analyser. Il existe quatre autorisations disponibles au niveau de l’application Web :

1. Contrôle total

Contrôle total de toutes les collections de sites dans l’application Web.

2. Lecture complète

Peut lire tout le contenu de l’Application Web, mais pas modifier ou ajouter du contenu, sauf si des droits lui sont directement accordés sur le Site.

3. Refuser l’écriture

Cette stratégie ne permettra pas à l’utilisateur ou au groupe de modifier ou d’ajouter du contenu dans l’application Web, même s’il dispose de droits directement sur un site SharePoint.

4. Tout refuser

Cette stratégie n’autorise pas l’utilisateur ou le groupe à accéder à un site de l’application Web, même s’il dispose de droits directement sur un site SharePoint dans cette application Web.

Vous pouvez également créer des stratégies personnalisées dans la stratégie d’autorisation d’application Web ; cependant, il est recommandé de n’utiliser que les valeurs par défaut si possible.

Pour ajouter des utilisateurs à la stratégie d’application Web, dans la page Application Web de l’Administration centrale, sélectionnez l’application Web à laquelle vous souhaitez appliquer la stratégie, puis sélectionnez Stratégie utilisateur dans le ruban. Une fenêtre similaire à la figure 13-16 s’ouvre, affichant toutes les politiques actuelles de l’application Web.

Figure 13-16. Politique d’application Web

Comme indiqué au chapitre 6, l’ajout ou la suppression d’utilisateurs des stratégies d’application Web obligera le moteur de recherche à analyser tout le contenu de l’application Web lors de l’analyse suivante, afin de recalculer l’élément Liste de contrôle d’accès.

Pour ajouter un utilisateur à la stratégie d’application Web, cliquez sur Ajouter des utilisateurs en haut à gauche de la fenêtre et si l’application Web possède plusieurs zones, sélectionnez la zone à laquelle vous souhaitez appliquer cette stratégie. Dans la fenêtre suivante illustrée à la figure 13-17, saisissez les utilisateurs ou les groupes que vous souhaitez ajouter à la stratégie d’application Web, ainsi que les autorisations que vous souhaitez leur accorder. La case à cocher « Le compte fonctionne en tant que système » n’est recommandée que pour les comptes de service, car leurs actions seront marquées comme « Système » dans les journaux, et non comme nom d’utilisateur réel.

Figure 13-17. Nouvelle politique d’application Web

Cliquez sur Terminer pour ajouter la stratégie. Pour ajouter la même stratégie via PowerShell, nous devons exécuter les applets de commande suivantes à partir d’un environnement de gestion SharePoint élevé :

$w = Get-SPWebApplication https://intranet.cobaltatom.com/

$policy = $w.Policies.Add(“i:0#.w|LAB\vlad.catrinescu”, “SharePoint Admin”) $policyRole = $w.PolicyRoles.GetSpecialRole([Microsoft.SharePoint.

Administration.SPPolicyRoleType]::FullControl)

$policy.PolicyRoleBindings.Add($policyRole)

$w.Update()

Où LAB \ vlad.catrinescu est le compte que nous voulons ajouter et SharePoint Admin est le nom d’affichage qui apparaîtra dans la stratégie d’application Web. Le résultat de cette applet de commande peut être vu sur la figure 13-18.

Figure 13-18. Ajouter une stratégie d’application Web via PowerShell

Comptes de cache d’objets

Les sites de publication SharePoint utilisent deux comptes de cache d’objets pour améliorer les vitesses de rendu des pages sur les pages de publication et réduire la charge sur SQL Server. Ces comptes sont souvent référés aux comptes Portal Super User et Portal Super Reader. Le compte Portal Super User aura le contrôle total sur l’application Web, tandis que le compte Portal Super Reader n’aura que la lecture complète sur l’application Web. SharePoint utilisera ces comptes de cache pour créer deux versions du cache d’objets, une avec le portail

Compte Super Reader, qui ne verra que les articles publiés, et un avec le compte Portal Super User, qui verra à la fois les articles publiés et les brouillons. Lorsqu’un utilisateur interroge une page de publication, le cache d’objets vérifie les autorisations de cet utilisateur et retourne l’objet mis en cache approprié selon qu’il peut voir les brouillons ou non. Les comptes de cache d’objets ne sont nécessaires que pour les applications Web qui exécuteront des sites de publication, mais il n’y a aucun mal à les définir sur toutes vos applications Web.

Les comptes Portal Super User et Portal Super Reader doivent être deux comptes de service distincts et ne doivent pas être utilisés pour se connecter sur le site. Nous devons d’abord les ajouter au sac de propriétés de l’application Web à l’aide des applets de commande suivantes :

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

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

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

$wa.Update()

Ensuite, nous devons leur donner les autorisations requises. Le compte Super User doit avoir un contrôle total au niveau de l’application Web, tandis que le Super Reader doit avoir une lecture complète.

$w = Get-SPWebApplication https://intranet.cobaltatom.com/

$policy = $w.Policies.Add(“i:0#.w|LAB\s-su”, “Portal Super User”) $policyRole = $w.PolicyRoles.GetSpecialRole([Microsoft.SharePoint.

Administration.SPPolicyRoleType]::FullControl)

$policy.PolicyRoleBindings.Add($policyRole)

$policy = $w.Policies.Add(“i:0#.w|LAB\s-sr”, “Portal Super Reader”) $policyRole = $w.PolicyRoles.GetSpecialRole([Microsoft.SharePoint.

Administration.SPPolicyRoleType]::FullRead)

$policy.PolicyRoleBindings.Add($policyRole)

$w.Update()

Après avoir exécuté ces scripts, les comptes seront visibles dans les propriétés de l’application Web, comme illustré à la figure 13-19.

Figure 13-19. Propriétés d’application Web

Les deux comptes de cache d’objets seront également visibles dans la stratégie d’application Web avec les autorisations requises.

Remarque : pour que les modifications des comptes de cache d’objet prennent effet, vous devrez effectuer un iisreset. 

Bases de données de contenu

Une application Web peut être associée à une ou plusieurs bases de données de contenu. En créant plusieurs bases de données de contenu, vous pouvez isoler les collections de sites les unes des autres, ce qui facilite la gestion de la base de données. Pour afficher ou créer des bases de données à partir de l’administration centrale, accédez à la page de gestion des applications, puis cliquez sur Gérer les bases de données de contenu. La page de la figure 13-20 montrera toutes les bases de données attachées à cette application Web, ainsi que le nombre de collections de sites qu’elles contiennent.

Figure 13-20. Bases de données de contenu

Pour créer une nouvelle base de données de contenu, cliquez sur le bouton « Ajouter une base de données de contenu » en haut à gauche. Vous devrez d’abord entrer le serveur de base de données où ajouter la base de données ainsi que son nom. Dans la figure 13-21, nous avons conservé notre serveur de base de données par défaut et nommé la base de données WSS_Content_Intranet_2.

Figure 13-21. Nouveau serveur et nom de base de données de contenu

Nous devons ensuite entrer dans le serveur de base de données de basculement si nous exécutons la mise en miroir SQL.

Cela n’est pas requis si vous exécutez des groupes de disponibilité AlwaysOn SQL Server ou le clustering SQL Server. Enfin, vous devrez entrer le nombre maximal de collections de sites pouvant être créées dans cette base de données, ainsi qu’un nombre où un événement d’avertissement sera généré dans le journal des événements. Si vous définissez ce maximum au nombre actuel de collections de sites dans la base de données de contenu, SharePoint ne créera tout simplement plus de collections de sites dans cette base de données de contenu. Dans la figure 13-22, nous avons défini l’avertissement à 10 et le nombre maximal à 15.

Figure 13-22. Paramètres de capacité de la base de données

Appuyez simplement sur OK pour créer la base de données de contenu. Assurez-vous d’ajouter la base de données à votre groupe de disponibilité ou au réplica secondaire si vous disposez de la haute disponibilité au niveau SQL. La base de données de contenu peut également être créée via PowerShell à l’aide de la cmdlet New-SPContentDatabase à partir d’un environnement de gestion SharePoint élevé. Pour créer une base de données avec les mêmes paramètres que le précédent, nous exécuterions l’applet de commande PowerShell suivante :

New-SPContentDatabase “WSS_Content_Intranet_3” -WebApplication https:// intranet.cobaltatom.com/ -WarningSiteCount 10 -MaxSiteCount 15

Pour modifier une base de données de contenu, à partir de la page Gestion de la base de données, cliquez simplement sur le nom et vous accédez aux paramètres de gestion de la base de données de contenu. Le nom et le serveur de la base de données ne peuvent pas être modifiés ; cependant, vous pouvez faire passer l’état de la base de données de Prêt à Hors ligne comme illustré à la figure 13-23. La modification du statut de la base de données sur Hors ligne ne mettra pas réellement la base de données hors ligne, elle indiquera uniquement à SharePoint de ne mettre aucune nouvelle collection de sites dans cette base de données. De plus, les bases de données en mode hors ligne ne peuvent pas être récupérées via la cmdlet Get-SPContentDatabase PowerShell, vous devez utiliser la cmdlet Get-SPDatabase pour les récupérer. Toutes les collections de sites existantes dans ces bases de données fonctionneront comme auparavant.

Figure 13-23. État de la base de données

Vous pouvez également modifier le nombre maximal de collections de sites dans la base de données à partir de cette page. Pour supprimer une base de données de contenu, cochez la case « Supprimer la base de données de contenu » illustrée à la figure 13-24. Cela ne supprimera pas la base de données, mais il la détachera simplement de la batterie de serveurs, et toutes les collections de sites de cette base de données ne seront plus disponibles dans la batterie de serveurs SharePoint. Les données seront toujours conservées dans la base de données jusqu’à ce que vous les supprimiez de SQL Server.

Figure 13-24. Supprimer la base de données de contenu

Vous pouvez également détacher une base de données de contenu de SharePoint à l’aide de la cmdlet PowerShell Dismount-SPContentDatabase. Pour supprimer une base de données de contenu de SharePoint et la supprimer de SQL Server, vous pouvez utiliser l’applet de commande Remove-SPContentDatabase PowerShell.

Lorsque les collections de sites sont créées sans spécifier de base de données de contenu, SharePoint crée la collection de sites dans la base de données de contenu qui est disponible et qui contient le plus petit nombre de collections de sites. Avec cet algorithme, les bases de données de contenu se développeront uniformément. Vous pouvez également implémenter un fournisseur de création de site personnalisé en utilisant du code personnalisé pour analyser le type de collection de sites en cours de création et l’acheminer vers une certaine base de données.

Collections de sites

Avec notre application Web créée et prête, nous devons maintenant créer des collections de sites.

Il existe deux stratégies pour créer des collections de sites. La première est appelée Collection de sites basée sur le chemin d’accès et est l’approche traditionnelle que nous utilisons depuis SharePoint 2010. Une collection de sites basée sur le chemin d’accès a toujours la même URL que l’application Web sous laquelle elle se trouve. Par exemple, si mon URL d’application Web est https://intranet.cobaltatom.com , toutes mes collections de sites dans cette application Web commenceront par https://intranet.cobaltatom.com . Par conséquent, si une équipe vous demande de créer une collection de sites qui se trouve sur https://communications.cobaltatom.com , vous devez créer une nouvelle application Web. N’oubliez pas que pour des raisons de performances, nous devrions avoir un maximum de 20 applications Web, de sorte que cette approche peut être très limitée en termes d’évolutivité.

Depuis SharePoint 2013, Microsoft a encouragé l’utilisation des collections de sites nommés par l’hôte. Les collections de sites nommées par l’hôte ne partagent pas nécessairement la même URL que l’application Web dans laquelle elles se trouvent ; par conséquent, je pourrais avoir ma collection de sites avec l’URL https://communications.cobaltatom.com dans mon https://intranet.cobaltatom.com application Web.

Mais quel est le problème avec les applications Web ? Les applications Web consomment beaucoup plus de ressources sur votre serveur Web frontal qu’une collection de sites. Dans les limites et limites logicielles de SharePoint 2019, Microsoft répertorie 20 comme nombre maximal pris en charge d’applications Web par batterie SharePoint. Bien que le fait d’avoir moins d’applications Web et d’utiliser les collections de sites nommés par l’hôte soit nettement meilleur pour les performances de votre serveur, la création et la gestion de la collection de sites nommés par l’hôte sont plus difficiles et beaucoup moins conviviales. Nous entrerons plus dans les détails dans la section couvrant les collections de sites nommés par l’hôte.

Collections de sites basées sur le chemin

Les collections de sites basées sur le chemin d’accès sont toujours les collections de sites les plus courantes dans les déploiements SharePoint sur site car elles sont plus faciles à créer et à gérer.

Pour créer une collection de sites à partir de l’administration centrale, accédez à la page Gestion des applications et sous Collections de sites, cliquez sur Créer des collections de sites. En haut de l’écran, vous devez sélectionner dans quelle application Web vous souhaitez créer cette collection de sites. Vous devrez d’abord saisir le titre de la collection de sites et éventuellement la description également. Vous devez ensuite choisir l’URL de votre collection de sites. Étant donné que notre application Web n’a pas de collections de sites à la racine, c’est-à-dire avec la même URL que l’application Web, nous pouvons créer une collection de sites racine ou une collection de sites qui se trouve sous / sites / url. La partie Sites de l’URL est ce que nous appelons un chemin géré, et nous pouvons personnaliser ceux-ci pour inclure des sites après / équipes / par exemple, ou même créer une collection de sites qui est (URL d’application Web) / HR, par exemple https://intranet/RH. Nous examinerons les chemins gérés plus loin dans ce chapitre. Dans notre exemple illustré à la figure 13-25, nous allons créer une collection de sites racine avec le titre Intranet Home.

Figure 13-25. Nouvelle collection de sites

Dans la deuxième partie du formulaire, vous devez sélectionner le modèle, ainsi que les administrateurs de collection de sites principal et secondaire, comme illustré à la figure 13-26. Si plusieurs modules linguistiques sont installés, vous disposerez également d’un champ déroulant dans lequel vous pourrez sélectionner la langue de la collection de sites. Enfin, la figure 13-26 ne présente pas la sélection du modèle de quota. Nous parlerons des modèles de quota un peu plus loin dans le chapitre. Pour créer des sites modernes, vous pouvez choisir le modèle de site d’équipe sous collaboration, comme illustré à la figure 13-26 , ou le site de communication sous l’onglet de publication.

Figure 13-26. Nouveau modèle de collection de sites et administrateurs de collection de sites

Pour créer la collection de sites, appuyez simplement sur OK en bas de l’écran. Pour créer une collection de sites par PowerShell, nous devons utiliser l’applet de commande New-SPSite à partir d’un environnement de gestion SharePoint élevé. En utilisant SharePoint Management Shell, nous avons également la possibilité de sélectionner dans quelle base de données de contenu nous voulons placer cette collection de sites. Dans l’applet de commande suivante, nous spécifions l’URL, le nom et la description de la collection de sites. Nous transmettons également les noms d’utilisateur des premiers propriétaires et des propriétaires secondaires. Enfin, nous spécifions l’ID du modèle de site d’équipe moderne (STS # 3) et la base de données de contenu dans laquelle nous voulons créer la collection de sites.

New-SPSite -url “https://intranet.cobaltatom.com/sites/team1” -Name “Team 1 Home” -Description “Team 1 SharePoint Site” -OwnerAlias “LAB\vlad.

catrinescu “-SecondaryOwnerAlias” LAB \ trevor.seward “-Template” STS # 3 “-ContentDatabase WSS_Content_Intranet_2

Remarque Lors de la création d’une collection de sites via PowerShell, les groupes de points de partage par défaut ne seront pas créés. 

Si vous ne spécifiez pas de modèle, la collection de sites sera créée sans site Web racine et SharePoint vous demandera de sélectionner un modèle la première fois que vous accédez au site, comme illustré à la figure 13-27.

Figure 13-27. Sélection du modèle de collection de sites

Quotas de site

SharePoint permet aux administrateurs de spécifier un quota pour chaque collection de sites. Les quotas ne permettront pas aux utilisateurs d’utiliser plus d’une certaine quantité de stockage et limiteront le nombre de ressources pouvant être consommées par Sandboxed Solutions. Les solutions Sandbox avec des limites de code sont toujours présentes dans l’interface utilisateur mais ne sont pas pertinentes car les solutions Sandbox avec du code sont supprimées de SharePoint 2019. Une fois le quota atteint, un message « Pas d’espace libre » apparaît aux utilisateurs lorsqu’ils essaient de créer de nouveaux éléments dans SharePoint, et une barre rouge s’affiche en haut du site. Pour créer un nouveau quota de site par l’administration centrale, accédez à la page Gestion des applications, puis spécifiez les modèles de quota. Vous allez voir une page similaire à la figure 13-28.

Figure 13-28. Nouveau modèle de quota

Le modèle de quota peut également être créé via PowerShell. Dans le prochain script, nous allons créer un quota nommé «Silver Team Site» avec une limite de stockage maximale de 1024 Mo et un avertissement envoyé à 750 Mo. Notez que les variables StorageMaximumLevel et StorageWarningLevel doivent être en octets.

$Template = New-Object Microsoft.SharePoint.Administration.SPQuotaTemplate

$Template.Name = “Silver Team Site”

$Template.StorageMaximumLevel = 1073741824

$Template.StorageWarningLevel = 786432000

$ContentService = [Microsoft.SharePoint.Administration.

SPWebService]::ContentService

$ContentService.QuotaTemplates.Add($Template)

$ContentService.Update()

L’affectation d’un modèle de quota à une collection de sites peut être effectuée à l’aide de l’applet de commande Set-SPSite et en spécifiant l’URL et le nom du modèle de quota, comme illustré dans l’exemple suivant :

Set-SPSite -Identity https://intranet.cobaltatom.com/sites/team1

-QuotaTemplate “Silver Team Site”

Vous pouvez également utiliser l’applet de commande Set-SPSite pour modifier le quota vers un autre modèle ultérieurement.

Chemins d’accès gérés

Les chemins d’accès gérés vous permettent de personnaliser l’URL de vos sites afin de les rendre plus conviviaux et de s’aligner sur les besoins de votre entreprise et nous permettent d’héberger plusieurs collections de sites dans la même application Web. Les chemins d’accès gérés sont ce qui se trouve entre l’URL de l’application Web et la partie de votre URL que vous souhaitez donner à votre collection de sites. Par défaut, chaque application Web SharePoint contient le / sites / chemin géré ainsi que le chemin géré (racine), vous permettant de créer la collection de sites racine. Il existe deux types de chemins d’accès gérés que vous pouvez créer dans SharePoint :

• Inclusion de caractères génériques

Une inclusion générique est un chemin d’accès géré qui vous permet de créer plusieurs collections de sites à l’aide du chemin que vous spécifiez. Par exemple, si vous créez un chemin d’accès / équipes / géré, vous pouvez créer des URL comme https://intranet.cobaltatom.com/teams/ engineering , https://intranet.cobaltatom.com/teams/HR , https: // intranet.cobaltatom.com/teams/Marketing et ainsi de suite. Cependant, vous ne pouvez pas créer un site avec l’URL https://intranet.cobaltatom.com/teams.

Le chemin par défaut / sites / Managed est de type Wildcard Inclusion.

• Inclusion explicite

Une inclusion explicite vous permet uniquement de créer une collection de sites avec l’adresse spécifiée. Par exemple, nous pourrions créer un chemin géré / HR dans l’inclusion explicite, vous ne pouvez créer qu’une collection de sites sur https: // intranet.cobaltatom.com/HR . Vous n’aurez pas besoin d’ajouter quoi que ce soit après le HR comme vous le feriez avec une inclusion générique.

Remarque Pour des raisons de performances, Microsoft recommande un maximum de 20 chemins d’accès gérés par application Web. 

Pour créer un chemin géré via l’administration centrale, accédez à la page de gestion des applications Web et, à partir du ruban, cliquez sur Chemins gérés, comme illustré à la figure 13-29.

Figure 13-29. Chemins d’accès gérés

Entrez simplement le chemin que vous souhaitez créer, ainsi que le type dans le menu déroulant, puis cliquez sur le bouton “Ajouter un chemin”. Une fois le chemin ajouté aux chemins inclus, vous pouvez cliquer sur OK pour fermer la fenêtre contextuelle. Dans la figure 13-30, nous avons créé un chemin géré appelé « Teams » de type Wildcard.

Figure 13-30. Chemin géré par les équipes

Pour créer un chemin géré avec PowerShell, nous devons exécuter l’applet de commande New-SPManagedPath PowerShell à partir d’un environnement de gestion SharePoint élevé. Par exemple, pour créer un nouveau chemin géré d’inclusion de caractères génériques avec le chemin d’accès “département”, nous exécuterions l’applet de commande PowerShell suivante :

New-SPManagedPath “department” -WebApplication https://intranet.cobaltatom.com

Si nous voulons créer un chemin géré explicite, nous devons ajouter le commutateur –Explicit, comme dans l’exemple suivant :

New-SPManagedPath “communications” -WebApplication “https://intranet.

cobaltatom.com” –Explicit

Si nous revenons pour créer une nouvelle collection de sites via l’administration centrale, nous verrons à la fois le chemin géré / teams comme illustré à la figure 13-31 et le chemin géré explicite / communications illustré à la figure 13-32 .

Figure 13-31. Chemin géré de l’inclusion des caractères génériques pour les équipes

Figure 13-32. Chemin géré explicite des communications

Maintenant que nous savons comment créer des collections de sites basées sur le chemin, jetons un coup d’œil aux collections de sites nommées par l’hôte.

Héberger des collections de sites nommées

Comme indiqué précédemment, les collections de sites nommés par l’hôte vous permettent d’héberger plusieurs noms d’hôte dans la même application Web. Bien que cette approche soit l’approche des meilleures pratiques selon Microsoft, ne vous lancez pas dans un parcours de collections de sites nommés par l’hôte sans une planification appropriée. L’application Web dans laquelle vous allez créer des collections de sites nommées par l’hôte devra avoir une liaison IIS qui répond à tout le trafic sur un port spécifique. Par exemple, si nous voulons créer des collections de sites nommés par l’hôte dans l’application Web https://sp.cobaltatom.com, vous devez ajouter une liaison qui écoute *: 443, qui a un certificat qui lui est attribué soit caractère générique ou possède toutes les URL de la collection de sites nommés par l’hôte dans le SAN.

Étant donné que dans le chapitre 5, nous avons configuré les compléments pour écouter sur *: 443, nous ne pouvons pas demander à un autre site d’écouter exactement la même liaison, nous avons donc configuré une autre adresse IP pour notre serveur. Si vous exécutez plusieurs serveurs Web frontaux, vous devrez configurer une adresse IP supplémentaire pour chaque serveur Web frontal de votre batterie de serveurs. Il est recommandé d’avoir une adresse IP supplémentaire et de configurer correctement chaque serveur exécutant le service d’application Web Microsoft SharePoint Foundation dans la batterie de serveurs. Pour chaque application Web que vous souhaitez utiliser pour les collections de sites nommés par l’hôte, vous devrez ajouter une autre adresse IP, car celle-ci devra également écouter sur *: 443 ou *: 80 si vous n’utilisez pas SSL.

Pour préparer notre https://sp.cobaltatom.com, nous avons ajouté la liaison dans IIS qui écoute toutes les demandes sur l’adresse IP 172.16.5.207 et le port 443 sur notre premier frontal. Nous avons également utilisé le certificat générique * .cobaltatom.com, ce qui signifie que toutes les collections de sites nommés par l’hôte que nous allons créer devront se trouver dans le domaine cobaltatom.com. IIS La liaison peut être vu dans la figure 13-33.

Figure 13-33. Liaison de la collection de sites nommés par l’hôte

Avec IIS configuré, nous pouvons maintenant créer notre collection de sites nommés par l’hôte. Contrairement aux collections de sites basées sur le chemin, nous ne pouvons pas utiliser l’Administration centrale pour les créer, PowerShell est donc obligatoire. Nous utilisons toujours l’applet de commande New-SPSite et la plupart des paramètres sont les mêmes ; cependant, lors de la création de collections de sites nommés par l’hôte, nous devons spécifier le paramètre –HostHeaderWebApplication, afin d’indiquer à SharePoint dans quelle application Web le placer.

New-SPSite https://Team1.cobaltatom.com –OwnerAlias “LAB\vlad.catrinescu” –HostHeaderWebApplication https://sp.cobaltatom.com –Name “Team Site 1”

-Template “STS#3”

L’autre différence avec les collections de sites nommés par l’hôte est les chemins d’accès gérés. Les chemins d’accès gérés pour les collections de sites nommées par l’hôte ne peuvent pas être créés par l’administration centrale et ne peuvent être créés qu’avec PowerShell. Nous devons utiliser la même applet de commande, qui est New-SPManagedPath, et nous devons ajouter le commutateur –HostHeader pour le rendre disponible pour les collections de sites nommées par l’hôte. Pour créer un chemin géré d’inclusion générique « Projets », nous devons utiliser l’applet de commande PowerShell suivante :

New-SPManagedPath “projects” -HostHeader

Remarque Les chemins d’accès gérés créés à l’aide du commutateur –hostheader sont valides pour toutes les applications Web de la batterie de serveurs. 

Nous pourrions ensuite créer une collection de sites avec l’URL https: // Team1. cobaltatom.com/Projects/Project1 à l’aide de l’applet de commande PowerShell suivante :

New-SPSite https://Team1.cobaltatom.com/Projects/Project1 –OwnerAlias “LAB\ vlad.catrinescu” –HostHeaderWebApplication https://sp.cobaltatom.com –Name “Project Site 1” -Template “STS#3”

Les mappages d’accès alternatif ne s’appliquent pas non plus aux collections de sites nommés par l’hôte.

Les URL alternatives peuvent être définies individuellement pour chaque collection de sites nommés par l’hôte à l’aide de l’applet de commande Set-SPSiteUrl PowerShell. Pour rendre notre https://Team1.cobaltatom.com Site Collection également accessible avec l’URL https://ProjectCenter.cobaltatom.com, nous devons exécuter les applets de commande PowerShell suivantes :

$site = Get-SPSite https://Team1.cobaltatom.com

Set-SPSiteUrl $site -Url ‘https://ProjectCenter.cobaltatom.com’ -Zone Intranet

Comme pour le fonctionnement des mappages d’accès alternatif, vous devrez attribuer l’URL à l’une des cinq zones. Pour afficher toutes les URL actuelles d’une collection de sites nommés par l’hôte, vous devez utiliser l’applet de commande Get-SPSiteURL et donner la variable $ site que nous avons enregistrée précédemment. Dans la figure 13-34, nous pouvons voir les URL que nous avons définies pour la collection de sites Team1.

Figure 13-34. Get-SPSiteURL

Bien que les collections de sites nommés par l’hôte soient recommandées par Microsoft et présentent des avantages en termes de performances par rapport à l’utilisation de plusieurs applications Web, il existe certains inconvénients qui empêchent les entreprises de les utiliser. Tout d’abord, il n’y a pas d’outils de gestion pour les collections de sites nommés par l’hôte dans l’administration centrale. En outre, le mélange de MySites et de collections de sites de contenu dans la même application Web peut entraîner une désorganisation dans la base de données de contenu, car vous aurez à la fois des collections de sites MySites et des collections de sites de contenu dans des bases de données mixtes, et ils pourraient ne pas tous avoir la même exigence pour les sauvegardes et le management. Enfin, vous ne pouvez pas créer de collections de sites nommées par l’hôte à l’aide de la fonction intégrée de création de sites en libre-service. Les utilisateurs pourront toujours utiliser la fonctionnalité et créer des collections de sites basées sur un chemin sous un chemin géré existant.

En fin de compte, la décision entre les collections de sites nommées par l’hôte et les collections de sites basées sur le chemin dépendra des besoins de votre entreprise.

Création rapide d’une collection de sites

La création rapide de collections de sites est une nouvelle fonctionnalité de SharePoint Server 2019 qui permet aux administrateurs de créer des collections de sites plus rapidement que la méthode traditionnelle. Lors de la création d’une collection de sites, SharePoint crée un site vierge et active toutes les fonctionnalités nécessaires pour accéder au modèle souhaité. Avec la création de collection de sites rapide, une copie d’un modèle serait enregistrée dans la base de données et chaque fois que vous créez une collection de sites avec ce modèle à l’aide de la création de collection de sites rapide, SharePoint copiera le site directement dans la base de données de contenu, ce qui rend le site création beaucoup plus rapide. SharePoint permet cela par défaut pour le modèle MySite, et toutes les collections de sites MySite que SharePoint crée automatiquement utilisent cette méthode.

Il est important de savoir que pour bénéficier de la création rapide de collections de sites, vous devez créer des sites via PowerShell car les collections de sites créées via l’administration centrale n’utiliseront pas ce nouveau moteur.

La première chose que nous devons faire est d’activer le modèle pour la création rapide de collections de sites à l’aide de l’applet de commande Enable-SPWebTemplateForSiteMaster PowerShell.

Dans les exemples, nous utiliserons CMSPUBLISHING # 0, qui est le modèle de site de publication. L’applet de commande que nous utiliserons est

Enable-SPWebTemplateForSiteMaster -Template CMSPUBLISHING#0

-CompatibilityLevel 15

Les modèles de notes pour les sites d’équipe modernes (sts # 3), les sites de communication modernes (# sitepagepUblishing # 0) sont activés par défaut. pour voir tous les modèles actuellement activés dans votre batterie de serveurs, exécutez l’applet de commande powershell get-spWebtemplatesenabledForsiteMaster. 

Alors que « 15 » est généralement associé à SharePoint 2013, SharePoint 2019 utilise le même niveau de compatibilité

Nous devons ensuite créer le Site Master dans la base de données de contenu à l’aide de l’applet de commande New-SPSiteMaster. Vous devrez le faire pour chaque base de données de contenu dans laquelle vous souhaitez créer ces types de collections de sites. Dans notre cas, le nom de la base de données de contenu est WSS_Content_Intranet_2 et nous avons exécuté l’applet de commande suivante :

New-SPSiteMaster -ContentDatabase WSS_Content_Intranet_2 -Template

SITEPAGEPUBLISHING#0

Avec tout prêt, nous pouvons maintenant créer notre site à l’aide de l’applet de commande New-SPSite PowerShell comme vu précédemment, mais nous devons ajouter le commutateur –CreateFromSiteMaster afin de dire à SharePoint d’utiliser la création de collection de sites rapide pour créer cette collection de sites. Un exemple d’applet de commande pour créer la collection de sites sera

New-SPSite -url “https://intranet.cobaltatom.com/sites/CommmSite”

-Name “Communication Site” -OwnerAlias “LAB\vlad.catrinescu” -Template

“SITEPAGEPUBLISHING#0” -ContentDatabase WSS_Content_Intranet_2

-CreateFromSiteMaster

Pour comparer côte à côte la vitesse du provisionnement de sites, nous avons créé deux collections de sites à l’aide du même modèle. Le premier a été créé sans le commutateur – CreateFromSiteMaster, tandis que le second a été créé avec le commutateur. Les résultats de la figure 13-35 montrent que la collection de sites provisionnée à l’aide de la méthode traditionnelle a pris 19,83 secondes pour créer, tandis que la collection de sites provisionnée avec la création de collection de sites rapide a pris 3,93 secondes.

Figure 13-35. Mesurer la création rapide d’une collection de sites

Selon le modèle de site que vous souhaitez activer pour Fast Site Collection, l’augmentation de la vitesse peut ne pas être perceptible. Par exemple, les sites Classic Team qui n’ont pas beaucoup de fonctionnalités à activer peuvent être créés plus lentement à l’aide de Fast Site Collection que le provisioning normal. N’oubliez pas également que Fast Site Collection ne peut être utilisé que par PowerShell ou par code, et toutes les collections de sites créées via l’Administration centrale utiliseront le moteur de provisioning standard.

Prochaines étapes

Dans ce chapitre, nous avons appris à créer des applications Web, ainsi que des collections de sites basées sur des chemins d’accès et des hôtes. Nous avons également appris comment activer la création rapide de collections de sites pour les modèles que nous utilisons le plus souvent. Dans le chapitre suivant, nous verrons comment implémenter une infrastructure SharePoint hybride entre SharePoint 2019 et Office 365.

CHAPITRE 14 Scénarios hybrides

Le déploiement d’une infrastructure SharePoint hybride peut offrir de grands avantages à votre entreprise et permettre à vos utilisateurs professionnels d’être plus productifs, tout en utilisant les technologies les plus récentes et les plus performantes de Microsoft.

Dans ce chapitre, nous verrons comment déployer une infrastructure SharePoint Server 2019 hybride à partir des exigences vers les sites hybrides, OneDrive Entreprise, la taxonomie hybride et l’application de service de recherche cloud.

Qu’est-ce qu’un déploiement hybride ?

Avant d’entrer dans les détails techniques, comprenons d’abord ce qu’est un déploiement hybride SharePoint. Un déploiement SharePoint hybride est un lien entre une batterie de serveurs SharePoint Server et Office 365. La batterie de serveurs SharePoint Server peut être hébergée dans notre propre centre de données, dans un cloud privé ou dans un cloud public tel qu’Azure ou AWS.

Il existe plusieurs raisons de déployer une infrastructure hybride SharePoint Server 2019.

Comme vous l’avez probablement déjà entendu d’innombrables fois, la vision de Microsoft est Cloud-First, Mobile-First, ce qui signifie que toutes les nouvelles fonctionnalités viennent en premier dans le cloud, puis font leur chemin dans la prochaine version sur site. De plus, certaines fonctionnalités telles que Delve, Groupes Office 365, Flow, PowerApps et Stream ne seront pas disponibles en tant que serveurs purement locaux.

Dans le même temps, il existe plusieurs raisons de continuer à utiliser SharePoint sur site. Les entreprises peuvent facilement personnaliser SharePoint 2019 pour répondre à leurs besoins commerciaux avec des solutions de batterie de serveurs et des tâches de minuteur, ainsi que garder le contrôle de tous les paramètres et configurations SharePoint. En outre, pour des raisons juridiques, de conformité ou de sécurité, certaines entreprises ne peuvent tout simplement pas stocker certaines de leurs données dans Office 365 car les données doivent être protégées de certaines manières.

C’est pourquoi un déploiement hybride est le meilleur des deux mondes. En utilisant le bon système pour le bon besoin commercial, vos utilisateurs professionnels pourront disposer des solutions SharePoint personnalisées et contrôler dont ils ont besoin sur site, ainsi que des dernières et meilleures fonctionnalités dans le cloud.

Authentification et autorisation

Une grande partie de la configuration d’un environnement Microsoft hybride consiste à configurer la synchronisation des utilisateurs entre Active Directory local et Azure Active Directory, qui est le répertoire utilisé par Office 365. Microsoft fournit DirSync, désormais obsolète, Azure AD Connect et un Agent de gestion Microsoft Identity Manager. Des tiers fournissent également des agents de synchronisation.

Le sujet suivant concerne la connexion unique (SSO). Une solution d’authentification unique garantit que vos utilisateurs ne se connectent qu’une seule fois sur Active Directory local et n’ont pas à ressaisir leurs informations d’identification lorsqu’ils essaient d’utiliser un service cloud. Microsoft propose les services de fédération Active Directory (ADFS) ainsi qu’Azure AD Connect SSO pour obtenir la fonctionnalité SSO, qui est la solution préférée. La fourniture d’une solution SSO est facultative (mais fortement recommandée) pour votre expérience utilisateur et n’est pas obligatoire pour configurer une infrastructure hybride SharePoint 2019.

Dans cet article, nous ne couvrirons pas les différences entre les solutions de synchronisation des utilisateurs et comment les configurer car cette action est généralement implémentée par un administrateur de domaine et non par l’administrateur SharePoint. Dans le contexte de cet article, nous avons utilisé Azure AD Connect pour synchroniser nos utilisateurs sur site avec Office 365. Examinons l’architecture de haut niveau d’un déploiement SharePoint hybride.

Présentation de l’architecture

Dans une infrastructure hybride, nous avons à la fois une batterie de serveurs SharePoint 2019 sur site et un locataire SharePoint Online. Il existe une configuration d’authentification de serveur à serveur (confiance S2S) entre les deux systèmes différents afin qu’ils puissent s’authentifier l’un l’autre et communiquer en toute sécurité.

Pour les fonctionnalités entrantes telles que Hybrid BCS et Inbound Hybrid Federated Search, un proxy inverse est nécessaire pour sécuriser les communications entrantes de SharePoint Online vers notre batterie de serveurs SharePoint sur site. Cela peut être visualisé dans la figure 14-1 .

Figure 14-1. Présentation de haut niveau de l’infrastructure hybride SharePoint 2019

Les fonctionnalités entrantes telles que les services de connectivité d’entreprise hybrides et la recherche fédérée entrante ne font pas partie d’un déploiement hybride classique, nous ne les couvrirons donc pas en détail dans cet article.

Présentation des fonctionnalités hybrides

Avant de commencer la configuration, nous ferons un aperçu des fonctionnalités disponibles en hybride et de ce que chacune offre !

Lanceur d’applications hybride

Le lanceur d’applications hybrides modifie le lanceur d’applications SharePoint 2019 pour être plus synchronisé avec la partie lanceur d’applications d’Office 365. Le lanceur d’applications hybrides, illustré à la figure 14-2, montre également les applications Office 365 telles que Delve et Office 365, ainsi comme toutes les applications personnalisées que vous épinglez à votre lanceur d’applications Office 365, comme «Tile de test» dans la figure 14-2 .

Figure 14-2. L’hybride lanceur App

Sites hybrides

La fonctionnalité Sites hybrides dans SharePoint 2019 et SharePoint Online permet aux sites suivis d’un utilisateur à la fois sur site et en ligne de s’afficher dans un seul emplacement ; leur SharePoint Home dans Office 365. Dans la figure 14-3, j’ai suivi le site appelé « Site de communication », et il apparaît dans ma page d’accueil SharePoint Online.

Figure 14-3. Sites hybrides

OneDrive hybride pour les entreprises

Une fois activé, Hybrid OneDrive Entreprise créera OneDrive Entreprise de l’utilisateur dans SharePoint Online au lieu de SharePoint sur site. D’un point de vue d’intégration, l’icône OneDrive dans le lanceur d’application SharePoint On-Premises redirige désormais les utilisateurs vers leur OneDrive dans Office 365. Dans la figure 14-4, vous pouvez voir l’icône OneDrive dans le lanceur d’application SharePoint 2019 me redirigeant vers mon SharePoint Site OneDrive Entreprise en ligne.

Figure 14-4. Hybrid OneDrive pour les entreprises

Sites hybrides interentreprises (B2B)

Bien que vous verrez cette fonctionnalité dans l’assistant de configuration hybride, dont nous parlerons plus tard, cette fonctionnalité ne crée pas vraiment d’intégrations entre votre batterie de serveurs SharePoint sur site et le locataire Office 365. Il n’est là que pour rappeler les fonctionnalités extranet de SharePoint Online et les avantages que vous pouvez tirer de l’hébergement de vos sites de collaboration externes dans Office 365 plutôt que sur site.

Notez que vous pouvez en savoir plus sur l’utilisation de Sharepoint en ligne en tant que solution extranet d’entreprise à entreprise (b2b) sur les documents Microsoft en cliquant sur le lien suivant:  https://docs.microsoft.com/en-us/sharepoint/create-b2b-extranet . 

Création d’un site hybride en libre-service

La création de site libre-service hybride vous permet de rediriger la page de création de site libre-service par défaut dans SharePoint Server (si vous l’avez activée) vers SharePoint Online. En activant cette fonctionnalité, vous pouvez vous assurer que tous les sites nouvellement créés se trouvent dans SharePoint Online, ayant ainsi moins de contenu à migrer lors d’une éventuelle migration vers Office 365.

Taxonomie hybride et types de contenu

La fonctionnalité de taxonomie hybride et de types de contenu vous permet d’avoir une taxonomie et un ensemble de types de contenu partagés entre votre locataire SharePoint Online et la batterie de serveurs SharePoint sur site. Une fois la migration initiale du magasin de termes effectuée via PowerShell, les termes de métadonnées gérées et les types de contenu seront synchronisés avec SharePoint sur site via un travail de minuteur quotidien.

Services de connectivité d’entreprise hybride

Les services de connectivité d’entreprise hybrides vous permettent d’afficher en toute sécurité les données d’un système externe, sous forme de liste SharePoint dans Office 365. Les utilisateurs peuvent ensuite afficher et modifier les données où qu’ils se trouvent dans le monde, sans avoir besoin d’être connectés à leur infrastructure locale. Dans la figure 14-5, vous pouvez voir les informations d’une base de données SQL Server affichées dans une liste SharePoint Online.

Figure 14-5. Services de connectivité d’entreprise hybride

Recherche hybride

SharePoint Server 2019 nous offre deux options pour intégrer la recherche entre SharePoint sur site et SharePoint Online. La première option est appelée recherche fédérée. Dans une configuration de recherche fédérée, SharePoint Server 2019 peut afficher les résultats de SharePoint Online en effectuant une requête SharePoint distante, et les utilisateurs peuvent également rechercher SharePoint sur site directement à partir de SharePoint Online. Ce qui est important à comprendre, c’est que dans un scénario de recherche fédérée, l’index reste sur le même système que les données. L’index SharePoint Server 2019 reste sur site tandis que l’index SharePoint Online reste dans le cloud.

La deuxième option est appelée Cloud Hybrid Search. Cette option nécessite un autre type d’application de service de recherche appelé Application de service de recherche cloud, et la principale différence entre la recherche fédérée et la recherche hybride cloud est que dans un scénario de recherche hybride cloud, SharePoint Server 2019 pousse l’index des éléments et des documents sur site vers Office 365, où il est fusionné avec l’index SharePoint Online. En fusionnant l’index des documents sur site et dans le cloud, vos utilisateurs auront accès aux fonctionnalités d’Office 365 uniquement, telles que Delve et Office Graph.

Présentation de la recherche fédérée hybride

Dans une configuration de recherche fédérée hybride, l’index des documents SharePoint sur site reste sur site et tout l’index SharePoint Online reste dans Office 365. Lors de la configuration de la recherche fédérée hybride, nous avons le choix entre trois topologies possibles.

One- Way sortant Topologie

Dans une topologie sortante unidirectionnelle, SharePoint Server peut interroger SharePoint Online ; cependant, SharePoint Online ne peut pas interroger SharePoint Server. Par conséquent, un utilisateur qui se connecte à SharePoint sur site et effectue une requête de recherche pourra récupérer les résultats de SharePoint sur site et de SharePoint Online. Cependant, un utilisateur effectuant une requête sur SharePoint Online ne pourra pas obtenir de résultats à partir de SharePoint sur site.

One- Way entrant Topologie

Dans une topologie entrante unidirectionnelle, SharePoint Online peut interroger SharePoint Server 2019 ; cependant, SharePoint sur site ne peut pas interroger SharePoint Online. Par conséquent, un utilisateur qui se connecte à SharePoint Online et exécute une requête pourra voir les résultats à la fois de SharePoint Online et de SharePoint sur site. Toutefois, un utilisateur effectuant une requête dans SharePoint sur site ne verra que les résultats de SharePoint sur site et non de SharePoint Online.

Deux voies ( bi – directionnel ) Topologie

Dans une topologie bidirectionnelle (bidirectionnelle), nous configurons essentiellement les topologies à sens unique entrant et à sens unique sortant. Dans cette topologie, les deux systèmes peuvent s’interroger mutuellement et donc renvoyer les résultats de l’autre système.

Présentation de la recherche dans le cloud hybride

La principale différence dans la topologie de recherche cloud hybride est que l’application de service de recherche cloud ne stocke pas l’index sur SharePoint sur site ; au lieu de cela, il le pousse vers Office 365. Sur les six composants de recherche de l’application de service de recherche, seuls les composants Admin, Crawl et Query sont actifs. Les composants Index, Content Processing et Analytics doivent exister, mais ils ne sont pas utilisés dans un scénario de recherche cloud hybride. Tous les traitements et analyses de contenu sont effectués dans Office 365, où l’index est stocké.

L’application de service de recherche dans le cloud peut analyser le même type de sources de contenu qu’une application de service de recherche normale ; par conséquent, vous pouvez envoyer des éléments à partir de sites SharePoint distants, de partages de fichiers, de BCS, etc. dans l’index SharePoint Online.

L’un des inconvénients de la topologie Hybrid Cloud Search est que vous êtes limité aux options de personnalisation de la recherche de SharePoint Online, car c’est là que le traitement du contenu est effectué et que l’index est stocké. Par conséquent, certaines options telles que l’extraction d’entité personnalisée et le service Web d’enrichissement de contenu ne sont pas disponibles. Le gros avantage de la recherche dans le cloud hybride est d’avoir des résultats homogènes lors de l’exécution d’une requête, que ces résultats proviennent de SharePoint Online ou de SharePoint On-Premises.

Quelle option choisir ?

Le choix entre la recherche fédérée et la recherche cloud hybride dépendra en fin de compte des besoins de votre entreprise et de la réglementation applicable à vos données. Dans un scénario de recherche fédérée, l’index de vos documents sur site reste des remises sur site. Dans un scénario de recherche hybride dans le cloud, votre index, et donc le contenu de tous vos documents, seront dans Office 365. Certaines réglementations concernant les données et les documents peuvent ne pas permettre à votre entreprise de mettre le contenu de vos documents dans Office 365.

En outre, dans une topologie de recherche hybride dans le cloud, puisque l’index est stocké dans SharePoint Online, tous vos utilisateurs SharePoint devront être autorisés dans Office 365 même s’ils souhaitent uniquement rechercher SharePoint sur site et ne jamais utiliser SharePoint Online. Avec la recherche fédérée hybride, les utilisateurs qui ne disposent que d’une licence sur site peuvent toujours rechercher tous les éléments SharePoint sur site.

Microsoft recommande d’utiliser la recherche hybride dans le cloud dans la mesure du possible, car elle offrira une meilleure expérience à vos utilisateurs, activera les fonctionnalités cloud uniquement sur le contenu sur site et économisera de l’espace disque et peut-être même des licences SharePoint Server 2019 sur site, car vous avez besoin d’une petite empreinte de recherche dans votre infrastructure SharePoint Server 2019 sur site. C’est l’option qui sera traitée dans ce chapitre.

Prérequis

Avant de commencer à configurer différentes fonctionnalités hybrides, vous devez avoir quelques exigences.

Prérequis SharePoint Server

Pour commencer à configurer Hybrid, vous devez configurer les applications de service suivantes sur votre serveur SharePoint Server 2019 :

1. Application de service de métadonnées gérées

2. Application de service de profil utilisateur

3. Service de gestion des applications

4. Application de service de paramètres d’abonnement

En outre, vous devez également configurer MySites dans votre application de service de profil utilisateur. Comme nous avons déjà expliqué comment créer ces applications de service, nous ne reviendrons pas sur ce sujet dans ce chapitre. Une chose importante à noter est que la propriété d’ utilisateur Work Email doit contenir l’adresse de messagerie que vous avez configurée pour l’utilisateur dans Active Directory, et la propriété User Principal Name doit être mappée à userPrincipalName attribué dans Active Directory.

Conditions préalables à l’octroi de licence

Pour pouvoir utiliser des fonctionnalités hybrides, vos utilisateurs doivent disposer de licences attribuées dans Office 365. Par défaut, lorsque Azure AD Connect synchronise les nouveaux utilisateurs dans Office 365, les utilisateurs sont synchronisés mais aucune licence n’est attribuée automatiquement. Vous pouvez utiliser des licences basées sur des groupes dans Azure Active Directory pour vous assurer que vos utilisateurs disposent automatiquement d’une licence!

Conseil Pour en savoir plus sur les licences basées sur les groupes dans Active Directory azur, cliquez ici: https://docs.microsoft.com/en-us/azure/active-directory/ fundamentals / active-directory-licensing- whatis -azure-portal .

 

Notez que si vous prévoyez d’utiliser la fonctionnalité de prévention de la perte de données de Sharepoint 2019 et que vous souhaitez qu’elle fonctionne en mode de recherche hybride dans le cloud, vous devrez également synchroniser et attribuer une licence au compte de la ferme Sharepoint. 

Exigences du proxy inverse

Si vous prévoyez de mettre en œuvre des services de connectivité d’entreprise hybrides ou la recherche fédérée entrante, vous devrez configurer un proxy inverse afin qu’Office 365 puisse accéder en toute sécurité à votre batterie de serveurs SharePoint 2019 sur site. Le proxy inverse est également requis pour afficher des aperçus des documents sur site dans SharePoint Online lors de l’utilisation de la recherche hybride dans le cloud si vous utilisez Office Online Server. Au moment de la rédaction de cet article, il existe quatre outils de proxy inverse pris en charge ; cependant, d’autres pourraient être ajoutés à l’avenir. Les quatre prises en charge par Microsoft sont

• Windows Server 2012 R2 avec proxy d’application Web
• Passerelle de gestion des menaces Forefront ( TMG ) 2010
• F5 BIG-IP
• Citrix NetScaler

Remarque pour afficher la liste à jour des procurations inverses prises en charge pour un hybride 

Infrastructure Sharepoint, visitez l’article Technet suivant. https: // documents.

microsoft.com/en-us/SharePoint/hybrid/configure-a-reverse- proxy-device-for-sharepoint-server-hybrid # pris en charge-reverse -proxy-devices .

Bien que les proxy inverses précédents soient recommandés par Microsoft, vous pouvez faire fonctionner SharePoint en mode hybride avec un proxy inverse qui prend en charge les fonctionnalités suivantes:

• Prend en charge l’authentification par certificat client avec un caractère générique ou un certificat SSL SAN.
• Prend en charge l’authentification unique pour OAuth 2.0, y compris les transactions de jetons de porteur OAuth illimitées.
• Acceptez le trafic entrant non sollicité sur le port TCP 443 (HTTPS).
• Liez un caractère générique ou un certificat SSL SAN à un point de terminaison publié.
• Relayez le trafic vers une batterie ou un équilibreur de charge SharePoint Server 2019 sur site sans réécrire aucun en-tête de paquet.

Comptes nécessaires pour la configuration et les tests hybrides

Pour configurer toutes les fonctionnalités hybrides de SharePoint 2019 décrites dans ce chapitre, vous devrez avoir accès aux comptes avec les rôles suivants :

• Administrateur global Office 365
• Administrateur de batterie de serveurs SharePoint

Pour le compte Administrateur global Office 365, nous vous recommandons d’avoir un compte cloud uniquement sans authentification multifactorielle activée lors de la configuration de votre environnement hybride. Dans cet article, nous utiliserons un compte de service dédié nommé sphybrid@cobaltatom.com.

Si vous ne prévoyez pas de déployer des fonctionnalités SharePoint hybrides pour tous les utilisateurs de votre organisation, envisagez de créer un groupe de sécurité dans Active Directory avec tous les comptes qui auront accès aux fonctionnalités hybrides. Ce groupe doit également être répliqué sur Azure Active Directory. En créant un groupe de sécurité, nous pourrons facilement créer une audience dans l’application de service de profil utilisateur SharePoint et proposer uniquement des fonctionnalités hybrides à ces utilisateurs, tandis que les autres utilisateurs pourront toujours utiliser des fonctionnalités telles que OneDrive Entreprise Sur place.

Exigences des utilisateurs du domaine

Vous devez créer un suffixe de domaine UPN pour vos utilisateurs sur site qui correspond au domaine public que vous utilisez dans Office 365. Pour donner un exemple concret, dans notre article, nous utilisons le domaine lab.cobaltatom.com pour tous nos utilisateurs et ordinateurs ; par conséquent, les noms d’utilisateur sont au format LAB \ Username. Pour que la synchronisation et le mappage des utilisateurs fonctionnent, nous configurons nos utilisateurs pour qu’ils utilisent également le format username@cobaltatom.com. Cela se fait dans la propriété « Nom de connexion de l’utilisateur », comme illustré à la figure 14-6 .

Scénario hybride

Figure 14-6. Le nom de connexion de l’utilisateur est le même que celui de notre domaine Office 365

Exigences du certificat

Pour configurer une communication sécurisée entre votre batterie de serveurs SharePoint 2019 sur site et SharePoint Online à partir d’Office 365, vous devrez mettre à jour votre SharePoint

Certificat STS (Server Security Token Service). Ce certificat est uniquement utilisé pour configurer l’approbation de serveur à serveur entre SharePoint Online et votre batterie de serveurs SharePoint 2019 Server. Conformément aux meilleures pratiques de Microsoft, dans cet article, nous utiliserons le sélecteur hybride , un outil d’interface utilisateur graphique qui facilite la configuration d’un environnement hybride. Cet outil créera un certificat auto-signé pour l’approbation de serveur à serveur. L’expiration du certificat a lieu en 9999, vous n’aurez donc pas à vous soucier de le remplacer de sitôt.

Logiciel

Si vous prévoyez de configurer la recherche hybride, vous devrez installer les outils suivants sur le serveur qui sera utilisé pour la configuration hybride :

• Assistant de connexion Microsoft Online Services ( www.microsoft.com/en- us / download / details.aspx? Id = 39267 )
• MSOnline PowerShell pour Azure Active Directory ( www.powershellgallery.com/packages/MSOnline/ )

Migrer votre taxonomie et vos types de contenu vers SharePoint Online

Si vous prévoyez d’utiliser la fonctionnalité Taxonomie hybride et types de contenu dans le cadre de votre déploiement hybride, il est recommandé de migrer vos termes et types de contenu vers SharePoint Online avant de commencer le processus de configuration. Cela peut être fait plus tard, une fois la fonctionnalité implémentée, mais cela vous obligerait à réexécuter l’assistant de configuration.

Le processus de copie conservera la plupart des informations sur les ensembles de termes tels que le propriétaire et les parties prenantes, mais seuls les utilisateurs peuvent être copiés; Les groupes Active Directory affectés en tant que propriétaires ou parties prenantes ne seront pas copiés sur Office 365.

La copie des groupes de taxonomie se fait avec l’applet de commande Copy-SPTaxonomyGroups PowerShell. Les suivants paramètres seront être nécessaires :

• LocalSiteUrl : URL du site à partir duquel vous souhaitez migrer les types de contenu. Il peut s’agir de votre hub de type de contenu local.
• LocalTermStoreName : nom du magasin de termes de votre application de service de métadonnées gérées locale.
• RemoteSiteUrl : l’URL de votre locataire SharePoint Online (https: // .sharepoint.com).
• GroupNames : nom des groupes de termes que vous souhaitez migrer vers SharePoint Online.
• Informations d’identification : un objet d’informations d’identification avec les informations d’identification de votre administrateur global Office 365.

Pour démarrer la copie, nous allons d’abord obtenir nos informations d’identification d’administrateur Office 365 et les enregistrer dans une variable appelée $ cred:

$cred = Get-Credential

Nous exécuterons ensuite l’applet de commande Copy-SPTaxonomyGroups PowerShell en spécifiant les paramètres requis. Dans notre exemple suivant, nous copions les groupes de termes d’ingénierie et de marketing sur SharePoint Online:

Copy-SPTaxonomyGroups `

-LocalTermStoreName “Managed Metadata Service Proxy” `

-LocalSiteUrl “https://sp.cobaltatom.com” `

-RemoteSiteUrl “https://cobaltatom.sharepoint.com” `

-GroupNames “Engineering”,”Marketing” `

-Credential $cred

La migration des types de contenu s’effectue via l’applet de commande Copy-SPContentTypes PowerShell, qui copiera les types de contenu vers votre concentrateur de types de contenu SharePoint Online situé à l’adresse https: // .sharepoint.com / sites / contentTypeHub. Si le site n’existe pas avant d’exécuter l’applet de commande PowerShell, il sera automatiquement créé pour vous et le concentrateur de syndication des types de contenu de la collection de sites sera activé. Les suivants paramètres seront être nécessaires :

• LocalSiteUrl : URL du site à partir duquel vous souhaitez migrer les types de contenu. Il peut s’agir de votre hub de type de contenu local.

• LocalTermStoreName : nom du magasin de termes de votre application de service de métadonnées gérées locale.

• RemoteSiteUrl : l’URL de votre locataire SharePoint Online (http: // .sharepoint.com).

• ContentTypeNames : nom des types de contenu que vous souhaitez migrer vers SharePoint Online.

• Informations d’identification : un objet d’informations d’identification avec les informations d’identification de votre administrateur global Office 365.

Afin de migrer les types de contenu Clients et Médecins de notre concentrateur de types de contenu local vers SharePoint Online, nous exécuterions l’applet de commande PowerShell suivante:

Copy-SPContentTypes `

-LocalSiteUrl https://sp.cobaltatom.com/sites/ContentTypeHub `

-LocalTermStoreName “Managed Metadata Service Proxy” `

-RemoteSiteUrl https://cobaltatom.sharepoint.com/ `

-ContentTypeNames @(“Customers”, “Doctors”) `

-Credential $cred

Configuration de SharePoint hybride

La première étape que nous devons faire est d’obtenir le sélecteur hybride SharePoint, également parfois appelé assistant de configuration hybride SharePoint. Pour l’obtenir, accédez au centre d’administration SharePoint Online et sous Configurer hybride, cliquez sur Aller à la page de téléchargement du sélecteur hybride, comme illustré à la figure 14-7. Assurez-vous que vous êtes sur le serveur SharePoint sur lequel vous souhaitez configurer SharePoint hybride, car en cliquant sur le lien, le téléchargement de l’application commencera.

Figure 14-7. Emplacement de téléchargement du sélecteur hybride

Une fois invité avec l’avertissement de sécurité illustré à la figure 14-8, cliquez sur Installer pour installer l’application.

Figure 14-8. Installation de l’Assistant Configuration hybride SharePoint

Une fois l’application installée, l’Assistant Configuration hybride SharePoint démarre. Après l’écran de démarrage, la première étape que vous devrez faire est de saisir à la fois vos informations d’identification locales et Office 365. Dans la figure 14-9, nous avons choisi de nous connecter à notre batterie de serveurs sur site avec l’utilisateur actuellement connecté et de se connecter à Office 365 à l’aide du compte de service sphybrid@cobaltatom.com que nous avons créé précédemment. Une fois ces informations entrées, cliquez sur le bouton Valider les informations d’identification. Si les informations ont été saisies correctement, vous devriez voir un message réussi comme celui de la figure 14-9 .

Figure 14-9. Validation des informations d’identification dans le sélecteur hybride SharePoint

L’assistant vérifie ensuite les prérequis nécessaires à la configuration de l’hybride sur votre batterie de serveurs. Si vous avez configuré les applications de service mentionnées plus haut dans ce chapitre et avez installé les modules requis, vous devriez voir des marques vertes à côté de chaque catégorie comme dans la figure 14-10.

Figure 14-10. Vérificateur de prérequis hybride SharePoint

Dans l’écran suivant, vous pouvez choisir les fonctionnalités hybrides que vous souhaitez que l’assistant configure pour vous. Selon la version sur laquelle vous vous trouvez, certaines options peuvent être grisées. Par exemple, dans la figure 14-11, vous pouvez voir que l’audit hybride est grisé car il n’était pas disponible sur SharePoint 2019 au moment de la rédaction de cet article.

Figure 14-11. Sélection des fonctionnalités hybrides

Certaines fonctionnalités, telles que la taxonomie hybride et les types de contenu, nécessitent la configuration de paramètres supplémentaires. Une fois que vous avez coché la case et que vous avez cliqué sur Paramètres d’entrée, un formulaire comme la figure 14-12 apparaîtra où vous pourrez saisir les informations requises. Pour la taxonomie hybride et les types de contenu, les paramètres suivants sont nécessaires :

• URL du site local : URL d’une collection de sites racine dans votre batterie de serveurs SharePoint locale.
• Nom du magasin de termes local : nom du magasin de termes de votre application de service de métadonnées gérées locale. Cela peut être différent du nom de votre application de service !
• Noms de groupes distants : les noms des groupes de taxonomie que vous souhaitez répliquer de SharePoint Online vers les locaux. Si vous ne spécifiez aucun nom, il répliquera tous les groupes sauf ceux du système.
• Noms des types de contenu distants : les noms des types de contenu que vous souhaitez répliquer de SharePoint Online vers les locaux. Si vous ne spécifiez aucun nom, il répliquera tous les types de contenu.

Vous devrez également ajouter votre compte agricole en tant qu’administrateur de magasin de termes.

Figure 14-12. Configuration de la taxonomie hybride et des types de contenu

Une autre fonctionnalité qui nécessite des paramètres d’entrée est la recherche hybride dans le cloud, illustrée à la figure 14-13. Bien que vous puissiez configurer cette fonctionnalité via l’assistant de configuration hybride SharePoint, nous vous recommandons de configurer le service de recherche cloud via PowerShell, que nous aborderons plus loin dans ce chapitre. En le configurant via PowerShell, vous aurez plus de contrôle sur la topologie, les pools d’applications et les comptes utilisés par cette application de service.

Figure 14-13. Paramètres de recherche hybride dans la configuration hybride SharePoint

Après avoir sélectionné toutes les fonctionnalités que vous souhaitez configurer, vous pouvez cliquer sur Suivant. L’Assistant Configuration hybride SharePoint commencera à configurer les paramètres et vous pourrez surveiller la progression dans l’Assistant. Une fois la configuration terminée, vous verrez un rapport de toutes les fonctionnalités qui ont été configurées avec succès, ainsi que celles qui ne l’ont pas été. Dans la figure 14-14, vous pouvez voir que la plupart des fonctionnalités hybrides ont été correctement configurées, à l’exception de la recherche hybride. Pour voir l’erreur, vous pouvez cliquer sur Afficher le rapport d’échec et vous obtiendrez plus de détails.

Figure 14-14. Résumé de la configuration de la configuration hybride SharePoint

Une fois l’Assistant terminé, un IISReset doit être effectué sur tous les serveurs SharePoint de la batterie de serveurs.

Maintenant que nous avons configuré tous les hybrides OneDrive Entreprise, les sites hybrides, le lanceur d’applications hybrides ainsi que la taxonomie hybride et les types de contenu, vérifions qu’ils fonctionnent correctement et affichons les autres options de configuration que nous avons pour ces fonctionnalités. Ensuite, nous configurerons l’application de service de recherche cloud via PowerShell.

OneDrive hybride pour les entreprises

Pour afficher ou modifier les paramètres d’Hybrid OneDrive Entreprise, vous devez vous rendre dans l’Administration centrale de SharePoint Server 2019 dans Office 365 ➤ Configurer l’hybride

Section des fonctionnalités de OneDrive et Sites et vous devriez atteindre une page similaire à la figure 14-15.

Figure 14-15. Configurer les fonctionnalités Hybrid OneDrive et Sites dans Central

Administration

Dans la section URL de mon site, le sélecteur hybride SharePoint a automatiquement entré l’URL de mon site de votre locataire SharePoint Online. Celui-ci se trouve dans le Centre d’administration SharePoint Online et est celui sous le format https: // tenantName-my. sharepoint.com .

L’une des grandes fonctionnalités d’Hybrid OneDrive Entreprise est que vous pouvez activer cette fonctionnalité uniquement pour certains utilisateurs au sein de l’organisation, tandis que les autres utiliseraient OneDrive Entreprise sur site. Si vous souhaitez activer cette fonctionnalité uniquement pour certains utilisateurs, vous devez créer une audience de ces utilisateurs et la spécifier comme illustré à la figure 14-16 .

Figure 14-16. Configuration des paramètres hybrides OneDrive Entreprise

Dans la section suivante de la page illustrée à la figure 14-17, vous pouvez modifier la fonction que nous voulons activer. Nos choix sont

• OneDrive et sites
• OneDrive uniquement
• Aucun

Figure 14-17. Boîtes radio de sélection de fonctions hybrides

Comme nous avons décidé d’activer les deux fonctionnalités dans le sélecteur hybride, la fonctionnalité OneDrive et Sites est sélectionnée. Si vous souhaitez désactiver la fonctionnalité Sites hybrides et ne conserver que OneDrive Entreprise, vous pouvez sélectionner OneDrive uniquement.

Pour tester la fonctionnalité Hybrid OneDrive Entreprise, connectez-vous en tant qu’utilisateur dans l’audience des utilisateurs hybrides et dans le lanceur d’applications, lorsque vous cliquez sur l’icône «OneDrive», vous devez être redirigé vers leur OneDrive dans Office 365. En outre, hybride- les utilisateurs activés verront également le Delve et la vidéo dans le lanceur d’applications, comme illustré à la figure 14-18 . En outre, le lien OneDrive Entreprise sera également lié au OneDrive Entreprise de l’utilisateur dans SharePoint Online.

Figure 14-18. Lanceur d’applications hybride et hybride OneDrive pour les entreprises

Les utilisateurs qui ne font pas partie de l’audience des utilisateurs hybrides verront un ruban sans «Delve» et «Video» comme le montre la figure 14-19 .

Figure 14-19. Lanceur d’applications SharePoint 2019 prêt à l’emploi

Un aspect important à retenir lors de la configuration de OneDrive Entreprise hybride est que si vous aviez déjà implémenté OneDrive Entreprise sur site et que vos utilisateurs avaient déjà placé des documents dans leur OneDrive Entreprise SharePoint 2019, ces fichiers ne seront pas migrés automatiquement vers Office 365. Vous devrez migrer ces fichiers manuellement, à l’aide de PowerShell ou d’un produit tiers. L’original Mon site et OneDrive sont toujours accessibles pour vos utilisateurs s’ils y accèdent en entrant l’URL dans le navigateur. Assurez-vous d’apprendre à vos utilisateurs à utiliser la version dans Office 365 pour les entreprises après avoir correctement migré leur contenu.

Astuce Si vous voulez éviter que les utilisateurs aient l’écran « Bienvenue » et attendre que leur onedrive for business soit créé dans Office 365 lors de leur première utilisation, vous pouvez les pré-provisionner en suivant cet article technet: https://docs.microsoft.com/en-us/onedrive/pre-provision- accounts.

Sites hybrides

La configuration des sites hybrides est vraiment liée à OneDrive Entreprise, comme vous l’avez vu dans les captures d’écran précédentes. La configuration est effectuée via l’administration centrale de SharePoint Server 2019 dans la section Configurer Office 365 ➤ Configurer les fonctionnalités hybrides OneDrive et Sites. Vous ne pouvez pas activer les sites hybrides sans activer OneDrive hybride pour les entreprises, et les sites hybrides et Hybrid OneDrive pour les entreprises partagent le même public

Pour tester la fonctionnalité, connectez-vous en tant que membre de l’audience des utilisateurs hybrides et suivez un site sur site en utilisant le bouton «Suivre» en haut à droite d’un site illustré à la figure 14-20 .

Figure 14-20. Le bouton Suivre le site

Ensuite, lorsque vous allez dans le ruban et cliquez sur l’icône SharePoint, vous devez être redirigé vers la page d’accueil SharePoint dans Office 365.

Sur la page Sites illustrée à la figure 14-21, vous devriez voir le site que vous venez de suivre à partir de votre batterie de serveurs SharePoint Server 2019 sur site. Dans notre cas, ce site est appelé « Site de l’équipe informatique » et vous pouvez le voir dans Office 365.

Astuce, cela peut prendre quelques minutes jusqu’à ce que le site apparaisse dans la maison Sharepoint. 

Figure 14-21. Sites sur site et SharePoint Online dans la page Sites Office 365

Taxonomie hybride et types de contenu

Une fois la taxonomie hybride et les types de contenu configurés dans votre batterie de serveurs SharePoint Server, un nouveau travail de minuteur appelé « Réplication des groupes de taxonomie » sera ajouté à votre batterie. Le travail de ce travail du minuteur consiste à copier tous les groupes de termes spécifiés de SharePoint Online vers SharePoint sur site. Le calendrier des travaux du minuteur, illustré à la figure 14-22, est défini par défaut pour s’exécuter une fois par jour.

Figure 14-22. Le travail du minuteur de réplication des groupes de taxonomie

Ce travail de minuteur est configurable, donc si les exigences de votre entreprise l’exigent, vous pouvez le modifier pour qu’il s’exécute toutes les heures par exemple. Pour tester le travail du minuteur, vous pouvez cliquer sur Exécuter maintenant, et s’il s’exécute correctement, vous verrez que tous les groupes de termes spécifiés ont été copiés de SharePoint Online vers votre batterie de serveurs sur site, en conservant le même nom, le même propriétaire et le même GUID. Dans la figure 14-23, vous pouvez voir que mon groupe de départements a été copié, ainsi que les différents termes à l’intérieur.

1

Figure 14-23. Termes synchronisés

Il est très important de former vos administrateurs de taxonomie délégués (toute personne autorisée à modifier des termes, un groupe de termes ou un ensemble de termes) à utiliser SharePoint Online pour créer des groupes de termes, des ensembles de termes et des termes et non à créer ou à modifier ces locaux.

Si des termes sont créés, modifiés ou supprimés sur site, ils ne seront pas répliqués sur

SharePoint Online. En outre, si le même terme est ajouté sur site en premier et dans SharePoint Online après, il sera synchronisé avec un GUID dans le nom lors de la prochaine exécution du travail du minuteur.

Conseil, vous pouvez définir le terme Définir sur site sur « Fermé » tout en le laissant « ouvert » dans Sharepoint en ligne. Lorsqu’un ensemble de termes est fermé, seuls les gestionnaires de métadonnées peuvent ajouter des termes à cet ensemble de termes. Cela empêchera les utilisateurs locaux d’ajouter des termes à un ensemble de termes existant. 

Recherche dans le cloud hybride

La recherche hybride dans le cloud est une fonctionnalité que nous vous recommandons de faire manuellement, car elle vous permettra de mieux contrôler les paramètres de votre nouvelle application de service de recherche !

Configuration de l’application de service de recherche cloud

Pour utiliser la recherche cloud hybride, vous devez d’abord configurer la recherche cloud

Application de service. L’application de service de recherche dans le cloud est très similaire à une application de service de recherche normale ; la seule différence est que la propriété CloudIndex est égale à True. Cette propriété est en lecture seule après la création d’une application de service ; par conséquent, vous ne pouvez pas convertir une application de service de recherche normale. Vous pouvez le créer via l’administration centrale, la seule différence étant que vous devez cocher la case « Application de service de recherche dans le cloud » pointée sur la figure 14-24.

Figure 14-24. Case à cocher Application Cloud Search Service

Cependant, sa création via l’administration centrale entraînera le nom de votre base de données d’avoir des GUID, ce que nous ne voulons pas. L’autre façon est bien sûr PowerShell. Dans ce chapitre, nous allons réutiliser le code PowerShell que nous avons vu dans les chapitres 3 et 6 ; la seule différence est que vous devez ajouter le paramètre -CloudIndex $ true lors de l’exécution de la cmdlet New-SPEnterpriseSearchServiceApplication.

Scénario hybride

Commençons par créer l’application de recherche dans le cloud via PowerShell, en exécutant le script suivant sur un serveur Search MinRole ou sur un serveur qui exécute les composants de recherche.

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

-CloudIndex $true

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

$sa = Get-SPEnterpriseSearchServiceApplication

$si = Get-SPEnterpriseSearchServiceInstance | ?{$_.Server -match “CALSP03”}

Start-SPEnterpriseSearchServiceInstance -Identity $si

$clone = $sa.Active Topology.Clone()

Notez que si vous exécutez sur un serveur Sharepoint exécutant le Minrole personnalisé, assurez-vous de démarrer l’instance du service de recherche avant de créer l’application de service de recherche cloud. Le démarrage de l’instance du service de recherche a été traité au chapitre 6 . 

Nous devons ensuite créer la topologie initiale et ajouter tous les composants requis à notre nouvelle application de service de recherche en exécutant le script 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

L’étape suivante consiste à ajouter également les composants sur le deuxième serveur de recherche, avec le nom de serveur CALSP04, et à activer la topologie.

$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

New-SPEnterpriseSearchQueryProcessingComponent -SearchTopology $clone

-SearchServiceInstance $si2

$clone.Activate()

Enfin, débarrassez-vous de toutes les topologies inactives et définissez le compte d’exploration sur le bon.

$sa = Get-SPEnterpriseSearchServiceApplication

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

$topo -Confirm:$false}

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

Content($sa)

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

“<Password>” -AsPlainText -Force))

Une fois le script terminé, vous pouvez accéder à l’Administration centrale et accéder à votre application de service de recherche cloud. Tout doit être exactement le même qu’une application de service de recherche normale et vos serveurs doivent afficher toutes les coches vertes. La seule différence est une boîte grise en haut de l’écran vous informant qu’il s’agit d’une application de service de recherche dans le cloud, comme le montre la figure 14-25.

Figure 14-25. Boîte d’informations sur l’application de recherche dans le cloud

Vous devez ensuite créer vos sources de contenu, mais ne lancez pas encore l’analyse car nous devons configurer la connexion entre notre application de service de recherche cloud et SharePoint Online. Ce processus est appelé On- embarquement.

On- embarquement Process

Le processus d’intégration est effectué par un script fourni par Microsoft dans le Centre de téléchargement. Ce téléchargement appelé « Scripts Windows PowerShell pour configurer la recherche hybride cloud pour SharePoint » est disponible à l’adresse www.microsoft.com/en-us/download/details. aspx? id = 51490 .

Notez que le processus d’intégration n’est nécessaire que si vous avez configuré l’application Cloud Search Service via powerShell ou l’administration centrale. vous n’avez pas besoin de le faire si vous l’avez configuré avec l’assistant de configuration hybride. 

Le fichier zip contient deux scripts. Le premier script appelé CreateCloudSSA.ps1 est utilisé pour créer l’application de service de recherche cloud, mais nous l’avons déjà créé afin que vous puissiez le supprimer. Le script important que nous utiliserons s’appelle Onboard-CloudHybridSearch.ps1.

Pour exécuter Onboard-CloudHybridSearch.ps1, vous devez disposer de l’Assistant de connexion Microsoft Online Services ainsi que de Microsoft Azure AD PowerShell installé sur le serveur sur lequel vous souhaitez l’exécuter. Nous avons précédemment installé ces prérequis lorsque nous avons configuré l’authentification de serveur à serveur plus tôt dans le chapitre, nous allons donc utiliser le même serveur pour exécuter ce script intégré.

Onboard-CloudHybridSearch prend trois paramètres :

1. PortalURL : la collection de sites racine de votre locataire SharePoint Online

2. CloudSsaId : le GUID ou le nom de votre application de service de recherche cloud

3. Informations d’identification : un objet PSCredential contenant les informations d’identification d’un administrateur Global Office 365

Le script fait quatre choses principales :

1. Get-HybridSSA

Cette section confirme que le CloudSsaId que vous avez donné est une application de service de recherche cloud valide.

2.Prepare-Environment

Cette section valide que vous avez l’Assistant de connexion Microsoft Online Services et Microsoft Azure AD PowerShell installés sur le serveur.

3. Connect-SPFarmToAAD

Cette section vérifie si vous avez déjà une configuration d’authentification de serveur à serveur et l’utilisez, sinon elle en créera une pour vous. Puisque nous en avons créé un précédemment dans ce chapitre, il a simplement utilisé celui existant. Cette section crée également un nouveau proxy de connexion SharePoint Online pour permettre à la batterie de serveurs de communiquer avec le point de terminaison externe du service de recherche cloud.

4. Add-ServicePrincipal

Cette section ajoutera l’ID principal d’Office 365 et créera quatre nouveaux principaux de service.

Maintenant que nous savons ce que fait le script, nous devons d’abord créer les trois variables que nous passerons comme paramètres au script. Nous avons expliqué ces variables plus tôt.

$PortalUrl = “https://cobaltatom.sharepoint.com”

$CloudSsaId = “Cloud Search Service Application”

$Credential = get-credential

Ensuite, nous devons accéder au dossier où se trouve Onboard-CloudHybridSearch.

Le script ps1 est et exécute l’applet de commande PowerShell suivante :

.\Onboard-CloudHybridSearch.ps1 $PortalUrl $CloudSsaId $Credential

Le script doit se terminer sans aucune erreur et sans rompre les configurations hybrides existantes.

Notez que le script peut générer une erreur lors du «redémarrage de Sharepoint Server 

Rechercher… »si vous ne l’avez pas exécuté à partir d’un serveur Search Minrole ou d’un serveur exécutant les services de recherche. Assurez-vous d’exécuter la cmdlet Restart-Service OSearch16 ou de redémarrer manuellement le service de recherche sur tous les serveurs de recherche de votre topologie Cloud SSa.

Lorsque le processus d’intégration est terminé, il est temps d’explorer notre contenu et de voir si tout a fonctionné.

Crawling et d’essais

Afin d’obtenir les données dans Office 365, nous devons d’abord les analyser. Accédez à l’administration centrale et à votre application de service de recherche cloud. Ensuite, accédez aux sources de contenu et lancez une analyse complète sur l’une de vos sources de contenu avec du contenu SharePoint.

Attendez la fin de l’exploration et vérifiez le journal d’exploration pour vous assurer qu’il existe un taux de réussite élevé et aucune erreur de niveau supérieur.

Conseil Avec l’application Cloud Search Service, la ligne des éléments consultables dans l’écran d’administration de la recherche affichera toujours 0. vous devez vérifier le journal d’analyse pour voir combien d’éléments ont été marqués comme ayant été correctement explorés. 

Une fois l’analyse terminée et que vous avez vérifié que les documents ont été correctement analysés, accédez à votre Centre de recherche Office 365 et recherchez la requête suivante : isexternalcontent: 1. La propriété isexternalcontent est une propriété gérée faisant partie du schéma de recherche SharePoint Online. Cette propriété est automatiquement définie sur VRAI pour le contenu sur site (externe à partir de SharePoint Online) et FAUX pour le contenu SharePoint Online. Cette propriété nous permettra de filtrer les résultats sur site ou SharePoint Online dans nos sources de résultats. Lorsque vous recherchez isexternalcontent: 1 dans le centre de recherche SharePoint Online, vous devez contenu à partir de votre batterie de serveurs SharePoint sur site, comme illustré à la figure 14-26 .

Figure 14-26. Test de l’application de service de recherche cloud

Vous pouvez facilement vérifier que le contenu provient de chez vous en consultant l’URL. Le contenu SharePoint Online se termine toujours par «.sharepoint.com».

Si vous effectuez une requête pour le contenu dont vous savez qu’il existe aux deux emplacements, vous devriez voir les résultats des deux systèmes, comme le montre la figure 14-27 . Les deux premiers résultats proviennent de SharePoint Online tandis que les deux suivants proviennent de SharePoint 2019 sur site.

Scénario hybride

Figure 14-27. Les résultats de SharePoint Online et de SharePoint On-Premises sont affichés

Une fois que vous avez obtenu les résultats des deux systèmes, cela signifie que l’application de service de recherche cloud fonctionne correctement, et vous pouvez définir le calendrier et analyser vos sources de contenu restantes. Cependant, comme nous n’avons plus d’index sur site, toutes vos zones de recherche sur site et votre centre de recherche ne fonctionneront pas à ce stade. Corrigeons-les afin que nos utilisateurs aient une grande expérience et puissent rechercher du contenu à partir de SharePoint Online et d’Office 365.

Recherche de SharePoint On- Local

La source de résultats par défaut pour l’application de service de recherche dans le cloud reste l’index SharePoint local, identique à une application de service de recherche standard. Cependant, puisque l’application Cloud Search Service pousse tous les éléments analysés dans l’index SharePoint Online, toutes nos requêtes sur site cessent de renvoyer des résultats, y compris les zones de recherche dans les bibliothèques de documents.

Nous devrons modifier la source de résultats par défaut de l’application de service de recherche cloud pour utiliser une nouvelle source de résultats qui interroge SharePoint Online pour les résultats. Cela utilise la même technique que la recherche fédérée sortante.

Pour créer la source de résultats, ouvrez l’Administration centrale, accédez à l’application de service de recherche dans le cloud et accédez à la page Sources de résultats. Cliquez sur le bouton “Nouvelle source de résultats” pour créer une nouvelle source de résultats.

Donnez un nom à la source des résultats, par exemple « Résultats combinés », ainsi qu’une description significative. Le protocole doit être « SharePoint distant » et l’URL du service distant doit être la collection de sites racine de votre locataire SharePoint Online, comme illustré à la figure 14-28.

Figure 14-28. Création d’une source de résultats de résultats combinés

Le type sera « Résultats de recherche SharePoint » et nous ne transformerons pas la requête pour cette source de résultats car nous voulons tous les résultats, sur site et en ligne. Dans les informations d’identification, choisissez « Authentification par défaut », comme illustré à la figure 14-29.

Figure 14-29. Création d’une source de résultats de résultats combinés

Cliquez sur Enregistrer et vous serez redirigé vers la page Source des résultats. Cliquez sur le menu déroulant de la source de résultats que vous venez de créer et cliquez sur « Définir par défaut » comme illustré à la figure 14-30 .

Figure 14-30. Définition de la source de résultats par défaut

Vos zones de recherche sur site ainsi que le Centre de recherche afficheront désormais les résultats à la fois sur site et SharePoint Online, exactement comme si un utilisateur effectuait une recherche à partir du Centre de recherche SharePoint Online.

Bien que la combinaison des résultats des deux systèmes soit une fonctionnalité étonnante, vos utilisateurs peuvent vouloir cibler uniquement certains systèmes. Dans la section suivante, nous apprendrons comment personnaliser nos résultats de recherche.

Personnalisation de vos résultats de recherche

En créant des sources de résultats dans SharePoint Online et SharePoint Server 2019, vous pouvez créer différentes pages dans vos centres de recherche pour afficher par exemple uniquement les résultats sur site ou uniquement les résultats SharePoint Online.

Pour créer différentes pages qui affichent les résultats uniquement de certains systèmes, vous pouvez créer différents onglets dans vos centres de recherche SharePoint avec différentes sources de résultats. Les sources de résultats utiliseraient le générateur de requêtes et la propriété gérée isexternalcontent pour renvoyer les résultats appropriés. Par exemple, vous pouvez avoir le texte de requête suivant pour renvoyer uniquement les résultats SharePoint Online :

{searchTerms} NOT(IsExternalContent:1)

Ou le texte de requête suivant pour les résultats sur site uniquement :

{searchTerms}(IsExternalContent:1)

Il faudra également planifier la recherche de personnes. Par défaut, tous les utilisateurs de l’application de service de profil utilisateur SharePoint Online seront indexés par le robot d’indexation Office 365. Si vous explorez également des utilisateurs sur site à l’aide de votre application de service de recherche cloud, vos résultats de recherche renverront des données en double. Il existe deux options pour contourner ce défi.

La première option consiste à utiliser le service de profil utilisateur Office 365 comme source principale d’informations sur les utilisateurs et à laisser la recherche Office 365 se charger de l’explorer. De cette façon, vous n’aurez pas besoin d’analyser les données des personnes sur site.

La deuxième option si vous souhaitez conserver le service de profil utilisateur sur site en tant que source principale d’informations sur les utilisateurs, vous devrez analyser les données des personnes sur site, puis utiliser les règles de transformation de requête pour n’afficher que les résultats sur site. Pour cela, vous pouvez ajouter une nouvelle source de résultats pour la recherche de personnes et utiliser la propriété gérée isexternalcontent pour filtrer les résultats.

Prochaines étapes

Dans ce chapitre, nous avons appris à configurer un SharePoint hybride 2019

Infrastructure et offre des fonctionnalités supplémentaires à vos utilisateurs. Dans le chapitre suivant, nous apprendrons comment utiliser d’autres fonctionnalités exclusivement cloud telles que PowerApps et Microsoft Flow avec votre contenu sur site!

CHAPITRE 15 PowerApps et Flow

Nous allons commencer à voir comment utiliser Microsoft PowerApps et Microsoft Flow avec SharePoint Server 2019 via la passerelle de données Microsoft On-Premises. Microsoft Flow et PowerApps sont la méthode recommandée pour automatiser les processus métier et créer des applications pour les environnements hybrides SharePoint 2019 et SharePoint Online. Ces services sont toujours des services cloud uniquement, ce qui signifie qu’ils ne s’exécutent que dans le cloud, mais vous pouvez les intégrer aux données locales. Ce chapitre couvrira l’installation d’une passerelle de données hautement disponible ainsi que des exemples d’utilisation de PowerApps et Flow avec des données SharePoint onpremises.

Microsoft On- Local Data Gateway

La passerelle de données Microsoft peut être déployée sur un ou plusieurs serveurs dans votre environnement local. La passerelle de données peut être configurée pour s’exécuter sous un compte de service géré Active Directory spécifié, un compte d’utilisateur de domaine ou le compte de service par défaut. Notre scénario utilisera une implémentation de passerelle de données à deux nœuds hautement disponibles en utilisant le compte de service par défaut, NT SERVICE \ PBIEgwService. Vous devrez peut-être utiliser un autre compte Active Directory si vous disposez d’un serveur proxy en amont qui nécessite une authentification. Si vous rencontrez ce scénario, utilisez un compte de service géré Active Directory, comme ce qui a été configuré pour SQL Server dans le chapitre 3 de cet article.

Remarque La passerelle de gestion des données peut être téléchargée à partir de https: // go.microsoft.com/fwlink/?LinkID=820925 ou via le site PowerApps à https://web.powerapps.com . 

Installation

Dans ce scénario, nous déploierons la passerelle de gestion des données sur CALDMG01 et CALDMG02. Ces serveurs sont joints au domaine Active Directory et ne nécessitent aucun port de pare-feu pour être ouvert en provenance d’Internet public. Les serveurs exécutent Windows Server 2016. Bien que Microsoft recommande un processeur 8 cœurs et 8 Go de RAM, le dimensionnement exact du serveur dépendra de votre utilisation du service.

Comme la passerelle vous oblige à vous connecter à Office 365 à partir du serveur sur lequel elle est installée, vous souhaiterez peut-être désactiver la configuration de sécurité renforcée IE pour les utilisateurs dans le Gestionnaire de serveur, les paramètres du serveur local.

Après avoir téléchargé le programme d’installation de la passerelle, exécutez-le sur le premier serveur Data Management Gateway. L’installation ne vous demandera que le chemin d’installation de la passerelle. Une fois l’installation terminée, vous serez invité à saisir une adresse e-mail associée à la passerelle, comme illustré à la figure 15-1.

Figure 15-1. Spécification d’une adresse e-mail pour la passerelle de données

Vous serez invité à vous connecter à Office 365 à l’aide de l’adresse de messagerie de la figure 15-1. Une fois la connexion terminée, nous configurerons la passerelle. Vous serez invité à créer le nom de la passerelle. Voici comment le nom apparaîtra lors de la connexion à la passerelle depuis PowerApps ou Flow. Vous devrez également spécifier une clé de récupération pour la passerelle, comme le montre la figure 15-2. Conservez cette clé dans un endroit sûr.

Figure 15-2. Configuration de la passerelle de données

La passerelle sur site est configurée à ce stade et l’état PowerApps, Microsoft Flow doit être vert, comme illustré à la figure 15-3.

Figure 15-3. Une passerelle configurée avec succès

Des options supplémentaires sont disponibles dans les paramètres de la passerelle, comme sous Réseau, nous pouvons configurer Azure Service Bus pour utiliser TLS 1.2.

Pour ajouter un serveur supplémentaire à Data Management Gateway, démarrez l’installation sur le deuxième serveur. Utilisez la même connexion lorsque vous êtes invité à entrer une adresse e-mail, comme indiqué précédemment dans la figure 15-1. Une fois connecté au service, une invite vous invite à enregistrer une nouvelle passerelle ou à migrer une passerelle, comme illustré à la figure 15-4. Choisissez l’option pour enregistrer une nouvelle passerelle.

Figure 15-4. Lorsqu’une autre passerelle est détectée, vous devrez choisir une option pour enregistrer la passerelle comme nouvelle ou migrer une passerelle existante

Saisissez un nouveau nom de passerelle et sélectionnez l’option Ajouter à un cluster de passerelle existant. Sélectionnez la passerelle précédente que nous avons créée, puis entrez la même clé de récupération que celle utilisée pour créer la passerelle initiale, comme illustré à la figure 15-5.

Figure 15-5. Configuration de la deuxième passerelle de données

Comme indiqué précédemment dans la figure 15-3, une passerelle correctement configurée s’affiche comme prête pour PowerApps et Microsoft Flow. Notez que si vous avez configuré la première passerelle pour utiliser TLS 1.2 sous l’onglet Réseau, vous devrez également la définir sur toutes les passerelles déployées ultérieurement.

Administration de la passerelle

Pour vérifier l’état et administrer la passerelle, accédez à https://web.powerapps.com ou https://flow.microsoft.com et connectez-vous avec le même compte que celui utilisé pour enregistrer les passerelles auprès d’Office 365. Sur l’un ou l’autre service, dans la navigation de gauche sous Données, puis Passerelles, vous pouvez administrer toutes les passerelles locales. Si vous avez navigué vers Microsoft Flow, vous serez redirigé vers PowerApps pour administrer la passerelle, comme le montre la figure 15-6.

Figure 15-6. Administration de la passerelle à partir de PowerApps

En cliquant sur le bouton Partager, vous pouvez ajouter des utilisateurs individuels ayant la capacité d’utiliser la passerelle, y compris le type de services auxquels ils peuvent se connecter. Vous pouvez également autoriser l’utilisateur à utiliser la passerelle mais également à la partager. Enfin, vous pouvez en faire un administrateur de la passerelle. Vous pouvez également partager la passerelle avec tous les utilisateurs de votre organisation qui sont synchronisés avec Azure AD et qui sont autorisés pour PowerApps, Power BI ou Flow, comme illustré dans la figure 15-7.

Figure 15-7. Ajout de tous les utilisateurs de l’organisation à la passerelle

Cliquez sur Détails pour afficher l’état de la connexion à la passerelle. Si une ou plusieurs passerelles sont en ligne, l’état sera Live, comme illustré à la figure 15-8.

Figure 15-8. Une ou plusieurs passerelles sont en ligne

Si toutes les passerelles sont en panne, vous verrez une erreur, comme le montre la figure 15-9. Cela peut être dû au fait que le serveur ou le service de passerelle est hors ligne.

Figure 15-9. Toutes les passerelles sont dans un état indisponible

PowerShell

Les passerelles peuvent également être configurées via PowerShell. Par défaut, le module PowerShell est installé sur «C:\Program Files\On-premises data gateway\OnPremisesDataGatewayHAMgmt.psm1». Vous devez d’abord vous connecter à la passerelle via PowerShell avant d’utiliser les autres applets de commande disponibles à l’aide de Login-

OnPremisesDataGateway. Utilisez Get-OnPremisesDataGatewayClusters pour récupérer l’ID d’objet (également appelé ClusterObjectId) et le gatewayObjectId. Il y aura un gatewayObjectId par serveur de passerelle dans le cluster. Dans cet exemple, la sortie de GetOnPremisesDataGatewayClusters affiche mon ID d’objet sous la forme 12558961-deac-4142-99524e9325d63ad5 et mes serveurs secondaires gatewayObjectId sous 6dc96cc6-70a8-48f9-90aeb1305780841f. Pour savoir si le logiciel Microsoft Data Gateway est à jour, je peux ensuite exécuter Get-OnPremisesDataGatewayStatus, comme indiqué ci-dessous avec la sortie :

Get-OnPremisesDataGatewayStatus -ClusterObjectId 12558961-deac-4142-9952-

4e9325d63ad5 -GatewayObjectId 12558961-deac-4142-9952-4e9325d63ad5

gatewayStatus gatewayVersion gatewayUpgradeState

————- ————– ——————-

Live 3000.0.155.1 UpToDate

Maintenant que notre passerelle est configurée, commençons à créer des workflows et des applications, mais avant cela, vérifiez si nous avons la bonne licence !

Exigences de licence

Depuis le 1er février 2019, Microsoft a mis en œuvre certaines modifications concernant les exigences de licence pour utiliser Flow et PowerApps avec du contenu sur site. Vérifiez les exigences de licence actuelles au moment de la mise en œuvre pour vous assurer que

Remarque Vous pouvez consulter le billet de blog annonçant les modifications sur le Tech 

Site communautaire au lien suivant: https://techcommunity.microsoft. com / t5 / Office-Retirement-Blog / UPDATED-Updates-to- Microsoft Flow – and-PowerApps-for-Office-365 / ba-p / 289589 .

Comme toujours, nous vous recommandons de parler à votre expert des licences Microsoft des cas spécifiques à votre organisation.

Workflows avec Microsoft Flow

Microsoft Flow est la méthode recommandée pour effectuer des flux de travail dans Office 365, ainsi que des scénarios SharePoint hybrides. Avant de créer nos flux, nous devons créer une connexion à notre serveur SharePoint 2019 sur site. Pour créer la connexion, ouvrez le Flow

Menu à gauche et accédez à Données, puis Connexions, comme illustré à la figure 15-10.

Figure 15-10. Connexions dans Microsoft Flow

En haut de la page, cliquez sur Nouvelle connexion et sélectionnez SharePoint dans la liste des connexions disponibles. Dans les boutons radio, sélectionnez l’ option Se connecter à l’aide d’une passerelle de données locale , comme illustré à la figure 15-11, puis sélectionnez Windows comme type d’authentification.

Figure 15-11. Création d’une nouvelle connexion pour SharePoint sur site

Après avoir défilé vers le bas, entrez votre nom d’utilisateur et votre mot de passe sur site et sélectionnez la passerelle que vous souhaitez utiliser lors de la connexion sur site, comme illustré à la figure 15-12.

Figure 15-12. Création d’une nouvelle connexion à SharePoint sur site, partie 2

Une fois la connexion établie, vous verrez une connexion SharePoint avec vos informations d’identification de domaine dans l’onglet Connexions dans Microsoft Flow, comme la figure 15-13 . En fonction de votre utilisation antérieure de Microsoft Flow, vous pouvez avoir plus ou moins de connexions que la figure 15-13 .

Figure 15-13. Le connecteur sur site nouvellement créé dans Microsoft Flow

Maintenant que notre connecteur est prêt, nous pouvons créer nos workflows. Je vais créer un flux de travail à partir de l’approbation de démarrage lorsqu’un nouvel élément est ajouté à un modèle proposé par Microsoft, et comme je veux me connecter à mon SharePoint sur site, il est important de sélectionner le bon connecteur pour SharePoint. Par défaut, le connecteur SharePoint Online sera sélectionné, mais en cliquant sur les trois points à côté de lui, vous pouvez sélectionner la connexion SharePoint avec vos informations d’identification de domaine, comme illustré à la figure 15-14.

Figure 15-14. Sélection du bon connecteur lors de la création du Flow

Vous pouvez ensuite commencer à créer vos flux comme d’habitude, et lorsque vous saisissez une collection de sites sur site, Flow sera en mesure de proposer des valeurs dynamiques en tant que suggestion de liste d’inventaire illustrée à la figure 15-15.

Figure 15-15. Flow propose une liste sur site

Vous pouvez ensuite le tester en ajoutant un élément sur votre liste sur site, ou le déclencheur que vous avez configuré, et le flux devrait démarrer dans le SLA spécifié par votre licence de flux. Dans la figure 15-16, vous pouvez voir notre flux déclenché lorsqu’un nouvel élément a été ajouté dans la liste d’inventaire de notre collection de sites sur site.

Figure 15-16. Débit déclenché avec succès

Même si l’intégration avec Microsoft Flow et SharePoint sur site est excellente, quelque chose qui manque à SharePoint 2019 par rapport à SharePoint Online est la possibilité de déclencher manuellement des flux à partir de locaux. Il n’y a pas de bouton de flux dans les listes locales SharePoint et les bibliothèques de documents, donc les déclencheurs tels que sur l’élément sélectionné sont disponibles dans Flow, mais ne peuvent pas être utilisés avec SharePoint sur site.

Maintenant que nous pouvons créer des workflows avec Microsoft Flow, regardons PowerApps.

Applications professionnelles avec PowerApps

PowerApps est l’outil recommandé pour créer des applications métier dans Office 365 et des déploiements SharePoint hybrides. PowerApps partage beaucoup de back-end avec Microsoft Flow, donc si vous avez créé la connexion pour notre environnement SharePoint On-Premises dans Flow comme nous l’avons fait plus tôt dans ce chapitre, vous devez également le voir dans vos connexions PowerApps comme illustré dans la figure 15-17.

Figure 15-17. Connexion SharePoint sur site dans PowerApps

Nous pouvons alors commencer à créer une application vierge, ou à partir d’un modèle, et dans les connexions de données, les connexions SharePoint Online et SharePoint On-Premises seront affichées. Sélectionnez celui qui affiche vos informations d’identification de domaine local et entrez l’URL de votre collection de sites SharePoint On-Premises, comme illustré à la figure 15-18, puis cliquez sur OK.

Figure 15-18. Connexions SharePoint sur site et en ligne

PowerApps devrait alors être en mesure de suggérer automatiquement les listes disponibles dans cette collection de sites, comme illustré à la figure 15-19.

Figure 15-19. Listes dans notre collection de sites sur site

Vous pouvez désormais créer votre application métier à l’aide de PowerApps avec vos données sur site. Vous pouvez utiliser les mêmes connaissances que si les données étaient entièrement dans SharePoint Online. Vous pouvez afficher le concepteur PowerApps montrant les éléments de SharePoint sur site dans la figure 15-20.

Figure 15-20. Concepteur PowerApps avec éléments SharePoint sur site

Une fois l’application publiée, vous pouvez également la consommer depuis votre téléphone mobile. Dans la figure 15-21, vous pouvez afficher la même application affichant des éléments sur site sur mon téléphone Android.

Figure 15-21. Éléments sur site dans PowerApps sur un téléphone Android

Comme Microsoft Flow, bien que l’intégration entre PowerApps et SharePoint Server 2019 soit excellente, certaines fonctionnalités manquent. L’un des plus importants est la possibilité de personnaliser les formulaires de liste SharePoint à l’aide de PowerApps et d’afficher ces formulaires directement dans la liste.

Nous avons maintenant créé avec succès les deux flux de travail avec Microsoft Flow et les applications d’entreprise avec PowerApps qui consomment le contenu de notre implémentation SharePoint sur site.

Prochaines étapes

Dans ce chapitre, nous avons appris à installer la passerelle de données sur site qui nous permet d’utiliser les dernières applications métier telles que Flow et PowerApps afin de créer des workflows et des applications avec notre contenu local. Une fois la connexion établie, les utilisateurs peuvent simplement consommer ces services sans avoir besoin de connaissances supplémentaires autres que les bases de Flow et PowerApps. Si vous souhaitez en savoir plus sur Flow et PowerApps, Apress a un article sur chaque sujet que vous pouvez apprendre.

Notre prochain chapitre couvrira comment migrer du contenu vers SharePoint Server 2019.

CHAPITRE 16 Migration vers SharePoint Server 2019

Dans les chapitres précédents, nous avons installé SharePoint et configuré nos applications Web et nos applications de service. Si votre entreprise exécute actuellement une version précédente de SharePoint telle que SharePoint 2013, SharePoint 2016 ou même plus tôt, vous souhaiterez probablement migrer ces données vers votre nouvelle batterie de serveurs SharePoint 2019.

Dans ce chapitre, nous apprendrons comment migrer des sites de SharePoint 2016 vers SharePoint 2019 ainsi que les applications de métadonnées gérées, de profil utilisateur, de recherche et de gestion des applications.

Chemin de migration

Semblable aux versions précédentes de SharePoint, le seul chemin direct pour migrer vers SharePoint Server 2019 est à partir de sa version précédente, qui est SharePoint 2016. Si vous êtes actuellement sur SharePoint Server 2013 et souhaitez migrer vers SharePoint Server 2019, vous devrez migrer vers une batterie de serveurs SharePoint Server 2016, puis migrez par la suite de SharePoint Server 2016 vers SharePoint Server 2019. Ce chemin de haut niveau est illustré à la figure 16-1. Il existe des outils tiers créés par Microsoft Partners qui vous permettent de migrer directement de presque toutes les versions de SharePoint vers SharePoint 2019; cependant, ceux-ci ont un prix.

Figure 16-1. Migration de SharePoint 2013/2016 vers SharePoint 2019

Il n’y a pas de niveau de correctif SharePoint 2016 requis pour mettre à niveau les bases de données de SharePoint 2016 vers SharePoint Server 2019, mais il est recommandé d’être sur la dernière mise à jour publique disponible. Vous devez également vous assurer que toutes les collections de sites sont en mode 15 et que toutes les applications Web utilisent des revendications et non une authentification classique. Si des applications Web sont toujours en mode classique, vous pouvez les convertir à l’aide de l’applet de commande Convert-SPWebApplication PowerShell.

Maintenant que nous comprenons les exigences et le chemin de migration, dans la section suivante, nous verrons comment migrer les applications de service de SharePoint 2016 vers SharePoint 2019.

Migration des applications de service

La première étape pour apprendre à migrer de SharePoint 2016 vers SharePoint Server 2019 consiste à migrer les applications de service.

Application de service de métadonnées gérées

Pour migrer l’application de service de métadonnées gérées, la première chose que vous devez faire est de sauvegarder la base de données d’application de service à partir de SharePoint 2016 et de la restaurer sur notre serveur SQL Server 2019 SharePoint. Une fois sur SQL Server, la façon de mettre à niveau l’application de service de métadonnées gérées est de créer une nouvelle application de service comme nous l’avons appris au chapitre 8, mais de spécifier la base de données que nous venons de transférer de SharePoint Server 2016. Dans notre environnement, nous avons nommé cette base de données ManagedMetadataDB, et nous allons créer l’application de service avec PowerShell comme nous l’avons appris au chapitre 8. Pour créer l’application de service, utilisez la New-SPMetadataServiceApplication avec le nom de base de données que nous avons restauré à partir de SharePoint Server 2016. Il s’agit de l’applet de commande que nous avons utilisée dans notre environnement. Nous avons également créé le proxy d’application de service à l’aide de l’applet de commande New-SPMetadataServiceApplicationProxy.

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

-DatabaseName “ManagedMetadataDB” -ApplicationPool “SharePoint Web Services

Default” -SyndicationErrorReportEnabled

New-SPMetadataServiceApplicationProxy -Name “Managed Metadata

Service Proxy” -ServiceApplication $sa -DefaultProxyGroup

-ContentTypePushdownEnabled -DefaultKeywordTaxonomy

-DefaultSiteCollectionTaxonomy

En migrant la base de données d’application de service, vous vous assurez que les ID de terme ne changent pas ; par conséquent, toutes les connexions entre le contenu migré et les conditions resteront intactes.

Application de service de recherche

La prochaine application de service que nous migrerons vers SharePoint 2019 est l’application de service de recherche. L’application de service de recherche possède quatre bases de données ; cependant, nous avons seulement besoin d’obtenir la base de données d’administration de l’ancien SharePoint et de la restaurer sur notre serveur SQL SharePoint 2019.

SharePoint a une applet de commande PowerShell que nous utiliserons nommée Restore-SPEnterpriseS earchServiceApplication, qui prend le nom de votre ancienne base de données d’administration, ainsi que le serveur de base de données avec le nom de l’application de service et le pool d’applications. SharePoint créera ensuite une application de service de recherche à partir de votre base de données, qui conservera vos sources de contenu, les paramètres du centre de recherche, le schéma de recherche et les règles d’analyse de votre application de service de recherche SharePoint 2016. Cette application de service conservera également le même compte d’analyse, cependant, et nous vous recommandons d’avoir différents comptes d’analyse entre vos batteries de serveurs; par conséquent, assurez-vous de changer par la suite.

Assurez-vous d’exécuter le script suivant sur un serveur exécutant le rôle Search MinRole. Nous allons d’abord obtenir l’instance de service de recherche locale, puis l’enregistrer dans une variable appelée $ si.

$si = Get-SPEnterpriseSearchServiceInstance –local

Afterward, we will create the Search Service Application using the Restore- SPEnter priseSearchServiceApplication cmdlet and specifying the database we have restored, in this case it’s named SharePoint_2016_Search.

$sa = Restore-SPEnterpriseSearchServiceApplication -Name

‘SearchServiceApplication’ -applicationpool “SharePoint Web Services

Default” -databasename SharePoint_2016_Search -databaseserver caspag.lab. cobaltatom.com -AdminSearchServiceInstance $si

Enfin, nous allons créer un nouveau proxy d’application de service de recherche et l’affecter à l’application de service que nous venons de créer.

Service de recherche New-SPEnterpriseSearchServiceApplicationProxy -Name ”

Proxy d’application “-SearchApplication $ sa

Vous avez maintenant migré votre application de service de SharePoint 2016 vers

SharePoint Server 2019. Notez que vous devrez définir la topologie de l’application de service de recherche à l’aide de PowerShell. Nous avons appris comment faire si au chapitre 6.

Application de service de profil utilisateur

La première chose que nous devons faire est de sauvegarder deux des trois bases de données de profils d’utilisateurs de SharePoint Server 2016. Nous devons sauvegarder la base de données sociales ainsi que la base de données de profils. Il n’est pas utile de transférer la base de données Sync vers SharePoint 2019 car les mappages entre les propriétés et Active Directory sont stockés dans Microsoft Identity Manager, et non dans la base de données SharePoint Sync.

Nous allons ensuite créer une nouvelle application de service de profil utilisateur à l’aide de la cmdlet New-SPProfileServiceApplication comme indiqué au chapitre 7 et spécifier le nom de ces deux bases de données dans les paramètres ainsi qu’un nom pour la base de données Sync. Étant donné que cette base de données n’existe pas, SharePoint la créera. L’applet de commande que nous avons utilisée dans notre environnement est la suivante :

$sa = New-SPProfileServiceApplication -Name “User Profile Service

Application” -applicationpool “SharePoint Web Services Default”

-ProfileDBName ‘Profile_DB_2016’ -SocialDBName ‘Social_DB_2016’

-ProfileSyncDBName ‘Sync_DB’

Nous devons ensuite créer un proxy d’application de service à l’aide de l’applet de commande suivante :

New-SPProfileServiceApplicationProxy -Name “User Profile Service

Application Proxy” -ServiceApplication $sa –DefaultProxyGroup

Avec l’application de service en place, vous devez mettre à jour Microsoft Identity

Gestionnaire, comme indiqué au chapitre 7, pour qu’il envoie des informations de profil à la nouvelle batterie de serveurs SharePoint Server 2019. Si vous utilisez l’importation Active Directory, configurez l’application de service de profil utilisateur comme indiqué au chapitre 7.

Ajouter des -ins

Les compléments SharePoint (applications) étaient une nouvelle méthode de développement introduite avec SharePoint Server 2013 et votre entreprise aurait pu profiter de cette méthode de développement pour déployer des solutions sur vos sites SharePoint. Nous avons déjà expliqué comment configurer les compléments au chapitre 5, et toute la configuration DNS ainsi que la configuration des URL de complément doivent être effectuées avant de poursuivre cette étape.

Remarque Votre URL de complément n’a pas besoin d’être la même dans Sharepoint 2019 qu’elle ne l’est dans Sharepoint 2016. 

À partir de la batterie de serveurs SharePoint Server 2016, nous devrons sauvegarder les bases de données de l’application App Management Service ainsi que de l’application de service d’abonnement et les restaurer sur le serveur de base de données de la batterie de serveurs SharePoint Server 2019.

Nous allons ensuite créer ces applications de service comme indiqué au chapitre 5, et spécifier d’utiliser le nom des bases de données restaurées. Nous allons d’abord créer l’application de service d’abonnement et le proxy avec les applets de commande PowerShell suivantes :

$SubscriptionSA = New-SPSubscriptionSettingsServiceApplication –

ApplicationPool “SharePoint Web Services Default” –Name “Subscription

Settings Service Application” –DatabaseName SharePoint_2016_

SubscriptionSettings

$proxySub = New-SPSubscriptionSettingsServiceApplicationProxy –

ServiceApplication $SubscriptionSA

Ensuite, nous créerons l’application App Management Service) et son proxy à l’aide des applets de commande suivantes :

$AppManagementSA = New-SPAppManagementServiceApplication –ApplicationPool

“SharePoint Web Services Default” -Name “App Management Service

Application” -DatabaseName SharePoint_2016_AppManagement

$proxyApp = New-SPAppManagementServiceApplicationProxy -ServiceApplication

$AppManagementSA

Sur la page Licences d’application de l’Administration centrale, vous verrez les compléments que vous avez installés, ainsi que les types de licence que vous avez, comme illustré à la figure 16-2.

Figure 16-2. Licences d’application SharePoint 2019

Lors de la restauration des bases de données de contenu qui comprenaient ces compléments, les compléments) seront installés et vous pourrez les utiliser comme vous l’avez fait dans votre environnement SharePoint 2016.

Avec la migration des applications de service, l’étape suivante consiste à apprendre à migrer nos sites SharePoint de SharePoint 2016 vers SharePoint 2019.

Migration de contenu

La migration de contenu de SharePoint Server 2016 vers SharePoint Server 2019 se fait en migrant les bases de données de SharePoint 2016 vers SharePoint 2019 et en les attachant à une application Web. La première étape consiste à identifier les collections de sites que vous souhaitez migrer de SharePoint 2016 vers SharePoint 2019. Vous pouvez migrer toutes les bases de données dans une application Web ou des bases de données particulières contenant des collections de sites particulières ; la chose importante à retenir est que les migrations de contenu se font au niveau de la base de données de contenu. Par conséquent, si vous ne souhaitez migrer que quelques collections de sites à partir de votre application Web, assurez-vous de les regrouper dans la même base de données de contenu. Vous pouvez déplacer des collections de sites entre des bases de données dans la même application Web à l’aide de l’applet de commande Move-SPSite PowerShell. Il ne faut pas oublier que si vous migrez uniquement certaines collections de sites au sein d’une application Web, vous devrez peut-être utiliser une URL différente dans SharePoint 2019 afin de garder le reste des collections de sites accessibles.

Sauvegardez la base de données à partir de SQL Server utilisé par SharePoint et restaurez-la avec le nom que vous souhaitez sur le serveur SQL utilisé par SharePoint Server 2019, comme illustré à la figure 16-3. Il n’est pas nécessaire que la base de données existe avant la restauration et vous pouvez entrer un nouveau nom pour cette base de données dans le champ Base de données.

Conseil, il est recommandé de sauvegarder les bases de données à l’aide de l’option Copier uniquement. cela garantira que le plan de sauvegarde sur l’environnement source reste cohérent. 

Figure 16-3. Restaurer la base de données de contenu

Une fois la base de données restaurée, créez votre application Web sur SharePoint Server 2019 si vous ne l’avez pas déjà fait. Lors de la création de votre application Web, vous devez également créer une nouvelle base de données de contenu, mais vous pouvez lui donner un nom temporaire car nous supprimerons cette base de données après la création de l’application Web. Nous avons expliqué comment créer des applications Web au chapitre 13, et pour ce test, nous avons créé une application Web avec l’URL https://intranet.cobaltatom.com et une base de données appelée «WSS_TempDB». Pour supprimer cette base de données, nous utiliserons l’applet de commande Remove-SPContentDatabase PowerShell. Pour supprimer toutes les bases de données de contenu de l’application Web intranet.cobaltatom.com, nous devons exécuter l’applet de commande suivante:

Get-SPContentDatabase -WebApplication

https://intranet.cobaltatom.com |Dismount-SPContentDatabase

Notre application Web est maintenant prête à monter la base de données de contenu restaurée sur le serveur SQL utilisé par SharePoint Server 2019. Avant de joindre la base de données, nous pouvons utiliser l’applet de commande PowerShell Test-SPContentDatabase. Pour tester notre base de données par rapport à l’application Web intranet.cobaltatom.com, nous exécuterions l’applet de commande suivante :

Test-SPContentDatabase -Name SP_Intranet_2019 -WebApplication https:// intranet.cobaltatom.com

Cela nous donnera un rapport sur les problèmes que nous pourrions rencontrer lors de la migration. Certains exemples sont les fonctionnalités manquantes dans la batterie de serveurs SharePoint 2016 qui ont été référencées dans la collection de sites. Le rapport affichera à la fois des erreurs et des avertissements, et nous informera si l’erreur est « Blocage de mise à niveau ». Si l’erreur est le blocage de mise à niveau, cela signifie que SharePoint peut ne pas être en mesure de mettre à niveau cette base de données vers SharePoint 2019. Si l’erreur n’est pas un blocage d’erreur, SharePoint pourra mettre à niveau la base de données, mais vos utilisateurs peuvent obtenir des comportements inattendus lors de la navigation vers parties du site. Pour notre exemple illustré à la figure 16-4, notre base de données possède actuellement des fonctionnalités Power View et SSRS ; cependant, ces fonctionnalités n’existent pas dans l’application Web.

Figure 16-4. Résultats de Test-SPContentDatabase

Les deux choix que nous avons pour éviter ces problèmes sont soit de supprimer ces fonctionnalités de SharePoint 2019, soit de les activer et d’avoir ces fonctionnalités prêtes sur la batterie de serveurs. Les supprimer serait une option valide lorsque nous n’utiliserions plus ces fonctionnalités dans SharePoint 2019. Lorsque tout est prêt et que Test-SPContentDatabse ne renvoie plus d’erreurs de blocage, nous pouvons procéder à la mise à niveau. La mise à niveau se fait automatiquement lorsque vous attachez la base de données de contenu à l’application Web. Cela se fait via PowerShell avec l’applet de commande Mount-SPContentDatabase. Les paramètres sont les mêmes que la cmdlet Test-SPContentDatabase, le nom de la base de données et l’application Web. Pour joindre notre base de données de contenu, nous avons exécuté l’applet de commande suivante:

Mount-SPContentDatabase -Name SP_Intranet_2019 -WebApplication https:// intranet.cobaltatom.com

PowerShell affichera un avertissement indiquant que la progression et les détails seront au même emplacement que vos fichiers journaux ULS, comme illustré à la figure 16-5. Le processus de mise à niveau crée deux fichiers journaux sous le format :

• Mise à niveau – <date> – < guid >. Journal
• Mise à niveau – <date> – < guid > – erreur . Journal

Figure 16-5. Mount-SPContentDatabase

Le fichier d’erreur affichera toutes les erreurs qui pourraient s’être produites pendant le processus de mise à niveau. La durée de la mise à niveau dépendra du nombre de collections de sites que vous avez dans votre base de données, ainsi que de la quantité de contenu de ces sites.

Une fois la base de données correctement connectée, vous pourrez accéder aux collections de sites que vous avez migrées et tester les fonctionnalités du site. Les autorisations sur le site et le contenu SharePoint n’auront pas changé entre SharePoint 2016 et SharePoint 2019.

Nous avons maintenant appris à migrer du contenu, ainsi que les applications de service les plus populaires de SharePoint Server 2016, vers SharePoint Server 2019. Voyons maintenant dans quel ordre nous devons effectuer ces migrations.

Ordonnance de migration

Il est recommandé de toujours migrer vos applications de service avant de migrer vos applications Web et sites SharePoint. La raison en est que le contenu SharePoint contient des références aux applications de service, et ces références seront rompues si le site ne sera pas en mesure de trouver l’application de service une fois restaurée.

Prochaines étapes

Dans ce chapitre, nous avons appris à migrer des sites SharePoint et des applications de service vers SharePoint Server 2019. Dans le chapitre suivant, nous apprendrons comment implémenter la haute disponibilité et la récupération d’urgence pour votre batterie de serveurs SharePoint.

CHAPITRE 17 Implémentation de la haute disponibilité et de la reprise après sinistre

SharePoint Server 2019 propose une variété d’options pour la haute disponibilité et la récupération d’urgence. Nous examinerons les options disponibles au niveau de la batterie de serveurs et de SQL Server, ce qui vous aidera à choisir l’option la plus appropriée pour votre entreprise.

Méthodes non prises en n charge

SharePoint propose diverses méthodes de réplication et de récupération qui ne sont pas prises en charge par Microsoft. Dans ce chapitre, nous couvrirons les méthodes prises en charge, mais il est important de noter les méthodes qui ne sont pas prises en charge par Microsoft afin de les éviter lors de l’implémentation de la récupération après sinistre.

Les fermes doivent avoir un temps d’aller-retour de 99% 1 ms en moyenne sur 10 minutes. Le dépassement de cette limitation de conception peut entraîner des problèmes de synchronisation des objets, notamment des échecs de travail du minuteur. Les batteries de serveurs doivent également avoir une connectivité de 1 Gbit / s entre tous les membres de la batterie de serveurs et les serveurs SQL qui servent la batterie de serveurs en lecture-écriture ou sont sous une forme de réplication synchrone avec le serveur SQL en lecture-écriture. Dans l’ensemble, la limitation pour cela signifie que chaque membre de la batterie ou SQL Server dans un mode de réplique synchrone doit se trouver à environ 186 miles ou 299,33 km.

La réplication virtuelle, qui consiste à répliquer une machine virtuelle sous-jacente (telle que l’utilisation de la réplique Hyper-V ou de produits tiers) n’est pas prise en charge car il peut y avoir des problèmes de cohérence lors de la mise en ligne de l’environnement de récupération après sinistre. Ceci est particulièrement important pour les travaux d’index de recherche et de minuteur. L’exclusion de cette règle est

Azure Site Recovery, qui prend en charge la réplication de machines virtuelles dans Azure à des fins de récupération d’urgence, car il s’agit d’un scénario que Microsoft est spécifiquement en mesure de tester.

Comme pour la réplication de machines virtuelles, la sauvegarde des machines virtuelles en ligne et leur enregistrement sur bande ou le transport de la sauvegarde via d’autres moyens n’est pas pris en charge.

Haute disponibilité SQL Server

SharePoint Server 2019 prend en charge une variété d’options pour la haute disponibilité SQL Server.

Il s’agit notamment du clustering SQL, de la mise en miroir de bases de données et des groupes de disponibilité Always On. Chacun a ses forces et ses faiblesses. Regardons chacun individuellement.

Clustering SQL

Le clustering SQL est une forme courante de haute disponibilité dont le but est d’avoir un basculement rapide lorsque le serveur SQL agissant en tant que principal échoue dans l’environnement.

SharePoint prend entièrement en charge toutes les bases de données résidant sur un cluster SQL.

Les points forts du clustering SQL incluent la possibilité d’utiliser le clustering SQL avec l’édition standard de SQL Server, ainsi que l’édition entreprise. Le clustering SQL utilise également un ensemble de disques partagés pour stocker les données, ce qui réduit les coûts de stockage. Comme SharePoint se connecte au nom virtuel du cluster, un basculement de SQL n’est qu’une interruption de service courte et mineure.

Une faiblesse importante de SQL Clustering est le sous-système de disque partagé. Si le stockage partagé devient indisponible, alors que le cluster peut rester en ligne, SharePoint sera hors ligne.

Mise en miroir de bases de données

La mise en miroir de bases de données a été introduite dans SQL Server 2005 et, bien que présente dans SQL Server 2016 et 2017, est désormais considérée comme une technologie déconseillée. Dans cet esprit, la mise en miroir de bases de données est un moyen efficace de fournir une haute disponibilité pour SharePoint. Le partenaire de basculement de la mise en miroir de bases de données doit être dans un délai de 1 ms et avoir une connectivité de 1 Gbit / s à la batterie de serveurs SharePoint ; cependant, il n’est pas nécessaire qu’il se trouve dans le même bâtiment tant que ces deux exigences sont remplies. La mise en miroir de bases de données implique la configuration de deux serveurs avec basculement automatique ou manuel. Le basculement automatique nécessite un témoin, soit un partage de fichiers, soit un témoin SQL Server (SQL Server Express peut être utilisé comme témoin). Il s’agit d’un troisième serveur, s’exécutant souvent sur un site distant ou aux côtés du partenaire de basculement.

La mise en miroir de bases de données prend également en charge trois modes de fonctionnement. Haute sécurité avec basculement automatique est une topologie dans laquelle un témoin est impliqué et les transactions sont d’abord validées auprès du partenaire de basculement avant le partenaire principal.

Haute sécurité sans basculement automatique est l’endroit où les transactions sont toujours validées en premier au partenaire de basculement, mais l’événement de basculement est un processus manuel qui nécessite l’intervention de l’administrateur.

Le dernier mode de fonctionnement, le mode haute performance, est un mode principalement destiné à répliquer une base de données sur une connexion réseau à latence élevée. Dans ce mode, il n’est pas garanti que les transactions parviennent au serveur partenaire de basculement. Pour cette raison, ce mode ne peut pas être utilisé à des fins de basculement SharePoint, mais peut convenir dans certains scénarios de récupération d’urgence.

Lors de la création de bases de données de contenu SharePoint ou de nombreuses bases de données d’application de service SharePoint, on peut spécifier un partenaire de basculement.

Cependant, toutes les bases de données ne peuvent pas être configurées via l’interface graphique pour utiliser un partenaire de basculement ou si vous devez ajouter un partenaire de basculement après coup, vous devrez définir le nom SQL Server du partenaire de basculement via PowerShell. Par exemple, notre base de données de configuration SharePoint est nommée «Configuration». Voici comment définir le partenaire de basculement via SharePoint Management Shell:

$db = Get-SPDatabase | ?{$_.Name -eq “Configuration”}

$db.FailoverServer = “SQL02”

$db.Update()

Il appartient à SharePoint de détecter qu’un basculement a eu lieu. Pour ce faire, il interroge d’abord le partenaire principal, puis le partenaire de basculement. Si le serveur principal n’est pas disponible mais que le basculement est disponible, SharePoint exploite alors le partenaire de basculement. La mise en miroir de bases de données peut également ne pas être automatique. Sans témoin, le basculement de la mise en miroir de bases de données est un processus manuel. Cela augmente considérablement les temps d’arrêt pour SharePoint pendant que l’administrateur intervient pour basculer sur les bases de données.

Enfin, avec la mise en miroir de bases de données, chaque base de données est traitée comme un objet unique à basculer. Il est possible, par exemple, d’avoir la base de données de configuration sur l’un des partenaires de basculement tandis qu’une base de données de contenu réside sur l’autre partenaire de basculement. Bien que cette configuration soit inhabituelle, le fait que les bases de données soient traitées indépendamment les unes des autres augmente l’investissement de maintenance dans l’utilisation de la mise en miroir de bases de données.

MISE EN ŒUVRE DE HAUTE DISPONIBILITÉ ET RÉCUPÉRATION EN CAS DE DÉSASTRE

Groupes de disponibilité Always On

Les groupes de disponibilité Always On sont ceux utilisés dans cet article pour fournir une haute disponibilité aux bases de données SharePoint. La configuration implique à la fois les services de cluster Microsoft et les groupes de disponibilité SQL Server Always On. Avec un serveur témoin, fourni par un serveur de fichiers ou un autre serveur SQL, les basculements sont transparents et rapides. Comme pour le clustering SQL, les clients comme SharePoint se connectent à Always On via un nom virtuel ou un nom de domaine complet.

Avec Always On Availability Groups, l’espace de stockage requis est doublé. Chaque serveur SQL doit disposer d’une quantité de stockage appropriée pour stocker les fichiers de données et les fichiers journaux pour chaque base de données SQL. Cela peut augmenter considérablement le coût de l’implémentation de SQL Server. Outre les frais de stockage, seul SQL Server Enterprise prend en charge les groupes de disponibilité Always On. Bien que SQL Server 2016 apporte des «groupes de disponibilité de base», cette fonctionnalité n’est pas appropriée pour une batterie de serveurs SharePoint car elle ne prend en charge qu’une seule base de données au sein du groupe de disponibilité de base.

Les groupes de disponibilité Always On vous permettent également d’avoir des membres de groupe de disponibilité synchrones supplémentaires. Des membres synchrones sont requis pour le basculement automatique pour SharePoint. Ces membres ont également les mêmes contraintes qu’une connexion réseau de 1 ms et 1 Gbit / s entre la batterie de serveurs SharePoint et SQL Server. SQL Server 2016 et 2017 autorisent jusqu’à huit répliques, dont trois peuvent participer à la réplication synchrone.

Les groupes de disponibilité Always On fournissent une fonction appelée « secondaire en lecture seule » où le trafic en lecture seule est dirigé du membre actif du groupe de disponibilité vers un secondaire qui ne sert pas de demandes d’écriture, mais cette fonction n’est pas prise en charge par SharePoint.

Reprise après sinistre

La mise en miroir de bases de données, les groupes de disponibilité Always On et l’envoi de journaux fournissent des options de récupération d’urgence pour les bases de données SQL Server prenant en charge la batterie de serveurs SharePoint. Dans cette section, nous considérerons que l’emplacement de récupération après sinistre est à plus de 310 miles ou 500 km du centre de données principal. Ce scénario nous empêche d’utiliser une connectivité synchrone avec le serveur SQL distant à l’emplacement de récupération après sinistre.

Mise en miroir de bases de données

La mise en miroir de bases de données pour la récupération après sinistre implique l’ajout d’un nœud en mode hautes performances à la configuration SQL Server existante. Ce membre peut coexister avec une mise en miroir de bases de données haute sécurité avec ou sans basculement automatique en place. Comme indiqué précédemment, le basculement vers un partenaire en mode haute performance est un processus manuel. Les bases de données de ce membre ne seront pas mises en ligne automatiquement.

Expédition des journaux

L’envoi de journaux est l’envoi de sauvegardes de journaux de transactions d’un serveur SQL à un autre.

Le serveur de destination SQL restaure ensuite les sauvegardes du journal des transactions dans la base de données cible. Cette méthode permet de maintenir les bases de données à jour avec des options de réplication supplémentaires disponibles en dehors de SQL Server. Par exemple, il est possible de « livrer » une sauvegarde du journal des transactions à un serveur de fichiers Windows et, à l’aide des services de fichiers distribués (DFS-R), de répliquer la sauvegarde du journal des transactions sur un serveur de fichiers Windows dans le centre de données Disaster Recovery et d’avoir le DR SQL Server restaure la sauvegarde du journal des transactions dans la base de données de destination. Cela évite à SQL Server d’être responsable de la réplication de la sauvegarde du journal des transactions. DFS-R fournit également un mécanisme de réplication plus rapide et plus fiable.

Groupes de disponibilité Always On

Les groupes de disponibilité Always On offrent la possibilité d’ajouter un partenaire distant asynchrone SQL Server à votre groupe de disponibilité. Cela permet à un local très disponible

Le groupe de disponibilité doit également disposer d’un seul serveur SQL dans un emplacement de récupération après sinistre. Contrairement au groupe de disponibilité local synchrone, le serveur SQL distant doit être défini en mode asynchrone. Ce mode a un processus de basculement manuel. C’est la méthode que nous utiliserons dans notre exemple de récupération après sinistre.

Pour ajouter SQL Server au groupe de disponibilité Always On qui sera le membre asynchrone, dupliquez le volume et la structure de répertoires pour les bases de données SQL et les fichiers journaux. Dans notre exemple, les lecteurs M: et L: seront créés à l’aide de ReFS avec des clusters de 64 Ko.

Ajoutez le rôle de clustering de basculement Windows avec la fonctionnalité .NET 3.5 Framework. À l’aide du gestionnaire de cluster de basculement, ajoutez le nouveau SQL Server au cluster de basculement existant ; nous utilisons CALSQLClus dans notre environnement. Comme le montre la figure 17-1 , ajoutez le nouveau SQL Server au cluster de basculement.

Figure 17-1. Ajout de CALDRSQL01 au cluster de basculement existant

Installez la même version, édition et niveau de correctif SQL Server que les autres serveurs SQL du cluster. Comme avec les serveurs précédents, utilisez le même compte de service que les membres synchrones du groupe de disponibilité.

Comme nous avons précédemment utilisé le compte de service géré de groupe (GMSA) LAB \ s-sql $, nous devrons le reconfigurer pour prendre en charge le serveur SQL supplémentaire et ajouter deux nouveaux noms principaux de service (SPN). Nous devons effectuer cette opération via PowerShell. Notez que nous spécifions tous les serveurs existants ainsi que le nouveau serveur de récupération après sinistre pour récupérer le mot de passe tout en spécifiant que nous ajoutons des SPN supplémentaires au compte de service.

Set-ADServiceAccount -Identity s-sql

-PrincipalsAllowedToRetrieveManagedPassword ‘calsql01