Compartilhar via

Pré-requisitos do Azure Virtual Desktop

Existem algumas coisas de que precisa para começar a utilizar o Azure Virtual Desktop. Aqui, pode encontrar os pré-requisitos que precisa de concluir para fornecer com êxito aos seus utilizadores ambientes de trabalho e aplicações.

A um nível elevado, precisa de:

  • Uma conta do Azure com uma assinatura ativa
  • Um fornecedor de identidade suportado
  • Um sistema operativo suportado para máquinas virtuais de anfitrião de sessões
  • Licenças adequadas
  • Conectividade de rede
  • Um cliente de Ambiente de Trabalho Remoto

Conta do Azure com uma subscrição ativa

Precisa de uma conta do Azure com uma subscrição ativa para implementar o Azure Virtual Desktop. Se ainda não tiver uma, pode criar uma conta gratuitamente.

Para implementar o Azure Virtual Desktop, tem de atribuir as funções de controlo de acesso baseado em funções (RBAC) relevantes do Azure. Os requisitos de função específicos são abordados em cada um dos artigos relacionados para implementar o Azure Virtual Desktop, que estão listados na secção Passos seguintes.

Certifique-se também de que registou o fornecedor de recursos Microsoft.DesktopVirtualization para a sua subscrição. Para marcar a status do fornecedor de recursos e registar se necessário, selecione o separador relevante para o seu cenário e siga os passos.

Importante

Você deve ter permissão para registrar um provedor de recursos, o que requer a operação */register/action. Isto é incluído se a sua conta tiver atribuída a função de contribuidor ou proprietário na sua subscrição.

  1. Entre 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 não estiver Registado, selecione Microsoft.DesktopVirtualização e, em seguida, selecione Registar.

  7. Verifique se a status de Microsoft.DesktopVirtualization está Registada.

Identidade

Para aceder a ambientes de trabalho e aplicações a partir dos anfitriões de sessão, os seus utilizadores têm de conseguir autenticar-se. Microsoft Entra ID é o serviço de identidade na cloud centralizado da Microsoft que permite esta capacidade. Microsoft Entra ID é sempre utilizado para autenticar utilizadores para o Azure Virtual Desktop. Os anfitriões de sessão podem ser associados ao mesmo inquilino Microsoft Entra ou a um domínio do Active Directory através de Active Directory Domain Services (AD DS) ou Microsoft Entra Domain Services, o que lhe permite escolher opções de configuração flexíveis.

Hosts de sessão

Tem de aderir a anfitriões de sessão que fornecem ambientes de trabalho e aplicações ao mesmo inquilino Microsoft Entra que os seus utilizadores ou a um domínio do Active Directory (AD DS ou Microsoft Entra Domain Services).

Observação

Por Azure Local, só pode associar anfitriões de sessão a um domínio de Active Directory Domain Services. Só pode participar em anfitriões de sessão no Azure Local num domínio de Active Directory Domain Services (AD DS). Isto inclui a utilização de Microsoft Entra associação híbrida, onde pode beneficiar de algumas das funcionalidades fornecidas pelo Microsoft Entra ID.

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

Usuários

Os seus utilizadores precisam de contas Microsoft Entra ID. Se também estiver a utilizar o AD DS ou Microsoft Entra Domain Services na implementação do Azure Virtual Desktop, estas contas têm de ser identidades híbridas, o que significa que as contas de utilizador estão sincronizadas. Tem de ter em mente os seguintes aspetos com base no fornecedor de identidade que utiliza:

  • Se estiver a utilizar Microsoft Entra ID com o AD DS, terá de configurar o Microsoft Entra Ligar para sincronizar os dados de identidade de utilizador entre o AD DS e o Microsoft Entra ID.
  • Se estiver a utilizar Microsoft Entra ID com Microsoft Entra Domain Services, as contas de utilizador são sincronizadas de Microsoft Entra ID para Microsoft Entra Domain Services. Este processo de sincronização é automático.

Importante

A conta de utilizador tem de existir no inquilino Microsoft Entra que utiliza para o Azure Virtual Desktop. O Azure Virtual Desktop não suporta contas B2B, B2C ou Microsoft pessoais.

