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 os pré-requisitos necessários para fornecer áreas de trabalho e aplicativos aos seus usuários com sucesso.

Em um alto nível, você vai precisar:

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

Conta do Azure com uma assinatura ativa

Você precisará de uma conta do Azure com uma assinatura ativa para implantar a Área de Trabalho Virtual do Azure. Se você ainda não tem uma conta, é possível criar uma conta gratuita.

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

Certifique-se também de que você registrou o provedor de recursos Microsoft.DesktopVirtualization para sua assinatura. Para verificar o status do provedor de recursos e se registrar, 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 operação */register/action. Ela estará incluída se você tiver atribuído a função de colaborador ou proprietário à sua assinatura.

  1. Entre no portal do Azure.

  2. Selecione Assinaturas.

  3. Selecione o nome da sua assinatura.

  4. Selecione Provedores de recursos.

  5. Pesquisar por Microsoft.DesktopVirtualization.

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

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

Identidade

Para acessar áreas de trabalho e aplicativos de seus hosts de sessão, os usuários precisam ser capazes de se autenticar. O Microsoft Entra ID é o serviço de identidade de nuvem centralizado da Microsoft que habilita essa capacidade. O Microsoft Entra ID é sempre usado para autenticar usuários para a Área de Trabalho Virtual do Azure. Os hosts da sessão podem ser ingressados no mesmo locatário do Microsoft Entra ou em um domínio do Active Directory usando o AD DS (Active Directory Domain Services) ou o Microsoft Entra Domain Services, fornecendo opções de configuração flexíveis.

Hosts de sessão

É necessário ingressar hosts da sessão que fornecem desktops e aplicativos para o mesmo locatário do Microsoft Entra que seus usuários ou um domínio do Active Directory (AD DS ou Microsoft Entra Domain Services).

Observação

Para o Azure Stack HCI, você só pode ingressar hosts de sessão em um domínio do Active Directory Domain Services.

Para ingressar hosts da sessão no Microsoft Entra ID ou um domínio do Active Directory, você precisa das seguintes permissões:

Usuários

Seus usuários precisam de contas que estejam no Microsoft Entra ID. Se você também estiver usando o AD DS ou o Microsoft Entra Domain Services na sua implantação da Área de Trabalho Virtual do Azure, essas contas precisarão ser identidades híbridas, o que significa que as contas de usuário serão sincronizadas. Você precisa ter em mente o seguinte, com base no provedor de identidade usado:

  • Se você estiver usando o Microsoft Entra ID com o AD DS, configure o Microsoft Entra Connect para sincronizar dados de identidade do usuário entre o AD DS e o Microsoft Entra ID.
  • Se você estiver usando o Microsoft Entra ID com o Microsoft Entra Domain Services, as contas de usuário serão sincronizadas unidirecionalmente do Microsoft Entra ID para o Microsoft Entra Domain Services. Esse 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. A Área de Trabalho Virtual do Azure não dá suporte a contas B2B, B2C ou pessoais da Microsoft.

Ao usar identidades híbridas, o UPN (UserPrincipalName) ou o SID (identificador de segurança) devem corresponder entre o Active Directory Domain Services e o Microsoft Entra ID. Para obter mais informações, consulte Métodos de autenticação e identidades com suporte.

Cenários de identidade com suporte

A tabela a seguir resume os cenários de identidade aos quais a Área de Trabalho Virtual do Azure dá suporte atualmente:

Cenário de identidade Hosts de sessão Contas de usuário
Microsoft Entra ID + AD DS Ingressado em AD DS No Microsoft Entra ID e no AD DS, sincronizado
Microsoft Entra ID + AD DS Ingressado no Microsoft Entra ID No Microsoft Entra ID e no AD DS, sincronizado
Microsoft Entra ID + Microsoft Entra Domain Services Ingressado no Microsoft Entra Domain Services No Microsoft Entra ID e no Microsoft Entra Domain Services, sincronizado
Microsoft Entra ID + Microsoft Entra Domain Services + AD DS Ingressado no Microsoft Entra Domain Services No Microsoft Entra ID e no AD DS, sincronizado
Microsoft Entra ID + Microsoft Entra Domain Services Ingressado no Microsoft Entra ID No Microsoft Entra ID e no Microsoft Entra Domain Services, sincronizado
Somente Microsoft Entra Ingressado no Microsoft Entra ID No Microsoft Entra ID

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

