Esta lista de verificação irá orientá-lo a preparar as suas assinaturas e redes do Microsoft Azure para a implantação de um pod do Horizon Cloud no Microsoft Azure. Garantir que esses requisitos sejam cumpridos, conforme descrito abaixo, fornecerá os dois para concluir uma implantação bem-sucedida de um novo pod e concluir com sucesso essas tarefas principais que são necessárias após a implantação de um pod.

Essa lista de verificação destina-se principalmente a contas de cliente do Horizon Cloud que nunca tiveram um pod implantado por meio de seu ambiente do tenant ou conectado a ele através da nuvem antes da data da versão de manutenção de julho de 2021. Esses ambientes podem ser chamados de ambientes novos ou ambientes greenfield. As implantações de novo pod que acontecerem após os binários de plano de nuvem e as versões de manifesto de novo pod serem enviados para o plano de nuvem na data da versão de manutenção serão implantadas usando a versão do manifesto do novo pod. Os requisitos para uma implantação de pod bem-sucedida são determinados principalmente pela versão do manifesto do pod. Os binários da camada de nuvem que estão na camada de nuvem de produção também podem determinar os requisitos para uma implantação bem-sucedida.

Alguns dos requisitos listados abaixo são aqueles necessários para a implantação do pod em si. Alguns requisitos são aqueles necessários para as principais tarefas que são realizadas após a implantação do pod para obter um ambiente de tenant produtivo, capaz de fornecer áreas de trabalho e aplicativos provisionados por pod a seus usuários finais.

Requisitos para a própria implantação do pod
Requisitos de ambiente produtivo após uma implantação de pod
Importante: Antes de iniciar o assistente de implantação de pod e começar a implantá-lo, além dos requisitos abaixo, você deve estar ciente dos seguintes pontos-chave:
  • A partir da versão de manutenção de julho de 2020, em ambientes totalmente novos, novos pods devem ser implantados com pelo menos uma configuração de gateway. Se a sua conta de cliente foi criada antes da versão de 2020 de julho, mas você ainda não tiver implantado o primeiro pod, a implantação desse primeiro pod exigirá a configuração de pelo menos uma configuração de gateway no momento da implantação do pod.
  • Uma implantação de pod bem-sucedida requer que nenhuma das políticas do Microsoft Azure que você ou sua equipe de TI tenha no ambiente do Microsoft Azure bloqueie, negue ou restrinja a criação dos componentes do pod. Além disso, você deve garantir que as definições de política interna das políticas do Microsoft Azure não bloqueiem, neguem nem restrinjam a criação dos componentes do pod. Por exemplo, você e sua equipe de TI devem garantir que nenhuma das políticas do Microsoft Azure bloqueie, negue ou restrinja a criação de componentes na conta de armazenamento do Azure. Para obter informações sobre as políticas do Azure, consulte a documentação da política do Azure.
  • O implantador do pod exige que a sua conta de armazenamento do Azure permita que o implantador use os tipos de conta StorageV1 e StorageV2 do Azure. Certifique-se de que suas políticas do Microsoft Azure não restrinjam nem neguem a criação de conteúdo que requer os tipos de conta StorageV1 e StorageV2 do Azure.
  • Como parte dos processos de implantação de gateway e de pod, a menos que você especifique tags de recursos personalizados no assistente de implantação, o Horizon Cloud cria grupos de recursos (RGs) na sua assinatura do Microsoft Azure que não têm etiquetas, incluindo o grupo de recursos inicial criado para a jumpbox temporária que orquestra esses processos de implantação. A partir da atualização do plano de nuvem de 8 de outubro de 2020, o assistente de implantação passou a ter um recurso no qual você pode especificar tags de recursos personalizadas que deseja aplicar aos grupos de recursos criados pelo implantador. Se você não especificar tags de recursos personalizadas e sua assinatura do Microsoft Azure tiver algum tipo de requisito de tag de recurso, a implantação do pod falhará se 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. 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. Para a lista de RGs que o implantador cria, consulte o tópico Grupos de recursos criados para um pod implantado no Microsoft Azure do Guia de administração.
  • Todos os pods conectados à nuvem devem ter linha de visão para o mesmo conjunto de domínios do Active Directory no momento em que você implantar esses pods.