Ao utilizar identidades híbridas, o UserPrincipalName (UPN) ou o Sid (Security Identifier) têm de corresponder entre Active Directory Domain Services e Microsoft Entra ID. Para obter mais informações, veja Supported identities and authentication methods (Identidades suportadas e métodos de autenticação).

Cenários de identidade suportados

A tabela seguinte resume os cenários de identidade suportados atualmente pelo Azure Virtual Desktop:

Cenário de identidade Hosts de sessão Contas de usuário
Microsoft Entra ID + AD DS Associado ao AD DS No Microsoft Entra ID e no AD DS, sincronizado
Microsoft Entra ID + AD DS Associado ao Microsoft Entra ID No Microsoft Entra ID e no AD DS, sincronizado
Microsoft Entra ID + Microsoft Entra Domain Services Associado ao Microsoft Entra Domain Services Em Microsoft Entra ID e Microsoft Entra Domain Services, sincronizado
Microsoft Entra ID + Microsoft Entra Domain Services + AD DS Associado ao Microsoft Entra Domain Services No Microsoft Entra ID e no AD DS, sincronizado
Microsoft Entra ID + Microsoft Entra Domain Services Associado ao Microsoft Entra ID Em Microsoft Entra ID e Microsoft Entra Domain Services, sincronizado
apenas Microsoft Entra Associado ao Microsoft Entra ID Em Microsoft Entra ID

Para obter informações mais detalhadas sobre cenários de identidade suportados, incluindo o início de sessão único e a autenticação multifator, veja Supported identities and authentication methods (Identidades suportadas e métodos de autenticação).

Contentor de Perfis FSLogix

Para utilizar o Contentor de Perfis do FSLogix ao associar os anfitriões de sessão ao Microsoft Entra ID, tem de armazenar perfis no Arquivos do Azure ou Azure NetApp Files e as suas contas de utilizador têm de ser identidades híbridas. Tem de criar estas contas no AD DS e sincronizá-las para Microsoft Entra ID. Para saber mais sobre como implementar o Contentor de Perfis FSLogix com diferentes cenários de identidade, veja os seguintes artigos:

Parâmetros de implementação

Tem de introduzir os seguintes parâmetros de identidade ao implementar anfitriões de sessão:

  • Nome de domínio, se estiver a utilizar o AD DS ou Microsoft Entra Domain Services.
  • Credenciais para associar anfitriões de sessão ao domínio.
  • Unidade Organizacional (UO), que é um parâmetro opcional que lhe permite colocar anfitriões de sessão na UO pretendida no momento da implementação.

Importante

A conta que utiliza para associar um domínio não pode ter a autenticação multifator (MFA) ativada.

Sistemas operativos e licenças