Contêiner de perfil FSLogix

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

Parâmetros de implantação

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

  • Nome de domínio, se estiver usando o AD DS ou o Microsoft Entra Domain Services.
  • Credenciais para unir hosts de sessão ao domínio.
  • A UO (Unidade organizacional), que é um parâmetro opcional que permite que você coloque os hosts de sessão na UO desejada no momento da implantação.

Importante

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

Licenças e sistemas operacionais

Você tem a opção de sistemas operacionais (SOs) que pode usar para hosts de sessão para fornecer áreas de trabalho e aplicativos. É possível usar diferentes sistemas operacionais com pools de hosts diferentes para fornecer flexibilidade aos seus usuários. Damos suporte a SKUs e sistemas operacionais de 64 bits nas seguintes listas de tabelas (em que as datas e versões compatíveis estão embutidas com a Política de Ciclo de Vida da Microsoft), juntamente com os métodos de licenciamento aplicáveis para cada finalidade comercial:

Sistema operacional
(somente 64 bits)
Método de licenciamento
(Finalidades comerciais internas)
Método de licenciamento
(Finalidades comerciais externas)
  • Microsoft 365 E3, E5, A3, A5, F3, Business Premium, Benefício de uso do aluno
  • Windows Enterprise E3, E5
  • Windows Azure para Educação A3, A5
  • VDA do Windows por usuário
  • A CAL (Licença de Acesso de Cliente) do RDS (Serviços de Área de Trabalho Remota) com o Software Assurance (por usuário ou por dispositivo)
  • Licenças de assinatura de usuário do RDS.
  • SAL (Licença de Acesso de Assinante) do RDS do Windows Server 2022.

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

Para saber mais sobre licenças que você pode usar, incluindo preços de acesso por usuário, consulte Área de Trabalho Virtual do Azure de Licenciamento.

Importante

No caso do Azure, você pode usar as 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. Usar os modelos de imagens personalizadas na Á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 da sessão. Para saber mais sobre como criar imagens personalizadas, consulte:

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

É possível e implantar VMs (máquinas virtuais) para serem usadas como hosts de sessão dessas imagens com qualquer um dos seguintes métodos:

Caso a sua licença conceda o direito de usar a Área de Trabalho Virtual do Azure, não é preciso instalar ou aplicar uma licença separada. Porém, se você estiver usando o preço de acesso por usuário para usuários externos, precisará registrar uma assinatura do Azure. Você precisa garantir que a licença do Windows usada nos hosts da sessão esteja corretamente atribuída no Azure e que o sistema operacional esteja ativado. Para obter mais informações, confira Aplicar licença do Windows a máquinas virtuais do host de sessão.

Para os hosts da sessão no Azure Stack HCI, licencie e ative as máquinas virtuais usadas para usá-las com a Área de Trabalho Virtual do Azure. Para ativar o Windows 10 e o Windows 11 Enterprise para múltiplas sessões, bem como 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 métodos de ativação existentes. Para obter mais informações, confira Ativar VMs do Windows Server no Azure Stack HCI.

Observação

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. Esta atualização é essencial para que as VMs continuem usando os benefícios do Azure. Para obter mais informações, confira Verificação do Azure para VMs.

Dica

Para simplificar os direitos de acesso do usuário durante o desenvolvimento e teste iniciais, a Área de Trabalho Virtual do Azure dá suporte a preço 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 direitos de licença separados para executar testes de aceitação ou fornecer comentários.

Rede

