O objetivo dessa lista de verificação é informá-lo dos elementos necessários para uma implantação do Horizon Cloud on Microsoft Azure de primeira geração. Seguir essa lista de verificação permite a execução bem-sucedida do implantador de pod e a conclusão das tarefas do dia 1.

Atenção: Use essa página somente quando você tiver acesso a um ambiente de tenant de primeira geração na camada de controle de primeira geração. Conforme descrito em KB-92424, a camada de controle de primeira geração atingiu o fim da disponibilidade (EOA). Consulte esse artigo para obter detalhes.

A partir de agosto de 2022, o Horizon Cloud Service - next-gen está disponível para todos e tem seu próprio conjunto de documentação sobre o uso de Next-Gen disponível aqui.

Uma indicação de qual ambiente você tem, next-gen ou primeira geração, é o padrão que aparece no campo de URL do navegador depois que você faz login em seu ambiente e vê o rótulo Horizon Universal Console. Para um ambiente next-gen, o endereço de URL do console contém uma parte como /hcsadmin/. A URL do console de primeira geração tem uma seção diferente (/horizonadmin/).

Público-alvo da lista de verificação

Esta lista de verificação se destina principalmente a contas de clientes do Horizon Cloud que nunca tiveram uma implantação do Horizon Cloud on Microsoft Azure em seu ambiente de tenant antes da atualização do serviço em 2 de novembro de 2023. Esses tenants podem ser chamados de ambientes novos ou greenfield.

O conjunto descrito aqui é principalmente para implantações de produção. A avaliação e a maioria das implantações de prova de conceito geralmente podem ser manipuladas com um subconjunto, como ilustrado em Uma implantação simplificada de prova de conceito.

Algumas das seções listadas abaixo devem ser implementadas antes da execução do assistente de implantação de Novo Pod.

Alguns itens podem ser adiados até que a implantação seja concluída e esteja em operação.

Alguns itens são listados como opcionais, pois estão relacionados às escolhas que você faz para a implantação do Horizon Cloud on Microsoft Azure.

Por exemplo, você pode executar o assistente de Novo Pod sem escolher uma configuração do Unified Access Gateway e adicionar a configuração de gateway mais tarde. Nesse caso, você não precisaria cumprir os requisitos do Unified Access Gateway até esse momento posterior.

Cumpra-os antes de executar o assistente de Novo Pod Isso pode ser feito após a implantação do pod
  • Conta de tenant da camada de controle
  • Itens de assinatura do Microsoft Azure
  • Rede
  • Portas e protocolos
  • Itens do Unified Access Gateway opcionais
  • Active Directory
  • Unified Access Gateway opcional (adicionado pós-implantação)
  • Universal Broker
  • Registros do DNS
  • Golden images, área de trabalho, capacidades de farms
  • Licenças do sistema operacional Microsoft Windows

Algumas considerações importantes

Quando você está fazendo uma implantação de avaliação ou de prova de conceito do Horizon Cloud on Microsoft Azure, pode ser o proprietário da assinatura do Microsoft Azure que será usada para a implantação, ou pode estar fazendo a prova de conceito em nome de uma organização que possui a assinatura.

O proprietário da assinatura deve garantir que nenhuma das políticas do Microsoft Azure em vigor na assinatura do pod bloqueie, negue ou restrinja a criação dos componentes do pod.

O motivo para garantir isso é que, durante o processo de implantação do pod, o implantador do pod usa chamadas de API para criar recursos na assinatura especificada no assistente de Novo Pod. Se essa assinatura tiver políticas do Microsoft Azure em vigor que possam bloquear, negar ou restringir a criação dos componentes do pod, a implantação não será bem-sucedida e exigirá uma solicitação de suporte da VMware.

Um exemplo é que o implantador do pod requer que nenhuma das políticas do Microsoft Azure em vigor na assinatura do pod bloqueie, negue ou restrinja a criação de componentes na conta de armazenamento do Azure.

Antes de executar o assistente de Novo Pod, verifique com o proprietário da assinatura se as definições de Política Interna das Políticas do Microsoft Azure não bloqueiam, negam ou restringem a criação dos componentes do pod.

Requisitos de camada de controle do Horizon Cloud

A conta do VMware Customer Connect que foi configurada pela VMware para fazer login na camada de controle do Horizon Cloud.

Para obter uma visão geral do relacionamento dessa conta com sua conta de tenant do Horizon Cloud, você pode consultar a página Implantações do Horizon Service e Pods de Integração.

Requisitos de assinatura do Microsoft Azure

Assinatura válida do Microsoft Azure em um ambiente do Microsoft Azure com suporte (Azure Commercial, Azure China, ou Azure Government). Se você implantar o Unified Access Gateway externo em uma VNet separada usando sua própria assinatura, obtenha outra assinatura válida do Microsoft Azure no mesmo ambiente que o Microsoft Azure.
Observação: O Horizon Cloud é compatível com a maioria das regiões do Microsoft Azure. Para obter a lista de regiões do Microsoft Azure que não têm suporte atualmente, consulte o artigo da Base de Conhecimento da VMware Regiões do Microsoft Azure com Horizon Cloud Service on Microsoft Azure (77121).
Privilégios administrativos válidos do Microsoft Azure nessa assinatura do Microsoft Azure, para você usar o portal do Microsoft Azure e executar as etapas de preparação da implantação do pod.
Registro do aplicativo e chave secreta do cliente do Horizon Cloud criados na assinatura do pod. Consulte Tenants de primeira geração: criar um Registro do aplicativo Horizon Cloud na assinatura do pod.

