Partilhar via


Configuração da máquina virtual do anfitrião de sessão do Azure Virtual Desktop (clássico)

Importante

Este conteúdo aplica-se ao Ambiente de Trabalho Virtual do Azure (clássico), que não suporta objetos do Azure Resource Manager do Ambiente de Trabalho Virtual do Azure. Se você estiver tentando gerenciar objetos da Área de Trabalho Virtual do Azure Resource Manager, consulte este artigo.

Use este artigo para solucionar problemas que você está tendo ao configurar as máquinas virtuais (VMs) de host de sessão da Área de Trabalho Virtual do Azure.

Fornecer comentários

Visite o da Comunidade Técnica de Área de Trabalho Virtual do para discutir o serviço de Área de Trabalho Virtual do Azure com a equipe do produto e os membros ativos da comunidade.

As VMs não estão associadas ao domínio

Siga estas instruções se tiver problemas para associar VMs ao domínio.

Erro: Credenciais incorretas

Causa: Houve um erro de digitação quando as credenciais foram inseridas nas correções da interface de modelo do Azure Resource Manager.

Solução: Execute uma das seguintes ações para resolver o problema.

Erro: Tempo limite aguardando a entrada do usuário

Causa: A conta usada para concluir a associação ao domínio pode ter autenticação multifator (MFA).

Correção: Execute uma das seguintes ações para resolver.

  • Remova temporariamente o MFA da conta.
  • Use uma conta de serviço.

Erro: A conta usada durante o provisionamento não tem permissões para concluir a operação

Causa: A conta que está a ser usada não tem permissões para adicionar VMs ao domínio devido à conformidade e aos regulamentos.

Correção: Execute uma das seguintes ações para resolver.

  • Use uma conta que seja membro do grupo Administrador.
  • Conceda as permissões necessárias para a conta que está sendo usada.

Erro: O nome de domínio não resolve

Causa 1: VMs estão em uma rede virtual que não está associada à rede virtual (VNET) onde o domínio está localizado.

Correção 1: Criar emparelhamento VNET entre a VNET onde as VMs foram provisionadas e a VNET onde o controlador de domínio (DC) está sendo executado. Consulte Criar um emparelhamento de rede virtual - Gestor de Recursos, subscrições diferentes.

Causa 2: Ao usar os Serviços de Domínio Microsoft Entra, a rede virtual não tem suas configurações de servidor DNS atualizadas para apontar para os controladores de domínio gerenciados.

Fix 2: Para atualizar as configurações de DNS para a rede virtual que contém os Serviços de Domínio Microsoft Entra, consulte Atualizar configurações de DNS para a rede virtual do Azure.

Causa 3: As configurações do servidor DNS da interface de rede não apontam para o servidor DNS apropriado na rede virtual.

Correção 3: Execute uma das seguintes ações para resolver, seguindo as etapas em [Alterar servidores DNS].

  • Altere as configurações do servidor DNS da interface de rede para Custom com as etapas de Change DNS servers e especifique os endereços IP privados dos servidores DNS na rede virtual.
  • Altere as configurações do servidor DNS da interface de rede para Herdar da rede virtual com as etapas de Alterar servidores DNSe, em seguida, altere as configurações do servidor DNS da rede virtual com as etapas de Alterar servidores DNS.

O Agente de Área de Trabalho Virtual do Azure e o Carregador de Inicialização da Área de Trabalho Virtual do Azure não estão instalados

A maneira recomendada de provisionar VMs é usando o modelo do Azure Resource Manager Criar e provisionar o grupo de hosts da Área de Trabalho Virtual do Azure. O modelo instala automaticamente o Agente de Área de Trabalho Virtual do Azure e o Carregador de Inicialização do Agente de Área de Trabalho Virtual do Azure.

