Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo explora métodos comuns de solução de problemas para SHIR (runtime de integração auto-hospedada) no Microsoft Purview.
O SHIR (runtime de integração auto-hospedada) também é usado pelo Azure Data Factory e pelo Azure Synapse Analytics. Embora muitas das etapas de solução de problemas se sobreponham, siga este guia para solucionar problemas de SHIR para esses produtos:
Coletar logs de tempo de execução de integração auto-hospedada SHIR específicos do Microsoft Purview
Para verificações com falha do Microsoft Purview que estão sendo executadas em um IR auto-hospedado, o serviço dá suporte à exibição e ao upload de logs de erro do Windows Visualizador de Eventos.
Você pode procurar todos os erros que vir no guia de erros abaixo. Para obter suporte e diretrizes de solução de problemas para problemas de SHIR, talvez seja necessário gerar uma ID de relatório de erros e entrar em contato com o suporte da Microsoft.
Para gerar a ID do relatório de erros para o Suporte da Microsoft, siga estas instruções:
Antes de iniciar uma verificação no portal de governança do Microsoft Purview:
- Navegue até o computador em que o runtime de integração auto-hospedada está instalado e abra o Windows Visualizador de Eventos.
- Limpe os logs do visualizador de eventos do Windows na seção Integration Runtime. Clique com o botão direito do mouse nos logs e selecione a opção limpar logs.
- Navegue de volta para o portal de governança do Microsoft Purview e inicie a verificação.
Depois que a verificação mostrar o status Failed, navegue de volta para a VM SHIR ou computador e atualize o visualizador de eventos na seção Integration Runtime .
Os logs de atividades são exibidos para a execução de verificação com falha.
Para obter mais assistência da Microsoft, selecione Enviar Logs.
A janela Compartilhar os logs SHIR (Integration Runtime) auto-hospedado com a Microsoft é aberta.
Quando os logs forem carregados, mantenha um registro da ID do Relatório para usar se você entrar em contato com o suporte da Microsoft.
Tempo de execução de integração auto-hospedada SHIR Falha ou erro geral
Há muitos erros, avisos e problemas comuns entre o SHIR do Purview, o Azure Data Factory ou o SHIR do Azure Synapse. O guia a seguir aborda muitos dos problemas mais comuns.
Erro ou falha geral de IR auto-hospedado
Problema de falta de memória
Sintomas
Um erro OutOfMemoryException (OOM) ocorre quando você tenta executar uma verificação com um IR auto-hospedado.
Causa
Uma nova verificação poderá gerar um erro OOM se o computador IR tiver alto uso momentâneo de memória. O problema pode ser causado por um grande volume de atividade simultânea ou uma quantidade baixa de memória e o erro é intencional.
Resolução
Verifique o uso de recursos para confirmar se algum outro software está sendo executado ao mesmo tempo e confirme se sua máquina SHIR atende às configurações recomendadas.
O IR auto-hospedado não pôde carregar arquivo ou assembly
Sintomas
A seguinte mensagem de erro é exibida:
"Não foi possível carregar o arquivo ou assembly 'XXXXXXXXXXXXXXXX, Versão=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' ou uma de suas dependências. O sistema não pôde encontrar o arquivo especificado. ID da atividade: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3"
Aqui está uma mensagem de erro mais específica:
"Não foi possível carregar o arquivo ou assembly 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' ou uma de 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 Processo, você pode visualizar o seguinte resultado:
Dica
No Monitor de Processo, você pode definir filtros conforme mostrado na captura de tela a seguir. A mensagem de erro anterior diz que a DLL System.ValueTuple não está localizada na pasta GAC (Cache de Assembly Global) relacionada, na pasta C:\Program Files\Microsoft Integration Runtime\4.0\Gateway ou em C:\Program Files\ Microsoft Integration Runtime\4.0\Pasta compartilhada. Basicamente, o processo carrega a DLL primeiro da pasta GAC , depois da pasta Shared e, por fim, da pasta Gateway . Portanto, você pode carregar a DLL de qualquer caminho que seja útil.
Resolução
Você encontrará o arquivo System.ValueTuple.dll na pasta C:\Program Files\Microsoft Integration Runtime\4.0\Gateway\DataScan. Para resolve o problema, copie o arquivo System.ValueTuple.dll para a pasta C:\Program Files\Microsoft Integration Runtime\4.0\Gateway.
Você pode usar o mesmo método para resolver outros problemas de arquivo ou assembly ausentes.
Mais informações
A razão pela qual você vê o System.ValueTuple.dll em %windir%\Microsoft.NET\assembly e %windir%\assembly é que esse é um comportamento do .NET.
No erro a seguir, você pode ver claramente que o assembly System.ValueTuple está ausente. Esse problema surge quando o aplicativo tenta marcar o assembly System.ValueTuple.dll.
"<LogProperties><ErrorInfo>[{"Code":0,"Message":"O inicializador do tipo para 'Npgsql.PoolManager' lançou 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 arquivo ou assembly 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' ou uma de suas dependências. O sistema não pôde encontrar o arquivo 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, consulte Cache de Assembly Global.
Tempo de execução de integração auto-hospedada A chave de autenticação está ausente
Sintomas
O runtime de integração auto-hospedada de repente fica offline sem uma chave de autenticação e o log de eventos exibe a seguinte mensagem de erro:
"A Chave de Autenticação ainda não foi atribuída"
Causa
O nó de IR auto-hospedado ou o IR lógico auto-hospedado no portal do Microsoft Purview foi excluído ou uma desinstalação limpa foi executada.
Resolução
Se nenhuma das causas anteriores se aplicar, você poderá acessar a pasta %programdata%\Microsoft\Data Transfer\DataManagementGateway para ver se o arquivo de Configurações foi excluído. Se ele foi excluído, siga as instruções no artigo do Netwrix Detectar quem excluiu um arquivo de seus servidores de arquivos do Windows.
Não é possível escolher o certificado porque a chave privada está ausente
Sintomas
- Você importou um arquivo PFX para o repositório de certificados.
- Ao selecionar o certificado por meio da interface do usuário do Configuration Manager IR, você recebeu a seguinte mensagem de erro:
"Falha ao alterar o modo de criptografia de comunicação da intranet. É provável que o "<nome> do certificado" do certificado não tenha uma chave privada capaz de troca de chaves ou que o processo não tenha direitos de acesso para a chave privada. Consulte a exceção interna para obter detalhes."
Causa
- A conta de usuário tem um nível de privilégio baixo e não pode acessar a chave privada.
- O certificado foi gerado como uma assinatura, mas não como uma troca de chaves.
Resolução
- Para operar a interface do usuário, use uma conta com privilégios apropriados para acessar a chave privada.
- Importe o certificado executando o seguinte comando:
certutil -importpfx FILENAME.pfx AT_KEYEXCHANGE
Mensagem de erro UserErrorJreNotFound ao executar uma verificação
Sintomas
Ao tentar digitalizar uma fonte de dados usando uma ferramenta ou programa baseado em Java (por exemplo, arquivos no formato Parquet), você recebe uma mensagem de erro semelhante a:
ErrorCode=UserErrorJreNotFound,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Java Runtime Environment não encontrado.
http://go.microsoft.com/fwlink/?LinkId=808605Acesse para baixar e instalar em seu computador de nó do Integration Runtime (auto-hospedado). Observaçã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=Não é possível carregar a DLL 'jvm.dll': o módulo especificado não pôde ser encontrado. (Exceção de HRESULT: 0x8007007E),Source=Microsoft.DataTransfer.Richfile.HiveOrcBridge
Causa
Esse problema ocorre por um dos seguintes motivos:
O JRE (Java Runtime Environment) não está instalado corretamente em seu servidor Integration Runtime.
Seu servidor Integration Runtime não tem a dependência necessária para JRE.
Por padrão, o Integration Runtime resolve o caminho do JRE usando entradas do Registro. 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 esse problema, siga estas etapas para verificar o status da instalação do JRE:
Certifique-se de que o Integration Runtime (Diahost.exe) e o JRE estejam instalados na mesma plataforma. Verifique as seguintes condições:
O JRE de 64 bits para o ADF de 64 bits Integration Runtime deve ser instalado na pasta:
C:\Program Files\Java\Observação
A pasta não está
C:\Program Files (x86)\Java\O JRE 11 é compatível para digitalização. O JRE 8 também é compatível, mas as versões anteriores ao JRE 8 não foram validadas para esse uso.
Verifique o Registro para obter as configurações apropriadas. Para fazer isso, siga estas etapas:
No menu Executar , digite Regedit e pressione Enter.
No painel de navegação, localize a seguinte subchave:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment.No painel de Detalhes , deverá haver uma entrada de Versão Atual que mostre a versão do JRE (por exemplo, 1.8).
No painel de navegação, localize uma subchave que seja uma correspondência exata da versão (por exemplo 1.8) na pasta do JRE. No painel de detalhes, deve haver uma entrada JavaHome . O valor dessa entrada é o caminho de instalação do JRE.
Localize a pasta bin\server no seguinte caminho:
C:\Program Files\Java\jre1.xx.xxx
Verifique se a pasta contém um arquivo jvm.dll. Em caso negativo, marque se o arquivo está na
bin\clientpasta.
Observação
- Se alguma dessas configurações não corresponder às descrições nessas etapas, use o instalador do JRE do Windows para corrigir os problemas.
- Se todas as configurações nessas etapas estão corretas conforme foram descritas, pode haver uma biblioteca VC++ runtime ausente no sistema. Você pode corrigir esse problema instalando o Pacote Redistribuível VC++ 2010.
Configuração de IR auto-hospedada
Erro de registro do runtime de integração
Sintomas
Ocasionalmente, você pode querer executar um IR auto-hospedado em uma conta diferente por um dos seguintes motivos:
- A política da empresa proíbe a conta de serviço.
- Alguma autenticação é necessária.
Depois de alterar a conta de serviço no painel de serviço, você poderá descobrir que o runtime de integração para de funcionar e você receberá a seguinte mensagem de erro:
"O nó do Integration Runtime (auto-hospedado) encontrou um erro durante o registro. Não é possível conectar-se ao Serviço de Host do Integration Runtime (auto-hospedado)."
Causa
Muitos recursos são concedidos somente para a conta de serviço. Quando você altera a conta de serviço para outra conta, as permissões de todos os recursos dependentes permanecem inalteradas.
Resolução
Acesse o log de eventos do runtime de integração para marcar o erro.
Se o erro no log de eventos for "UnauthorizedAccessException", faça o seguinte:
Verifique a conta de serviço de entrada do DIAHostService no painel de serviço do Windows.
Verifique se a conta de serviço de entrada tem permissões de leitura/gravação para a pasta %programdata%\Microsoft\DataTransfer\DataManagementGateway .
Por padrão, se a conta de entrada do serviço não foi alterada, ela deve ter permissões de leitura/gravação.
Se você alterou a conta de entrada do serviço, atenue o problema fazendo o seguinte:
- Execute uma desinstalação limpa do IR auto-hospedado atual.
- Instale os bits de IR auto-hospedados.
- Altere a conta de serviço da seguinte maneira:
- Vá para a pasta de instalação do IR auto-hospedado e, em seguida, alterne para a pasta Microsoft Integration Runtime\4.0\Shared.
- Abra uma janela do Prompt de Comando usando privilégios elevados. Substitua <o usuário> e <a senha> por seu próprio nome de usuário e senha e execute o seguinte comando:
dmgcmd.exe -SwitchServiceAccount "<user>" "<password>" - Se você quiser alterar para a conta LocalSystem, certifique-se de usar o formato correto para essa conta:
dmgcmd.exe -SwitchServiceAccount "NT Authority\System" "" -
Não use este formato:
dmgcmd.exe -SwitchServiceAccount "LocalSystem" "" - Opcionalmente, como o Sistema Local tem privilégios mais altos do que o Administrador, você também pode alterá-lo diretamente em "Serviços".
- Você pode usar um usuário local/domínio para a conta de entrada do serviço de IR.
- Registre o runtime de integração.
Se o erro for "O serviço 'Integration Runtime Service' (DIAHostService) falhou ao iniciar. Verifique se você tem privilégios suficientes para iniciar os serviços do sistema", faça o seguinte:
Verifique a conta de serviço de entrada do DIAHostService no painel de serviço do Windows.
Verifique se a conta de serviço de entrada tem permissão Fazer logon como serviço para iniciar o serviço do Windows:
Mais informações
Se nenhum dos dois padrões de resolução anteriores se aplicar ao seu caso, tente coletar os seguintes logs de eventos do Windows:
- Logs > de Aplicativos e Serviços Integration Runtime
- Aplicativo de Logs do > Windows
Não é possível encontrar o botão Registrar para registrar um IR auto-hospedado
Sintomas
Quando você registra um IR auto-hospedado, o botão Registrar não é exibido no painel do Configuration Manager.
Causa
A partir do lançamento do Integration Runtime 3.0, o botão Registrar nos nós de runtime de integração existentes foi removido para permitir um ambiente mais limpo e seguro. Se um nó tiver sido registrado em um runtime de integração, esteja ele online ou não, registre-o novamente em outro runtime de integração desinstalando o nó anterior e, em seguida, instale e registre o nó.
Resolução
No Painel de Controle, desinstale o runtime de integração existente.
Importante
No processo a seguir, selecione Sim. Não guarde dados durante o processo de desinstalação.
Se você não tiver o arquivo MSI do instalador do runtime de integração, acesse o centro de download para baixar o runtime de integração mais recente.
Instale o arquivo MSI e registre o runtime de integração.
Não é possível registrar o IR auto-hospedado devido a localhost
Sintomas
Você não consegue registrar o IR auto-hospedado em um novo computador quando usa get_LoopbackIpOrName.
Depuração: Ocorreu um erro em tempo de execução. O inicializador do tipo para "Microsoft.DataTransfer.DIAgentHost.DataSourceCache" lançou uma exceção. Ocorreu um erro irrecuperável durante uma consulta de banco de dados.
Detalhe da exceção: System.TypeInitializationException: o inicializador do tipo para "Microsoft.DataTransfer.DIAgentHost.DataSourceCache" lançou uma exceção. >--- System.Net.Sockets.SocketException: ocorreu um erro irrecuperável durante uma pesquisa de banco de dados em System.Net.Dns.GetAddrInfo(String name).
Causa
O problema geralmente ocorre quando o localhost está sendo resolvido.
Resolução
Use o endereço IP do localhost 127.0.0.1 para hospedar o arquivo e resolver o problema.
Falha na configuração auto-hospedada
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. Você pode ter problemas de instalação pelos seguintes motivos:
- Espaço em disco disponível insuficiente.
- Falta de permissões.
- O serviço do Windows NT está bloqueado.
- A utilização da CPU está muito alta.
- O arquivo MSI está hospedado em um local de rede lento.
- Alguns arquivos do sistema ou registros foram tocados involuntariamente.
A conta de serviço de IR falhou ao buscar acesso ao certificado
Sintomas
Quando você instala um IR auto-hospedado por meio de Microsoft Integration Runtime Configuration Manager, é gerado um certificado com uma AC (autoridade de certificação) confiável. Não foi possível aplicar o certificado para criptografar a comunicação entre dois nós e a seguinte mensagem de erro é exibida:
"Falha ao alterar o modo de criptografia de comunicação da intranet: Falha ao conceder à conta de serviço do Integration Runtime o acesso ao certificado '<nome> do certificado'. Código de erro 103"
Causa
O certificado está usando o armazenamento KSP (provedor de armazenamento de chaves), que ainda não tem suporte. Até o momento, o IR auto-hospedado dá suporte apenas ao armazenamento do CSP (provedor de serviços criptográficos).
Resolução
Recomendamos que você use certificados CSP nesse caso.
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:
Runtime de integração auto-hospedada versão 5.x
Para a atualização para a versão 5.x do runtime de integração auto-hospedada, exigimos o .NET Framework Runtime 4.7.2 ou posterior. Na página de download, você encontrará links para download da versão mais recente do 4.x e das duas versões mais recentes do 5.x.
Para clientes do Azure Data Factory v2 e do Azure Synapse:
- Se a atualização automática estiver ativada e você já tiver atualizado o .NET Framework Runtime para 4.7.2 ou posterior, o runtime de integração auto-hospedada será atualizado automaticamente para a versão 5.x mais recente.
- Se a atualização automática estiver ativada e você não tiver atualizado o .NET Framework Runtime para 4.7.2 ou posterior, o runtime de integração auto-hospedada não será atualizado automaticamente para a versão 5.x mais recente. O runtime de integração auto-hospedada permanecerá na versão 4.x atual. Você pode ver um aviso para uma atualização do .NET Framework Runtime no portal e no cliente de runtime de integração auto-hospedada.
- Se a atualização automática estiver desativada e você já tiver atualizado o tempo de execução do .NET Framework para 4.7.2 ou posterior, será possível baixar manualmente o 5.x mais recente e instalá-lo no computador.
- Se a atualização automática estiver desativada e você não tiver atualizado o tempo de execução do .NET Framework para 4.7.2 ou posterior. Quando você tenta instalar manualmente o runtime de integração auto-hospedada 5.x e registrar a chave, será necessário atualizar sua versão do .NET Framework Runtime primeiro.
Para clientes do Azure Data Factory v1:
- O runtime de integração auto-hospedada 5.X não dá suporte ao Azure Data Factory v1.
- O runtime de integração auto-hospedada será atualizado automaticamente para a versão mais recente do 4.x. E a versão mais recente do 4.x não expirará.
- Se tentar instalar manualmente o runtime de integração auto-hospedada 5.x e registrar a chave, você será notificado de que o runtime de integração auto-hospedada 5.x não dá suporte ao Azure Data Factory v1.
Problemas de conectividade IR auto-hospedada
O runtime de integração auto-hospedada não pode se conectar ao serviço de nuvem
Sintomas
Quando você tenta registrar o runtime de integração auto-hospedada, o Configuration Manager exibe a seguinte mensagem de erro:
"O nó do Integration Runtime (auto-hospedado) encontrou um erro durante o registro."
Causa
O IR auto-hospedado não pode se conectar ao back-end do serviço. Esse problema geralmente é causado por configurações de rede no firewall.
Resolução
Verifique se o serviço runtime de integração está em execução. Se estiver, vá para a etapa 2.
Se nenhum proxy estiver configurado no IR auto-hospedado, que é a configuração padrão, execute o seguinte comando do PowerShell no computador em que o runtime de integração auto-hospedada está instalado:
(New-Object System.Net.WebClient).DownloadString("https://wu2.frontend.clouddatahub.net/")Observação
A URL do serviço pode variar, dependendo do local do data factory ou da instância do workspace do Synapse. Para localizar a URL do serviço, use a página Gerenciar da interface do usuário em seu data factory ou instância do Azure Synapse para encontrar runtimes de integração e selecione seu IR auto-hospedado para editá-lo. Lá, selecione a guia Nós e selecione Exibir URLs de serviço.
A resposta esperada é a seguinte:
Se você não receber a resposta esperada, use um dos seguintes métodos, conforme apropriado:
- Se você receber uma mensagem "O nome remoto não pôde ser resolvido", há um problema de DNS (Sistema de Nomes de Domínio). Entre em contato com sua equipe de rede para corrigir o problema.
- Se você recebeu uma mensagem "Certificado SSL/TLS não confiável", Marque o certificado (
https://wu2.frontend.clouddatahub.net/) para ver se ele é confiável no computador e instale o certificado público usando o Gerenciador de Certificados. Essa ação deve mitigar o problema. - Acesse Visualizador de Eventos do Windows>(logs)>Logs >de Aplicativos e ServiçosIntegrationRuntime e marque se há falhas causadas pelo DNS, uma regra de firewall ou configurações de rede da empresa. Se você encontrar tal falha, feche a conexão à força. Como cada empresa tem suas próprias configurações de rede personalizadas, entre em contato com sua equipe de rede para solucionar esses problemas.
Se o "proxy" tiver sido configurado no runtime de integração auto-hospedada, verifique se o servidor proxy pode acessar o ponto de extremidade de serviço. Para obter um comando de exemplo, consulte PowerShell, solicitações da 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
A resposta esperada é a seguinte:
Observação
Considerações sobre proxy:
- Verifique se o servidor proxy precisa ser colocado na lista de Destinatários Confiáveis. Em caso afirmativo, verifique se esses domínios estão na lista de Destinatários Confiáveis.
- Verifique se o certificado SSL/TLS "wu2.frontend.clouddatahub.net/" é confiável no servidor proxy.
- Se você estiver usando a autenticação do Active Directory no proxy, altere a conta de serviço para a conta de usuário que pode acessar o 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 auto-hospedado não pôde se conectar ao Microsoft Purview.
Ao marcar o log de eventos de IR auto-hospedado depois de acessar o Visualizador de Eventos do Windows>(logs)>Logs > de Aplicativos e ServiçosIntegrationRuntime, você encontrará a seguinte mensagem de erro:
"A conexão subjacente foi fechada: não foi possível estabelecer uma 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 maneira mais simples de marcar o certificado do servidor do serviço é abrir a URL do serviço no navegador. Por exemplo, abra o link de certificado do servidor de marcar ((https://eu.frontend.clouddatahub.net/) no computador em que o IR auto-hospedado está instalado e exiba as informações de certificado do servidor.
Causa
Há dois motivos possíveis para esse problema:
- Motivo 1: a CA raiz do certificado de servidor do serviço não é confiável no computador em que o IR auto-hospedado está instalado.
- Razão 2: você está usando um proxy em seu ambiente, o certificado do servidor do serviço é substituído pelo proxy e o certificado do servidor substituído não é confiável para o computador em que o IR auto-hospedado está instalado.
Resolução
- Razão 1: verifique se o certificado do servidor do serviço e sua cadeia de certificados são confiáveis para o computador em que o IR auto-hospedado está instalado.
- Pelo motivo 2: confie na AC raiz substituída no computador de IR auto-hospedado 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 Instalando o certificado raiz confiável.
Mais informações
Lançamos um novo certificado SSL, que é assinado pela DigiCert. Verifique se o DigiCert Global Root G2 está na CA raiz confiável.
Se não estiver na AC raiz confiável, baixe-o aqui.
Próximas etapas
Para obter mais ajuda com a solução de problemas, experimente os seguintes recursos: