Risolvere i problemi relativi al runtime di integrazione autogestito

APPLICABILE A: Azure Data Factory Azure Synapse Analytics Microsoft Purview

Questo articolo illustra i metodi di risoluzione dei problemi comuni per il runtime di integrazione self-hosted nelle aree di lavoro di Azure Data Factory e Synapse.

Raccogliere i log del runtime di integrazione self-hosted

Azure Data Factory e Azure Synapse Analytics

Per le attività non riuscite in esecuzione in un runtime di integrazione self-hosted o in un runtime di integrazione condiviso, il servizio supporta la visualizzazione e il caricamento dei log degli errori. Per ottenere l'ID del report degli errori, seguire le istruzioni riportate qui e quindi immettere l'ID del report per cercare i problemi noti correlati.

1. Nella pagina Monitoraggio per l'interfaccia utente del servizio selezionare Esecuzioni della pipeline.

2. In Esecuzioni delle attività, nella colonna Errore selezionare il pulsante evidenziato per visualizzare i registri delle attività, come illustrato nello screenshot seguente.

   • Azure Data Factory
   • Azure Synapse

   

   I log di attività vengono visualizzati per l'attività eseguita senza successo.

   

3. Per ulteriore assistenza, selezionare Invia log.

   Viene visualizzata la finestra Condividere i log del runtime di integrazione self-hosted con Microsoft.

   

4. Selezionare i log da inviare.

   • Per un runtime di integrazione self-hosted, è possibile caricare i log correlati all'attività non riuscita o a tutti i log nel nodo del runtime di integrazione self-hosted.
   • Per un IR condiviso, è possibile caricare solo i log correlati all'attività non riuscita.

5. Quando i log vengono caricati, mantenere un record dell'ID report per usarli in un secondo momento se è necessaria ulteriore assistenza per risolvere il problema.

   

Microsoft Purview

Per le attività di Microsoft Purview non riuscite in esecuzione in un runtime di integrazione self-hosted o in un runtime di integrazione condiviso, il servizio supporta la visualizzazione e il caricamento dei log degli errori dal Windows Visualizzatore eventi.

È possibile cercare qualsiasi errore visualizzato nella guida agli errori seguente. Per ricevere supporto e indicazioni per la risoluzione dei problemi relativi a SHIR, potrebbe essere necessario generare un ID di segnalazione errori e contattare il supporto Microsoft.

Per generare l'ID del report degli errori per supporto tecnico Microsoft, seguire queste istruzioni:

1. Prima di avviare un'analisi nel portale di governance di Microsoft Purview:

   1. Passare al computer in cui è installato il runtime di integrazione self-hosted e aprire il Windows Visualizzatore eventi.
   2. Cancellare i log di Windows Visualizzatore eventi nella sezione Integration Runtime. Fare clic con il pulsante destro del mouse sui log e selezionare l'opzione Cancella log.
   3. Tornare al portale di governance Microsoft Purview e avviare l'analisi.

2. Quando l'analisi mostra lo stato Failed, tornare alla macchina virtuale SHIR o aggiornare il visualizzatore eventi nella sezione Integration Runtime.

3. I registri delle attività vengono visualizzati per l'esecuzione di una scansione fallita.

4. Per ulteriore assistenza da Microsoft, selezionare Send Logs.

   Viene visualizzata la finestra Condividi i log di runtime di integrazione autonomo (SHIR) con Microsoft.

   

5. Selezionare i log da inviare.

   • Per un runtime di integrazione self-hosted, è possibile caricare i log correlati all'attività non riuscita o a tutti i log nel nodo del runtime di integrazione self-hosted.
   • Per un IR condiviso, è possibile caricare solo i log correlati all'attività fallita.

6. Quando i log vengono caricati, mantenere un record dell'ID report per usarli in un secondo momento se è necessaria ulteriore assistenza per risolvere il problema.

   

Errore generale del runtime di integrazione self-hosted

Problema relativo a memoria insufficiente

• Sintomi

  Un errore OutOfMemoryException (OOM) si verifica quando si tenta di eseguire un'attività di ricerca con un runtime di integrazione collegato o un runtime di integrazione self-hosted.

• Causa

  Una nuova attività può generare un errore OOM se il computer del runtime di integrazione sperimenta un utilizzo momentaneo elevato della memoria. Il problema potrebbe essere causato da un volume elevato di attività simultanee e l'errore è per impostazione predefinita.

• Risoluzione

  Controllare l'utilizzo delle risorse e l'esecuzione simultanea delle attività sul nodo IR. Modificare il tempo interno e il tempo di attivazione delle esecuzioni dell'attività per evitare un'esecuzione troppo grande in un singolo nodo di runtime di integrazione contemporaneamente.

Problemi nelle limiti dei processi simultanei

• Sintomi

  Quando si tenta di aumentare il limite di processi simultanei dall'interfaccia utente, il processo si blocca in Stato di aggiornamento .

  Scenario di esempio: il valore massimo dei processi simultanei è attualmente impostato su 24 e si vuole aumentare il numero in modo che i processi possano essere eseguiti più velocemente. Il valore minimo che può essere inserito è pari a 3 e il valore massimo è pari a 32. Aumentare il valore da 24 a 32 e quindi selezionare il pulsante Aggiorna . Il processo si blocca in Stato di aggiornamento , come illustrato nello screenshot seguente. La pagina viene aggiornata e il valore viene comunque visualizzato come 24. Non è stato aggiornato a 32 come previsto.

  

• Causa

  Il limite al numero di processi simultanei dipende dal core logico e dalla memoria del computer. Provare a regolare il valore verso il basso, ad esempio su 24, quindi visualizzare il risultato.

  Suggerimento

  • Per altre informazioni sul numero di core logici e per determinare il numero di core logici del computer, vedere Modi per trovare il numero di core nella CPU in Windows 10.
  • Per informazioni su come calcolare il file math.log, passare al calcolatore logaritmico.

Problema del certificato SSL a disponibilità elevata (HA) del runtime di integrazione self-hosted