Quando você ou sua organização usarem o recurso para implantar a configuração de gateway externo em uma assinatura separada da assinatura do pod, essa assinatura de gateway também precisará de um registro de aplicativo do Horizon Cloud e de uma chave secreta do cliente.

A criação do registro do aplicativo do Horizon Cloud em uma assinatura cria automaticamente uma entidade de serviço, pelo comportamento padrão do Microsoft Azure.

Para essa entidade de serviço, atribua uma função que permita que o Horizon Cloud faça chamadas à API na assinatura do pod.

Normalmente, a função Contributor é atribuída no nível de assinatura do pod.

Como alternativa, a função pode ser personalizada e atribuída no nível de assinatura do pod.

Ao implantar a configuração de gateway externo em um grupo de recursos existente em uma assinatura separada, você pode atribuir uma função personalizada ou a função Contributor para a entidade de serviço dessa assinatura de gateway.

Quando você ou sua organização quiserem que o registro do aplicativo do Horizon Cloud use uma função personalizada, consulte a página a seguir, que descreve as ações que a função personalizada deve ter: Quando sua organização prefere usar uma função personalizada.

Observação: A função deve ser atribuída diretamente à entidade de serviço do registro do aplicativo do Horizon Cloud. Não há suporte para o uso de uma atribuição baseada em grupo de uma função para essa entidade de serviço.
Provedores de recursos necessários registrados em cada assinatura do Microsoft Azure. Consulte Registrar provedores de recursos.
ID da assinatura, ID do diretório, ID do aplicativo e chave identificados para a assinatura que você especificará no assistente de implantação.
A assinatura deve permitir o uso do tipo de conta Azure StorageV2. Verifique se suas políticas do Microsoft Azure não restringem nem negam a criação de conteúdo que requer o tipo de conta Azure StorageV2.
A assinatura deve permitir a criação de grupos de recursos que não têm tags, a menos que você especifique tags de recursos personalizadas no assistente de implantação de pod. O processo de implantação do pod cria grupos de recursos na assinatura do pod sem tags, a menos que você especifique tags de recursos personalizadas no assistente.

Se você não estiver planejando usar o recurso de tags de recursos personalizadas do assistente de implantação, deverá verificar se as suas políticas do Microsoft Azure permitem a criação dos grupos de recursos não marcados do pod na assinatura de destino. Se você não especificar tags de recursos personalizadas no assistente e sua assinatura do Microsoft Azure tiver algum tipo de requisito de tag de recurso, a implantação do pod falhará quando você tentar implantar um pod nessa assinatura, ou ela falhará durante a atualização do pod ou a adição de uma configuração de gateway a um pod. Para obter os nomes dos grupos de recursos criados pelo implantador, consulte Grupos de recursos que o implantador do pod cria.

Opcional. Sua organização pode especificar que requer que você use um grupo de recursos específico e pré-criado nomeado pela organização para o Unified Access Gateway externo, em uma VNet e uma assinatura separadas da assinatura do pod, e a organização requer o uso de um grupo de recursos específico pré-criado nomeado pela organização; você usaria o recurso para implantar o Unified Access Gateway externo em seu próprio grupo de recursos nomeado. Sem usar esse recurso, o implantador do pod cria automaticamente um grupo de recursos com sua própria convenção de nomenclatura.

O uso do recurso exige que você crie esse grupo de recursos nessa assinatura antes de executar o implantador do pod. Você também precisa garantir que as permissões necessárias estejam em vigor para o implantador do pod implantar a configuração do Unified Access Gateway nesse grupo de recursos, gerenciar a configuração e atualizar o software Unified Access Gateway no processo de atualização do pod padrão. Para obter detalhes sobre as permissões necessárias para incluir na função personalizada, consulte Quando sua organização prefere usar uma função personalizada.

Requisitos de capacidade do Microsoft Azure

Quando a tabela a seguir se refere à capacidade do Microsoft Azure, nenhuma instalação manual é necessária. Contanto que as capacidades declaradas estejam disponíveis na assinatura, o implantador do pod instanciará automaticamente as VMs descritas.

Para capacidade envolvendo famílias de VMs, o portal do Microsoft Azure também usa o termo quota.

Capacidade do Microsoft Azure para os artefatos do pod principal do Horizon Cloud a serem implantados nessa assinatura. (essa lista exclui as capacidades necessárias para as configurações opcionais do Unified Access Gateway e para suas cargas de trabalho de área de trabalho e aplicativos previstas).
Pod
  • Gerenciadores de Pods, 2 x Standard_D4_v3 (se não houver Standard_D4_v3 na região, 2 x Standard_D3_v2)
  • Base de dados do Microsoft Azure para o PostgreSQL Service: Geração 5, memória otimizada, 2 vCores, armazenamento de 10 GB
  • Quando seu pod estiver pronto para uso, sua capacidade na nuvem do Microsoft Azure também terá que acomodar as VMs importadas, as golden images, as áreas de trabalho virtuais, os farms RDSH e as VMs de captura de aplicativo do App Volumes que você criar nesse pod. Consulte a seção Imagens base, áreas de trabalho e farms do Horizon Cloud abaixo.
  • Em uma circunstância especial em que você abra uma solicitação de suporte e o suporte VMware determine que a maneira de atender essa solicitação é implantar temporariamente uma jumpbox de VM relacionada ao suporte, sua capacidade terá de acomodar a implantação de uma VM modelo Standard_F2 nesse momento.
