Configuração da máquina virtual do host da sessão

  • Artigo

Importante

Este conteúdo se aplica à Área de Trabalho Virtual do Azure com objetos do Azure Resource Manager. Para usar a Área de Trabalho Virtual do Azure (clássica) sem objetos do Azure Resource Manager, consulte este artigo.

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

Fornecer comentários

Visite a Comunidade Tecnológica da Área de Trabalho Virtual do Azure para comentar sobre o serviço da Área de Trabalho Virtual do Azure com a equipe do produto e membros ativos da comunidade.

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

Siga as instruções abaixo caso tenha problemas para associar as máquinas virtuais (VMs) ao domínio.

Erro: Credenciais incorretas

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

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

Erro: Tempo limite de espera para a entrada do usuário

Causa: a conta usada para concluir o ingresso no domínio pode ter uma autenticação multifator (MFA).

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

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

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

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

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

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

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

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

Correção 1: Crie um emparelhamento entre a VNET em que as VMs foram provisionadas e a VNET em que o DC (controlador de domínio) está em execução. Confira Criar um emparelhamento de rede virtual – Resource Manager, assinaturas diferentes.

Causa 2: ao usar o Microsoft Entra Domain Services, a rede virtual não terá suas configurações de servidor DNS atualizadas para apontar para os controladores de domínio gerenciados.

Correção 2: para atualizar as configurações de DNS para a rede virtual que contém o Microsoft Entra Domain Services, confira 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 ações a seguir para resolver, seguindo as etapas em [Alterar servidores DNS].

  • Altere as configurações do servidor DNS da interface de rede para Personalizado com as etapas de Alterar servidores DNS 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 DNS e, em seguida, altere as configurações do servidor DNS da rede virtual com as etapas de Alterar servidores DNS.

O carregador de inicialização e o agente da Área de Trabalho Virtual do Azure não estão instalados

A maneira recomendada para provisionar VMs é usar o modelo de criação do portal do Azure. O modelo instala automaticamente o carregador de inicialização e o agente da Área de Trabalho Virtual do Azure.

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

  1. Confirme se os dois componentes estão instalados, verificando em Painel de Controle>Programas>Programas e Recursos. Caso o Agente da Área de Trabalho Virtual e o Carregador de Inicialização da Área de Trabalho Virtual do Azure não estejam visíveis, isso significa que eles não estão instalados na VM.
  2. Abra o Explorador de Arquivos e navegue até C:\Windows\Temp\ScriptLog.log. Se o arquivo estiver ausente, isso indica que a DSC do PowerShell que instalou os dois componentes não pôde ser executada 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 carregador de inicialização e o agente da Área de Trabalho Virtual do Azure estão ausentes. C:\Windows\Temp\ScriptLog.log também está ausente.

Causa 1: As 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 host com o PowerShell.

Causa 2: o DSC do PowerShell conseguiu ser iniciado e executado, mas falhou na conclusão, pois não conseguiu se conectar à Área de Trabalho Virtual do Azure e obter as informações necessárias.

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

  • Verifique se a conta não tem MFA.
  • Confirme se o nome do pool de hosts está correto e se ele existe na Área de Trabalho Virtual do Azure.
  • Confirme se a conta tem, no mínimo, permissões de Colaborador na assinatura ou no grupo de recursos do Azure.

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

Causa: o DSC do PowerShell conseguiu ser executado, mas não se conectou à Área de Trabalho Virtual do Azure.

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

  • Registre manualmente as VMs no serviço da Área de Trabalho Virtual do Azure.
  • Confirme se a conta usada para a conexão com a Área de Trabalho Virtual do Azure tem permissões no grupo de recursos ou na assinatura do Azure para criar pools de hosts.
  • Confirme se a conta não tem MFA.

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

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

Erro: O status registrado no cmdlet Get-AzWvdSessionHost é exibido como indisponível

Get-AzWvdSessionHost cmdlet shows status as Unavailable.

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

