Solucionar problemas de visualização de dependência

Este artigo ajuda você a solucionar problemas com a análise de dependência baseada em agente e sem agente, disponível apenas para servidores VMware. Saiba mais sobre os tipos de visualização de dependência com suporte nas Migrações para Azure.

Visualizar dependências por > uma hora com a análise de dependência sem agente

Com a análise de dependência sem agente, você pode visualizar dependências ou exportá-las em um mapa por uma duração de até 30 dias.

Visualizar dependências para > dez servidores com a análise de dependência sem agente

As Migrações para Azure oferecem um modelo de Power BI que você pode usar para visualizar conexões de rede de vários servidores ao mesmo tempo e filtrar por processo e servidor. Saiba mais sobre como visualizar as dependências de vários servidores em conjunto.

O CSV de exportação de dependências mostra "Processo desconhecido" com análise de dependência sem agente

Na análise de dependência sem agente, os nomes de processo são capturados com o melhor esforço. Em alguns cenários, embora os nomes do servidor de origem e de destino e a porta de destino sejam capturados, não é viável determinar os nomes dos processos em ambas as extremidades da dependência. Nesses casos, o processo é marcado como "Processo desconhecido".

Não é possível exportar os dados de dependência de um CSV devido ao erro "403: esta solicitação não está autorizada a executar esta operação"

Se o projeto de Migrações para Azure tiver uma conectividade de ponto de extremidade privado, a solicitação para exportar os dados de dependência deverá ser iniciada por meio de um cliente conectado à rede virtual do Azure em uma rede privada. Para resolver esse erro, abra o portal do Azure na rede local ou no servidor do dispositivo e tente exportá-los novamente.

Exportar os erros de análise de dependência

Você pode exportar todos os erros e correções para análise de dependência sem agente no portal selecionando Exportar notificações. O arquivo CSV exportado também contém informações adicionais, como o carimbo de data/hora em que o erro foi encontrado e se foi um erro na validação ou descoberta de dados de dependência.

Erros comuns da análise de dependência sem agente

As Migrações para Azure dão suporte à análise de dependência sem agente por meio das Migrações para Azure: Descoberta e avaliação. Saiba mais sobre como executar a análise de dependência sem agente.

Para VMs VMware, a análise de dependência sem agente é executada conectando-se aos servidores por meio do vCenter Server usando as APIs do VMware. Para VMs Hyper-V e servidores físicos, a análise de dependência sem agente é executada conectando-se diretamente a servidores Windows usando a comunicação remota do PowerShell na porta 5985 (HTTP) e em servidores Linux usando a conectividade SSH na porta 22 (TCP).

A tabela abaixo resume todos os erros encontrados ao coletar dados de dependência por meio de APIs do VMware ou conectando-se diretamente a servidores:

Observação

Os mesmos erros também podem ser encontrados com o inventário de software, pois ele segue a mesma metodologia da análise de dependência sem agente para coletar os dados necessários.

