Partilhar via

Resolver Problemas da instalação push do Serviço de mobilidade

  • Artigo

A instalação do Serviço de mobilidade é um passo importante para ativar a replicação. O sucesso deste passo depende do cumprimento dos pré-requisitos e de se trabalhar com configurações suportadas. As falhas mais comuns que você pode enfrentar durante a instalação do serviço de mobilidade são devidas a:

Quando você habilita a replicação, o Azure Site Recovery tenta instalar o agente de serviço de mobilidade em sua máquina virtual (VM). Como parte desse processo, o servidor de configuração tenta se conectar com a máquina virtual e copiar o agente. Para habilitar a instalação bem-sucedida, siga as diretrizes de solução de problemas passo a passo.

Verificação de credenciais (ErrorID: 95107 & 95108)

Verifique se a conta de usuário escolhida durante a habilitação da replicação é válida e precisa. O Azure Site Recovery requer a conta raiz ou a conta de usuário com privilégios de administrador para executar uma instalação por push. Caso contrário, a instalação por push será bloqueada na máquina de origem.

Para Windows (erro 95107), verifique se a conta de usuário tem acesso administrativo no computador de origem, com uma conta local ou de domínio. Se você não estiver usando uma conta de domínio, precisará desabilitar o controle de Acesso de Usuário Remoto no computador local.

  • Para adicionar manualmente uma chave do Registro que desabilita o controle de Acesso de Usuário Remoto:

    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
    • Adicionar um novo DWORD: LocalAccountTokenFilterPolicy
    • Defina o valor como 1

  • Para adicionar a chave do Registro, em um prompt de comando, execute o seguinte comando:

    REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1

Para Linux (erro 95108), você deve escolher a conta raiz para a instalação bem-sucedida do agente de serviço de mobilidade. Além disso, os serviços SSH File Transfer Protocol (SFTP) devem estar em execução. Para habilitar o subsistema SFTP e a autenticação de senha no arquivo sshd_config :

  1. Inicie sessão como raiz.
  2. Vá para o arquivo /etc/ssh/sshd_config, encontre a linha que começa com PasswordAuthentication.
  3. Descomente a linha e altere o valor para yes.
  4. Localize a linha que começa com Subsysteme descomente a linha.
  5. Reinicie o sshd serviço.

Se desejar modificar as credenciais da conta de utilizador escolhida, siga estas instruções.

Falha de privilégios insuficientes (ErrorID: 95517)

Quando o usuário escolhido para instalar o Mobility agent não tiver privilégios de administrador, o servidor de configuração/servidor de processo de expansão não terá permissão para copiar o software do Mobility agent para a máquina de origem. Este erro é resultado de uma falha de acesso negado. Verifique se a conta de usuário tem privilégios de administrador.

Se desejar modificar as credenciais da conta de utilizador escolhida, siga estas instruções.

Falha de privilégios insuficientes (ErrorID: 95518)

Quando o estabelecimento da relação de confiança de domínio entre o domínio primário e a estação de trabalho falha ao tentar entrar na máquina de origem, a instalação do Mobility agent falha com a ID de erro 95518. Verifique se a conta de usuário usada para instalar o agente de mobilidade tem privilégios administrativos para entrar através do domínio primário da máquina de origem.

Se desejar modificar as credenciais da conta de utilizador escolhida, siga estas instruções.

Falhas de login (ErrorID: 95519, 95520, 95521, 95522)

Esta seção descreve as mensagens de erro de credencial e login.

As credenciais da conta de usuário foram desabilitadas (ErrorID: 95519)

A conta de usuário escolhida durante a habilitação da replicação foi desabilitada. Para habilitar a conta de usuário, consulte este artigo ou execute o seguinte comando substituindo o nome de usuário de texto pelo nome de usuário real.

net user 'username' /active:yes

Credenciais bloqueadas devido a várias tentativas de login com falha (ErrorID: 95520)

Vários esforços de repetição com falha para acessar uma máquina bloquearão a conta do usuário. A falha pode ser devida a:

  • As credenciais fornecidas durante a configuração estão incorretas.
  • A conta de usuário escolhida durante a habilitação da replicação está errada.

Modifique as credenciais escolhidas seguindo estas instruções e tente novamente a operação.

