Compartilhar via

Solucionar problemas comuns do Agente da Área de Trabalho Virtual do Azure

  • Artigo

O Agente da Área de Trabalho Virtual do Azure pode causar problemas de conexão devido a vários fatores:

  • Um erro no broker que faz o agente parar o serviço.
  • Problemas com atualizações.
  • Problemas com a instalação durante a instalação do agente, o que interrompe a conexão com o host da sessão.

Este artigo guia você através de soluções para esses cenários comuns e como resolver problemas de conexão.

Observação

Para solucionar problemas relacionados à conectividade de uma sessão e ao agente da Área de Trabalho Virtual do Azure, recomendamos que você revise os logs de eventos em suas máquinas virtuais (VMs) de host de sessão Visualizador de Eventos>Logs do Windows>Aplicativo. Procure eventos que tenham uma das seguintes origens para identificar seu problema:

  • WVD-Agent
  • WVD-Agent-Updater
  • RDAgentBootLoader
  • MsiInstaller

Erro: o carregador do agente RDAgentBootLoader e/ou da Área de Trabalho Remota parou de funcionar

Se você vir algum dos seguintes problemas, isso significa que o carregador de inicialização, que carrega o agente, não conseguiu instalar o agente corretamente e o serviço do agente não está em execução na VM do host da sessão:

  • O RDAgentBootLoader foi interrompido ou não está em execução.
  • Não há um status para o carregador do agente da Área de Trabalho Remota.

Para resolver esse problema, inicie o carregador de inicialização RDAgent:

  1. Na janela Serviços, clique com o botão direito do mouse em Carregador do Agente da Área de Trabalho Remota.
  2. Selecione Iniciar. Se essa opção estiver esmaecida, você não tem permissões de administrador. Você precisa obter essas permissões para iniciar o serviço.
  3. Aguarde 10 segundos e clique com o botão direito do mouse em Carregador do Agente da Área de Trabalho Remota.
  4. Selecione Atualizar.
  5. Se o serviço parar depois de iniciá-lo e atualizá-lo, você poderá ter uma falha de registro. Para obter mais informações, consulte INVALID_REGISTRATION_TOKEN ou EXPIRED_MACHINE_TOKEN.

Erro: INVALID_REGISTRATION_TOKEN ou EXPIRED_MACHINE_TOKEN

Na VM do host da sessão, vá para Aplicativo de Logs do >Windows do >Visualizador de Eventos. Se você vir um evento com o ID 3277 com a descrição INVALID_REGISTRATION_TOKEN ou EXPIRED_MACHINE_TOKEN, a chave de registro utilizada não é reconhecida como válida.

Para resolver o problema:

  1. Crie uma nova chave de registro seguindo as etapas em Como gerar uma chave de registro.

  2. Abra um prompt do PowerShell como administrador e execute os cmdlets a seguir para adicionar a nova chave de registro ao registro. Substitua <RegistrationToken> pelo novo token de registro gerado.

    $newKey = '<RegistrationToken>'

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\RDInfraAgent" -Name "IsRegistered" -Value 0 -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\RDInfraAgent" -Name "RegistrationToken" -Value $newKey -Force

  3. Execute o seguinte cmdlet para reiniciar o serviço RDAgentBootLoader :

    Restart-Service RDAgentBootLoader

  4. Execute os cmdlets a seguir para verificar se IsRegistered está definido como 1 e RegistrationToken está em branco.

    Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\RDInfraAgent" -Name IsRegistered | FL IsRegistered
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\RDInfraAgent" -Name RegistrationToken | FL RegistrationToken

    A saída deve ser semelhante à seguinte saída:

    IsRegistered : 1

RegistrationToken :

  5. Verifique se o host da sessão está disponível no pool de hosts. Se não estiver, analise as entradas do Visualizador de Eventos e confira se há erros que estão impedindo o agente de iniciar.

Erro: o agente não consegue se conectar ao broker com INVALID_FORM

Na VM do host da sessão, vá para Aplicativo de Logs do >Windows do >Visualizador de Eventos. Se você vir um evento com ID 3277 na INVALID_FORM descrição, o agente não poderá se conectar ao agente ou acessar um ponto de extremidade específico. Esse problema pode ser causado por determinadas configurações de firewall ou DNS.

