Résoudre les problèmes liés au runtime d’intégration auto-hébergé (SHIR) Microsoft Purview

Cet article explore les méthodes de résolution des problèmes courantes pour le runtime d’intégration auto-hébergé (SHIR) dans Microsoft Purview.

Le runtime d’intégration auto-hébergé (SHIR) est également utilisé par Azure Data Factory et Azure Synapse Analytics. Bien que la plupart des étapes de résolution des problèmes se chevauchent, suivez ce guide pour résoudre les problèmes liés à votre solution SHIR pour ces produits :

• Résoudre les problèmes liés à SHIR pour Azure Data Factory et Azure Synapse Analytics

Collecter les journaux du runtime d’intégration auto-hébergé SHIR spécifique à Microsoft Purview

Pour les analyses Microsoft Purview ayant échoué qui s’exécutent sur un runtime d’intégration auto-hébergé, le service prend en charge l’affichage et le chargement des journaux d’erreurs à partir du observateur d'événements Windows.

Vous pouvez rechercher les erreurs que vous voyez dans le guide d’erreur ci-dessous. Pour obtenir du support et des conseils de résolution des problèmes liés à SHIR, vous devrez peut-être générer un ID de rapport d’erreurs et contacter le support Microsoft.

Pour générer l’ID de rapport d’erreurs pour Support Microsoft, suivez ces instructions :

1. Avant de démarrer une analyse dans le portail de gouvernance Microsoft Purview :

   1. Accédez à l’ordinateur sur lequel le runtime d’intégration auto-hébergé est installé et ouvrez le observateur d'événements Windows.
   2. Effacez les journaux de l’observateur d’événements Windows dans la section Integration Runtime. Cliquez avec le bouton droit sur les journaux et sélectionnez l’option Effacer les journaux.
   3. Revenez au portail de gouvernance Microsoft Purview et démarrez l’analyse.

2. Une fois que l’analyse a indiqué status Échec, revenez à la machine virtuelle SHIR ou à l’ordinateur et actualisez l’observateur d’événements dans la section Integration Runtime.

3. Les journaux d’activité s’affichent pour l’exécution de l’analyse ayant échoué.

4. Pour obtenir de l’aide supplémentaire de Microsoft, sélectionnez Envoyer les journaux.

   La fenêtre Partager les journaux du runtime d’intégration auto-hébergé (SHIR) avec Microsoft s’ouvre.

   

5. Lorsque les journaux sont chargés, conservez un enregistrement de l’ID de rapport à utiliser si vous contactez le support Microsoft.

   

Erreur ou échec général du runtime d’intégration auto-hébergé

Il existe de nombreuses erreurs, avertissements et problèmes courants entre le SHIR Purview, Azure Data Factory ou Azure Synapse SHIR. Le guide ci-dessous couvre la plupart des problèmes les plus courants.

Erreur ou échec général du runtime d’intégration auto-hébergé

Problème de mémoire insuffisante

Symptômes

Une erreur OutOfMemoryException (OOM) se produit lorsque vous essayez d’exécuter une analyse avec un runtime d’intégration auto-hébergé.

Cause

Une nouvelle analyse peut générer une erreur OOM si l’ordinateur IR subit une utilisation momentanée élevée de la mémoire. Le problème peut être dû à un volume important d’activités simultanées ou à une faible quantité de mémoire, et l’erreur est due à la conception.

Solution

Vérifiez l’utilisation des ressources pour vérifier si un autre logiciel est en cours d’exécution en même temps, et vérifiez que votre machine SHIR répond aux configurations recommandées.

Le runtime d’intégration auto-hébergé n’a pas pu charger le fichier ou l’assembly

Symptômes

Vous obtenez le message d’erreur suivant :

« Impossible de charger le fichier ou l’assembly 'XXXXXXXXXXXXXXXXXX, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' ou l’une de ses dépendances. Le fichier spécifié est introuvable. ID d’activité : 92693b45-b4bf-4fc8-89da-2d3dc56f27c3 »

Voici un message d’erreur plus spécifique :

« Impossible de charger le fichier ou l’assembly 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' ou l’une de ses dépendances. Le fichier spécifié est introuvable. ID d’activité : 92693b45-b4bf-4fc8-89da-2d3dc56f27c3 »

