Résoudre les problèmes liés au runtime d’intégration auto-hébergé

S’APPLIQUE À : Azure Data Factory Azure Synapse Analytics Microsoft Purview

Conseil

Essayez Data Factory dans Microsoft Fabric, une solution d’analyse tout-en-un pour les entreprises. Microsoft Fabric couvre tous les aspects, du déplacement des données à la science des données, en passant par l’analyse en temps réel, l’aide à la décision et la création de rapports. Découvrez comment démarrer un nouvel essai gratuitement !

Cet article présente des méthodes couramment employées pour résoudre les problèmes liés au runtime d’intégration (IR) auto-hébergé dans les espaces de travail Azure Data Factory et Synapse.

Collecter les journaux d’un IR auto-hébergé

Azure Data Factory et Azure Synapse Analytics

Le service prend en charge l’affichage et le chargement des journaux d’erreurs pour les activités ayant échoué qui sont exécutées sur un IR auto-hébergé ou partagé. Pour obtenir l’ID de rapport d’erreurs, suivez les instructions fournies ici, puis entrez l’ID de rapport pour rechercher les problèmes connus associés.

1. Dans la page Superviser de l’interface utilisateur du service, sélectionnez Exécutions de pipeline.

2. Sous Exécutions de l’activité, dans la colonne Erreur, sélectionnez le bouton en surbrillance pour afficher les journaux d’activité, comme illustré dans la capture d’écran suivante :

   Azure Data Factory

   

   Azure Synapse

   

   Les journaux d’activité s’affichent pour l’exécution de l’activité qui a échoué.

   

3. Pour obtenir de l’aide, sélectionnez Envoyer des journaux.

   La fenêtre Share the self-hosted integration runtime (IR) logs with Microsoft (Partager les journaux du runtime d’intégration (IR) auto-hébergé avec Microsoft) s’ouvre.

   

4. Sélectionnez les journaux que vous souhaitez envoyer.

   • Pour un IR auto-hébergé, vous pouvez charger les journaux relatifs à l’activité ayant échoué ou tous les journaux sur le nœud de l’IR auto-hébergé.
   • Pour un IR partagé, vous pouvez charger uniquement les journaux liés à l’activité ayant échoué.

5. Lorsque les journaux sont chargés, conservez une trace de l’ID du rapport au cas où vous auriez besoin d’une aide supplémentaire ultérieurement pour résoudre le problème.

   

Notes

Les requêtes de consultation et de chargement des journaux sont exécutées sur toutes les instances de l’IR auto-hébergé en ligne. S’il manque des journaux, assurez-vous que toutes les instances de l’IR auto-hébergé sont en ligne.

Microsoft Purview

Pour les activités Microsoft Purview ayant échoué exécutées sur un IR auto-hébergé ou partagé, le service prend en charge l’affichage et le chargement des journaux d’erreurs depuis l’observateur d’événements Windows.

Vous pouvez rechercher toutes 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 le support Microsoft, suivez ces instructions :

1. Avant de commencer 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 l’observateur d’événements Windows.
   2. Effacez les journaux de l’observateur d’événements Windows dans la section Runtime d’intégration. 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é le statut Échec, revenez à la machine virtuelle SHIR ou à l’ordinateur et actualisez l’observateur d’événements dans la section Runtime d’intégration.

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

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

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

   

5. Sélectionnez les journaux que vous souhaitez envoyer.

   • Pour un IR auto-hébergé, vous pouvez charger les journaux relatifs à l’activité ayant échoué ou tous les journaux sur le nœud de l’IR auto-hébergé.
   • Pour un IR partagé, vous pouvez charger uniquement les journaux liés à l’activité ayant échoué.

6. Lorsque les journaux sont chargés, conservez une trace de l’ID du rapport au cas où vous auriez besoin d’une aide supplémentaire ultérieurement pour résoudre le problème.

   

Notes

Les requêtes de consultation et de chargement des journaux sont exécutées sur toutes les instances de l’IR auto-hébergé en ligne. S’il manque des journaux, assurez-vous que toutes les instances de l’IR auto-hébergé sont en ligne.

Erreur générale ou échec général de l’IR auto-hébergé

Problème de mémoire insuffisante

• Symptômes

  Une erreur OutOfMemoryException (Mémoire insuffisante) se produit lorsque vous essayez d’exécuter une activité de recherche avec un IR lié ou un IR auto-hébergé.

• Cause

  Une nouvelle activité peut générer une erreur Mémoire insuffisante si l’ordinateur de l’IR subit une utilisation de mémoire élevée momentanément. Le problème peut être dû à l’exécution de nombreuses activités simultanées et l’erreur est due à la conception.

• Résolution :

  Vérifiez l’utilisation des ressources et l’exécution simultanée d’activités sur le nœud IR. Ajustez l’heure interne et l’heure de déclenchement des exécutions d’activité pour éviter un trop grand nombre d’exécutions sur un même nœud IR en même temps.

Problème lié à la limite de tâches simultanées

• Symptômes

  Lorsque vous essayez d’augmenter la limite de travaux simultanés à partir de l’interface utilisateur, le processus se bloque à l’état Mise à jour.

  Exemple de scénario : la valeur maximale de travaux simultanés est actuellement définie sur 24 et vous souhaitez augmenter le nombre afin que les travaux puissent s’exécuter plus rapidement. La valeur minimale que vous pouvez entrer est 3 et la valeur maximale est 32. Vous augmentez la valeur de 24 à 32, puis vous sélectionnez le bouton Mettre à jour. Le processus est bloqué avec l’état Mise à jour, comme indiqué dans la capture d’écran suivante. Vous actualisez la page et la valeur 24 est toujours affichée. Elle n’a pas été mise à jour sur 32 comme prévu.

  