Para resolver esse problema, verifique se você pode acessar os dois pontos de extremidade chamados de BrokerResourceIdURI e BrokerResourceIdURIGlobal:

  1. Abra o Editor do Registro.

  2. Ir para HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RDInfraAgent.

  3. Anote os valores para BrokerResourceIdURI e BrokerResourceIdURIGlobal.

  4. Abra um navegador da Web, insira seu valor for BrokerResourceIdURI na barra de endereços e adicione /api/health ao final, por exemplo, https://rdbroker-g-us-r0.wvd.microsoft.com/api/health.

  5. Abra outra guia no navegador, insira seu valor para BrokerResourceIdURIGlobal na barra de endereço e adicione /api/health ao final, por exemplo, https://rdbroker.wvd.microsoft.com/api/health.

  6. Se sua rede não estiver bloqueando a conexão com o corretor, ambas as páginas deverão ser carregadas com êxito e mostrar uma mensagem informando que o Agente da Área de Trabalho Remota está Íntegro, conforme mostrado nas capturas de tela a seguir:

    Captura de tela do acesso ao uri do agente carregado com êxito.

    Captura de tela do acesso ao uri global do agente carregado com êxito.

  7. Se a rede estiver bloqueando a conexão do agente, as páginas não serão carregadas, conforme mostrado na captura de tela a seguir.

    Captura de tela do acesso malsucedido do agente carregado.

    Captura de tela do acesso global do agente carregado malsucedido.

    Você deve desbloquear os pontos de extremidade necessários e repetir as etapas 4 a 7. Para obter mais informações, consulte Lista de URL Necessárias.

  8. Se seguir as etapas anteriores não resolver o problema, verifique se você não tem nenhuma política de grupo com criptografias que bloqueiem o agente para a conexão do agente. A Área de Trabalho Virtual do Azure usa as mesmas criptografias TLS 1.2 que o Azure Front Door. Para saber mais, confira Segurança de conexão.

Erro: 3703

Na VM do host da sessão, vá para Aplicativo de Logs do >Windows do >Visualizador de Eventos. Se você vir um evento com ID 3703 na RD Gateway Url: is not accessible descrição, o agente não poderá acessar as URLs do gateway. Para se conectar com sucesso ao seu host de sessão, você deve permitir o tráfego de rede para os URLs da Lista de URLs obrigatórios. Além disso, verifique se suas configurações do firewall ou do proxy não bloqueiam essas URLs. É necessário desbloquear essas URLs para usar a Área de Trabalho Virtual do Azure.

Para resolver esse problema, verifique se você pode acessar as URLs necessárias executando a ferramenta Verificação de URL Necessária. Se você estiver usando o Firewall do Azure, consulte Usar o Firewall do Azure para proteger implantações da Área de Trabalho Virtual do Azure e as configurações de DNS do Firewall do Azure para obter mais informações sobre como configurá-lo para a Área de Trabalho Virtual do Azure.

Erro: 3019

Na VM do host da sessão, vá para Aplicativo de Logs do >Windows do >Visualizador de Eventos. Se você vir um evento com a ID 3019, o agente não poderá acessar as URLs de transporte do soquete da Web. Para se conectar com êxito ao host da sessão e permitir que o tráfego de rede ignore as restrições, você deve desbloquear as URLs na Lista de URLs necessárias. Fale com sua equipe de rede para garantir que suas configurações de firewall, proxy e DNS não estejam bloqueando essas URLs. Você também pode verificar os logs de rastreamento de rede para identificar onde o serviço da Área de Trabalho Virtual do Azure está sendo bloqueado. Se você abrir uma solicitação de Suporte da Microsoft para esse problema específico, certifique-se de anexar os logs de rastreamento de rede à solicitação.

Erro: InstallationHealthCheckFailedException

Na VM do host da sessão, vá para Aplicativo de Logs do >Windows do >Visualizador de Eventos. Se você vir um evento com ID 3277 na InstallationHealthCheckFailedException descrição, o ouvinte de pilha não está funcionando porque o servidor de terminal alternou a chave do Registro para o ouvinte de pilha.

Para resolver o problema:

  1. Verifique se o ouvinte da pilha está funcionando.
  2. Se o ouvinte da pilha não estiver funcionando, desinstale e reinstale manualmente o componente de pilha.

Erro: ENDPOINT_NOT_FOUND

