Fehlerbehebung bei der selbstgehosteten Integration Runtime

GILT FÜR: Azure Data Factory Azure Synapse Analytics Microsoft Purview

In diesem Artikel werden allgemeine Problembehandlungsmethoden für selbst gehostete Integrationslaufzeiten (IR) in Azure Data Factory- und Synapse-Arbeitsbereichen beschrieben.

Erfassen von selbstgehosteten Integration Runtime-Protokollen

Azure Data Factory und Azure Synapse Analytics

Wenn bei den Aktivitäten in der selbstgehosteten oder freigegebenen Integration Runtime (IR) Fehler auftreten, unterstützt der Dienst das Anzeigen und Hochladen von Fehlerprotokollen. Befolgen Sie die hier erwähnten Anweisungen, um die Fehlerberichts-ID abzurufen, und geben Sie dann die Berichts-ID ein, um nach verwandten bekannten Problemen zu suchen.

1. Wählen Sie auf der Seite „Überwachen“ für die Dienstbenutzeroberfläche die Funktion Pipeline führt aus.

2. Wählen Sie unter Aktivitätsausführungen in der Spalte Fehler die hervorgehobene Schaltfläche aus, um die Aktivitätsprotokolle anzuzeigen (siehe folgender Screenshot):

   • Azure Data Factory
   • Azure Synapse

   

   Die Aktivitätsprotokolle für die fehlgeschlagene Aktivitätsausführung werden angezeigt.

   

3. Wählen Sie Protokolle senden aus, wenn Sie weitere Hilfe benötigen.

   Das Fenster Protokolle der selbstgehosteten Integration Runtime (IR) für Microsoft freigeben wird geöffnet.

   

4. Wählen Sie die Protokolle aus, die Sie senden möchten.

   • Bei einer selbstgehosteten IR können Sie Protokolle im Zusammenhang mit einer fehlgeschlagenen Aktivität oder alle Protokolle auf dem Knoten der selbstgehosteten IR hochladen.
   • Bei einer freigegebenen IR können Sie nur Protokolle hochladen, die mit der fehlgeschlagenen Aktivität in Zusammenhang stehen.

5. Notieren Sie sich beim Hochladen der Protokolle die Berichts-ID und bewahren Sie sie für später auf, falls Sie weitere Unterstützung bei der Problemlösung benötigen.

   

Microsoft Purview

Bei fehlgeschlagenen Microsoft Purview Aktivitäten, die auf einer selbst gehosteten IR oder freigegebenen IR ausgeführt werden, unterstützt der Dienst das Anzeigen und Hochladen von Fehlerprotokollen aus der Windows Event Viewer.

Sie können alle Fehler nachschlagen, die im folgenden Fehlerleitfaden aufgeführt sind. Um Unterstützungs- und Problembehandlungsanleitungen für SHIR-Probleme zu erhalten, müssen Sie möglicherweise eine Fehlerberichts-ID generieren und den Microsoft-Support kontaktieren.

Gehen Sie wie folgt vor, um die Fehlerberichts-ID für Microsoft Support zu generieren:

1. Bevor Sie einen Scan im Microsoft Purview Governance-Portal starten:

   1. Navigieren Sie zu dem Computer, auf dem die selbst gehostete Integrationslaufzeit installiert ist, und öffnen Sie die Windows Event Viewer.
   2. Löschen Sie die Windows Event Viewer Protokolle im Abschnitt Integration Runtime. Klicken Sie mit der rechten Maustaste auf die Protokolle, und wählen Sie die Option Protokolle löschen aus.
   3. Navigieren Sie zurück zum Microsoft Purview Governance-Portal, und starten Sie den Scan.

2. Sobald der Scan den Status Failed anzeigt, navigieren Sie zurück zur SHIR-VM oder zum Computer, und aktualisieren Sie die Ereignisanzeige im Abschnitt Integration Runtime.

3. Die Aktivitätsprotokolle werden für den fehlgeschlagenen Scan angezeigt.

4. Um weitere Unterstützung von Microsoft zu erhalten, wählen Sie Protokolle senden aus.

   Das Fenster „Teilen Sie die selbstgehosteten Integrationslaufzeitprotokolle (SHIR) mit Microsoft“ wird geöffnet.

   

5. Wählen Sie die Protokolle aus, die Sie senden möchten.

   • Bei einer selbstgehosteten IR können Sie Protokolle im Zusammenhang mit einer fehlgeschlagenen Aktivität oder alle Protokolle auf dem Knoten der selbstgehosteten IR hochladen.
   • Bei einer freigegebenen IR können Sie nur Protokolle hochladen, die mit der fehlgeschlagenen Aktivität in Zusammenhang stehen.

6. Notieren Sie sich beim Hochladen der Protokolle die Berichts-ID und bewahren Sie sie für später auf, falls Sie weitere Unterstützung bei der Problemlösung benötigen.

   

Allgemeiner Ausfall oder Fehler bei selbstgehosteter IR

Arbeitsspeicherproblem

• Symptome

  Ein Fehler vom Typ „OutOfMemoryException“ (OOM) tritt auf, wenn Sie versuchen, mit einer verknüpften oder selbstgehosteten IR eine Lookup-Aktivität auszuführen.

• Ursache

  Eine neue Aktivität kann einen OOM-Fehler auslösen, wenn auf dem IR-Computer eine vorübergehende hohe Speicherauslastung auftritt. Das Problem wird möglicherweise durch eine große Anzahl gleichzeitiger Aktivitäten verursacht. Der Fehler ist systembedingt.

• Lösung

  Überprüfen Sie die Ressourcennutzung und gleichzeitige Aktivitätsausführung auf dem IR-Knoten. Passen Sie die interne und die Auslösezeit von Aktivitätsausführungen an, um zu viele gleichzeitige Ausführungen auf einem einzelnen IR-Knoten zu vermeiden.

Problem mit der Begrenzung von gleichzeitigen Aufträgen

• Symptome

  Wenn Sie versuchen, auf der Benutzeroberfläche den Grenzwert für gleichzeitige Aufträge zu erhöhen, bleibt der Vorgang im Status Wird aktualisiert hängen.

  Beispielszenario: Der Höchstwert für gleichzeitige Aufträge ist aktuell auf „24“ festgelegt, und Sie möchten die Anzahl erhöhen, damit Aufträge schneller ausgeführt werden können. Der Mindestwert, den Sie eingeben können, ist „3“, und der Höchstwert beträgt „32“. Sie erhöhen den Wert von 24 auf 32 und wählen dann die Schaltfläche Aktualisieren aus. Der Prozess bleibt in Status Wird aktualisiert hängen, wie aus dem folgenden Screenshot hervorgeht. Sie aktualisieren die Seite, und es wird immer noch der Wert 24 angezeigt. Es wurde nicht wie erwartet auf 32 aktualisiert.

  

• Ursache

  Der Grenzwert für die Anzahl gleichzeitiger Aufträge hängt vom logischen Kern des Computers und vom Arbeitsspeicher ab. Versuchen Sie, den Wert in einen niedrigeren Wert (z. B. 24) zu ändern, und zeigen Sie dann das Ergebnis an.

  Tipp

  • Weitere Informationen zur Anzahl der Logikkerne und zum Ermitteln der Logikkernanzahl Ihres Computers finden Sie unter Four Wege, um die Anzahl der Kerne in Ihrer CPU auf Windows 10 zu ermitteln.
  • Informationen zum Berechnen der Math.log-Funktion finden Sie im Logarithmusrechner.

Problem beim SSL-Zertifikat für die Hochverfügbarkeit der selbstgehosteten IR