Os servidores de logon não estão disponíveis na máquina de origem (ID de erro: 95521)

Este erro ocorre quando os servidores de logon não estão disponíveis na máquina de origem. Se os servidores de logon não estiverem disponíveis, as solicitações de login falharão e o agente de mobilidade não poderá ser instalado. Para um logon bem-sucedido, verifique se os servidores de logon estão disponíveis na máquina de origem e inicie o serviço Netlogon. Para obter mais informações, consulte Cenários de logon do Windows.

O serviço de logon não está em execução na máquina de origem (ID de erro: 95522)

O serviço de login não está em execução na sua máquina de origem e causou falha na solicitação de login. O agente de mobilidade não pode ser instalado. Para resolver o erro, use um dos seguintes métodos para iniciar o Netlogon serviço na máquina de origem:

  • Para iniciar o Netlogon serviço a partir de um prompt de comando, execute o comando net start Netlogon.
  • No Gestor de Tarefas, inicie o Netlogon serviço.

Falha de conectividade (ErrorID: 95117 & 97118)

O servidor de configuração/servidor de processo de expansão tenta se conectar à VM de origem para instalar o agente de mobilidade. Este erro ocorre quando a máquina de origem não está acessível porque há problemas de conectividade de rede.

Para resolver o erro:

  • Verifique se a conta de usuário tem acesso administrativo no computador de origem, com uma conta local ou de domínio. Se você não estiver usando uma conta de domínio, precisará desabilitar o controle de Acesso de Usuário Remoto no computador local.

    • Para adicionar manualmente uma chave do Registro que desabilita o controle de Acesso de Usuário Remoto:

      • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
      • Adicionar um novo DWORD: LocalAccountTokenFilterPolicy
      • Defina o valor como 1

    • Para adicionar a chave do Registro, em um prompt de comando, execute o seguinte comando:

      REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1

  • Certifique-se de que você pode executar ping em sua máquina de origem a partir do servidor de configuração. Se você tiver escolhido o servidor de processo de expansão durante a habilitação da replicação, certifique-se de que pode executar ping em sua máquina de origem a partir do servidor de processo.

  • Certifique-se de que o serviço de partilha de ficheiros e impressoras está ativado na sua máquina virtual. Veja os passos aqui.

  • Verifique se o serviço WMI está habilitado em sua máquina virtual. Veja os passos aqui.

  • Certifique-se de que as pastas compartilhadas de rede em sua máquina virtual estejam acessíveis a partir do servidor de processo. Veja os passos aqui.

  • A partir do servidor de configuração ou da linha de comando do servidor de processo de expansão, use Telnet para executar ping na VM de origem na porta 135, conforme mostrado no comando a seguir. Este comando verifica se há problemas de conectividade de rede ou problemas de bloqueio de porta de firewall.

    telnet <Source IP address> <135>

  • Além disso, para uma VM Linux:

    • Verifique se os pacotes OpenSSH, OpenSSH Server e OpenSSL mais recentes estão instalados.

    • Verifique e verifique se o Secure Shell (SSH) está ativado e em execução na porta 22.

    • Os serviços SFTP devem estar em execução. Para habilitar o subsistema SFTP e a autenticação de senha no arquivo sshd_config :

      1. Inicie sessão como raiz.
      2. Vá para o arquivo /etc/ssh/sshd_config , encontre a linha que começa com PasswordAuthentication.
      3. Descomente a linha e altere o valor para yes.
      4. Localize a linha que começa com Subsysteme descomente a linha
      5. Reinicie o sshd serviço.

  • Uma tentativa de conexão pode ter falhado se não houver respostas adequadas após um período de tempo, ou uma conexão estabelecida falhou porque um host conectado não respondeu.

  • Pode ser um problema relacionado à conectividade/rede/domínio. Também pode ser porque o problema de resolução de nome DNS ou o problema de exaustão da porta TCP. Verifique se existem problemas conhecidos no seu domínio.

Falha de conectividade (ErrorID: 95523)

Este erro ocorre quando a rede em que reside a máquina de origem não foi encontrada, pode ter sido excluída ou não está mais disponível. A única maneira de resolver o erro é garantir que a rede existe.

Verificar o acesso para pastas compartilhadas de rede na máquina de origem (ID de erro: 95105,95523)