Erro	Causa	Ação
60001:UnableToConnectToPhysicalServer	Os pré-requisitos para se conectar ao servidor não foram atendidos ou há problemas de rede na conexão com o servidor, por exemplo, algumas configurações de proxy.	- Verifique se o servidor atende aos pré-requisitos e aos requisitos de acesso a porta. - Adicione os endereços de IP das máquinas remotas (servidores descobertos) à lista do WinRM TrustedHosts, no dispositivo de Migrações para Azure e repita a operação. Isso é feito para se permitir conexões de entrada remotas em servidores - Windows : portas 5985 (HTTP) do WinRM and Linux: SSH porta 22 (TCP). - Verifique se você escolheu o método de autenticação correto no dispositivo para se conectar ao servidor. - Se o problema persistir, envie um caso de suporte da Microsoft, fornecendo a ID da máquina do dispositivo (disponível no rodapé do Gerenciador de configuração do dispositivo).
60002:InvalidServerCredentials	Não é possível conectar ao servidor. Você forneceu credenciais incorretas no dispositivo ou as credenciais fornecidas anteriormente expiraram.	- Verifique se você forneceu as credenciais corretas para o servidor no dispositivo. Você pode verificar isso tentando se conectar ao servidor usando essas credenciais. - Se as credenciais adicionadas estiverem incorretas ou tiverem expirado, edite as credenciais no dispositivo e revalide os servidores adicionados. Se a validação for realizada com sucesso, o problema será resolvido. - Se o problema persistir, envie um caso de suporte da Microsoft, fornecendo a ID da máquina do dispositivo (disponível no rodapé do Gerenciador de configuração do dispositivo).
60005:SSHOperationTimeout	A operação demorou mais do que o esperado devido a problemas de latência de rede ou devido à falta de atualizações mais recentes no servidor.	- Verifique se o servidor afetado tem as atualizações mais recentes do kernel e do sistema operacional instaladas. - Verifique se não há nenhuma latência de rede entre o dispositivo e o servidor. É recomendável ter o dispositivo e o servidor de origem no mesmo domínio para evitar problemas de latência. - Conecte-se ao servidor afetado do dispositivo e execute os comandos documentados aqui para verificar se eles retornam dados nulos ou vazios. - Se o problema persistir, envie um caso de suporte da Microsoft, fornecendo a ID da máquina do dispositivo (disponível no rodapé do Gerenciador de configuração do dispositivo).
9000: não é possível detectar o status das ferramentas do VMware no servidor.	As ferramentas do VMware podem não estar instaladas no servidor ou a versão instalada está corrompida.	Verifique se as ferramentas do VMware instaladas e em execução no servidor são posteriores à versão 10.2.1.
9001: as ferramentas do VMware não estão instaladas no servidor.	As ferramentas do VMware podem não estar instaladas no servidor ou a versão instalada está corrompida.	Verifique se as ferramentas do VMware instaladas e em execução no servidor são posteriores à versão 10.2.1.
9002: as ferramentas do VMware não estão em execução no servidor.	As ferramentas do VMware podem não estar instaladas no servidor ou a versão instalada está corrompida.	Verifique se as ferramentas do VMware instaladas e em execução no servidor são posteriores à versão 10.2.0.
9003: não há suporte para o tipo de sistema operacional em execução no servidor.	O sistema operacional em execução no servidor não é o Windows nem o Linux.	Somente os tipos de sistema operacional Windows e Linux são suportados. Se o servidor estiver realmente executando o sistema operacional Windows ou Linux, verifique o tipo de sistema operacional especificado no vCenter Server.
9004: o servidor não está no estado de execução.	O servidor está no estado desligado.	Verifique se o servidor está em estado de execução.
9005: não há suporte para o tipo de sistema operacional em execução no servidor.	O sistema operacional em execução no servidor não é o Windows nem o Linux.	Somente os tipos de sistema operacional Windows e Linux são suportados. Atualmente, não há suporte para o sistema operacional <FetchedParameter>.
9006: a URL necessária para baixar o arquivo de metadados de descoberta do servidor está vazia.	Esse pode ser um problema transitório causado pelo funcionamento inesperado do agente de descoberta no dispositivo.	O problema deve ser resolvido automaticamente no próximo ciclo dentro de 24 horas. Se o problema persistir, envie um caso de suporte da Microsoft.
9007: o processo que executa o script para coletar os metadados não foi encontrado no servidor.	Esse pode ser um problema transitório causado pelo funcionamento inesperado do agente de descoberta no dispositivo.	O problema deve ser resolvido automaticamente no próximo ciclo dentro de 24 horas. Se o problema persistir, envie um caso de suporte da Microsoft.
9008: não foi possível recuperar o status do processo em execução no servidor para coletar os metadados.	Esse pode ser um problema transitório devido a um erro interno.	O problema deve ser resolvido automaticamente no próximo ciclo dentro de 24 horas. Se o problema persistir, envie um caso de suporte da Microsoft.
9009: o UAC (Controle de Conta de Usuário) do Windows impede a execução de operações de descoberta no servidor.	As configurações do UAC do Windows restringem a descoberta de aplicativos instalados do servidor.	No servidor afetado, diminua o nível das configurações do Controle de Conta de Usuário no Painel de Controle.
9010: o servidor está desligado.	O servidor está no estado desligado.	Verifique se o servidor está no estado ligado.
9011: não foi possível encontrar o arquivo que contém os metadados descobertos no servidor.	Esse pode ser um problema transitório devido a um erro interno.	O problema deve ser resolvido automaticamente no próximo ciclo dentro de 24 horas. Se o problema persistir, envie um caso de suporte da Microsoft.
9012: o arquivo que contém os metadados descobertos no servidor está vazio.	Esse pode ser um problema transitório devido a um erro interno.	O problema deve ser resolvido automaticamente no próximo ciclo dentro de 24 horas. Se o problema persistir, envie um caso de suporte da Microsoft.
9013: um perfil de usuário temporário é criado a cada novo logon no servidor.	Um perfil de usuário temporário é criado a cada novo logon no servidor.	Envie um caso de suporte da Microsoft para ajudar a solucionar o problema.
9014: não foi possível recuperar o arquivo que contém os metadados descobertos devido a um erro no host ESXi. Código de erro: %ErrorCode; detalhes: %ErrorMessage	Um erro foi encontrado no host ESXi <HostName>. Código de erro: %ErrorCode; detalhes: %ErrorMessage.	Verifique se a porta 443 está aberta no host ESXi no qual o servidor está em execução. Saiba mais sobre como corrigir o problema.
9015: a conta de usuário do vCenter Server fornecida para a descoberta de servidor não tem privilégios de operações de convidado habilitados.	Os privilégios de operações de convidado necessários não foram habilitados na conta de usuário do vCenter Server.	Verifique se a conta de usuário do vCenter Server tem privilégios habilitados em Máquinas Virtuais>Operações de Convidado para interagir com o servidor e extrair os dados necessários. Saiba mais sobre como configurar a conta do vCenter Server com os privilégios necessários.
9016: não foi possível descobrir os metadados porque o agente de operações de convidado no servidor está desatualizado.	As ferramentas do VMware não estão instaladas no servidor ou a versão instalada não está atualizada.	Verifique se as ferramentas do VMware estão instaladas e em execução e se estão atualizadas no servidor. A versão das ferramentas do VMware deve ser a versão 10.2.1 ou posterior.
9017: não foi possível encontrar o arquivo que contém os metadados descobertos no servidor.	Esse pode ser um problema transitório devido a um erro interno.	Envie um caso de suporte da Microsoft para ajudar a solucionar o problema.
9018: o PowerShell não está instalado no servidor.	Não foi possível encontrar o PowerShell no servidor.	Verifique se o PowerShell 2.0 ou posterior está instalado no servidor. Saiba mais sobre como corrigir o problema.
9019: não foi possível descobrir os metadados devido a falhas de operação de convidado no servidor.	Falha em operações de convidado do VMware no servidor. O problema foi encontrado ao tentar usar as seguintes credenciais no servidor: <FriendlyNameOfCredentials>.	Verifique se as credenciais do servidor no dispositivo são válidas e se o nome de usuário nas credenciais está no formato de nome UPN. (Encontre o nome amigável das credenciais testadas pelas Migrações para Azure nas causas possíveis).
9020: não foi possível criar o arquivo necessário para conter os metadados descobertos no servidor.	A função associada às credenciais fornecidas no dispositivo ou uma política de grupo local está impedindo a criação do arquivo na pasta necessária. O problema foi encontrado ao tentar usar as seguintes credenciais no servidor: <FriendlyNameOfCredentials>.	1. Verifique se as credenciais fornecidas no dispositivo têm permissão de gravação de arquivo na pasta <caminho da pasta/nome da pasta> no servidor. 2. Se as credenciais fornecidas no dispositivo não tiverem as permissões necessárias, forneça outro conjunto de credenciais ou edite um existente. (Encontre o nome amigável das credenciais testadas pelas Migrações para Azure nas causas possíveis).
9021: não foi possível criar o arquivo necessário para conter os metadados descobertos no caminho correto do servidor.	As ferramentas do VMware estão relatando um caminho de arquivo incorreto para a criação do arquivo.	Verifique se as ferramentas do VMware instaladas e em execução no servidor são posteriores à versão 10.2.0.
9022: o acesso foi negado para executar o cmdlet Get-WmiObject no servidor.	A função associada às credenciais fornecidas no dispositivo ou uma política de grupo local está impedindo o acesso ao objeto WMI. O problema foi encontrado ao tentar usar as seguintes credenciais no servidor: <FriendlyNameOfCredentials>.	1. Verifique se as credenciais fornecidas no dispositivo têm privilégios de administrador de criação de arquivo e se o WMI está habilitado. 2. Se as credenciais fornecidas no dispositivo não tiverem as permissões necessárias, forneça outro conjunto de credenciais ou edite um existente. (Encontre o nome amigável das credenciais testadas pelas Migrações para Azure nas causas possíveis). Saiba mais sobre como corrigir o problema.
9023: não foi possível executar o PowerShell porque o valor da variável de ambiente %SystemRoot% está vazio.	O valor da variável de ambiente %SystemRoot% está vazio para o servidor.	1. Verifique se a variável de ambiente retorna um valor vazio executando o comando de eco %systemroot% no servidor afetado. 2. Se o problema persistir, envie um caso de suporte da Microsoft.
9024: não foi possível realizar a descoberta porque o valor da variável de ambiente %TEMP% está vazio.	O valor da variável de ambiente %TEMP% está vazio para o servidor.	1. Verifique se a variável de ambiente retorna um valor vazio executando o comando de eco %temp% no servidor afetado. 2. Se o problema persistir, envie um caso de suporte da Microsoft.
9025: não foi possível realizar a descoberta porque o PowerShell está corrompido no servidor.	O PowerShell está corrompido no servidor.	Reinstale o PowerShell e verifique se ele está em execução no servidor afetado.
9026: não foi possível executar operações de convidado no servidor.	O estado atual do servidor não permite a execução das operações de convidado.	1. Verifique se o servidor afetado está funcionando. 2. Se o problema persistir, envie um caso de suporte da Microsoft.
9027: não foi possível descobrir os metadados porque o agente de operações de convidado não está em execução no servidor.	Não foi possível entrar em contato com o agente de operações de convidado no servidor.	Verifique se as ferramentas do VMware instaladas e em execução no servidor são posteriores à versão 10.2.0.
9028: não foi possível criar o arquivo necessário para conter os metadados descobertos devido ao armazenamento insuficiente no servidor.	Não há espaço de armazenamento suficiente no disco do servidor.	Verifique se há espaço suficiente disponível no armazenamento em disco do servidor afetado.
9029: as credenciais fornecidas no dispositivo não têm permissões de acesso para executar o PowerShell.	As credenciais no dispositivo não têm permissões de acesso para executar o PowerShell. O problema foi encontrado ao tentar usar as seguintes credenciais no servidor: <FriendlyNameOfCredentials>.	1. Verifique se as credenciais no dispositivo podem acessar o PowerShell no servidor. 2. Se as credenciais no dispositivo não tiverem o acesso necessário, forneça outro conjunto de credenciais ou edite um existente. (Encontre o nome amigável das credenciais testadas pelas Migrações para Azure nas causas possíveis).
9030: não foi possível coletar os metadados descobertos porque o host ESXi no qual o servidor está hospedado está em um estado desconectado.	O host ESXi no qual o servidor reside está em um estado desconectado.	Verifique se o host ESXi que executa o servidor está em um estado conectado.
9031: não foi possível coletar os metadados descobertos porque o host ESXi no qual o servidor está hospedado não está respondendo.	O host ESXi no qual o servidor reside está em um estado inválido.	Verifique se o host ESXi que executa o servidor está em um estado em execução e conectado.
9032: não foi possível realizar a descoberta devido a um erro interno.	O problema encontrado foi gerado por um erro interno.	Siga as etapas deste site para resolver o problema. Caso o problema persista, abra um caso de suporte da Microsoft.
9033: não foi possível realizar a descoberta porque o nome de usuário das credenciais fornecidas no dispositivo para o servidor tem caracteres inválidos.	As credenciais no dispositivo contêm caracteres inválidos no nome de usuário. O problema foi encontrado ao tentar usar as seguintes credenciais no servidor: <FriendlyNameOfCredentials>.	Verifique se as credenciais no dispositivo não têm caracteres inválidos no nome de usuário. É possível voltar ao gerenciador de configuração do dispositivo para editar as credenciais. (Encontre o nome amigável das credenciais testadas pelas Migrações para Azure nas causas possíveis).
9034: não foi possível realizar a descoberta porque o nome de usuário das credenciais fornecidas no dispositivo para o servidor não está no formato UPN.	As credenciais no dispositivo não têm o nome de usuário no formato UPN. O problema foi encontrado ao tentar usar as seguintes credenciais no servidor: <FriendlyNameOfCredentials>.	Verifique se as credenciais no dispositivo têm o nome de usuário no formato UPN. É possível voltar ao gerenciador de configuração do dispositivo para editar as credenciais. (Encontre o nome amigável das credenciais testadas pelas Migrações para Azure nas causas possíveis).
9035: não foi possível realizar a descoberta porque o modo de linguagem do PowerShell não está definido corretamente.	O modo de linguagem do PowerShell não está definido como Linguagem completa.	Verifique se o modo de linguagem do PowerShell está definido como Linguagem completa.
9036: não foi possível realizar a descoberta porque o nome de usuário das credenciais fornecidas no dispositivo para o servidor não está no formato UPN.	As credenciais no dispositivo não têm o nome de usuário no formato UPN. O problema foi encontrado ao tentar usar as seguintes credenciais no servidor: <FriendlyNameOfCredentials>.	Verifique se as credenciais no dispositivo têm o nome de usuário no formato UPN. É possível voltar ao gerenciador de configuração do dispositivo para editar as credenciais. (Encontre o nome amigável das credenciais testadas pelas Migrações para Azure nas causas possíveis).
9037: a coleção de metadados está temporariamente em pausa devido ao alto tempo de resposta do servidor.	O servidor está levando muito tempo para responder.	O problema deve ser resolvido automaticamente no próximo ciclo dentro de 24 horas. Se o problema persistir, envie um caso de suporte da Microsoft.
10000: não há suporte para o tipo de sistema operacional em execução no servidor.	O sistema operacional em execução no servidor não é o Windows nem o Linux.	Somente os tipos de sistema operacional Windows e Linux são suportados. Atualmente, não há suporte para o sistema operacional <GuestOSName>.
10001: o script necessário para coletar metadados de descoberta não foi encontrado no servidor.	O script necessário para realizar a descoberta pode ter sido excluído ou removido da localização esperada.	Envie um caso de suporte da Microsoft para ajudar a solucionar o problema.
10002: as operações de descoberta atingiram o tempo limite no servidor.	Esse pode ser um problema transitório causado pelo funcionamento inesperado do agente de descoberta no dispositivo.	O problema deve ser resolvido automaticamente no próximo ciclo dentro de 24 horas. Se ele não for resolvido, siga as etapas deste site para corrigir o problema. Caso o problema persista, abra um caso de suporte da Microsoft.
10003: o processo de execução das operações de descoberta foi encerrado com um erro.	O processo de execução das operações de descoberta foi encerrado abruptamente devido a um erro.	O problema deve ser resolvido automaticamente no próximo ciclo dentro de 24 horas. Se o problema persistir, envie um caso de suporte da Microsoft.
10004: não foram fornecidas credenciais no dispositivo para o tipo de sistema operacional do servidor.	As credenciais do tipo de sistema operacional do servidor não foram adicionadas ao dispositivo.	1. Adicione as credenciais do tipo de sistema operacional do servidor afetado no dispositivo. 2. Agora é possível adicionar várias credenciais de servidor no dispositivo.
10005: as credenciais fornecidas no dispositivo para o servidor são inválidas.	As credenciais fornecidas no dispositivo não são válidas. O problema foi encontrado ao tentar usar as seguintes credenciais no servidor: <FriendlyNameOfCredentials>.	1. Verifique se as credenciais fornecidas no dispositivo são válidas e se o servidor pode ser acessado por meio delas. 2. Agora é possível adicionar várias credenciais de servidor no dispositivo. 3. Volte ao gerenciador de configuração do dispositivo para fornecer outro conjunto de credenciais ou editar um existente. (Encontre o nome amigável das credenciais testadas pelo Azure Migrate nas possíveis causas.) Saiba mais sobre como corrigir o problema.
10006: não há suporte para o tipo de sistema operacional em execução no servidor.	O sistema operacional em execução no servidor não é o Windows nem o Linux.	Somente os tipos de sistema operacional Windows e Linux são suportados. Atualmente, não há suporte para o sistema operacional <GuestOSName>.
10007: não foi possível processar os metadados descobertos no servidor.	Ocorreu um erro ao analisar o conteúdo do arquivo que contém os metadados descobertos.	Envie um caso de suporte da Microsoft para ajudar a solucionar o problema.
10008: não foi possível criar o arquivo necessário para conter os metadados descobertos no servidor.	A função associada às credenciais fornecidas no dispositivo ou uma política de grupo local está impedindo a criação do arquivo na pasta necessária. O problema foi encontrado ao tentar usar as seguintes credenciais no servidor: <FriendlyNameOfCredentials>.	1. Verifique se as credenciais fornecidas no dispositivo têm permissão de gravação de arquivo na pasta <caminho da pasta/nome da pasta> no servidor. 2. Se as credenciais fornecidas no dispositivo não tiverem as permissões necessárias, forneça outro conjunto de credenciais ou edite um existente. (Encontre o nome amigável das credenciais testadas pelas Migrações para Azure nas causas possíveis).
10009: não foi possível gravar os metadados descobertos em um arquivo no servidor.	A função associada às credenciais fornecidas no dispositivo ou uma política de grupo local está impedindo a gravação no arquivo do servidor. O problema foi encontrado ao tentar usar as seguintes credenciais no servidor: <FriendlyNameOfCredentials>.	1. Verifique se as credenciais fornecidas no dispositivo têm permissão de gravação de arquivo na pasta <caminho da pasta/nome da pasta> no servidor. 2. Se as credenciais fornecidas no dispositivo não tiverem as permissões necessárias, forneça outro conjunto de credenciais ou edite um existente. (Encontre o nome amigável das credenciais testadas pelas Migrações para Azure nas causas possíveis).
10010: não foi possível realizar a descoberta porque o comando %CommandName; necessário para coletar alguns metadados está ausente no servidor.	O pacote que contém o comando %CommandName; não está instalado no servidor.	Verifique se o pacote que contém o comando %CommandName; está instalado no servidor.
10011: as credenciais fornecidas no dispositivo foram usadas para logon e logoff em uma sessão interativa.	O logon e o logoff interativos forçam as chaves do Registro a serem descarregadas no perfil da conta usada. Essa condição torna as chaves indisponíveis para uso futuro.	Use os métodos de resolução documentados neste site.
10012: não foram fornecidas credenciais no dispositivo para o servidor.	Nenhuma credencial foi fornecida para o servidor ou você forneceu credenciais de domínio com um nome de domínio incorreto no dispositivo. Saiba mais sobre a causa desse erro.	1. Verifique se as credenciais foram fornecidas no dispositivo para o servidor e se ele pode ser acessado com as credenciais. 2. Agora é possível adicionar diversas credenciais no dispositivo para servidores. Volte ao gerenciador de configuração de dispositivo para fornecer credenciais para o servidor.