• Symptome

  Der Arbeitsknoten der selbstgehosteten IR hat den folgenden Fehler gemeldet:

  „Fehler beim Abrufen der Freigabezustände vom primären Knoten net.tcp://abc.cloud.corp.Microsoft.com:8060/ExternalService.svc/. Aktivitäts-ID: XXXXX Fehler beim Erstellen der X.509-Zertifikatskette CN=abc.cloud.corp.Microsoft.com, OU=test, O=Microsoft. Das Zertifikat, das verwendet wurde, besitzt eine Vertrauenswürdigkeitskette, die nicht überprüft werden kann. Ersetzen Sie das Zertifikat, oder ändern Sie certificateValidationMode. Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war.“

• Ursache

  Bei der Behandlung von Fällen im Zusammenhang mit dem SSL/TLS-Handshake können einige Probleme bei der Überprüfung der Zertifikatskette auftreten.

• Lösung

  • Nachstehend finden Sie eine schnelle und intuitive Möglichkeit zum Beheben von Fehlern beim Erstellen einer X.509-Zertifikatkette:

    1. Exportieren Sie das Zertifikat, das überprüft werden muss. Führen Sie hierzu folgende Schritte aus:

       a) Wählen Sie in Windows Start, beginnen Sie mit der Eingabe von certificates, und wählen Sie dann Manage Computerzertifikate aus.

       b. Suchen Sie im Datei-Explorer im linken Bereich nach dem Zertifikat, das Sie überprüfen möchten. Klicken Sie mit der rechten Maustaste darauf, und wählen Sie dann Alle Tasks>Exportieren aus.

       

    2. Kopieren Sie das exportierte Zertifikat auf den Clientcomputer.

    3. Führen Sie clientseitig in einem Eingabeaufforderungsfenster den folgenden Befehl aus: Achten Sie darauf, <certificate path> und <output txt file path> durch die tatsächlichen Pfade zu ersetzen.

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

       Beispiel:

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

    4. Überprüfen Sie die TXT-Ausgabedatei auf Fehler. Die Fehlerübersicht finden Sie am Ende der TXT-Datei.

       Beispiel:

       

       Wenn am Ende der Protokolldatei kein Fehler angezeigt wird (siehe folgender Screenshot), können Sie davon ausgehen, dass die Zertifikatkette auf dem Clientcomputer erfolgreich erstellt wurde.

       

  • Wenn in der Zertifikatdatei die Dateinamenerweiterungen AIA (Authority Information Access), CDP (CRL Distribution Point) oder OCSP (Online Certificate Status Protocol) konfiguriert sind, können Sie eine intuitivere Überprüfung vornehmen:

    1. Rufen Sie diese Informationen ab, indem Sie die Zertifikatdetails überprüfen (siehe folgender Screenshot):

       

    2. Führen Sie den folgenden Befehl aus. Achten Sie darauf, <certificate path> durch den tatsächlichen Pfad des Zertifikats zu ersetzen.

         Certutil   -URL    <certificate path> 
       

       Das URL-Abrufprogramm wird geöffnet.

    3. Wählen Sie Abrufen aus, um Zertifikate mit den Dateinamenerweiterungen AIA, CDP und OCSP zu überprüfen.

       

       Die Zertifikatkette wurde erfolgreich erstellt, wenn der Zertifikatstatus von AIA Überprüft und der Zertifikatstatus von CDP oder OCSP ebenfalls Überprüft lautet.

       Wenn beim Abrufen von AIA oder CDP ein Fehler auftritt, wenden Sie sich an das Netzwerkteam, um den Clientcomputer zum Verbinden mit der Ziel-URL einzurichten. Es reicht aus, wenn entweder der HTTP-Pfad oder der LDAP-Pfad (Lightweight Directory Access Protocol) überprüft werden kann.

Selbstgehostete IR konnte Datei oder Assembly nicht laden

• Symptome

  Es wird folgende Fehlermeldung angezeigt:

  „Die Datei oder Assembly 'XXXXXXXXXXXXXXXX, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' oder eine Abhängigkeit davon konnte nicht geladen werden. Die angegebene Datei wurde nicht gefunden. Aktivitäts-ID: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3“

  Nachstehend eine genauere Fehlermeldung:

  "Die Datei oder Assembly 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' oder eine Abhängigkeit davon konnte nicht geladen werden. Die angegebene Datei wurde nicht gefunden. Aktivitäts-ID: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3“

• Ursache

  In Process Monitor können Sie folgendes Ergebnis anzeigen:

  

  Tipp

  In Process Monitor können Sie Filter festlegen (siehe folgender Screenshot).

  Die obige Fehlermeldung besagt, dass sich das DLL System.ValueTuple nicht im zugehörigen Global Assembly Cache (GAC) Ordner befindet, im Ordner C:\Programme\Microsoft Integration Runtime\4.0\Gateway oder im Ordner C:\Programme\Microsoft Integration Runtime\4.0\Shared Ordner.

  Grundsätzlich lädt der Prozess die DLL zuerst aus dem Ordner GAC, dann aus dem Ordner Shared und schließlich aus dem Ordner Gateway. Daher können Sie die DLL aus jedem Pfad laden, der hilfreich ist.

  

• Lösung

  Sie finden die Datei System.ValueTuple.dll im Ordner C:\Programme\Microsoft Integration Runtime\4.0\Gateway\DataScan. Um das Problem zu beheben, kopieren Sie die Datei System.ValueTuple.dll in den Ordner C:\Programme\Microsoft Integration Runtime\4.0\Gateway.

  Mit derselben Methode können Sie andere Probleme mit fehlenden Dateien oder Assemblys beheben.

• Weitere Informationen zu diesem Problem

  Der Grund, warum die System.ValueTuple.dll unter %windir%\Microsoft.NET\assembly und %windir%\assembly angezeigt wird, besteht darin, dass dies ein .NET Verhalten ist.

  Beim folgenden Fehler können Sie deutlich erkennen, dass die Assembly System.ValueTuple fehlt. Dieses Problem tritt auf, wenn die Anwendung versucht, die Assembly System.ValueTuple.dll zu überprüfen.

  <LogProperties><Fehlerinformation>[{"Code":0,"Message":"Der Typinitialisierer für 'Npgsql.PoolManager' hat eine Ausnahme ausgelöst.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.TypeInitializationException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[{"Code":0,"Message":"Datei oder Assembly 'System.ValueTuple, Version=4.0.2.0, konnte nicht geladen werden, Culture=neutral, PublicKeyToken=XXXXXXX' oder eine seiner Abhängigkeiten. Das System kann die angegebene Datei nicht finden.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.IO.FileNotFoundException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[]}]]/<ErrorInfo></LogProperties>"

  Weitere Informationen zu GAC finden Sie unter Global Assembly Cache.

Fehlender Authentifizierungsschlüssel für selbstgehostete Integration Runtime

• Symptome

  Die selbstgehostete Integration Runtime wird plötzlich ohne Authentifizierungsschlüssel offline geschaltet, und im Ereignisprotokoll wird die folgende Fehlermeldung angezeigt:

  „Der Authentifizierungsschlüssel wurde noch nicht zugewiesen.“

  

• Ursache

  • Der selbstgehostete IR-Knoten oder die logische selbstgehostete IR im Azure-Portal wurde gelöscht.
  • Es wurde eine saubere Deinstallation durchgeführt.

• Lösung

  Wenn keine der vorstehenden Ursachen zutrifft, können Sie zum Ordner %programdata%\Microsoft\Data Transfer\DataManagementGateway wechseln, um festzustellen, ob die Datei Configurations gelöscht wurde. Wenn sie gelöscht wurde, folgen Sie den Anweisungen im Netwrix-Artikel Detect, der eine Datei von Ihren Windows Dateiservern gelöscht hat.

  