• Cause

  La limite du nombre de travaux simultanés dépend de la mémoire et du cœur logique de l’ordinateur. Essayez d’ajuster la valeur vers le bas jusqu’à une valeur telle que 24, puis affichez le résultat.

  Conseil

  • Pour en savoir plus sur le nombre de cœurs logiques et pour déterminer le nombre de cœurs logiques de votre ordinateur, consultez Quatre façons de trouver le nombre de cœurs dans votre UC sur Windows 10.
  • Pour savoir comment calculer le fichier math.log, accédez à la calculatrice de logarithme.

Problème de certificat SSL à haute disponibilité de l’IR auto-hébergé

• Symptômes

  Le nœud Worker de l’IR auto-hébergé a signalé l’erreur suivante :

  «Échec de l’extraction des états partagés du nœud principal net.tcp://abc.cloud.corp.Microsoft.com:8060/ExternalService.svc/. ID d’activité : XXXXX Échec de la génération de la chaîne de certificat X.509 CN=abc.cloud.corp.Microsoft.com, OU=test, O=Microsoft. Le certificat qui a été utilisé est doté d'une chaîne d'approbation impossible à vérifier. Remplacez ce certificat ou modifiez l'élément certificateValidationMode. « La fonction de révocation n’a pas pu vérifier la révocation car le serveur de révocation était déconnecté ».

• Cause

  Lorsque vous traitez des cas liés à une négociation SSL/TLS, vous pouvez rencontrer certains problèmes liés à la vérification de la chaîne de certificats.

• Résolution :

  • Voici un moyen rapide et intuitif de résoudre les échecs de génération de chaîne de certificats X.509 :

    1. Exportez le certificat, qui doit être vérifié. Pour ce faire, procédez comme suit :

       a. Dans Windows, sélectionnez Démarrer, commencez à taper Certificats, puis sélectionnez Gérer les certificats d’ordinateur.

       b. Dans l’Explorateur de fichiers, dans le volet gauche, recherchez le certificat que vous souhaitez vérifier, cliquez dessus avec le bouton droit, puis sélectionnez Toutes les tâches>Exporter.

       

    2. Copiez le certificat exporté sur la machine cliente.

    3. Côté client, dans une fenêtre d’invite de commandes, exécutez la commande suivante. Veillez à remplacer le <chemin d’accès du certificat> et le <chemin d’accès du fichier txt> par les chemins d’accès réels.

       Certutil -verify -urlfetch    <certificate path>   >     <output txt file path> 
       

       Par exemple :

       Certutil -verify -urlfetch c:\users\test\desktop\servercert02.cer > c:\users\test\desktop\Certinfo.txt
       

    4. Recherchez les erreurs dans le fichier TXT de sortie. Le résumé des erreurs se trouve à la fin du fichier TXT.

       Par exemple :

       

       Si aucune erreur ne s’affiche à la fin du fichier journal, comme indiqué dans la capture d’écran suivante, vous pouvez considérer que la chaîne de certificats a été générée correctement sur l’ordinateur client.

       

  • Si une extension de nom de fichier AIA (Authority Information Access), CDP (CRL Distribution Point) ou OCSP (Online Certificate Status Protocol) est configurée dans le fichier de certificat, vous pouvez la vérifier de manière plus intuitive :

    1. Pour plus d’informations, consultez les détails du certificat, comme indiqué dans la capture d’écran suivante :

       

    2. Exécutez la commande suivante : Veillez à remplacer le <chemin d’accès du certificat> par le chemin d’accès réel.

         Certutil   -URL    <certificate path> 
       

       L’outil de récupération d’URL s’ouvre.

    3. Pour vérifier les certificats avec les extensions de nom de fichier AIA, CDP et OCSP, sélectionnez Récupérer.

       

       Vous avez généré la chaîne de certificats correctement si l’état du certificat AIA est Vérifié et que l’état du certificat CDP ou OCSP est Vérifié.

       Si vous échouez lorsque vous tentez de récupérer AIA ou CDP, contactez l’équipe réseau pour préparer la machine cliente à se connecter à l’URL cible. Cela suffit si le chemin d’accès HTTP ou le chemin d’accès LDAP (Lightweight Directory Access Protocol) peuvent être vérifiés.

L’IR auto-hébergé n’a pas pu télécharger le fichier ou l’assembly

• Symptômes

  Vous obtenez le message d'erreur suivant :

  « Impossible de charger le fichier ou l’assembly 'XXXXXXXXXXXXXXXX, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' ou une de ses dépendances. Le système ne peut pas trouver le fichier spécifié. 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 une de ses dépendances. Le système ne peut pas trouver le fichier spécifié. ID d’activité : 92693b45-b4bf-4fc8-89da-2d3dc56f27c3"

• Cause

  Dans Process Monitor, vous pouvez afficher les résultats suivants :

  

  Conseil

  Dans Process Monitor, vous pouvez définir des filtres comme indiqué 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 associé GAC ou dans 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.

  

• Résolution

  Le fichier System.ValueTuple.dll se trouve 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 manquant.

• Plus d'informations sur ce problème

  La raison pour laquelle vous voyez le fichier 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 voir clairement que l’assembly System.ValueTuple est manquant. Ce problème se produit lorsque l’application tente de vérifier l’assembly System.ValueTuple.dll.

  "<LogProperties><ErrorInfo>[{"Code":0,"Message":"L’initialiseur de type pour 'Npgsql.PoolManager' a généré 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=neutral, PublicKeyToken=XXXXXXXXX' ou 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 le GAC, consultez Global Assembly Cache.