Verifique se as pastas compartilhadas de rede em sua máquina virtual estão acessíveis a partir do Process Server (PS) remotamente usando credenciais especificadas. Para confirmar o acesso:

  1. Faça login na máquina do Process Server.

  2. Abra o Explorador de Ficheiros. Na barra de endereço, digite \\<SOURCE-MACHINE-IP>\C$ e clique em Enter.

    Abrir pasta no PS

  3. O explorador de arquivos solicitará credenciais. Introduza o nome de utilizador e a palavra-passe e clique em OK.

    Fornecer credenciais

    Nota

    Se a máquina de origem estiver associada ao domínio, forneça o nome de domínio juntamente com o nome de usuário como <domainName>\<username>. Se a máquina de origem estiver no grupo de trabalho, forneça apenas o nome de usuário.

  4. Se a conexão for bem-sucedida, as pastas da máquina de origem ficarão visíveis remotamente a partir do Process Server.

    Pastas visíveis da máquina de origem

Se a conexão não for bem-sucedida, verifique se todos os pré-requisitos foram atendidos.

Verificação de serviços de compartilhamento de arquivos e impressoras (ErrorID: 95105 & 95106)

Após uma verificação de conectividade, verifique se o serviço de compartilhamento de arquivos e impressoras está habilitado em sua máquina virtual. Essas configurações são necessárias para copiar o agente de mobilidade para a máquina de origem.

Para Windows 2008 R2 e versões anteriores:

  • Para ativar a partilha de ficheiros e impressão através da Firewall do Windows,

    1. Abra o Sistema do Painel de Controle>e Segurança>do Firewall do Windows. No painel esquerdo, selecione Configurações>avançadas Regras de entrada na árvore de console.
    2. Localize as regras Partilha de ficheiros e impressoras (NB-Session-In) e Partilha de ficheiros e impressoras (SMB-In).
    3. Para cada regra, clique com o botão direito do rato na regra e, em seguida, clique em Ativar Regra.

  • Para habilitar o compartilhamento de arquivos com a Diretiva de Grupo:

    1. Vá para Iniciar, digite gpmc.msc e pesquise.

    2. No painel de navegação, abra as seguintes pastas: Política do>Computador Local Configuração>do Usuário Modelos Administrativos Componentes>do Windows Compartilhamento>de Rede.

    3. No painel de detalhes, clique duas vezes em Impedir que os usuários compartilhem arquivos em seus perfis.

      Para desativar a configuração de Diretiva de Grupo e habilitar a capacidade do usuário de compartilhar arquivos, selecione Desabilitado.

    4. Selecione OK para salvar as alterações.

    Para saber mais, consulte Habilitar ou desabilitar o compartilhamento de arquivos com a Diretiva de Grupo.

Para habilitar o compartilhamento de arquivos e impressoras para versões posteriores do Windows ou Linux, siga as instruções em Instalar o serviço de mobilidade para recuperação de desastres de VMs VMware e servidores físicos.

Verificação de configuração do WMI (Instrumentação de Gerenciamento do Windows) (Código de erro: 95103)

Após a verificação dos serviços de arquivo e impressora, habilite o serviço WMI para perfis privados, públicos e de domínio através do firewall. Essas configurações são necessárias para concluir a execução remota na máquina de origem.

Para habilitar o WMI:

  1. Vá para Segurança do Painel de Controle>e selecione Firewall do Windows.
  2. Selecione Alterar configurações e, em seguida, selecione a guia Exceções .
  3. Na janela Exceções, marque a caixa de seleção WMI (Instrumentação de Gerenciamento do Windows) para habilitar o tráfego WMI através do firewall.

Você também pode habilitar o tráfego WMI através do firewall no prompt de comando com o seguinte comando:

netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes

Outros artigos de solução de problemas do WMI podem ser encontrados nos seguintes artigos.

Sistemas operativos não suportados

Outra razão comum para a falha pode ser devido a um sistema operacional não suportado. Use um sistema operacional suportado e uma versão do kernel para uma instalação bem-sucedida do serviço de mobilidade. Evite o uso de adesivos privados.

Para exibir a lista de sistemas operacionais e versões do kernel suportados pelo Azure Site Recovery, consulte o documento da matriz de suporte.

