Risolvere i problemi relativi al runtime di integrazione self-hosted

SI APPLICA 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 attività, nella colonna Errore selezionare il pulsante evidenziato per visualizzare i log attività, come illustrato nello screenshot seguente:

   • Azure Data Factory
   • Azure Synapse

   

   I log attività vengono visualizzati per l'esecuzione dell'attività non riuscita.

   

3. Per ulteriore assistenza, selezionare Invia log.

   Viene visualizzata la finestra Condividi 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 runtime di integrazione 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 da Windows Visualizzatore eventi.

È possibile cercare eventuali errori visualizzati nella guida all'errore seguente. Per ottenere supporto e indicazioni sulla risoluzione dei problemi relativi a SHIR, potrebbe essere necessario generare un ID segnalazione errori e contattare il supporto tecnico 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 Visualizzatore eventi di Windows.
   2. Deselezionare 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 di Microsoft Purview e avviare l'analisi.

2. Dopo che l'analisi mostra lo stato Non riuscito, tornare alla macchina virtuale shir o al computer e aggiornare il visualizzatore eventi nella sezione Integration Runtime .

3. I log attività vengono visualizzati per l'esecuzione dell'analisi non riuscita.

4. Per ulteriore assistenza da Microsoft, selezionare Invia log.

   Viene visualizzata la finestra Condividi i log del runtime di integrazione self-hosted 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 runtime di integrazione condiviso, è possibile caricare solo i log correlati all'attività non riuscita.

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 di attività simultanee nel nodo del runtime di integrazione. 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 conteggio dei core logici e per determinare il numero di core logici del computer, vedere Quattro 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 del runtime di integrazione self-hosted

• Sintomi

  Il nodo di lavoro del runtime di integrazione self-hosted ha segnalato il messaggio di errore seguente:

  "Non è stato possibile 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. Impossibile verificare una catena di trust del certificato utilizzato. 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 certificati, quindi selezionare Gestisci i 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, in una finestra del prompt dei comandi eseguire il comando seguente. Assicurarsi di sostituire <il percorso> del certificato e <il 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. Verificare la presenza di errori nel file di output con estensione txt. È 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 dell'evento di revoche di certificati) o OCSP (protocollo di stato del certificato online), è possibile controllare 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 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. Activity ID: 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\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.

  

• Risoluzione

  Il file System.ValueTuple.dll è disponibile 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 di 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":"Could not load file or assembly 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' o una delle relative 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 del runtime di integrazione self-hosted è 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 nell'articolo di Netwrix Detect who deleted a file from your Windows file servers (Rilevare chi ha eliminato un file dai file Windows file server).

  

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:

  • "The driver of source cannot be found in destination IR" (Impossibile trovare il driver dell'origine nel runtime di integrazione 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 il runtime di integrazione è installato nell'archivio dati di origine o di destinazione oppure in 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), è possibile che la copia in un'attività non venga completata anche se è installato il runtime di integrazione. 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 runtime di integrazione dall'archivio dati 1 ad Archiviazione BLOB di Azure
  • Copiare un altro runtime di integrazione da Archiviazione BLOB di Azure all'archivio dati 2.

  Questa soluzione potrebbe simulare la necessità di usare il runtime di integrazione per creare un bridge che connetta due archivi dati disconnessi.

Il problema di sincronizzazione delle credenziali causa la perdita delle credenziali da disponibilità elevata

• Sintomi

  Se la credenziali dell'origine dati "XXXXXXXXXX" vengono eliminate dal nodo del runtime di integrazione corrente con il 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.

  • Dopo avere selezionato il certificato tramite l'interfaccia utente di Configuration Manager di runtime di integrazione, si riceve il messaggio di errore seguente:

    "Failed to change Intranet communication encryption mode. È 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
    

Problema relativo a nodi del runtime di integrazione self-hosted non sincronizzati