Erro 970: DependencyMapInsufficientPrivilegesException

Causa

O erro geralmente ocorre para servidores Linux quando você não forneceu credenciais com os privilégios necessários no dispositivo.

Remediação

Você tem duas opções:

• Verifique se você forneceu uma conta de usuário raiz.
• Verifique se uma conta tem essas permissões nos arquivos /bin/netstat e /bin/ls:
  • CAP_DAC_READ_SEARCH
  • CAP_SYS_PTRACE

Para verificar se a conta de usuário fornecida no dispositivo tem os privilégios necessários:

1. Faça logon no servidor em que você encontrou esse erro com a mesma conta de usuário mencionada na mensagem de erro.

2. Execute os comandos a seguir no Azure Shell. Você receberá erros se não tiver os privilégios necessários para a análise de dependência sem agente.

   ps -o pid,cmd | grep -v ]$
   netstat -atnp | awk '{print $4,$5,$7}'
   

3. Defina as permissões necessárias nos arquivos /bin/netstat e /bin/ls executando os seguintes comandos:

   sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/ls
   sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/netstat
   

4. Você pode validar se os comandos anteriores atribuíram as permissões necessárias à conta de usuário.

   getcap /usr/bin/ls
   getcap /usr/bin/netstat
   

5. Execute novamente os comandos fornecidos na etapa 2 para obter uma saída bem-sucedida.

