Partage via


Configurer l’authentification serveur à serveur dans SharePoint dans Microsoft 365 à partir de SharePoint Server

S’APPLIQUE À :oui-img-132013 oui-img-162016 oui-img-192019 oui-img-seÉdition d’abonnement oui-img-sopSharePoint dans Microsoft 365

Cet article fait partie d’une feuille de route de procédures de configuration pour les solutions hybrides SharePoint. Veillez à respecter une feuille de route lorsque vous effectuez les procédures décrites dans cet article.

Notes

Nous vous recommandons d’utiliser l’Assistant Configuration hybride sharePoint pour établir l’authentification de serveur à serveur entre SharePoint Server et SharePoint dans Microsoft 365. Si vous ne parvenez pas à utiliser l’Assistant Configuration hybride pour une raison quelconque, suivez les étapes décrites dans cet article pour activer l’authentification de serveur à serveur.

Configurer l’authentification de serveur à serveur

Cet article donne des conseils pour le processus de déploiement d'environnement hybride SharePoint qui intègre SharePoint Server et SharePoint dans Microsoft 365.

Conseil

Pour obtenir le résultat le plus fiable, exécutez les procédures dans l’ordre indiqué dans cet article.

Vérifier les paramètres de l’application web

Dans une solution hybride SharePoint, les utilisateurs fédérés peuvent envoyer des demandes à SharePoint dans Microsoft 365 à partir de n'importe quelle application web SharePoint Server configurée pour utiliser l'authentification Windows intégrée avec NTLM.

Par exemple, vous devez vous assurer que les sites Centre de recherche sur site que vous voulez utiliser dans votre solution sont configurés pour utiliser l'authentification Windows intégrée avec NTLM. Si ce n'est pas le cas, vous devez reconfigurer l'application web pour utiliser l'authentification Windows avec NTLM ou utiliser un site Centre de recherche sur une application web qui répond aux exigences. Vous devez également vous assurer que les utilisateurs qui s’attendent à ce que les résultats de la recherche soient retournés à partir de SharePoint dans Microsoft 365 sont des utilisateurs fédérés.

Pour vérifier qu’une application web répond à la demande

  1. Vérifiez que le compte d’utilisateur qui effectue cette procédure est membre du groupe SharePoint Administrateurs de batterie de serveurs.

  2. Dans Administration centrale, sélectionnez Gestion des applications, puis Gérer les applications web.

  3. Dans la colonne Nom, sélectionnez l'application web à vérifier, puis sélectionnez Fournisseurs d'authentification dans le ruban.

  4. Dans la boîte de dialogue Fournisseurs d'authentification dans la colonne Zone, sélectionnez la zone à laquelle le site Centre de recherche est associé.

  5. Dans la boîte de dialogue Modifier l'authentification, vérifiez que l'authentification Windows intégrée et NTLM sont sélectionnés, comme le montre la figure suivante.

    Paramètre de type d’authentification pour une application web.

Configurer OAuth sur HTTP (si nécessaire)

Par défaut, OAuth dans SharePoint Server requiert le protocole HTTPS. Si vous avez configuré votre application web principale de sorte qu'elle utilise le protocole HTTP au lieu du protocole SSL, vous devez activer le protocole OAuth sur HTTP sur chaque serveur web dans votre batterie de serveurs SharePoint Server.

Notes

Si vous avez configuré votre application web principale pour utiliser le protocole SSL, cette étape n’est pas requise.

Pour activer OAuth sur HTTP, exécutez les commandes suivantes avec un compte d'administrateur de batterie à partir de l'invite de commandes SharePoint 2016 Management Shell sur chaque serveur web de votre batterie SharePoint Server.

$serviceConfig = Get-SPSecurityTokenServiceConfig
$serviceConfig.AllowOAuthOverHttp = $true
$serviceConfig.Update()

Si vous avez activé OAuth sur HTTP à des fins de test, mais que vous voulez reconfigurer votre environnement pour utiliser SSL, vous pouvez désactiver OAuth sur HTTP en exécutant les commandes suivantes avec un compte d'administrateur de batterie à partir de l'invite de commandes SharePoint 2016 Management Shell sur chaque serveur web de votre batterie SharePoint Server.

$serviceConfig = Get-SPSecurityTokenServiceConfig
$serviceConfig.AllowOAuthOverHttp = $false
$serviceConfig.Update()

