Resolver problemas do runtime de integração autoalojado do Microsoft Purview (SHIR)

Este artigo explora métodos comuns de resolução de problemas para o runtime de integração autoalojado (SHIR) no Microsoft Purview.

O runtime de integração autoalojado (SHIR) também é utilizado pelo Azure Data Factory e pelo Azure Synapse Analytics. Embora muitos dos passos de resolução de problemas se sobreponham, siga este guia para resolver problemas do SHIR para esses produtos:

• Troubleshoot SHIR for Azure Data Factory and Azure Synapse Analytics (Resolver problemas do SHIR para o Azure Data Factory e o Azure Synapse Analytics)

Recolher registos de runtime de integração autoalojados do SHIR específicos do Microsoft Purview

Para análises do Microsoft Purview falhadas que estão em execução num IR autoalojado, o serviço suporta a visualização e carregamento de registos de erros a partir do windows Visualizador de Eventos.

Pode procurar quaisquer erros que veja no guia de erros abaixo. Para obter suporte e documentação de orientação de resolução de problemas do SHIR, poderá ter de gerar um ID do relatório de erros e contactar o suporte da Microsoft.

Para gerar o ID do relatório de erros para Suporte da Microsoft, siga estas instruções:

1. Antes de iniciar uma análise no portal de governação do Microsoft Purview:

   1. Navegue para o computador onde o runtime de integração autoalojado está instalado e abra o windows Visualizador de Eventos.
   2. Limpe os registos do visualizador de eventos do Windows na secção Integration Runtime. Clique com o botão direito do rato nos registos e selecione a opção limpar registos.
   3. Navegue de volta para o portal de governação do Microsoft Purview e inicie a análise.

2. Assim que a análise mostrar status Falhou, navegue de volta para a VM do SHIR ou para o computador e atualize o visualizador de eventos na secção Integration Runtime.

3. Os registos de atividades são apresentados para a execução da análise falhada.

4. Para obter mais assistência da Microsoft, selecione Enviar Registos.

   A janela Partilhar o runtime de integração autoalojado (SHIR) com a Microsoft é aberta.

   

5. Quando os registos forem carregados, mantenha um registo do ID do Relatório a utilizar se contactar o suporte da Microsoft.

   

Erro ou falha geral do SHIR do runtime de integração autoalojado

Existem muitos erros, avisos e problemas comuns entre o Purview SHIR, o Azure Data Factory ou o Azure Synapse SHIR. O guia abaixo abrange muitos dos problemas mais comuns.

Erro ou falha geral do IR autoalojado

Problema de memória insuficiente

Sintomas

Um erro OutOfMemoryException (OOM) ocorre quando tenta executar uma análise com um IR autoalojado.

Causa

Uma nova análise pode gerar um erro OOM se o computador do IR tiver uma utilização momentânea de memória elevada. O problema pode ser causado por um grande volume de atividade simultânea ou uma baixa quantidade de memória e o erro é por predefinição.

Resolução

Verifique a utilização do recurso para confirmar se outro software está em execução ao mesmo tempo e confirme que o computador SHIR cumpre as configurações recomendadas.

O IR autoalojado não conseguiu carregar o ficheiro ou a assemblagem

Sintomas

Recebe a seguinte mensagem de erro:

"Não foi possível carregar o ficheiro ou a assemblagem 'XXXXXXXXXXXXXXXX, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' ou uma das respetivas dependências. O sistema não pôde encontrar o arquivo especificado. ID da Atividade: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3"

Eis uma mensagem de erro mais específica:

"Não foi possível carregar o ficheiro ou a assemblagem 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' ou uma das suas dependências. O sistema não pôde encontrar o arquivo especificado. ID da Atividade: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3"

Causa

No Monitor de Processos, pode ver o seguinte resultado:

Dica

No Monitor de Processos, pode definir filtros conforme mostrado na captura de ecrã seguinte. A mensagem de erro anterior indica que a pasta DLL System.ValueTuple não está localizada na pasta da Cache de Assemblagem Global (GAC) relacionada, na pasta C:\Program Files\Microsoft Integration Runtime\4.0\Gateway ou na pasta C:\Program Files\Microsoft Integration Runtime\4.0\Shared. Basicamente, o processo carrega a DLL primeiro a partir da pasta GAC , depois da pasta Partilhado e, por fim, da pasta Gateway . Por conseguinte, pode carregar a DLL a partir de qualquer caminho que seja útil.

