Pré-requisitos para a Área de Trabalho Virtual do Azure

Há algumas coisas que você precisa para começar a usar a Área de Trabalho Virtual do Azure. Aqui você pode encontrar quais pré-requisitos você precisa preencher para fornecer com sucesso aos seus usuários desktops e aplicativos.

Em um alto nível, você precisa:

  • Uma conta do Azure com uma subscrição ativa
  • Um provedor de identidade suportado
  • Um sistema operacional suportado para máquinas virtuais de host de sessão
  • Licenças apropriadas
  • Conectividade de rede
  • Um cliente de Área de Trabalho Remota

Conta do Azure com uma subscrição ativa

Você precisa de uma conta do Azure com uma assinatura ativa para implantar a Área de Trabalho Virtual do Azure. Se ainda não tiver uma, pode criar uma conta gratuitamente.

Para implantar a Área de Trabalho Virtual do Azure, você precisa atribuir as funções relevantes de controle de acesso baseado em função (RBAC) do Azure. Os requisitos de função específicos são abordados em cada um dos artigos relacionados à implantação da Área de Trabalho Virtual do Azure, listados na seção Próximas etapas .

Certifique-se também de que registou o fornecedor de recursos Microsoft.DesktopVirtualization para a sua subscrição. Para verificar o status do provedor de recursos e registrar-se, se necessário, selecione a guia relevante para seu cenário e siga as etapas.

Importante

Você deve ter permissão para registrar um provedor de recursos, o que requer a */register/action operação. Isso será incluído se a sua conta receber a função de colaborador ou proprietário na sua assinatura.

  1. Inicie sessão no portal do Azure.

  2. Selecione Subscrições.

  3. Selecione o nome da sua subscrição.

  4. Selecione Fornecedores de recursos.

  5. Procure Microsoft.DesktopVirtualization.

  6. Se o status for NotRegistered, selecione Microsoft.DesktopVirtualization e, em seguida, selecione Register.

  7. Verifique se o status de Microsoft.DesktopVirtualization está registrado.

Identidade

Para acessar áreas de trabalho e aplicativos de seus hosts de sessão, seus usuários precisam ser capazes de autenticar. O Microsoft Entra ID é o serviço centralizado de identidade na nuvem da Microsoft que permite esse recurso. A ID do Microsoft Entra é sempre usada para autenticar usuários para a Área de Trabalho Virtual do Azure. Os hosts de sessão podem ser associados ao mesmo locatário do Microsoft Entra ou a um domínio do Ative Directory usando os Serviços de Domínio Ative Directory (AD DS) ou os Serviços de Domínio Microsoft Entra, oferecendo opções de configuração flexíveis.

Anfitriões de sessão

Você precisa ingressar em hosts de sessão que fornecem áreas de trabalho e aplicativos para o mesmo locatário do Microsoft Entra que seus usuários ou um domínio do Ative Directory (AD DS ou Serviços de Domínio Microsoft Entra).

Nota

Para o Azure Stack HCI, você só pode ingressar hosts de sessão em um domínio dos Serviços de Domínio Ative Directory.

Para associar anfitriões de sessão ao Microsoft Entra ID ou a um domínio do Ative Directory, necessita das seguintes permissões:

  • Para o Microsoft Entra ID, precisa de uma conta que possa associar computadores ao seu inquilino. Para obter mais informações, consulte Gerenciar identidades de dispositivos. Para saber mais sobre como ingressar hosts de sessão na ID do Microsoft Entra, consulte Hosts de sessão ingressados no Microsoft Entra.

  • Para um domínio do Ative Directory, você precisa de uma conta de domínio que possa associar computadores ao seu domínio. Para os Serviços de Domínio Microsoft Entra, você precisa ser membro do grupo Administradores de DC do AAD.

Utilizadores

Seus usuários precisam de contas que estejam na ID do Microsoft Entra. Se você também estiver usando o AD DS ou os Serviços de Domínio Microsoft Entra em sua implantação da Área de Trabalho Virtual do Azure, essas contas precisam ser identidades híbridas, o que significa que as contas de usuário estão sincronizadas. Você precisa ter as seguintes coisas em mente com base em qual provedor de identidade você usa:

  • Se você estiver usando o Microsoft Entra ID com o AD DS, precisará configurar o Microsoft Entra Connect para sincronizar os dados de identidade do usuário entre o AD DS e o Microsoft Entra ID.
  • Se você estiver usando a ID do Microsoft Entra com os Serviços de Domínio do Microsoft Entra, as contas de usuário serão sincronizadas de uma maneira da ID do Microsoft Entra para os Serviços de Domínio do Microsoft Entra. Este processo de sincronização é automático.

Importante

