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 de 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ê estiver vendo 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á sendo executado 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 esta opção estiver esmaecida para você, significa que você não tem permissões de administrador. Você precisa obter essas permissões para iniciar o serviço.

  3. Aguarde 10 segundos e depois 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 for interrompido depois que você o tiver iniciado e atualizado, é possível que haja 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 comandos 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. Em seguida, execute o seguinte comando para reiniciar o serviço RDAgentBootLoader:

    Restart-Service RDAgentBootLoader

  4. Execute os comandos 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 nã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 a ID 3277 com INVALID_FORM na descrição, o agente não poderá se conectar ao agente ou alcançar um ponto de extremidade específico. Esse problema pode ser devido a determinadas configurações de firewall ou DNS.

Para resolver esse problema, verifique se você consegue alcançar os dois pontos de extremidade conhecidos como BrokerURI e BrokerURIGlobal:

  1. Abra o Editor do Registro.

  2. Vá para HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RDInfraAgent.

  3. Anote os valores de BrokerResourceIdURI e de BrokerResourceIdURIGlobal.

  4. Abra um navegador da Web e insira o valor de BrokerURI 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 da Web e insira o valor de BrokerURIGlobal na barra de endereços 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 corretor, as páginas não serão carregadas, conforme mostrado na captura de tela a seguir.

    Captura de tela de acesso ao agente carregado sem êxito

    Captura de tela de acesso ao agente global carregado sem êxito

    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 seu problema, certifique-se de que você não tenha nenhuma política de grupo com criptografias que bloqueiem a conexão do agente com o corretor. 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 a ID 3703 que diz URL do gateway RD: não está acessível na 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 Firewall do Azure, consulte Como usar o Firewall do Azure para proteger implantações da Área de Trabalho Virtual do Azure e 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 conseguirá 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 a ID 3277 com InstallationHealthCheckFailedException na descrição, o ouvinte da pilha não está funcionando porque o servidor do terminal alterou a chave de registro do ouvinte da pilha.

Para resolver o problema:

  1. Verifique se oouvinte 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 a ID 3277 com ENDPOINT_NOT_FOUND na descrição, o corretor não poderá encontrar um ponto de extremidade com o qual 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 hosts excederam o limite máximo de sessão.
  • Nenhuma das VMs em seu pool de hosts tem o serviço de agente em execução.

Para resolver o problema:

  1. Verifique se a VM está ligada e não foi removida do pool de hosts.

  2. Certifique-se de que a VM não exceda 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 com InstallMsiException na descrição, o instalador já está sendo executado para outro aplicativo enquanto você tenta instalar o agente ou a política de grupo está bloqueando msiexec.exea execução.

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

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

  2. Na janela Conjunto de Políticas Resultante que aparece, acesse Configuração do Computador>Modelos Administrativos>Componentes do Windows>Windows Installer>Desativar o Windows Installer. Se o estado estiver Habilitado, fale com sua equipe do Active Directory para permitir a execução de msiexec.exe.

    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 a ID 3277 que diz InstallMsiException na descrição, uma política está bloqueando a inicialização do 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 resultante de política executando rsop.msc em um prompt de comando com privilégios elevados.

  2. Na janela Conjunto resultante de política que aparece, vá para Configuração do usuário> Modelos Administrativos > Sistema >Impedir o acesso ao prompt de comando. Se o estado estiver Habilitado, fale com sua equipe do Active Directory para permitir a execução de cmd.exe.

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