Siga estas instruções para confirmar se os componentes estão instalados e para verificar se há mensagens de erro.

  1. Confirme se os dois componentes estão instalados verificando Painel de Controle>Programas>Programas e Recursos. Se do Agente de Área de Trabalho Virtual do Azure e do Carregador de Inicialização do Agente de Área de Trabalho Virtual do Azure não estiverem visíveis, eles não serão instalados na VM.
  2. Abra Explorador de Ficheiros e navegue até C:\Windows\Temp\ScriptLog.log. Se o arquivo estiver ausente, isso indica que o DSC do PowerShell que instalou os dois componentes não pôde ser executado no contexto de segurança fornecido.
  3. Se o arquivo C:\Windows\Temp\ScriptLog.log estiver presente, abra-o e verifique se há mensagens de erro.

Erro: O Agente de Área de Trabalho Virtual do Azure e o Carregador de Inicialização do Agente de Área de Trabalho Virtual do Azure estão ausentes. C:\Windows\Temp\ScriptLog.log também não está presente

Causa 1: credenciais fornecidas durante a entrada para o modelo do Azure Resource Manager estavam incorretas ou as permissões eram insuficientes.

Correção 1: Adicione manualmente os componentes ausentes às VMs usando Criar um pool de hosts com o PowerShell.

Causa 2: PowerShell DSC conseguiu iniciar e executar, mas não conseguiu concluir, pois não consegue entrar na Área de Trabalho Virtual do Azure e obter as informações necessárias.

Correção 2: Confirme os itens na lista a seguir.

  • Certifique-se de que a conta não tem Autenticação Multifator (MFA).
  • Confirme se o nome do locatário está correto e se o locatário existe na Área de Trabalho Virtual do Azure.
  • Confirme se a conta tem pelo menos permissões de Colaborador RDS.

Erro: Falha na autenticação, erro em C:\Windows\Temp\ScriptLog.log

Causa: O DSC do PowerShell foi capaz de ser executado, mas não conseguiu conectar-se à Área de Trabalho Virtual do Azure.

Correção de Erro: Confirme os itens na lista abaixo.

  • Registre manualmente as VMs com o serviço de Área de Trabalho Virtual do Azure.
  • Confirme se a conta usada para se conectar à Área de Trabalho Virtual do Azure tem permissões no locatário para criar pools de hosts.
  • Verifique se a conta não possui MFA.

O Agente de Área de Trabalho Virtual do Azure não está se registrando no serviço de Área de Trabalho Virtual do Azure

Quando o Agente de Área de Trabalho Virtual do Azure é instalado pela primeira vez em VMs de host de sessão (manualmente ou por meio do modelo do Azure Resource Manager e do PowerShell DSC), ele fornece um token de registro. A seção a seguir aborda a solução de problemas aplicáveis ao Agente de Área de Trabalho Virtual do Azure e ao token.

Erro: O status arquivado no cmdlet Get-RdsSessionHost mostra o status como Indisponível

Get-RdsSessionHost cmdlet mostra o status como Indisponível.

Causa: O agente não consegue se atualizar para uma nova versão.

Correção: Siga estas instruções para atualizar manualmente o agente.

  1. Baixe uma nova versão do agente na VM do host da sessão.
  2. Inicie o Gerenciador de Tarefas e, na guia Serviço, pare o serviço RDAgentBootLoader.
  3. Execute o instalador para a nova versão do Agente de Área de Trabalho Virtual do Azure.
  4. Quando for solicitado o token de registro, remova o INVALID_TOKEN de entrada e pressione Avançar (um novo token não é necessário).
  5. Complete o Assistente de instalação.
  6. Abra o Gestor de Tarefas e inicie o serviço RDAgentBootLoader.

Erro: A entrada de registo IsRegistered do Azure Virtual Desktop Agent mostra um valor de 0

Causa: token de registo expirou ou foi gerado com prazo de validade de 999999.

Correção: Siga estas instruções para corrigir o erro de registro do agente.

  1. Se já houver um token de registro, remova-o com Remove-RDSRegistrationInfo.
  2. Gere um novo token com o comando Rds-NewRegistrationInfo.
  3. Confirme se o parâmetro -ExpriationHours está definido como 72 (o valor máximo é 99999).

