Risolvere i problemi relativi al runtime di integrazione self-hosted (SHIR) di Microsoft Purview

Questo articolo illustra i metodi di risoluzione dei problemi comuni per il runtime di integrazione self-hosted (SHIR) in Microsoft Purview.

Il runtime di integrazione self-hosted (SHIR) viene usato anche da Azure Data Factory e Azure Synapse Analytics. Anche se molti dei passaggi di risoluzione dei problemi si sovrappongono, seguire questa guida per risolvere i problemi relativi a SHIR per tali prodotti:

• Risolvere i problemi di SHIR per Azure Data Factory e analisi Azure Synapse

Raccogliere log di runtime di integrazione self-hosted specifici di Microsoft Purview

Per le analisi di Microsoft Purview non riuscite eseguite in un runtime di integrazione self-hosted, il servizio supporta la visualizzazione e il caricamento dei log degli errori da Windows Visualizzatore eventi.

È possibile cercare eventuali errori visualizzati nella guida agli errori riportata di seguito. Per ottenere supporto e indicazioni sulla risoluzione dei problemi di 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 windows Visualizzatore eventi.
   2. Deselezionare i log del Visualizzatore eventi di Windows 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 ulteriori informazioni su Microsoft, selezionare Invia log.

   Verrà visualizzata la finestra Condividi i log del runtime di integrazione self-hosted (SHIR) con Microsoft .

   

5. Quando i log vengono caricati, mantenere un record dell'ID report da usare se si contatta il supporto tecnico Microsoft.

   

Errore o errore generale SHIR del runtime di integrazione self-hosted

Esistono molti errori, avvisi e problemi comuni tra Purview SHIR, Azure Data Factory o Azure Synapse SHIR. La guida seguente illustra molti dei problemi più comuni.

Errore o errore generale del runtime di integrazione self-hosted

Problema di memoria insufficiente

Sintomi

Si verifica un errore OutOfMemoryException (OOM) quando si tenta di eseguire un'analisi con un runtime di integrazione self-hosted.

Causa

Una nuova analisi può generare un errore OOM se il computer a runtime di integrazione riscontra un utilizzo momentaneo della memoria elevata. Il problema potrebbe essere causato da un volume elevato di attività simultanee o da una quantità ridotta di memoria e l'errore è dovuto alla progettazione.

Risoluzione

Controllare l'utilizzo delle risorse per verificare se qualsiasi altro software è in esecuzione contemporaneamente e verificare che il computer SHIR soddisfi le configurazioni consigliate.

Il runtime di integrazione self-hosted non è riuscito a caricare file o assembly

Sintomi

Viene visualizzato il messaggio di errore seguente:

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

Ecco un messaggio di errore più specifico:

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

Causa

In Monitoraggio processi è possibile visualizzare il risultato seguente:

Consiglio

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. Fondamentalmente, il processo carica la DLL prima dalla cartella GAC , quindi dalla cartella Shared e infine dalla cartella Gateway . È quindi possibile caricare la DLL da qualsiasi percorso utile.

Risoluzione

Il file System.ValueTuple.dll si trova 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 altri problemi di file o assembly mancanti.

Ulteriori informazioni

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 notare chiaramente che l'assembly System.ValueTuple è mancante. 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":"Impossibile caricare il file o l'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.

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:

"Chiave di autenticazione non ancora assegnata"

Causa

Il nodo del runtime di integrazione self-hosted o il runtime di integrazione self-hosted logico nel portale di Microsoft Purview è stato eliminato oppure è stata eseguita una disinstallazione pulita.

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 Netwrix Rilevare chi ha eliminato un file dai file server Windows.

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

Sintomi

• È stato importato un file PFX nell'archivio certificati.
• Quando è stato selezionato il certificato tramite l'interfaccia utente Configuration Manager del runtime di integrazione, viene visualizzato il messaggio di errore seguente:

"Impossibile modificare la modalità di crittografia delle comunicazioni Intranet. È probabile che il certificato "<nome> certificato" non disponga di una chiave privata in grado di scambiare chiavi o che il processo non disponga dei diritti di accesso per la chiave privata. Per informazioni dettagliate, vedere l'eccezione interna.

Causa

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

Risoluzione

• Per gestire l'interfaccia utente, usa un account con privilegi appropriati per accedere alla chiave privata.
• Importare il certificato eseguendo il comando seguente:

certutil -importpfx FILENAME.pfx AT_KEYEXCHANGE

