Resolver problemas comuns do Agente do Azure Virtual Desktop

  • Artigo

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

  • Um erro no corretor que faz com que o agente pare 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 orienta você por soluções para esses cenários comuns e como resolver problemas de conexão.

Nota

Para solucionar problemas relacionados à conectividade de 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) do host de sessão acessando o Aplicativo de Logs>do Windows do Visualizador>de Eventos. Procure eventos que tenham uma das seguintes fontes para identificar o problema:

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

Erro: O RDAgentBootLoader e/ou Remote Desktop Agent Loader parou de ser executado

Se você estiver vendo qualquer um dos seguintes problemas, isso significa que o carregador de inicialização, que carrega o agente, não pôde instalar o agente corretamente e o serviço do agente não está sendo executado na VM do host da sessão:

  • RDAgentBootLoader está parado ou não está em execução.
  • Não há status para o Remote Desktop Agent Loader.

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

  1. Na janela Serviços, clique com o botão direito do mouse em Carregador de Agente de Área de Trabalho Remota.

  2. Selecione Iniciar. Se essa opção estiver acinzentada para você, você não terá permissões de administrador. Você precisa obter essas permissões para iniciar o serviço.

  3. Aguarde 10 segundos e, em seguida, clique com o botão direito do rato em Remote Desktop Agent Loader.

  4. Selecione Atualizar.

  5. Se o serviço parar depois de iniciado e atualizado, você pode 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 vir um evento com ID 3277 com a descrição INVALID_REGISTRATION_TOKEN ou EXPIRED_MACHINE_TOKEN, a chave de registo que foi utilizada não é reconhecida como válida.

Para resolver este problema:

  1. Crie uma nova chave de registo seguindo os passos em Gerar uma chave de registo.

  2. Abra um prompt do PowerShell como administrador e execute os seguintes comandos 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 RDAgentBootLoader serviço:

    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, exiba as entradas do Visualizador de Eventos e veja se há algum erro que esteja impedindo o agente de iniciar.

Erro: O agente não pode 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 com INVALID_FORM na descrição, o agente não poderá se conectar ao broker 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ê pode alcançar os dois pontos de extremidade referidos como BrokerResourceIdURI e BrokerResourceIdURIGlobal:

  1. Abra o Editor de Registo.

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

  3. Anote os valores para BrokerResourceIdURI e BrokerResourceIdURIGlobal.

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

  5. Abra outra guia no navegador e 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 broker, ambas as páginas deverão ser carregadas com êxito e mostrar uma mensagem informando que o RD Broker está íntegro, conforme mostrado nas seguintes capturas de tela:

    Captura de tela do acesso ao uri do broker carregado com êxito

    Captura de tela do acesso ao uri global do broker 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 do acesso do broker carregado sem sucesso

    Captura de tela do acesso global do broker carregado sem sucesso

    Tem de desbloquear os pontos finais necessários e, em seguida, repetir os passos 4 a 7. Para obter mais informações, consulte Lista de URL necessária.

  8. Se seguir as etapas anteriores não resolver o problema, certifique-se de que você não tenha políticas de grupo com cifras que bloqueiem a conexão do agente para intermediar. A Área de Trabalho Virtual do Azure usa as mesmas cifras TLS 1.2 que o Azure Front Door. Para obter mais informações, consulte 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 vir um evento com ID 3703 com URL de Gateway de RD: não está acessível na descrição, o agente não consegue aceder aos URLs de gateway. Para se conectar com êxito ao host da sessão, você deve permitir o tráfego de rede para as URLs da Lista de URLs Necessárias. Além disso, certifique-se de que suas configurações de firewall ou proxy não bloqueiem esses URLs. O desbloqueio dessas URLs é necessário 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 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 ID 3019, o agente não poderá acessar as URLs de transporte de soquete da Web. Para se conectar com êxito ao host da sessão e permitir que o tráfego de rede ignore essas restrições, você deve desbloquear as URLs listadas na lista URL necessário. Trabalhe 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 seus logs de rastreamento de rede para identificar onde o serviço de Área de Trabalho Virtual do Azure está sendo bloqueado. Se você abrir um caso de Suporte da Microsoft para esse problema específico, certifique-se de anexar seus 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 com InstallationHealthCheckFailedException na 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 este problema:

  1. Verifique se o ouvinte da pilha está funcionando

  2. Se o ouvinte de 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 com ENDPOINT_NOT_FOUND na descrição, o broker não conseguiu encontrar um ponto de extremidade com o qual estabelecer uma conexão. Esse problema de conexão pode acontecer por 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 nelas.