Correção: Siga as instruções abaixo 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, interrompa o serviço RDAgentBootLoader.
  3. Execute o instalador da nova versão do Agente da Área de Trabalho Virtual do Azure.
  4. Quando o token de registro for solicitado, remova a entrada INVALID_TOKEN e pressione Avançar (um novo token não é necessário).
  5. Conclua o assistente de instalação.
  6. Abra o Gerenciador de Tarefas e inicie o serviço RDAgentBootLoader.

Erro: a entrada de registro IsRegistered do Agente da Área de Trabalho Virtual do Azure mostra um valor de 0

Causa: O token de registro expirou.

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

  1. Se já houver um token de registro, remova-o com Remove-AzWvdRegistrationInfo.
  2. Execute o cmdlet New-AzWvdRegistrationInfo para gerar um novo token.
  3. Confirme se o parâmetro -ExpriationTime está definido como três dias.

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

Causa 1: O serviço RDAgentBootLoader foi interrompido.

Correção 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: A porta 443 pode estar fechada.

Correção 2: Siga as instruções abaixo para abrir a porta 443.

  1. Confirme se a porta 443 está aberta, baixando a ferramenta PSPing em Ferramentas do Sysinternal.

  2. Instale o PSPing na VM do host da sessão em que o agente está em execução.

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

    psping rdbroker.wvdselfhost.microsoft.com:443

  4. Confirme se o PSPing recebeu informações de volta 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

Solucionando problemas da pilha lado a lado da Área de Trabalho Virtual do Azure

Há três maneiras principais pelas quais a pilha lado a lado é instalada ou habilitada nas VMs do pool de host da sessão:

  • Com o modelo de criação do portal do Azure
  • Ao ser incluída e habilitada na imagem mestra
  • Instalada ou habilitada manualmente em cada VM (ou com extensões/PowerShell)

Em caso de 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 ela está instalada ou habilitada.

A saída de qwinsta listará o rdp-sxs na saída se a pilha lado a lado estiver instalada e habilitada.

Side-by-side stack installed or enabled with qwinsta listed as rdp-sxs in the output.

Analise as entradas de registro listadas abaixo e confirme se os seus valores correspondem. Se as chaves do registro estiverem ausentes ou os valores forem incompatíveis, verifique se você está executando um sistema operacional compatível. Se estiver, siga as instruções em Registrar hosts da sessão em um pool de host 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 error code.

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

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

  1. Use o Protocolo de Área de Trabalho Remota (RDP) para entrar diretamente na VM do host da sessão como administrador local.
  2. Instale a pilha lado a lado seguindo as etapas para Registrar hosts da sessão em um pool de host.

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

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

  • Não seguir a ordem correta das etapas para habilitar a pilha lado a lado
  • Atualizar automaticamente para o Enhanced Versatile Disc (EVD) do Windows 10.
  • A função de Host da Sessão da Área de Trabalho Remota (RDSH) está ausente.

As instruções nesta seção podem ajudar você a desinstalar a pilha lado a lado da Área de Trabalho Virtual do Azure. Depois de desinstalar a pilha lado a lado, siga as etapas para Registrar os hosts da sessão em um pool de host para reinstalar a pilha lado a lado.

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

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

  1. Conecte-se à VM de onde a correção será aplicada com o Protocolo de Área de Trabalho Remota (RDP).

  2. Baixe e instale o PsExec.

  3. Inicie o prompt de comando como administrador local e navegue até a pasta em que PsExec foi descompactado.

  4. No prompt de comando, use o comando a seguir, em que <VMname> é o nome do nome do host da VM com a pilha lado a lado com mau funcionamento. Se essa for a primeira vez que você executar o PsExec, também precisará aceitar o Contrato de Licença PsExec para continuar, clicando em Concordar.

    psexec.exe \\<VMname> cmd

  5. Depois que a sessão de prompt de comando for aberta na VM com a pilha lado a lado com defeito, execute o seguinte comando e confirme se uma entrada chamada rdp-sxs está disponível. Caso contrário, uma pilha lado a lado não estará presente na VM, portanto, o problema não está vinculado à pilha lado a lado.

    qwinsta

    Administrator command prompt

  6. Execute o comando a seguir, que listará os componentes da Microsoft instalados na VM com a pilha lado a lado com defeito.

    wmic product get name

  7. Execute o comando abaixo com os nomes de produtos da etapa acima, por exemplo:

    wmic product where name="<Remote Desktop Services Infrastructure Agent>" call uninstall

  8. Desinstale todos os produtos que são iniciados com a Área de Trabalho Remota.

  9. Depois que todos os componentes da Área de Trabalho Virtual do Azure tiverem sido desinstalados, reinicie a VM que tinha a pilha lado a lado com mau funcionamento (com o portal do Azure ou com a ferramenta PsExec). Você pode então reinstalar a pilha lado a lado seguindo as etapas para Registrar hosts da sessão em um pool de host.

