Resolver problemas do runtime de integração autoalojado

APLICA-SE A: Azure Data Factory Azure Synapse Analytics Microsoft Purview

Gorjeta

Experimente o Data Factory no Microsoft Fabric, uma solução de análise tudo-em-um para empresas. O Microsoft Fabric abrange tudo, desde a movimentação de dados até ciência de dados, análises em tempo real, business intelligence e relatórios. Saiba como iniciar uma nova avaliação gratuitamente!

Este artigo explora métodos comuns de solução de problemas para o tempo de execução de integração (IR) auto-hospedado nos espaços de trabalho do Azure Data Factory e Synapse.

Reunir logs de IR auto-hospedados

Azure Data Factory e Azure Synapse Analytics

Para atividades com falha que estão sendo executadas em um IR auto-hospedado ou um IR compartilhado, o serviço suporta a visualização e upload de logs de erros. Para obter o ID do relatório de erros, siga as instruções aqui e insira o ID do relatório para procurar problemas conhecidos relacionados.

1. Na página Monitor da interface do usuário do serviço, selecione Pipeline runs.

2. Em Execuções de atividade, na coluna Erro , selecione o botão realçado para exibir os logs de atividades, conforme mostrado na captura de tela a seguir:

   Fábrica de Dados do Azure

   

   Azure Synapse

   

   Os logs de atividade são exibidos para a execução da atividade com falha.

   

3. Para obter mais assistência, selecione Enviar logs.

   A janela Compartilhar os logs de IR (tempo de execução de integração) auto-hospedados com a Microsoft é aberta.

   

4. Selecione quais logs você deseja enviar.

   • Para um IR auto-hospedado, você pode carregar logs relacionados à atividade com falha ou todos os logs no nó IR auto-hospedado.
   • Para um IR compartilhado, você pode carregar somente logs relacionados à atividade com falha.

5. Quando os logs forem carregados, mantenha um registro da ID do relatório para uso posterior se precisar de mais assistência para resolver o problema.

   

Nota

As solicitações de visualização e upload de logs são executadas em todas as instâncias de RI auto-hospedadas online. Se algum log estiver faltando, certifique-se de que todas as instâncias de IR auto-hospedadas estão online.

Microsoft Purview

Para atividades com falha do Microsoft Purview que estão sendo executadas em um IR auto-hospedado ou IR compartilhado, o serviço oferece suporte à exibição e upload de logs de erro do Visualizador de Eventos do Windows.

Você pode procurar quaisquer erros que você vê no guia de erros abaixo. Para obter suporte e orientação de solução de problemas para problemas SHIR, talvez seja necessário gerar uma ID de relatório de erro 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:

1. Antes de iniciar uma verificação no portal de governança do Microsoft Purview:

   1. Navegue até a máquina onde o tempo de execução de integração auto-hospedado está instalado e abra o Visualizador de Eventos do Windows.
   2. Limpe os logs do Visualizador de Eventos do Windows na seção Tempo de Execução de Integração . Clique com o botão direito do mouse nos logs e selecione a opção limpar logs.
   3. Navegue de volta para o portal de governança do Microsoft Purview e inicie a verificação.

2. Quando a verificação mostrar o status Falha, navegue de volta para a VM ou máquina SHIR e atualize o visualizador de eventos na seção Integration Runtime .

3. Os logs de atividade são exibidos para a execução da verificação com falha.

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

   A janela Compartilhar os logs do tempo de execução de integração auto-hospedado (SHIR) com a Microsoft é aberta.

   

5. Selecione quais logs você deseja enviar.

   • Para um IR auto-hospedado, você pode carregar logs relacionados à atividade com falha ou todos os logs no nó IR auto-hospedado.
   • Para um IR compartilhado, você pode carregar somente logs relacionados à atividade com falha.

6. Quando os logs forem carregados, mantenha um registro da ID do relatório para uso posterior se precisar de mais assistência para resolver o problema.

   

Nota

As solicitações de visualização e upload de logs são executadas em todas as instâncias de RI auto-hospedadas online. Se algum log estiver faltando, certifique-se de que todas as instâncias de IR auto-hospedadas estão online.

Erro ou falha geral do IR Autoalojado

Problema de memória esgotada

• Sintomas

  Um erro OutOfMemoryException (OOM) ocorre quando tenta executar uma atividade de procura com um IR ligado ou um IR autoalojado.

• Motivo

  Uma nova atividade poderá causar um erro OOM se o computador de IR registar momentaneamente uma elevada utilização da memória. Este problema pode ser causado por um grande volume de atividade simultânea e o erro é propositado.

• Resolução

  Verifique a utilização de recursos e a execução de atividade simultânea no nó IR. Ajuste o tempo de acionamento e interno da execução de atividade, para evitar uma execução excessiva num único nó de IR ao mesmo tempo.

Problema de limite de trabalhos simultâneos