• Sintomi

  Il nodo di lavoro di IR self-hosted ha segnalato il seguente errore:

  Impossibile effettuare il pull degli stati condivisi dal nodo primario net.tcp://abc.cloud.corp.Microsoft.com:8060/ExternalService.svc/. Activity ID: XXXXX The X.509 certificate CN=abc.cloud.corp.Microsoft.com, OU=test, O=Microsoft chain building failed." (Non è stato possibile eseguire il pull degli stati condivisi dal nodo primario net.tcp://abc.cloud.corp.Microsoft.com:8060/ExternalService.svc/. ID attività: XXXXX La compilazione della catena CN=abc.cloud.corp.Microsoft.com, OU=test, O=Microsoft del certificato X.509 ha avuto esito negativo). La catena di fiducia del certificato utilizzato non può essere verificata. Sostituire il certificato o modificare certificateValidationMode. La funzione di revoca non è in grado di completare il controllo di revoca perché il server di revoca è offline."

• Causa

  Quando vengono gestiti casi relativi all'handshake SSL/TLS, è possibile riscontrare problemi relativi alla verifica della catena di certificati.

• Risoluzione

  • Ecco un modo veloce e intuitivo per risolvere l'errore di compilazione della catena di certificati X.509:

    1. Esportare il certificato, che deve essere verificato. A tale scopo, seguire questa procedura:

       a) In Windows selezionare Start, iniziare a digitare certificates e quindi selezionare Gestisci certificati computer.

       b. In Esplora file, a sinistra, cercare il certificato che si vuole controllare, fare clic con il pulsante destro del mouse, quindi selezionare Tutte le attività>Esporta.

       

    2. Copiare il certificato esportato nel computer client.

    3. Sul lato client, nella finestra del prompt dei comandi, eseguire il comando seguente. Assicurarsi di sostituire percorso del certificato e percorso del file txt di output con i percorsi effettivi.

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

       Ad esempio:

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

    4. Controllare errori nel file TXT di output. È possibile trovare il riepilogo degli errori alla fine di tale file.

       Ad esempio:

       

       Se non viene visualizzato un errore alla fine del file di log, come illustrato nello screenshot seguente, è possibile considerare che la catena di certificati è stata compilata correttamente nel computer client.

       

  • Se nel file del certificato è configurata un'estensione di file AIA (Accesso alle Informazioni dell'Autorità), CDP (Punto di Distribuzione delle Liste di Revoca dei Certificati) o OCSP (Protocollo di Stato del Certificato Online), puoi verificarlo in modo più intuitivo:

    1. Ottenere queste informazioni controllando i dettagli del certificato, come illustrato nello screenshot seguente:

       

    2. Esegui il comando seguente: Assicurarsi di sostituire <il percorso> del certificato con il percorso effettivo del certificato.

         Certutil   -URL    <certificate path> 
       

       Verrà aperto lo strumento di recupero URL.

    3. Per verificare i certificati con estensioni di file AIA, CDP e OCSP, selezionare Recupera.

       

       La catena di certificati è stata compilata correttamente se lo stato del certificato da AIA è Verificato e lo stato del certificato da CDP o OCSP è Verificato.

       Se si verifica un errore durante il tentativo di recuperare AIA o CDP, collaborare con il team di rete per preparare il computer client a connettersi all'URL di destinazione. Sarà sufficiente se è possibile verificare il percorso HTTP o il percorso del Lightweight Directory Access Protocol (LDAP).

Il runtime di integrazione self-hosted non può caricare il file o l'assembly

• Sintomi

  Viene visualizzato il seguente messaggio di errore:

  "Non è stato possibile caricare il file o l'assembly "XXXXXXXXXXXXXXXX, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX" o una delle relative dipendenze. Non è possibile trovare il file specificato. ID attività: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3"

  Ecco un messaggio di errore più specifico:

  "Non è stato possibile caricare il file o l'assembly "System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX" o una delle relative dipendenze. Non è possibile trovare il file specificato. ID attività: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3"

• Causa

  In Monitoraggio processi è possibile visualizzare il risultato seguente:

  

  Suggerimento

  In Monitoraggio processi è possibile impostare i filtri come illustrato nello screenshot seguente.

  Il messaggio di errore precedente indica che la DLL System.ValueTuple non si trova nella cartella Global Assembly Cache (GAC) correlata, nella cartella C:\Programmi\Microsoft Integration Runtime\4.0\Gateway o nella cartella C:\Programmi\Microsoft Integration Runtime\4.0\Cartella Shared.

  In pratica, il processo carica prima la DLL dalla cartella GAC , quindi dalla cartella Shared e infine dalla cartella Gateway . Pertanto, è possibile caricare la DLL da qualsiasi percorso utile.

  Screenshot della pagina "Filtro del monitoraggio dei processi", che elenca i filtri per la DLL.

• Risoluzione

  Troverai il file System.ValueTuple.dll nella cartella C:\Programmi\Microsoft Integration Runtime\4.0\Gateway\DataScan. Per risolvere il problema, copiare il file System.ValueTuple.dll nella cartella C:\Programmi\Microsoft Integration Runtime\4.0\Gateway.

  È possibile usare lo stesso metodo per risolvere i problemi di altri file o assembly mancanti.