Zwei lokale Datenspeicher können mit der selbstgehosteten IR nicht überbrückt werden

• Symptome

  Nachdem Sie selbstgehostete IRs für Quell- und Zieldatenspeicher erstellt haben, möchten Sie die beiden IRs miteinander verbinden, um eine Kopieraktivität abzuschließen. Wenn die Datenspeicher in verschiedenen virtuellen Netzwerken konfiguriert wurden oder den Gatewaymechanismus nicht verstehen können, wird einer der folgenden Fehler ausgegeben:

  • „Der Treiber der Quelle wurde in der Ziel-IR nicht gefunden“
  • „Die Ziel-IR kann nicht auf die Quelle zugreifen“

• Ursache

  Die selbstgehostete IR ist als zentraler Knoten für eine Kopieraktivität konzipiert und nicht als Client-Agent, der für jeden Datenspeicher installiert werden muss.

  In diesem Fall sollte der verknüpfte Dienst für jeden Datenspeicher mit derselben IR erstellt werden, und die IR sollte über das Netzwerk auf beide Datenspeicher zugreifen können. Es spielt keine Rolle, ob die IR im Quell- oder Zieldatenspeicher oder auf einem dritten Computer installiert wird. Wenn zwei verknüpfte Dienste mit unterschiedlichen IRs erstellt, aber in derselben Kopieraktivität verwendet werden, wird die Ziel-IR verwendet, und Sie müssen die Treiber für beide Datenspeicher auf dem Ziel-IR-Computer installieren.

• Lösung

  Installieren Sie Treiber für den Quell- und Zieldatenspeicher in der Ziel-IR, und stellen Sie sicher, dass diese auf den Quelldatenspeicher zugreifen kann.

  Wenn der Datenverkehr das Netzwerk zwischen zwei Datenspeichern (die z. B. in zwei virtuellen Netzwerken konfiguriert wurden) nicht durchlaufen kann, können Sie den Kopiervorgang in einer Aktivität eventuell auch dann nicht beenden, wenn die IR installiert wurde. Wenn Sie den Kopiervorgang in einer einzelnen Aktivität nicht beenden können, können Sie zwei Kopieraktivitäten mit zwei IRs (jeweils in einem VNET) erstellen:

  • Kopiere eine IR vom Datenspeicher 1 in Azure Blob Storage
  • Kopieren Sie eine andere IR aus Azure Blob Storage in den Datenspeicher 2.

  Diese Lösung könnte die Anforderung simulieren, die IR zum Erstellen einer Brücke zu verwenden, die zwei getrennte Datenspeicher miteinander verbindet.

Synchronisierungsproblem bei Anmeldeinformationen führt zum Verlust von Anmeldeinformationen beim Hochverfügbarkeitsmodus

• Symptome

  Wenn die Anmeldeinformationen „XXXXXXXXXX“ für die Datenquelle aus dem aktuellen Integration Runtime-Knoten mit Nutzlast gelöscht werden, erhalten Sie die folgende Fehlermeldung:

  "Wenn Sie den Linkdienst im Azure Portal löschen oder die Aufgabe die falsche Nutzlast hat, erstellen Sie erneut einen neuen Linkdienst mit Ihren Anmeldeinformationen."

• Ursache

  Die selbstgehostete IR wird im Hochverfügbarkeitsmodus mit zwei Knoten erstellt, die Anmeldeinformationen auf den Knoten sind jedoch nicht synchronisiert. Dies bedeutet, dass die im Verteilerknoten gespeicherten Anmeldeinformationen nicht mit anderen Workerknoten synchronisiert werden. Wenn ein Failover vom Verteilerknoten zum Workerknoten erfolgt, die Anmeldeinformationen aber nur im bisherigen Verteilerknoten vorhanden sind, schlägt der Task beim Versuch eines Zugriffs auf die Anmeldeinformationen fehl, und der vorstehende Fehler wird angezeigt.

• Lösung

  Die einzige Möglichkeit zur Vermeidung dieses Problems besteht darin sicherzustellen, dass die Anmeldeinformationen auf den beiden Knoten stets synchron sind. Wenn sie nicht synchron sind, müssen Sie die Anmeldeinformationen für den neuen Verteiler erneut eingeben.

Das Zertifikat kann nicht ausgewählt werden, da der private Schlüssel fehlt

• Symptome

  • Sie haben eine PFX-Datei in den Zertifikatspeicher importiert.

  • Wenn Sie das Zertifikat über die IR-Configuration Manager UI ausgewählt haben, wurde die folgende Fehlermeldung angezeigt:

    „Der Verschlüsselungsmodus für die Intranetkommunikation konnte nicht geändert werden. Es ist wahrscheinlich, dass das Zertifikat „<Zertifikatsname>“ keinen privaten Schlüssel besitzt, der für den Schlüsselaustausch geeignet ist, oder der Prozess verfügt möglicherweise nicht über Zugriffsrechte für den privaten Schlüssel. Weitere Details finden Sie in der inneren Ausnahme.

• Ursache

  • Das Benutzerkonto verfügt über eine niedrige Berechtigungsstufe und kann nicht auf den privaten Schlüssel zugreifen.
  • Das Zertifikat wurde als Signatur, nicht als Schlüsselaustausch generiert.

• Lösung

  • Verwenden Sie ein Konto mit entsprechenden Berechtigungen für den Zugriff auf den privaten Schlüssel, um die Benutzeroberfläche verwenden zu können.

  • Importieren Sie das Zertifikat mithilfe des folgenden Befehls:

    certutil -importpfx FILENAME.pfx AT_KEYEXCHANGE
    

Synchronisierungsproblem bei Knoten der selbstgehosteten Integration Runtime

• Symptome

  Knoten der selbstgehosteten Integrationslaufzeit versuchen, die Anmeldedaten zwischen den Knoten zu synchronisieren, aber der Vorgang bleibt stecken und nach einiger Zeit wird die folgende Fehlermeldung angezeigt:

  "Der Knoten Integration Runtime (selbst gehostet) versucht, die Anmeldeinformationen über Knoten hinweg zu synchronisieren. Dieser Vorgang kann einige Minuten dauern.“

  Hinweis

  Wenn dieser Fehler länger als 10 Minuten dauert, überprüfen Sie die Konnektivität mit dem Verteilerknoten.

• Ursache

  Der Grund dafür ist, dass die Workerknoten keinen Zugriff auf die privaten Schlüssel haben. Dies kann anhand der folgenden Protokolle der selbstgehosteten Integration Runtime bestätigt werden:

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

  Wenn Sie die Dienstprinzipalauthentifizierung im verknüpften Dienst verwenden, tritt kein Problem beim Synchronisierungsprozess auf. Sobald Sie jedoch den Authentifizierungstyp in den Kontoschlüssel ändern, beginnt das Synchronisierungsproblem. Dies liegt daran, dass der selbstgehostete Integration Runtime-Dienst unter einem Dienstkonto (NT SERVICE\DIAHostService) ausgeführt wird und den Berechtigungen für den privaten Schlüssel hinzugefügt werden muss.