Requisitos de camada de controle do Horizon Cloud

Conta ativa do My VMware para fazer logon na camada de controle do Horizon Cloud.

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 a própria assinatura, precisará de outra assinatura válida do Microsoft Azure no mesmo ambiente do 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 na assinatura do Microsoft Azure. Para obter informações adicionais, consulte Introdução ao controle de acesso com base em função no portal do Azure na documentação da Microsoft.
Capacidade mínima do Microsoft Azure disponível para a infraestrutura do Horizon Cloud, além da carga de trabalho esperada da área de trabalho e do aplicativo. Observe que, contanto que essa capacidade seja disponibilizada, o Horizon Cloud implantará automaticamente essas VMs, e nenhuma instalação manual será necessária.
  • Mecanismo de implantação de pod, também conhecido como jumpbox (transitório): 1 x Standard_F2
  • Pod/Gerenciador de pod com alta disponibilidade habilitada – 2 x Standard_D4_v3 (se não houver nenhum Standard_D4_v3 na região, 2 x Standard_D3_v2)
  • Pod/Gerenciador de pod sem alta disponibilidade habilitada – 1 x Standard_D4_v3 (se não houver nenhum Standard_D4_v3 na região, 1 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
  • Unified Access Gateway externo (opcional, a menos que nenhum gateway interno seja especificado): 2 x Standard_A4_v2 ou 2 x Standard_F8s_v2
  • Unified Access Gateway interno (opcional, a menos que nenhum gateway externo seja especificado): 2 x Standard_A4_v2 ou 2 x Standard_F8s_v2
Importante: Conforme declarado em Limites de serviço do VMware Horizon Cloud Service on Microsoft Azure, 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. Use F8s_v2 se você antecipar que seu ambiente ultrapassará 1.000 sessões ativas por pod.
  • A partir da versão de manutenção de julho de 2020, em ambientes totalmente novos, novos pods devem ser implementados com pelo menos uma configuração de gateway. Se a sua conta de cliente foi criada antes da versão de 2020 de julho, mas você ainda não tiver implantado o primeiro pod, a implantação desse primeiro pod exigirá a configuração de pelo menos uma configuração de gateway no momento da implantação do pod. Como resultado, sua capacidade mínima do Microsoft Azure disponível deve acomodar as VMs para uma das configurações de gateway, conforme descrito na lista anterior.
  • Se a região da assinatura não fornecer os tamanhos de VM Standard_F8s_v2, o assistente do implantador de pod não exibirá essa opção no seletor na etapa do assistente Especificar Gateways.
  • Após a conclusão da implantação do pod, sua capacidade na nuvem do Microsoft Azure também terá que acomodar as VMs importadas, as golden images, as áreas de trabalho virtuais e os farms RDSH que você criar nesse pod. Quando a sua conta estiver ativada para usar os recursos do App Volumes, e você usar o fluxo de trabalho de captura de aplicativos do console, sua capacidade também terá que acomodar as VMs na atribuição de área de trabalho gerada pelo sistema usada para esse processo de captura. Consulte a seção Imagens base, áreas de trabalho e farms do Horizon Cloud abaixo.
  • Quando a sua conta de tenant estiver ativada para usar o recurso do Monitoramento de Infraestrutura do Horizon, e você estiver planejando ativar esse recurso no pod depois que o pod for implantado, sua capacidade também terá de acomodar nesse momento a implantação do Dispositivo virtual do Horizon Edge. Leia a seção Requisitos de monitoramento de Infraestrutura do Horizon abaixo.

O Unified Access Gateway externo pode ser implantado opcionalmente na própria rede virtual (VNet) do Microsoft Azure, usando a mesma assinatura do pod ou usando uma assinatura diferente. Ao implantar o Unified Access Gateway externo na própria VNet, é necessária a seguinte capacidade na assinatura em que o Unified Access Gateway externo é implantado:

  • Mecanismo de implantação externo do Unified Access Gateway, também conhecido como jumpbox de gateway (transitório), 1 x Standard_F2
  • Conector de gateway externo: 1 x Standard_A1_v2
  • Unified Access Gateway externo: 2 x Standard_A4_v2 ou 2 x Standard_F8s_v2.
Importante: Repita esse texto aqui para que seja claramente visível nessa área sobre a implantação opcional do gateway externo em uma VNet separada. Conforme declarado em Limites de serviço do VMware Horizon Cloud Service on Microsoft Azure, 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. Use F8s_v2 se você antecipar que seu ambiente ultrapassará 1.000 sessões ativas por pod.
Entidade de serviço e chave de autenticação criadas para cada assinatura. Para ver mais detalhes, consulte Usar um portal para criar um aplicativo e uma entidade de serviço do Azure Active Directory que possa acessar recursos. Consulte também Crie a entidade de serviço necessária para o implantador do pod do Horizon Cloud através da criação de um registro de aplicativo.
Cada entidade de serviço deve receber a atribuição da função adequada que possibilita as ações que o Horizon Cloud deve realizar na assinatura. Essa função pode ser a função de Colaborador ou a uma função personalizada com as ações necessárias permitidas no nível da assinatura. Quando você estiver implantando a configuração de gateway externo em um grupo de recursos existente em uma assinatura separada, as permissões mais detalhadas poderão ser definidas para a entidade de serviço dessa assinatura. Para obter detalhes adicionais sobre as ações de função necessárias, consulte Operações exigidas pelo Horizon Cloud em suas assinaturas do Microsoft Azure.
Importante: A função deve ser atribuída diretamente à entidade de serviço usada para Horizon Cloud. O uso de uma atribuição baseada em grupo de uma função para a entidade de serviço: na qual a função é atribuída a um grupo, e a entidade de serviço é um membro desse grupo: não é suportada.
Provedores de recursos necessários registrados em cada assinatura do Microsoft Azure. Consulte Os provedores de recursos que o Horizon Cloud exige que estejam com status Registrado na assinatura do Microsoft Azure.
ID de assinatura do Microsoft Azure, ID do diretório, chave e ID do aplicativo identificados.
Se você estiver implantando o Unified Access Gateway externo em uma VNet separada usando sua própria assinatura, e sua organização exigir o uso de um grupo de recursos controlado por você e não criado pelo implantador do pod, use o recurso para implantar o Unified Access Gateway externo no seu próprio grupo de recursos nomeado. O uso desse 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 do Unified Access Gateway no processo de atualização do pod padrão. Para obter detalhes sobre as permissões necessárias, consulte Operações exigidas pelo Horizon Cloud em suas assinaturas do Microsoft Azure.

Requisitos de rede

Rede virtual do Microsoft Azure (VNet) criada na região desejada do Microsoft Azure com espaço de endereço aplicável para cobrir as sub-redes necessárias. Para obter mais detalhes, consulte Rede virtual do 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.
Observação: Para novos pods implantados no manifesto 2298.0 ou posterior, 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 o Guia de Administração.
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 para um pod do Horizon Cloud na Microsoft e recursos de serviço relacionados e Requisitos de portas e protocolos para um pod do Horizon Cloud no manifesto da versão de setembro de 2019 ou posteriores.
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)
Rota do Microsoft Azure VPN/Express configurada (opcional)
FQDN para acesso de usuário externo e interno ou ambos (necessário ao implantar um pod com o Unified Access Gateway).
Observação: A partir da atualização do plano de nuvem de 15 de dezembro de 2020, ter FQDNs diferentes para as configurações do gateway externo do pod e do gateway interno é compatível. Antes de 15 de dezembro de 2020, o sistema aplicava o mesmo FQDN para um pod de manifesto 2298 e posteriores. Agora, é a sua escolha se você deseja que os gateways do pod usem FQDNs diferentes ou o mesmo FQDN. Se você quiser usar o mesmo FQDN em ambos os gateways, após a implantação do pod, 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. Em seguida, o mesmo FQDN usado no cliente do usuário final poderá rotear para o gateway externo quando o cliente estiver na Internet e rotear para o gateway interno quando o cliente estiver na sua rede interna.
Certificado ou certificados para o Unified Access Gateway no formato PEM correspondente ao FQDN (necessário ao implantar um pod com o Unified Access Gateway).
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.
Autenticação de dois fatores para um servidor de autenticação RADIUS local (opcional)
  • 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