Cause

Dans Process Monitor, vous pouvez afficher le résultat suivant :

Conseil

Dans Process Monitor, vous pouvez définir des filtres comme illustré dans la capture d’écran suivante. Le message d’erreur précédent indique que la DLL System.ValueTuple ne se trouve pas dans le dossier Global Assembly Cache (GAC) associé, dans le dossier C :\Program Files\Microsoft Integration Runtime\4.0\Gateway ou dans le dossier C :\Program Files\Microsoft Integration Runtime\4.0\Shared. Fondamentalement, le processus charge la DLL d’abord à partir du dossier GAC , puis à partir du dossier Partagé et enfin à partir du dossier Passerelle . Par conséquent, vous pouvez charger la DLL à partir de n’importe quel chemin d’accès utile.

Solution

Vous trouverez le fichier System.ValueTuple.dll dans le dossier C :\Program Files\Microsoft Integration Runtime\4.0\Gateway\DataScan. Pour résoudre le problème, copiez le fichier System.ValueTuple.dll dans le dossier C :\Program Files\Microsoft Integration Runtime\4.0\Gateway.

Vous pouvez utiliser la même méthode pour résoudre d’autres problèmes de fichier ou d’assembly manquants.

Plus d’informations

La raison pour laquelle vous voyez le System.ValueTuple.dll sous %windir%\Microsoft.NET\assembly et %windir%\assembly est qu’il s’agit d’un comportement .NET.

Dans l’erreur suivante, vous pouvez clairement voir que l’assembly System.ValueTuple est manquant. Ce problème se produit lorsque l’application tente d’case activée l’assembly System.ValueTuple.dll.

« <LogProperties><ErrorInfo>[{"Code » :0,"Message » :"The type initializer for 'Npgsql.PoolManager' a levé une exception. »,"EventType » :0,"Category » :5,"Data » :{},"MsgId » :null,"ExceptionType » :"System.TypeInitializationException »,"Source » :"Npgsql »,"StackTrace » :" »,"InnerEventInfos » :[{"Code » :0,"Message » :"Impossible de charger le fichier ou l’assembly 'System.ValueTuple, Version=4.0.2.0, Culture=neutre, PublicKeyToken=XXXXXXXXX' ou l’une de ses dépendances. Le système ne trouve pas le fichier spécifié. »,"EventType » :0,"Category » :5,"Data » :{},"MsgId » :null,"ExceptionType » :"System.IO.FileNotFoundException »,"Source » :"Npgsql »,"StackTrace » :" »,"InnerEventInfos » :[]}}]]</ErrorInfo></LogProperties> »

Pour plus d’informations sur GAC, consultez Global Assembly Cache.

Clé d’authentification manquante du runtime d’intégration auto-hébergé

Symptômes

Le runtime d’intégration auto-hébergé passe soudainement hors connexion sans clé d’authentification, et le journal des événements affiche le message d’erreur suivant :

« La clé d’authentification n’est pas encore affectée »

Cause

Le nœud du runtime d’intégration auto-hébergé ou le runtime d’intégration auto-hébergé logique dans le portail Microsoft Purview a été supprimé ou une désinstallation propre a été effectuée.

Solution

Si aucune des causes précédentes ne s’applique, vous pouvez accéder au dossier %programdata%\Microsoft\Data Transfer\DataManagementGateway pour voir si le fichier Configurations a été supprimé. S’il a été supprimé, suivez les instructions de l’article Netwrix Détecter qui a supprimé un fichier de vos serveurs de fichiers Windows.

Impossible de choisir le certificat, car la clé privée est manquante

Symptômes

• Vous avez importé un fichier PFX dans le magasin de certificats.
• Lorsque vous avez sélectionné le certificat via l’interface utilisateur de Configuration Manager ir, vous avez reçu le message d’erreur suivant :

« Échec de la modification du mode de chiffrement de la communication intranet. Il est probable que le certificat «<nom> du certificat » n’ait pas de clé privée capable d’échanger des clés ou que le processus ne dispose pas de droits d’accès pour la clé privée. Consultez l’exception interne pour plus de détails. »

Cause