Opcional. Capacidade necessária ao especificar o uso do Unified Access Gateway para o pod.
Observação: O modelo de VM A4_v2 só é suficiente para provas de conceito (PoCs), pilotos ou ambientes menores nos quais você sabe que não excederão 1.000 sessões ativas no pod.
Unified Access Gateway externo na mesma VNet do pod
2 x Standard_A4_v2 ou 2 x Standard_F8s_v2
Unified Access Gateway externo em sua própria VNet
  • Conector de gateway externo: 1 x Standard_A1_v2
  • Unified Access Gateway externo: 2 x Standard_A4_v2 ou 2 x Standard_F8s_v2.
Unified Access Gateway interno
2 x Standard_A4_v2 ou 2 x Standard_F8s_v2

Se a região da assinatura não fornecer os tamanhos Standard_F8s_v2 VM, o assistente do implantador de pod não exibirá essa opção no seletor na etapa do assistente Especificar Gateways.

Requisitos de rede

Rede virtual do Microsoft Azure (VNet) criada na região de destino do Microsoft Azure com espaço de endereço aplicável para cobrir as sub-redes necessárias. Consulte Horizon Cloud de primeira geração: configurar a rede virtual necessária no Microsoft Azure.

Ao implantar o Unified Access Gateway externo na própria VNet, separada da do pod, crie essa VNet do Unified Access Gateway na mesma região do Microsoft Azure que a VNet do pod com o espaço de endereço aplicável para cobrir as sub-redes necessárias e emparelhe as duas VNets.

3 intervalos de endereços não sobrepostos no formato CIDR na VNet do pod, reservados para sub-redes.
  • Sub-rede de gerenciamento: No mínimo /27
  • Sub-rede de VM - Principal (tenant): No mínimo /27, com /24 - /22 de preferência, com base no número de áreas de trabalho e servidores RDS
  • Sub-rede de zona desmilitarizada: No mínimo /28 quando o Unified Access Gateway for implantado na VNet do pod (opcional)
As sub-redes podem ser criadas manualmente na VNet ou pelo Horizon Cloud durante a implantação. Se você estiver usando sub-redes criadas manualmente, nenhum outro recurso poderá ser anexado.
Dica: Depois que o pod for implantado, você poderá editá-lo para adicionar sub-redes de tenant para uso com as VMs em seus farms e atribuições de área de trabalho. As sub-redes adicionais do tenant podem estar na mesma VNet na qual o pod está implantado ou em uma VNet emparelhada. Para obter detalhes, consulte Visão geral do uso de várias sub-redes de tenant.
Ao implantar o Unified Access Gateway externo na própria VNet separada da do pod, três intervalos de endereços não sobrepostos no formato CIDR na VNet do Unified Access Gateway, reservados para sub-redes.
  • Sub-rede de gerenciamento: No mínimo /27
  • Sub-rede de back-end: no mínimo /27, com /24 - /22 de preferência, com base no número de áreas de trabalho e servidores RDS
  • Sub-rede de zona desmilitarizada (front-end): No mínimo de /28
As sub-redes podem ser criadas manualmente na VNet ou pelo Horizon Cloud durante a implantação. Se você estiver usando sub-redes criadas manualmente, nenhum outro recurso poderá ser anexado. Para esse caso de uso, normalmente as sub-redes são criadas manualmente. Nesse caso de uso, a finalidade da sub-rede de back-end é semelhante à finalidade da Sub-rede de VM (Principal) descrita na linha da tabela anterior.
Servidores ou servidor NTP disponíveis e acessíveis a partir do pod do Horizon Cloud e das instâncias do Unified Access Gateway.
Configure o servidor DNS da VNet (rede virtual), apontando para um servidor DNS válido que possa resolver os nomes externos e os nomes de máquinas internos.
O acesso de saída à Internet nas VNets que você está usando para o pod e a implantação do gateway devem resolver e acessar nomes DNS específicos usando portas e protocolos específicos. Isso é necessário para a implantação e a continuidade das operações. Para obter a lista de nomes e portas DNS, consulte Requisitos de DNS e Requisitos de portas e protocolos.
Opcional. Informações do servidor proxy, se necessário, para acesso de saída à Internet na VNet que é usada durante a implantação e a continuidade das operações do ambiente do Horizon Cloud.
Opcional. O Microsoft Azure VPN/Express Route configurado, quando você deseja a rede entre a VNet e sua rede corporativa local.

Requisitos de portas e protocolos

Portas e protocolos específicos são necessários para a integração de pods e a continuidade das operações do ambiente do Horizon Cloud. Consulte Portas e protocolos.

Requisitos do Unified Access Gateway

Você pode executar o assistente de Novo Pod sem escolher uma configuração do Unified Access Gateway e adicionar a configuração de gateway mais tarde. Nesse caso, você não precisaria cumprir os requisitos do Unified Access Gateway até esse momento posterior. Por definição, um Unified Access Gateway externo permite que os clientes em redes externas iniciem as áreas de trabalho e aplicativos virtuais, enquanto um Unified Access Gateway interno permite que os clientes em redes internas tenham conexões do HTML Access (Blast) confiáveis. Para oferecer suporte a conexões de usuário final da Internet e à inicialização de suas áreas de trabalho e aplicativos virtuais, o pod deve ter um Unified Access Gateway externo configurado.

Se você selecionar as opções do Unified Access Gateway no assistente de Novo Pod, o assistente exigirá itens específicos abaixo.