Na VM do host da sessão, vá para Aplicativo de Logs do >Windows do >Visualizador de Eventos. Se você vir um evento com ID 3277 na ENDPOINT_NOT_FOUND descrição, o agente não conseguiu encontrar um endpoint para estabelecer uma conexão. Esse problema de conexão pode ocorrer devido a um dos seguintes motivos:

  • Não há VMs de host de sessão em seu pool de hosts.
  • As VMs de host de sessão em seu pool de hosts não estão ativas.
  • Todas as VMs de host de sessão em seu pool de host excederam o limite máximo de sessão.
  • Nenhuma das VMs em seu pool de host tem o serviço de agente em execução nelas.

Para resolver o problema:

  1. Verifique se a VM está ligada e não foi removida do pool de hosts.
  2. Verifique se a VM não excedeu o limite máximo de sessão.
  3. Verifique se o serviço do agente está em execução e se o ouvinte da pilha está funcionando.
  4. Verifique se o agente pode se conectar ao broker.
  5. Verifique se sua VM tem um token de registro válido.
  6. Verifique se o token de registro da VM não expirou.

Erro: InstallMsiException

Na VM do host da sessão, vá para Aplicativo de Logs do >Windows do >Visualizador de Eventos. Se você vir um evento com ID 3277 na InstallMsiException descrição, o instalador já está em execução para outro aplicativo enquanto você está tentando instalar o agente ou a política de grupo está bloqueando a execução de msiexec.exe .

Para verificar se a política de grupo está bloqueando a execução do msiexec.exe :

  1. Abra o Conjunto de Diretivas resultante executando rsop.msc em um prompt de comando com privilégios elevados.

  2. Na janela Conjunto de Políticas Resultante que aparece, vá para Configuração>do Computador Modelos>Administrativos Componentes do Windows Windows>Installer>Desative o Windows Installer. Se o estado for Habilitado, trabalhe com sua equipe do Active Directory para permitir que msiexec.exe seja executado.

    Captura de tela da política do Windows Installer no Conjunto de Políticas Resultante.

    Observação

    Essa liste não é uma lista abrangente de políticas, apenas as que conhecemos atualmente.

Erro: Win32exception

Na VM do host da sessão, vá para Aplicativo de Logs do >Windows do >Visualizador de Eventos. Se você vir um evento com ID 3277 na InstallMsiException descrição, uma política está bloqueando a inicialização de cmd.exe . O bloqueio desse programa impede que você execute a janela do console, que é o que você precisa usar para reiniciar o serviço sempre que o agente é atualizado.

  1. Abra o Conjunto de Diretivas resultante executando rsop.msc em um prompt de comando com privilégios elevados.
  2. Na janela Resultante do Conjunto de Políticas que aparece, vá para Modelos>Administrativos de Configuração>do Usuário Sistema>Impedir o acesso ao prompt de comando. Se o estado for Habilitado, trabalhe com sua equipe do Active Directory para permitir que cmd.exe seja executado.

Erro: o ouvinte da pilha não está funcionando na VM do Windows 10 2004

Na VM do host da sessão, em um prompt de comando, execute qwinsta.exe e anote o número da versão que aparece ao lado da rdp-sxsSESSIONNAME coluna. Se a STATE coluna para rdp-tcp e rdp-sxs entradas não Listenfor , ou se rdp-tcp e rdp-sxs entradas não estiverem listadas, isso significa que há um problema de pilha. As atualizações de pilha são instaladas juntamente com as atualizações do agente, mas se a atualização não for bem-sucedida, o Ouvinte da Área de Trabalho Virtual do Azure não funcionará.

Para resolver o problema:

  1. Abra o Editor do Registro.

  2. Ir para HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations.

  3. Em WinStations, você pode ver várias pastas para diferentes versões de pilha. Selecione uma pasta que corresponda às informações de versão que você viu ao executar qwinsta.exe em um prompt de comando.

    • Encontre fReverseConnectMode e certifique-se de que seu valor de dados seja 1. Além disso, certifique-se de que fEnableWinStation está definido como 1.

      Captura de tela de fReverseConnectMode.

    • Se fReverseConnectMode não estiver definido como 1, selecione fReverseConnectMode e insira 1 em seu campo de valor.

    • Se fEnableWinStation não estiver definido como 1, selecione fEnableWinStation e insira 1 em seu campo de valor.

  4. Repita as etapas anteriores para cada pasta que corresponda às informações de versão que você viu ao executar qwinsta.exe em um prompt de comando.

    Dica

    Para alterar o fReverseConnectMode modo or fEnableWinStation para várias VMs ao mesmo tempo, você pode fazer uma das duas coisas a seguir:

    • Exporte a chave do registro do computador que já está funcionando e importe-a em todos os outros computadores que precisam dessa alteração.
    • Crie um GPO (objeto de política de grupo) que defina o valor da chave do registro para os computadores que precisam da alteração.

  5. Reinicie a VM do host de sessão.

  6. Abra o Editor do Registro.

  7. Ir para HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\ClusterSettings.

  8. Em ClusterSettings, localize SessionDirectoryListener e verifique se o valor dos dados é rdp-sxs<version number, onde <version number> corresponde às informações de versão que você viu ao executar qwinsta.exe em um prompt de comando.

  9. Se SessionDirectoryListener não estiver definido como rdp-sxs<version number, você precisará seguir as etapas na seção Seu problema não está listado aqui ou não foi resolvido .