• Lösung

  Um dieses Problem zu beheben, müssen Sie den Berechtigungen für den privaten Schlüssel das Dienstkonto für die selbstgehostete Integration Runtime (NT SERVICE\DIAHostService) hinzufügen. Sie können die folgenden Schritte ausführen:

  1. Öffnen Sie den Befehl "Microsoft Management Console ausführen" (MMC).

     

  2. Führen Sie im MMC-Bereich die folgenden Schritte aus:

     

     1. Wählen Sie Datei aus.
     2. Wählen Sie im Dropdownmenü den Eintrag Snap-In hinzufügen/entfernen aus.
     3. Wählen Sie im Bereich „Verfügbare Snap-Ins“ die Option Zertifikate aus.
     4. Wählen Sie Hinzufügen.
     5. Wählen Sie im Popupbereich „Zertifikat-Snap-In“ die Option Computerkonto aus.
     6. Wählen Sie Weiter aus.
     7. Wählen Sie im Bereich „Computer auswählen“ die Option Lokaler Computer: (Computer, auf dem diese Konsole ausgeführt wird) aus.
     8. Wählen Sie Fertig stellen aus.
     9. Klicken Sie im Bereich „Snap-Ins hinzufügen oder entfernen“ auf OK.

  3. Führen Sie dann im MMC-Bereich die folgenden Schritten aus:

     

     1. Wählen Sie in der linken Ordnerliste die Optionen Konsolenstamm -> Zertifikate (Lokaler Computer) -> Persönlich -> Zertifikate aus.
     2. Klicken Sie mit der rechten Maustaste auf die Microsoft Intune Beta MDM.
     3. Wählen Sie in der Dropdownliste den Eintrag Alle Aufgaben aus.
     4. Wählen Sie Private Schlüssel verwalten aus.
     5. Wählen Sie unter „Gruppen- oder Benutzernamen“ die Option Hinzufügen aus.
     6. Wählen Sie NT SERVICE\DIAHostService aus, um dem Konto Vollzugriff auf dieses Zertifikat zu gewähren. Übernehmen und speichern Sie die Änderung.
     7. Wählen Sie Namen überprüfen aus, und klicken Sie dann auf OK.
     8. Wählen Sie im Bereich „Berechtigungen“ die Option Übernehmen aus, und klicken Sie dann auf OK.

Fehlermeldung "UserErrorJreNotFound", wenn Sie eine Kopieraktivität nach Azure ausführen

• Symptome

  Wenn Sie versuchen, Inhalte mithilfe eines Java-basierten Tools oder Programms (z. B. Kopieren von ORC- oder Parkettformatdateien) in Microsoft Azure zu kopieren, wird eine Fehlermeldung angezeigt, die wie folgt aussieht:

  ErrorCode=UserErrorJreNotFound,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Java Runtime Environment nicht gefunden. Wechseln Sie zu http://go.microsoft.com/fwlink/?LinkId=808605, um sie auf Ihrem Integration Runtime -Knotencomputer (selbst gehostet) herunterzuladen und zu installieren. Hinweis: Für eine 64-Bit-Version von Integration Runtime ist die 64-Bit-JRE erforderlich, für eine 32-Bit-Version von Integration Runtime die 32-Bit-JRE.,Source=Microsoft.DataTransfer.Common,''Type=System.DllNotFoundException,Message=Die DLL 'jvm.dll' kann nicht geladen werden: Das angegebene Modul wurde nicht gefunden. (Ausnahme von HRESULT: 0x8007007E),Source=Microsoft. DataTransfer.Richfile.HiveOrcBridge

• Ursache

  Dieses Problem tritt aus einem der folgenden Gründe auf:

  • Java Runtime Environment (JRE) ist auf Ihrem Integration Runtime Server nicht ordnungsgemäß installiert.

  • Ihr Integration Runtime Server fehlt an der erforderlichen Abhängigkeit für JRE.

  Standardmäßig löst Integration Runtime den JRE-Pfad mithilfe von Registrierungseinträgen auf. Diese Einträge sollten während der JRE-Installation automatisch festgelegt werden.

• Lösung

  Folgen Sie den Schritten in diesem Abschnitt sorgfältig. Wird die Registrierung falsch angepasst, können schwerwiegende Probleme auftreten. Bevor Sie sie ändern, sichern Sie die Registrierung zwecks Wiederherstellung für den Fall, dass Probleme auftreten.

  Zur Behebung dieses Problems führen Sie die folgenden Schritte aus, um den Status der JRE-Installation zu überprüfen:

  1. Stellen Sie sicher, dass Integration Runtime (Diahost.exe) und JRE auf derselben Plattform installiert sind. Überprüfen Sie die folgenden Punkte:

     • 64-Bit-JRE für das 64-Bit-ADF-Integrationslaufzeitmodul soll im Ordner installiert werden: C:\Program Files\Java\

       Hinweis

       Der Ordner ist nicht C:\Program Files (x86)\Java\

     • Java Runtime (JRE) ist Version 11 oder höher, von einem JRE-Anbieter wie Microsoft OpenJDK 11 oder Eclipse Temurin 11. Stellen Sie sicher, dass die JAVA_HOME-Systemumgebungsvariable auf den JDK-Ordner (und nicht nur den JRE-Ordner) zeigt. Möglicherweise müssen Sie außerdem den Bin-Ordner der PATH-Umgebungsvariablen Ihres Systems hinzufügen.

  2. Überprüfen Sie die Registrierung auf die entsprechenden Einstellungen. Gehen Sie hierzu folgendermaßen vor:

     1. Geben Sie im Menü Ausführen die Zeichenfolge Regedit ein, und drücken Sie dann die EINGABETASTE.

     2. Suchen Sie im Navigationsbereich nach dem folgenden Unterschlüssel:

        HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment.

        Im Bereich Details sollte ein Eintrag „CurrentVersion“ angezeigt werden, der die JRE-Version angibt (z. B. 1.8).

        

     3. Suchen Sie im Navigationsbereich einen Unterschlüssel, der genau mit der Version (z. B. 1.8) im JRE-Ordner übereinstimmt. Im Detailbereich sollte ein Eintrag JavaHome enthalten sein. Der Wert dieses Eintrags ist der JRE-Installationspfad.

        

  3. Suchen Sie den Ordner „bin\server“ im folgenden Pfad:

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

     

  4. Überprüfen Sie, ob dieser Ordner eine Datei „jvm.dll“ enthält. Wenn das nicht der Fall ist, suchen Sie im Ordner bin\client nach der Datei.

     

  Hinweis

  • Wenn eine dieser Konfigurationen nicht den Beschreibungen in diesen Schritten entspricht, verwenden Sie den JRE-Windows Installer, um die Probleme zu beheben.
  • Wenn alle Konfigurationen wie in diesen Schritten beschrieben sind, fehlt möglicherweise eine VC++-Laufzeitbibliothek im System. Sie können dieses Problem beheben, indem Sie VC++ 2010 Redistributable Package installieren.

Einrichten der selbstgehosteten IR

Integrations-Runtime-Registrierungsfehler

• Symptome

  Möglicherweise möchten Sie gelegentlich aus einem der folgenden Gründe eine selbstgehostete IR in einem anderen Konto ausführen:

  • Die Unternehmensrichtlinie lässt das Dienstkonto nicht zu.
  • Eine Authentifizierung ist erforderlich.

  Nachdem Sie das Dienstkonto im Dienstbereich geändert haben, stellen Sie möglicherweise fest, dass die Integration Runtime nicht mehr funktioniert, und Sie erhalten die folgende Fehlermeldung:

  „Bei dem Knoten von Integration Runtime (selbstgehostet) ist bei der Registrierung ein Fehler aufgetreten. Es kann keine Verbindung mit dem Integration Runtime (selbst gehosteten) Hostdienst hergestellt werden."

  

• Ursache

  Viele Ressourcen werden ausschließlich dem Servicekonto zugewiesen. Wenn Sie das Dienstkonto in ein anderes Konto ändern, bleiben die Berechtigungen für alle abhängigen Ressourcen unverändert erhalten.