Configurações de disco de inicialização não suportadas (ErrorID: 95309, 95310, 95311)

As partições/volumes de inicialização e do sistema não são o mesmo disco (ErrorID: 95309)

Antes da versão 9.20, as partições/volumes de inicialização e do sistema em discos diferentes eram uma configuração não suportada. A partir da versão 9.20, esta configuração é suportada.

O disco de inicialização não está disponível (ErrorID: 95310)

Uma máquina virtual sem um disco de inicialização não pode ser protegida. Um disco de inicialização garante uma recuperação suave de uma máquina virtual durante uma operação de failover. A ausência de um disco de inicialização resulta em uma falha na inicialização da máquina após o failover. Verifique se a máquina virtual contém um disco de inicialização e tente novamente a operação. Além disso, não há suporte para vários discos de inicialização na mesma máquina.

Vários discos de inicialização presentes na máquina de origem (ErrorID: 95311)

Uma máquina virtual com vários discos de inicialização não é uma configuração suportada.

Partição do sistema em vários discos (ErrorID: 95313)

Antes da versão 9.20, uma partição raiz ou configuração de volume em vários discos era uma configuração não suportada. A partir da versão 9.20, esta configuração é suportada.

Falha ao ativar a proteção como nome do dispositivo mencionado na configuração do GRUB em vez de UUID (ErrorID: 95320)

Causa possível

Os arquivos de configuração do Grand Unified Bootloader (GRUB) (/boot/grub/menu.lst, /boot/grub/grub.cfg, /boot/grub2/grub.cfg ou /etc/default/grub) podem conter o valor para a raiz dos parâmetros e retomar como os nomes reais do dispositivo em vez de um identificador universalmente exclusivo (UUID). A Recuperação de Site exige a abordagem UUID, pois os nomes dos dispositivos podem mudar durante a reinicialização da VM. Por exemplo, a VM pode não ficar online com o mesmo nome no failover e isso resulta em problemas.

Por exemplo:

  • A seguinte linha é do arquivo GRUB /boot/grub2/grub.cfg:

    linux /boot/vmlinuz-3.12.49-11-default root=/dev/sda2 ${extra_cmdline} resume=/dev/sda1 splash=silent quiet showopts

  • A seguinte linha é do arquivo GRUB /boot/grub/menu.lst:

    kernel /boot/vmlinuz-3.0.101-63-default root=/dev/sda2 resume=/dev/sda1 splash=silent crashkernel=256M-:128M showopts vga=0x314

Nota

As linhas GRUB contêm nomes de dispositivos reais para os parâmetros raiz e retomar em vez do UUID.

Como corrigir

Os nomes dos dispositivos devem ser substituídos pelo UUID correspondente.

  1. Encontre o UUID do dispositivo executando o comando blkid \<device name>.

    Por exemplo:

    blkid /dev/sda1
/dev/sda1: UUID="6f614b44-433b-431b-9ca1-4dd2f6f74f6b" TYPE="swap"
blkid /dev/sda2
/dev/sda2: UUID="62927e85-f7ba-40bc-9993-cc1feeb191e4" TYPE="ext3"

  2. Agora substitua o nome do dispositivo por seu UUID no formato como root=UUID=\<UUID>. Por exemplo, se substituirmos os nomes dos dispositivos por UUID para o parâmetro root e resume mencionado nos arquivos /boot/grub2/grub.cfg, /boot/grub2/grub.cfg ou /etc/default/grub, as linhas nos arquivos se parecem com a seguinte linha:

    kernel /boot/vmlinuz-3.0.101-63-default root=UUID=62927e85-f7ba-40bc-9993-cc1feeb191e4 resume=UUID=6f614b44-433b-431b-9ca1-4dd2f6f74f6b splash=silent crashkernel=256M-:128M showopts vga=0x314

  3. Reinicie a proteção.

Instalar o serviço Mobility concluído com aviso para reiniciar (ErrorID: 95265 & 95266)

O serviço de Mobilidade de Recuperação de Site tem muitos componentes, um dos quais é chamado de driver de filtro. O driver de filtro é carregado na memória do sistema somente durante uma reinicialização do sistema. As correções do driver de filtro só podem ser realizadas quando um novo driver de filtro é carregado no momento da reinicialização do sistema.

Importante