Erro: O agente da Área de Trabalho Virtual do Azure não está relatando uma pulsação ao executar o Get-RdsSessionHost

Causa 1: serviço RDAgentBootLoader foi interrompido.

Fix 1: Inicie o Gerenciador de Tarefas e, se a guia Serviço relatar um status interrompido para o serviço RDAgentBootLoader, inicie o serviço.

Causa 2: porta 443 pode estar fechada.

Fix 2: Siga estas instruções para abrir a porta 443.

  1. Confirme se a porta 443 está aberta baixando a ferramenta PSPing de Sysinternal tools.

  2. Instale o PSPing na VM do host da sessão onde o agente está sendo executado.

  3. Abra o prompt de comando como administrador e emita o comando abaixo:

    psping rdbroker.wvdselfhost.microsoft.com:443
    
  4. Confirme se o PSPing recebeu informações de retorno do RDBroker:

    PsPing v2.10 - PsPing - ping, latency, bandwidth measurement utility
    Copyright (C) 2012-2016 Mark Russinovich
    Sysinternals - www.sysinternals.com
    TCP connect to 13.77.160.237:443:
    5 iterations (warmup 1) ping test:
    Connecting to 13.77.160.237:443 (warmup): from 172.20.17.140:60649: 2.00ms
    Connecting to 13.77.160.237:443: from 172.20.17.140:60650: 3.83ms
    Connecting to 13.77.160.237:443: from 172.20.17.140:60652: 2.21ms
    Connecting to 13.77.160.237:443: from 172.20.17.140:60653: 2.14ms
    Connecting to 13.77.160.237:443: from 172.20.17.140:60654: 2.12ms
    TCP connect statistics for 13.77.160.237:443:
    Sent = 4, Received = 4, Lost = 0 (0% loss),
    Minimum = 2.12ms, Maximum = 3.83ms, Average = 2.58ms
    

Resolução de problemas com a stack paralela da Área de Trabalho Virtual do Azure

A pilha lado a lado da Área de Trabalho Virtual do Azure é instalada automaticamente com o Windows Server 2019 e versões mais recentes. Use o Microsoft Installer (MSI) para instalar a pilha lado a lado no Microsoft Windows Server 2016 ou Windows Server 2012 R2. Para o Microsoft Windows 10, a pilha em paralelo da Área de Trabalho Virtual do Azure está habilitada com enablesxstackrs.ps1.

Há três maneiras principais de a pilha lado a lado ser instalada ou habilitada em VMs do pool de hosts de sessão:

  • Com o Azure Resource Manager Criar e provisionar novo modelo de pool de host da Área de Trabalho Virtual do Azure
  • Ao ser incluído e ativado na imagem principal
  • Instalado ou habilitado manualmente em cada VM (ou com extensões/PowerShell)

Se você estiver tendo problemas com a pilha lado a lado da Área de Trabalho Virtual do Azure, digite o comando qwinsta no prompt de comando para confirmar se a pilha lado a lado está instalada ou habilitada.

A saída de qwinsta irá listar rdp-sxs na saída se a pilha paralela estiver instalada e ativada.

Pilha instalada ou ativada lado a lado com qwinsta listada como rdp-sxs na saída.

Examine as entradas do Registro listadas abaixo e confirme se seus valores correspondem. Se as chaves do Registro estiverem ausentes ou os valores forem incompatíveis, siga as instruções em Criar um pool de hosts com o PowerShell para saber como reinstalar a pilha lado a lado.

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal
    Server\WinStations\rds-sxs\"fEnableWinstation":DWORD=1

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal
    Server\ClusterSettings\"SessionDirectoryListener":rdp-sxs

Erro: O_REVERSE_CONNECT_STACK_FAILURE

O_REVERSE_CONNECT_STACK_FAILURE código de erro.

Causa: A pilha lado a lado não está instalada na VM do host da sessão.