• 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:

  "The Integration Runtime (Self-hosted) node is trying to sync the credentials across nodes. It may take several minutes." (Il nodo del runtime di integrazione (self-hosted) sta tentando di sincronizzare le credenziali nei nodi. L'operazione 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 log del runtime di integrazione self-hosted seguenti:

  [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 dell'entità servizio 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 self-hosted (NT SERVICE\DIAHostService) alle autorizzazioni della chiave privata. È possibile applicare i passaggi seguenti:

  1. Aprire il comando Esegui di 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 delle cartelle a sinistra selezionare Radice della console -> Certificati (computer locale) -> Personale -> Certificati.
     2. Fare clic con il pulsante destro del mouse sull'MDM Microsoft Intune Beta.
     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 in Azure

• Sintomi

  Quando si tenta di copiare contenuti in Microsoft Azure usando uno strumento o un programma basato su Java, ad esempio copiando file di 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,Message=Unable to load DLL 'jvm.dll': Non è possibile trovare il modulo specificato. (Exception from 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 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:

     • JRE a 64 bit per ADF Integration Runtime 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 Temlation 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 bin\client cartella .

     

  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

  In alcuni casi potrebbe essere necessario eseguire un runtime di integrazione self-hosted in un account diverso per uno dei motivi seguenti:

  • I criteri aziendali non consentono l'account del 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. Non è possibile connettersi al servizio host di Integration Runtime (self-hosted)".

  

• Causa

  Molte risorse vengono concesse solo all'account del 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 riquadro Servizio 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 <utente e <password> con il proprio 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 usare un utente locale/di dominio per l'account di accesso al servizio runtime di integrazione.

         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. Controllare l'account del servizio di accesso DIAHostService nel riquadro Servizio Windows.

       

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

       

• Ulteriori informazioni

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

  • Runtime di integrazione dei log > di applicazioni e servizi
  • Applicazione Log > di 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 Di Configuration Manager.

  

• Causa

  A partire dal rilascio di Integration Runtime 3.0, il pulsante Registra nei nodi esistenti del runtime di integrazione è stato rimosso in modo da offrire 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.

Non è possibile registrare il runtime di integrazione self-hosted a causa del localhost

• Sintomi

  Non è possibile registrare il runtime di integrazione self-hosted in un nuovo computer quando si usa 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.

  Dettagli eccezione: 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 self-hosted 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 Windows NT è 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 di integrazione non è riuscito a recuperare l'accesso al certificato

• Sintomi

  Quando si installa un runtime di integrazione self-hosted tramite Microsoft Integration Runtime Configuration Manager, 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 usa l'archiviazione del provider di archiviazione chiavi (KSP), che non è ancora supportata. Fino ad oggi, il runtime di integrazione self-hosted supporta solo l'archiviazione CSP (Cryptographic Service Provider).

• 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 self-hosted 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 di Azure Data Factory v2 e Azure Synapse:

• Se l'aggiornamento automatico è attivo e il runtime di .NET Framework è già stato aggiornato 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 self-hosted.
• Se l'aggiornamento automatico è disattivato e il runtime di .NET Framework è già stato aggiornato 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à prima necessario aggiornare la versione del runtime di .NET Framework.

Problemi di connettività del runtime di integrazione self-hosted

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:

  "Si è verificato un errore del nodo di integration Runtime (self-hosted) 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 Gestisci dell'interfaccia utente nella data factory o nell'istanza di Azure Synapse per trovare i runtime di integrazione e fare clic sul runtime di integrazione self-hosted 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>Visualizzatore eventi (log) >Registri applicazioni e servizi>Integration Runtime e verificare la presenza di errori causati da DNS, da una regola del firewall o dalle impostazioni della 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 sul 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 self-hosted è inattivo/ 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 Registri applicazioni e servizi>Integration Runtime aprire il 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 eseguito correttamente telnet, se si verificano ancora problemi con lo stato del nodo del runtime di integrazione, contattare il supporto tecnico Microsoft.

     

  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 la data factory o l'istanza di Azure Synapse o 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, comprendere come usarla e analizzare la traccia di Microsoft Network Monitor (Netmon) prima di applicare netmon Tools in casi reali dal 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:

  • "La copia non è riuscita. Errore:Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Impossibile connettersi al server SQL: 'indirizzo IP'"

  • "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 dati dalla connessione del 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).

       

    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, estratto 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 verificare la provenienza del dispositivo di reimpostazione, 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 TTL sarebbe 128, il che significa che il sistema operativo Windows esegue 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 che cosa 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 tempo 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 lato server 8.8.8.8 sulla porta 888, quindi sono presenti due pacchetti aggiuntivi SynReTransmit . Poiché self-host2 di origine non è riuscito a connettersi alla versione 8.8.8.8 con il primo pacchetto, continuerà a provare a 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 Configurare una configurazione del firewall e consentire gli indirizzi IP.

• L'utente è interessato se si abilita in modo esplicito l'elenco di indirizzi IP in uscita nel firewall aziendale.

  Se si è interessati, eseguire l'azione seguente: entro l'8 novembre 2020, inviare una notifica al team dell'infrastruttura di rete per aggiornare la configurazione di rete per usare gli indirizzi IP della data factory più recenti. Per scaricare gli indirizzi IP più recenti, passare a Individuare i tag del servizio usando i file JSON scaricabili.

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

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 sono presenti restrizioni in uscita, non si è interessati.

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

  

• L'utente è interessato se si abilita in modo esplicito l'elenco di indirizzi IP in uscita 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 della data factory più recenti. Per scaricare gli indirizzi IP più recenti, passare a Individuare i tag del servizio usando i file JSON scaricabili.

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

Come determinare se si è interessati:

• Verificare se sono presenti regole del gruppo di sicurezza di rete in uscita in una rete privata che contiene SQL Server Integration Services (SSIS) Integration Runtime. Se non sono presenti restrizioni in uscita, non si è interessati.

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

• L'utente è interessato se si abilita in modo esplicito l'elenco di indirizzi IP in uscita 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 della data factory più recenti. Per scaricare gli indirizzi IP più recenti, passare a Individuare i tag del servizio usando 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 self-hosted dopo aver eseguito il passaggio a Visualizzatore eventi di Windows>(log)>Applications and Services Logs>Integration Runtime, viene visualizzato il messaggio di errore seguente.

  "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 controlla certificato 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: è in uso un proxy nell'ambiente, il certificato del server del servizio è sostituito dal proxy e il certificato del server sostituito non è considerato attendibile dal computer in cui è installato il runtime di integrazione 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 sulla considerazione di attendibilità dei certificati in Windows, vedere Installare il certificato radice trusted.

• 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 nella CA radice attendibile, scaricarla 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 Stack Overflow per Data Factory
• Informazioni su X su Data Factory
• Guida alle prestazioni dei flussi di dati per mapping