Este é um aviso e a replicação existente funcionará mesmo após a atualização do novo agente. Você pode optar por reiniciar sempre que quiser obter os benefícios do novo driver de filtro, mas se você não reiniciar, o driver de filtro antigo continua funcionando. Assim, após uma atualização sem uma reinicialização, exceto para o driver de filtro, os benefícios de outros aprimoramentos e correções no serviço de mobilidade são realizados. Embora recomendado, não é obrigatório reiniciar após cada atualização. Para obter informações sobre quando uma reinicialização é obrigatória, defina a seção Reinicializar após atualização do serviço de mobilidade em Atualizações de serviço no Azure Site Recovery.

Gorjeta

Para obter as práticas recomendadas sobre como agendar atualizações durante a janela de manutenção, consulte Suporte para o sistema operacional/kernel mais recente em Atualizações de serviço no Azure Site Recovery.

Suporte LVM a partir da versão 9.20

Antes da versão 9.20, o LVM (Logical Volume Manager) era suportado apenas para discos de dados. A /boot partição deve estar em uma partição de disco e não em um volume LVM.

A partir da versão 9.20, o disco do SO no LVM é suportado.

Espaço insuficiente (ErrorID: 95524)

Quando o Mobility agent é copiado para a máquina de origem, pelo menos 100 MB de espaço livre são necessários. Certifique-se de que sua máquina de origem tenha a quantidade necessária de espaço livre e tente novamente a operação.

Recursos do sistema insuficientes

Os possíveis IDs de erro vistos para esse problema são 95572 e 95573. Esse problema ocorre quando o sistema tem pouca memória disponível e não é capaz de alocar memória para a instalação do serviço de mobilidade. Certifique-se de que foi libertada memória suficiente para que a instalação prossiga e seja concluída com êxito.

Falhas de instalação do VSS

A instalação do VSS (Serviço de Cópias de Sombra de Volume) faz parte da instalação do Mobility Agent. Esse serviço é usado no processo para gerar pontos de recuperação consistentes do aplicativo. Falhas durante a instalação do VSS podem ocorrer devido a vários motivos. Para identificar os erros exatos, consulte C:\ProgramData\ASRSetupLogs\ASRUnifiedAgentInstaller.log. Alguns dos erros comuns e as etapas de resolução são destacados na seção a seguir.

Erro VSS -2147023170 [0x800706BE] - código de saída 511

Esse problema é visto com mais frequência quando o software antivírus está bloqueando as operações dos serviços do Azure Site Recovery.

Para resolver este problema:

  1. Reveja a lista de exclusões de pastas do programa antivírus.
  2. Siga as diretrizes publicadas pelo seu provedor de antivírus para desbloquear o registro de DLL no Windows.

Erro VSS 7 [0x7] - código de saída 511

Este erro é um erro de tempo de execução que é causado porque não há memória suficiente para instalar o VSS. Aumente o espaço em disco para a conclusão bem-sucedida desta operação.

Erro VSS -2147023824 [0x80070430] - código de saída 517

Este erro ocorre quando o serviço Provedor VSS do Azure Site Recovery está marcado para exclusão. Tente instalar o VSS manualmente na máquina de origem executando o seguinte comando:

"C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Install.cmd"

VSS error -2147023841 [0x8007041F] - código de saída 512

Este erro ocorre quando o banco de dados do serviço Provedor VSS do Azure Site Recovery está bloqueado. Tente instalar o VSS manualmente na máquina de origem executando o seguinte comando em um prompt de comando:

"C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Install.cmd"

Quando houver uma falha, verifique se algum programa antivírus ou outros serviços estão presos em um estado inicial . Um processo em um estado inicial pode manter o bloqueio nos serviços de banco de dados. Isso levará a falhas na instalação do provedor VSS. Certifique-se de que nenhum serviço está em um estado inicial e, em seguida, tente novamente a operação acima.

Código de saída VSS 806

Este erro ocorre quando a conta de utilizador utilizada para a instalação não tem permissões para executar o CSScript comando. Forneça as permissões necessárias à conta de usuário para executar o script e repetir a operação.

Outros erros VSS

Tente instalar o serviço do provedor VSS manualmente na máquina de origem executando o seguinte comando em um prompt de comando:

"C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Install.cmd"