Messaggio di errore UserErrorJreNotFound quando si esegue un'analisi

Sintomi

Quando si tenta di analizzare un'origine dati usando uno strumento o un programma basato su Java (ad esempio, file di formato 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 computer del nodo Integration Runtime (self-hosted). Nota: Integration Runtime a 64 bit richiedono JRE a 64 bit e Integration Runtime a 32 bit richiedono JRE a 32 bit,Source=Microsoft.DataTransfer.Common,''Type=System.DllNotFoundException,Message=Impossibile caricare la DLL 'jvm.dll': impossibile trovare il modulo specificato. (Eccezione da HRESULT: 0x8007007E),Source=Microsoft.DataTransfer.Richfile.HiveOrcBridge

Causa

Questo problema si verifica per 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

Seguire attentamente i passaggi in questa sezione. L'errata modifica del Registro di sistema può causare seri problemi. Prima di apportare le modifiche, eseguire il backup del Registro di sistema per il ripristino nel caso si verifichino dei 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:

   • Nella cartella deve essere installato JRE a 64 bit per Integration Runtime ADF a 64 bit:C:\Program Files\Java\

     Nota

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

   • JRE 11 è compatibile per l'analisi. Anche JRE 8 è compatibile, ma le versioni precedenti a JRE 8 non sono state convalidate per questo uso.

2. Controllare nel Registro di sistema le impostazioni appropriate. A tal fine, attenersi alla seguente procedura:

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

4. Nel riquadro di spostamento individuare la sottochiave seguente:

   HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment.

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

   

5. Nel riquadro di spostamento individuare una sottochiave che corrisponde 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 JRE.

   

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

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

   

7. Controllare se questa cartella contiene un file jvm.dll. In caso contrario, verificare la presenza del file nella bin\client cartella .

   

Nota

• Se una di queste configurazioni non è come descritto in questi passaggi, usare il programma di installazione di Windows JRE per risolvere i problemi.
• Se tutte le configurazioni in questi passaggi sono corrette come descritto, potrebbe essere presente una libreria di runtime VC++ mancante nel sistema. È possibile risolvere questo problema installando il pacchetto ridistribuibile di VC++ 2010.

Configurazione del runtime di integrazione self-hosted

Errore di registrazione del runtime di integrazione

Sintomi

A volte è possibile 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, si potrebbe notare che il runtime di integrazione smette di funzionare e viene 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 del servizio. Quando si modifica l'account del servizio in un altro account, le autorizzazioni di tutte le risorse dipendenti rimangono invariate.

Risoluzione

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

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

  1. Controllare l'account del servizio di accesso DIAHostService nel pannello del 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 avere autorizzazioni di lettura/scrittura.

       

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

       1. Eseguire una disinstallazione pulita del runtime di integrazione self-hosted corrente.
       2. Installare i bit del runtime di integrazione self-hosted.
       3. Modificare l'account del servizio eseguendo le operazioni seguenti:
          1. Passare alla cartella di installazione del runtime di integrazione self-hosted e quindi passare alla cartella Microsoft Integration Runtime\4.0\Shared.
          2. 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>"
          3. Se si vuole passare all'account LocalSystem, assicurarsi di usare il formato corretto per questo account: dmgcmd.exe -SwitchServiceAccount "NT Authority\System" ""
          4. Non usare questo formato:dmgcmd.exe -SwitchServiceAccount "LocalSystem" ""
          5. Facoltativamente, poiché il sistema locale dispone di privilegi più elevati rispetto all'amministratore, è anche possibile modificarlo direttamente in "Servizi".
          6. È possibile usare un utente locale/di dominio per l'account di accesso del servizio di integrazione.
       4. 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 pannello del 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 specifico, provare a raccogliere i log eventi di Windows seguenti:

• Log applicazioni e servizi > Integration Runtime
• 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 Configuration Manager.

Causa

A partire dalla versione di Integration Runtime 3.0, il pulsante Registra nei nodi di runtime di integrazione esistenti è stato rimosso per abilitare un ambiente più pulito e sicuro. Se un nodo è stato registrato in un runtime di integrazione, indipendentemente dal fatto che sia online o meno, registrarlo nuovamente in un altro runtime di integrazione disinstallando il nodo precedente e 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 del programma di installazione del runtime di integrazione, passare all'Area download per scaricare il runtime di integrazione più recente.

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