FQDN para a configuração do Unified Access Gateway.
Certificado ou certificados para o Unified Access Gateway no formato PEM correspondente ao FQDN.
Observação: Se o certificado ou os certificados que você fornecer para essa finalidade usarem as CRLs (listas de certificados revogados) ou as configurações de OCSP (protocolo de status de certificados on-line) que se referem a nomes DNS específicos, você deverá garantir que o acesso à internet de saída na VNet para esses nomes DNS seja resolvível e acessível. Durante a configuração do certificado fornecido na configuração do gateway do Unified Access Gateway, o software do Unified Access Gateway consultará esses nomes DNS para verificar o status de revogação do certificado. Se esses nomes DNS não estiverem acessíveis, a implantação do pod falhará durante a fase de Conexão. Esses nomes são altamente dependentes da autoridade de certificação que você usou para obter os certificados e, portanto, não estão no controle da VMware.
Opcional, exceto quando você deseja que seus usuários finais usem a autenticação de dois fatores. Nesse caso, o Unified Access Gateway deve ser configurado para autenticação de dois fatores com um dos tipos de sistema de autenticação compatíveis para uso com implantações do Horizon Cloud on Microsoft Azure.

A configuração deve incluir:

  • Endereços DNS para o Unified Access Gateway para resolver o nome desse servidor de autenticação
  • Rotas para o Unified Access Gateway para resolver o roteamento de rede para esse servidor de autenticação
Observação: Depois que o pod é implantado e você configurou a autenticação de dois fatores nas configurações do Universal Broker, algumas configurações adicionais são necessárias quando você também deseja que seus usuários finais internos ignorem o uso da autenticação de dois fatores. Quando um pod tem uma configuração do Unified Access Gateway interno, essa configuração roteia as solicitações de conexão para áreas de trabalho virtuais e aplicativos para esses usuários finais internos. Quando você quiser que o Universal Broker ignore a etapa de autenticação de dois fatores para seus usuários finais internos, depois que o pod for implantado e o Universal Broker estiver configurado, insira os intervalos de endereços NAT de saída que correspondem ao seu tráfego de usuário final interno. Esses intervalos permitem que o Universal Broker identifique o tráfego do cliente dos usuários finais internos distintos dos usuários finais externos com o objetivo de ignorar a autenticação de dois fatores. Para obter detalhes, consulte o tópico de documentação Definir intervalos de rede interna para o Universal Broker

Fluxo de trabalho de implantação do pod

Os itens anteriores são aqueles necessários antes de iniciar o assistente de implantação do pod. Depois de garantir que você tenha os itens anteriores, siga as etapas 1 a 4 de implantação do pod em Tenants de primeira geração: implantações do Horizon Cloud on Microsoft Azure: sequência de alto nível para implantar o pod.

Depois que o pod for implantado com êxito, certifique-se de ter os itens descritos na seção a seguir, para que você possa concluir as etapas de chave restantes nesse fluxo de trabalho de alto nível.

Requisitos do Active Directory

O fluxo de trabalho de registro do Active Directory do console exige os seguintes itens. Para compreender totalmente esse fluxo de trabalho, consulte Como realizar seu primeiro registro de domínio do Active Directory no ambiente do Horizon Cloud.

Uma das seguintes configurações do Active Directory com suporte:
  • Servidor local do Active Directory conectado via VPN/Express Route
  • Servidor do Active Directory localizado no Microsoft Azure
  • Serviços de Domínio do Microsoft Azure Active Directory
Níveis funcionais de domínio do Microsoft Windows Active Directory Domain Services (AD DS) compatíveis:
  • Microsoft Windows Server 2008 R2
  • Microsoft Windows Server 2012 R2
  • Microsoft Windows Server 2016
Todos os pods conectados à nuvem na mesma conta de cliente do Horizon Cloud devem ter linha de visão para o mesmo conjunto de domínios do Active Directory no momento em que você implanta esses pods. Esse requisito é aplicado não apenas aos pods adicionais que você implanta no Microsoft Azure após o primeiro pod, mas também a quaisquer pods do Horizon conectados por nuvem à mesma conta de cliente que usa o Horizon Cloud Connector.
Conta de BIND de domínio
Uma conta de BIND de domínio do Active Directory (um usuário padrão com acesso de leitura) que tem o seguinte atributo sAMAccountName. O atributo sAMAccountName deve ter 20 caracteres ou menos e não pode conter nenhum dos seguintes caracteres: "/ \ [ ] : ; | = , + * ? < >

A conta deve ter as seguintes permissões:

  • Conteúdo da lista
  • Ler todas as propriedades
  • Permissões de leitura
  • Read tokenGroupsGlobalAndUniversal (implicado por Ler todas as propriedades)

Você também deve definir a senha da conta para Nunca Expirar para garantir o acesso contínuo para fazer login no seu ambiente do Horizon Cloud.

  • Se você estiver familiarizado com a oferta do VMware Horizon no local, as permissões acima serão o mesmo conjunto necessário para as contas de credenciais secundárias da oferta do Horizon no local.
  • Em geral, as contas de BIND de domínio devem receber as permissões padrão relacionadas ao acesso de leitura prontas para uso que são normalmente concedidas a Usuários Autenticados em uma implantação do Microsoft Active Directory. No entanto, se os administradores do AD da sua organização optarem por bloquear permissões relacionadas ao acesso de leitura para usuários regulares, você deverá solicitar que os administradores do AD preservem os padrões de Usuários Autenticados para as contas de BIND de domínio que você usará para o Horizon Cloud.

Referência: Contas de serviço que o Horizon Cloud exige para suas operações

Conta de BIND de domínio auxiliar
Deve ser separada da conta BIND de domínio principal. A UI impedirá a reutilização da mesma conta em ambos os campos.

Uma conta de BIND de domínio do Active Directory (um usuário padrão com acesso de leitura) que tem o seguinte atributo sAMAccountName. O atributo sAMAccountName deve ter 20 caracteres ou menos e não pode conter nenhum dos seguintes caracteres: "/ \ [ ] : ; | = , + * ? < >