Erro 9014: HTTPGetRequestToRetrieveFileFailed

Causa

O problema ocorre quando o agente de descoberta do VMware no dispositivo tenta baixar o arquivo de saída contendo os dados de dependência do sistema de arquivos do servidor por meio do host ESXi no qual o servidor está hospedado.

Remediação

• Teste a conectividade TCP com o host ESXi (nome fornecido na mensagem de erro) na porta 443 (deve estar aberta em hosts ESXi para extrair os dados de dependência) do dispositivo. Abra o PowerShell no servidor do dispositivo e execute o seguinte comando:

  Test -NetConnection -ComputeName <Ip address of the ESXi host> -Port 443
  

• Se o comando retornar uma conectividade bem-sucedida, acesse o projeto de Migrações para Azure>Descoberta e avaliação>Visão geral>Gerenciar>Dispositivos, selecione o nome do dispositivo e escolha Atualizar serviços.

Erro 9018: PowerShellNotFound

Causa

O erro geralmente ocorre em servidores que executam o Windows Server 2008 ou inferior.

Remediação

Instale o Windows PowerShell 5.1 neste local no servidor. Seguindo as instruções em Instalar e configurar o WMF 5.1 sobre como instalar o PowerShell no Windows Server.

Depois de instalar a versão necessária do PowerShell, verifique se o erro foi resolvido seguindo as etapas deste site.