Erro: DownloadMsiException

Na VM do host da sessão, vá para Aplicativo de Logs do >Windows do >Visualizador de Eventos. Se você vir um evento com ID 3277 na DownloadMsiException descrição, não há espaço suficiente no disco para o RDAgent.

Para resolver esse problema, libere espaço no disco:

  • Excluindo arquivos que não estão mais em uso.
  • Aumentando a capacidade de armazenamento de sua VM.

Erro: falha na atualização do agente mostrando MissingMethodException

Na VM do host da sessão, vá para Aplicativo de Logs do >Windows do >Visualizador de Eventos. Se você vir um evento com a ID 3389 na MissingMethodException: Method not found descrição, o agente da Área de Trabalho Virtual do Azure não foi atualizado com êxito e foi revertido para uma versão anterior. Esse problema pode ocorrer porque o número de versão do .NET Framework atualmente instalado em suas VMs é inferior a 4.7.2. Para resolver esse problema, você precisa atualizar o .NET para a versão 4.7.2 ou posterior seguindo as instruções de instalação na documentação do .NET Framework.

Erro: as VMs do host da sessão estão presas no estado de atualização

Se o status listado para hosts de sessão em seu pool de hosts sempre indicar Indisponível ou Atualização, o agente ou pilha não foi instalado com êxito.