• Sintomas

  Quando você tenta aumentar o limite de trabalhos simultâneos da interface do usuário, o processo trava em Status de atualização .

  Cenário de exemplo: O valor máximo de tarefas simultâneas está atualmente definido para 24 e quer aumentar a contagem para que as tarefas possam ser executadas mais rapidamente. O valor mínimo que pode introduzir é 3 e o valor máximo é 32. Você aumenta o valor de 24 para 32 e, em seguida, selecione o botão Atualizar . O processo fica preso no status de atualização , conforme mostrado na captura de tela a seguir. Atualiza a página e o valor ainda é apresentado como 24. Não foi atualizado para 32 como esperava.

  

• Motivo

  O limite do número de tarefas simultâneas depende do núcleo lógico e da memória do computador. Tente ajustar para baixo para um valor como 24 e, em seguida, veja o resultado.

  Gorjeta

  • Para saber mais sobre a contagem de núcleos lógicos e determinar o número de núcleos lógicos do computador, veja Quatro formas de encontrar o número de núcleos na CPU no Windows 10.
  • Para saber como calcular o math.log, aceda à Calculadora de logaritmos.

Problema com o certificado SSL de elevada disponibilidade (HA) do IR Autoalojado

• Sintomas

  O nó de trabalho do IR autoalojado apresentou o erro seguinte:

  “Não foi possível solicitar estados partilhados do nó primário net.tcp://abc.cloud.corp.Microsoft.com:8060/ExternalService.svc/. ID de atividade: XXXXX O certificado X.509 CN=abc.cloud.corp.Microsoft.com, OU=teste, O=Falha da compilação da cadeia da Microsoft. O certificado utilizado tem uma cadeia de confiança que não pode ser verificada. Substitua o certificado ou altere o certificado Modo de Validação. A função de revogação não conseguiu verificar a revogação porque o servidor de revogação estava offline.”

• Motivo

  Quando processa casos relacionados com o handshake do SSL/TLS, pode encontrar alguns problemas relacionados com a verificação da cadeia de certificados.

• Resolução

  • Veja a seguir uma forma rápida e intuitiva de resolver problemas de falha de compilação da cadeia de certificados X.509:

    1. Exporte o certificado, que precisa de ser verificado. Para tal, faça o seguinte:

       a. No Windows, selecione Iniciar, comece a escrever certificados e, em seguida, selecione Gerir certificados de computador.

       b. No Explorador de Ficheiros, no painel esquerdo, procure o certificado que quer verificar, clique com o botão direito do rato e, em seguida, selecione Todas as tarefas>Exportar.

       

    2. Copie o certificado exportado para o computador cliente.

    3. Do lado do cliente, numa janela da Linha de Comandos, execute o seguinte comando. Certifique-se de substituir <o caminho> do certificado e< o caminho> do arquivo txt de saída pelos caminhos reais.

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

       Por exemplo:

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

    4. Verifique se há erros no ficheiro TXT de saída. Pode encontrar o resumo dos erros no final do ficheiro TXT.

       Por exemplo:

       

       Se você não vir um erro no final do arquivo de log, conforme mostrado na captura de tela a seguir, poderá considerar que a cadeia de certificados foi criada com êxito na máquina cliente.

       

  • Se uma extensão de nome de ficheiro AIA (Acesso a Informações sobre a Autoridade), CDP (Ponto de Distribuição CRL) ou OCSP (Protocolo de Estado de Certificado Online) estiver configurada no ficheiro de certificado, poderá verificar de uma forma mais intuitiva:

    1. Obtenha essas informações verificando os detalhes do certificado, conforme mostrado na captura de tela a seguir:

       

    2. Execute o seguinte comando. Certifique-se de substituir <o caminho> do certificado pelo caminho real do certificado.

         Certutil   -URL    <certificate path> 
       

       A ferramenta de Obtenção de URLs é aberta.

    3. Para verificar certificados com extensões de nomes de ficheiro AIA, CDP e OCSP, selecione Obter.

       

       Você criou a cadeia de certificados com êxito se o status do certificado do AIA for Verificado e o status do certificado da CDP ou OCSP for Verificado.

       Se ocorrer uma falha ao tentar obter o AIA ou o CDP, trabalhe com a equipa de rede para preparar o computador cliente para se ligar ao URL de destino. Será suficiente se o caminho HTTP ou o caminho do protocolo LDAP (Lightweight Directory Access Protocol) puder ser verificado.

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

• Sintomas

  Receberá mensagem de erro seguinte:

  “Não foi possível carregar o ficheiro ou a montagem “XXXXXXXXXXXXXXXX, Versão=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXXX” ou uma das dependências. O sistema não consegue encontrar o ficheiro especificado. ID da Atividade: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3”

  Veja a seguir uma mensagem de erro mais específica:

  “Não foi possível carregar o ficheiro ou a montagem “System.ValueTuple, Versão=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXXX” ou uma das dependências. O sistema não consegue encontrar o ficheiro especificado. ID da Atividade: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3”

• Motivo

  No Process Monitor, você pode exibir o seguinte resultado:

  

  Gorjeta

  No Monitor de Processos, pode definir os filtros como mostrado na captura de ecrã seguinte.

  A mensagem de erro anterior diz que a DLL System.ValueTuple não está localizada na pasta GAC (Global Assembly Cache) 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 da pasta GAC , depois da pasta compartilhada e, finalmente, da pasta Gateway . Portanto, pode carregar o DLL a partir 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 resolver o problema, copie o arquivo System.ValueTuple.dll para a pasta C:\Program Files\Microsoft Integration Runtime\4.0\Gateway .

  Pode utilizar o mesmo método para resolver outros problemas de ficheiros ou assemblagens em falta.