Observação: Depois que o pod é implantado, quando você planeja definir o ambiente para usar o Universal Broker para que as áreas de trabalho sejam configuradas aos seus usuários finais, é necessária uma configuração adicional quando você deseja ignorar a autenticação de dois fatores para os usuários finais em sua rede interna. As instâncias internas do Unified Access Gateway do pod roteiam as solicitações de conexão para áreas de trabalho virtuais e aplicativos para esses usuários finais internos. Quando haverá uma configuração de gateway interno no pod, você planeja definir o ambiente para usar o Universal Broker e deseja usar a autenticação de dois fatores para os usuários finais externos, mas ignorar essa autenticação para os usuários finais internos, depois que o pod for implantado, você deverá inserir intervalos de IP de modo que o Universal Broker seja usado para identificar os usuários finais internos diferenciando-os dos usuários externos com o objetivo de ignorar a autenticação de dois fatores. Para obter detalhes, consulte o tópico de documentação Configurar um método de intermediação e atribuições de usuário final em seu ambiente de tenant do Horizon Cloud e seus subtópicos.

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 Requisitos de portas e protocolos para um pod do Horizon Cloud no manifesto da versão de setembro de 2019 ou posteriores.

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 Fluxo de trabalho de alto nível para adicionar um pod do Horizon no Microsoft Azure como primeiro pod ao seu ambiente de tenant do Horizon Cloud 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

