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.

As seções neste tópico da documentação são:

Essa lista de verificação destina-se principalmente a contas de cliente do Horizon Cloud que nunca tiveram um pod implantado a partir de seu ambiente do tenant ou conectado a ele através da nuvem antes da data da versão de manutenção de 9 de julho de 2020. 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 camada de nuvem e as versões de manifesto de novo pod serem enviadas para a camada de nuvem na data da versão de manutenção trimestral de julho de 2020 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, 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 implantação do pod falhará se você tentar implantar um pod em uma assinatura do Microsoft Azure que tenha qualquer tipo de requisito de etiqueta de recursos no momento da implantação ou no momento das atualizações de pod ou de adição de uma configuração de gateway a um pod. Você deve 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
Observação:
  • 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 terá que também acomodar as imagens base, 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 de base, áreas de trabalho e farms do Horizon Cloud 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.
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.
Provedores de recursos necessários registrados em cada assinatura do Microsoft Azure. Consulte a etapa 8.b em Criar a entidade de serviço exigida pelo implantador de pod do Horizon Cloud através da criação de um registro de aplicativo.
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: A partir da versão trimestral de julho de 2020, para novos pods implantados no nível de manifesto dessa versão, depois que o pod for implantado, você poderá editar o pod para adicionar sub-redes de tenant adicionais 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 no Microsoft Azure 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: Para os pods implantados a partir da versão de julho de 2020, quando um pod tem os dois tipos de gateways, as configurações de gateway interno e externo no pod devem especificar o mesmo FQDN. Como os dois gateways usarão o mesmo FQDN, 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.
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:
  • Para os pods implantados a partir da versão de julho de 2020, as configurações de gateway interno e externo no pod devem especificar o mesmo FQDN. Como o certificado precisa coincidir com o FQDN, quando um pod tem os dois tipos de gateways, o mesmo certificado é usado em ambas as configurações de gateway.
  • 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

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 quando for implantar seu primeiro pod conectado à nuvem do Horizon Cloud e usar o implantador de pod para implantar um pod no Microsoft Azure 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 se aplica 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 no local ou na AWS que estejam conectados à nuvem, à mesma conta de cliente usando 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 2020.
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 as seguintes permissões:
    • Conteúdo da lista
    • Ler todas as propriedades
    • Permissões de leitura
    • Read tokenGroupsGlobalAndUniversal (implicado por Ler todas as propriedades)
    Observação:
    • 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

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 as seguintes permissões:
    • Conteúdo da lista
    • Ler todas as propriedades
    • Permissões de leitura
    • Read tokenGroupsGlobalAndUniversal (implicado por Ler todas as propriedades)
    Observação:
    • 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

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)
  • É membro do grupo de administradores do Horizon Cloud
  • Defina a senha da conta como Nunca Expirar
  • Essa conta requer as seguintes permissões do Active Directory: listar conteúdo, ler todas as propriedades, ler permissões, redefinir a senha, criar objetos de computador, excluir objetos de computador.
  • 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 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, 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)
  • É membro do grupo de administradores do Horizon Cloud
  • Defina a senha da conta como Nunca Expirar
  • Essa conta requer as seguintes permissões do Active Directory: listar conteúdo, ler todas as propriedades, ler permissões, redefinir a senha, criar objetos de computador, excluir objetos de computador.
  • 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 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 a conta de ingresso no domínio e usuários administrativos do Horizon Cloud. Esse grupo é adicionado à função de super administrador 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.
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 no Microsoft Azure 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: Para os pods implantados a partir da versão de julho de 2020, quando um pod tem os dois tipos de gateways, as configurações de gateway interno e externo no pod devem especificar o mesmo FQDN. Como os dois gateways usarão o mesmo FQDN, 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.
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, 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 o acesso interno do usuário final que corresponde ao FQDN, apontando para o balanceador de carga interno do Microsoft Azure na configuração interna do Unified Access Gateway do pod (necessário quando o pod implantado tem essa configuração).
Registro DNS interno criado para conexões do VMware Workspace ONE Access com o pod que corresponde ao certificado que você carregará para o pod em si, apontando para o balanceador de carga interno do Microsoft Azure do gerenciador de pod. Obrigatório quando você deseja usar o VMware Workspace ONE Access com o pod.
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.)

Imagem de base, áreas de trabalho e farms do Horizon Cloud

Sua assinatura do Microsoft Azure deve acomodar os seguintes requisitos, dependendo dos tipos de imagens mestre, das áreas de trabalho VDI e dos farms RDS que você deseja provisionar a partir do 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 imagem mestre: uma das configurações de VM do Microsoft Azure com suporte.
  • Standard_D3_v2, Standard_D4_v3
  • Standard_D2_v2, Standard_D2_v3
  • Standard_NV6
Observação: Ao usar o assistente de Importação de VM do Marketplace 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.
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.

Licenciamento para os sistemas operacionais Microsoft Windows

Os itens estão relacionados aos sistemas operacionais Microsoft Windows nas suas imagens mestre de base, nas VMs de farm compatíveis com RDSH e nas 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

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.