Configurer l’authentification de serveur à serveur entre SharePoint Server sur site et SharePoint dans Microsoft 365

Cette section vous aide à configurer l’authentification de serveur à serveur parmi :

  • SharePoint Server

  • SharePoint dans Microsoft 365

  • Identifiant Microsoft Entra

Lorsque vous configurez l’authentification de serveur à serveur pour les environnements hybrides, vous créez une relation d’approbation entre votre batterie sharePoint locale et votre locataireSharePoint dans Microsoft 365, qui utilise l’ID Microsoft Entra comme service de signature de jeton approuvé. En ajoutant les modules et les composants logiciels enfichables PowerShell requis, ce processus peut s'effectuer dans une seule fenêtre PowerShell sur un serveur web SharePoint sur site.

Conseil

Vous devez conserver un enregistrement de vos étapes, des applets de commande PowerShell que vous exécutez et des erreurs que vous pouvez rencontrer. Vous devez capturer tout le contenu de la mémoire tampon PowerShell lorsque vous avez terminé et avant de fermer la fenêtre. Cela vous donnera un historique des étapes que vous avez effectuées, ce qui sera utile si vous devez résoudre les problèmes ou expliquer le processus à d’autres personnes. Cela peut également être utile pour actualiser votre mémoire si la configuration se produit par étapes.

Voici une vue d'ensemble des procédures que vous devez exécuter dans cette section :

  1. Installer les outils de gestion de service en ligne sur un serveur web dans votre batterie de serveurs SharePoint Server.

  2. Configurer l’authentification de serveur à serveur.

    • Définir les variables à utiliser dans les étapes ultérieures.

    • Chargez le certificat STS SharePoint Server intégré dans SharePoint dans Microsoft 365.

    • Ajouter un nom de principal du service (SPN) à Azure.

    • Inscrivez l'ID d'objet principal de l'application SharePoint dans Microsoft 365 avec SharePoint Server sur site.

    • Configurez un domaine d'authentification commun entre votre batterie de serveurs SharePoint Server sur site et SharePoint dans Microsoft 365.

    • Configurez un proxy d’application Microsoft Entra localement.

Installer les outils de gestion de service en ligne et configurer la fenêtre Windows PowerShell

Pour continuer, vous devez installer ces outils dans un serveur web SharePoint Server sur site :

  • Microsoft Graph PowerShell

  • SharePoint dans Microsoft 365 Management Shell

Cela s’effectue plus facilement sur un serveur web de votre batterie de serveurs SharePoint, car il est plus facile de charger le composant logiciel enfichable Microsoft.SharePoint.PowerShell sur les serveurs web que sur les serveurs sur 2 2000.

L’authentification auprès de SharePoint Server, SharePoint dans Microsoft 365 et l’ID Microsoft Entra nécessite différents comptes d’utilisateur. Pour plus d'informations sur la façon de déterminer les comptes à utiliser, voir Comptes nécessaires pour la configuration et les tests d'un environnement hybride.

Notes

Pour faciliter la procédure décrite dans cette section, nous allons ouvrir une fenêtre d’invite de commandes PowerShell sur un serveur web SharePoint Server et ajouter les modules et les composants logiciels enfichables qui vous permettent de vous connecter à SharePoint Server, SharePoint dans Microsoft 365 et à l’ID Microsoft Entra. (Nous vous fournirons les étapes détaillées concernant cette procédure plus loin dans cet article.) Nous laisserons ensuite cette fenêtre ouverte, car elle nous servira pour les étapes PowerShell restantes de cet article.