Para resolver esse problema, primeiro reinstale a pilha lado a lado:

  1. Faça login na VM do host da sessão como administrador.

  2. Em um prompt do PowerShell com privilégios elevados, execute qwinsta.exe e anote o número da versão que aparece ao lado na rdp-sxsSESSIONNAME coluna. Se a STATE coluna para rdp-tcp e rdp-sxs entradas não Listenfor , ou se rdp-tcp e rdp-sxs entradas não estiverem listadas, isso significa que há um problema de pilha.

  3. Execute o seguinte comando para interromper o serviço RDAgentBootLoader :

    Stop-Service RDAgentBootLoader

  4. Vá para Painel>de Controle, Programas>, Programas e Recursos ou, no Windows 11, vá para Configurações, Aplicativo>, Aplicativos.

  5. Desinstale a versão mais recente da pilha de rede SxS dos Serviços de Área de Trabalho Remota ou a versão listada no Editor do Registro sob HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations o valor de ReverseConnectionListener.

  6. De volta ao prompt do PowerShell, execute os seguintes cmdlets para adicionar o caminho do arquivo do instalador mais recente disponível na VM do host da sessão para a pilha lado a lado a uma variável e listar seu nome:

    $sxsMsi = (Get-ChildItem "$env:SystemDrive\Program Files\Microsoft RDInfra\" | ? Name -like SxSStack*.msi | Sort-Object CreationTime -Descending | Select-Object -First 1).FullName
$sxsMsi

  7. Instale o instalador mais recente disponível na VM do host da sessão para a pilha lado a lado executando o seguinte cmdlet:

    msiexec /i $sxsMsi

  8. Reinicie a VM do host de sessão.

  9. Em um prompt de comando, execute qwinsta.exe novamente e verifique se a coluna para rdp-tcp e rdp-sxs entradas STATE é Listen. Caso contrário, você deve registrar novamente sua VM e reinstalar o componente do agente.

Erro: os hosts da sessão estão presos no estado Indisponível

Se as VMs do host da sessão estiverem presas no estado Indisponível, sua VM não passou em uma das verificações de integridade listadas em Verificação de integridade. Você deve resolver o problema que está fazendo com que a VM falhe na verificação de integridade.

Erro: os hosts da sessão estão presos no estado Precisa de Assistência

Várias verificações de integridade podem fazer com que as VMs do host da sessão fiquem presas no estado Precisa de Assistência : UrlsAccessibleCheck, MetaDataServiceCheck e MonitoringAgentCheck.

UrlsAccessibleCheck

Se o host da sessão não passar na verificação de integridade UrlsAccessibleCheck , você precisará identificar qual URL necessária sua implantação está bloqueando no momento. Depois de saber qual URL está bloqueada, identifique qual configuração está bloqueando esse URL e remova-o.

Há dois motivos pelos quais o serviço está bloqueando um URL necessário:

  • Você tem um firewall ativo que está bloqueando a maioria do tráfego de saída e o acesso aos URLs necessários.
  • O arquivo de hosts locais está bloqueando os sites necessários.

Para resolver um problema relacionado ao firewall, adicione uma regra que permite conexões de saída à porta TCP 80/443 associada aos URLs bloqueados.

Se o arquivo de hosts locais estiver bloqueando os URLs necessários, verifique se nenhum dos URLs necessários está no arquivo Hosts em seu dispositivo. Você pode encontrar o local do arquivo Hosts na seguinte chave e valor do Registro:

Chave: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Digite: REG_EXPAND_SZ

Nome: DataBasePath

MetaDataServiceCheck

Se o host da sessão não passar na verificação de integridade MetaDataServiceCheck , o serviço não poderá acessar o ponto de extremidade do IMDS. Para resolver esse problema, você precisa fazer o seguinte:

  • Reconfigure as configurações de rede, firewall ou proxy para desbloquear o endereço IP 169.254.169.254.
  • Certifique-se de que seus clientes HTTP ignorarem os proxies Web na VM ao consultar o IMDS. Recomendamos que você permita o endereço IP necessário em quaisquer políticas de firewall dentro da VM que lidam com a direção de tráfego de rede de saída.

Se o problema for causado por um proxy Web, adicione uma exceção para 169.254.169.254 na configuração do proxy Web. Para adicionar essa exceção, abra uma sessão do Prompt de Comando ou do PowerShell com privilégios elevados e execute o seguinte comando:

netsh winhttp set proxy proxy-server="http=<customerwebproxyhere>" bypass-list="169.254.169.254"

MonitoringAgentCheck

Se o host da sessão não passar na verificação de integridade MonitoringAgentCheck , você precisará verificar o Agente Geneva da Infraestrutura de Serviços de Área de Trabalho Remota e validar se ele está funcionando corretamente no host da sessão:

  1. Verifique se o Agente de Genebra da Infraestrutura de Serviços da Área de Trabalho Remota está instalado no host da sessão. Você pode verificar isso na lista de programas instalados no host da sessão. Se você vir várias versões desse agente instaladas, desinstale as versões mais antigas e mantenha apenas a versão mais recente instalada.
  2. Se você não encontrar o Agente Geneva da Infraestrutura de Serviços de Área de Trabalho Remota instalado no host da sessão, examine os logs localizados em C:\Arquivos de Programas\Microsoft RDInfra\GenevaInstall.txt e veja se a instalação está falhando devido a um erro.
  3. Verifique se a tarefa agendada GenevaTask_<versão> foi criada. Essa tarefa agendada deve estar habilitada e em execução. Se não estiver, reinstale o agente usando o .msi arquivo chamado Microsoft.RDInfra.Geneva.Installer-x64-version<>.msi, que está disponível em C:\Arquivos de Programas\Microsoft RDInfra.

Erro: Conexão não encontrada: o RDAgent não tem uma conexão ativa com o agente

As VMs do host da sessão podem estar no limite de conexão e não podem aceitar novas conexões.

Para resolver esse problema:

  • Diminua o limite máximo de sessão. Essa alteração garante que os recursos sejam distribuídos de maneira mais uniforme entre os hosts da sessão e evita o esgotamento de recursos.
  • Aumente a capacidade de recursos das VMs do host de sessão.

Erro: operando um VM do Pro ou outro sistema operacional sem suporte

A pilha lado a lado só tem suporte em SKUs do Windows Enterprise ou Windows Server, o que significa que sistemas operacionais como o de uma VM do Pro não têm suporte. Se você não tiver um SKU Enterprise ou Server, a pilha será instalada em sua VM, mas não será ativada, portanto, ela não aparecerá quando você executar qwinsta.exe em sua linha de comando.

Para resolver esse problema, crie VMs de host de sessão usando um sistema operacional com suporte.

Erro: NAME_ALREADY_REGISTERED

O nome da VM do host da sessão já foi registrado e provavelmente é uma duplicata.

Para resolver o problema:

  1. Siga as etapas para remover o host da sessão do pool de host.

  2. Criar outra VM. Certifique-se de escolher um nome exclusivo para essa VM.

  3. Acesse o Portal do Azure e abra a página Visão Geral do pool de hosts na qual sua VM estava.

  4. Abra a guia Hosts da Sessão e verifique se todos os hosts de sessão estão no pool de hosts.

  5. Aguarde de 5 a 10 minutos para que o status do host da sessão diga Disponível.

    Captura de tela do host da sessão disponível.

Seu problema não está listado aqui ou não foi resolvido

Se você não encontrar seu problema neste artigo ou as instruções não o ajudaram, recomendamos que você desinstale, reinstale e registre novamente o Agente de Área de Trabalho Virtual do Azure. As instruções nesta seção mostram como registrar novamente sua VM de host da sessão no serviço de Área de Trabalho Virtual do Azure:

  1. Desinstale todos os componentes do agente, do carregador de inicialização e da pilha.
  2. Remova o host da sessão do pool de hosts.
  3. Gere uma nova chave de registro para a VM.
  4. Reinstale o Agente da Área de Trabalho Virtual do Azure e o carregador de inicialização.

Siga as instruções nesta seção se um ou mais dos seguintes cenários se aplicarem a você:

  • O estado da VM do host de sessão está travado como Atualização ou Indisponível.
  • Seu ouvinte de pilha não está funcionando e você está executando no Windows 10 versão 1809, 1903 ou 1909.
  • Você está recebendo um erro de EXPIRED_REGISTRATION_TOKEN.
  • Você não está vendo suas VMs aparecem na lista de hosts da sessão.
  • Você não está vendo Carregador do Agente da Área de Trabalho Remota no console Serviços.
  • Você não vê o componente RdAgentBootLoader como um processo em execução no Gerenciador de Tarefas.
  • Você está recebendo um erro "O Agente de Conexão não pôde validar as configurações" em VMs de imagem personalizadas.
  • As seções anteriores neste artigo não resolveram o problema.

Etapa 1: desinstalar todos os programas componentes do agente, do carregador de inicialização e da pilha

Antes de reinstalar o agente, o carregador de inicialização e a pilha, você deve desinstalar todos os programas componentes existentes da VM. Para desinstalar todos os programas componentes do agente, do carregador de inicialização e da pilha:

  1. Faça login na VM do host da sessão como administrador.

  2. Vá para Painel>de Controle, Programas>, Programas e Recursos ou, no Windows 11, vá para Configurações, Aplicativo>, Aplicativos.

  3. Desinstale os seguintes programas e reinicie a VM do host da sessão:

    Cuidado

    Ao desinstalar a Pilha de Rede SxS dos Serviços de Área de Trabalho Remota, você será solicitado a fechar os Serviços de Área de Trabalho Remota e o Redirecionador de Porta UserMode dos Serviços de Área de Trabalho Remota. Se você estiver conectado à VM do host da sessão usando RDP, selecione Não fechar aplicativos e, em seguida, selecione OK. Caso contrário, sua conexão RDP não funcionará.

    Captura de tela mostrando o prompt de que os Serviços de Área de Trabalho Remota e o Redirecionador de Porta UserMode dos Serviços de Área de Trabalho Remota devem ser fechados.

    • Carregador de Inicialização do Agente da Área de Trabalho Remota
    • Agente de Infraestrutura dos Serviços da Área de Trabalho Remota
    • Agente Geneva de Infraestrutura dos Serviços da Área de Trabalho Remota
    • Pilha de Rede SxS dos Serviços da Área de Trabalho Remota

    Observação

    Você pode ver várias instâncias desses programas. Certifique-se de remover todas elas.

    Captura de tela da desinstalação de programas.

Etapa 2: remover o host da sessão do pool de hosts

Quando você remove o host da sessão do pool de hosts, o host da sessão não fica mais registrado nesse pool de hosts. Essa alteração atua como uma redefinição para o registro do host da sessão. Para remover o host da sessão do pool de hosts:

  1. Entre no portal do Azure.

  2. Na barra de pesquisa, digite Área de Trabalho Virtual do Azure e selecione a entrada de serviço correspondente.

  3. Selecione Pools de host e selecione o nome do pool de host no qual a VM do host da sessão está.

  4. Acesse a guia Hosts da Sessão para ver a lista de todos os hosts da sessão nesse pool de hosts.

  5. Examine a lista de hosts de sessão e marque a caixa ao lado do host da sessão que você deseja remover.

  6. Selecione Remover.

    Captura de tela da remoção da VM do pool de host.

Etapa 3: gerar uma nova chave de registro para a VM

Você deve gerar uma nova chave de registro que é usada para registrar novamente sua VM de sessão no pool de host e no serviço. Para gerar uma nova chave de registro para a VM:

  1. Entre no portal do Azure.

  2. Na barra de pesquisa, digite Área de Trabalho Virtual do Azure e selecione a entrada de serviço correspondente.

  3. Selecione Pools de host e selecione o nome do pool de host no qual a VM do host da sessão está.

  4. Na folha Visão geral, selecione Chave de registro.

    Captura de tela da chave de registro no portal.

  5. Abra a guia Chave de registro e selecione Gerar nova chave.

  6. Insira a data de expiração e selecione Ok.

    Observação

    A data de validade não pode ser inferior a uma hora e superior a 27 dias a partir de sua data e hora de geração. Gere uma chave de registro apenas pelo tempo necessário.

  7. Copie a chave recém-gerada para sua área de transferência ou baixe o arquivo. Você precisará dessa chave mais tarde.

Etapa 4: reinstalar o agente e o carregador de inicialização

A reinstalação da versão mais recente do agente e do carregador de inicialização também instala automaticamente a pilha lado a lado e o agente de monitoramento de Genebra. Para reinstalar o agente e o carregador de inicialização, siga estas etapas. Esta é a versão mais recente para download do Agente da Área de Trabalho Virtual do Azure em ambientes de não validação. Para obter mais informações sobre a distribuição de novas versões do agente, confira Novidades no Agente da Área de Trabalho Virtual do Azure.

  1. Entre na VM do host da sessão como administrador e execute o instalador do agente e o carregador de inicialização da VM do host da sessão:

    Dica

    Para cada um dos instaladores do agente e do carregador de inicialização que você baixou, talvez seja necessário desbloqueá-los. Clique com o botão direito do mouse em cada arquivo e selecione Propriedades>Desbloquear>OK.

  2. Quando o instalador solicitar o token de registro, cole a chave de registro que está na área de transferência.

    Captura de tela do token de registro colado.

  3. Execute o instalador do carregador de inicialização.

  4. Reinicie sua VM de sessão.

  5. Entre no portal do Azure.

  6. Na barra de pesquisa, insira Área de Trabalho Virtual do Azure e selecione a entrada de serviço correspondente.

  7. Selecione Pools de host e selecione o nome do pool de host no qual a VM do host da sessão está.

  8. Acesse a guia Hosts da Sessão para ver a lista de todos os hosts da sessão nesse pool de hosts.

  9. Agora você deve ver o host da sessão registrado no pool de hosts com o status Disponível.

    Captura de tela do host da sessão disponível.

Remover a chave do Registro DisableRegistryTools

Se você executou todas as quatro etapas, mas o agente ainda não funciona, pode ser porque a DisableRegistryTools chave do Registro está habilitada em um dos seguintes locais:

  • HKU: \DEFAULT\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\DisableRegistryTools = 1
  • HKU: \S-1-5-18\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\DisableRegistryTools = 1
  • HKCU: \SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\DisableRegistryTools = 1

Essa chave do Registro impede que o agente instale a pilha lado a lado, o que resulta em um erro installMSIException. Esse erro faz com que os hosts da sessão fiquem presos em um estado indisponível.

Para resolver esse problema, você precisa remover a chave:

  1. Remova a DisableRegistryTools chave dos três locais listados anteriormente.
  2. Desinstale e remova a instalação de pilha lado a lado afetada da pasta Aplicativos e Recursos.
  3. Remova as chaves do Registro da pilha lado a lado afetadas.
  4. Reinicie a VM.
  5. Inicie o agente e deixe-o instalar automaticamente a pilha lado a lado.

Próximas etapas

Se o problema continuar, crie um caso de suporte e inclua informações detalhadas sobre o problema que você está enfrentando e as ações que você executou para tentar resolvê-lo. A lista a seguir inclui outros recursos que você pode usar para solucionar problemas na implantação da sua Área de Trabalho Virtual do Azure.