Para resolver este 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 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. Certifique-se de que o agente pode se conectar ao corretor.

  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á em execução para outro aplicativo enquanto você está tentando instalar o agente ou a diretiva de grupo está bloqueando msiexec.exe a execução.

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

  1. Abra o Conjunto de Políticas Resultante executando rsop.msc a partir de um prompt de comando elevado.

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

    Captura de ecrã da política do Windows Installer no Conjunto de Políticas Resultante

    Nota

    Esta lista 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 com InstallMsiException na descrição, uma política está bloqueando cmd.exe a inicialização. Bloquear este programa impede que você execute a janela do console, que é o que você precisa usar para reiniciar o serviço sempre que o agente for atualizado.

  1. Abra o Conjunto de Políticas Resultante executando rsop.msc a partir de um prompt de comando elevado.

  2. Na janela Conjunto de Políticas Resultante que aparece, vá para Configuração do Usuário > Modelos > Administrativos do Sistema > Impedir o acesso ao prompt de comando. Se o estado estiver Habilitado, trabalhe com sua equipe do Ative Directory para permitir cmd.exe a execução.

Erro: O ouvinte de pilha não está funcionando em uma VM de host de sessão 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 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 junto com as atualizações do agente, mas se a atualização não tiver êxito, o Ouvinte da Área de Trabalho Virtual do Azure não funcionará.

Para resolver este problema:

  1. Abra o Editor de Registo.

  2. Vá 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 verifique se o valor dos dados é 1. Certifique-se também de que fEnableWinStation está definido como 1.

      Screenshot de fReverseConnectMode

    • Se fReverseConnectMode não estiver definido como 1, selecione fReverseConnectMode e digite 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.

    Gorjeta

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

    • Exporte a chave do Registro da máquina que você já tem trabalhando e importe-a para todas as outras máquinas que precisam dessa alteração.
    • Crie um objeto de política de grupo (GPO) que defina o valor da chave do Registro para as máquinas que precisam da alteração.

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

  6. Abra o Editor de Registo.

  7. Vá para HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\ClusterSettings.

  8. Em ClusterSettings, localize SessionDirectoryListener e verifique se seu valor de 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 com DownloadMsiException na descrição, não há espaço suficiente no disco para o RDAgent.

Para resolver esse problema, crie espaço no disco da seguinte forma:

  • Exclusão de arquivos que não estão mais em uso.
  • Aumentar a capacidade de armazenamento da VM do host da sessão.

Erro: O agente não consegue atualizar com 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 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 reverteu para uma versão anterior. Esse problema pode estar acontecendo 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 disser Indisponível ou Atualizando, o agente ou a pilha não foi instalado com êxito.

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

  1. Entre 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 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. Aceda a Programas>e Funcionalidades do Painel de Controlo>ou, no Windows 11, aceda a Definições de Aplicações.>

  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 da 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 de host de sessão para a pilha lado a lado executando o seguinte comando:

    msiexec /i $sxsMsi

  8. Reinicie a VM do host da 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 de sessão estão presos no estado Indisponível

Se as VMs do host da sessão estiverem presas no estado Indisponível, a VM não passou em uma das verificações de integridade listadas na 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 de sessão estão presos no estado Precisa de assistência

Há várias verificações de integridade que podem fazer com que suas VMs de host de 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ário sua implantação está bloqueando no momento. Depois de saber qual URL está bloqueado, identifique qual configuração está bloqueando esse URL e remova-o.

Há dois motivos pelos quais o serviço está bloqueando uma URL necessária:

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

Para resolver um problema relacionado ao firewall, adicione uma regra que permita conexões de saída para a porta TCP 80/443 associada às URLs bloqueadas.

Se o seu ficheiro de anfitriões locais estiver a bloquear os URLs necessários, certifique-se de que nenhum dos URLs necessários se encontra no ficheiro Hosts do seu dispositivo. Você pode encontrar o local do arquivo Hosts na seguinte chave e valor do Registro:

Chave: 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 do MetaDataServiceCheck , o serviço não poderá acessar o ponto de extremidade do 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 ignorem proxies da Web dentro da VM ao consultar o IMDS. Recomendamos que você permita o endereço IP necessário em todas as políticas de firewall dentro da VM que lidam com a direção do tráfego de rede de saída.

Se o problema for causado por um proxy da Web, adicione uma exceção para 169.254.169.254 na configuração do proxy da Web. Para adicionar essa exceção, abra um prompt de comando elevado ou uma sessão do PowerShell 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 do MonitoringAgentCheck , você precisará verificar o Agente de Genebra 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 de Á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 vir várias versões deste 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 da Infraestrutura de Serviços de Área de Trabalho Remota instalado no host da sessão, revise 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. Esta tarefa agendada deve estar habilitada e em execução. Se não estiver, reinstale o agente usando o arquivo chamado Microsoft.RDInfra.Geneva.Installer-x64-version<>.msi, que está disponível em C:\Program Files\Microsoft RDInfra..msi

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

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