Correção: Siga estas instruções para instalar a pilha lado a lado na VM do host da sessão.

  1. Use o protocolo RDP (Remote Desktop Protocol) para entrar diretamente na VM do host da sessão como administrador local.

  2. Baixe e importe o módulo PowerShell da Área de Trabalho Virtual do Azure para usar na sua sessão do PowerShell, caso ainda não o tenha feito, e execute este cmdlet para entrar na sua conta.

    Add-RdsAccount -DeploymentUrl "https://rdbroker.wvd.microsoft.com"
    
  3. Instale a pilha em paralelo usando Crie um pool de hosts com o PowerShell.

Como corrigir a pilha lado a lado da Área de Trabalho Virtual do Azure que não funciona corretamente

Existem circunstâncias conhecidas que podem causar o mau funcionamento da pilha lado a lado:

  • Não seguir a ordem correta das etapas para ativar a sobreposição lado a lado
  • Atualização automática para o Windows 10 Enhanced Versatile Disc (EVD)
  • Falta a função de Host de Sessão da Área de Trabalho Remota (RDSH)
  • Executando enablesxsstackrc.ps1 várias vezes
  • Executando enablesxsstackrc.ps1 em uma conta que não tem privilégios de administrador local

As instruções nesta seção podem ajudá-lo a desinstalar a pilha lado a lado da Área de Trabalho Virtual do Azure. Depois de desinstalar a pilha lado a lado, vá para "Registrar a VM com o pool de hosts da Área de Trabalho Virtual do Azure" em Criar um pool de hosts com o PowerShell, para reinstalar a pilha lado a lado.

A VM usada para executar a remediação deve estar na mesma sub-rede e domínio que a VM com a pilha paralela com defeito.

Siga estas instruções para executar a correção a partir da mesma sub-rede e domínio:

  1. Conecte-se com o protocolo RDP (Remote Desktop Protocol) padrão à VM de onde a correção será aplicada.

  2. Baixe o PsExec de PsExec v2.40.

  3. Descompacte o arquivo baixado.

  4. Inicie o prompt de comando como administrador local.

  5. Navegue até a pasta onde o PsExec foi descompactado.

  6. No prompt de comando, use o seguinte comando:

            psexec.exe \\<VMname> cmd
    

    Observação

    VMname é o nome da máquina virtual com a pilha de execução paralela com defeito.

  7. Aceite o Contrato de Licença da PsExec clicando em Concordar.

    captura de tela do contrato de licença de software.

    Observação

    Esta caixa de diálogo aparecerá apenas na primeira vez que o PsExec for executado.

  8. Depois de a janela de comandos ser aberta na VM com a pilha "side-by-side" defeituosa, execute qwinsta e confirme se está disponível uma entrada chamada rdp-sxs. Caso contrário, uma pilha lado a lado não estará presente na VM, portanto, o problema não está vinculado a ela.

    prompt de comando do administrador

  9. Corra o seguinte comando, que listará os componentes da Microsoft instalados na VM com a pilha paralela com defeito.

        wmic product get name
    
  10. Execute o comando abaixo com os nomes dos produtos da etapa acima.

        wmic product where name="<Remote Desktop Services Infrastructure Agent>" call uninstall
    
  11. Desinstale todos os produtos que começam com "Área de Trabalho Remota".

  12. Depois que todos os componentes da Área de Trabalho Virtual do Azure tiverem sido desinstalados, siga as instruções para seu sistema operacional:

  13. Se o seu sistema operativo for o Windows Server, reinicie a VM que teve a pilha lado a lado avariada (com o portal do Azure ou a partir da ferramenta PsExec).

Se o seu sistema operativo for o Microsoft Windows 10, continue com as instruções abaixo:

  1. Na VM que executa o PsExec, abra o Explorador de Arquivos e copie disablesxsstackrc.ps1 para a unidade do sistema da VM com a pilha lado a lado com defeito.

        \\<VMname>\c$\
    

    Observação

    VMname é o nome da máquina virtual com uma stack lado a lado que está com defeito.

  2. O processo recomendado: a partir da ferramenta PsExec, inicie o PowerShell e navegue até a pasta da etapa anterior e execute disablesxsstackrc.ps1. Como alternativa, você pode executar os seguintes cmdlets:

    Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\ClusterSettings" -Name "SessionDirectoryListener" -Force
    Remove-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\rdp-sxs" -Recurse -Force
    Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations" -Name "ReverseConnectionListener" -Force
    
  3. Quando a execução dos cmdlets terminar, reinicie a VM com a pilha lado a lado problemática.