Erro 9022: GetWMIObjectAccessDenied

Remediação

Verifique se a conta de usuário fornecida no dispositivo tem acesso ao namespace e aos subnamespaces do WMI. Para definir o acesso:

1. Acesse o servidor que está relatando o erro.
2. Pesquise e selecione Executar no menu Iniciar. Na caixa de diálogo Executar, insira wmimgmt.msc na caixa de texto Abrir e selecione ENTER.
3. O console do wmimgmt será aberto e nele você encontrará Controle do WMI (Local) no painel esquerdo. Clique nele com o botão direito do mouse e selecione Propriedades no menu.
4. Na caixa de diálogo Propriedades do Controle do WMI (Local), clique na guia Títulos.
5. Na guia Segurança, selecione Segurança para abrir a caixa de diálogo Segurança de RAIZ.
6. Escolha Avançado para abrir a caixa de diálogo Configurações de Segurança Avançada de Raiz.
7. Selecione Adicionar para abrir a caixa de diálogo Entrada de Permissão de Raiz.
8. Clique em Selecionar uma entidade de segurança para abrir a caixa de diálogo Selecionar Usuários, Computadores, Contas de Serviço ou Grupos.
9. Escolha os nomes de usuário ou os grupos aos quais deseja permitir acesso ao WMI e selecione OK.
10. Conceda permissões de execução e selecione Este namespace e subnamespaces na lista suspensa Aplicável a.
11. Selecione Aplicar para salvar as configurações e fechar todas as caixas de diálogo.