A conta deve ter as seguintes permissões:

  • Conteúdo da lista
  • Ler todas as propriedades
  • Permissões de leitura
  • Read tokenGroupsGlobalAndUniversal (implicado por Ler todas as propriedades)

Você também deve definir a senha da conta para Nunca Expirar para garantir o acesso contínuo para fazer login no seu ambiente do Horizon Cloud.

  • Se você estiver familiarizado com a oferta do VMware Horizon no local, as permissões acima serão o mesmo conjunto necessário para as contas de credenciais secundárias da oferta do Horizon no local.
  • Em geral, as contas de BIND de domínio devem receber as permissões padrão relacionadas ao acesso de leitura prontas para uso que são normalmente concedidas a Usuários Autenticados em uma implantação do Microsoft Active Directory. No entanto, se os administradores do AD da sua organização optarem por bloquear permissões relacionadas ao acesso de leitura para usuários regulares, você deverá solicitar que os administradores do AD preservem os padrões de Usuários Autenticados para as contas de BIND de domínio que você usará para o Horizon Cloud.

Referência: Contas de serviço que o Horizon Cloud exige para suas operações

Conta de ingresso no domínio
Conta de ingresso no domínio do Active Directory que pode ser usada pelo sistema para executar operações Sysprep e ingressar os computadores virtuais no domínio. Normalmente, uma nova conta que você cria para essa finalidade expressa. (Uma conta de usuário de ingresso no domínio)

A conta deve ter o atributo sAMAccountName. O atributo sAMAccountName deve ter 20 caracteres ou menos e não pode conter nenhum dos seguintes caracteres: "/ \ [ ] : ; | = , + * ? < >

No momento, não há suporte para o uso de espaços em branco no nome de usuário da conta.

Você também deve definir a senha da conta como Nunca Expirar para garantir a capacidade contínua do Horizon Cloud para realizar as operações do Sysprep e ingressar os computadores virtuais no domínio.

Essa conta requer as permissões a seguir do Active Directory, aplicadas à UO de Computadores ou à UO que você inserirá na UI de Ingresso no Domínio do console.

  • Ler todas as propriedades: somente este objeto
  • Criar objetos de computador: esse objeto e todos os objetos descendentes
  • Excluir objetos de computador: esse objeto e todos os objetos descendentes
  • Gravar todas as propriedades: objetos de computador descendentes
  • Redefinir senha: objetos de computador descendentes

Em relação à Unidade Organizacional (UO) de destino que você planeja usar para farms e atribuições de área de trabalho VDI, essa conta também requer a permissão do Active Directory chamada Gravar Todas as Propriedades em todos os objetos descendentes dessa Unidade Organizacional (UO) de destino.

Consulte Contas de serviço que o Horizon Cloud exige para suas operações para obter mais detalhes.

No Microsoft Active Directory, quando você cria uma nova UO, pode ser que o sistema defina automaticamente o atributo Prevent Accidental Deletion que aplica um Deny à permissão Excluir Todos os Objetos Herdeiros para a UO recém-criada e todos os objetos descendentes. Como resultado, se você tiver atribuído explicitamente a permissão Excluir Objetos de Computador à conta de ingresso no domínio, no caso de uma UO recém-criada, o Active Directory poderá ter aplicado uma substituição a essa permissão Excluir Objetos de Computador explicitamente atribuída. Como limpar o sinalizador Impedir Exclusão Acidental pode não limpar automaticamente o Deny que o Active Directory aplicou à permissão Excluir Todos os Objetos Herdeiros, no caso de uma UO recentemente adicionada, talvez você precise verificar e limpar manualmente o conjunto de permissões Deny para as permissões Excluir Todos os Objetos Herdeiros na OU e todas as UOs herdeiras antes de usar a conta de ingresso no domínio no console do Horizon Cloud.

Conta de ingresso no domínio auxiliar opcional
Conta de ingresso no domínio do Active Directory que pode ser usada pelo sistema para executar operações Sysprep e ingressar os computadores virtuais no domínio. Normalmente, uma nova conta que você cria para essa finalidade expressa. (Uma conta de usuário de ingresso no domínio)

A conta deve ter o atributo sAMAccountName. O atributo sAMAccountName deve ter 20 caracteres ou menos e não pode conter nenhum dos seguintes caracteres: "/ \ [ ] : ; | = , + * ? < >

No momento, não há suporte para o uso de espaços em branco no nome de usuário da conta.

Você também deve definir a senha da conta como Nunca Expirar para garantir a capacidade contínua do Horizon Cloud para realizar as operações do Sysprep e ingressar os computadores virtuais no domínio.

Essa conta requer as permissões a seguir do Active Directory, aplicadas à UO de Computadores ou à UO que você inserirá na UI de Ingresso no Domínio do console.

  • Ler todas as propriedades: somente este objeto
  • Criar objetos de computador: esse objeto e todos os objetos descendentes
  • Excluir objetos de computador: esse objeto e todos os objetos descendentes
  • Gravar todas as propriedades: objetos de computador descendentes
  • Redefinir senha: objetos de computador descendentes

Em relação à Unidade Organizacional (UO) de destino que você planeja usar para farms e atribuições de área de trabalho VDI, essa conta também requer a permissão do Active Directory chamada Gravar Todas as Propriedades em todos os objetos descendentes dessa Unidade Organizacional (UO) de destino.

Consulte Contas de serviço que o Horizon Cloud exige para suas operações para obter mais detalhes.