La clé d’authentification du runtime d’intégration auto-hébergé est manquante

• Symptômes

  Le runtime d’intégration auto-hébergé se met 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 IR auto-hébergé ou l’IR auto-hébergé logique dans le portail Azure a été supprimé.
  • Une désinstallation propre a été effectuée.

• Résolution :

  Si aucune des causes ci-dessus ne s’applique, vous pouvez accéder au dossier %programdata%\Microsoft\Data Transfer\DataManagementGateway et vérifier 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 d’utiliser l’IR auto-hébergé pour relier deux magasins de données locaux

• Symptômes

  Une fois que vous avez créé les IR auto-hébergés pour les magasins de données source et de destination, connectez-les pour terminer une activité de copie. Si les magasins de données sont configurés dans différents réseaux virtuels, ou si les magasins de données ne peuvent pas comprendre le mécanisme de passerelle, vous recevez l’une des erreurs suivantes :

  • « Le pilote de la source est introuvable dans l’IR de destination »
  • « La source n’est pas accessible par l’IR de destination »

• Cause

  L’IR auto-hébergé est conçu comme un nœud central d’une activité de copie, et non un agent client qui doit être installé pour chaque magasin de données.

  Dans le cas ci-dessus, vous devez créer le service lié pour chaque magasin de données avec le même IR et l’IR doit être en mesure d’accéder aux deux magasins de données via le réseau. Cela n’a pas d’importance si le runtime d’intégration (IR) est installé sur le magasin de données source ou de destination, ou sur un troisième ordinateur. Si deux services liés sont créés avec différents IR mais qu’ils sont utilisés dans la même activité de copie, le runtime d’intégration (IR) de destination est utilisé et vous devez installer les pilotes pour les deux magasins de données sur l’ordinateur IR de destination.

• Résolution :

  Installez les pilotes pour les magasins de données source et de destination sur le runtime d’intégration de destination et assurez-vous qu’il peut accéder au magasin de données source.

  Si le trafic ne peut pas traverser le réseau entre deux magasins de données (par exemple, s’ils sont configurés en deux réseaux virtuels), vous risquez de ne pas terminer la copie en une seule activité, même si l’IR est installé. Si vous ne pouvez pas terminer la copie en une seule activité, vous pouvez créer deux activités de copie avec deux IR, chacun dans un VENT :

  • Copiez un IR du magasin de données 1 vers le Stockage Blob Azure.
  • Copiez l’autre IR à partir de Stockage Blob Azure vers le magasin de données 2.

  Cette solution peut simuler la nécessité d’utiliser le runtime d’intégration pour créer un pont qui connecte deux magasins de données déconnectés.

Un problème de synchronisation des informations d’identification provoque la perte des informations d’identification de haute disponibilité

• Symptômes

  Si les informations d’identification de la source de données « XXXXXXXXXX » sont supprimées du nœud de runtime d’intégration actuel avec la charge utile, vous recevez le message d’erreur suivant :

  « Quand vous avez supprimé le service de lien sur le portail Azure, ou la tâche n’a pas la bonne charge utile. Recréez un service de lien avec vos informations d’identification. »

• Cause

  Votre IR auto-hébergé est intégré en mode Haute disponibilité avec deux nœuds, mais les nœuds ne sont pas dans l’état de synchronisation des informations d’identification. Cela signifie que les informations d’identification stockées dans le nœud de répartiteur ne sont pas synchronisées avec d’autres nœuds Worker. Si un basculement se produit du nœud répartiteur vers le nœud Worker et que les informations d’identification existent uniquement dans le nœud répartiteur précédent, la tâche échoue lorsque vous tentez d’accéder aux informations d’identification et vous pouvez recevoir l’erreur ci-dessus.

• Résolution :

  La seule façon d’éviter ce problème consiste à s’assurer que les deux nœuds sont dans l’état de synchronisation des informations d’identification. Si elles ne sont pas synchronisées, vous devez réentrer les informations d’identification du nouveau répartiteur.

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 du gestionnaire de configuration d’IR, vous avez reçu le message d’erreur suivant :

    « Échec du changement du mode de chiffrement de la communication intranet. Il est probable que le certificat « <nom du certificat> » n’a pas de clé privée qui prend en charge l’échange de clés ou le processus ne dispose peut-être pas de droits d’accès pour la clé privée. Pour plus d’informations, consultez l’exception interne. »

    

• Cause

  • Le compte d’utilisateur dispose d’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.

• Résolution :

  • Pour utiliser l’interface utilisateur, utilisez un compte disposant des 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
    

Problèmes de synchronisation des nœuds de runtime d'intégration auto-hébergé

• Symptômes

  Les nœuds de runtime d'intégration auto-hébergé essaient de synchroniser les informations d'identification entre les nœuds, mais ils restent bloqués en cours de processus, ce qui finit par déclencher le message d'erreur ci-dessous :

  « Le nœud Integration Runtime (auto-hébergé) essaie de synchroniser les informations d'identification entre les nœuds. Cette opération peut prendre quelques minutes.

  Notes

  Si cette erreur apparaît pendant plus de 10 minutes, vérifiez la connectivité avec le nœud répartiteur.