• Altre informazioni su questo problema

  Il motivo per cui viene visualizzato il System.ValueTuple.dll in %windir%\Microsoft.NET\assembly e %windir%\assembly è che si tratta di un comportamento .NET.

  Nell'errore seguente è possibile vedere chiaramente che l'assembly System.ValueTuple non è presente. Questo problema si verifica quando l'applicazione tenta di controllare l'assembly System.ValueTuple.dll .

  "<LogProperties><ErrorInfo>[{"Code":0,"Message":"L'inizializzatore del tipo per 'Npgsql.PoolManager' ha generato un'eccezione.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.TypeInitializationException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[{"Code":0,"Message":"Impossibile caricare il file o l'assembly 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' o una delle sue dipendenze. Impossibile trovare il file specificato.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.IO.FileNotFoundException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[]}]}]</ErrorInfo></LogProperties>"

  Per altre informazioni su GAC, vedere Global Assembly Cache.

La chiave di autenticazione per il runtime di integrazione ospitata internamente è mancante

• Sintomi

  Il runtime di integrazione self-hosted passa improvvisamente offline senza una chiave di autenticazione e nel registro eventi viene visualizzato il messaggio di errore seguente:

  "Authentication Key is not assigned yet" (La chiave di autenticazione non è ancora assegnata)

  

• Causa

  • Il nodo di runtime di integrazione self-hosted o il nodo di runtime di integrazione self-hosted logico nel portale di Azure sono stati eliminati.
  • È stata eseguita una disinstallazione completa.

• Risoluzione

  Se nessuna delle cause precedenti si applica, è possibile passare alla cartella %programdata%\Microsoft\Data Transfer\DataManagementGateway per verificare se il file Configurations è stato eliminato. Se è stato eliminato, seguire le istruzioni riportate nell'articolo Netwrix Rilevare chi ha eliminato un file dai server di file di Windows.

  

Non è possibile usare il runtime di integrazione self-hosted per collegare due archivi dati locali

• Sintomi

  Dopo aver creato i runtime di integrazione self-hosted per gli archivi dati di origine e di destinazione, è necessario connettere i due runtime di integrazione per completare un'attività di copia. Se gli archivi dati sono configurati in reti virtuali diverse o non sono in grado di comprendere il meccanismo del gateway, viene visualizzato uno degli errori seguenti:

  • Impossibile trovare il driver dell'origine nell'IR di destinazione.
  • "The source cannot be accessed by the destination IR" (Il runtime di integrazione di destinazione non può accedere all'origine)

• Causa

  Il runtime di integrazione self-hosted è progettato come nodo centrale di un'attività di copia, non come agente client da installare per ogni archivio dati.

  In questo caso è necessario creare il servizio collegato per ogni archivio dati con lo stesso runtime di integrazione e tale runtime di integrazione dovrebbe essere in grado di accedere a entrambi gli archivi dati tramite la rete. Non importa se l'IR è installato nell'archivio dati di origine, di destinazione oppure su un terzo computer. Se vengono creati due servizi collegati con runtime di integrazione diversi ma vengono usati nella stessa attività di copia, viene usato il runtime di integrazione di destinazione ed è necessario installare i driver per entrambi gli archivi dati nel computer del runtime di integrazione di destinazione.

• Risoluzione

  Installare i driver sia per l'archivio dati di origine che per quello di destinazione nel runtime di integrazione di destinazione e assicurarsi che possano accedere all'archivio dati di origine.

  Se il traffico non può passare attraverso la rete tra due archivi dati (ad esempio, gli archivi dati sono configurati in due reti virtuali), la copia potrebbe non completarsi in un'unica attività anche con IR installato. Se non è possibile completare la copia in una singola attività, è possibile creare due attività di copia con due runtime di integrazione, ognuna in un VENT:

  • Copiare un IR da datastore 1 a Archiviazione BLOB di Azure
  • Copiare un altro IR da Archiviazione BLOB di Azure al datastore 2.

  Questa soluzione potrebbe simulare la necessità di usare l'IR per creare un ponte che connetta due archivi dati disconnessi.

Il problema di sincronizzazione delle credenziali provoca la perdita di credenziali da HA.

• Sintomi

  Se le credenziali dell'origine dati "XXXXXXXXXX" vengono eliminate dal nodo del runtime di integrazione corrente con payload, viene visualizzato il messaggio di errore seguente:

  "When you delete the link service on Azure portal, or the task has the wrong payload, please create new link service with your credential again." (Quando si elimina il servizio di collegamento nel portale di Azure o l'attività ha un payload errato, creare un nuovo servizio di collegamento con le credenziali.)

• Causa

  Il runtime di integrazione self-hosted è stato creato in modalità a disponibilità elevata con due nodi, ma i nodi non sono sincronizzati con le credenziali. Ciò significa che le credenziali archiviate nel nodo dispatcher non vengono sincronizzate con altri nodi di lavoro. Se si verifica un failover dal nodo dispatcher al nodo di lavoro e le credenziali esistono solo nel nodo dispatcher precedente, l'attività avrà esito negativo quando si tenta di accedere alle credenziali e si riceverà l'errore precedente.

• Risoluzione

  L'unico modo per evitare questo problema consiste nel verificare che due nodi si trovino nello stato di sincronizzazione delle credenziali. Se non sono sincronizzati, è necessario immettere di nuovo le credenziali per il nuovo dispatcher.

Non è possibile scegliere il certificato perché manca la chiave privata

• Sintomi

  • È stato importato un file con estensione pfx nell'archivio certificati.

  • Quando è stato selezionato il certificato tramite l'interfaccia utente del runtime di integrazione Gestione configurazione, è stato visualizzato il messaggio di errore seguente:

    Impossibile cambiare la modalità di crittografia della comunicazione dell'intranet. È probabile che il certificato "<nome> certificato" non abbia una chiave privata in grado di scambiare chiavi o che il processo potrebbe non avere diritti di accesso per la chiave privata. Per informazioni dettagliate, vedere l'eccezione interna."

• Causa

  • L'account utente ha un livello di privilegi basso e non può accedere alla chiave privata.
  • Il certificato è stato generato come firma ma non come scambio di chiave.

• Risoluzione

  • Per usare l'interfaccia utente, usare un account con privilegi appropriati per accedere alla chiave privata.

  • Importare il certificato eseguendo il comando seguente:

    certutil -importpfx FILENAME.pfx AT_KEYEXCHANGE
    

Nodi del runtime di integrazione self-hosted fuori dal problema di sincronizzazione

• Sintomi

  I nodi del runtime di integrazione self-hosted tentano di sincronizzare le credenziali all'interno dei nodi, ma si bloccano durante il processo e dopo un po' riscontrano il messaggio di errore seguente:

  "Il nodo Integration Runtime (self-hosted) sta tentando di sincronizzare le credenziali tra i nodi. Potrebbe richiedere alcuni minuti.

  Nota

  Se questo errore viene visualizzato per più di 10 minuti, controllare la connettività con il nodo dispatcher.

• Causa

  Il motivo è che i nodi di lavoro non hanno accesso alle chiavi private. Questa operazione può essere confermata dai seguenti log del runtime di integrazione ospitato internamente:

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

  Quando si usa l'autenticazione del service principal nel servizio collegato, non si verificano problemi con il processo di sincronizzazione. Tuttavia, quando si passa al tipo di autenticazione chiave dell'account, il problema di sincronizzazione ricomincia. Questo succede perché il servizio di runtime di integrazione self-hosted viene eseguito in un account del servizio (NT SERVICE\DIAHostService) e deve essere aggiunto alle autorizzazioni della chiave privata.

• Risoluzione

  Per risolvere il problema, è necessario aggiungere l'account del servizio runtime di integrazione autogestito (NT SERVICE\DIAHostService) alle autorizzazioni della chiave privata. È possibile applicare i passaggi seguenti:

  1. Apri il comando di esecuzione della Microsoft Management Console (MMC).

     

  2. Nel riquadro MMC applicare i passaggi seguenti:

     

     1. Selezionare File.
     2. Scegliere Aggiungi/Rimuovi snap-in nel menu a discesa.
     3. Selezionare Certificati nel riquadro "Available snap-ins" (Snap-in disponibili).
     4. Selezionare Aggiungi.
     5. Nel riquadro a comparsa "Certificates snap-in" (Snap-in certificati) scegliere Account del computer.
     6. Selezionare Avanti.
     7. Nel riquadro "Seleziona computer" scegliere Computer locale: il computer su cui è in esecuzione questa console.
     8. Selezionare Fine.
     9. Selezionare OK nel riquadro "Aggiungi/Rimuovi snap-in".

  3. Nel riquadro di MMC procedere con i passaggi seguenti:

     

     1. Nell'elenco di cartelle a sinistra, selezionare Radice console -> Certificati (Computer locale) -> Personale -> Certificati.
     2. Fare clic con il pulsante destro del mouse sul Microsoft Intune Beta MDM.
     3. Selezionare Tutte le attività nell'elenco a discesa.
     4. Selezionare Manage Private Keys (Gestisci chiavi private).
     5. Selezionare Aggiungi in "Nomi utente o gruppo".
     6. Selezionare NT SERVICE\DIAHostService per concedere l'accesso con controllo completo a questo certificato, applicarlo e proteggerlo.
     7. Selezionare Verifica nomi, quindi selezionare OK.
     8. Nel riquadro "Autorizzazioni" selezionare Applica, quindi selezionare OK.

Messaggio di errore UserErrorJreNotFound quando si esegue un'attività di copia per Azure

• Sintomi

  Quando si tenta di copiare il contenuto in Microsoft Azure usando uno strumento o un programma basato su Java (ad esempio, la copia di file in formato ORC o Parquet), viene visualizzato un messaggio di errore simile al seguente:

  ErrorCode=UserErrorJreNotFound,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Java Runtime Environment non trovato. Passare a http://go.microsoft.com/fwlink/?LinkId=808605 per scaricare e installare nel nodo Integration Runtime (self-hosted) del computer. Nota: Integration Runtime a 64 bit richiede JRE a 64 bit e Integration Runtime a 32 bit richiede JRE a 32 bit.,Source=Microsoft.DataTransfer.Common,''Type=System.DllNotFoundException,Messaggio=Impossibile caricare la DLL 'jvm.dll': Il modulo specificato non è stato trovato. (Eccezione da HRESULT: 0x8007007E),Source=Microsoft. DataTransfer.Richfile.HiveOrcBridge

• Causa

  Questo problema è causato da uno dei motivi seguenti:

  • Java Runtime Environment (JRE) non è installato correttamente nel server Integration Runtime.

  • Il server Integration Runtime non dispone della dipendenza necessaria per JRE.

  Per impostazione predefinita, Integration Runtime risolve il percorso JRE usando le voci del Registro di sistema. Tali voci devono essere impostate automaticamente durante l'installazione di JRE.

• Risoluzione

  Segui con attenzione la procedura descritta in questa sezione. Se le modifiche al Registro di sistema vengono apportate in modo non corretto, possono verificarsi problemi gravi. Prima di modificarlo, esegui il backup del Registro di sistema per il ripristino nel caso in cui si verifichino problemi.

  Per risolvere questo problema, seguire questa procedura per verificare lo stato dell'installazione di JRE:

  1. Assicurarsi che Integration Runtime (Diahost.exe) e JRE siano installati nella stessa piattaforma. Verificare le condizioni seguenti:

     • Il JRE a 64 bit per l'Integration Runtime ADF a 64 bit deve essere installato nella cartella: C:\Program Files\Java\

       Nota

       La cartella non è C:\Program Files (x86)\Java\

     • Java Runtime (JRE) è versione 11 o successiva, da un provider JRE, ad esempio Microsoft OpenJDK 11 o Eclipse Temurin 11. Assicurarsi che la variabile di ambiente di sistema JAVA_HOME sia impostata sulla cartella JDK (non solo sulla cartella JRE). Potrebbe anche essere necessario aggiungere la cartella bin alla variabile di ambiente PATH del sistema.

  2. Controllare le impostazioni appropriate nel registro di sistema. A questo scopo, seguire questa procedura:

     1. Nel menu Esegui digitare Regedit e quindi premere INVIO.

     2. Nel riquadro di spostamento individuare la sottochiave seguente:

        HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment.

        Nel riquadro Dettagli dovrebbe essere presente una voce Versione corrente che mostra la versione JRE (ad esempio, 1.8).

        

     3. Nel riquadro di spostamento individuare una sottochiave corrispondente esattamente alla versione (ad esempio 1.8) nella cartella JRE. Nel riquadro dei dettagli deve essere presente una voce JavaHome. Il valore di questa voce è il percorso di installazione di JRE.

        

  3. Individuare la cartella bin\server nel percorso seguente:

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

     

  4. Controllare se questa cartella contiene un file jvm.dll. In caso contrario, cercare il file nella cartella bin\client.

     

  Nota

  • Se una di queste configurazioni non è come descritta in questi passaggi, usare JRE Windows Installer per risolvere i problemi.
  • Se tutte le configurazioni in questi passaggi sono corrette come descritto, potrebbe mancare una libreria di runtime VC++ nel sistema. È possibile risolvere questo problema installando VC++ 2010 Redistributable Package.

Configurazione del runtime di integrazione self-hosted

Errore di registrazione del runtime di integrazione

• Sintomi

  Occasionalmente potresti voler eseguire un IR self-hosted in un account diverso per uno dei seguenti motivi:

  • La politica aziendale non consente l'account di servizio.
  • È necessaria un'autenticazione.

  Dopo aver modificato l'account del servizio nel riquadro del servizio, è possibile che il runtime di integrazione interrompa il funzionamento e venga visualizzato il messaggio di errore seguente:

  "Il nodo Integration Runtime (self-hosted) ha rilevato un errore durante la registrazione. Impossibile connettersi al servizio host Integration Runtime (self-hosted).

  

• Causa

  Molte risorse vengono concesse solo all'account di servizio. Quando si passa dall'account del servizio a un altro account, le autorizzazioni di tutte le risorse dipendenti rimangono invariate.

• Risoluzione

  Passare al registro eventi del runtime di integrazione per verificare l'errore.

  

  • Se l'errore nel log eventi è "UnauthorizedAccessException", eseguire le operazioni seguenti:

    1. Controllare l'account del servizio di accesso DIAHostService nel pannello servizi di Windows.

       

    2. Verificare se l'account del servizio di accesso dispone di autorizzazioni di lettura/scrittura per la cartella %programdata%\Microsoft\DataTransfer\DataManagementGateway.

       • Per impostazione predefinita, se l'account di accesso al servizio non è stato modificato, deve disporre delle autorizzazioni di lettura/scrittura.

         

       • Se l'account di accesso al servizio è stato modificato, attenuare il problema eseguendo le operazioni seguenti:

         a) Eseguire una disinstallazione pulita del runtime di integrazione self-hosted corrente.
         b. Installare i bit del runtime di integrazione self-hosted.
         c. Modificare l'account del servizio eseguendo le operazioni seguenti:

         i. Andare alla cartella di installazione del runtime di integrazione self-hosted, quindi passare alla cartella Microsoft Integration Runtime\4.0\Shared.
         ii. Aprire una finestra del prompt dei comandi usando privilegi elevati. Sostituire <user> e <password> con il vostro nome utente e password e quindi eseguire il comando seguente:
         dmgcmd.exe -SwitchServiceAccount "<user>" "<password>"
         iii. Se si vuole passare all'account LocalSystem, assicurarsi di usare il formato corretto per questo account: dmgcmd.exe -SwitchServiceAccount "NT Authority\System" ""
         Non usare questo formato: dmgcmd.exe -SwitchServiceAccount "LocalSystem" ""
         iv. Facoltativamente, poiché il sistema locale dispone di privilegi più elevati rispetto all'amministratore, è anche possibile modificarlo direttamente in "Servizi".
         v. È possibile utilizzare un utente locale/di dominio per l'account di accesso al servizio IR.

         d. Registrare il runtime di integrazione.

  • Se l'errore è "Service 'Integration Runtime Service' (DIAHostService) non è stato avviato. Verificare di disporre di privilegi sufficienti per avviare i servizi di sistema", eseguire le operazioni seguenti:

    1. Verificare l'account del servizio di accesso DIAHostService nel pannello servizi di Windows.

       

    2. Controllare se l'account del servizio di accesso dispone dell'autorizzazione Accedi come servizio per avviare il servizio di Windows:

       

• Ulteriori informazioni

  Se nessuno dei due modelli di risoluzione precedenti si applica nel caso in uso, provare a raccogliere i log eventi Windows seguenti:

  • Log applicazioni e servizi > Integration Runtime
  • Log > applicazione Windows

Non è possibile trovare il pulsante Registra per registrare un runtime di integrazione self-hosted

• Sintomi

  Quando si registra un runtime di integrazione self-hosted, il pulsante Registra non viene visualizzato nel riquadro Gestione configurazione.

  

• Causa

  A partire dal rilascio di Integration Runtime 3.0, il pulsante Register nei nodi integration runtime esistenti è stato rimosso per abilitare un ambiente più pulito e sicuro. Se un nodo è stato registrato in un runtime di integrazione (online oppure no), è necessario registrarlo nuovamente in un altro runtime di integrazione disinstallando il nodo precedente, quindi installare e registrare il nodo.

• Risoluzione

  1. In Pannello di controllo disinstallare il runtime di integrazione esistente.

     Importante

     Nel processo seguente selezionare Sì. Non conservare i dati durante il processo di disinstallazione.

     

  2. Se non si dispone del file MSI di installazione del runtime di integrazione, andare all'area download per scaricare il runtime di integrazione più recente.

  3. Installare il file MSI e registrare il runtime di integrazione.

Impossibile registrare l'Integration Runtime (IR) autogestito a causa del localhost

• Sintomi

  Non è possibile registrare il runtime di integrazione self-hosted su un nuovo computer quando si utilizza get_LoopbackIpOrName.

  Debug: si è verificato un errore di runtime. L'inizializzatore di tipo per 'Microsoft.DataTransfer.DIAgentHost.DataSourceCache' ha generato un'eccezione. Si è verificato un errore irreversibile durante una ricerca nel database.

  Exception detail: System.TypeInitializationException: L'inizializzatore di tipo per 'Microsoft.DataTransfer.DIAgentHost.DataSourceCache' ha generato un'eccezione. >--- System.Net.Sockets.SocketException: si è verificato un errore non ripristinabile durante una ricerca del database in System.Net.Dns.GetAddrInfo(String name).

• Causa

  Il problema si verifica in genere quando viene risolto localhost.

• Risoluzione

  Usare l'indirizzo IP localhost 127.0.0.1 per ospitare il file e risolvere il problema.

Installazione auto-ospitata non riuscita

• Sintomi

  Non è possibile disinstallare un runtime di integrazione esistente, installare un nuovo runtime di integrazione o aggiornare un runtime di integrazione esistente a un nuovo runtime di integrazione.

• Causa

  L'installazione del runtime di integrazione dipende dal servizio Windows Installer. Potrebbero verificarsi problemi di installazione per i motivi seguenti:

  • Spazio disponibile su disco insufficiente.
  • Mancanza di autorizzazioni.
  • Il servizio NT Windows è bloccato.
  • L'utilizzo della CPU è troppo elevato.
  • Il file MSI è ospitato in un percorso di rete lento.
  • Alcuni file di sistema o registri sono stati toccati involontariamente.

L'account del servizio IR non è riuscito a ottenere l'accesso al certificato

• Sintomi

  Quando si installa un runtime di integrazione self-hosted tramite Microsoft Integration Runtime Gestione configurazione, viene generato un certificato con un'autorità di certificazione (CA) attendibile. Non è stato possibile applicare il certificato per crittografare la comunicazione tra due nodi e viene visualizzato il messaggio di errore seguente:

  Impossibile modificare la modalità di crittografia delle comunicazioni Intranet: non è stato possibile concedere all'account del servizio Integration Runtime l'accesso al certificato "<nome certificato>". Codice errore 103"

• Causa

  Il certificato utilizza il provider di archiviazione chiavi (KSP), che non è ancora supportato. Ad oggi, il self-hosted IR supporta solo l'archiviazione del fornitore di servizi crittografici (CSP).

• Risoluzione

  In questo caso è consigliabile usare i certificati CSP.

  Soluzione 1

  Per importare il certificato, eseguire il comando seguente:

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

  

  Soluzione 2

  Per convertire il certificato, eseguire i comandi seguenti:

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

  Prima e dopo la conversione:

  

  

Runtime di integrazione autogestito versione 5.x

Per l'aggiornamento alla versione 5.x del runtime di integrazione self-hosted, è necessario .NET Framework Runtime 4.7.2 o versione successiva. Nella pagina di download sono disponibili i collegamenti di download per la versione 4.x più recente e le ultime due versioni 5.x.

Per i clienti Azure Data Factory v2 e Azure Synapse:

• Se l'aggiornamento automatico è attivo ed è già stato aggiornato il runtime di .NET Framework alla versione 4.7.2 o successiva, il runtime di integrazione self-hosted verrà aggiornato automaticamente alla versione 5.x più recente.
• Se l'aggiornamento automatico è attivo e non è stato aggiornato il runtime di .NET Framework alla versione 4.7.2 o successiva, il runtime di integrazione self-hosted non verrà aggiornato automaticamente alla versione 5.x più recente. Il runtime di integrazione self-hosted rimarrà nella versione 4.x corrente. È possibile visualizzare un avviso per un aggiornamento del runtime di .NET Framework nel portale e nel client del runtime di integrazione ospitato autonomamente.
• Se l'aggiornamento automatico è disattivato ed è già stato aggiornato il runtime di .NET Framework alla versione 4.7.2 o successiva, è possibile scaricare manualmente la versione 5.x più recente e installarla nel computer.
• Se l'aggiornamento automatico è disattivato e non è stato aggiornato il runtime di .NET Framework alla versione 4.7.2 o successiva. Quando si tenta di installare manualmente il runtime di integrazione self-hosted 5.x e registrare la chiave, sarà necessario aggiornare prima la versione del runtime di .NET Framework.

Problemi di connettività del runtime di integrazione autogestito

Il runtime di integrazione self-hosted non riesce a connettersi al servizio cloud

• Sintomi

  Quando si tenta di registrare il runtime di integrazione self-hosted, Gestione configurazione visualizza il messaggio di errore seguente:

  "Il nodo Integration Runtime (self-hosted) ha rilevato un errore durante la registrazione."

  

• Causa

  Il runtime di integrazione self-hosted non può connettersi al back-end del servizio. In genere questo problema è causato dalle impostazioni di rete nel firewall.

• Risoluzione

  1. Verificare se il servizio di runtime di integrazione è in esecuzione. In caso affermativo, andare al passaggio 2.

     

  2. Se nel runtime di integrazione self-hosted non è configurato alcun proxy (impostazione predefinita), eseguire il comando di PowerShell seguente nel computer in cui è installato il runtime di integrazione self-hosted:

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

     Nota

     L'URL del servizio può variare a seconda della posizione della data factory o dell'istanza dell'area di lavoro di Synapse. Per trovare l'URL del servizio, usare la pagina Gestione dell'UI nella data factory o nell'istanza di Azure Synapse per trovare Integration runtimes e fare clic sul runtime di integrazione autogestito per modificarlo. Selezionare la scheda Nodi e fare clic su Visualizza URL del servizio.

     La risposta prevista è la seguente:

     

  3. Se non si riceve la risposta prevista, usare uno dei metodi seguenti in base alla situazione:

     • Se viene visualizzato il messaggio "Non è stato possibile risolvere il nome remoto", significa che è presente un problema a livello di DNS (Domain Name System). Per risolvere il problema, contattare il team addetto alla rete.
     • Se viene visualizzato un messaggio "certificato ssl/tls non attendibile", controllare il certificato (https://wu2.frontend.clouddatahub.net/) per verificare se è attendibile nel computer e quindi installare il certificato pubblico usando Gestione certificati. Questa azione dovrebbe attenuare il problema.
     • Passare a Windows>Event viewer (logs)>Applications and Services Logs>Integration Runtime, e verificare la presenza di eventuali errori causati da DNS, una regola del firewall, o impostazioni di rete aziendale. Se si rileva un errore di questo tipo, forzare la chiusura della connessione. Poiché ogni società ha le sue impostazioni di rete personalizzate, per risolvere questi problemi contattare il team addetto alla rete.

  4. Se il proxy è stato configurato nel runtime di integrazione self-hosted, verificare che il server proxy possa accedere all'endpoint del servizio. Per un comando di esempio, vedere PowerShell, Web Requests, and Proxies.

     $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
     

  La risposta prevista è la seguente:

  

  Nota

  Considerazioni sui proxy:

  • Verificare se il server proxy deve essere inserito nell'elenco Destinatari attendibili. In tal caso, verificare che questi domini siano nell'elenco Destinatari attendibili.
  • Verificare se il certificato wu2.frontend.clouddatahub.net/ SSL/TLS è attendibile nel server proxy.
  • Se si usa l'autenticazione Active Directory sul proxy, sostituire l'account del servizio con l'account utente che può accedere al proxy come "servizio Integration Runtime".

Messaggio di errore: il nodo del runtime di integrazione self-hosted/runtime di integrazione self-hosted è Inattivo/è nello stato "In esecuzione (limitato)"

• Causa

  Il nodo di runtime integrato self-hosted potrebbe avere lo stato Inattivo, come illustrato nello screenshot seguente:

  

  Questo comportamento si verifica quando i nodi non possono comunicare tra loro.

• Risoluzione

  1. Accedere alla macchina virtuale ospitata dal nodo. In Applicazioni e log dei servizi>Integration Runtime aprire Visualizzatore eventi e filtrare i log degli errori.

  2. Verificare se un log degli errori contiene l'errore seguente:

     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. Se viene visualizzato questo errore, eseguire il comando seguente in una finestra del prompt dei comandi:

     telnet 10.2.4.10 8060
     

  4. Se viene visualizzato l'errore della riga di comando "Impossibile aprire la connessione all'host" visualizzato nello screenshot seguente, contattare il reparto IT per assistenza per risolvere il problema. Dopo aver completato telnet, contattare supporto tecnico Microsoft se si verificano ancora problemi con lo stato del nodo del runtime di integrazione.

     

  5. Verificare se il log degli errori contiene la voce seguente:

     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. Per risolvere il problema, provare uno o entrambi i metodi seguenti:

     • Inserire tutti i nodi nello stesso dominio.
     • Aggiungere l'indirizzo IP al mapping dell'host in tutti i file host della macchina virtuale ospitata.

Problema di connettività tra il runtime di integrazione self-hosted e l'istanza di Azure Synapse o della data factory oppure tra il runtime di integrazione self-hosted e l'origine dati o il sink

Per risolvere il problema di connettività di rete, è necessario sapere come raccogliere la traccia di rete, capire come usarla e analizzare la traccia di Microsoft Network Monitor (Netmon) prima di applicare gli strumenti Netmon in casi reali del runtime di integrazione self-hosted.

• Sintomi

  In alcuni casi potrebbe essere necessario risolvere alcuni problemi di connettività tra il runtime di integrazione self-hosted e la data factory o l'istanza di Azure Synapse, come illustrato nello screenshot seguente o tra il runtime di integrazione self-hosted e l'origine dati o il sink.

  

  In entrambi i casi è possibile che si verifichino gli errori seguenti:

  • Copia non riuscita con errore:Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Impossibile connettersi al server SQL: 'IP address'

  • "Si sono verificati uno o più errori. Si è verificato un errore durante l'invio della richiesta. Connessione sottostante chiusa: Errore imprevisto durante un'operazione di ricezione. Impossibile leggere i dati dalla connessione di trasporto: una connessione esistente è stata chiusa forzatamente dall'host remoto. Una connessione esistente è stata chiusa forzatamente dall'ID attività dell'host remoto."

• Risoluzione

  Quando si verificano gli errori precedenti, risolverli seguendo le istruzioni riportate in questa sezione.

  • Raccogliere una traccia Netmon per l'analisi:

    1. È possibile impostare il filtro per visualizzare una reimpostazione dal server sul lato client. Nello screenshot di esempio seguente è possibile notare che il lato server è il server Data Factory.

       

    2. Quando si ottiene il pacchetto di reimpostazione, è possibile trovare la conversazione seguendo il protocollo TCP (Transmission Control Protocol).

       Screenshot della conversazione TCP.

    3. Ottenere la conversazione tra il client e il server Data Factory rimuovendo il filtro.

  • Un'analisi della traccia Netmon raccolta mostra che il totale TTL (Time to Live) è 64. In base ai valori indicati nell'articolo Informazioni di base sul time to live (TTL) e sul limite di hop, estratti nell'elenco seguente, è possibile notare che si tratta del sistema Linux che reimposta il pacchetto e causa la disconnessione.

    I valori predefiniti TTL e Hop Limit variano tra diversi sistemi operativi, come indicato di seguito:

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

    

    Nell'esempio precedente, il TTL viene visualizzato come 61 anziché 64, perché quando il pacchetto di rete raggiunge la destinazione, deve passare attraverso vari hop, ad esempio router o dispositivi di rete. Il numero di router o dispositivi di rete viene dedotto per produrre il TTL finale.

    In questo caso, è possibile vedere che è possibile inviare una reimpostazione dal sistema Linux con TTL 64.

  • Per confermare l'origine del dispositivo di ripristino, controllare il quarto hop dal runtime di integrazione self-hosted.

    Pacchetto di rete dal sistema Linux A con TTL 64 -> B TTL 64 meno 1 = 63 -> C TTL 63 meno 1 = 62 -> TTL 62 meno 1 = 61 runtime di integrazione self-hosted

  • In una situazione ideale, il numero di hop del TTL sarà 128, il che indica che il sistema operativo Windows sta eseguendo l'istanza di data factory. Come illustrato nell'esempio seguente, 128 meno 107 = 21 hop, il che significa che 21 hop per il pacchetto sono stati inviati dall'istanza di data factory al runtime di integrazione self-hosted durante l'handshake TCP 3.

    

    È quindi necessario coinvolgere il team di rete per verificare quale sia il quarto hop dal runtime di integrazione self-hosted. Se si tratta del firewall, come nel sistema Linux, controllare i log per verificare il motivo per cui il dispositivo reimposta il pacchetto dopo l'handshake TCP 3.

    Se non si è certi di dove indagare, provare a ottenere la traccia Netmon sia dal runtime di integrazione self-hosted che dal firewall durante il periodo problematico. Questo approccio consente di capire quale dispositivo potrebbe aver reimpostato il pacchetto e causato la disconnessione. In questo caso, è anche necessario coinvolgere il team di rete per proseguire.

Analizzare la traccia Netmon

Quando si tenta di eseguire telnet 8.8.8.8 888 con la traccia Netmon raccolta, verrà visualizzata la traccia negli screenshot seguenti:

Le immagini precedenti mostrano che non è stato possibile stabilire una connessione TCP al server 8.8.8.8 sulla porta 888, quindi vedi due pacchetti aggiuntivi SynReTransmit lì. Poiché la sorgente SELF-HOST2 non è riuscita a connettersi a 8.8.8.8 al primo pacchetto, continuerà a tentare di stabilire la connessione.

Gli scenari riusciti sono illustrati negli esempi seguenti:

• Se è possibile telnet 8.8.8.8 53 senza problemi, è presente un handshake TCP 3 riuscito e la sessione termina con un handshake TCP 4.

  

  

• L'handshake TCP 3 precedente produce il flusso di lavoro seguente:

  

• L'handshake TCP 4 per completare la sessione è illustrato dai flussi di lavoro seguenti:

  

  

Determinare se questa notifica influisce sull'utente

Questa notifica si applica agli scenari seguenti:

Scenario 1: Comunicazione in uscita da un runtime di integrazione self-hosted in esecuzione in locale dietro un firewall aziendale

Come determinare se si è interessati:

• Non si è interessati se si definiscono regole del firewall basate su nomi di dominio completi (FQDN) che usano l'approccio descritto in Impostare una configurazione del firewall e un elenco di indirizzi IP consentiti.

• Si è interessati se si abilita in modo esplicito l'elenco di indirizzi IP in uscita consentiti nel firewall aziendale.

  Se sei interessato, esegui la seguente azione: entro l'8 novembre 2020, invia una notifica al team della rete per aggiornare la configurazione di rete per utilizzare gli indirizzi IP della data factory più aggiornati. Per scaricare gli indirizzi IP più recenti, vai a Scoprire i tag del servizio utilizzando file JSON scaricabili.

Scenario 2: Comunicazione in uscita da un runtime di integrazione self-hosted in esecuzione in una macchina virtuale Azure all'interno di una rete virtuale gestita dal cliente Azure

Come determinare se si è interessati:

• Verificare se sono presenti regole del gruppo di sicurezza di rete in uscita in una rete privata che contiene il runtime di integrazione self-hosted. Se non ci sono restrizioni in uscita, non si è interessati.

• Se sono presenti restrizioni per le regole in uscita, verificare se si usano tag del servizio. Se si utilizzano tag di servizio, non si è influenzati. Non è necessario modificare o aggiungere elementi, perché il nuovo intervallo IP si trova sotto i tag del servizio esistenti.

  

• You Si è interessati se si abilita in modo esplicito l'elenco di indirizzi IP in uscita consentiti nell'impostazione delle regole del gruppo di sicurezza di rete nella rete virtuale di Azure.

  Se sei coinvolto, esegui la seguente azione: entro l'8 novembre 2020, notifica il team dell'infrastruttura di rete per aggiornare le regole NSG nella configurazione della rete virtuale Azure utilizzando gli ultimi indirizzi IP del data factory. Per scaricare gli indirizzi IP più recenti, visitare per individuare i tag del servizio utilizzando i file JSON scaricabili.

Scenario 3: Comunicazione in uscita da SSIS Integration Runtime in una rete virtuale Azure gestita dal cliente

Come determinare se si è interessati:

• Verificare se sono presenti regole NSG in uscita all'interno di una rete privata che include SQL Server Integration Services (SSIS) Integration Runtime. Se non sono presenti restrizioni in uscita, non sarete coinvolti.

• Se sono presenti restrizioni per le regole in uscita, verificare se si usano tag del servizio. Se usi i tag di servizio, non ne sei influenzato. Non è necessario modificare o aggiungere elementi perché il nuovo intervallo IP si trova sotto i tag del servizio esistenti.

• You Si è interessati se si abilita in modo esplicito l'elenco di indirizzi IP in uscita consentiti nell'impostazione delle regole del gruppo di sicurezza di rete nella rete virtuale di Azure.

  Se si è interessati, eseguire l'azione seguente: entro l'8 novembre 2020, inviare una notifica al team dell'infrastruttura di rete per aggiornare le regole del gruppo di sicurezza di rete nella configurazione della rete virtuale di Azure per usare gli indirizzi IP più recenti di Data Factory. Per scaricare gli indirizzi IP più recenti, vai a Scoprire i tag del servizio utilizzando i file JSON scaricabili.

Non è possibile stabilire una relazione di trust per il canale sicuro SSL/TLS

• Sintomi

  Il runtime di integrazione self-hosted non è riuscito a connettersi al servizio Azure Data Factory o Azure Synapse.

  Quando si controlla il registro eventi del runtime di integrazione autonomo dopo aver aperto Windows>Visualizzatore eventi (registri)>Registri applicazioni e servizi>Runtime di integrazione, verrà visualizzato il seguente messaggio di errore.

  "La connessione sottostante è stata chiusa: non è stato possibile stabilire una relazione di trust per il canale sicuro SSL/TLS. Il certificato remoto non è stato ritenuto valido dalla procedura di convalida."

  Il modo più semplice per controllare il certificato del server del servizio è aprire l'URL del servizio nel browser. Ad esempio, aprire il collegamento al certificato del server (https://eu.frontend.clouddatahub.net/) nel computer in cui è installato il runtime di integrazione self-hosted e quindi visualizzare le informazioni sul certificato del server.

  

  

• Causa

  Le cause del problema possono essere due:

  • Motivo 1: l'autorità di certificazione radice del certificato del server del servizio non è considerato attendibile nel computer in cui è installato il runtime di integrazione self-hosted.
  • Motivo 2: Nell'ambiente è in uso un proxy, il certificato del servizio viene sostituito dal proxy e il certificato del server sostituito non è considerato attendibile dal computer su cui è installato l'IR self-hosted.

• Risoluzione

  • Per il motivo 1: assicurarsi che il certificato del server del servizio e la relativa catena di certificati siano considerati attendibili dal computer in cui è installato il runtime di integrazione self-hosted.
  • Per il motivo 2: considerare attendibile l'autorità di certificazione radice sostituita nel computer del runtime di integrazione self-hosted oppure configurare il proxy in modo che non sostituisca il certificato del server del servizio.

  Per altre informazioni sull'attendibilità dei certificati in Windows, vedere Installazione del certificato radice attendibile.

• Altre informazioni
  È stato presentato un nuovo certificato SSL, firmato da DigiCert. Controllare se DigiCert Global Root G2 si trova nell'autorità di certificazione considerata attendibile.

  

  Se non si trova nell'autorità di certificazione radice attendibile, scaricalo qui.

Contenuto correlato

Per altre informazioni sulla risoluzione dei problemi, provare le risorse seguenti:

• Blog di Data Factory
• Richieste di funzionalità di Data Factory

• video di Azure

• Pagina Microsoft Q&A
• Forum di Stack Overflow per Data Factory
• Informazioni su X relative a Data Factory
• Guida alle prestazioni dei flussi di dati di mapping