• Mais informações sobre esta questão

  A razão pela qual você vê o System.ValueTuple.dll em %windir%\Microsoft.NET\assembly e %windir%\assembly é que esse é um comportamento .NET.

  No erro a seguir, você pode ver claramente que o assembly System.ValueTuple está faltando. Esse problema surge quando o aplicativo tenta verificar o assembly System.ValueTuple.dll .

  "<LogProperties><ErrorInfo>[{"Code":0,"Message":"O inicializador de 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 consegue encontrar 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 a GAC, veja Global Assembly Cache.

Falta a Chave de Autenticação do Runtime de integração autoalojado

• Sintomas

  O runtime de integração autoalojado fica subitamente 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”

  

• Motivo

  • O nó do IR autoalojado ou o IR autoalojado lógico no portal do Azure foi eliminado.
  • Foi realizada uma desinstalação limpa.

• Resolução

  Se nenhuma das causas anteriores se aplicar, você pode ir para a pasta %programdata%\Microsoft\Data Transfer\DataManagementGateway para ver se o arquivo de configurações foi excluído. Se tiver sido eliminado, siga as instruções do artigo da Netwrix Detetar quem eliminou um ficheiro dos servidores de ficheiros do Windows.

  

Não é possível utilizar o IR autoalojado para ligar dois arquivos de dados no local

• Sintomas

  Depois de criar os IRs autoalojados para os arquivos de dados de origem e de destino, deve ligar os dois IRs para concluir a atividade de cópia. Se os arquivos de dados estiverem configurados em diferentes redes virtuais ou não entenderem o mecanismo do gateway, receberá um dos seguintes erros:

  • “Não é possível localizar o controlador da origem no IR de destino”
  • “Não é possível aceder à origem pelo IR de destino”

• Motivo

  O IR autoalojado foi criado como um nó central de uma atividade de cópia, não como um agente cliente que precisa de ser instalado para cada arquivo de dados.

  Neste caso, deverá criar o serviço associado para cada arquivo de dados com o mesmo IR e o IR deverá poder aceder a ambos os arquivos de dados através da rede. Não importa se o IR está instalado no arquivo de dados de origem ou de destino ou num terceiro computador. Se forem criados dois serviços ligados com IRs diferentes, mas utilizados na mesma atividade de cópia, o IR de destino será utilizado e precisará de instalar os controladores para ambos os arquivos de dados no computador do IR de destino.

• Resolução

  Instale os controladores para os arquivos de dados de origem e de destino no IR de destino e verifique se consegue aceder ao arquivo de dados de origem.

  Se o tráfego não puder passar pela rede entre os dois arquivos de dados (por exemplo, estão configurados em duas redes virtuais), poderá não terminar a cópia numa só atividade mesmo com o IR instalado. Se não conseguir terminar a cópia numa única atividade, poderá criar duas atividades de cópia com dois IRs, cada uma num VENT:

  • Copie um IR do arquivo de dados 1 para o Armazenamento de Blobs do Azure
  • Copie o outro IR do Armazenamento de Blobs do Azure para o arquivo de dados 2.

  Esta solução poderá simular a condição de utilizar o IR para criar uma ponte que liga dois arquivos de dados desligados.

O problema de sincronização de credenciais causa a perda de credenciais da HA

• Sintomas

  Se a credencial da origem de dados “XXXXXXXXX” for eliminada do nó de runtime de integração atual com payload, receberá a seguinte mensagem de erro:

  “Quando eliminar o serviço de ligação no portal do Azure ou a tarefa tiver o payload incorreto, crie novamente um novo serviço de ligação com a credencial”.

• Motivo

  O IR autoalojado é criado no modo HA com dois nós, mas os nós não estão num estado de sincronização de credenciais. Tal significa que as credenciais armazenadas no nó do despachante não estão sincronizadas com os outros nós de trabalho. Se ocorrer alguma ativação pós-falha entre o nó do despachante e o nó de trabalho e se as credenciais existirem apenas no nó do despachante anterior, a tarefa falhará quando tentar aceder às credenciais e receberá o erro anterior.

• Resolução

  A única forma de evitar este problema é verificar se os dois nós estão no estado de sincronização de credenciais. Se não estiverem sincronizados, terá de reintroduzir as credenciais do novo despachante.

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

• Sintomas

  • Importou um ficheiro PFX para o arquivo de certificados.

  • Quando selecionou o certificado através da IU do Configuration Manager do IR, recebeu a seguinte mensagem de erro:

    “Falha ao alterar o modo de encriptação da comunicação da Intranet. É provável que o certificado '<nome> do certificado' não tenha uma chave privada capaz de troca de chaves ou o processo pode não ter direitos de acesso para a chave privada. Por favor, veja a exceção interna para detalhes.""

• Motivo

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

• Resolução

  • Para operar na 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
    

Problema com nós do Runtime de integração autoalojado não sincronizados