Depois de receber o acesso necessário, verifique se o erro foi resolvido seguindo as etapas deste site.

Erro 9032: InvalidRequest

Causa

Pode haver várias razões que causam esse problema. Um dos motivos é quando o nome de usuário fornecido (credenciais do servidor) no gerenciador de configuração do dispositivo tem caracteres XML inválidos. Os caracteres inválidos causam um erro na análise da solicitação SOAP.

Remediação

• Verifique se o nome de usuário das credenciais do servidor não tem caracteres XML inválidos e está no formato username@domain.com. Esse formato é popularmente conhecido como formato UPN.
• Depois de editar as credenciais no dispositivo, verifique se o erro foi resolvido seguindo as etapas deste site.

Erro 10002: ScriptExecutionTimedOutOnVm

Causa

• Esse erro ocorre quando o servidor está lento ou não responde e o script executado para extrair os dados de dependência começa a atingir o tempo limite.
• Depois que o agente de descoberta encontra esse erro no servidor, o dispositivo não tenta realizar a análise de dependência sem agente no servidor para evitar sobrecarregar o servidor que não está respondendo.
• Você continuará vendo o erro até verificar o problema com o servidor e reiniciar o serviço de descoberta.

Remediação

1. Faça logon no servidor que está apresentando esse erro.

2. Execute os seguintes comandos no PowerShell:

   Get-WMIObject win32_operatingsystem;
   Get-WindowsFeature  | Where-Object {$_.InstallState -eq 'Installed' -or ($_.InstallState -eq $null -and $_.Installed -eq 'True')};
   Get-WmiObject Win32_Process;
   netstat -ano -p tcp | select -Skip 4;
   

3. Se os comandos produzirem o resultado em alguns segundos, acesse o projeto de Migrações para Azure>Descoberta e avaliação>Visão geral>Gerenciar>Dispositivos, selecione o nome do dispositivo e escolha Atualizar serviços para reiniciar o serviço de descoberta.

4. Se os comandos atingirem o tempo limite sem fornecer nenhuma saída, você precisará:

   • Descobrir quais processos estão consumindo uma alta taxa de CPU ou de memória no servidor.
   • Tentar fornecer mais núcleos ou memória para esse servidor e executar os comandos novamente.

Erro 10005: GuestCredentialNotValid

Remediação