• Cause

  Cela est dû au fait que les nœuds Worker n'ont pas accès aux clés privées. Cela peut être confirmé à partir des journaux du runtime d'intégration auto-hébergé ci-dessous :

  [14]0460.3404::05/07/21-00:23:32.2107988 [System] A fatal error occurred when attempting to access the TLS server credential private key. The error code returned from the cryptographic module is 0x8009030D. The internal error state is 10001.

  Le processus de synchronisation ne pose aucun problème lorsque vous utilisez l'authentification du principal du service dans le service lié. En revanche, lorsque vous changez de type d'authentification pour utiliser une clé de compte, un problème de synchronisation survient. En effet, le service du runtime d'intégration auto-hébergé est exécuté sous un compte de service (NT SERVICE\DIAHostService) et doit être ajouté aux autorisations des clés privées.

• Résolution :

  Pour résoudre ce problème, vous devez ajouter le compte de service du runtime d'intégration auto-hébergé (NT SERVICE\DIAHostService) aux autorisations des clés privées. Vous pouvez procéder comme suit :

  1. Ouvrez la Run Command de votre console MMC (Microsoft Management Console).

     

  2. Dans le volet MMC, procédez comme suit :

     

     1. Sélectionnez Fichier.
     2. Dans le menu déroulant, choisissez Ajouter/supprimer un composant logiciel enfichable.
     3. Sélectionnez Certificats dans le volet « Composants logiciels enfichables disponibles ».
     4. Sélectionnez Ajouter.
     5. Dans le volet contextuel « Composant logiciel enfichable Certificats », choisissez Compte d'ordinateur.
     6. Sélectionnez Suivant.
     7. Dans le volet « Sélectionner un ordinateur », choisissez L'ordinateur local (l'ordinateur sur lequel cette console s'exécute) .
     8. Sélectionnez Terminer.
     9. Sélectionnez OK dans le volet « Ajouter ou supprimer des composants logiciels enfichables ».

  3. Dans le volet de la console MMC, procédez comme suit :

     

     1. Dans la liste des dossiers de gauche, sélectionnez Racine de la console -> Certificats (ordinateur local) -> Personnel -> Certificats.
     2. Cliquez avec le bouton droit sur Microsoft Intune Beta MDM.
     3. Dans la liste déroulante, sélectionnez Toutes les tâches.
     4. Sélectionnez Gérer les clés privées.
     5. Sélectionnez Ajouter sous « Noms de groupes ou d'utilisateurs ».
     6. Sélectionnez NT SERVICE\DIAHostService pour lui accorder un accès avec contrôle total à ce certificat, l'appliquer et le sécuriser.
     7. Sélectionnez Vérifier les noms, puis OK.
     8. Dans le volet « Autorisations », sélectionnez Appliquer, puis cliquez sur OK.

Message d’erreur UserErrorJreNotFound lors de l’exécution d’une activité de copie vers Azure

• Symptômes

  Lorsque vous essayez de copier du contenu vers Microsoft Azure à l’aide d’un outil ou programme Java (par exemple, en copiant des fichiers de format ORC ou Parquet), un message d’erreur semblable au suivant s’affiche :

  ErrorCode=UserErrorJreNotFound,’Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Java Runtime Environment introuvable. Accédez à http://go.microsoft.com/fwlink/?LinkId=808605 pour opérer un téléchargement et une installation sur votre machine de nœud Integration Runtime (auto-hébergé). Remarquez que le runtime d’intégration 64 bits requiert le JRE 64 bits, et que le runtime d’intégration 32 bits requiert le JRE 32 bits.,Source=Microsoft.DataTransfer.Common,’’Type=System.DllNotFoundException,Message=Impossible de charger DLL ’jvm.dll’ : le module spécifié est introuvable. (Exception from 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 de runtime d’intégration.

  • Votre serveur de runtime d’intégration ne dispose pas de la dépendance requise pour JRE.

  Par défaut, le runtime d’intégration 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.

• Résolution :

  Suivez attentivement les étapes décrites dans cette section. De graves problèmes peuvent se produire si vous modifiez le Registre de façon incorrecte. Avant de le modifier, sauvegardez le Registre afin de pouvoir le restaurer en cas de problème.

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

  1. Assurez-vous que le runtime d’intégration (Diahost.exe) et le JRE sont installés sur la même plateforme. Vérifiez les conditions suivantes :

     • Le JRE 64 bits pour le runtime d’intégration ADF 64 bits doit être installé dans le dossier : C:\Program Files\Java\

       Notes

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

     • Java Runtime (JRE) est à la version 11 ou plus provenant d’un fournisseur JRE, comme Microsoft OpenJDK 11 ou Eclipse Temurin 11. Assurez-vous que la variable d’environnement du système JAVA_HOME est définie vers le dossier JDK (pas seulement le dossier JRE). Vous allez peut-être également devoir ajouter le dossier corbeille à la variable d’environnement PATH de votre système.

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

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

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

        HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment.

        Le volet Détails doit contenir une entrée Version actuelle affichant la version du JRE (par exemple, 1.8).

        

     3. Dans le volet de navigation, recherchez une sous-clé correspondant exactement à la version (par exemple, 1.8) dans le dossier JRE. Le volet Détails devrait contenir une entrée JavaHome. La valeur de cette entrée est le chemin d’installation de JRE.

        

  3. Localisez le dossier bin\server dans le chemin d’accès suivant :

     C:\Program Files\Java\jre1.8.0_74

     

  4. Vérifiez si ce dossier contient un fichier jvm.dll. Si ce n’est pas le cas, recherchez le fichier dans le dossier bin\client.

     

  Notes

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

Installation du runtime d’intégration IR auto-hébergé

Erreur d’inscription du runtime d’intégration

• Symptômes

  Vous pouvez vouloir exécuter un IR auto-hébergé dans un autre compte pour l’une des raisons suivantes :

  • La stratégie d’entreprise interdit le compte de service.
  • L’authentification est obligatoire.

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

  « Le nœud Integration Runtime (auto-hébergé) a rencontré une erreur durant 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 les mêmes.