• Sintomas

  Os nós do Runtime de integração autoalojado tentam sincronizar as credenciais nos nós, mas ficam bloqueados no processo. A mensagem de erro abaixo é apresentada após algum tempo:

  “O nó do Integration Runtime (Autoalojado) está a tentar sincronizar as credenciais nos nós. Esta operação poderá demorar alguns minutos”.

  Nota

  Se esse erro aparecer por mais de 10 minutos, verifique a conectividade com o nó do dispatcher.

• Motivo

  O motivo é os nós de trabalho não terem acesso às chaves privadas. Pode confirmar isto nos registos do runtime de integração autoalojado abaixo:

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

  Não tem qualquer problema com o processo de sincronização quando utiliza a autenticação do principal de serviço no serviço associado. No entanto, quando troca o tipo de autenticação para chave de conta, verificas o problema de sincronização. Este problema ocorre porque o serviço de runtime de integração autoalojado é executado numa conta de serviço (SERVIÇO NT\DIAHostService) e tem de ser adicionado às permissões de chave privada.

• Resolução

  Para resolver este problema, tem de adicionar a conta de serviço do runtime de integração autoalojado (SERVIÇO NT\DIAHostService) às permissões de chave privada. Pode realizar os seguintes passos:

  1. Abrir o Comando Executar na Consola de Gestão Microsoft (MMC)

     

  2. No painel MMC, aplique as seguintes etapas:

     

     1. Selecione Ficheiro.
     2. Escolha Adicionar/Remover Snap-in no menu pendente.
     3. Selecione Certificados no painel “Snap-ins disponíveis”.
     4. Selecione Adicionar.
     5. No painel “Certificados snap-in” do item de pop-up, escolha Conta do computador.
     6. Selecione Seguinte.
     7. No painel “Selecionar Computador”, escolha Computador local: o computador no qual a consola está a ser executada.
     8. Selecione Concluir.
     9. Selecione OK no painel “Adicionar ou Remover Snap-ins”.

  3. No painel do MMC, siga em frente com as seguintes etapas:

     

     1. Na lista de pastas à esquerda, selecione Raiz do Console -> Certificados (Computador Local) -> Pessoal -> Certificados.
     2. Clique com o botão direito do rato em Microsoft Intune Beta MDM.
     3. Selecione Todas as Tarefas na lista pendente.
     4. Selecione Gerir Chaves Privadas.
     5. Selecione Adicionar em “Grupos ou nomes de utilizadores”.
     6. Selecione SERVIÇO NT\DIAHostService para lhe conceder acesso com controlo total a este certificado, aplicá-lo e protegê-lo.
     7. Selecione Verificar Nomes e, em seguida, OK.
     8. No painel “Permissões”, selecione Aplicar e, em seguida, OK.

Mensagem de erro UserErrorJreNotFound ao executar uma atividade de cópia no Azure

• Sintomas

  Quando tenta copiar conteúdo para o Microsoft Azure com uma ferramenta ou um programa baseado em Java (por exemplo, copiar ficheiros de formato ORC ou Parquet), receberá uma mensagem de erro parecida com a seguinte:

  ErrorCode=UserErrorJreNotFound,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Não é possível encontrar o Java Runtime Environment. Aceda a http://go.microsoft.com/fwlink/?LinkId=808605 para transferir e instalar no computador do nó do Integration Runtime (Autoalojado). Nota: o Integration Runtime de 64 bits exige o JRE de 64 bits e o Integration Runtime de 32 bits exige o JRE de 32 bits.,Source=Microsoft.DataTransfer.Common,''Type=System.DllNotFoundException,Message=Não é possível carregar a DLL “jvm.dll”: não foi possível encontrar o módulo especificado. (Exceção de HRESULT: 0x8007007E),Source=Microsoft.DataTransfer.Richfile.HiveOrcBridge

• Motivo

  Este problema ocorre por um dos seguintes motivos:

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

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

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

• Resolução

  Siga cuidadosamente os passos indicados nesta secção. Poderão ocorrer problemas graves se modificar o registo de forma incorreta. Antes de o modificar, faça uma cópia de segurança do registo para restauro caso ocorram problemas.

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

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

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

       Nota

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

     • Java Runtime (JRE) é a versão 11 ou superior, de um provedor JRE como o Microsoft OpenJDK 11 ou Eclipse Temurin 11. Certifique-se de que a variável de ambiente do sistema JAVA_HOME esteja definida para a pasta JDK (não apenas a pasta JRE), você também pode precisar adicionar a pasta bin à variável de ambiente PATH do sistema.

  2. Verifique se o registo tem as definições corretas. Para o fazer, siga estes passos:

     1. No menu Executar, escreva Regedit e prima Enter.

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

        HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment.

        No painel Detalhes, deve existir uma entrada para a Versão Atual a mostrar a versão do JRE (por exemplo, 1.8).

        

     3. No painel de navegação, localize uma subchave que seja uma correspondência exata da 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.

        

  3. Localize a pasta classe\servidor no seguinte caminho:

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

     

  4. Verifique se esta pasta tem um ficheiro jvm.dll. Se isso não acontecer, verifique o bin\client arquivo na pasta.

     

  Nota

  • Se alguma destas configurações não estiver conforme descrita nestes passos, utilize o Windows Installer do 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 de IR auto-hospedada