• Verifique a validade das credenciais (nome amigável fornecido no erro) selecionando Revalidar credenciais no gerenciador de configuração do dispositivo.
• Verifique se é possível fazer logon no servidor afetado com a mesma credencial fornecida no dispositivo.
• Tente usar outra conta de usuário (para o mesmo domínio, caso o servidor esteja conectado ao domínio), em vez da conta de administrador.
• O problema pode ocorrer quando a comunicação entre o Catálogo Global <–> Controlador de Domínio é interrompida. Verifique se esse problema existe criando uma conta de usuário no controlador de domínio e fornecendo-a no dispositivo. Talvez você também precise reiniciar o controlador de domínio.
• Depois de executar as etapas de correção, verifique se o erro foi resolvido seguindo as etapas deste site.

Erro 10012: CredentialNotProvided

Causa

Esse erro ocorre quando você fornece uma credencial de domínio com um nome de domínio incorreto no gerenciador de configuração do dispositivo. Por exemplo, se você tiver fornecido uma credencial de domínio com o nome de usuário user@abc.com, mas forneceu o nome de domínio como def.com, essas credenciais não serão testadas se o servidor estiver conectado a def.com e você receberá essa mensagem de erro.

Remediação

• Acesse o gerenciador de configuração do dispositivo para adicionar uma credencial do servidor ou editar uma existente, conforme explicado na causa.
• Depois de executar as etapas de correção, verifique se o erro foi resolvido seguindo as etapas deste site.

Verificação de mitigação

Depois de usar as etapas de mitigação dos erros anteriores, verifique se a mitigação funcionou executando alguns comandos da PowerCLI no servidor do dispositivo. Se os comandos forem executados com sucesso, significa que o problema foi resolvido. Caso contrário, verifique e siga as etapas de correção novamente.

Para VMs VMware (usando o pipe do VMware)

1. Execute os seguintes comandos para configurar o PowerCLI no servidor do dispositivo:

   Install-Module -Name VMware.PowerCLI -AllowClobber
   Set-PowerCLIConfiguration -InvalidCertificateAction Ignore
   

2. Conecte-se ao vCenter Server no dispositivo fornecendo o endereço IP do vCenter Server no comando e as credenciais no prompt:

   Connect-VIServer -Server <IPAddress of vCenter Server>
   

3. Conecte-se ao servidor de destino no dispositivo fornecendo o nome e as credenciais do servidor, conforme fornecido no dispositivo:

   $vm = get-VM <VMName>
   $credential = Get-Credential
   

4. Para a análise de dependência sem agente, execute os comandos a seguir para tentar obter uma saída bem-sucedida.

   • Para servidores Windows:

     Invoke-VMScript -VM $vm -ScriptText "powershell.exe 'Get-WmiObject Win32_Process'" -GuestCredential $credential
     
     Invoke-VMScript -VM $vm -ScriptText "powershell.exe 'netstat -ano -p tcp'" -GuestCredential $credential
     

   • Para servidores Linux:

     Invoke-VMScript -VM $vm -ScriptText "ps -o pid,cmd | grep -v ]$" -GuestCredential $credential
     
     Invoke-VMScript -VM $vm -ScriptText "netstat -atnp | awk '{print $4,$5,$7}'" -GuestCredential $credential
     

Para VMs Hyper-V e servidores físicos (usando o pipe de conexão direta)

Para servidores Windows:

1. Conecte-se ao servidor Windows executando o comando:

   $Server = New-PSSession –ComputerName <IPAddress of Server> -Credential <user_name>
   

   e insira as credenciais do servidor no prompt.

2. Para a análise de dependência sem agente, execute os comandos a seguir para tentar obter uma saída bem-sucedida:

   Invoke-Command -Session $Server -ScriptBlock {Get-WmiObject Win32_Process}
   Invoke-Command -Session $Server -ScriptBlock {netstat -ano -p tcp}
   

Para servidores Linux:

1. Instalar o cliente OpenSSH

   Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
   

2. Instalar o servidor OpenSSH

   Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
   

3. Iniciar e configurar o OpenSSH Server

   Start-Service sshd
   Set-Service -Name sshd -StartupType 'Automatic'
   

4. Conectar-se ao servidor OpenSSH

   ssh username@servername
   

5. Execute os seguintes comandos para validar a análise de dependência sem agente para ver se você obtém uma saída bem-sucedida:

   ps -o pid,cmd | grep -v ]$
   netstat -atnp | awk '{print $4,$5,$7}'
   

Depois de verificar se a mitigação funcionou, acesse o projeto de Migrações para Azure>Descoberta e avaliação>Visão geral>Gerenciar>Dispositivos, selecione o nome do dispositivo e escolha Atualizar serviços para iniciar um novo ciclo de descoberta.

O workspace do Log Analytics não é listado quando você tenta configurar o workspace nas Migrações para Azure para a análise de dependência baseada em agente

Atualmente, as Migrações para Azure dão suporte à criação do workspace do OMS nas regiões Leste dos EUA, Sudeste da Ásia e Oeste da Europa. Mesmo que o workspace seja criado fora das Migrações para Azure em qualquer outra região, ele não pode estar associado a um projeto no momento.