No Microsoft Active Directory, quando você cria uma nova UO, pode ser que o sistema defina automaticamente o atributo Prevent Accidental Deletion que aplica um Deny à permissão Excluir Todos os Objetos Herdeiros para a UO recém-criada e todos os objetos descendentes. Como resultado, se você tiver atribuído explicitamente a permissão Excluir Objetos de Computador à conta de ingresso no domínio, no caso de uma UO recém-criada, o Active Directory poderá ter aplicado uma substituição a essa permissão Excluir Objetos de Computador explicitamente atribuída. Como limpar o sinalizador Impedir Exclusão Acidental pode não limpar automaticamente o Deny que o Active Directory aplicou à permissão Excluir Todos os Objetos Herdeiros, no caso de uma UO recentemente adicionada, talvez você precise verificar e limpar manualmente o conjunto de permissões Deny para as permissões Excluir Todos os Objetos Herdeiros na OU e todas as UOs herdeiras antes de usar a conta de ingresso no domínio no console do Horizon Cloud.

Grupos do Active Directory

  • Administradores do Horizon Cloud: Grupo de segurança do Active Directory para administradores do Horizon Cloud. Contém os usuários administrativos do Horizon Cloud. Esse grupo recebe a função Superadministrador no Horizon Cloud.
  • Usuários do Horizon Cloud: Grupo de segurança do Active Directory para os usuários que terão acesso a áreas de trabalho virtuais e aplicativos publicados e áreas de trabalho baseadas em sessão RDS no Horizon Cloud.

O Horizon Cloud é compatível com o uso de grupos de segurança personalizados do Active Directory para logins de administrador e direitos de usuário final. Há suporte para grupos aninhados. A associação ao grupo é avaliada, solicitando o atributo computado tokenGroups, o que significa que o Horizon Cloud não tem limitações de profundidade de aninhamento, mas oferece suporte ao que está definido no seu Active Directory.

Quando perguntada se há considerações adicionais ou limitações adicionais no contexto dos grupos do Active Directory e a combinação de Horizon Cloud mais Universal Broker e Workspace ONE Access Cloud, a resposta a essa pergunta é Não, nenhum.

Se o seu ambiente de tenant tiver algum pod do Horizon Cloud no Microsoft Azure executando manifestos anteriores ao 1600.0, a conta de ingresso no domínio e quaisquer contas auxiliares de ingresso no domínio também deverão estar no grupo de administradores do Horizon Cloud ou em um grupo do Active Directory que tenha recebido a função de Superadministrador no Horizon Cloud.

Unidade organizacional (OU) ou unidades organizacionais (UOs) do Active Directory para áreas de trabalho virtuais e áreas de trabalho com base em sessão RDS ou aplicativos publicados ou ambos.

No Microsoft Active Directory, quando você cria uma nova UO, pode ser que o sistema defina automaticamente o atributo Prevent Accidental Deletion que aplica um Deny à permissão Excluir Todos os Objetos Herdeiros para a UO recém-criada e todos os objetos descendentes. Como resultado, se você tiver atribuído explicitamente a permissão Excluir Objetos de Computador à conta de ingresso no domínio, no caso de uma UO recém-criada, o Active Directory poderá ter aplicado uma substituição a essa permissão Excluir Objetos de Computador explicitamente atribuída. Como limpar o sinalizador Impedir Exclusão Acidental pode não limpar automaticamente o Deny que o Active Directory aplicou à permissão Excluir Todos os Objetos Herdeiros, no caso de uma UO recentemente adicionada, talvez você precise verificar e limpar manualmente o conjunto de permissões Deny para as permissões Excluir Todos os Objetos Herdeiros na OU e todas as UOs herdeiras antes de usar a conta de ingresso no domínio no console do Horizon Cloud.

Se você quiser usar um Active Directory configurado para LDAPS, deverá solicitar a ativação dos recursos compatíveis do LDAPS com seu tenant do Horizon Cloud. Para obter mais detalhes, consulte Usar ambientes do Active Directory configurados para LDAPS.

Configuração do Universal Broker

Para a configuração do Universal Broker, preencha os itens da tabela a seguir que são aplicáveis às opções desejadas. Para obter detalhes completos, consulte Configurar o Universal Broker.

O acesso de saída à Internet nas VNets que você está usando para o pod deve resolver e acessar nomes DNS específicos usando portas e protocolos específicos. Isso é necessário para a configuração do Universal Broker e operações contínuas. Para obter a lista de nomes e portas DNS, consulte Tenants de primeira geração: Implantações do Horizon Cloud on Microsoft Azure: requisitos de resolução de nomes de host e nomes DNS e Tenants de primeira geração: pod do Horizon Cloud: requisitos de portas e protocolos.
Dependendo dos tipos de conexões de usuário final que você deseja fornecer:
  • Para conexões de usuário final da Internet e inicialização de áreas de trabalho e aplicativos virtuais, um pod deve ter um Unified Access Gateway externo configurado.
  • Se todas as suas conexões de usuário final forem sempre da sua rede interna, nenhum Unified Access Gateway será necessário no pod, exceto quando você quiser que o Universal Broker imponha a autenticação de dois fatores com essas conexões de usuários finais internos.
Opcional. Quando você deseja que o Universal Broker imponha a autenticação de dois fatores, os pods devem ter um Unified Access Gateway externo configurado para autenticação de dois fatores com um dos tipos de sistema de autenticação compatíveis para uso com implantações do Horizon Cloud on Microsoft Azure.

O Universal Broker passa a solicitação de autenticação para o Unified Access Gateway, que se comunica com o servidor de autenticação e, em seguida, retransmite a resposta para o Universal Broker.

Essa configuração do Unified Access Gateway externo requer os seguintes itens:

  • Endereços DNS para o Unified Access Gateway para resolver o nome do servidor de autenticação
  • Rotas para o Unified Access Gateway para resolver o roteamento de rede para o servidor de autenticação