Pour installer les outils de gestion de service en ligne et configurer la fenêtre PowerShell :

  1. Installer la dernière version de Microsoft Graph PowerShell

  2. Installez SharePoint Online dans Microsoft 365 Management Shell :

    SharePoint dans Microsoft 365 Management Shell (version 64 bits)

    Pour plus d'informations, voir Présentation de SharePoint dans Microsoft 365 Management Shell.

  3. Ouvrez une fenêtre PowerShell.

  4. Pour être certain de ne pas remplir la mémoire tampon et de ne perdre aucun élément de votre historique des commandes, augmentez la taille de la mémoire tampon de la fenêtre PowerShell :

  5. Sélectionnez le coin supérieur gauche de la fenêtre PowerShell, puis Propriétés.

  6. Dans la fenêtre Propriétés de PowerShell, sélectionnez l'onglet Disposition.

  7. Sous Taille de la mémoire tampon écran, définissez le champ Hauteur sur 9999, puis sélectionnez OK.

  8. Cette étape permet de charger les modules téléchargés pour que vous puissiez les utiliser dans votre sessionPowerShell. Copiez les commandes suivantes dans votre session PowerShell et appuyez sur Entrée.

    Add-PSSnapin Microsoft.SharePoint.PowerShell
    Import-Module Microsoft.PowerShell.Utility
    Import-Module Microsoft.Graph
    

    Si vous devez à nouveau exécuter l'une de ces étapes de configuration ultérieurement, n'oubliez pas d'exécuter à nouveau ces commandes pour charger les modules et les composants logiciels enfichables requis dans PowerShell.

  9. Entrez les commandes suivantes pour vous connecter à SharePoint dans Microsoft 365 à partir de l’invite de commandes PowerShell :

       Connect-MgGraph -Scopes "Group.ReadWrite.All","RoleManagement.ReadWrite.Directory","Organization.ReadWrite.All"
    

    Vous êtes invité à vous connecter. Vous devez vous connecter à l’aide d’un compte d’administrateur général Microsoft 365. Vous pouvez explorer d’autres façons de vous connecter à Microsoft Graph.

    Laissez la fenêtre PowerShell ouverte jusqu'à ce que vous ayez effectué toutes les étapes de cet article. Vous en aurez besoin pour nombre de procédures des sections suivantes.

Configurer l’authentification de serveur à serveur (S2S)

Maintenant que vous avez installé les outils pour vous permettre d’administrer à distance l’ID Microsoft Entra et SharePoint dans Microsoft 365, vous êtes prêt à configurer l’authentification de serveur à serveur.

À propos des variables que vous allez créer

Cette section décrit les variables que vous allez définir dans la procédure qui suit. Ces variables contiennent d'importantes informations utilisées dans la plupart des étapes de configuration restantes.

Variable Commentaires
$spcn Nom de domaine racine de votre domaine public. Cette valeur ne doit pas être sous la forme d’une URL ; il doit s’agir du nom de domaine uniquement, sans protocole.
Par exemple, adventureworks.com.
$spsite URL interne de votre application web principale sur site, telle que http://sharepoint ou https://sharepoint.adventureworks.com. Cette valeur est une URL complète utilisant le protocole adéquat ( http: // ou https:// ).
Il s’agit de l’URL interne de l’application web que vous utilisez pour les fonctionnalités hybrides.
Par exemple, http://sharepoint ou https://sharepoint.adventureworks.com.
$site Objet de votre application web principale sur site. La commande qui remplit cette variable obtient l'objet du site spécifié dans la variable $spsite.
Cette variable est remplie automatiquement.
$spoappid L’ID du principal de l’application SharePoint dans Microsoft 365 est toujours 00000003-0000-0ff1-ce00-00000000000000. Cette valeur générique identifie SharePoint dans les objets Microsoft 365 dans une organisation Microsoft 365.
$spocontextID ID de contexte (ObjectID) de votre client SharePoint dans Microsoft 365. Cette valeur est un GUID unique qui identifie votre client SharePoint dans Microsoft 365.
Cette valeur est détectée automatiquement lors de l’exécution de la commande pour définir la variable.
$metadataEndpoint URL utilisée par votre proxy d’ID Microsoft Entra pour se connecter à votre location Microsoft Entra.
Vous n’avez pas besoin d’entrer une valeur pour cette variable.

Étape 1 : Définir des variables

Maintenant que vous avez identifié les variables à définir, utilisez ces instructions pour les définir. Le pré-remplissage des variables les plus fréquemment utilisées devrait vous aider à effectuer les étapes restantes plus vite. Ces variables restent remplies tant que vous ne fermez pas la session PowerShell. Veillez à fournir des informations précises partout où vous voyez des crochets (<>) et supprimez toujours les crochets avant d’exécuter la commande. Ne modifiez pas le code en dehors des crochets.

Notes

Si vous devez à nouveau effectuer l'une de ces étapes de configuration ultérieurement, vous devez commencer par exécuter les commandes PowerShell suivantes dans cette étape pour re-remplir les variables importantes.

Copiez les déclarations de variable suivantes et collez-les dans un éditeur de texte tel que le Bloc-notes. Définissez les valeurs d'entrée propres à votre organisation. À partir de l'invite de commandes PowerShell configurée à l'aide des outils de gestion de service en ligne, exécutez les commandes.