A conta de usuário deve existir no locatário do Microsoft Entra que você usa para a Área de Trabalho Virtual do Azure. O Ambiente de Trabalho Virtual do Azure não suporta contas B2B, B2C ou pessoais da Microsoft.

Ao usar identidades híbridas, o UserPrincipalName (UPN) ou o Security Identifier (SID) devem corresponder entre os Serviços de Domínio Ative Directory e o Microsoft Entra ID. Para obter mais informações, consulte Identidades e métodos de autenticação suportados.

Cenários de identidade suportados

A tabela a seguir resume os cenários de identidade que a Área de Trabalho Virtual do Azure suporta atualmente:

Cenário de identidade Anfitriões de sessão Contas de utilizador
Microsoft Entra ID + AD DS Ingressou no AD DS No Microsoft Entra ID e AD DS, sincronizado
Microsoft Entra ID + AD DS Aderiu ao Microsoft Entra ID No Microsoft Entra ID e AD DS, sincronizado
Microsoft Entra ID + Serviços de Domínio Microsoft Entra Ingressou nos Serviços de Domínio do Microsoft Entra Nos Serviços de Domínio Microsoft Entra ID e Microsoft Entra, sincronizados
Microsoft Entra ID + Serviços de Domínio Microsoft Entra + AD DS Ingressou nos Serviços de Domínio do Microsoft Entra No Microsoft Entra ID e AD DS, sincronizado
Microsoft Entra ID + Serviços de Domínio Microsoft Entra Aderiu ao Microsoft Entra ID Nos Serviços de Domínio Microsoft Entra ID e Microsoft Entra, sincronizados
Microsoft Entra-only Aderiu ao Microsoft Entra ID No Microsoft Entra ID

Para obter informações mais detalhadas sobre cenários de identidade suportados, incluindo logon único e autenticação multifator, consulte Identidades e métodos de autenticação suportados.

Contêiner de perfil FSLogix

Para usar o Contêiner de Perfil FSLogix ao ingressar seus hosts de sessão na ID do Microsoft Entra, você precisa armazenar perfis nos Arquivos do Azure ou nos Arquivos NetApp do Azure e suas contas de usuário devem ser identidades híbridas. Você deve criar essas contas no AD DS e sincronizá-las com a ID do Microsoft Entra. Para saber mais sobre como implantar o FSLogix Profile Container com diferentes cenários de identidade, consulte os seguintes artigos:

Parâmetros de implantação

Você precisa inserir os seguintes parâmetros de identidade ao implantar hosts de sessão:

  • Nome de domínio, se estiver usando AD DS ou Serviços de Domínio Microsoft Entra.
  • Credenciais para associar anfitriões de sessão ao domínio.
  • Unidade organizacional (UO), que é um parâmetro opcional que permite colocar hosts de sessão na UO desejada no momento da implantação.

Importante

A conta que você usa para ingressar em um domínio não pode ter a autenticação multifator (MFA) habilitada.

Sistemas operacionais e licenças

Você tem uma escolha de sistemas operacionais (SO) que você pode usar para hosts de sessão para fornecer desktops e aplicativos. Você pode usar diferentes sistemas operacionais com diferentes pools de hosts para fornecer flexibilidade aos seus usuários. Suportamos os sistemas operativos de 64 bits e SKUs nas seguintes listas de tabelas (onde as versões e datas suportadas estão em linha com a Política de Ciclo de Vida da Microsoft), juntamente com os métodos de licenciamento aplicáveis para cada finalidade comercial:

Sistema operativo
(Apenas 64 bits)
Método de licenciamento
(Fins comerciais internos)
Método de licenciamento
(Fins comerciais externos)
  • Microsoft 365 E3, E5, A3, A5, F3, Business Premium, Benefício de Uso Estudantil
  • Windows Enterprise E3, E5
  • Windows Educação A3, A5
  • Windows VDA por usuário
  • Preços de acesso por usuário registrando uma assinatura do Azure.
  • Licença de Acesso para Cliente (CAL) dos Serviços de Área de Trabalho Remota (RDS) com Software Assurance (por usuário ou por dispositivo)
  • Licenças de Subscrição de Utilizador do RDS.
  • Licença de Acesso de Assinante (SAL) do Windows Server 2022 RDS.

Os preços de acesso por usuário não estão disponíveis para sistemas operacionais Windows Server.

Para saber mais sobre as licenças que pode utilizar, incluindo os preços de acesso por utilizador, consulte Licenciamento do Ambiente de Trabalho Virtual do Azure.

Importante

Para o Azure, você pode usar imagens do sistema operacional fornecidas pela Microsoft no Azure Marketplace ou criar suas próprias imagens personalizadas armazenadas em uma Galeria de Computação do Azure ou como uma imagem gerenciada. O uso de modelos de imagem personalizados para a Área de Trabalho Virtual do Azure permite que você crie facilmente uma imagem personalizada que pode ser usada ao implantar máquinas virtuais (VMs) de host de sessão. Para saber mais sobre como criar imagens personalizadas, consulte:

Como alternativa, para o Azure Stack HCI, você pode usar imagens do sistema operacional de:

Você pode implantar máquinas virtuais (VMs) para serem usadas como hosts de sessão a partir dessas imagens com qualquer um dos seguintes métodos:

Se a sua licença lhe permitir utilizar o Ambiente de Trabalho Virtual do Azure, não precisa de instalar ou aplicar uma licença separada, no entanto, se estiver a utilizar preços de acesso por utilizador para utilizadores externos, tem de inscrever uma Subscrição do Azure. Você precisa verificar se a licença do Windows usada em seus hosts de sessão está atribuída corretamente no Azure e se o sistema operacional está ativado. Para obter mais informações, consulte Aplicar licença do Windows a máquinas virtuais de host de sessão.

Para hosts de sessão no Azure Stack HCI, você deve licenciar e ativar as máquinas virtuais usadas antes de usá-las com a Área de Trabalho Virtual do Azure. Para ativar o Windows 10 e o Windows 11 Enterprise com várias sessões e o Windows Server 2022 Datacenter: Azure Edition, use a verificação do Azure para VMs. Para todas as outras imagens do sistema operacional (como Windows 10 e Windows 11 Enterprise e outras edições do Windows Server), você deve continuar a usar os métodos de ativação existentes. Para obter mais informações, consulte Ativar VMs do Windows Server no Azure Stack HCI.

Nota

Para garantir a funcionalidade contínua com a atualização de segurança mais recente, atualize suas VMs no Azure Stack HCI para a atualização cumulativa mais recente até 17 de junho de 2024. Essa atualização é essencial para que as VMs continuem usando os benefícios do Azure. Para obter mais informações, consulte Verificação do Azure para VMs.

Gorjeta

Para simplificar os direitos de acesso do usuário durante o desenvolvimento e teste iniciais, a Área de Trabalho Virtual do Azure dá suporte aos preços de Desenvolvimento/Teste do Azure. Se você implantar a Área de Trabalho Virtual do Azure em uma assinatura de Desenvolvimento/Teste do Azure, os usuários finais poderão se conectar a essa implantação sem direito de licença separado para executar testes de aceitação ou fornecer comentários.

Rede

Há vários requisitos de rede que você precisa atender para implantar com êxito a Área de Trabalho Virtual do Azure. Isso permite que os usuários se conectem a seus desktops e aplicativos, ao mesmo tempo em que oferece a melhor experiência de usuário possível.

Os usuários que se conectam à Área de Trabalho Virtual do Azure estabelecem com segurança uma conexão reversa com o serviço, o que significa que você não precisa abrir nenhuma porta de entrada. O protocolo TCP (Transmission Control Protocol) na porta 443 é usado por padrão, no entanto, o RDP Shortpath pode ser usado para redes gerenciadas e redes públicas que estabelecem um transporte direto baseado em UDP (User Datagram Protocol).

Para implantar com êxito a Área de Trabalho Virtual do Azure, você precisa atender aos seguintes requisitos de rede:

  • Você precisa de uma rede virtual e sub-rede para seus hosts de sessão. Se você criar seus hosts de sessão ao mesmo tempo que um pool de hosts, deverá criar essa rede virtual com antecedência para que ela apareça na lista suspensa. Sua rede virtual deve estar na mesma região do Azure que o host da sessão.

  • Verifique se essa rede virtual pode se conectar aos controladores de domínio e servidores DNS relevantes se você estiver usando o AD DS ou os Serviços de Domínio Microsoft Entra, já que você precisa ingressar hosts de sessão no domínio.

  • Seus hosts de sessão e usuários precisam ser capazes de se conectar ao serviço de Área de Trabalho Virtual do Azure. Essas conexões também usam TCP na porta 443 para uma lista específica de URLs. Para obter mais informações, consulte Lista de URL necessária. Você deve certificar-se de que essas URLs não estão bloqueadas pela filtragem de rede ou por um firewall para que sua implantação funcione corretamente e tenha suporte. Se os usuários precisarem acessar o Microsoft 365, verifique se os hosts de sessão podem se conectar aos pontos de extremidade do Microsoft 365.