Os itens a seguir são necessários para o fluxo de trabalho de registro do Active Directory. Para compreender 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. Você pode ver a lista de verificação para esses pods do Horizon em Pods do VMware Horizon com o Horizon Cloud: lista de verificação de requisitos: atualização conforme apropriado para a conexão de pods a partir da versão de manutenção de julho de 2021.
Importante: Leia Contas de serviço que o Horizon Cloud requer para suas operações para ver as principais características que essa conta deve ter.

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)
  • 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, definidas no tópico da documentação 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.

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.

Para obter mais detalhes e requisitos, consulte Contas de serviço que o Horizon Cloud requer para suas operações

Importante: Leia Contas de serviço que o Horizon Cloud requer para suas operações para ver as principais características que essa conta deve ter.

Conta de BIND de domínio auxiliar: não pode usar a mesma conta que a mencionada acima

  • 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)
  • 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, definidas no tópico da documentação 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.

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.

Importante: Leia Contas de serviço que o Horizon Cloud requer para suas operações para ver as principais características que essa conta deve ter.

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 de Sysprep e ingressar computadores no domínio, normalmente uma nova conta (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: "/ \ [ ] : ; | = , + * ? < >
  • Defina a senha da conta como Nunca Expirar
  • Essa conta requer as seguintes permissões do Active Directory: ler todas as propriedades, redefinir a senha, criar objetos de computador, excluir objetos de computador, gravar todas as propriedades
    Observação: A partir do manifesto do pod 2474.0, as permissões necessárias para a conta de ingresso no domínio são reduzidas do conjunto anterior usado para manifestos anteriores a 2474 e, agora, incluem Gravar Todas as Propriedades em Objetos de Computador Descendentes. Os pods que executam manifestos anteriores ainda exigem o conjunto anterior de permissões. Consulte Contas de serviço que o Horizon Cloud exige para suas operações para obter detalhes.
  • Essa conta também requer a permissão do Active Directory chamada Gravar Todas as Propriedades em todos os objetos descendentes da Unidade Organizacional (UO) de destino que pretende usar para farms e atribuições de área de trabalho VDI.
  • Para obter mais detalhes e requisitos, consulte Contas de serviço que o Horizon Cloud requer para suas operações
Observação:
  • No momento, não há suporte para o uso de espaços em branco no nome de usuário da conta. Se o nome contiver um espaço em branco, ocorrerão resultados inesperados nas operações do sistema que dependerem dessa conta.
  • 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.
  • Antes do manifesto 1600.0, essa conta exigia as permissões da função de superadministrador do sistema. 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 deverá estar no grupo descrito Administradores do Horizon Cloud. O sistema usa essa conta de ingresso no domínio com todos os pods do Horizon Cloud do seu tenant no Microsoft Azure. Quando o seu tenant tem pods de manifestos existentes anteriores ao 1600.0, a conta de ingresso no domínio deve atender a esse requisito. Consulte Contas de serviço que o Horizon Cloud exige para suas operações para obter detalhes.
Importante: Leia Contas de serviço que o Horizon Cloud requer para suas operações para ver as principais características que essa conta deve ter.

Conta de ingresso no domínio auxiliar (opcional, não pode usar a mesma conta que a mencionada acima)

  • Conta de ingresso no domínio do Active Directory que pode ser usada pelo sistema para executar operações de Sysprep e ingressar computadores no domínio, normalmente uma nova conta (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: "/ \ [ ] : ; | = , + * ? < >
  • Defina a senha da conta como Nunca Expirar
  • Essa conta requer as seguintes permissões do Active Directory: ler todas as propriedades, redefinir a senha, criar objetos de computador, excluir objetos de computador, gravar todas as propriedades
    Observação: A partir do manifesto do pod 2474.0, as permissões necessárias para a conta de ingresso no domínio são reduzidas do conjunto anterior usado para manifestos anteriores a 2474 e, agora, incluem Gravar Todas as Propriedades em Objetos de Computador Descendentes. Os pods que executam manifestos anteriores ainda exigem o conjunto anterior de permissões. Consulte Contas de serviço que o Horizon Cloud exige para suas operações para obter detalhes.
  • Essa conta também requer a permissão do Active Directory chamada Gravar Todas as Propriedades em todos os objetos descendentes da Unidade Organizacional (UO) de destino que você pretenda usar para farms e áreas de trabalho virtuais VDI.
  • Para obter mais detalhes e requisitos, consulte Contas de serviço que o Horizon Cloud requer para suas operações
Observação:
  • No momento, não há suporte para o uso de espaços em branco no nome de usuário da conta. Se o nome contiver um espaço em branco, ocorrerão resultados inesperados nas operações do sistema que dependerem dessa conta.
  • 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.
  • Antes do manifesto 1600.0, essa conta exigia as permissões da função de superadministrador do sistema. 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 deverá estar no grupo descrito Administradores do Horizon Cloud. O sistema usa essa conta de ingresso no domínio com todos os pods do Horizon Cloud do seu tenant no Microsoft Azure. Quando o seu tenant tem pods de manifestos existentes anteriores ao 1600.0, a conta de ingresso no domínio deve atender a esse requisito. Consulte Contas de serviço que o Horizon Cloud exige para suas operações para obter detalhes.
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.
Observação: 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.
Observação: 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.

Requisitos do Universal Broker

A partir da versão de julho de 2020, quando seu ambiente de tenant do Horizon Cloud for uma conta totalmente nova a partir dessa data, e você acabar de concluir a implantação do primeiro pod no Microsoft Azure, você poderá optar por usar o Universal Broker como o método de intermediação para o ambiente. Quando você opta por configurar o Universal Broker para o seu ambiente, os itens a seguir são necessários. Consulte Configurar 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 Requisitos de DNS para um pod do Horizon Cloud na Microsoft e recursos de serviço relacionados e Requisitos de portas e protocolos para um pod do Horizon Cloud no manifesto da versão de setembro de 2019 ou posteriores.
Opcional: configure os gateways do pod para a autenticação de dois fatores com um servidor de autenticação RADIUS se você quiser que o Universal Broker use a autenticação de dois fatores para o pod.
  • 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 (opcional)

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.

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.
Se você tiver configurado o Universal Broker com um FQDN personalizado, crie um registro DNS público que mapeie o FQDN personalizado para o FQDN de intermediação fornecido pela VMware na configuração do Universal Broker. Consulte Configurar Universal Broker.
O registro DNS público criado para o acesso externo do usuário final que corresponde ao FQDN na configuração do gateway externo, apontando para o balanceador de carga externo do Microsoft Azure na configuração externa do Unified Access Gateway do pod (necessário quando o pod implantado tem essa configuração). Para obter mais detalhes, consulte Como configurar um nome de domínio personalizado para um serviço de nuvem do Azure.
O registro DNS interno criado para acesso do usuário final interno que corresponde ao FQDN na configuração do gateway interno, apontando para o balanceador de carga interno do Microsoft Azure na configuração interna do pod do Unified Access Gateway (necessário quando o pod implantado tem essa configuração).
Registro DNS interno criado quando você planeja escolher a intermediação de pod único para sua implantação e integrará a implantação com o VMware Workspace ONE Access. Nesse cenário, esse registro DNS interno dá suporte às conexões do VMware Workspace ONE Access com o pod, em que o VMware Workspace ONE Access Connector sincroniza as informações sobre atribuições de usuários do pod. Esse registro DNS interno corresponde ao FQDN no certificado que você carregará no próprio pod e aponta para o balanceador de carga interno do Microsoft Azure do gerenciador de pods. Obrigatório quando você deseja usar o VMware Workspace ONE Access com um pod em um ambiente configurado para a intermediação de pod único.
Observação: Esse registro DNS interno e um certificado correspondente que é carregado no próprio pod também são usados no caso de uso raro e atípico em que você precisa pedir que os usuários finais internos se conectem diretamente ao pod, em vez de pedir que se conectem a uma configuração interna do Unified Access Gateway no pod. Essas conexões diretas são um caso de uso atípico. Normalmente, é usado um Unified Access Gateway interno.
Cadeia de certificados (certificado de autoridade de certificação, certificado SSL, arquivo de chave SSL) que corresponde ao registro DNS interno criado para conexões do VMware Workspace ONE Access com o pod. Para obter mais detalhes, consulte Carregar certificados SSL em um pod do Horizon Cloud para conexões diretas. (Também necessário se você estiver utilizando o caso de uso atípico de pedir que usuários finais internos se conectem diretamente ao pod. As conexões diretas são um uso raro e atípico. Normalmente, é usado um Unified Access Gateway interno.)

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.
Base para a golden image: uma ou mais das configurações compatíveis de VM do Microsoft Azure.
  • Standard_D3_v2, Standard_D4_v3
  • Standard_D2_v2, Standard_D2_v3
  • Standard_NV6

Ao ser usado o assistente de Importação de VM do Marketplace automatizada da página Imagens para criar uma VM base, o sistema usa automaticamente um dos tamanhos de VM acima por padrão. A opção padrão do sistema é baseada em algoritmos internos que incluem verificar quais tamanhos estão disponíveis na região do Microsoft Azure do pod. Ao usar o assistente para criar uma VM ativada para GPU, a VM de tamanho de Standard_NV6 é criada por padrão. Ao usar o assistente para criar uma VM baseada em sistema operacional de servidor, uma VM Standard_D2_v2 ou Standard_D2_v3 é criada. Ao criar uma VM baseada no sistema operacional do cliente ou uma VM de várias sessões do Windows 10, uma VM Standard_D3_v2 ou Standard_D4_v3 é criada.

Observação: 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 estiver configurado para usar o Universal Broker, os recursos do Serviço de Gerenciamento de Imagens do Horizon para imagens de vários pods estarão disponíveis para a criação de golden images para áreas de trabalho VDI de sessão única. Executar o fluxo de trabalho Nova Imagem na página Imagens de Vários Pods criará uma VM de Standard_D2_v2 por padrão. Quando a opção para GPU estiver ativada, executar o fluxo de trabalho Nova Imagem na página Imagens de Vários Pods criará uma VM de Standard_NV6 por padrão.
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 as várias sessões do Windows 10 Enterprise da Microsoft quando essa VM é usada com o Horizon Cloud. Conforme descrito nas Perguntas frequentes sobre as várias sessões do Windows 10 Enterprise da Microsoft na documentação da área de trabalho virtual do Windows do Microsoft Azure, o com as várias sessões do Windows 10 Enterprise da Microsoft é 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 do Microsoft Windows Server. Os fluxos de trabalho do Horizon Cloud que se aplicam a servidores RDS são aplicáveis ao Microsoft Windows 10 Enterprise Multi-Session.

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 estiver configurado para usar o Universal Broker, 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. Uma descrição dos requisitos adicionais da assinatura e da entidade de serviço ao serem usadas imagens de vários pods pode ser encontrada 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 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.

As funções personalizadas usadas pelas entidades de serviço dos pods participantes devem incluir as seguintes permissões 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 Windows para as várias sessões do Windows 10 Enterprise e para o Windows 7 Enterprise, consulte o tópico da documentação do Microsoft Azure denominado Preços da área de trabalho virtual do Windows.
Licenciamento para um ou mais dos seguintes tipos: Microsoft Windows 7 Enterprise, Microsoft Windows 10 (tipos de cliente)
Licenciamento para as várias sessões do Windows 10 Enterprise da Microsoft
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

Requisitos de monitoramento de Infraestrutura do Horizon

Se o seu tenant do Horizon Cloud estiver ativado para usar o Monitoramento de Infraestrutura do Horizon, você poderá usar o Horizon Universal Console para ativar esse recurso na sua escolha de pods. Quando você opta por ativar esse recurso em um pod, o sistema cria automaticamente um dispositivo virtual na mesma assinatura do Microsoft Azure onde esse pod reside e configura que esse dispositivo colete os dados da infraestrutura. Antes de ativar esse recurso de monitoramento, seu tenant deve ser integrado ao VMware Cloud Services. Consulte Integrar seu tenant do Horizon Cloud ao VMware Cloud Services e Monitoramento de infraestrutura do Horizon e os pods no ambiente do Horizon Cloud.

Integre o seu tenant ao VMware Cloud Services.
Para cada pod no qual você ativará o recurso do Monitoramento de Infraestrutura do Horizon, a assinatura do Microsoft Azure do pod deverá acomodar esses requisitos adicionais.
  • Dispositivo virtual do Horizon Edge: 1 x Standard_D4_v3

Arquitetura de referência

Use os diagramas de arquitetura abaixo como referência.

Figura 1. Ilustração da arquitetura do Horizon Cloud Pod para um pod com alta disponibilidade habilitada, com configurações de gateway interno e externo, o gateway externo implantado na mesma VNet do pod, três NICs nas VMs de gateway externo, duas NICs nas VMs de gateway interno e um IP público habilitado para o balanceador de carga do gateway externo

Ilustração de arquitetura dos grupos de recursos, VMs e sub-redes do pod que tem alta disponibilidade habilitada e ambos os tipos de configurações do Unified Access Gateway, com o gateway externo que reside 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

Recursos

Consulte os recursos a seguir para obter informações adicionais.