Na VM do host de sessão, a partir de um prompt de comando, execute qwinsta.exe e anote o número de versão que aparece ao lado de rdp-sxs na coluna SESSIONNAME. Se a coluna STATE para entradas rdp-tcp e rdp-sxs não for Listen ou se as entradas rdp-tcp e rdp-sxs 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. Vá para HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations.

  3. Em WinStations, você pode ver várias pastas referentes a diferentes versões de pilha; selecione a pasta que corresponde às informações de versão que você viu ao executar o qwinsta.exe no prompt de comando.

    • Localize fReverseConnectMode e verifique se seu valor de dados é 1. Verifique também se fEnableWinStation está definido como 1.

      Captura de tela de fReverseConnectMode

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

    • Se fEnableWinStation não estiver definido como 1, selecione fEnableWinStation e insira 1 no 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 modo fReverseConnectMode ou fEnableWinStation em várias VMs de uma vez, você pode executar uma das duas ações 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. Vá para HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\ClusterSettings.

  8. Em ClusterSettings, localize SessionDirectoryListener e verifique se seu valor de dados está 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 a ID 3277 que diz DownloadMsiException na 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 com MissingMethodException: método não encontrado na 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 estar acontecendo porque o número da versão do .NET Framework atualmente instalado em suas VMs é menor que 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 de sessão estão presas no estado Em 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 elevado do PowerShell, execute qwinsta.exe e anote o número da versão que aparece ao lado de rdp-sxs na coluna SESSIONNAME. Se a coluna STATE para entradas rdp-tcp e rdp-sxs não for Listen ou se as entradas rdp-tcp e rdp-sxs não estiverem listadas, isso significa que há um problema de pilha.

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

    Stop-Service RDAgentBootLoader

  4. Vá para Painel de controle>Programas>Programas e recursos, ou no Windows 11 vá para Aplicativo de configurações> 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 em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations sob o valor de ReverseConnectionListener.

  6. De volta ao prompt do PowerShell, execute os seguintes comandos para adicionar o caminho do arquivo do instalador mais recente disponível na VM do host de sessão para a pilha lado a lado a uma variável e liste 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 em sua VM do host de sessão para a pilha lado a lado executando o seguinte comando:

    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 STATE para entradas rdp-tcp e rdp-sxs é 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 não passe na verificação de integridade.

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

Há várias verificações de integridade que podem fazer com que os hosts da sessão fiquem presos 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:

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

Tipo: 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 IMDS. Para resolver esse problema, você precisará 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 de Genebra da Infraestrutura de Serviços da Á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 de Genebra de Infraestrutura de Serviços da Á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_<version> 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

Suas VMs de host de 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 da sessão. Essa alteração garante que os recursos sejam distribuídos de forma mais uniforme entre os hosts da sessão e evite o esgotamento dos 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 corporativo ou de servidor, a pilha será instalada na sua VM, mas não será ativada, então ela não aparecerá quando você executar qwinsta na 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 na seção Remover o host da sessão do pool de hosts.

  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 cinco a dez minutos para que o status do host da sessão mostre 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. Desinstalando todos os componentes do agente, do carregador de inicialização e da pilha.

  2. Removendo o host da sessão do pool de hosts.

  3. Gerando uma nova chave de registro para a VM.

  4. Reinstalando o Agente de Á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.
  • O ouvinte da pilha não está funcionando e você o 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 Agente de conexão não conseguiu validar as configurações em VMs com imagem personalizada.
  • 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 Aplicativo de configurações> Aplicativos .

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

    Cuidado

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

    Captura de tela mostrando a solicitação que tanto os Serviços de Área de Trabalho Remota quanto o Redirecionador de Porta UserMode dos Serviços de Área de Trabalho Remota devem estar 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

    É possível que você veja várias instâncias desses programas. Certifique-se de remover todas elas.

    Captura de tela da desinstalação dos 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 hosts

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 hosts 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 validade 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.

  1. Copie a chave recém-gerada para sua área de transferência ou baixe o arquivo. Precisaremos 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 carregador de inicialização e do agente que você baixou, talvez seja necessário desbloqueá-los. Clique com o botão direito do mouse em cada arquivo e selecione Propriedades, selecione Desbloquear e, por fim, selecione 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, isso pode ser porque a chave do Registro DisableRegistryTools 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ê precisará remover a chave:

  1. Remova a chave DisableRegistryTools 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.