Além disso, considere o seguinte:

  • Seus usuários podem precisar de acesso a aplicativos e dados hospedados em redes diferentes, portanto, certifique-se de que seus hosts de sessão possam se conectar a eles.

  • A latência de tempo de ida e volta (RTT) da rede do cliente para a região do Azure que contém os pools de hosts deve ser inferior a 150 ms. Use o Estimador de Experiência para exibir a integridade da conexão e a região recomendada do Azure. Para otimizar o desempenho da rede, recomendamos que você crie hosts de sessão na região do Azure mais próxima de seus usuários.

  • Use o Firewall do Azure para implantações de Área de Trabalho Virtual do Azure para ajudá-lo a bloquear seu ambiente e filtrar o tráfego de saída.

  • Para ajudar a proteger seu ambiente de Área de Trabalho Virtual do Azure no Azure, recomendamos que você não abra a porta de entrada 3389 em seus hosts de sessão. A Área de Trabalho Virtual do Azure não requer que uma porta de entrada aberta esteja aberta. Se você precisar abrir a porta 3389 para fins de solução de problemas, recomendamos usar o acesso just-in-time à VM. Também recomendamos que não atribua um endereço IP público aos seus anfitriões de sessão.

Para saber mais, consulte Noções básicas sobre a conectividade de rede da Área de Trabalho Virtual do Azure.

Nota

Para manter a Área de Trabalho Virtual do Azure confiável e escalável, agregamos padrões de tráfego e uso para verificar a integridade e o desempenho do plano de controle de infraestrutura. Agregamos essas informações de todos os locais onde está a infraestrutura de serviço e, em seguida, enviamos para a região dos EUA. Os dados enviados para a região dos EUA incluem dados apagados, mas não dados de clientes. Para obter mais informações, consulte Locais de dados para a Área de Trabalho Virtual do Azure.

Gerenciamento de host de sessão

Considere os seguintes pontos ao gerenciar hosts de sessão:

  • Não habilite nenhuma política ou configuração que desabilite o Windows Installer. Se você desabilitar o Windows Installer, o serviço não poderá instalar atualizações de agente em seus hosts de sessão e seus hosts de sessão não funcionarão corretamente.

  • Se você estiver ingressando hosts de sessão em um domínio do AD DS e quiser gerenciá-los usando o Intune, precisará configurar o Microsoft Entra Connect para habilitar a associação híbrida do Microsoft Entra.

  • Se você estiver ingressando hosts de sessão em um domínio dos Serviços de Domínio Microsoft Entra, não poderá gerenciá-los usando o Intune.

  • Se você estiver usando o Microsoft Entra ingressar com o Windows Server para seus hosts de sessão, não poderá inscrevê-los no Intune, pois o Windows Server não é compatível com o Intune. Você precisa usar a associação híbrida do Microsoft Entra e a Diretiva de Grupo de um domínio do Ative Directory ou a Diretiva de Grupo local em cada host de sessão.

Regiões do Azure

Você pode implantar pools de hosts, espaços de trabalho e grupos de aplicativos nas seguintes regiões do Azure. Esta lista de regiões é onde os metadados do pool de hosts podem ser armazenados. No entanto, os hosts de sessão para as sessões de usuário podem estar localizados em qualquer região do Azure e no local ao usar a Área de Trabalho Virtual do Azure no Azure Stack HCI, permitindo que você implante recursos de computação próximos aos seus usuários. Para obter mais informações sobre os tipos de dados e locais, consulte Locais de dados para a Área de Trabalho Virtual do Azure.

  • Leste da Austrália
  • Canadá Central
  • Leste do Canadá
  • Índia Central
  • E.U.A. Central
  • E.U.A. Leste
  • E.U.A. Leste 2
  • Leste do Japão
  • E.U.A. Centro-Norte
  • Europa do Norte
  • E.U.A. Centro-Sul
  • Sul do Reino Unido
  • Oeste do Reino Unido
  • E.U.A. Centro-Oeste
  • Europa Ocidental
  • E.U.A. Oeste
  • E.U.A. Oeste 2
  • EUA Oeste 3

O Azure Virtual Desktop também está disponível em nuvens soberanas, como o Azure para o Governo dos EUA e o Azure operado pela 21Vianet na China.

Para saber mais sobre a arquitetura e a resiliência do serviço de Área de Trabalho Virtual do Azure, consulte Arquitetura e resiliência do serviço de Área de Trabalho Virtual do Azure.

Clientes de Ambiente de Trabalho Remoto

Seus usuários precisam de um cliente de Área de Trabalho Remota para se conectar a áreas de trabalho e aplicativos. Os seguintes clientes dão suporte à Área de Trabalho Virtual do Azure:

Importante

A Área de Trabalho Virtual do Azure não oferece suporte a conexões do cliente Conexões de RemoteApp e Área de Trabalho (RADC) ou do cliente MSTSC (Conexão de Área de Trabalho Remota).

Para saber quais URLs os clientes usam para se conectar e que você deve permitir por meio de firewalls e filtros da Internet, consulte a lista URL necessária.

Próximos passos