• Le compte d’utilisateur a un niveau de privilège faible et ne peut pas accéder à la clé privée.
• Le certificat a été généré en tant que signature, mais pas en tant qu’échange de clés.

Solution

• Pour utiliser l’interface utilisateur, utilisez un compte avec les privilèges appropriés pour accéder à la clé privée.
• Importez le certificat en exécutant la commande suivante :

certutil -importpfx FILENAME.pfx AT_KEYEXCHANGE

Message d’erreur UserErrorJreNotFound lorsque vous exécutez une analyse

Symptômes

Lorsque vous essayez d’analyser une source de données à l’aide d’un outil ou d’un programme Java (par exemple, des fichiers au format Parquet), vous recevez un message d’erreur semblable au suivant :

ErrorCode=UserErrorJreNotFound,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Java Runtime Environment is not found. Accédez à http://go.microsoft.com/fwlink/?LinkId=808605 pour télécharger et installer sur votre ordinateur de nœud Integration Runtime (auto-hébergé). Remarque Integration Runtime 64 bits nécessite JRE 64 bits et 32 bits Integration Runtime nécessite JRE 32 bits.,Source=Microsoft.DataTransfer.Common,'Type=System.DllNotFoundException,Message=Impossible de charger la DLL 'jvm.dll' : Le module spécifié est introuvable. (Exception de HRESULT : 0x8007007E),Source=Microsoft.DataTransfer.Richfile.HiveOrcBridge

Cause

Ce problème se produit pour l’une des raisons suivantes :

• Java Runtime Environment (JRE) n’est pas installé correctement sur votre serveur Integration Runtime.

• Votre serveur Integration Runtime ne dispose pas de la dépendance requise pour JRE.

Par défaut, Integration Runtime résout le chemin D’accès JRE à l’aide d’entrées de Registre. Ces entrées doivent être définies automatiquement lors de l’installation de JRE.

Solution

Suivez attentivement les étapes de cette section. Des problèmes graves peuvent se produire si vous modifiez le Registre de façon incorrecte. Avant de modifier le Registre, sauvegardez-le pour restauration en cas de problèmes.

Pour résoudre ce problème, procédez comme suit pour vérifier la status de l’installation JRE :

1. Assurez-vous que Integration Runtime (Diahost.exe) et JRE sont installés sur la même plateforme. Vérifiez les conditions suivantes :

   • JRE 64 bits pour les Integration Runtime ADF 64 bits doivent être installés dans le dossier :C:\Program Files\Java\

     Remarque

     Le dossier n’est pas C:\Program Files (x86)\Java\

   • JRE 11 est compatible pour l’analyse. JRE 8 est également compatible, mais les versions antérieures à JRE 8 n’ont pas été validées pour cette utilisation.

2. Vérifiez les paramètres appropriés dans le Registre. Pour cela, procédez comme suit :

3. Dans le menu Exécuter , tapez Regedit, puis appuyez sur Entrée.

4. Dans le volet de navigation, recherchez la sous-clé suivante :

   HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment.

   Dans le volet Détails , il doit y avoir une entrée Version actuelle qui affiche la version JRE (par exemple, 1.8).

   

5. Dans le volet de navigation, recherchez une sous-clé qui correspond exactement à la version (par exemple 1.8) sous le dossier JRE. Dans le volet d’informations, il doit y avoir une entrée JavaHome . La valeur de cette entrée est le chemin d’installation de JRE.

   

6. Recherchez le dossier bin\server dans le chemin d’accès suivant :

   C:\Program Files\Java\jre1.xx.xxx

   

7. Vérifiez si ce dossier contient un fichier jvm.dll. Si ce n’est pas le cas, case activée pour le fichier dans le bin\client dossier .

   

Remarque

• Si l’une de ces configurations n’est pas décrite dans ces étapes, utilisez le programme d’installation windows JRE pour résoudre les problèmes.
• Si toutes les configurations de ces étapes sont correctes comme décrit, il se peut qu’il manque une bibliothèque runtime VC++ dans le système. Vous pouvez résoudre ce problème en installant le package redistributable VC++ 2010.

Configuration du runtime d’intégration auto-hébergé

Erreur d’inscription au runtime d’intégration

Symptômes

Vous pouvez parfois exécuter un runtime d’intégration auto-hébergé dans un autre compte pour l’une des raisons suivantes :