• Résolution :

  Accédez au journal des événements du runtime d’intégration pour vérifier 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 de l’autorisation de lecture/écriture sur le dossier %programdata%\Microsoft\DataTransfer\DataManagementGateway.

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

         

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

         a. Effectuez une désinstallation propre du runtime d’intégration auto-hébergé actuel.
         b. Installez le runtime d’intégration auto-hébergé.
         c. Modifiez le compte de service en procédant comme suit :

         i. Accédez au dossier d’installation du runtime d’intégration auto-hébergé, puis accédez au dossier Microsoft Integration Runtime\4.0\Shared.
         ii. Ouvrez une fenêtre Invite de commandes en utilisant des privilèges élevés. Remplacez <utilisateur> et <mot de passe> par vos propres nom d’utilisateur et mot de passe, puis exécutez la commande suivante :
         dmgcmd.exe -SwitchServiceAccount "<user>" "<password>"
         iii. Si vous souhaitez passer au compte LocalSystem, veillez à utiliser un format correct pour ce compte : dmgcmd.exe -SwitchServiceAccount "NT Authority\System" ""
         N’utilisez pas ce format : dmgcmd.exe -SwitchServiceAccount "LocalSystem" ""
         iv. À l’inverse, étant donné que le système local dispose de privilèges plus élevés que l’administrateur, vous pouvez également le modifier directement en « Services ».
         v. Vous pouvez utiliser un utilisateur local/de domaine pour le compte d’ouverture de session du service IR.

         d. Inscrivez le runtime d’intégration.

  • Si l’erreur « Échec du démarrage du service Integration Runtime Service (DIAHostService). Vérifiez que vous disposez de privilèges suffisants pour démarrer les services système. » s’affiche, 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
  • Journaux d’activité Windows > Application

Impossible de trouver le bouton Inscrire pour inscrire un IR auto-hébergé

• Symptômes

  Lorsque vous inscrivez un IR auto-hébergé, le bouton Inscrire ne s’affiche pas dans le volet du gestionnaire de configuration.

  

• Cause

  Depuis la sortie d’Integration Runtime 3.0, le bouton Inscrire des nœuds de runtime d’intégration existants a été supprimé pour proposer un environnement plus clair et plus sécurisé. Si un nœud a été inscrit sur un IR (qu’il soit en ligne ou non), réinscrivez-le dans un autre IR en désinstallant le nœud précédent, puis installez et inscrivez le nœud.

• Résolution :

  1. Dans le Panneau de configuration, désinstallez l’IR existant.

     Important

     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 l’IR le plus récent.

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

Impossible d’inscrire l’IR auto-hébergé en raison du localhost

• Symptômes

  Vous ne pouvez pas inscrire l’IR auto-hébergé sur un nouvel ordinateur lorsque vous utilisez get_LoopbackIpOrName.

  Débogage : 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 lors de la résolution de l’hôte local.

• Résolution :

  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 ni installer un nouveau runtime d’intégration existant ou mettre à niveau un IR 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.
  • Autorisations manquantes.
  • Le service Windows NT est verrouillé.
  • Utilisation du processeur trop élevée.
  • Le fichier MSI est hébergé dans un emplacement réseau lent.
  • Certains registres ou fichiers système ont été touchés par inadvertance.

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

• Symptômes

  Lorsque vous installez l’IR auto-hébergé via le gestionnaire de configuration Microsoft Integration Runtime, un certificat avec une autorité de certification approuvée est généré. Le certificat n’a pas pu être appliqué pour chiffrer les communications entre deux nœuds et le message d’erreur suivant s’affiche :

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

  

• Cause

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

• Résolution :

  Nous vous recommandons d’utiliser des certificats CSP dans ce cas.

  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

  Conversion avant et après :

  

  

Version 5.x du runtime d’intégration auto-hébergé

Pour la mise à niveau vers la version 5.x du runtime d’intégration auto-hébergé, vous avez besoin du runtime .NET Framework 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 le runtime .NET Framework vers la version 4.7.2 ou ultérieure, le runtime d’intégration auto-hébergé sera automatiquement mis à niveau vers la version 5.x la plus récente.
• Si la mise à jour automatique est activée et que vous n’avez pas mis à niveau le 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 version 5.x la plus récente. Le runtime d’intégration auto-hébergé conservera la version 4.x actuelle. Vous pouvez voir un avertissement pour la 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 le runtime .NET Framework vers la version 4.7.2 ou ultérieure, vous pouvez télécharger manuellement la version 5.x la plus récente et l’installer sur votre ordinateur.
• Si la mise à jour automatique est désactivée et que vous n’avez pas mis à niveau le 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 runtime .NET Framework.

Problème de connexion de l’IR 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é, le gestionnaire de configuration affiche le message d’erreur suivant :

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

  

• Cause

  L’IR auto-hébergé ne peut pas se connecter au back-end du service. Ce problème est généralement dû à des paramètres réseau dans le pare-feu.

