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.
Entre no portal do Azure.
Selecione Assinaturas.
Selecione o nome da sua assinatura.
Selecione Provedores de recursos.
Pesquisar por Microsoft.DesktopVirtualization.
Se o status for NotRegistered, selecione Microsoft. DesktopVirtualization e, em seguida, selecione Registrar.
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 Local, você só pode ingressar hosts de sessão em um domínio do Active Directory Domain Services. Você só pode ingressar hosts de sessão no Azure Local em um domínio do AD DS (Active Directory Domain Services). Isso inclui o uso da ingresso no Microsoft Entra híbrido, em que você pode se beneficiar de algumas das funcionalidades fornecidas pelo Microsoft Entra ID.
Para ingressar hosts da sessão no Microsoft Entra ID ou um domínio do Active Directory, você precisa das seguintes permissões:
Para o Microsoft Entra ID, você precisa de uma conta que possa ingressar computadores em seu locatário. Para saber mais, confira Gerenciar identidades de dispositivos . Para saber mais sobre como ingressar hosts da sessão no Microsoft Entra ID, consulte Hosts da sessão ingressados no Microsoft Entra.
Em um domínio do Active Directory, você precisa de uma conta de domínio que possa ingressar em computadores no seu domínio. Para o Microsoft Entra Domain Services, você precisa ser membro do grupo Administradores de DC do AAD.
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:
- Configurar o Contêiner de Perfil do FSLogix com Arquivos do Azure e Active Directory Domain Services ou Microsoft Entra Domain Services.
- Configurar o Contêiner de Perfil do FSLogix com Arquivos do Azure e Microsoft Entra ID.
- Configurar o contêiner de perfil FSLogix com o Azure NetApp Files
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) |
---|---|---|
|
|
|
|
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
- Os seguintes itens não têm suporte em hosts de sessão:
- Sistemas operacionais de 32 bits.
- N, KN, LTSC e outras edições de sistemas operacionais Windows não listadas na tabela anterior.
- Discos Ultra para o tipo de disco do sistema operacional.
- Discos do SO efêmero para VMs do Azure.
- Conjuntos de Dimensionamento de Máquinas Virtuais.
- VMs do Azure baseadas em Arm64.
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:
- Modelos de imagens personalizadas na Área de Trabalho Virtual do Azure
- Armazenar e compartilhar imagens em uma Galeria de Computação do Azure.
- Criar uma imagem gerenciada de uma VM generalizada no Azure.
Como alternativa, para o Azure Local, você pode usar imagens do sistema operacional de:
- No Azure Marketplace. Para obter mais informações, consulte Criar imagem de VM local do Azure usando imagens do Azure Marketplace.
- Conta de Armazenamento do Azure. Para obter mais informações, consulte Criar imagem de VM Local do Azure usando imagem na conta de Armazenamento do Azure.
- Um compartilhamento local. Para obter mais informações, consulte Criar imagem de VM local do Azure usando imagens em um compartilhamento local.
É 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:
- Automaticamente, como parte do processo de instalação do pool de hosts no portal do Azure.
- Adicionando hosts de sessão manualmente a um pool de hosts existente no portal do Azure.
- Programaticamente, com a CLI do Azure ou o Azure PowerShell.
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 hosts de sessão no Azure Local, 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 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, consulte Ativar VMs do Windows Server no Azure Local.
Observação
Para garantir a funcionalidade contínua com a atualização de segurança mais recente, atualize suas VMs no Azure Local 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. Para ver quais locais têm a melhor latência, procure o local desejado nas estatísticas de latência de ida e volta da rede 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 de sessão para as sessões de usuário podem estar localizados em qualquer região do Azure e localmente ao usar Área de Trabalho Virtual do Azure no Azure Local, permitindo que você implante recursos de computação perto de 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:
- Cliente de Área de Trabalho do Windows
- Aplicativo da Store da Área de Trabalho Virtual do Azure para Windows
- Cliente Web
- Cliente para macOS
- Cliente iOS e iPadOS
- Cliente Android e Chrome OS
- Aplicativo da Área de Trabalho Remota para Windows
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
Para ver uma forma simples de começar a usar a Área de Trabalho Virtual do Azure criando uma infraestrutura de exemplo, confira Tutorial: Implantar uma infraestrutura de exemplo da Área de Trabalho Virtual do Azure com uma área de trabalho do Windows 11.
Para ver uma abordagem mais detalhada e adaptável para implantar a Área de Trabalho Virtual do Azure, confira Implantar a Área de Trabalho Virtual do Azure.