• La stratégie d’entreprise interdit le compte de service.
• Une certaine authentification est requise.

Après avoir modifié le compte de service dans le volet de service, vous pouvez constater que le runtime d’intégration cesse de fonctionner et que vous obtenez le message d’erreur suivant :

« Le nœud Integration Runtime (auto-hébergé) a rencontré une erreur lors de l’inscription. Impossible de se connecter au service hôte Integration Runtime (auto-hébergé). »

Cause

De nombreuses ressources sont accordées uniquement au compte de service. Lorsque vous remplacez le compte de service par un autre compte, les autorisations de toutes les ressources dépendantes restent inchangées.

Solution

Accédez au journal des événements du runtime d’intégration pour case activée l’erreur.

• Si l’erreur dans le journal des événements est « UnauthorizedAccessException », procédez comme suit :

  1. Vérifiez le compte de service d’ouverture de session DIAHostService dans le panneau de service Windows.

     

  2. Vérifiez si le compte de service d’ouverture de session dispose d’autorisations en lecture/écriture pour le dossier %programdata%\Microsoft\DataTransfer\DataManagementGateway .

     • Par défaut, si le compte d’ouverture de session de service n’a pas été modifié, il doit disposer d’autorisations en lecture/écriture.

       

     • Si vous avez modifié le compte d’ouverture de session du service, limitez le problème en procédant comme suit :

       1. Effectuez une désinstallation propre du runtime d’intégration auto-hébergé actuel.
       2. Installez les bits de runtime d’intégration auto-hébergés.
       3. Modifiez le compte de service en procédant comme suit :
          1. Accédez au dossier d’installation du runtime d’intégration auto-hébergé, puis basculez vers le dossier Microsoft Integration Runtime\4.0\Shared.
          2. Ouvrez une fenêtre d’invite de commandes à l’aide de privilèges élevés. Remplacez <l’utilisateur> et <le mot de passe> par votre propre nom d’utilisateur et mot de passe, puis exécutez la commande suivante : dmgcmd.exe -SwitchServiceAccount "<user>" "<password>"
          3. Si vous souhaitez passer au compte LocalSystem, veillez à utiliser le format approprié pour ce compte : dmgcmd.exe -SwitchServiceAccount "NT Authority\System" ""
          4. N’utilisez pas ce format :dmgcmd.exe -SwitchServiceAccount "LocalSystem" ""
          5. Si vous le souhaitez, étant donné que le système local dispose de privilèges plus élevés que l’administrateur, vous pouvez également le modifier directement dans « Services ».
          6. Vous pouvez utiliser un utilisateur local/de domaine pour le compte d’ouverture de session du service IR.
       4. Inscrivez le runtime d’intégration.

• Si l’erreur est « Le service 'Integration Runtime service' (DIAHostService) n’a pas pu démarrer. Vérifiez que vous disposez des privilèges suffisants pour démarrer les services système », procédez comme suit :

  1. Vérifiez le compte de service d’ouverture de session DIAHostService dans le panneau de service Windows.

     

  2. Vérifiez si le compte de service d’ouverture de session dispose de l’autorisation Ouvrir une session en tant que service pour démarrer le service Windows :

     

Plus d’informations

Si aucun des deux modèles de résolution précédents ne s’applique dans votre cas, essayez de collecter les journaux des événements Windows suivants :

• Journaux > des applications et des services Integration Runtime
• Application journaux > Windows

Impossible de trouver le bouton Inscrire pour inscrire un runtime d’intégration auto-hébergé

Symptômes

Lorsque vous inscrivez un runtime d’intégration auto-hébergé, le bouton Inscrire ne s’affiche pas dans le volet Configuration Manager.

Cause

Depuis la version de Integration Runtime 3.0, le bouton Inscrire sur les nœuds du runtime d’intégration existants a été supprimé pour permettre un environnement plus propre et plus sécurisé. Si un nœud a été inscrit auprès d’un runtime d’intégration, qu’il soit en ligne ou non, réinscrivez-le auprès d’un autre runtime d’intégration en désinstallant le nœud précédent, puis installez et inscrivez le nœud.

Solution