O modo de licenciamento de Ambiente de Trabalho Remoto não está configurado

Se iniciar sessão no Windows 10 Enterprise com várias sessões utilizando uma conta administrativa, poderá receber uma notificação a dizer: "O modo de licenciamento de Ambiente de Trabalho Remoto não está configurado, os Serviços de Ambiente de Trabalho Remoto deixarão de funcionar em X dias. No servidor do Agente de Conexão, use o Gerenciador do Servidor para especificar o modo de licenciamento da Área de Trabalho Remota."

Se o limite de tempo expirar, aparecerá uma mensagem de erro que diz: "A sessão remota foi desconectada porque não há licenças de acesso para cliente de Área de Trabalho Remota disponíveis para este computador".

Se vir uma destas mensagens, significa que a imagem não tem as atualizações mais recentes do Windows instaladas ou que está a definir o modo de licenciamento de Ambiente de Trabalho Remoto através da política de grupo. Siga as etapas nas próximas seções para verificar a configuração de política de grupo, identificar a versão do Windows 10 Enterprise com várias sessões e instalar a atualização correspondente.

Observação

A Área de Trabalho Virtual do Azure só requer uma CAL (licença de acesso para cliente) RDS quando seu pool de hosts contém hosts de sessão do Windows Server. Para saber como configurar uma CAL RDS, consulte Licenciar sua implantação do RDS com licenças de acesso para cliente.

Desativar a definição de política de grupo do modo de licenciamento de Ambiente de Trabalho Remoto

Verifique a configuração da política de grupo abrindo o Editor de Políticas de Grupo na VM e navegando até Modelos Administrativos>Componentes do Windows>Serviços de Área de Trabalho Remota>Host de Sessão de Área de Trabalho Remota>Licenciamento>Definir o modo de licenciamento da Área de Trabalho Remota. Se a definição de política de grupo for Ativado, altere-a para Desativado. Se já estiver desativado, deixe-o as-is.

Observação

Se definir a política de grupo através do seu domínio, desative esta definição nas políticas destinadas a estas VMs de várias sessões do Windows 10 Enterprise.

Identificar qual versão do Windows 10 Enterprise multi-sessão você está usando

Para verificar qual versão do Windows 10 Enterprise multi-sessão você tem:

  1. Inicie sessão com a sua conta de administrador.

  2. Digite "Sobre" na barra de pesquisa ao lado do menu Iniciar.

  3. Selecione Acerca do seu PC.

  4. Verifique o número ao lado de "Versão". O número deve ser "1809" ou "1903", como mostra a imagem a seguir.

    Uma captura de tela da janela de especificações do Windows. O número da versão está realçado em azul.

Agora que você já sabe o número da versão, vá para a seção relevante.

Versão 1809

Se o seu número de versão indicar "1809", instale o KB4516077 update.

Versão 1903

Reinstale o sistema operativo do host com a versão mais recente da imagem do Windows 10, versão 1903, da Galeria do Azure.

Não foi possível ligar ao PC remoto devido a um erro de segurança

Se os utilizadores virem um erro que diz: "Não foi possível ligar ao PC remoto devido a um erro de segurança. Se isso continuar acontecendo, peça ajuda ao seu administrador ou suporte técnico", valide todas as políticas existentes que alteram as permissões RDP padrão. Uma política que pode fazer com que esse erro apareça é "Permitir iniciar sessão através da política de segurança dos Serviços de Ambiente de Trabalho Remoto".

Para saber mais sobre esta política, consulte Permitir início de sessão através dos Serviços de Ambiente de Trabalho Remoto.

Próximos passos