Erro de registro do tempo de execução da 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 não permite a conta de serviço.
  • É necessário algum tipo de autenticação.

  Depois de alterar a conta de serviço no painel de serviço, você pode achar que o tempo de execução de integração para de funcionar e você recebe a seguinte mensagem de erro:

  "O nó Integration Runtime (Self-hosted) encontrou um erro durante o registro. Não é possível ligar ao Serviço de Anfitrião do Integration Runtime (Autoalojado)”.

  

• Motivo

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

• Resolução

  Vá para o log de eventos do tempo de execução de integração para verificar o erro.

  

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

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

       

    2. Verifique se a conta de serviço de logon tem permissões de leitura/gravação para a pasta %programdata%\Microsoft\DataTransfer\DataManagementGateway .

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

         

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

         a. Realize uma desinstalação limpa do IR autoalojado atual.
         b. Instale os bits do IR autoalojado.
         c. Altere a conta de serviço ao fazer o seguinte:

         i. Aceda à pasta de instalação do IR autoalojado e, em seguida, mude para a pasta Microsoft Integration Runtime\4.0\Shared.
         ii. Abra uma janela da linha de comandos com privilégios elevados. Substitua <usuário> e< senha> por seu próprio nome de usuário e senha e execute o seguinte comando:
         dmgcmd.exe -SwitchServiceAccount "<user>" "<password>"
         iii. Se quiser mudar para a conta LocalSystem, não se esqueça de utilizar o formato correto para esta conta: dmgcmd.exe -SwitchServiceAccount "NT Authority\System" ""
         Não utilize este formato: dmgcmd.exe -SwitchServiceAccount "LocalSystem" ""
         iv. Opcionalmente, como o Sistema Local tem privilégios mais altos do que o Administrador, você também pode alterá-lo diretamente em "Serviços".
         v. Pode utilizar um utilizador local/de domínio para a conta de serviço de início de sessão do serviço IR.

         d. Registe o integration runtime.

  • Se o erro for "Service '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:

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

       

    2. Verifique se a conta de serviço de logon tem permissão Fazer logon como um serviço para iniciar o serviço do Windows:

       

• Mais informações

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

  • Tempo de execução da integração de logs > de aplicativos e serviços
  • Aplicativo de logs > do Windows

Não consigo encontrar o botão Registar para registar um IR autoalojado

• Sintomas

  Quando você registra um IR auto-hospedado, o botão Registrar não é exibido no painel do Gerenciador de Configurações.

  

• Motivo

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

• Resolução

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

     Importante

     No processo a seguir, selecione Sim. Não guarde dados durante o processo de desinstalação.

     

  2. Se não tiver o ficheiro MSI do programa de instalação do runtime de integração, aceda ao Centro de transferência para transferir o runtime de integração mais recente.

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

Não consigo registar o IR autoalojado por causa do localhost

• Sintomas

  Você não consegue registrar o IR auto-hospedado em uma nova máquina quando você usa get_LoopbackIpOrName.

  Depuração: Ocorreu um erro de tempo de execução. O inicializador de tipo de “Microsoft.DataTransfer.DIAgentHost.DataSourceCache” gerou uma exceção. Ocorreu um erro não recuperável durante uma pesquisa na base de dados.

  Detalhe da exceção: System.TypeInitializationException: O inicializador de tipo para 'Microsoft.DataTransfer.DIAgentHost.DataSourceCache' lançou uma exceção. >--- System.Net.Sockets.SocketException: Ocorreu um erro não recuperável durante uma pesquisa de banco de dados em System.Net.Dns.GetAddrInfo(nome da cadeia de caracteres).

• Motivo

  O problema geralmente ocorre quando o localhost está sendo resolvido.

• Resolução

  Use o endereço IP localhost 127.0.0.1 para hospedar o arquivo e resolver o problema.

Falha na instalaçã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.

• Motivo

  A instalação do tempo de execução de integração depende do serviço Windows Installer. Você pode ter problemas de instalação pelos seguintes motivos:

  • Espaço disponível em disco insuficiente.
  • Falta de permissões.
  • O serviço Windows NT está bloqueado.
  • A utilização da CPU é muito alta.
  • O arquivo MSI está hospedado em um local de rede lento.
  • Alguns ficheiros de sistema ou registos foram tocados sem intenção.

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

• Sintomas

  Quando você instala um IR auto-hospedado por meio do Microsoft Integration Runtime Configuration Manager, um certificado com uma autoridade de certificação (CA) confiável é gerado. O certificado não pôde ser aplicado 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 Integration Runtime o acesso ao certificado '<nome> do certificado'. Código de erro 103"

• Motivo

  O certificado está usando o armazenamento KSP (provedor de armazenamento de chaves), que ainda não é suportado. Até o momento, o IR auto-hospedado suporta apenas armazenamento de provedor de serviços criptográficos (CSP).

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

  

  

Tempo de execução de integração auto-hospedado versão 5.x

Para a atualização para a versão 5.x do tempo de execução de integração auto-hospedado, precisamos do .NET Framework Runtime 4.7.2 ou posterior. Na página de download, você encontrará links para download da versão 4.x mais recente e das duas versões 5.x mais recentes.