• Lösung

  Navigieren Sie zum Integration Runtime-Ereignisprotokoll, um den Fehler zu überprüfen.

  

  • Wenn der Fehler im Ereignisprotokoll „UnauthorizedAccessException“ lautet, führen Sie folgende Schritte aus:

    1. Überprüfen Sie das DIAHostService Anmeldedienstkonto im Windows-Dienstbereich.

       

    2. Überprüfen Sie, ob das Anmeldedienstkonto Über Lese-/Schreibberechtigungen für den Ordner %programdata%\Microsoft\DataTransfer\DataManagementGateway verfügt.

       • Standardmäßig sollte das Dienstanmeldekonto Lese-/Schreibberechtigung haben, falls es nicht geändert wurde.

         

       • Wenn Sie das Dienstanmeldekonto geändert haben, führen Sie die folgenden Schritte zur Behebung des Problems aus:

         a) Führen Sie eine saubere Deinstallation der aktuellen selbstgehosteten IR durch.
         b. Installieren Sie die Bits der selbstgehosteten IR.
         c. Ändern Sie das Dienstkonto mit folgenden Schritten:

         i. Wechseln Sie zum selbst gehosteten IR-Installationsordner, und wechseln Sie dann zum Ordner Microsoft Integration Runtime\4.0\Shared.
         ii. Öffnen Sie mit erhöhten Rechten ein Eingabeaufforderungsfenster. Ersetzen Sie <user> und <password> durch Ihren eigenen Benutzernamen und Ihr eigenes Kennwort, und führen Sie dann den folgenden Befehl aus:
         dmgcmd.exe -SwitchServiceAccount "<user>" "<password>"
         iii. Wenn Sie zum Konto „LocalSystem“ wechseln möchten, müssen Sie für dieses Konto das richtige Format verwenden: dmgcmd.exe -SwitchServiceAccount "NT Authority\System" ""
         Verwenden Sie keinesfalls das Format dmgcmd.exe -SwitchServiceAccount "LocalSystem" "".
         iv. Da das Konto „LocalSystems“ höhere Berechtigungen als der Administrator hat, können Sie es optional auch direkt in „Dienste“ ändern.
         v. Sie können einen lokalen Benutzer/Domänenbenutzer für das IR-Dienstanmeldekonto verwenden.

         d. Registrieren Sie die Integration Runtime.

  • Wenn der Fehler „Der Dienst ‚Integration Runtime Service‘ (DIAHostService) konnte nicht gestartet werden. Überprüfen Sie, ob Sie ausreichende Berechtigungen zum Starten von Systemdiensten besitzen, und gehen Sie dann wie folgt vor:

    1. Überprüfen Sie das DIAHostService Anmeldedienstkonto im Windows-Dienstbereich.

       

    2. Überprüfen Sie, ob das Anmeldedienstkonto Log on as a service Berechtigung zum Starten des Windows Diensts hat:

       

• Weitere Informationen

  Wenn keines der beiden vorherigen Auflösungsmuster in Ihrem Fall zutrifft, versuchen Sie, die folgenden Windows Ereignisprotokolle zu erfassen:

  • Anwendungs- und Dienstprotokolle > Integration Runtime
  • Windows-Protokolle > Anwendung

Schaltfläche „Registrieren“ zum Registrieren einer selbstgehosteten IR wurde nicht gefunden

• Symptome

  Wenn Sie eine selbst gehostete IR registrieren, wird die Schaltfläche Register nicht im bereich Configuration Manager angezeigt.

  

• Ursache

  Ab der Veröffentlichung von Integration Runtime 3.0 wurde die Schaltfläche Register auf vorhandenen integration runtime Knoten entfernt, um eine übersichtlichere und sicherere Umgebung zu ermöglichen. Wenn ein Knoten für eine Integration Runtime registriert wurde (ganz gleich, ob online oder nicht), müssen Sie ihn bei einer anderen Integration Runtime registrieren. Dazu müssen Sie den bisherigen Knoten deinstallieren, anschließend neu installieren und dann registrieren.

• Lösung

  1. Deinstallieren Sie in Control Panel die vorhandene Integrationslaufzeit.

     Wichtig

     Wählen Sie Ja im folgenden Prozess aus. Bewahren Sie beim Deinstallationsvorgang keine Daten auf.

     

  2. Wenn Sie keine MSI-Installationsdatei für die Integration Runtime haben, wechseln Sie zum Download Center, um die aktuelle Integration Runtime herunterzuladen.

  3. Installieren Sie die MSI-Datei, und registrieren Sie die Integration Runtime.

Die selbstgehostete IR kann aufgrund von Localhost nicht registriert werden

• Symptome

  Die selbstgehostete IR kann bei Verwendung von „get_LoopbackIpOrName“ auf einem neuen Computer nicht registriert werden.

  Debug: Ein Laufzeitfehler ist aufgetreten. Der Typinitialisierer für 'Microsoft.DataTransfer.DIAgentHost.DataSourceCache' hat eine Ausnahme ausgelöst. Beim Datenbankaufruf ist ein nicht behebbarer Fehler aufgetreten.

  Ausnahmedetail: System.TypeInitializationException: Der Typinitializer für 'Microsoft. DataTransfer.DIAgentHost.DataSourceCache' hat eine Ausnahme ausgelöst. ---> System.Net.Sockets.SocketException: Bei einer Datenbanksuche unter „System.Net.Dns.GetAddrInfo(Zeichenfolgenname)“ ist ein nicht wiederherstellbarer Fehler aufgetreten.

• Ursache

  Das Problem tritt normalerweise auf, wenn Localhost aufgelöst wird.

• Lösung

  Verwenden Sie zum Hosten der Datei und zum Beheben des Problems die Localhost-IP-Adresse 127.0.0.1.

Fehler beim selbstgehosteten Setup

• Symptome

  Sie können weder eine vorhandene IR deinstallieren, noch eine neue IR installieren oder eine vorhandene IR auf eine neue IR aktualisieren.

• Ursache

  Die Integrationslaufzeitinstallation hängt vom Windows Installer-Dienst ab. Installationsprobleme treten möglicherweise aus folgenden Gründen auf:

  • Es steht nicht genügend Speicherplatz zur Verfügung
  • Fehlende Berechtigungen
  • Der Windows NT-Dienst ist gesperrt.
  • Die CPU-Auslastung ist zu hoch
  • Die MSI-Datei wird in einem langsamen Netzwerkspeicherort gehostet
  • Es wurde versehentlich auf einige Systemdateien oder Registrierungen zugegriffen

Das IR-Dienstkonto konnte nicht auf das Zertifikat zugreifen.

• Symptome

  Wenn Sie eine selbst gehostete IR über Microsoft Integration Runtime Configuration Manager installieren, wird ein Zertifikat mit einer vertrauenswürdigen Zertifizierungsstelle generiert. Das Zertifikat konnte nicht angewendet werden, um die Kommunikation zwischen zwei Knoten zu verschlüsseln, und die folgende Fehlermeldung wird angezeigt:

  „Fehler beim Ändern des Kommunikationsverschlüsselungsmodus des Intranets: Dem Integration Runtime-Dienstkonto konnte der Zugriff auf das Zertifikat <Zertifikatname> nicht gewährt werden. Fehlercode 103“

• Ursache

  Das Zertifikat verwendet Speicher von Schlüsselspeicheranbietern (KSP-Speicher), der noch nicht unterstützt wird. Bisher unterstützt die selbstgehostete IR nur Speicher von Kryptografiedienstanbietern (CSP-Speicher).

• Lösung

  In diesem Fall wird die Verwendung von CSP-Zertifikaten empfohlen.

  Lösung 1

  Importieren Sie das Zertifikat mithilfe des folgenden Befehls:

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

  

  Lösung 2

  Konvertieren Sie das Zertifikat mit den folgenden Befehlen:

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

  Vor und nach der Konvertierung:

  

  