$spcn="*.<public_root_domain_name>.com"
$spsite=Get-Spsite <principal_web_application_URL>
$site=Get-Spsite $spsite
$spoappid="00000003-0000-0ff1-ce00-000000000000"
$spocontextID = (Get-MgOrganization).Id
$metadataEndpoint = "https://accounts.accesscontrol.windows.net/" + $spocontextID + "/metadata/json/1"

Après avoir rempli ces variables, vous pouvez afficher leurs valeurs en saisissant le nom de la variable dans la fenêtre PowerShell. Par exemple, la saisie $metadataEndpoint renvoie une valeur similaire à la suivante :

https://accounts.accesscontrol.windows.net/00fceb75-246c-4ac4-a0ad-7124xxxxxxxx/metadata/json/1

Étape 2 : Charger le certificat STS vers SharePoint dans Microsoft 365

Dans cette étape, vous chargez le certificat STS de votre batterie de serveurs SharePoint Server vers votre client SharePoint dans Microsoft 365, ce qui permet à SharePoint Server et à SharePoint dans Microsoft 365 de se connecter et d'utiliser les applications de service de l'un et de l'autre.

Architecture impliquée quand un certificat STS est chargé vers SharePoint dans Microsoft 365

Les commandes de cette étape ajoutent le certificat STS local (clé publique uniquement) à l’objet principal SharePoint dans Microsoft 365 de votre organisation Microsoft 365.

À partir de l'invite de commandes PowerShell, saisissez les commandes suivantes :

$Cert = (Get-SPSecurityTokenServiceConfig).LocalLoginProvider.SigningCertificate

$principal = Get-MgServicePrincipal -Filter "AppId eq '$spoappid’” -Property "Id,DisplayName,KeyCredentials,AppId"

$existingCerts = $principal.KeyCredentials

$keyCredentials = @(@{ Type = "AsymmetricX509Cert"; Usage = "Verify"; Key = $Cert.RawData; KeyId = New-Guid; StartDateTime = $Cert.NotBefore; EndDateTime = $Cert.NotAfter; })

$noUpdate = $false

foreach($existingCert in $existingCerts) {

    if ([string]$existingCert.Key -eq [string]$Cert.RawData) {

        $noUpdate = $true

        break

    }

    else {

        $existingCert.Key = $null

        $keyCredentials += $existingCert

    }
}

if (-Not $noUpdate) {

     Update-MgServicePrincipal -ServicePrincipalId $principal.Id -KeyCredentials $keyCredentials

}

Étape 3 : Ajouter un SPN pour votre nom de domaine public à l’ID Microsoft Entra

Dans cette étape, vous ajoutez un nom de principal de service (SPN) à votre locataire Microsoft Entra. L’objet principal SharePoint dans Microsoft 365 et l’espace de noms DNS public de votre entreprise forment le SPN.

Tout comme la fonction SPN dans Active Directory, la création de ce SPN inscrit un objet dans l’ID Microsoft Entra qui est utilisé pour prendre en charge l’authentification mutuelle entre SharePoint Server et SharePoint dans Microsoft 365. La syntaxe de base du SPN est la suivante :

<type de> service/<nom de l’instance>

Où :

  • <le type de> service est l’objet principal SharePoint dans Microsoft 365, qui est le même pour tous les locataires SharePoint dans Microsoft 365.

  • <nom d'instance> correspond à l'URL de l'espace de noms de domaine DNS public de votre entreprise, qui est toujours exprimé sous la forme d'un caractère générique (même si le certificat SSL de canal sécurisé est un certificat SAN).

Voici un exemple :