Para clientes do Azure Data Factory v2 e do Azure Synapse:

• Se a atualização automática estiver ativada e você já tiver atualizado seu .NET Framework Runtime para 4.7.2 ou posterior, o tempo de execução de integração auto-hospedado 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 seu .NET Framework Runtime para 4.7.2 ou posterior, o tempo de execução de integração auto-hospedado não será atualizado automaticamente para a versão 5.x mais recente. O tempo de execução de integração auto-hospedado 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 tempo de execução de integração auto-hospedado.
• Se a atualização automática estiver desativada e você já tiver atualizado seu .NET Framework Runtime para 4.7.2 ou posterior, poderá baixar manualmente o 5.x mais recente e instalá-lo em sua máquina.
• Se a atualização automática estiver desativada e você não tiver atualizado seu .NET Framework Runtime para 4.7.2 ou posterior. Quando você tenta instalar manualmente o tempo de execução de integração auto-hospedado 5.x e registrar a chave, será necessário atualizar sua versão do .NET Framework Runtime primeiro.

Problemas de conectividade de IR auto-hospedados

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, o Configuration Manager apresenta a seguinte mensagem de erro:

  “O nó do Integration Runtime (Autoalojado) encontrou um erro durante o registo”.

  

• Motivo

  O IR auto-hospedado não pode se conectar ao back-end do serviço. Este problema é normalmente causado pelas definições da rede na firewall.