Tem uma opção de sistemas operativos (SO) que pode utilizar para anfitriões de sessão para fornecer ambientes de trabalho e aplicações. Pode utilizar sistemas operativos diferentes com conjuntos de anfitriões diferentes para fornecer flexibilidade aos seus utilizadores. Suportamos os sistemas operativos e SKUs de 64 bits nas seguintes listas de tabelas (em que 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 operacional
(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, Student Use Benefit
  • Windows Enterprise E3, E5
  • Windows Education A3, A5
  • VDA do Windows por utilizador
  • Licença de Acesso de Cliente (CAL) dos Serviços de Ambiente de Trabalho Remoto (RDS) com Software Assurance (por utilizador ou por dispositivo)
  • Licenças de Subscrição de Utilizador do RDS.
  • Windows Server licença de acesso de subscritor RDS (SAL).

Os preços de acesso por utilizador não estão disponíveis para Windows Server sistemas operativos.

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

Importante

Para o Azure, pode utilizar imagens do sistema operativo fornecidas pela Microsoft no Azure Marketplace ou criar as suas próprias imagens personalizadas armazenadas numa Galeria de Computação do Azure ou como uma imagem gerida. Utilizar modelos de imagem personalizados para o Azure Virtual Desktop permite-lhe criar facilmente uma imagem personalizada que pode utilizar ao implementar máquinas virtuais (VMs) do anfitrião de sessões. Para saber mais sobre como criar imagens personalizadas, consulte:

Em alternativa, para Azure Local pode utilizar imagens do sistema operativo a partir de:

Pode implementar máquinas virtuais (VMs) para serem utilizadas como anfitriões de sessão a partir destas imagens com qualquer um dos seguintes métodos:

Se a licença lhe permitir utilizar o Azure Virtual Desktop, 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, terá de inscrever uma Subscrição do Azure. Tem de se certificar de que a licença do Windows utilizada nos anfitriões de sessão está corretamente atribuída no Azure e que o sistema operativo está ativado. Para obter mais informações, veja Apply Windows license to session host virtual machines (Aplicar licença do Windows a máquinas virtuais de anfitrião de sessões).

Para anfitriões de sessão no Azure Local, tem de licenciar e ativar as máquinas virtuais que utiliza antes de as utilizar com o Azure Virtual Desktop. Para ativar Windows 10 e Windows 11 Enterprise várias sessões e Windows Server 2022 Datacenter: Edição do Azure, utilize a verificação do Azure para VMs. Para todas as outras imagens do SO (como Windows 10 e Windows 11 Enterprise e outras edições de Windows Server), deve continuar a utilizar métodos de ativação existentes. Para obter mais informações, veja Activate Windows Server VMs on Azure Local (Ativar VMs Windows Server no Azure Local).

Observação

Para garantir a funcionalidade contínua com a atualização de segurança mais recente, atualize as 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 a utilizar os benefícios do Azure. Para obter mais informações, veja Verificação do Azure para VMs.

Dica

Para simplificar os direitos de acesso dos utilizadores durante o desenvolvimento e teste iniciais, o Azure Virtual Desktop suporta os preços do Azure Dev/Test. Se implementar o Azure Virtual Desktop numa subscrição do Azure Dev/Test, os utilizadores finais poderão ligar-se a essa implementação sem elegibilidade de licença separada para realizar testes de aceitação ou fornecer feedback.

Rede

Existem vários requisitos de rede que precisa de cumprir para implementar com êxito o Azure Virtual Desktop. Isto permite que os utilizadores se liguem aos respetivos ambientes de trabalho e aplicações, ao mesmo tempo que lhes dá a melhor experiência de utilizador possível.

Os utilizadores que se ligam ao Azure Virtual Desktop estabelecem de forma segura uma ligação inversa ao serviço, o que significa que não precisa de abrir portas de entrada. O Protocolo de Controlo de Transmissão (TCP) na porta 443 é utilizado por predefinição. No entanto, o RDP Shortpath pode ser utilizado para redes geridas e redes públicas que estabelecem um transporte direto baseado no Protocolo UDP (User Datagram Protocol).

Para implementar com êxito o Azure Virtual Desktop, tem de cumprir os seguintes requisitos de rede:

  • Precisa de uma rede virtual e de uma sub-rede para os anfitriões de sessão. Se criar os anfitriões de sessão ao mesmo tempo que um conjunto de anfitriões, tem de criar esta rede virtual com antecedência para que apareça na lista pendente. A rede virtual tem de estar na mesma região do Azure que o anfitrião da sessão.

  • Certifique-se de que esta rede virtual consegue ligar-se aos controladores de domínio e aos servidores DNS relevantes se estiver a utilizar o AD DS ou Microsoft Entra Domain Services, uma vez que tem de associar anfitriões de sessão ao domínio.

  • Os anfitriões de sessão e os utilizadores têm de conseguir ligar-se ao serviço Azure Virtual Desktop. Estas ligações também utilizam TCP na porta 443 para uma lista específica de URLs. Para obter mais informações, veja Lista de URLs necessários. Tem de se certificar de que estes URLs não são bloqueados pela filtragem de rede ou por uma firewall para que a implementação funcione corretamente e seja suportada. Se os seus utilizadores precisarem de aceder ao Microsoft 365, certifique-se de que os anfitriões de sessão se podem ligar aos pontos finais do Microsoft 365.

Considere também o seguinte:

  • Os seus utilizadores podem precisar de acesso a aplicações e dados alojados em redes diferentes, por isso certifique-se de que os anfitriões de sessão se podem ligar às mesmas.

  • A latência do tempo de ida e volta (RTT) da rede do cliente para a região do Azure que contém os conjuntos de anfitriões deve ser inferior a 150 ms. Para ver que localizações têm a melhor latência, procure a localização pretendida nas estatísticas de latência de ida e volta da rede do Azure. Para otimizar o desempenho da rede, recomendamos que crie anfitriões de sessão na região do Azure mais próximos dos seus utilizadores.

  • Utilize Firewall do Azure para implementações do Azure Virtual Desktop para o ajudar a bloquear o ambiente e a filtrar o tráfego de saída.

  • Para ajudar a proteger o ambiente do Azure Virtual Desktop no Azure, recomendamos que não abra a porta de entrada 3389 nos anfitriões de sessão. O Azure Virtual Desktop não requer a abertura de uma porta de entrada aberta. Se tiver de abrir a porta 3389 para fins de resolução de problemas, recomendamos que utilize o acesso just-in-time à VM. Também recomendamos que não atribua um endereço IP público aos anfitriões de sessão.

Para saber mais, veja Compreender a conectividade de rede do Azure Virtual Desktop.

Observação

Para manter o Azure Virtual Desktop fiável e dimensionável, agregamos os padrões de tráfego e a utilização para marcar o estado de funcionamento e o desempenho do plano de controlo da infraestrutura. Agregamos estas informações a partir de todas as localizações onde se encontra a infraestrutura de serviço e, em seguida, enviamo-las para a região dos E.U.A. Os dados enviados para a região dos EUA incluem dados limpos, mas não dados de clientes. Para obter mais informações, veja Localizações de dados para o Azure Virtual Desktop.

Gestão de anfitriões de sessões

Considere os seguintes pontos ao gerir anfitriões de sessão:

  • Não ative políticas ou configurações que desativem o Windows Installer. Se desativar o Windows Installer, o serviço não poderá instalar atualizações de agentes nos anfitriões de sessão e os anfitriões de sessão não funcionarão corretamente.

  • Se estiver a associar anfitriões de sessão a um domínio do AD DS e quiser geri-los com Intune, tem de configurar o Microsoft Entra Connect para ativar Microsoft Entra associação híbrida.

  • Se estiver a associar anfitriões de sessão a um domínio de Microsoft Entra Domain Services, não poderá geri-los com Intune.

  • Se estiver a utilizar Microsoft Entra participar com Windows Server para os anfitriões de sessão, não poderá inscrevê-los no Intune uma vez que Windows Server não é suportada com Intune. Tem de utilizar Microsoft Entra associação híbrida e Política de Grupo a partir de um domínio do Active Directory ou Política de Grupo local em cada anfitrião de sessão.

Regiões do Azure

Pode implementar conjuntos de anfitriões, áreas de trabalho e grupos de aplicações nas seguintes regiões do Azure. Esta lista de regiões é onde os metadados do conjunto de anfitriões podem ser armazenados. No entanto, os anfitriões de sessão para as sessões de utilizador podem estar localizados em qualquer região do Azure e no local ao utilizar o Azure Virtual Desktop no Azure Local, permitindo-lhe implementar recursos de computação perto dos seus utilizadores. Para obter mais informações sobre os tipos de dados e localizações, veja Localizações de dados para o Azure Virtual Desktop.

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

O Azure Virtual Desktop também está disponível em clouds soberanas, como o Azure for US Government e o Azure operado pela 21Vianet na China.

Para saber mais sobre a arquitetura e resiliência do serviço Azure Virtual Desktop, veja Arquitetura e resiliência do serviço Azure Virtual Desktop.

Ligar a uma sessão remota

Os seus utilizadores têm de utilizar Windows App ou o cliente de Ambiente de Trabalho Remoto para se ligarem a ambientes de trabalho e aplicações. Pode ligar a partir de:

  • Windows
  • macOS
  • iOS/iPadOS
  • SO Android/Chrome
  • Navegador da Web

Para obter mais informações, consulte Introdução ao Windows App para ligar a dispositivos e aplicações.

Importante

O Azure Virtual Desktop não suporta ligações do cliente RemoteApp and Desktop Connections (RADC) ou da Ligação de Ambiente de Trabalho Remoto (MSTSC).

Para saber que URLs os clientes utilizam para ligar e que tem de permitir através de firewalls e filtros da Internet, veja a lista URL Obrigatório.

Próximas etapas