1. Dans Panneau de configuration, désinstallez le runtime d’intégration existant.

   Importante

   Dans le processus suivant, sélectionnez Oui. Ne conservez pas les données pendant le processus de désinstallation.

   

2. Si vous n’avez pas le fichier MSI du programme d’installation du runtime d’intégration, accédez au centre de téléchargement pour télécharger le dernier runtime d’intégration.

3. Installez le fichier MSI et inscrivez le runtime d’intégration.

Impossible d’inscrire le runtime d’intégration auto-hébergé en raison de localhost

Symptômes

Vous ne pouvez pas inscrire le runtime d’intégration auto-hébergé sur un nouvel ordinateur lorsque vous utilisez get_LoopbackIpOrName.

Debug: Une erreur d’exécution s’est produite. L’initialiseur de type pour « Microsoft.DataTransfer.DIAgentHost.DataSourceCache » a levé une exception. Une erreur non récupérable s’est produite lors d’une recherche de base de données.

Détail de l’exception : System.TypeInitializationException : l’initialiseur de type pour « Microsoft.DataTransfer.DIAgentHost.DataSourceCache » a levé une exception. >--- System.Net.Sockets.SocketException : une erreur non récupérable s’est produite lors d’une recherche de base de données sur System.Net.Dns.GetAddrInfo(String name).

Cause

Le problème se produit généralement lorsque le localhost est en cours de résolution.

Resolition

Utilisez l’adresse IP localhost 127.0.0.1 pour héberger le fichier et résoudre le problème.

Échec de l’installation auto-hébergée

Symptômes

Vous ne pouvez pas désinstaller un runtime d’intégration existant, installer un nouveau runtime d’intégration ou mettre à niveau un runtime d’intégration existant vers un nouveau runtime d’intégration.

Cause

L’installation du runtime d’intégration dépend du service Windows Installer. Vous pouvez rencontrer des problèmes d’installation pour les raisons suivantes :

• Espace disque disponible insuffisant.
• Absence d’autorisations.
• Le service Windows NT est verrouillé.
• L’utilisation du processeur est trop élevée.
• Le fichier MSI est hébergé dans un emplacement réseau lent.
• Certains fichiers ou registres système ont été touchés involontairement.

Le compte de service ir n’a pas pu récupérer l’accès au certificat

Symptômes

Lorsque vous installez un runtime d’intégration auto-hébergé via Microsoft Integration Runtime Configuration Manager, un certificat avec une autorité de certification approuvée est généré. Impossible d’appliquer le certificat pour chiffrer la communication entre deux nœuds, et le message d’erreur suivant s’affiche :

« Échec de la modification du mode de chiffrement de la communication intranet : échec de l’octroi d’Integration Runtime compte de service à l’accès au certificat « nom> du certificat ».< Code d’erreur 103 »

Cause

Le certificat utilise le stockage du fournisseur de stockage de clés (KSP), qui n’est pas encore pris en charge. À ce jour, le runtime d’intégration auto-hébergé prend uniquement en charge le stockage fournisseur de services de chiffrement (CSP).

Solution

Dans ce cas, nous vous recommandons d’utiliser des certificats CSP.

Solution 1

Pour importer le certificat, exécutez la commande suivante :

Certutil.exe -CSP "CSP or KSP" -ImportPFX FILENAME.pfx

Solution 2

Pour convertir le certificat, exécutez les commandes suivantes :

openssl pkcs12 -in .\xxxx.pfx -out .\xxxx_new.pem -password pass: <EnterPassword> openssl pkcs12 -export -in .\xxxx_new.pem -out xxxx_new.pfx

Avant et après la conversion :

Runtime d’intégration auto-hébergé version 5.x

Pour la mise à niveau vers la version 5.x du runtime d’intégration auto-hébergé, nous avons besoin de .NET Framework Runtime 4.7.2 ou version ultérieure. Sur la page de téléchargement, vous trouverez des liens de téléchargement pour la dernière version 4.x et les deux dernières versions 5.x.

Pour les clients Azure Data Factory v2 et Azure Synapse :