• Resolução

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

     

  2. Se não estiver configurado qualquer proxy no IR autoalojado, 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/")
     

     Nota

     A URL do serviço pode variar, dependendo do local da sua fábrica de dados ou da instância do espaço de trabalho Sinapse. 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 localizar tempos de execução de integração e clique em seu IR auto-hospedado para editá-lo. Lá, selecione a guia Nós e clique em Exibir URLs de serviço.

     O seguinte é a resposta esperada:

     

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

     • Se receber uma mensagem “Não foi possível resolver o nome remoto”, significa que existe um problema no Sistema de Nomes de Domínio (DNS). Contacte a equipa de rede para corrigir o problema.
     • Se você receber uma mensagem "ssl/tls cert is not trusted", verifique o certificado (https://wu2.frontend.clouddatahub.net/) para ver se ele é confiável na máquina e instale o certificado público usando o Gerenciador de Certificados. Esta ação deve mitigar o problema.
     • Aceda a Windows>Visualizador de eventos (registos) >Registos de Aplicações e serviços>Integration Runtime e verifique se existe alguma falha causada pelo DNS, regra de firewall ou definição de rede da empresa. Se encontrar uma falha, force o encerramento da ligação. Como cada empresa tem as suas próprias definições de rede personalizadas, contacte a equipa de rede para resolver estes problemas.

  4. Se o “proxy” tiver sido configurado no runtime de integração autoalojado, verifique se o servidor proxy consegue aceder ao ponto final de serviço. Para obter um comando de amostra, 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
     

  O seguinte é a resposta esperada:

  

  Nota

  Considerações sobre procuração:

  • Verifique se o servidor proxy precisa ser colocado na lista de destinatários seguros. Se assim for, verifique se estes domínios estão na lista de Destinatários Seguros.
  • Verifique se o certificado wu2.frontend.clouddatahub.net/ SSL/TLS é confiável no servidor proxy.
  • Se estiver a utilizar a autenticação do Azure Active Directory no proxy, altere a conta de serviço para a conta de utilizador que pode aceder ao proxy como “Serviço do Integration Runtime”.

Mensagem de erro: Nó de tempo de execução de integração auto-hospedada/IR lógico auto-hospedado está no estado Inativo/ "Em execução (limitado)"

• Motivo

  O nó de tempo de execução integrado auto-hospedado pode ter um status de Inativo, conforme mostrado na captura de tela a seguir:

  

  Este comportamento ocorre quando os nós não conseguem comunicar uns com os outros.

• Resolução

  1. Inicie sessão na máquina virtual (VM) que aloja o nó. Em Registos de Aplicações e Servidores>Runtime de Integração, abra o Visualizador de Eventos e filtre os registos de erros.

  2. Verifique se um log de erros contém o seguinte erro:

     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 vir este erro, execute o seguinte comando numa janela da Linha de Comandos:

     telnet 10.2.4.10 8060
     

  4. Se você receber o erro de linha de comando "Não foi possível abrir a conexão com o host" mostrado na captura de tela a seguir, entre em contato com o departamento de TI para obter ajuda para corrigir esse problema. Quando conseguir executar o telnet com êxito, contacte o Suporte da Microsoft se continuar a registar problemas com o estado do nó do runtime de integração.

     

  5. Verifique se o registo de erros contém a seguinte entrada:

     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. Para resolver o problema, experimente um dos métodos seguintes:

     • Coloque todos os nós no mesmo domínio.
     • Adicione o IP para alojar o mapeamento em todos os ficheiros anfitriões da VM alojada.

Problema de conectividade entre o IR auto-hospedado e sua fábrica de dados ou instância do Azure Synapse ou o IR auto-hospedado e a fonte de dados ou coletor

Para solucionar o problema de conectividade de rede, você deve saber como coletar o rastreamento de rede, entender como usá-lo e analisar o rastreamento do Microsoft Network Monitor (Netmon) antes de aplicar as Ferramentas Netmon em casos reais do IR auto-hospedado.

• Sintomas

  Ocasionalmente, você pode precisar solucionar certos problemas de conectividade entre o IR auto-hospedado e sua fábrica de dados ou instância do Azure Synapse, conforme mostrado na captura de tela a seguir, ou entre o IR auto-hospedado e a fonte de dados ou coletor.

  

  Em qualquer dos casos, poderá encontrar os seguintes erros:

  • “A cópia falhou com o erro: Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Não é possível ligar ao SQL Server: 'endereço IP'”

  • “Ocorreu um ou mais erros. Ocorreu um erro durante o envio do pedido. A ligação subjacente foi encerrada: ocorreu um erro inesperado numa receção. Não é possível ler os dados da ligação de transporte: uma ligação existente foi forçada a fechar por um anfitrião remoto. Uma ligação existente foi forçada a fechar pelo ID de Atividade de anfitrião remoto”.

• Resolução

  Quando encontrar os erros anteriores, solucione-os seguindo as instruções nesta seção.

  • Colete um rastreamento Netmon para análise:

    1. Você pode definir o filtro para ver uma redefinição do servidor para o lado do cliente. Na captura de tela de exemplo a seguir, você pode ver que o lado do servidor é o servidor Data Factory.

       

    2. Quando você recebe o pacote de redefinição, você pode encontrar a conversa seguindo o protocolo TCP (Transmission Control Protocol).

       

    3. Obtenha a conversa entre o cliente e o servidor do Data Factory removendo o filtro.

  • Uma análise do rastreamento Netmon que você coletou mostra que o total de Tempo de Vida (TTL)) é 64. De acordo com os valores mencionados no artigo IP Time to Live (TTL) e Hop Limit Basics , extraídos na lista a seguir, você pode ver que é o sistema Linux que redefine o pacote e causa a desconexão.

    Os valores padrão de TTL e Hop Limit variam entre diferentes sistemas operacionais, conforme listado aqui:

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

    

    No exemplo anterior, o TTL é mostrado como 61 em vez de 64, porque quando o pacote de rede chega ao seu destino, ele precisa passar por vários saltos, como roteadores ou dispositivos de rede. O número de roteadores ou dispositivos de rede é deduzido para produzir o TTL final.

    Neste caso, você pode ver que uma redefinição pode ser enviada do sistema Linux com TTL 64.

  • Para confirmar de onde o dispositivo de redefinição pode vir, verifique o quarto salto do IR auto-hospedado.

    Pacote de rede do Linux System A com TTL 64 -> B TTL 64 menos 1 = 63 -> C TTL 63 menos 1 = 62 -> TTL 62 menos 1 = 61 IR auto-hospedado

  • Em uma situação ideal, o número de saltos TTL seria 128, o que significa que o sistema operacional Windows está executando sua instância de fábrica de dados. Como mostrado no exemplo a seguir, 128 menos 107 = 21 saltos, o que significa que 21 saltos para o pacote foram enviados da instância do data factory para o IR auto-hospedado durante o handshake TCP 3.

    

    Portanto, você precisa envolver a equipe de rede para verificar qual é o quarto salto do IR auto-hospedado. Se for o firewall, como acontece com o sistema Linux, verifique todos os logs para ver por que esse dispositivo redefine o pacote após o handshake TCP 3.

    Se você não tiver certeza de onde investigar, tente obter o rastreamento Netmon do IR auto-hospedado e do firewall durante o tempo problemático. Essa abordagem ajudará você a descobrir qual dispositivo pode ter redefinido o pacote e causado a desconexão. Nesse caso, você também precisa envolver sua equipe de rede para avançar.

Analise o rastreamento Netmon

Nota

As instruções a seguir se aplicam ao rastreamento Netmon. Como o rastreamento Netmon está atualmente sem suporte, você pode usar o Wireshark para essa finalidade.

Quando você tenta telnet 8.8.8.8 888 com o rastreamento Netmon coletado, você deve ver o rastreamento nas seguintes capturas de tela:

As imagens anteriores mostram que você não pôde fazer uma conexão TCP com o lado do servidor 8.8.8.8 na porta 888, então você vê dois pacotes adicionais SynReTransmit lá. Como o SELF-HOST2 de origem não pôde se conectar ao 8.8.8.8 com o primeiro pacote, ele continuará tentando fazer a conexão.

Gorjeta

Para fazer essa conexão, tente a seguinte solução:

1. Selecione Carregar Filtro Padrão>Filtrar>Endereços>IPv4 Endereços IPv4.
2. Para aplicar o filtro, digite IPv4.Address == 8.8.8.8 e selecione Aplicar. Em seguida, você verá a comunicação da máquina local para o destino 8.8.8.8.

Os cenários bem-sucedidos são mostrados nos seguintes exemplos:

• Se você puder telnet 8.8.8.8 53 sem problemas, há um handshake TCP 3 bem-sucedido e a sessão termina com um handshake TCP 4.

  

  