Erro VSS - 0x8004E00F

Esse erro normalmente ocorre durante a instalação do agente de mobilidade devido a problemas em DCOM e DCOM está em um estado crítico.

Use o procedimento a seguir para determinar a causa do erro.

Examine os logs de instalação

  1. Abra o log de instalação localizado em C:\ProgramData\ASRSetupLogs\ASRUnifiedAgentInstaller.log.

  2. A presença do seguinte erro indica esse problema:

    Unregistering the existing application...
Create the catalogue object
Get the collection of Applications

ERROR:

- Error code: -2147164145 [0x8004E00F]
- Exit code: 802

Para resolver o problema:

Entre em contato com a equipe da plataforma Microsoft Windows para obter assistência com a resolução do problema DCOM.

Quando o problema DCOM for resolvido, reinstale o Provedor VSS do Azure Site Recovery manualmente usando o seguinte comando em um prompt de comando:

"C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Install.cmd"

Se a consistência do aplicativo não for crítica para seus requisitos de recuperação de desastres, você poderá ignorar a instalação do VSS Provider.

Para ignorar a instalação do Provedor VSS do Azure Site Recovery e instalar manualmente o Provedor VSS do Azure Site Recovery após a instalação:

  1. Instale o serviço de mobilidade. A instalação falhará na etapa: Configuração pós-instalação.

  2. Para ignorar a instalação do VSS:

    1. Abra o diretório de instalação do Serviço de Mobilidade do Azure Site Recovery localizado em:

      C:\Arquivos de Programas (x86)\Microsoft Azure Site Recovery\agent

    2. Modifique os scripts de instalação do Provedor VSS do Azure Site Recovery InMageVSSProvider_Install e InMageVSSProvider_Uninstall.cmd para sempre ter êxito adicionando as seguintes linhas:

      rem @echo off
setlocal
exit /B 0

  3. Faça uma instalação manual do Mobility Agent.

  4. Quando a instalação for bem-sucedida e passar para a próxima etapa, Configurar, remova as linhas adicionadas.

  5. Para instalar o provedor VSS, abra um prompt de comando como administrador e execute o seguinte comando:

    "C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Install.cmd"

  6. Verifique se o Provedor VSS do Azure Site Recovery está instalado como um serviço nos Serviços do Windows. Abra o MMC do Serviço de Componentes para confirmar se o Provedor VSS está listado.

  7. Se a instalação do VSS Provider continuar a falhar, trabalhe com suporte técnico para resolver os erros de permissões na Cryptographic Application Programming Interface (CAPI2).

A instalação do Provedor VSS falha porque o serviço de cluster está sendo habilitado em uma máquina que não é de cluster

Esse problema faz com que a instalação do Agente de Mobilidade do Azure Site Recovery falhe durante a instalação do Provedor VSS do Azure Site Recovery. A falha ocorre porque há um problema que COM+ impede a instalação do provedor VSS.

Para identificar o problema

No log localizado no servidor de configuração em C:\ProgramData\ASRSetupLogs\UploadedLogs<date-time>UA_InstallLogFile.log você encontrará a seguinte exceção:

COM+ was unable to talk to the Microsoft Distributed Transaction Coordinator (Exception from HRESULT: 0x8004E00F)

Para resolver o problema:

  1. Verifique se essa máquina não é de cluster e se os componentes do cluster não estão sendo usados.
  2. Se os componentes não estiverem sendo usados, remova os componentes do cluster da máquina.

Drivers estão faltando no servidor de origem

Se a instalação do Mobility Agent falhar, examine os logs em C:\ProgramData\ASRSetupLogs para determinar se alguns dos drivers necessários estão faltando em alguns conjuntos de controle.

Para resolver o problema:

  1. Usando um editor do Registro, como regedit.msco , abra o Registro.

  2. Abra o HKEY_LOCAL_MACHINE\SYSTEM nó.

  3. No nó, localize os SYSTEM conjuntos de controle.

  4. Abra cada conjunto de controle e verifique se os seguintes drivers do Windows estão presentes:

    • Atapi
    • Vmbus
    • Storflt
    • Storvsc
    • Intelide

  5. Reinstale todos os drivers ausentes.

Próximos passos

Saiba mais sobre como configurar a recuperação de desastres para VMs VMware.