• Si la mise à jour automatique est activée et que vous avez déjà mis à niveau votre runtime .NET Framework vers la version 4.7.2 ou ultérieure, le runtime d’intégration auto-hébergé est automatiquement mis à niveau vers la dernière version 5.x.
• Si la mise à jour automatique est activée et que vous n’avez pas mis à niveau votre runtime .NET Framework vers la version 4.7.2 ou ultérieure, le runtime d’intégration auto-hébergé ne sera pas automatiquement mis à niveau vers la dernière version 5.x. Le runtime d’intégration auto-hébergé reste dans la version 4.x actuelle. Vous pouvez voir un avertissement pour une mise à niveau du runtime .NET Framework dans le portail et le client du runtime d’intégration auto-hébergé.
• Si la mise à jour automatique est désactivée et que vous avez déjà mis à niveau votre runtime .NET Framework vers la version 4.7.2 ou ultérieure, vous pouvez télécharger manuellement la dernière version 5.x et l’installer sur votre ordinateur.
• Si la mise à jour automatique est désactivée et que vous n’avez pas mis à niveau votre runtime .NET Framework vers la version 4.7.2 ou ultérieure. Lorsque vous essayez d’installer manuellement le runtime d’intégration auto-hébergé 5.x et d’inscrire la clé, vous devez d’abord mettre à niveau votre version du runtime .NET Framework.

Pour les clients Azure Data Factory v1 :

• Le runtime d’intégration auto-hébergé 5.X ne prend pas en charge Azure Data Factory v1.
• Le runtime d’intégration auto-hébergé sera automatiquement mis à niveau vers la dernière version de la version 4.x. Et la dernière version de 4.x n’expirera pas.
• Si vous essayez d’installer manuellement le runtime d’intégration auto-hébergé 5.x et d’inscrire la clé, vous serez averti que le runtime d’intégration auto-hébergé 5.x ne prend pas en charge Azure Data Factory v1.

Problèmes de connectivité du runtime d’intégration auto-hébergé

Le runtime d’intégration auto-hébergé ne peut pas se connecter au service cloud

Symptômes

Lorsque vous tentez d’inscrire le runtime d’intégration auto-hébergé, Configuration Manager affiche le message d’erreur suivant :

« Le nœud Integration Runtime (auto-hébergé) a rencontré une erreur lors de l’inscription. »

Cause

Le runtime d’intégration auto-hébergé ne peut pas se connecter au serveur principal du service. Ce problème est généralement dû aux paramètres réseau du pare-feu.

Solution

1. Vérifiez si le service runtime d’intégration est en cours d’exécution. Si c’est le cas, passez à l’étape 2.

   

2. Si aucun proxy n’est configuré sur le runtime d’intégration auto-hébergé, qui est le paramètre par défaut, exécutez la commande PowerShell suivante sur l’ordinateur sur lequel le runtime d’intégration auto-hébergé est installé :

    (New-Object System.Net.WebClient).DownloadString("https://wu2.frontend.clouddatahub.net/")
   

   Remarque

   L’URL du service peut varier en fonction de l’emplacement de votre fabrique de données ou de votre espace de travail Synapse instance. Pour trouver l’URL du service, utilisez la page Gérer de l’interface utilisateur dans votre fabrique de données ou Azure Synapse instance pour rechercher les runtimes d’intégration et cliquez sur votre runtime d’intégration auto-hébergé pour le modifier. Sélectionnez l’onglet Nœuds , puis cliquez sur Afficher les URL du service.

3. Voici la réponse attendue :

   