Impossibile registrare il runtime di integrazione self-hosted a causa di 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 non ripristinabile 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 recuperabile durante una ricerca nel database in System.Net.Dns.GetAddrInfo(String name).

Causa

Il problema si verifica in genere quando viene risolto localhost.

Resolition

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. È possibile che si verifichino problemi di installazione per i motivi seguenti:

• Spazio su disco disponibile 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 attendibile.When you install a self-hosted IR via Microsoft Integration Runtime Configuration Manager, a certificate with a trusted certificate authority (CA) is generated. 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 a Integration Runtime account del servizio l'accesso al certificato '<nome> certificato'. Codice di errore 103"

Causa

Il certificato usa l'archiviazione del provider di archiviazione chiavi (KSP), che non è ancora supportata. Ad oggi, il runtime di integrazione self-hosted supporta solo l'archiviazione del provider di servizi di crittografia (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 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 collegamenti per il download della versione 4.x più recente e delle due versioni 5.x più recenti.

Per i clienti Azure Data Factory v2 e Azure Synapse:

• Se l'aggiornamento automatico è attivato 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 è attivato 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 di .NET Framework Runtime nel portale e nel client di 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 l'ultima versione di 5.x 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 di .NET Framework Runtime.

Per Azure Data Factory clienti v1:

• Il runtime di integrazione self-hosted 5.X non supporta Azure Data Factory v1.
• Il runtime di integrazione self-hosted verrà aggiornato automaticamente alla versione più recente di 4.x. E la versione più recente di 4.x non scadrà.
• Se si tenta di installare manualmente il runtime di integrazione self-hosted 5.x e registrare la chiave, si riceverà una notifica che il runtime di integrazione self-hosted 5.x non supporta Azure Data Factory v1.

Problemi di connettività del runtime di integrazione self-hosted

Il runtime di integrazione self-hosted non può connettersi al servizio cloud

Sintomi

Quando si tenta di registrare il runtime di integrazione self-hosted, Configuration Manager 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. Questo problema è in genere 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 non è configurato alcun proxy nel runtime di integrazione self-hosted, ovvero l'impostazione predefinita, eseguire il comando 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 del percorso della data factory o dell'istanza dell'area di lavoro 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.

3. Di seguito è riportata la risposta prevista:

   

4. Se non si riceve la risposta prevista, usare uno dei metodi seguenti, in base alle esigenze:

   • Se viene visualizzato un messaggio "Impossibile risolvere il nome remoto", si verifica un problema dns (Domain Name System). Per risolvere il problema, contattare il team di rete.
   • Se si riceve un messaggio "ssl/tls cert is not trusted", 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 aVisualizzatore eventi diWindows> (log)>Registri >applicazioni e serviziIntegration Runtime e verificare la presenza di eventuali errori causati da DNS, una regola del firewall o le impostazioni di rete aziendale. Se si verifica un errore di questo tipo, chiudere forzatamente la connessione. Poiché ogni azienda ha le proprie impostazioni di rete personalizzate, contattare il team di rete per risolvere questi problemi.

5. Se "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, richieste Web e proxy.

    $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
   

Di seguito è riportata la risposta prevista:

Nota

Considerazioni sul proxy:

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

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

Sintomi

Il runtime di integrazione self-hosted non è riuscito a connettersi a Microsoft Purview.

Quando si controlla il registro eventi del runtime di integrazione self-hosted dopo essere andato alVisualizzatore eventi diWindows> (log)>Registri >applicazioni e serviziIntegration Runtime, verrà 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 è valido in base alla procedura di convalida.

Il modo più semplice per controllare il certificato server del servizio consiste nell'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

Esistono due possibili motivi per questo problema:

• Motivo 1: l'autorità di certificazione radice del certificato server del servizio non è attendibile nel computer in cui è installato il runtime di integrazione self-hosted.
• Motivo 2: si usa un proxy nell'ambiente, il certificato server del servizio viene sostituito dal proxy e il certificato 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 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 la CA radice sostituita nel computer del runtime di integrazione self-hosted oppure configurare il proxy per non sostituire il certificato server del servizio.

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

Ulteriori informazioni

È stato implementato un nuovo certificato SSL firmato da DigiCert. Verificare se la radice globale G2 di DigiCert si trova nella CA radice attendibile.

Se non si tratta della CA radice attendibile, scaricarla qui.

Operazioni successive

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

• Introduzione a Microsoft Purview
• Creare e gestire runtime di integrazione self-hosted SHIR in Purview
• Domande frequenti su Microsoft Purview