• O handshake TCP 3 anterior produz o seguinte fluxo de trabalho:

  

• O handshake TCP 4 para concluir a sessão é ilustrado pelos seguintes fluxos de trabalho:

  

  

Determinar se esta notificação o afeta

Esta notificação aplica-se aos seguintes cenários:

Cenário 1: Comunicação de saída de um tempo de execução de integração auto-hospedado que está sendo executado no local atrás de um firewall corporativo

Como determinar se você é afetado:

• Você não será afetado se estiver definindo regras de firewall com base em FQDNs (nomes de domínio totalmente qualificados) que usam a abordagem descrita em Configurar uma configuração de firewall e lista de permissões para endereços IP.

• Você será afetado se estiver ativando explicitamente a lista de permissões para IPs de saída no firewall corporativo.

  Se você for afetado, execute a seguinte ação: até 8 de novembro de 2020, notifique sua equipe de infraestrutura de rede para atualizar sua configuração de rede para usar os endereços IP de fábrica de dados mais recentes. Para baixar os endereços IP mais recentes, vá para Descobrir tags de serviço usando arquivos JSON para download.

Cenário 2: Comunicação de saída de um tempo de execução de integração auto-hospedado que está sendo executado em uma VM do Azure dentro de uma rede virtual do Azure gerenciada pelo cliente

Como determinar se você é afetado:

• Verifique se você tem alguma regra de NSG (grupo de segurança de rede) de saída em uma rede privada que contenha tempo de execução de integração auto-hospedada. Se não houver restrições de saída, você não será afetado.

• Se você tiver restrições de regras de saída, verifique se está usando tags de serviço. Se estiver a utilizar etiquetas de serviço, não será afetado. Não há necessidade de alterar ou adicionar nada, porque o novo intervalo de IP está sob suas tags de serviço existentes.

  

• Você será afetado se estiver habilitando explicitamente a lista de permissões para endereços IP de saída em sua configuração de regras NSG na rede virtual do Azure.

  Se você for afetado, execute a seguinte ação: até 8 de novembro de 2020, notifique sua equipe de infraestrutura de rede para atualizar as regras NSG em sua configuração de rede virtual do Azure para usar os endereços IP de fábrica de dados mais recentes. Para baixar os endereços IP mais recentes, vá para Descobrir tags de serviço usando arquivos JSON para download.

Cenário 3: Comunicação de saída do SSIS Integration Runtime em uma rede virtual do Azure gerenciada pelo cliente

Como determinar se você é afetado:

• Verifique se você tem alguma regra NSG de saída em uma rede privada que contenha o SQL Server Integration Services (SSIS) Integration Runtime. Se não houver restrições de saída, você não será afetado.

• Se você tiver restrições de regras de saída, verifique se está usando tags de serviço. Se estiver a utilizar etiquetas de serviço, não será afetado. Não há necessidade de alterar ou adicionar nada porque o novo intervalo de IP está sob suas tags de serviço existentes.

• Você será afetado se estiver habilitando explicitamente a lista de permissões para endereços IP de saída em sua configuração de regras NSG na rede virtual do Azure.

  Se você for afetado, execute a seguinte ação: até 8 de novembro de 2020, notifique sua equipe de infraestrutura de rede para atualizar as regras NSG em sua configuração de rede virtual do Azure para usar os endereços IP de fábrica de dados mais recentes. Para baixar os endereços IP mais recentes, vá para Descobrir tags de serviço usando arquivos JSON para download.

Não é 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 Azure Data Factory ou ao serviço Azure Synapse.

  Quando você verifica o log de eventos de IR auto-hospedado depois de ir para o Visualizador de eventos do Windows>(logs)>Tempo de execução de integração de logs>de aplicativos e serviços, 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 processo de validação”.

  A forma mais simples de verificar o certificado de servidor do serviço é abrir o URL de serviço no browser. Por exemplo, abra o link de certificado do servidor de verificação (https://eu.frontend.clouddatahub.net/) na máquina onde o IR auto-hospedado está instalado e exiba as informações do certificado do servidor.

  

  

• Motivo

  Existem dois motivos possíveis para este problema:

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

• Resolução

  • Para o motivo 1: confirme que o certificado de servidor do serviço e a cadeia de certificados associada são de confiança no computador onde o IR autoalojado está instalado.
  • Para o motivo 2: confie na AC de raiz substituída no computador com o IR autoalojado instalado ou configure o proxy para não substituir o certificado de servidor do serviço.

  Para obter mais informações sobre os certificados de confiança no Windows, veja Instalar o certificado de raiz fidedigna.

• Informações adicionais
  Implementámos um novo certificado SSL, com assinatura da DigiCert. Verifique se o DigiCert Global Root G2 está na AC de raiz fidedigna.

  

  Se não estiver na autoridade de certificação raiz confiável, baixe-a aqui.

Conteúdos relacionados

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

• Blogue do Data Factory
• Solicitações de recursos do Data Factory
• Vídeos do Azure
• Página de Perguntas e Respostas da Microsoft
• Fórum de estouro de pilha para o Data Factory
• X informações sobre Data Factory
• Guia de desempenho de fluxos de dados de mapeamento