Há vários requisitos de rede que você precisa cumprir para implantar a Área de Trabalho Virtual do Azure com sucesso. Isso permite que os usuários se conectem a suas áreas de trabalho e aplicativos, fornecendo também 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 inversa com o serviço, o que significa que você não precisa abrir nenhuma porta de entrada. O Protocolo TCP (Protocolo de Controle de Transmissão) na porta 443 é usado por padrão; no entanto, o Shortpath RDP pode ser usado com redes gerenciadas e redes públicas que estabelecem um transporte direto baseado em UDP (Protocolo de Datagrama de Usuário).

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

  • Você precisa ter uma rede virtual e uma sub-rede para os hosts da sessão. Se você criar os 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. A 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 aos servidores DNS relevantes, caso você esteja usando o AD DS ou o Microsoft Entra Domain Services, pois você precisará ingressar os hosts da sessão no domínio.

  • Os hosts de sessão e os 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árias. Você deve verificar se 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 a pontos de extremidade da Microsoft 365.

Considere também o seguinte:

  • Os usuários podem precisar ter acesso aos aplicativos e aos dados hospedados em redes diferentes, portanto, verifique se os hosts da sessão podem se conectar a eles.

  • A latência do RTT (tempo de viagem de ida e volta) 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 avaliador de experiência para ver a integridade da sua 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 da Área de Trabalho Virtual do Azure no Azure, recomendamos que você não abra a porta de entrada 3389 nos hosts da sessão. A Área de Trabalho Virtual do Azure não requer que uma porta de entrada aberta esteja aberta. Caso você precise abrir a porta 3389 para fins de solução de problemas, recomendamos o uso do acesso just-in-time à VM. Também recomendamos que você não atribua um endereço IP público aos hosts da sessão.

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

Observação

Para manter a Área de Trabalho Virtual do Azure confiável e escalonável, agregamos padrões de tráfego e uso para verificar a integridade e o desempenho do painel de controle de infraestrutura. Agregamos essas informações de todos os locais onde essa infraestrutura de serviço está, e as enviamos para a região dos EUA. Os dados enviados para a região dos EUA incluem dados removidos, mas não dados do cliente. Para saber mais, confira Locais de dados para a Área de Trabalho Virtual do Azure.

Gerenciamento de host de sessão

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

  • Não ative nenhuma política ou configuração que desabilite o Windows Installer. Se você desabilitar o Windows Installer, o serviço não poderá instalar as atualizações do agente nos hosts da sessão, os quais não funcionarão corretamente.

  • Se você estiver ingressando os hosts da sessão em um domínio do AD DS e quiser gerenciá-los com o Intune, configure o Microsoft Entra Connect para habilitar o ingresso híbrido no Microsoft Entra.

  • Se você estiver ingressando hosts da sessão em um domínio do Microsoft Entra Domain Services, não poderá gerenciá-los usando o Intune.

  • Se você estiver usando o ingresso no Microsoft Entra com o Windows Server para os hosts da sessão, não poderá registrá-los no Intune, pois não há suporte para o Windows Server no Intune. Será necessário usar o ingresso híbrido no Microsoft Entra e a Política de Grupo de um domínio do Active Directory ou a Política de Grupo local em cada host da sessão.

Regiões do Azure

É possível implantar pools de host, workspaces e grupos de aplicativos nas regiões do Azure a seguir. Essa lista de regiões é onde os metadados do pool de host podem ser armazenados. No entanto, os hosts da sessão para as sessões de usuário podem ser localizados em qualquer região do Azure e 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 localizações, consulte Localizações de dados para a Área de Trabalho Virtual do Azure.

  • Leste da Austrália
  • Canadá Central
  • Leste do Canadá
  • Índia Central
  • Centro dos EUA
  • Leste dos EUA
  • Leste dos EUA 2
  • Leste do Japão
  • Centro-Norte dos EUA
  • Norte da Europa
  • Centro-Sul dos Estados Unidos
  • Sul do Reino Unido
  • Oeste do Reino Unido
  • Centro-Oeste dos EUA
  • Europa Ocidental
  • Oeste dos EUA
  • Oeste dos EUA 2
  • Oeste dos EUA 3

A Área de Trabalho Virtual do Azure também está disponível em nuvens soberanas, como Azure para Governo dos EUA e Azure operado por 21Vianet na China.

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

Clientes de área de trabalho remota

Os usuários precisam ter 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 dá suporte ás conexões do cliente RADC (Conexões de RemoteApp e Área de Trabalho) nem o cliente de 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 de URL necessária.

Próximas etapas