O modo de licenciamento da Área de Trabalho Remota não está configurado

Se você entrar na multissessão do Windows 10 Enterprise usando uma conta administrativa, poderá receber esta notificação: "O modo de licenciamento da Área de Trabalho Remota não está configurado, os Serviços da Área de Trabalho Remota 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, a seguinte mensagem de erro será exibida: "A sessão remota foi desconectada porque não há licenças de acesso de cliente da Área de Trabalho Remota disponíveis para este computador."

Se você vir uma dessas mensagens, isso significa que a imagem não tem as atualizações mais recentes do Windows instaladas ou que você está configurando o modo de licenciamento da Área de Trabalho Remota por meio da política de grupo. Siga as etapas nas próximas seções para verificar a configuração da política de grupo, identificar a versão da multissessão do Windows 10 Enterprise e instalar a atualização correspondente.

Observação

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

Desabilitar a configuração da política de grupo do modo de licenciamento da Área de Trabalho Remota

Verifique a configuração da política de grupo, abrindo o Editor de Política de Grupo na VM e acessando Modelos Administrativos>Componentes do Windows>Serviços da Área de Trabalho Remota>Host da Sessão da Área de Trabalho Remota>Licenciamento>Definir o modo de licenciamento da Área de Trabalho Remota. Se a configuração da política de grupo estiver Habilitada, altere-a para Desabilitada. Se já estiver desabilitada, deixe-a como está.

Observação

Se você definir a política de grupo por meio do seu domínio, desabilite essa configuração nas políticas relacionadas a essas VMs de multissessão do Windows 10 Enterprise.

Identifique qual versão da multissessão do Windows 10 Enterprise você está usando.

Para verificar qual versão da multissessão do Windows 10 Enterprise você tem:

  1. Conecte-se usando sua conta de administrador.

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

  3. Selecione Sobre o computador.

  4. Verifique o número ao lado de "versão". O número deve ser "1809" ou "1903", conforme mostrado na imagem a seguir.

    A screenshot of the Windows specifications window. The version number is highlighted in blue.

Agora que você sabe o número da sua versão, pule para a seção relevante.

Versão 1809

Se o número da sua versão for "1809", instale a atualização KB4516077.

Versão 1903

Implante novamente o sistema operacional do host com a versão mais recente do Windows 10; imagem da versão 1903 do Azure Gallery.

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

Se seus usuários virem o erro "Não foi possível conectar-se ao PC remoto devido a um erro de segurança. Se isso continuar acontecendo, solicite ajuda ao seu administrador ou suporte técnico", valide todas as políticas existentes que alteram as permissões padrão do RDP. Uma política que pode causar esse erro é "Permitir logon por meio da política de segurança dos Serviços da Área de Trabalho Remota".

Para saber mais sobre essa política, confira Permitir logon por meio de Serviços da Área de Trabalho Remota.

Não consigo implantar a imagem dourada

As imagens douradas não podem incluir o agente da Área de Trabalho Virtual do Azure. Você só pode instalar o agente depois de implantar a imagem dourada.

Próximas etapas