Para resolver este problema:

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

Erro: Operando uma VM Pro ou outro sistema operacional não suportado

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

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

Erro: NAME_ALREADY_REGISTERED

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

Para resolver este problema:

  1. Siga as etapas na seção Remover o host da sessão do pool de hosts.

  2. Crie outra VM. Certifique-se de escolher um nome exclusivo para esta VM.

  3. Vá para o portal do Azure e abra a página Visão geral do pool de hosts em que sua VM estava.

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

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

    Captura de ecrã do anfitrião de sessão disponível

O seu problema não está listado aqui ou não foi resolvido

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

  1. Desinstalando todos os agentes, carregadores de inicialização e componentes de pilha.

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

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

  4. Reinstalar o Agente de Ambiente de Trabalho Virtual do Azure e o gestor de arranque.

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

  • O estado da VM do host da sessão está bloqueado como Atualizando 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 de host de sessão aparecerem na lista de hosts de sessão.
  • Não vê o serviço Carregador de Agentes de Ambiente de Trabalho Remoto na consola Serviços.
  • Você não vê o componente RdAgentBootLoader como um processo em execução no Gerenciador de Tarefas.
  • Você está recebendo um agente de conexão não pôde validar o erro de configurações em VMs de imagem personalizada.
  • As secções anteriores deste artigo não resolveram o problema.

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

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

  1. Entre na VM do host da sessão como administrador.

  2. Aceda a Programas>e Funcionalidades do Painel de Controlo>ou, no Windows 11, aceda a Definições de Aplicações.>

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

    Atenção

    Ao desinstalar a Pilha de Rede SxS dos Serviços de Área de Trabalho Remota, você 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 RDP, selecione Não fechar aplicativos e selecione OK, caso contrário, sua conexão RDP não funcionará.

    Captura de ecrã a mostrar o aviso de que os Serviços de Ambiente de Trabalho Remoto e o Redirecionador de Porta UserMode dos Serviços de Ambiente de Trabalho Remoto devem ser fechados

    • Carregador de inicialização do agente de área de trabalho remota
    • Agente de Infraestrutura de Serviços de Área de Trabalho Remota
    • Agente de Genebra da Infraestrutura de Serviços de Área de Trabalho Remota
    • Pilha de rede SxS dos Serviços de Área de Trabalho Remota

    Nota

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

    Captura de ecrã da desinstalação de programas

Etapa 2: Remover o host de sessão do pool de hosts

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

  1. Inicie sessão 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 hosts e selecione o nome do pool de hosts no qual sua VM de host de sessão está.

  4. Selecione Anfitriões de Sessão para ver a lista de todos os anfitriões de sessão nesse conjunto de anfitriões.

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

  6. Selecione Remover.

    Captura de tela mostrando a remoção de 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. Inicie sessão 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 hosts e selecione o nome do pool de hosts no qual sua VM de host de sessão está.

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

    Captura de ecrã da chave de registo no portal

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

  6. Introduza a data de validade e, em seguida, selecione Ok.

Nota

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

  1. Copie a chave recém-gerada para a á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 gestor de arranque também instala automaticamente a pilha lado a lado e o agente de monitorização de Genebra. Para reinstalar o agente e o gestor de arranque, siga estes passos. Esta é a versão mais recente para download do Agente de Área de Trabalho Virtual do Azure em ambientes sem validação. Para obter mais informações sobre a distribuição de novas versões do agente, consulte Novidades no Agente de Á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:

    Gorjeta

    Para cada um dos instaladores de agente e 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, selecione Desbloquear e, finalmente, selecione OK.

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

    Captura de ecrã do token de registo colado

  3. Execute o instalador do gestor de arranque.

  4. Reinicie a VM de sessão.

  5. Inicie sessão 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 hosts e selecione o nome do pool de hosts no qual sua VM de host de sessão está.

  8. Selecione Anfitriões de Sessão para ver a lista de todos os anfitriões de sessão nesse conjunto de anfitriões.

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

    Captura de ecrã do anfitrião de sessão disponível

Remover chave de registo 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. Este erro faz com que os anfitriões de sessão fiquem presos num 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 da pilha lado a lado afetada da pasta Apps & Features .

  3. Remova as chaves de registo da pilha lado a lado afetada.

  4. Reinicie a VM.

  5. Inicie o agente e deixe-o instalar automaticamente a pilha lado a lado.

Próximos passos

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