Opcional: um FQDN personalizado que os usuários finais usarão para acessar o serviço do Universal Broker e o certificado com base nesse FQDN. Se você quiser usar o FQDN de intermediação fornecido pela VMware, não será necessário um FQDN personalizado.

Requisitos de registro DNS

Depois que o pod é implantado na nuvem do Microsoft Azure e, dependendo da sua situação de negócios e dos recursos que você deseja aproveitar, é importante configurar os registros no servidor DNS que mapeia nomes de domínio totalmente qualificados (FQDNs) para endereços IP relacionados ao pod. Para obter informações básicas sobre o mapeamento de registros DNS, consulte a página de documentação dos serviços de nuvem da Microsoft Configuração de um nome de domínio personalizado para um serviço de nuvem do Azure.

Observação: Se você implantou o pod com as configurações de gateway externo e interno com o mesmo FQDN, configure o DNS dividido (Sistema de nome de domínio dividido) para resolver o endereço do gateway como o gateway externo ou o gateway interno, dependendo da rede de origem da consulta de DNS do cliente de usuário final.
Quando você configura o Universal Broker do tenant usando um FQDN personalizado
Crie um registro DNS público que mapeie seu FQDN personalizado para o FQDN de intermediação fornecido pela VMware na configuração do Universal Broker. Consulte Configurar Universal Broker.
Quando o pod tem um Unified Access Gateway externo
Crie um registro DNS público para o acesso do usuário final externo que corresponda ao FQDN na configuração do gateway externo. Esse registro DNS aponta esse FQDN para o balanceador de carga externo do Microsoft Azure na configuração do Unified Access Gateway externo do pod.

Para obter informações básicas sobre o mapeamento de registros DNS, consulte a página de documentação da Microsoft Configuração de um nome de domínio personalizado para um serviço de nuvem do Azure.

Quando o pod tem um Unified Access Gateway interno
Crie um registro DNS interno para o acesso do usuário final interno que corresponda ao FQDN na configuração do gateway interno. Esse registro DNS pinta esse FQDN para o balanceador de carga interno do Microsoft Azure na configuração do Unified Access Gateway interno do pod.

Golden images, áreas de trabalho e farms do Horizon Cloud

Sua assinatura do Microsoft Azure deve acomodar os seguintes requisitos, dependendo dos tipos de golden images, áreas de trabalho VDI e farms RDS que você deseja provisionar com base no pod implantado.

Observação: Quando a conta estiver ativada para usar os recursos do App Volumes, e você usar a ação Capturar do console para adicionar aplicativos do App Volumes ao inventário, o sistema gerará uma atribuição de área de trabalho de duas VMs de área de trabalho para oferecer suporte ao fluxo de trabalho de captura. Sua capacidade precisará também acomodar a criação dessas áreas de trabalho enquanto você estiver realizando o fluxo de trabalho de captura. Você poderá excluir essa atribuição de área de trabalho ao terminar de capturar aplicativos para o seu ambiente.

Além disso, observe a matriz de suporte a seguir para o uso de modelos de VM de Geração 1, VM de Geração 2 da Microsoft Azure, com relação aos sistemas operacionais convidados Windows 10 e Windows 11.

Modelo de VM do Azure Windows 10 Windows 11
VM de Geração 1 Com suporte Sem suporte
VM de Geração 2 Sem suporte Com suporte
Base para a golden image: uma ou mais das configurações compatíveis de VM do Microsoft Azure.
  • Standard_DS2_v2
  • Standard_NV12s_v3 (para o assistente automatizado para Importar VM do Marketplace do serviço ou importação manual e driver gráfico NVIDIA GRID), Standard_NV8as_v4 (para o método de importação manual e driver gráfico AMD)
  • Standard_D4s_v3

Ao usar o assistente automatizado para Importar VM do Marketplace do console para criar uma VM base, o sistema usa automaticamente um dos tamanhos de VM acima por padrão. A escolha padrão do sistema baseia-se em suas configurações internas e no sistema operacional (SO) específico.

O sistema usa os modelos conforme indicado para imagens de pod único e imagens de vários pods.

O assistente de importação de VM do Marketplace cria:
  • Não GPU, não Windows 11, uma VM Standard_DS2_v2
  • Não GPU usando Windows 11, uma VM Standard_D4s_v3
  • Com capacidade para GPU, uma VM Standard_NV12s_v3
Seleção de modelo para as VMs de área de trabalho nas atribuições de área de trabalho VDI: qualquer uma das configurações de VM do Microsoft Azure disponíveis na região do Microsoft Azure, exceto aquelas não compatíveis com operações de área de trabalho do Horizon Cloud.

Para ambientes de produção, o teste de dimensionamento da VMware recomenda o uso de modelos que tenham no mínimo 2 CPUs ou mais.

Seleção de modelo para as VMs RDSH em farms: qualquer uma das configurações de VM do Microsoft Azure disponíveis na região do Microsoft Azure, exceto aquelas não compatíveis com operações de farm RDS do Horizon Cloud.

Esse requisito também se aplica a uma VM que executa o Microsoft Windows 10 Enterprise de várias sessões ou o Windows 11 Enterprise de várias sessões quando essa VM é usada com o Horizon Cloud. Conforme descrito nas Perguntas frequentes sobre o Microsoft Windows Enterprise de várias sessões na documentação da Área de Trabalho Virtual do Microsoft Azure, o Microsoft Windows Enterprise de várias sessões é um tipo de Host de Sessão de Área de Trabalho Remota (RDSH) que permite várias sessões interativas simultâneas, que, anteriormente, eram fornecidas apenas pelos sistemas operacionais Microsoft Windows Server. Os fluxos de trabalho do Horizon Cloud que se aplicam a servidores RDS são aplicáveis ao Microsoft Windows Enterprise de várias sessões.

