Configuração da máquina virtual de host da sessão da Área de Trabalho Virtual do Azure (clássico)

Importante

Este conteúdo se aplica à Área de Trabalho Virtual do Azure (clássica), que não dá suporte a objetos do Azure Resource Manager na Área de Trabalho Virtual do Azure. Se você estiver tentando gerenciar objetos do Azure Resource Manager na Área de Trabalho Virtual do Azure, confira 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 Tech Community da Área de Trabalho Virtual do Azure para discutir sobre o serviço Á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 você estiver tendo 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 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 de provisionar VMs é usando o modelo Criar e provisionar um pool de host da Área de Trabalho Virtual do Azure do Azure Resource Manager. 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 do Azure 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 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 de RDS.

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 conexão com a Área de Trabalho Virtual do Azure tem permissões no locatário 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 aplicáveis ao Agente da Área de Trabalho Virtual do Azure e ao token.

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

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

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 ou foi gerado com o valor de expiração 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 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 Get-RdsSessionHost

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

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

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 Criar e provisionar um pool de host da Área de Trabalho Virtual do Azure do Azure Resource Manager
  • 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.

Pilha lado a lado instalada ou habilitada com qwinsta, listado como rdp-sxs na saída.

Examine as entradas de registro listadas abaixo e confirme se os seus valores correspondem. Se as chaves do registro estiverem ausentes ou se os valores forem incompatíveis, siga as instruções em Criar um pool de host com o PowerShell sobre 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

Código de erro O_REVERSE_CONNECT_STACK_FAILURE.

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. Baixe e importe o módulo do PowerShell da Área de Trabalho Virtual do Azure para usá-lo na sessão do PowerShell, caso ainda não tenha feito isso, e execute este cmdlet para entrar na conta:

    Add-RdsAccount -DeploymentUrl "https://rdbroker.wvd.microsoft.com"
    
  3. Instale a pilha lado a lado usando Criar um pool de host com o PowerShell.

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.
  • Executar o enablesxsstackrc.ps1 várias vezes
  • Executar o enabledxsstackrc.ps1 em uma conta que não tem privilégios de administrador local

As instruções nesta seção podem ajudar você a desinstalar a pilha lado a lado da Área de Trabalho Virtual do Azure. Depois da desinstalação, acesse "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 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 PsExec do PsExec v2.40.

  3. Descompacte o arquivo baixado.

  4. Inicie o prompt de comando como administrador local.

  5. Navegue até a pasta em que o PsExec foi descompactado.

  6. No prompt de comando, utilize o comando a seguir:

            psexec.exe \\<VMname> cmd
    

    Observação

    VMname é o nome do computador da VM com a pilha lado a lado com defeito.

  7. Aceite o Contrato de Licença do PsExec, clicando em Concordo.

    Captura de tela do Contrato de Licença de software.

    Observação

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

  8. Depois que a sessão de prompt de comando for aberta na VM com a pilha lado a lado com defeito, execute o qwinsta 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.

    Prompt de comando do administrador

  9. 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
    
  10. Execute o comando abaixo com os nomes de produtos da etapa acima.

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

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

  13. Se o seu sistema operacional for o Windows Server, reinicie a VM que tinha a pilha lado a lado com defeito (seja pelo portal do Azure ou pela ferramenta PsExec).

Se o seu sistema operacional 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 do computador da VM com a pilha lado a lado com defeito.

  2. O processo recomendado: na ferramenta PsExec, inicie o PowerShell e navegue até a pasta da etapa anterior, em seguida, 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 os cmdlets forem executados, reinicie a VM com a pilha lado a lado com defeito.

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.

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

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.

Próximas etapas