Resolução

Encontrará o ficheiro System.ValueTuple.dll na pasta C:\Program Files\Microsoft Integration Runtime\4.0\Gateway\DataScan. Para resolve o problema, copie o ficheiro deSystem.ValueTuple.dll para a pasta C:\Program Files\Microsoft Integration Runtime\4.0\Gateway.

Pode utilizar o mesmo método para resolve outros problemas de assemblagem ou ficheiro em falta.

Mais informações

O motivo pelo qual vê o System.ValueTuple.dll em %windir%\Microsoft.NET\assembly e %windir%\assembly é que se trata de um comportamento .NET.

No erro seguinte, pode ver claramente que a assemblagem System.ValueTuple está em falta. Este problema surge quando a aplicação tenta marcar a assemblagem System.ValueTuple.dll.

"<LogProperties><ErrorInfo>[{"Code":0,"Message":"The type initializer for 'Npgsql.PoolManager' atirou uma exceção.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.TypeInitializationException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[{"Code":0,"Message":"Não foi possível carregar o ficheiro ou a assemblagem 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' ou uma das respetivas dependências. O sistema não consegue localizar o ficheiro especificado.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.IO.FileNotFoundException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[]}]}]</ErrorInfo></LogProperties>"

Para obter mais informações sobre o GAC, veja Global Assembly Cache(Cache de Assemblagem Global).

A Chave de Autenticação do runtime de integração autoalojado está em falta

Sintomas

De repente, o runtime de integração autoalojado fica offline sem uma Chave de Autenticação e o Registo de Eventos apresenta a seguinte mensagem de erro:

"A Chave de Autenticação ainda não foi atribuída"

Causa

O nó de IR autoalojado ou o IR autoalojado lógico no portal do Microsoft Purview foi eliminado ou foi executada uma limpo desinstalação.

Resolução

Se nenhuma das causas anteriores se aplicar, pode aceder à pasta %programdata%\Microsoft\Data Transfer\DataManagementGateway para ver se o ficheiro de Configurações foi eliminado. Se tiver sido eliminado, siga as instruções no artigo da Netwrix Detetar quem eliminou um ficheiro dos servidores de ficheiros do Windows.

Não é possível escolher o certificado porque a chave privada está em falta

Sintomas

• Importou um ficheiro PFX para o arquivo de certificados.
• Quando selecionou o certificado através do IR Configuration Manager IU, recebeu a seguinte mensagem de erro:

"Falha ao alterar o modo de encriptação de comunicação da intranet. É provável que o "<nome> do certificado" não tenha uma chave privada capaz de troca de chaves ou que o processo possa não ter direitos de acesso para a chave privada. Veja a exceção interna para obter detalhes."

Causa

• A conta de utilizador tem um nível de privilégio baixo e não consegue aceder à chave privada.
• O certificado foi gerado como uma assinatura, mas não como uma troca de chaves.

Resolução

• Para operar a IU, utilize uma conta com privilégios adequados para aceder à chave privada.
• Importe o certificado ao executar o seguinte comando:

certutil -importpfx FILENAME.pfx AT_KEYEXCHANGE

Mensagem de erro UserErrorJreNotFound ao executar uma análise

Sintomas

Quando tenta analisar uma origem de dados com uma ferramenta ou programa baseado em Java (por exemplo, ficheiros de formato Parquet), recebe uma mensagem de erro semelhante à seguinte:

ErrorCode=UserErrorJreNotFound,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Java Runtime Environment não foi encontrado. Aceda a http://go.microsoft.com/fwlink/?LinkId=808605 para transferir e instalar no computador Integration Runtime (auto-hospedado) nó. Tenha em atenção Integration Runtime de 64 bits requer JRE de 64 bits e Integration Runtime de 32 bits requer JRE de 32 bits.,Source=Microsoft.DataTransfer.Common,'''Type=System.DllNotFoundException,Message=Unable to load DLL 'jvm.dll': Não foi possível localizar o módulo especificado. (Exceção de HRESULT: 0x8007007E),Source=Microsoft.DataTransfer.Richfile.HiveOrcBridge

Causa

Este problema ocorre por um dos seguintes motivos:

• O Java Runtime Environment (JRE) não está corretamente instalado no servidor Integration Runtime.

• O servidor Integration Runtime não tem a dependência necessária para JRE.

Por predefinição, Integration Runtime resolve o caminho do JRE com entradas de registo. Essas entradas devem ser definidas automaticamente durante a instalação do JRE.

Resolução

Siga as etapas nesta seção com cuidado. Sérios problemas poderão ocorrer caso você modifique o Registro incorretamente. Antes de modificá-lo, faça backup do Registro para restauração em caso de problemas.

Para corrigir este problema, siga estes passos para verificar a status da instalação do JRE:

1. Certifique-se de que Integration Runtime (Diahost.exe) e JRE estão instalados na mesma plataforma. Verifique as seguintes condições:

   • JRE de 64 bits para Integration Runtime do ADF de 64 bits deve ser instalado na pasta:C:\Program Files\Java\

     Observação

     A pasta não é C:\Program Files (x86)\Java\

   • O JRE 11 é compatível com a análise. O JRE 8 também é compatível, mas as versões anteriores ao JRE 8 não foram validadas para esta utilização.

2. Verifique se existem definições adequadas no registo. Para fazer isso, siga estas etapas:

3. No menu Executar , escreva Regedit e, em seguida, prima Enter.

4. No painel de navegação, localize a seguinte subchave:

   HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment.

   No painel Detalhes , deve existir uma entrada Versão Atual que mostra a versão do JRE (por exemplo, 1,8).

   

5. No painel de navegação, localize uma subchave que seja uma correspondência exata para a versão (por exemplo, 1,8) na pasta JRE. No painel de detalhes, deve existir uma entrada JavaHome . O valor desta entrada é o caminho de instalação do JRE.

   

6. Localize a pasta bin\server no seguinte caminho:

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

   

7. Verifique se esta pasta contém um ficheiro jvm.dll. Caso contrário, marcar para o ficheiro na bin\client pasta .

   

Observação

• Se alguma destas configurações não for conforme descrito nestes passos, utilize o instalador do WINDOWS JRE para corrigir os problemas.
• Se todas as configurações nestes passos estiverem corretas, conforme descrito, poderá existir uma biblioteca de runtime VC++ em falta no sistema. Pode corrigir este problema ao instalar o Pacote Redistribuível VC++ 2010.

Configuração do IR autoalojado

Erro de registo do runtime de integração

Sintomas

Ocasionalmente, poderá querer executar um IR autoalojado numa conta diferente por um dos seguintes motivos:

• A política da empresa não permite a conta de serviço.
• É necessária alguma autenticação.

Depois de alterar a conta de serviço no painel de serviço, poderá constatar que o runtime de integração deixa de funcionar e recebe a seguinte mensagem de erro:

"O nó Integration Runtime (auto-hospedado) encontrou um erro durante o registo. Não é possível ligar ao Integration Runtime (auto-hospedado) Serviço de Anfitrião".

Causa

Muitos recursos são concedidos apenas à conta de serviço. Quando altera a conta de serviço para outra conta, as permissões de todos os recursos dependentes permanecem inalteradas.

Resolução

Aceda ao registo de eventos do runtime de integração para marcar o erro.

• Se o erro no registo de eventos for "UnauthorizedAccessException", faça o seguinte:

  1. Verifique a conta de serviço de início de sessão DIAHostService no painel de serviço do Windows.

     

  2. Verifique se a conta de serviço de início de sessão tem permissões de leitura/escrita para a pasta %programdata%\Microsoft\DataTransfer\DataManagementGateway .

     • Por predefinição, se a conta de início de sessão do serviço não tiver sido alterada, deverá ter permissões de leitura/escrita.

       

     • Se tiver alterado a conta de início de sessão do serviço, mitige o problema ao fazer o seguinte:

       1. Execute uma limpo desinstalação do IR autoalojado atual.
       2. Instale os bits do IR autoalojado.
       3. Altere a conta de serviço ao fazer o seguinte:
          1. Aceda à pasta de instalação do IR autoalojado e, em seguida, mude para a pasta Microsoft Integration Runtime\4.0\Shared.
          2. Abra uma janela da Linha de Comandos com privilégios elevados. Substitua <o utilizador> e <a palavra-passe> pelo seu próprio nome de utilizador e palavra-passe e, em seguida, execute o seguinte comando: dmgcmd.exe -SwitchServiceAccount "<user>" "<password>"
          3. Se quiser alterar para a conta LocalSystem, certifique-se de que utiliza o formato correto para esta conta: dmgcmd.exe -SwitchServiceAccount "NT Authority\System" ""
          4. Não utilize este formato:dmgcmd.exe -SwitchServiceAccount "LocalSystem" ""
          5. Opcionalmente, uma vez que o Sistema Local tem privilégios mais elevados do que o Administrador, também pode alterá-lo diretamente em "Serviços".
          6. Pode utilizar um utilizador local/de domínio para a conta de início de sessão do serviço IR.
       4. Registe o runtime de integração.

• Se o erro for "O serviço "serviço Integration Runtime" (DIAHostService) não conseguiu iniciar. Verifique se tem privilégios suficientes para iniciar os serviços do sistema", faça o seguinte:

  1. Verifique a conta de serviço de início de sessão DIAHostService no painel de serviço do Windows.

     

  2. Verifique se a conta de serviço de início de sessão tem a permissão Iniciar sessão como serviço para iniciar o serviço Windows:

     

Mais informações

Se nenhum dos dois padrões de resolução anteriores se aplicar no seu caso, tente recolher os seguintes registos de eventos do Windows:

• Integration Runtime de Registos de Aplicações e Serviços >
• Aplicação de Registos > do Windows

Não é possível localizar o botão Registar para registar um IR autoalojado

Sintomas

Quando regista um IR autoalojado, o botão Registar não é apresentado no painel Configuration Manager.

Causa

A partir do lançamento do Integration Runtime 3.0, o botão Registar nos nós de runtime de integração existentes foi removido para permitir um ambiente mais limpo e seguro. Se um nó tiver sido registado num runtime de integração, quer esteja online ou não, registe-o novamente noutro runtime de integração ao desinstalar o nó anterior e, em seguida, instale e registe o nó.

Resolução

1. No Painel de Controle, desinstale o runtime de integração existente.

   Importante

   No processo seguinte, selecione Sim. Não mantenha os dados durante o processo de desinstalação.

   

2. Se não tiver o ficheiro MSI do instalador do runtime de integração, aceda ao centro de transferências para transferir o runtime de integração mais recente.

3. Instale o ficheiro MSI e registe o runtime de integração.

Não é possível registar o IR autoalojado devido ao localhost

Sintomas

Não é possível registar o IR autoalojado num novo computador quando utiliza get_LoopbackIpOrName.

Depuração: Ocorreu um erro de runtime. O inicializador de tipo para "Microsoft.DataTransfer.DIAgentHost.DataSourceCache" gerou uma exceção. Ocorreu um erro não detetável durante uma pesquisa de base de dados.

Detalhe da exceção: System.TypeInitializationException: o inicializador de tipo para "Microsoft.DataTransfer.DIAgentHost.DataSourceCache" gerou uma exceção. >--- System.Net.Sockets.SocketException: Ocorreu um erro não detetável durante uma pesquisa de base de dados em System.Net.Dns.GetAddrInfo(Nome da cadeia).

Causa

Normalmente, o problema ocorre quando o localhost está a ser resolvido.

Resolução

Utilize o endereço IP localhost 127.0.0.1 para alojar o ficheiro e resolve o problema.

Falha na configuração autoalojada

Sintomas

Não é possível desinstalar um IR existente, instalar um novo IR ou atualizar um IR existente para um novo IR.

Causa

A instalação do runtime de integração depende do serviço Windows Installer. Poderá deparar-se com problemas de instalação pelos seguintes motivos:

• Espaço em disco insuficiente disponível.
• Falta de permissões.
• O serviço Windows NT está bloqueado.
• A utilização da CPU é demasiado elevada.
• O ficheiro MSI está alojado numa localização de rede lenta.
• Alguns ficheiros ou registos do sistema foram tocados involuntariamente.

A conta de serviço do IR não conseguiu obter o acesso ao certificado

Sintomas

Quando instala um IR autoalojado através de Microsoft Integration Runtime Configuration Manager, é gerado um certificado com uma autoridade de certificação (AC) fidedigna. Não foi possível aplicar o certificado para encriptar a comunicação entre dois nós e é apresentada a seguinte mensagem de erro:

"Falha ao alterar o modo de encriptação de comunicação da Intranet: não foi possível conceder à conta de serviço Integration Runtime acesso ao certificado "<nome> do certificado". Código de erro 103"

Causa

O certificado está a utilizar o armazenamento do fornecedor de armazenamento de chaves (KSP), que ainda não é suportado. Até à data, o IR autoalojado suporta apenas o armazenamento do fornecedor de serviços criptográficos (CSP).

Resolução

Neste caso, recomendamos que utilize certificados CSP.

Solução 1

Para importar o certificado, execute o seguinte comando:

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

Solução 2

Para converter o certificado, execute os seguintes comandos:

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

Antes e depois da conversão:

Versão 5.x do runtime de integração autoalojado

Para a atualização para a versão 5.x do runtime de integração autoalojado, é necessário .NET Framework Runtime 4.7.2 ou posterior. Na página de transferência, encontrará ligações de transferência para a versão 4.x mais recente e as duas versões mais recentes do 5.x.

Para clientes Azure Data Factory v2 e Azure Synapse:

• Se a atualização automática estiver ativada e já tiver atualizado o .NET Framework Runtime para a versão 4.7.2 ou posterior, o runtime de integração autoalojado será atualizado automaticamente para a versão 5.x mais recente.
• Se a atualização automática estiver ativada e não tiver atualizado o .NET Framework Runtime para a versão 4.7.2 ou posterior, o runtime de integração autoalojado não será atualizado automaticamente para a versão 5.x mais recente. O runtime de integração autoalojado permanecerá na versão 4.x atual. Pode ver um aviso para uma atualização do .NET Framework Runtime no portal e o cliente do runtime de integração autoalojado.
• Se a atualização automática estiver desativada e já tiver atualizado o .NET Framework Runtime para a versão 4.7.2 ou posterior, pode transferir manualmente o 5.x mais recente e instalá-lo no seu computador.
• Se a atualização automática estiver desativada e não tiver atualizado o .NET Framework Runtime para a versão 4.7.2 ou posterior. Quando tenta instalar manualmente o integration runtime 5.x autoalojado e registar a chave, primeiro terá de atualizar a sua versão do .NET Framework Runtime.

Para clientes Azure Data Factory v1:

• O runtime de integração autoalojado 5.X não suporta Azure Data Factory v1.
• O runtime de integração autoalojado será atualizado automaticamente para a versão mais recente do 4.x. E a versão mais recente do 4.x não expira.
• Se tentar instalar manualmente o integration runtime 5.x autoalojado e registar a chave, será notificado de que o runtime de integração autoalojado 5.x não suporta Azure Data Factory v1.

Problemas de conectividade do IR autoalojado

O runtime de integração autoalojado não consegue ligar-se ao serviço cloud

Sintomas

Quando tenta registar o runtime de integração autoalojado, Configuration Manager apresenta a seguinte mensagem de erro:

"O nó Integration Runtime (auto-hospedado) encontrou um erro durante o registo."

Causa

O IR autoalojado não consegue ligar ao back-end do serviço. Normalmente, este problema é causado pelas definições de rede na firewall.

Resolução

1. Verifique se o serviço de runtime de integração está em execução. Se estiver, avance para o passo 2.

   

2. Se nenhum proxy estiver configurado no IR autoalojado, que é a predefinição, execute o seguinte comando do PowerShell no computador onde o runtime de integração autoalojado está instalado:

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

   Observação

   O URL do serviço pode variar consoante a localização da fábrica de dados ou da instância da área de trabalho do Synapse. Para localizar o URL do serviço, utilize a página Gerir da IU na sua fábrica de dados ou Azure Synapse instância para localizar Runtimes de integração e selecione o IR autoalojado para editá-lo. Selecione o separador Nós e selecione Ver URLs do Serviço.

3. Segue-se a resposta esperada:

   

4. Se não receber a resposta esperada, utilize um dos seguintes métodos, conforme adequado:

   • Se receber uma mensagem "Não foi possível resolver o nome remoto", existe um problema com o Sistema de Nomes de Domínio (DNS). Contacte a equipa de rede para corrigir o problema.
   • Se recebeu uma mensagem "o certificado ssl/tls não é fidedigno", marcar o certificado (https://wu2.frontend.clouddatahub.net/) para ver se é fidedigno no computador e, em seguida, instale o certificado público com o Gestor de Certificados. Esta ação deve mitigar o problema.
   • Aceda a Visualizadorde Eventos do Windows >(registos)>Registos de Aplicações e Serviços>Integration Runtime e marcar para qualquer falha causada pelo DNS, uma regra de firewall ou as definições de rede da empresa. Se encontrar tal falha, feche a ligação à força. Uma vez que cada empresa tem as suas próprias definições de rede personalizadas, contacte a equipa de rede para resolver estes problemas.

5. Se o "proxy" tiver sido configurado no runtime de integração autoalojado, verifique se o servidor proxy pode aceder ao ponto final de serviço. Para obter um comando de exemplo, veja PowerShell, pedidos Web e 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
   

Segue-se a resposta esperada:

Observação

Considerações de proxy:

• Verifique se o servidor proxy precisa de ser colocado na lista Destinatários Seguros. Se for o caso, certifique-se de que estes domínios estão na lista Destinatários Seguros.
• Verifique se o certificado SSL/TLS "wu2.frontend.clouddatahub.net/" é fidedigno no servidor proxy.
• Se estiver a utilizar a autenticação do Active Directory no proxy, altere a conta de serviço para a conta de utilizador que pode aceder ao proxy como "serviço Integration Runtime".

Não foi possível estabelecer uma relação de confiança para o canal seguro SSL/TLS

Sintomas

O IR autoalojado não conseguiu ligar ao Microsoft Purview.

Quando marcar o registo de eventos do IR autoalojado depois de aceder aoVisualizador de Eventos doWindows> (registos)>Registos de Aplicações e Serviços> Integration Runtime, encontrará a seguinte mensagem de erro:

"A ligação subjacente foi fechada: não foi possível estabelecer a relação de confiança para o canal seguro SSL/TLS. O certificado remoto é inválido de acordo com o procedimento de validação."

A forma mais simples de marcar o certificado de servidor do serviço é abrir o URL do serviço no browser. Por exemplo, abra a ligação marcar certificado de servidor ((https://eu.frontend.clouddatahub.net/) no computador onde o IR autoalojado está instalado e, em seguida, veja as informações do certificado do servidor.

Causa

Existem dois motivos possíveis para este problema:

• Motivo 1: a AC de raiz do certificado de servidor do serviço não é fidedigna no computador onde o IR autoalojado está instalado.
• Motivo 2: está a utilizar um proxy no seu ambiente, o certificado de servidor do serviço é substituído pelo proxy e o certificado de servidor substituído não é considerado fidedigno pelo computador onde o IR autoalojado está instalado.

Resolução

• Por motivo 1: certifique-se de que o certificado de servidor do serviço e a respetiva cadeia de certificados são considerados fidedignos pelo computador onde o IR autoalojado está instalado.
• Por motivo 2: confie na AC de raiz substituída no computador ir autoalojado ou configure o proxy para não substituir o certificado de servidor do serviço.

Para obter mais informações sobre como confiar em certificados no Windows, consulte Instalar o certificado de raiz fidedigna.

Mais informações

Lançámos um novo certificado SSL, assinado a partir da DigiCert. Verifique se o DigiCert Global Root G2 está na AC de raiz fidedigna.

Se não estiver na AC de raiz fidedigna, transfira-a aqui.

Próximas etapas

Para obter mais ajuda com a resolução de problemas, experimente os seguintes recursos:

• Introdução ao Microsoft Purview
• Criar e Gerir runtimes de integração autoalojados do SHIR no Purview
• Perguntas mais frequentes sobre a governação de dados