• Résolution :

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

     

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

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

     Notes

     L’URL du service peut varier en fonction de l’emplacement de votre instance Data Factory ou Synapse. Pour trouver l’URL du service, accédez à la page Manage (Gérer) de l’interface utilisateur de votre instance Data Factory ou Azure Synapse et recherchez Runtimes d’intégration, puis cliquez sur votre IR auto-hébergé pour le modifier. Ensuite, sélectionnez l’onglet Nœuds et cliquez sur View Service URLs (Afficher les URL de service).

     Voici la réponse attendue :

     

  3. Si vous ne recevez pas la réponse que vous attendiez, utilisez l’une des méthodes suivantes, selon le cas :

     • Si vous recevez le message « le nom distant n’a pas pu être résolu », il existe un problème DNS (Domain Name System). Contactez votre équipe réseau pour résoudre ce problème.
     • Si vous recevez un message « Certificat SSL/TLS non approuvé », vérifiez si le certificat (https://wu2.frontend.clouddatahub.net/) 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 à Windows>Observateur d’événements (journaux)>Journaux des applications et des services>Runtime d’intégration et recherchez les défaillances provoquées par le DNS, une règle de pare-feu ou des paramètres réseau d’entreprise. Si vous trouvez une de ces défaillances, forcez la fermeture de la connexion. Étant donné que chaque entreprise a personnalisé ses propres paramètres réseau, contactez votre équipe réseau pour résoudre ces problèmes.

  4. Si « proxy » a été configuré sur le runtime d’intégration auto-hébergé, vérifiez que votre serveur proxy est en mesure d’accéder à notre point de terminaison de service. Pour obtenir un exemple de commande, consultez PowerShell, les requêtes Web et les 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 :

  

  Notes

  Considérations liées au proxy :

  • Vérifiez si le serveur proxy doit être placé dans la liste des destinataires approuvés. Dans ce 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 ».

Message d’erreur : Le nœud du runtime d’intégration auto-hébergé /l’IR auto-hébergé logique présente l’état Inactif/ « En cours d’exécution (limité) »

• Cause

  Le nœud Runtime intégré auto-hébergé peut avoir un état inactif, comme indiqué dans la capture d’écran suivante :

  

  Ce comportement se produit lorsque les nœuds ne peuvent pas communiquer entre eux.

• Résolution :

  1. Connectez-vous à la machine virtuelle hébergée sur un nœud. Sous Journaux des applications et des services>Runtime d’intégration, ouvrez l’Observateur d’événements, puis filtrez tous les journaux d’erreurs.

  2. Vérifiez si un journal des erreurs contient l’erreur suivante :

     System.ServiceModel.EndpointNotFoundException: Could not connect to net.tcp://xxxxxxx.bwld.com:8060/ExternalService.svc/WorkerManager. The connection attempt lasted for a time span of 00:00:00.9940994. TCP error code 10061: No connection could be made because the target machine actively refused it 10.2.4.10:8060. 
     System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it. 
     10.2.4.10:8060
     at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
     at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
     at System.ServiceModel.Channels.SocketConnectionInitiator.Connect(Uri uri, TimeSpan timeout)
     

  3. Si vous voyez cette erreur, tapez la commande suivante dans une fenêtre d’invite de commandes.

     telnet 10.2.4.10 8060
     

  4. Si vous recevez l’erreur de ligne de commande « Impossible d’ouvrir la connexion à l’hôte » présentée dans la capture d’écran suivante, contactez votre service informatique pour obtenir de l’aide afin de résoudre ce problème. Lorsque vous parvenez à utiliser Telnet, contactez le support Microsoft si vous rencontrez toujours des problèmes pour l’état du nœud IR.

     

  5. Vérifiez si le journal des erreurs contient l’entrée suivante :

     Error log: Cannot connect to worker manager: net.tcp://xxxxxx:8060/ExternalService.svc/ No DNS entries exist for host azranlcir01r1. No such host is known Exception detail: System.ServiceModel.EndpointNotFoundException: No DNS entries exist for host xxxxx. ---> System.Net.Sockets.SocketException: No such host is known at System.Net.Dns.GetAddrInfo(String name) at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6) at System.Net.Dns.GetHostEntry(String hostNameOrAddress) at System.ServiceModel.Channels.DnsCache.Resolve(Uri uri) --- End of inner exception stack trace --- Server stack trace: at System.ServiceModel.Channels.DnsCache.Resolve(Uri uri)
     

  6. Pour résoudre le problème, essayez l’une des méthodes suivantes, voire les deux :

     • Placez tous les nœuds dans le même domaine.
     • Ajoutez l’adresse IP au mappage de l’hôte dans tous les fichiers hôtes de la machine virtuelle hébergée.

Problème de connectivité entre l’IR auto-hébergé et votre instance Data Factory ou Azure Synapse ou entre l’IR auto-hébergé et la source de données ou le récepteur

Pour résoudre le problème de connectivité réseau, vous devez savoir comment collecter la trace réseau, comprendre comment l’utiliser et analyser la trace Microsoft Network Monitor (Netmon) avant d’appliquer les outils Netmon à de vrais cas à partir de l’IR auto-hébergé.

• Symptômes

  Vous devrez peut-être parfois résoudre certains problèmes de connectivité entre le runtime d’intégration auto-hébergé et votre instance Data Factory ou Azure Synapse, comme indiqué dans la capture d’écran suivante, ou entre l’IR auto-hébergé et la source de données ou le récepteur.

  

  Dans les deux cas, vous pouvez rencontrer les erreurs suivantes :

  • « Échec de la copie avec l’erreur : error:Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Impossible de se connecter à SQL Server : « Adresse IP »

  • « Une ou plusieurs erreurs se sont produites. An error occurred while sending the request. Le serveur a clos la connexion sous-jacente : Une erreur inattendue s’est produite lors de la réception. Impossible de lire les données de la connexion de transport : une connexion existante a dû être fermée par l’hôte distant. Une connexion existante a été fermée de force par l’ID d’activité de l’hôte distant ».

• Résolution :

  Lorsque vous rencontrez les erreurs précédentes, corrigez-les en suivant les instructions de cette section.

  • Collectez une trace Netmon pour analyse :

    1. Vous pouvez définir le filtre pour voir toute réinitialisation à partir du serveur vers le côté client. Dans l’exemple de capture d’écran ci-dessous, vous pouvez voir que le côté serveur est le serveur Data Factory.

       

    2. Lorsque vous obtenez le package de réinitialisation, vous pouvez trouver la conversation en suivant le protocole TCP (Transmission Control Protocol).

       

    3. Obtenez la conversation entre le client et le serveur Data Factory ci-dessous en supprimant le filtre.

       

  • Une analyse de la trace Netmon que vous avez collectée montre que la durée de vie (TTL) est 64. Selon les valeurs mentionnées dans l’article Principes de base de la durée de vie (TTL) et des limites de tronçons, extraites dans la liste suivante, vous pouvez voir qu’il s’agit du système Linux qui réinitialise le package et provoque la déconnexion.

    Les valeurs de durée de vie et de limite de tronçon par défaut varient entre différents systèmes d’exploitation, comme indiqué ici :

    • Noyau Linux 2.4 (circa 2001) : 255 pour TCP, UDP (User Datagram Protocol) et ICMP (Internet Control Message Protocol)
    • Noyau Linux 4.10 (2015) : 64 pour TCP, UDP et ICMP
    • Windows XP (2001) : 128 pour TCP, UDP et ICMP
    • Windows 10 (2015) : 128 pour TCP, UDP et ICMP
    • Windows Server 2008 : 128 pour TCP, UDP et ICMP
    • Windows Server 2019 (2018) : 128 pour TCP, UDP et ICMP
    • macOS (2001) : 64 pour TCP, UDP et ICMP

    

    Dans l’exemple précédent, la durée de vie est indiquée sous la forme 61 au lieu de 64, car lorsque le package réseau atteint sa destination, il doit traverser différents tronçons, tels que des routeurs ou des périphériques réseau. Le nombre de routeurs ou périphériques réseau est déduit pour produire la durée de vie (TTL) finale.

    Dans ce cas, vous pouvez voir qu’une réinitialisation peut être envoyée à partir du système Linux avec TTL 64.

  • Pour confirmer l’origine de la réinitialisation de l’appareil, vérifiez le quatrième tronçon de l’IR auto-hébergé.

    Package réseau provenant du système Linux A avec TTL 64 -> B TTL 64 moins 1 = 63 -> C TTL 63 moins 1 = 62 -> TTL 62 moins 1 = 61 Runtime d’intégration auto-hébergé

  • Dans une situation idéale, le nombre de tronçons TTL est de 128, ce qui signifie que le système d’exploitation Windows exécute votre instance Data Factory. Comme indiqué dans l’exemple suivant, 128 moins 107 = 21 tronçons, ce qui signifie que 21 tronçons pour le package ont été envoyés de l’instance Data Factory vers l’IR auto-hébergé pendant la négociation TCP 3.

    

    Par conséquent, vous devez faire appel à l’équipe réseau pour vérifier à quoi correspond le quatrième tronçon provenant de l’IR auto-hébergé. S’il s’agit du pare-feu, comme avec le système Linux, consultez tous les journaux pour déterminer la raison pour laquelle ce périphérique réinitialise le package après la négociation TCP 3.

    Si vous n’êtes pas sûr de l’emplacement à examiner, essayez d’accéder à la trace Netmon à partir de l’IR auto-hébergé et du pare-feu pendant la période problématique. Cette approche vous permet de déterminer quel appareil a pu réinitialiser le package et a provoqué la déconnexion. Dans ce cas, vous devez également encourager votre équipe réseau à avancer.

Analyser la trace NetMon

Notes

Les instructions suivantes s’appliquent à la trace Netmon. Étant donné que la trace Netmon n’est pas prise en charge, vous pouvez utiliser Wireshark à cet effet.

Lorsque vous essayez d’utiliser Telnet 8.8.8.8 888 avec la trace Netmon collectée, vous devez voir la trace dans les captures d’écran suivantes :

L’image précédente montre que vous n’avez pas pu établir la connexion TCP côté serveur 8.8.8.8 sur le port 888, de sorte que vous y voyez deux packages SynReTransmit supplémentaires. Étant donné que la source SELF-HOST2 ne parvient pas à se connecter à 8.8.8.8 avec le premier package, elle continue d’effectuer des tentatives pour établir la connexion.

Conseil

Pour établir cette connexion, essayez la solution suivante :

1. Sélectionnez Charger le filtre>Filtre standard>Adresses>Adresses IPv4.
2. Pour appliquer le filtre, entrez IPv4.Address == 8.8.8.8, puis sélectionnez Appliquer. Vous devez ensuite voir la communication entre l’ordinateur local et la destination 8.8.8.8.

Les scénarios réussis sont illustrés dans les exemples suivants :

• Si vous pouvez utiliser Telnet 8.8.8.8 53 sans aucun problème, il y a une négociation TCP 3 réussie et la session se termine avec une négociation TCP 4.

  

  

• La négociation TCP 3 précédente produit le workflow suivant :

  

• La négociation TCP 4 pour terminer la session est illustrée par les workflows suivants :

  

  

Notification par e-mail de Microsoft sur la mise à jour de la configuration de votre réseau

Vous pouvez recevoir la notification par e-mail ci-dessous, qui vous recommande de mettre à jour la configuration du réseau afin de permettre la communication avec les nouvelles adresses IP pour Azure Data Factory d’ici le 8 novembre 2020 :

Déterminer si cette notification vous concerne

Cette notification s’applique aux scénarios suivants :

Scénario 1 : Communications sortantes à partir du runtime d’intégration auto-hébergé exécuté localement derrière le pare-feu d’entreprise

Comment déterminer si vous êtes concerné :

• Vous n’êtes pas concerné si vous définissez des règles de pare-feu basées sur des noms de domaine complets qui utilisent l’approche décrite dans le document Configurations de pare-feu et configuration de la liste d’autorisation pour les adresses IP.

• Vous êtes concerné si vous activez explicitement la liste d’autorisation pour les adresses IP sortantes sur votre pare-feu d’entreprise.

  Si vous êtes concerné, procédez comme suit : avant le 8 novembre 2020, demandez à votre équipe d’infrastructure réseau de mettre à jour votre configuration réseau pour utiliser les adresses IP Data Factory les plus récentes. Pour télécharger les dernières adresses IP, accédez à Découvrir les étiquettes de service à l’aide de fichiers JSON téléchargeables.

Scénario 2 : Communications sortantes à partir du runtime d’intégration auto-hébergé exécuté sur une machine virtuelle Azure au sein d’un réseau virtuel Azure géré par le client

Comment déterminer si vous êtes concerné :

• Vérifiez si vous avez des règles de groupe de sécurité réseau sortantes dans un réseau privé qui contient l’IR auto-hébergé. S’il n’existe aucune restriction sur les communications sortantes, vous n’êtes pas concerné.

• Si vous avez des restrictions sur les règles de trafic sortant, vérifiez si vous utilisez ou non des étiquettes de service. Si vous utilisez des étiquettes de service, vous n’êtes pas concerné. Vous n’avez pas besoin de modifier ni d’ajouter quoi que ce soit, car les nouvelles plages d’adresses IP se trouvent sous les étiquettes de service actuelles.

  

• Vous êtes concerné si vous activez explicitement la liste d’autorisation pour les adresses IP sortantes sur votre paramètre de règles de groupe de sécurité réseau sur le réseau virtuel Azure.

  Si vous êtes concerné, procédez comme suit : avant le 8 novembre 2020, demandez à votre équipe d’infrastructure réseau de mettre à jour les règles de groupe de sécurité réseau sur votre configuration de réseau virtuel Azure pour utiliser les adresses IP les plus récentes de Data Factory. Pour télécharger les dernières adresses IP, accédez à Découvrir les étiquettes de service à l’aide de fichiers JSON téléchargeables.

Scénario 3 : Communications sortantes à partir de SSIS Integration Runtime dans le réseau virtuel Azure géré par le client

Comment déterminer si vous êtes concerné :

• Vérifiez si vous avez des règles de groupe de sécurité réseau sortantes dans un réseau privé qui contient des runtimes d’intégration SQL Server Integration Services (SSIS). S’il n’existe aucune restriction sur les communications sortantes, vous n’êtes pas concerné.

• Si vous avez des restrictions sur les règles de trafic sortant, vérifiez si vous utilisez ou non des étiquettes de service. Si vous utilisez des étiquettes de service, vous n’êtes pas concerné. Vous n’avez pas besoin de modifier ni d’ajouter quoi que ce soit, car les nouvelles plages d’adresses IP se trouvent sous les étiquettes de service actuelles.

• Vous êtes concerné si vous activez explicitement la liste d’autorisation pour les adresses IP sortantes sur votre paramètre de règles de groupe de sécurité réseau sur le réseau virtuel Azure.

  Si vous êtes concerné, procédez comme suit : avant le 8 novembre 2020, demandez à votre équipe d’infrastructure réseau de mettre à jour les règles de groupe de sécurité réseau sur votre configuration de réseau virtuel Azure pour utiliser les adresses IP les plus récentes de Data Factory. Pour télécharger les dernières adresses IP, accédez à Découvrir les étiquettes de service à l’aide de fichiers JSON téléchargeables.

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

• Symptômes

  L’IR auto-hébergé ne peut pas se connecter au service Azure Data Factory ou Azure Synapse.

  Lorsque vous vérifiez le journal des évènements IR auto-hébergé après avoir parcouru Windows>Observateur d’évènements (journaux)>Journaux d’Applications et Services>Integration Runtime, le message d’erreur suivant s’affiche.

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

  La façon la plus simple de vérifier le certificat de serveur du service consiste à ouvrir l’URL du service dans votre navigateur. Par exemple, ouvrez le lien (https://eu.frontend.clouddatahub.net/) Vérifier le certificat du serveur sur l’ordinateur où est installé l’IR auto-hébergé, puis affichez les informations du certificat du 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 l’IR auto-hébergé est installé.
  • Raison 2 : vous utilisez un proxy dans votre environnement et le certificat de serveur du service est remplacé par le proxy, tandis que le certificat de serveur remplacé n’est pas approuvé par l’ordinateur sur lequel l’IR auto-hébergé est installé.

• Ré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 l’IR auto-hébergé est installé.
  • Pour la raison 2 : approuvez l’autorité de certification racine remplacée sur l’ordinateur de l’IR auto-hébergé ou configurez le proxy pour qu’il ne remplace pas le certificat de serveur du service.

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

• Informations supplémentaires
  Nous avons déployé un nouveau certificat SSL, qui est signé à partir de DigiCert. Vérifiez si la racine globale DigiCert G2 se trouve dans l’autorité de certification racine de confiance.

  

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

Contenu connexe

Pour plus d’informations sur la résolution des problèmes, essayez les ressources suivantes :

• Blog Data Factory
• Demandes de fonctionnalités Data Factory
• Vidéos Azure
• Page Microsoft Q&A
• Forum Stack Overflow pour Data Factory
• Informations Twitter sur Data Factory
• Guide de performances des flux de données de mappage