Para ambientes de produção, o teste de dimensionamento da VMware recomenda o uso de modelos que tenham no mínimo 2 CPUs ou mais.

Requisitos do Serviço de Gerenciamento de Imagens (IMS)

A partir da versão de julho de 2021, quando os pods do Horizon Cloud estiverem executando o manifesto 2632 ou posterior e seu ambiente de tenant tiver o Universal Broker ativado, os recursos do Serviço de Gerenciamento de Imagens do Horizon estarão disponíveis para uso com esses pods. O uso dos recursos de imagem de vários pods fornecidos pelo serviço tem requisitos adicionais. Para obter todos os detalhes dos requisitos do sistema para uso desses recursos, consulte a seção do Microsoft Azure Requisitos do sistema do Serviço de Gerenciamento de Imagens do Horizon. Um resumo dos requisitos adicionais na assinatura do pod e no registro do aplicativo do Horizon Cloud dessa assinatura e sua entidade de serviço ao usar imagens de vários pods são descritos na tabela a seguir.

As assinaturas usadas por esses pods que participam de imagens de vários pods devem estar em um único tenant do Microsoft Azure Active Directory (AAD).
A entidade de serviço do registro do aplicativo do Horizon Cloud usada pelos pods que participam de imagens de vários pods deve atender a um dos seguintes requisitos:
  • Mesma entidade de serviço usada em todos os pods e assinaturas participantes.
  • Cada entidade de serviço deve ter acesso de leitura a cada assinatura do Microsoft Azure usada por esses pods participantes.

Como os pods provavelmente estão em assinaturas diferentes, o requisito de acesso de leitura permite que a assinatura de cada pod participante tenha uma linha de visão para as assinaturas dos outros pods participantes. Essa linha de visão é necessária para que o serviço use os recursos da Galeria de Imagens Compartilhadas do Azure para a criação das imagens de vários pods.

Quaisquer funções personalizadas usadas pelas entidades de serviço dos pods participantes devem incluir as permissões a seguir relacionadas ao uso da Galeria de Imagens Compartilhadas do Azure.
  • Microsoft.Compute/galleries/read
  • Microsoft.Compute/galleries/write
  • Microsoft.Compute/galleries/delete
  • Microsoft.Compute/galleries/images/*
  • Microsoft.Compute/galleries/images/versions/*

Licenciamento para os sistemas operacionais Microsoft Windows

Os itens estão relacionados aos sistemas operacionais Microsoft Windows nas suas VMs importadas, golden images, VMs do farm compatíveis com RDSH e VMs de área de trabalho virtual. Para obter a lista de sistemas operacionais Microsoft Windows compatíveis com o Horizon Cloud, consulte o Artigo 78170 da base de dados de conhecimento da VMware e o Artigo 70965 da base de dados de conhecimento da VMware.

O Horizon Cloud não fornece nenhum licenciamento de sistema operacional convidado necessário para o uso de sistemas operacionais Microsoft Windows que você utiliza durante o uso dos fluxos de trabalho do Horizon Cloud. Você, o cliente, tem a responsabilidade de possuir licenças válidas e elegíveis da Microsoft que lhe autorizem a criar, realizar fluxos de trabalho nas e operar as VMs de área de trabalho baseadas no Windows e as VMs RDSH que você escolhe usar em seu ambiente de tenant do Horizon Cloud. O licenciamento necessário depende do uso pretendido.

Dica: Para obter informações sobre o licenciamento da Área de Trabalho Virtual do Microsoft Azure específico para o Windows 11 Enterprise de várias sessões, o Windows 10 Enterprise de várias sessões e o Windows 7 Enterprise, consulte o tópico de documentação do Microsoft Azure Preços da Área de Trabalho Virtual do Azure.
Licenciamento para um ou mais dos seguintes tipos: Microsoft Windows 7 Enterprise, Microsoft Windows 10, Microsoft Windows 11 (tipos de cliente de sessão única, VDI)
Licenciamento para o Microsoft Windows 10 Enterprise de várias sessões ou o Microsoft Windows 11 Enterprise de várias sessões
Licenciamento para um ou mais dos seguintes tipos: Microsoft Windows Server 2012 R2, Microsoft Server 2016, Microsoft Server 2019
Servidores de licenciamento Microsoft Windows RDS – para alta disponibilidade, são recomendados servidores de licenciamento redundantes
CAL por usuário ou CAL por dispositivo do Microsoft RDS ou ambas

Arquitetura de referência

Use os diagramas de arquitetura abaixo como referência.

Figura 1. Ilustração da Arquitetura do Horizon Cloud Pod em que o pod tem configurações do gateway externo e interno, o gateway externo implantado na mesma VNet que o pod, três NICs nas VMs de gateway externo, duas NICs nas VMs de gateway interno e um IP público ativado para o balanceador de carga do gateway externo

Ilustração de arquitetura dos grupos de recursos, VMs e sub-redes do pod para um pod que tem os dois tipos de configurações do Unified Access Gateway, com o gateway externo residindo na mesma VNet que o pod.

Figura 2. Ilustração dos elementos de arquitetura do gateway externo quando o gateway externo é implantado em sua própria VNet, separado da VNet do pod, com três NICS, e em um grupo de recursos criado pelo implantador do pod

ilustração dos elementos de arquitetura do gateway externo quando o gateway externo é implantado em sua própria VNet, separado da VNet do pod e em um grupo de recursos criado pelo implantador do pod