Visualização de dependência baseada em agente no Azure Governamental

A análise de dependência baseada em agente não é compatível com o Azure Government. Use a análise de dependência sem agente, que está disponível apenas para servidores VMware.

As dependências baseadas em agente não são mostradas após a instalação do agente

Depois que você instala os agentes de visualização de dependência em VMs locais, as Migrações para Azure normalmente levam de 15 a 30 minutos para exibir as dependências no portal. Se você tiver aguardado por mais de 30 minutos, verifique se o MMA (Microsoft Monitoring Agent) pode se conectar ao workspace do Log Analytics.

Para VMs do Windows:

1. No Painel de Controle, inicie o MMA.

2. Em Propriedades do Microsoft Monitoring Agent>Azure Log Analytics (OMS), verifique se o Status do workspace está verde.

3. Se o status não estiver verde, tente remover o workspace e adicioná-lo novamente no MMA.

   

Para VMs do Linux, verifique se os comandos de instalação do MMA e do agente de dependência foram executados com êxito. Veja as diretrizes de solução de problemas neste site.

Sistemas operacionais compatíveis para a análise de dependência baseada em agente

• Agente do MMS: os sistemas operacionais Windows e Linux compatíveis.
• Agente de dependência: os sistemas operacionais Windows e Linux compatíveis.

Visualizar dependências por > uma hora com a análise de dependência baseada em agente

Com a análise de dependência baseada em agente, embora as Migrações para Azure permitam que você volte a uma data específica no último mês, a duração máxima de visualização das dependências é de uma hora. Por exemplo, você pode usar a funcionalidade de duração de tempo no mapa de dependências para exibir as dependências de ontem, mas só pode exibi-las durante o período de uma hora. Use os logs do Azure Monitor para consultar os dados de dependência por um período mais longo.

Visualizar dependências para > dez servidores com a análise de dependência baseada em agente

Nas Migrações para Azure, com a análise de dependência baseada em agente, você pode visualizar dependências para grupos com até 10 VMs. Para grupos maiores, divida as VMs em grupos menores para visualizar as dependências.

Os servidores mostram "Instalar agente" para análise de dependência baseada em agente

Após a migração de servidores com a visualização de dependência habilitada para o Azure, os servidores podem mostrar a ação Instalar agente em vez de Exibir dependências devido ao seguinte comportamento:

• Após a migração para o Azure, os servidores locais são desativados e as VMs equivalentes são ativadas no Azure. Esses servidores adquirem um endereço MAC diferente.
• Os servidores também podem ter um endereço IP diferente, dependendo se você manteve o endereço IP local ou não.
• Se os endereços MAC e IP forem diferentes do local, a ferramenta Migrações para Azure não associará os servidores locais a nenhum dado de dependência do Mapa de Serviço. Nesse caso, ele mostra a opção para instalar o agente em vez de exibir as dependências.
• Após a migração de um teste para o Azure, os servidores locais permanecem ligados conforme o esperado. Os servidores equivalentes criados no Azure adquirem um endereço MAC diferente e podem adquirir endereços IP diferentes. A menos que você bloqueie o tráfego de log do Azure Monitor de saída desses servidores, as Migrações para Azure não associarão os servidores locais a nenhum dado de dependência do Mapa do Serviço. Nesse caso, ele mostra a opção para instalar os agentes em vez de exibir as dependências.

Capturar o tráfego de rede

Para coletar os logs de tráfego de rede:

1. Entre no portal do Azure.
2. Selecione F12 para iniciar as Ferramentas para Desenvolvedores. Se necessário, desmarque a configuração Limpar entradas na navegação.
3. Selecione a guia Rede e comece a capturar o tráfego de rede:
   • No Chrome, selecione Preservar log. A gravação deve ser iniciada automaticamente. Um círculo vermelho indica que o tráfego está sendo capturado. Se o círculo vermelho não aparecer, selecione o círculo preto para iniciar.
   • No Microsoft Edge e no Internet Explorer, a gravação será iniciada automaticamente. Se isso não acontecer, clique no botão verde para executar.
4. Tente reproduzir o erro.
5. Depois de encontrar o erro durante a gravação, pare a gravação e salve uma cópia da atividade gravada:
   • No Chrome, clique com o botão direito do mouse e selecione Salvar como HAR com conteúdo. Essa ação compacta e exporta os logs como um arquivo Arquivamento HTTP (har).
   • No Microsoft Edge ou Internet Explorer, selecione a opção Exportar tráfego capturado. Essa ação compacta e exporta o log.
6. Selecione a guia Console para verificar se há avisos ou erros. Para salvar o log do console:
   • No Chrome, clique com o botão direito em qualquer lugar no log do console. Selecione Salvar como para exportar e compactar o log.
   • No Microsoft Edge ou no Internet Explorer, clique com o botão direito do mouse nos erros e selecione Copiar tudo.
7. Fechar as Ferramentas para Desenvolvedores.

Próximas etapas

Crie ou personalize uma avaliação.