00000003-0000-0ff1-ce00-000000000000/*.<public domain name>.com

Si le nom commun de votre certificat est sharepoint.adventureworks.com, la syntaxe du SPN ressemble à ceci :

00000003-0000-0ff1-ce00-000000000000/*.adventureworks.com

L’utilisation d’une valeur générique permet à SharePoint dans Microsoft 365 de valider les connexions avec n’importe quel hôte dans ce domaine. Cela est utile si vous avez besoin de changer le nom d’hôte de votre point de terminaison externe (si votre topologie en inclut un) ou de votre application web SharePoint Server dans le futur.

Pour ajouter le SPN à l’ID Microsoft Entra, entrez les commandes suivantes dans l’invite de commandes Microsoft Graph PowerShell.

$msp = Get-MgServicePrincipal -Filter "AppId eq '$spoappid'"
$params =@{
  "servicePrincipalNames"="$spoappid/$spcn"
}
Update-MgServicePrincipal -ServicePrincipalId $msp.Id -BodyParameter $params

Pour vérifier que le SPN a été défini, entrez les commandes suivantes dans l’invite de commandes Microsoft Graph PowerShell.

$msp = Get-MgServicePrincipal -Filter "AppId eq '$spoappid'"
$spns = $msp.ServicePrincipalNames
$spns

Vous devez voir la liste actuelle des SPN pour SharePoint dans Microsoft 365 dans votre organisation Microsoft 365, et l’un des SPN doit inclure votre nom de domaine racine public, précédé de l’ID principal de l’application SharePoint dans Microsoft 365. Il s’agit d’une inscription générique qui doit ressembler à l’exemple suivant :

00000003-0000-0ff1-ce00-000000000000/*.<public domain name>.com

Il doit s’agir de l’unique SPN de la liste incluant votre nom de domaine racine public.

Étape 4 : Inscrivez l'ID d'objet principal de l'application SharePoint dans Microsoft 365 avec SharePoint Server

Cette étape permet d'inscrire l'ID d'objet principal de l'application SharePoint dans Microsoft 365 auprès du service de gestion de l'application SharePoint dans Microsoft 365 sur site, qui permet à SharePoint Server de s'authentifier sur SharePoint dans Microsoft 365 à l'aide d'OAuth.

À partir de l'invite de commandes PowerShell, saisissez les commandes suivantes :

$spoappprincipalID  = (Get-MgServicePrincipal -Filter "AppId eq '$spoappid'").Id
$sponameidentifier = "$spoappprincipalID@$spocontextID"
$appPrincipal = Register-SPAppPrincipal -site $site.rootweb -nameIdentifier $sponameidentifier -displayName "SharePoint"

Pour valider cette étape, saisissez la variable $appPrincipal à partir de l'invite de commandes PowerShell.

$appPrincipal | fl

La sortie attendue est une description du principal d'application inscrit avec le nom SharePoint Online, semblable à ceci :

Principal d’application inscrit pour SharePoint dans Microsoft 365

Étape 5 : Définir le domaine d’authentification SharePoint dans Microsoft 365

Cette étape définit le domaine d’authentification de votre batterie SharePoint Server sur l’ID de contexte de l’organisation Microsoft 365.

À partir de l’invite de commandes PowerShell, entrez la commande suivante :

Set-SPAuthenticationRealm -realm $spocontextID

Pour valider cette étape, entrez les commandes suivantes à partir de l’invite de commandes PowerShell :

$spocontextID
Get-SPAuthenticationRealm

La sortie de chacune de ces commandes est le GUID qui représente l'ID de contexte du client SharePoint dans Microsoft 365. Ces GUID doivent être identiques.

Importante

Si vous avez configuré des scripts d'installation de batterie de serveurs qui spécifient la valeur de domaine d'authentification de batterie de serveurs, vous devez mettre à jour les scripts d'installation avec cette nouvelle valeur avant de les exécuter une nouvelle fois. > Pour plus d’informations sur la configuration requise pour les valeurs de domaine dans les scripts d’installation de batterie de serveurs, voir Planifier l’authentification de serveur à serveur dans SharePoint Server. Cette batterie de serveurs SharePoint étant désormais configurée pour participer à la configuration hybride, la valeur de domaine d'authentification de batterie SharePoint doit toujours correspondre à l'identificateur de contexte de client. Si vous modifiez cette valeur, la batterie ne participera plus à la fonctionnalité hybride.

Étape 6 : Configurer un proxy local pour l’ID Microsoft Entra

Dans cette étape, vous créez un service proxy d’ID Microsoft Entra dans la batterie de serveurs SharePoint Server. Cela active l’ID Microsoft Entra en tant qu’émetteur de jeton approuvé que SharePoint Server utilise pour signer et authentifier des jetons de revendications à partir de SharePoint dans Microsoft 365.

Dans l’invite de commandes PowerShell, entrez les commandes suivantes.

New-SPAzureAccessControlServiceApplicationProxy -Name "ACS" -MetadataServiceEndpointUri $metadataEndpoint -DefaultProxyGroup
New-SPTrustedSecurityTokenIssuer -MetadataEndpoint $metadataEndpoint -IsTrustBroker:$true -Name "ACS"

Pour valider la commande New-SPAzureAccessControlServiceApplicationProxy:

  1. Parcourez le site web Administration centrale de SharePoint 2016 et sélectionnez Sécurité>Sécurité générale>Gérer la relation d’approbation.

  2. Vérifiez qu’il existe une entrée dont le nom commence par ACS, puis entrez Consommateur de services approuvés.

    Pour valider cette étape, à partir de l’invite de commandes PowerShell, saisissez la commande suivante.

    Get-SPTrustedSecurityTokenIssuer
    

    La sortie attendue est une description de l'émetteur de jeton approuvé de la batterie où la valeur de la propriété RegisteredIssuerName est la suivante :

    00000001-0000-0000-c000-000000000000@<context ID>

    Où :

    • <l’ID de> contexte est l’ID de contexte de votre location SharePoint dans Microsoft 365, qui est la valeur de la variable $spocontextID.

À compter d’octobre 2021, une étape supplémentaire est nécessaire pour ajuster une configuration sharePoint hybride existante afin qu’elle fonctionne avec et s’authentifie à l’aide du nouveau moteur de recherche Microsoft 365.

Le script doit être exécuté sur un serveur sur lequel SharePoint local est installé (2013, 2016 ou 2019). Le script tente d’installer les dépendances de module requises (MSOnline, AzureAD) sur le serveur sur lequel il est exécuté.

  1. Téléchargez le script de configuration.

  2. À partir du répertoire dans lequel le script a été téléchargé, exécutez le script à l’aide du compte Administrateur de batterie de serveurs SharePoint local, à l’aide de la commande suivante :

    Update-FederatedHybridSearchForM365.ps1 -HybridWebApp YourHybridWebApplication -Force
    

    Pour plus d’informations sur les valeurs des paramètres, exécutez la commande suivante :

    Get-Help .\Update-FederatedHybridSearchForM365.ps1
    
  3. Lorsque vous y êtes invité, connectez-vous à l’aide du compte Administrateur général Microsoft 365.

  4. Attendez la fin de l’exécution du script ; en cas de problème, contactez le support Microsoft.

  5. Après l’exécution du script, les utilisateurs ne voient aucune modification lorsque cette modification est implémentée.

Étape 8 (requise uniquement pour SharePoint Server 2013) : Accorder l’autorisation New App Principal QueryAsUserIgnoreAppPrincipal

SharePoint Server 2013 a besoin d’une contrainte masquée dans chaque requête fédérée. Le proxy inverse retourne les documents indexés dans le site proxy inverse lui-même, et non le site de recherche interne local comme prévu. Pour éviter cela, vous devez exécuter les étapes suivantes dans votre site d’administration SharePoint Server 2013 :

  1. Accédez à <CentralAdminURL>/_layouts/appinv.aspx et recherchez c3959f3a-5ad4-4d2b-b1f0-bc70f9a5d0a1, où vous devriez trouver la compétence bot de recherche fédérée du Groenland.

  2. S’il existe des éléments dans le champ Domaine d’application, conservez-les et s’il est vide, utilisez localhost.

  3. Dans l’URL de redirection, utilisez https://localhost.

  4. Dans le champ XML de demande d’autorisation, collez l’extrait XML suivant :

    <AppPermissionRequests>
    <AppPermissionRequest Scope="http://sharepoint/search" Right="QueryAsUserIgnoreAppPrincipal" />
    </AppPermissionRequests>
    
  5. La page de configuration doit ressembler à la capture d’écran suivante. Pour terminer, sélectionnez le bouton Créer.

Accorder l’autorisation QueryAsUserIgnoreAppPrincipal à l’application

Validation et étapes suivantes

Après avoir terminé les tâches de cette rubrique et ses étapes de validation, vérifiez votre SSO et la configuration de la synchronisation d’annuaires.

Pour pouvoir disposer d'un historique des étapes effectuées, vous devez capturer l'intégralité du contenu de la mémoire tampon PowerShell dans un fichier. Il s'agit d'une étape cruciale si vous devez référencer votre historique de configuration à des fins de résolution des problèmes ou pour toute autre raison. Vous pourrez également reprendre là où vous en étiez si la configuration s'étend sur plusieurs jours ou implique plusieurs personnes.

Une fois que vous avez terminé et validé les tâches de configuration décrites dans cet article, poursuivez avec votre feuille de route de configuration.

Voir aussi

Environnement hybride pour SharePoint Server

Installer et configurer SharePoint Server hybride