4. Si vous ne recevez pas la réponse attendue, utilisez l’une des méthodes suivantes, le cas échéant :

   • Si vous recevez un message « Impossible de résoudre le nom distant », il y a un problème DNS (Domain Name System). Contactez votre équipe réseau pour résoudre le problème.
   • Si vous recevez un message « ssl/tls cert is not trusted », case activée le certificat (https://wu2.frontend.clouddatahub.net/) pour voir s’il est approuvé sur l’ordinateur, puis installez le certificat public à l’aide du Gestionnaire de certificats. Cette action doit atténuer le problème.
   • Accédez àObservateur d’événements Windows > (journaux)>Journaux > des applications et des servicesIntegration Runtime et case activée pour toute défaillance provoquée par DNS, une règle de pare-feu ou les paramètres réseau de l’entreprise. Si vous constatez un tel échec, fermez de force la connexion. Étant donné que chaque entreprise dispose de ses propres paramètres réseau personnalisés, contactez votre équipe réseau pour résoudre ces problèmes.

5. Si « proxy » a été configuré sur le runtime d’intégration auto-hébergé, vérifiez que votre serveur proxy peut accéder au point de terminaison de service. Pour obtenir un exemple de commande, consultez PowerShell, requêtes web et proxys.

    $user = $env:username
    $webproxy = (get-itemproperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet
    Settings').ProxyServer
    $pwd = Read-Host "Password?" -assecurestring
    $proxy = new-object System.Net.WebProxy
    $proxy.Address = $webproxy
    $account = new-object System.Net.NetworkCredential($user,	[Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($pwd)), "")
    $proxy.credentials = $account
    $url = "https://wu2.frontend.clouddatahub.net/"
    $wc = new-object system.net.WebClient
    $wc.proxy = $proxy
    $webpage = $wc.DownloadData($url)
    $string = [System.Text.Encoding]::ASCII.GetString($webpage)
    $string
   

Voici la réponse attendue :

Remarque

Considérations relatives au proxy :

• Vérifiez si le serveur proxy doit être placé dans la liste des destinataires approuvés. Si c’est le cas, assurez-vous que ces domaines figurent dans la liste Des destinataires approuvés.
• Vérifiez si le certificat SSL/TLS « wu2.frontend.clouddatahub.net/ » est approuvé sur le serveur proxy.
• Si vous utilisez l’authentification Active Directory sur le proxy, remplacez le compte de service par le compte d’utilisateur qui peut accéder au proxy en tant que « service Integration Runtime ».

Impossible d’établir une relation d’approbation pour le canal sécurisé SSL/TLS

Symptômes

Le runtime d’intégration auto-hébergé n’a pas pu se connecter à Microsoft Purview.

Lorsque vous case activée le journal des événements du runtime d’intégration auto-hébergé après avoir accédez àl’Observateur d’événementsWindows> (journaux)>Journaux > des applications et des services Integration Runtime, le message d’erreur suivant s’affiche :

« La connexion sous-jacente a été fermée : Impossible d’établir une relation d’approbation pour le canal sécurisé SSL/TLS. Le certificat distant n’est pas valide selon la procédure de validation. »

La méthode la plus simple pour case activée le certificat de serveur du service consiste à ouvrir l’URL du service dans votre navigateur. Par exemple, ouvrez le lien de certificat de serveur case activée ((https://eu.frontend.clouddatahub.net/) sur l’ordinateur sur lequel le runtime d’intégration auto-hébergé est installé, puis affichez les informations du certificat de serveur.

Cause

Il existe deux raisons possibles à ce problème :

• Raison 1 : L’autorité de certification racine du certificat de serveur du service n’est pas approuvée sur l’ordinateur sur lequel le runtime d’intégration auto-hébergé est installé.
• Raison 2 : Vous utilisez un proxy dans votre environnement, le certificat de serveur du service est remplacé par le proxy et le certificat de serveur remplacé n’est pas approuvé par l’ordinateur sur lequel le runtime d’intégration auto-hébergé est installé.

Solution

• Pour la raison 1 : assurez-vous que le certificat de serveur du service et sa chaîne de certificats sont approuvés par l’ordinateur sur lequel le runtime d’intégration auto-hébergé est installé.
• Pour la raison 2 : approuvez l’autorité de certification racine remplacée sur l’ordinateur runtime d’intégration auto-hébergé, ou configurez le proxy pour ne pas remplacer le certificat de serveur du service.

Pour plus d’informations sur l’approbation des certificats sur Windows, consultez Installation du certificat racine approuvé.

Plus d’informations

Nous avons déployé un nouveau certificat SSL, qui est signé à partir de DigiCert. Vérifiez si DigiCert Global Root G2 se trouve dans l’autorité de certification racine approuvée.

S’il ne se trouve pas dans l’autorité de certification racine approuvée, téléchargez-la ici.

Étapes suivantes

Pour obtenir de l’aide sur la résolution des problèmes, essayez les ressources suivantes :

• Prise en main de Microsoft Purview
• Créer et gérer des runtimes d’intégration auto-hébergés SHIR dans Purview
• Forum aux questions sur Microsoft Purview