Selbstgehostete Integration Runtime, Version 5.x

Für das Upgrade auf Version 5.x der selbst gehosteten Integrationslaufzeit benötigen wir .NET Framework Runtime 4.7.2 oder höher. Auf der Downloadseite befinden sich Downloadlinks für die aktuelle 4.x-Version und die beiden neuen 5.x-Versionen.

Für Azure Data Factory v2- und Azure Synapse-Kunden:

• Wenn das automatische Update aktiviert ist und Sie Ihre .NET Framework-Runtime bereits auf 4.7.2 oder höher aktualisiert haben, wird die selbst gehostete Integrationslaufzeit automatisch auf die neueste Version von 5.x aktualisiert.
• Wenn das automatische Update aktiviert ist und Sie Ihre .NET Framework-Runtime nicht auf 4.7.2 oder höher aktualisiert haben, wird die selbst gehostete Integrationslaufzeit nicht automatisch auf die neueste Version von 5.x aktualisiert. Die selbstgehostete Integration Runtime bleibt in der aktuellen Version 4.x. Sie können eine Warnung für ein .NET Framework-Runtime-Upgrade im Portal und den selbst gehosteten Integrations-Runtime-Client sehen.
• Wenn das automatische Update deaktiviert ist und Sie Ihre .NET Framework-Runtime bereits auf 4.7.2 oder höher aktualisiert haben, können Sie die neueste Version von 5.x manuell herunterladen und auf Ihrem Computer installieren.
• Wenn die automatische Aktualisierung deaktiviert ist und Sie ihr .NET Framework Runtime nicht auf 4.7.2 oder höher aktualisiert haben. Wenn Sie versuchen, die selbst gehostete Integrationslaufzeit 5.x manuell zu installieren und den Schlüssel zu registrieren, müssen Sie zuerst ihre .NET Framework-Runtime-Version aktualisieren.

Konnektivitätsprobleme bei der selbstgehosteten Integration Runtime

Die selbstgehostete Integration Runtime kann keine Verbindung zum Clouddienst herstellen

• Symptome

  Wenn Sie versuchen, die selbst gehostete Integrationslaufzeit zu registrieren, zeigt Configuration Manager die folgende Fehlermeldung an:

  "Der Integration Runtime (Selbst gehosteter) Knoten hat während der Registrierung einen Fehler festgestellt."

  

• Ursache

  Die selbstgehostete Integration Runtime kann keine Verbindung zum Backenddienst herstellen. Dieses Problem wird in der Regel durch Netzwerkeinstellungen in der Firewall verursacht.

• Lösung

  1. Überprüfen Sie, ob der Integration Runtime-Dienst ausgeführt wird. Wenn ja, fahren Sie mit Schritt 2 fort.

     

  2. Wenn kein Proxy für die selbstgehostete Integration Runtime konfiguriert ist (Standardeinstellung), führen Sie den folgenden PowerShell-Befehl auf dem Computer aus, auf dem die selbstgehostete Integration Runtime installiert ist:

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

     Hinweis

     Die Dienst-URL kann je nach Speicherort Ihrer Azure Data Factory- oder Synapse-Arbeitsbereichsinstanz variieren. Um die Dienst-URL zu finden, verwenden Sie die Seite „Verwalten der Benutzeroberfläche“ in Ihrer Data Factory- oder Azure Synapse-Instanz, um Integration Runtimes zu suchen. Klicken Sie auf Ihre selbstgehostete IR, um sie zu bearbeiten. Wählen Sie dort die Registerkarte Knoten aus und klicken Sie auf Dienst-URLs anzeigen.

     Die folgende Antwort wird erwartet:

     

  3. Wenn Sie nicht die erwartete Antwort erhalten, verwenden Sie je nach Bedarf eine der folgenden Methoden:

     • Wenn Sie die Meldung erhalten, dass der Remotename nicht aufgelöst werden konnte, gibt es ein Problem mit dem Domain Name System (DNS). Wenden Sie sich an das Netzwerkteam, um dieses Problem zu beheben.
     • Wenn Sie eine Meldung erhalten, dass das SSL/TLS-Zertifikat nicht vertrauenswürdig ist, überprüfen Sie das Zertifikat (https://wu2.frontend.clouddatahub.net/), ob es auf dem Computer als vertrauenswürdig gilt, und installieren Sie dann mithilfe des Zertifikat-Managers das öffentliche Zertifikat. Durch diese Aktion sollte das Problem behoben werden.
     • Wechseln Sie zu Windows>Event viewer (logs)>Applications and Services Logs>Integration Runtime, und überprüfen Sie, ob ein Fehler auftritt, der durch DNS, eine Firewallregel verursacht wird, oder Unternehmensnetzwerkeinstellungen. Wenn Sie einen solchen Fehler finden, müssen Sie die Verbindung zwangsweise beenden. Da jedes Unternehmen über seine eigenen angepassten Netzwerkeinstellungen verfügt, wenden Sie sich an das Netzwerkteam, um diese Probleme zu beheben.

  4. Wenn „Proxy“ in der selbstgehosteten Integration Runtime konfiguriert wurde, überprüfen Sie, ob Ihr Proxyserver auf den Dienstendpunkt zugreifen kann. Ein Beispiel für einen Befehl finden Sie unter PowerShell, Webanforderungen und 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
     

  Die folgende Antwort wird erwartet:

  

  Hinweis

  Proxy-Aspekte:

  • Überprüfen Sie, ob der Proxyserver in die Liste der sicheren Empfänger aufgenommen werden muss. Stellen Sie in diesem Fall sicher, dass diese Domänen in der Liste der sicheren Empfänger enthalten sind.
  • Überprüfen Sie, ob das SSL/TLS-Zertifikat wu2.frontend.clouddatahub.net/ auf dem Proxyserver als vertrauenswürdig gilt.
  • Wenn Sie die Active Directory-Authentifizierung für den Proxy verwenden, ändern Sie das Dienstkonto auf das Benutzerkonto, das als "Integration Runtime-Dienst" auf den Proxy zugreifen kann.

Fehlermeldung: „Knoten der selbstgehosteten Integration Runtime/logischen selbstgehosteten Integration Runtime befindet sich im Status ‚Inaktiv/Wird ausgeführt (eingeschränkt)‘.“

• Ursache

  Der Knoten der selbstgehosteten Integrated Runtime weist möglicherweise den Status Inaktiv auf, wie im folgenden Screenshot gezeigt:

  

  Dieses Verhalten tritt auf, wenn Knoten nicht miteinander kommunizieren können.

• Lösung

  1. Melden Sie sich bei dem virtuellen Computer an, der auf dem Knoten gehostet wird. Öffnen Sie unter Applications and Services Logs>Integration Runtime, öffnen Sie Event Viewer, und filtern Sie die Fehlerprotokolle.

  2. Überprüfen Sie, ob das Fehlerprotokoll den folgenden Fehler enthält:

     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. Wenn dieser Fehler angezeigt wird, führen Sie in einem Eingabeaufforderungsfenster den folgenden Befehl aus:

     telnet 10.2.4.10 8060
     

  4. Wenn der im folgenden Screenshot gezeigte Befehlszeilenfehler „Verbindung zum Host konnte nicht geöffnet werden“ ausgegeben wird, wenden Sie sich an Ihre IT-Abteilung, um Hilfe bei der Behebung dieses Problems zu erhalten. Nachdem Sie telnet erfolgreich abgerufen haben, wenden Sie sich an Microsoft Support, wenn weiterhin Probleme mit dem Status des Integrationslaufzeitknotens auftreten.

     

  5. Überprüfen Sie, ob das Fehlerprotokoll den folgenden Eintrag enthält:

     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. Probieren Sie zur Lösung des Problems eine folgenden Methoden (oder beide) aus:

     • Platzieren Sie alle Knoten in derselben Domäne.
     • Fügen Sie die IP-Adresse zur Hostzuordnung in allen Hostdateien des gehosteten virtuellen Computers hinzu.

Konnektivitätsprobleme zwischen der selbstgehosteten IR und Ihrer Azure Data Factory- oder Azure Synapse-Instanz oder der selbstgehosteten IR und der Datenquelle oder Senke

Um das Problem mit der Netzwerkkonnektivität zu beheben, sollten Sie wissen, wie Sie die Netzwerkablaufverfolgung erfassen, verstehen, wie sie verwendet wird, und die Microsoft Network Monitor (Netmon)-Ablaufverfolgung analysieren bevor Sie die Netmon-Tools in realen Fällen aus der selbst gehosteten IR anwenden.

• Symptome

  Es kann vorkommen, dass Sie gelegentlich bestimmte Verbindungsprobleme zwischen der selbstgehosteten IR und Ihrer Data Factory oder Azure Synapse Instanz beheben müssen, wie im folgenden Screenshot dargestellt, oder zwischen der selbstgehosteten IR und der Datenquelle oder Datensenke.

  

  In beiden Fällen können möglicherweise folgende Fehler auftreten:

  • Kopieren fehlgeschlagen mit Fehler: Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException, Message=Kann nicht mit SQL Server verbinden: 'IP-Adresse'

  • „Es ist mindestens ein Fehler aufgetreten. Fehler beim Senden der Anforderung. Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Empfangen. Es können keine Daten aus der Transportverbindung gelesen werden: Eine bestehende Verbindung wurde vom Remotehost zwangsweise geschlossen. Eine vorhandene Verbindung wurde erzwungenermaßen von der Aktivitäts-ID des Remotehosts geschlossen.“

• Lösung

  Wenn die zuvor genannten Fehler auftreten, befolgen Sie die Anweisungen in diesem Abschnitt, um die Probleme zu beheben.

  • Erfassen Sie eine Netmon-Ablaufverfolgung zur Analyse:

    1. Sie können den Filter so festlegen, dass eine Zurücksetzung vom Server zur Clientseite angezeigt wird. Im folgenden Beispielscreenshot sehen Sie, dass der Azure Data Factory-Server die Serverseite darstellt.

       

    2. Wenn Sie das Zurücksetzungspaket erhalten, finden Sie die Konversation anhand des folgenden TCP-Protokolls (Transmission Control Protocol).

       

    3. Rufen Sie die Konversation zwischen Client und Azure Data Factory-Server ab, indem Sie den Filter entfernen.

  • Eine Analyse der erfassten Netmon-Ablaufverfolgung zeigt, dass die Gültigkeitsdauer (Time to Live, TTL) 64 beträgt. Anhand der im Artikel Grundlegendes zur IP-Gültigkeitsdauer (Time to Live, TTL) und zur maximalen Anzahl an Weiterleitungen erwähnten Werte (extrahiert in die folgende Liste) können Sie sehen, dass das Linux-System dafür verantwortlich ist, dass das Paket zurückgesetzt und die Verbindung getrennt wird.

    Die Standardwerte für die Gültigkeitsdauer und die maximale Hopanzahl variieren je nach Betriebssystem, wie aus der folgenden Auflistung hervorgeht:

    • Linux-Kernel 2.4 (etwa 2001): 255 für TCP, User Datagram Protocol (UDP) und Internet Control Message Protocol (ICMP)
    • Linux-Kernel 4.10 (2015): 64 für TCP, UDP und ICMP
    • Windows XP (2001): 128 für TCP, UDP und ICMP
    • Windows 10 (2015): 128 für TCP, UDP und ICMP
    • Windows Server 2008: 128 für TCP, UDP und ICMP
    • Windows Server 2019 (2018): 128 für TCP, UDP und ICMP
    • macOS (2001): 64 für TCP, UDP und ICMP

    

    Im vorherigen Beispiel wird die TTL als 61 anstatt 64 angezeigt, da das Netzwerkpaket, wenn es sein Ziel erreicht, verschiedene Zwischenstationen (z. B. Router oder Netzwerkgeräte) durchlaufen muss. Die Anzahl der Router oder Netzwerkgeräte wird abgezogen, um den endgültigen TTL-Wert zu erreichen.

    In diesem Fall können Sie sehen, dass ein Reset vom Linux-System mit TTL 64 gesendet werden kann.

  • Überprüfen Sie den vierten Hop der selbstgehosteten IR, um zu bestätigen, woher das zurücksetzende Gerät stammt.

    Netzwerkpaket von Linux-System A mit TTL 64 -> B TTL 64 minus 1 = 63 -> C TTL 63 minus 1 = 62 -> TTL 62 minus 1 = 61 selbstgehostete IR

  • In einer idealen Situation wäre die TTL-Hopsnummer 128, was bedeutet, dass das Windows Betriebssystem Ihre Data Factory-Instanz ausführt. 128 minus 107 = 21 Hops, wie im folgenden Beispiel gezeigt. Dies bedeutet, dass beim TCP-3-Wege-Handshake 21 Hops für das Paket von der Azure Data Factory-Instanz an die selbstgehostete IR gesendet wurden.

    

    Daher müssen Sie sich an das Netzwerkteam wenden, um zu den vierten Hop der selbstgehosteten IR zu ermitteln. Wenn es sich um die Firewall handelt (wie beim Linux-System), überprüfen Sie alle Protokolle, um herauszufinden, warum dieses Gerät das Paket nach dem TCP-3-Wege-Handshake zurücksetzt.

    Wenn Sie unsicher sind, wo Sie untersuchen sollen, versuchen Sie, die Netmon-Ablaufverfolgung von sowohl der selbstgehosteten IR als auch der Firewall in dem Problemzeitraum abzurufen. Mit diesem Ansatz können Sie herausfinden, welches Gerät das Paket möglicherweise zurückgesetzt und die Trennung der Verbindung verursacht hat. In diesem Fall müssen Sie sich auch an Ihr Netzwerkteam wenden, um fortzufahren.

Analysiere die Netmon-Ablaufverfolgung

Wenn Sie versuchen, Telnet 8.8.8.8 888 mit der erfassten Netmon-Ablaufverfolgung zu verwenden, sollte die Ablaufverfolgung wie in den folgenden Screenshots angezeigt werden:

Die vorherigen Abbildungen zeigen, dass Sie an Port 888 keine TCP-Verbindung zu 8.8.8.8 auf Server-Seite herstellen konnten. Daher werden dort zwei zusätzliche SynReTransmit-Pakete angezeigt. Da die Quelle SELF-HOST2 mit dem ersten Paket keine Verbindung zu 8.8.8.8 herstellen konnte, versucht sie weiterhin, die Verbindung herzustellen.

Erfolgreiche Szenarien sind in den folgenden Beispielen dargestellt:

• Wenn Sie mit Telnet 8.8.8.8 53 ohne Probleme erreichen können, gibt es einen erfolgreichen TCP-3-Wege-Handshake, und die Sitzung wird mit einem TCP-4-Wege-Handshake beendet.

  

  

• Der vorherige TCP-3-Wege-Handshake erzeugt den folgenden Workflow:

  

• Der 4-Wege-Handshake von TCP zum Beenden der Sitzung wird in den folgenden Workflows veranschaulicht:

  

  

Sind Sie von dieser Benachrichtigung betroffen?

Diese Benachrichtigung gilt für die folgenden Szenarios:

Szenario 1: Ausgehende Kommunikation von einer selbstgehosteten Integration Runtime, die lokal hinter einer Unternehmensfirewall ausgeführt wird

So bestimmen Sie, ob Sie betroffen sind:

• Sie sind nicht betroffen, wenn Sie die Firewallregeln anhand von vollqualifizierten Domänennamen (FQDNs) definieren und den unter Einrichten einer Firewallkonfiguration und Positivliste für IP-Adressen beschriebenen Ansatz verwenden.

• Sie sind betroffen, wenn Sie die Positivliste für ausgehende IP-Adressen in Ihrer Unternehmensfirewall ausdrücklich aktivieren.

  Wenn Sie betroffen sind, gehen Sie wie folgt vor: Benachrichtigen Sie bis zum 8. November 2020 das für die Netzwerkinfrastruktur zuständige Team, damit Ihre Netzwerkkonfiguration aktualisiert und die neuesten IP-Adressen von Azure Data Factory verwendet werden. Navigieren Sie zum Herunterladen der aktuellen IP-Adressen zu Ermitteln von Diensttags mit herunterladbaren JSON-Dateien.

Szenario 2: Ausgehende Kommunikation von einer selbst gehosteten Integrationslaufzeit, die auf einer Azure VM in einem vom Kunden verwalteten Azure virtuellen Netzwerk ausgeführt wird

So bestimmen Sie, ob Sie betroffen sind:

• Überprüfen Sie, ob Sie in einem privaten Netzwerk, das die selbstgehostete Integration Runtime enthält, NSG-Regeln (Netzwerksicherheitsgruppen) für den ausgehenden Datenverkehr definiert haben. Wenn keine Ausgangseinschränkungen vorliegen, sind Sie nicht betroffen.

• Wenn Einschränkungen durch Ausgangsregeln bestehen, prüfen Sie, ob Sie Diensttags verwenden. Wenn Sie Diensttags verwenden, sind Sie nicht betroffen. Sie brauchen nichts zu ändern oder hinzuzufügen, da der neue IP-Adressbereich in den Bereich der vorhandenen Diensttags fällt.

  

• Sie sind betroffen, wenn Sie die Positivliste für ausgehende IP-Adressen in den Einstellungen für die NSG-Regeln im virtuellen Azure-Netzwerk ausdrücklich aktivieren.

  Wenn Sie betroffen sind, ergreifen Sie die folgenden Maßnahmen: Benachrichtigen Sie Ihr Netzwerkinfrastrukturteam bis zum 8. November 2020, um die NSG-Regeln für Ihre Azure konfiguration des virtuellen Netzwerks zu aktualisieren, um die neuesten IP-Adressen der Datenfabrik zu verwenden. Navigieren Sie zum Herunterladen der aktuellen IP-Adressen zu Ermitteln von Diensttags mit herunterladbaren JSON-Dateien.

Szenario 3: Ausgehende Kommunikation von SSIS Integration Runtime in einem vom Kunden verwalteten Azure virtuellen Netzwerk

So bestimmen Sie, ob Sie betroffen sind:

• Überprüfen Sie, ob sie über ausgehende NSG-Regeln in einem privaten Netzwerk verfügen, das SQL Server Integration Services (SSIS) Integration Runtime enthält. Wenn keine Ausgangseinschränkungen vorliegen, sind Sie nicht betroffen.

• Wenn Einschränkungen durch Ausgangsregeln bestehen, prüfen Sie, ob Sie Diensttags verwenden. Wenn Sie Diensttags verwenden, sind Sie nicht betroffen. Sie brauchen nichts zu ändern oder hinzuzufügen, da der neue IP-Adressbereich in den Bereich der vorhandenen Diensttags fällt.

• Sie sind betroffen, wenn Sie die Positivliste für ausgehende IP-Adressen in den Einstellungen für die NSG-Regeln im virtuellen Azure-Netzwerk ausdrücklich aktivieren.

  Wenn Sie betroffen sind, ergreifen Sie die folgenden Maßnahmen: Benachrichtigen Sie Ihr Netzwerkinfrastrukturteam bis zum 8. November 2020, um die NSG-Regeln für Ihre Azure konfiguration des virtuellen Netzwerks zu aktualisieren, um die neuesten IP-Adressen der Datenfabrik zu verwenden. Navigieren Sie zum Herunterladen der aktuellen IP-Adressen zu Ermitteln von Diensttags mit herunterladbaren JSON-Dateien.

Es konnte keine Vertrauensstellung für den sicheren SSL/TLS-Kanal eingerichtet werden

• Symptome

  Die selbst gehostete IR konnte keine Verbindung mit dem Azure Data Factory oder Azure Synapse Dienst herstellen.

  Wenn Sie das selbst gehostete IR-Ereignisprotokoll überprüfen, nachdem Sie zu Windows>Ereignisanzeige (Protokolle)>Anwendungs- und Dienstprotokollen>Integration Runtime wechseln, finden Sie die folgende Fehlermeldung.

  „Die zugrunde liegende Verbindung wurde geschlossen: Es konnte keine Vertrauensstellung für den sicheren SSL/TLS-Kanal eingerichtet werden. System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure." (System.Security.Authentication.AuthenticationException: Das Remotezertifikat ist laut Validierungsverfahren ungültig.)

  Am einfachsten überprüfen Sie das Dienstzertifikat, indem Sie die URL in Ihren Browser eingeben und den Dienst öffnen. Öffnen Sie beispielsweise auf dem Computer, auf dem die selbstgehostete IR installiert ist, den Link Serverzertifikat (https://eu.frontend.clouddatahub.net/) und sehen Sie sich dann die Informationen zum Serverzertifikat an.

  

  

• Ursache

  Für dieses Problem gibt es zwei mögliche Ursachen:

  • Ursache 1: Auf dem Computer, auf dem die selbstgehostete Integration Runtime installiert ist, wird die Stammzertifizierungsstelle des Dienstserverzertifikats nicht als vertrauenswürdig eingestuft.
  • Ursache 2: Sie verwenden einen Proxy in Ihrer Umgebung. Das Dienstserverzertifikat wird durch den Proxy ersetzt und das ersetzte Serverzertifikat wird auf dem Computer, auf dem die selbstgehostete Integration Runtime installiert ist, nicht als vertrauenswürdig eingestuft.

• Lösung

  • Für Grund 1: Stellen Sie sicher, dass das Serverzertifikat des Dienstes und die zugehörige Zertifikatkette auf dem Computer, auf dem die selbstgehostete IR installiert ist, als vertrauenswürdig gelten.
  • Für Ursache 2: Stellen Sie entweder auf dem Computer mit der selbstgehosteten Integration Runtime eine Vertrauensstellung zur ersetzten Stammzertifizierungsstelle her, oder konfigurieren Sie den Proxy so, dass das Dienstserverzertifikat nicht ersetzt wird.

  Weitere Informationen zum Vertrauen von Zertifikaten auf Windows finden Sie unter Installieren des vertrauenswürdigen Stammzertifikats.

• Zusätzliche Informationen
  Wir haben eine neues, von DigiCert signiertes SSL-Zertifikat eingeführt. Überprüfen Sie, ob sich DigiCert Global Root G2 unter den vertrauenswürdigen Stammzertifizierungsstellen befindet.

  

  Wenn sich das Zertifikat nicht unter den vertrauenswürdigen Stammzertifizierungsstellen befindet, können Sie es hier herunterladen.

Zugehöriger Inhalt

Weitere Hilfe zur Problembehandlung finden Sie in den folgenden Ressourcen:

• Data Factory-Blog
• Data Factory-Funktionsanfragen

• Azure Videos

• Microsoft Q&A-Seite
• Stack Overflow-Forum für Data Factory
• Informationen zu Data Factory auf X
• Leitfaden zur Leistungsoptimierung von Mapping Data Flows