Esta é uma lista de alto nível das etapas em que você está chegando ao primeiro pod conectado à nuvem por meio da execução do implantador de pod para implantar um pod baseado em gerenciador de pods na assinatura do Microsoft Azure. Esse tipo de pod baseia-se na tecnologia de gerenciador de pods do VMware Horizon Cloud (em comparação com um pod do Horizon que se baseia em componentes de software do Horizon Connection Server). Depois que esse primeiro pod conectado à nuvem tiver sido totalmente implantado e você tiver concluído as etapas para registrar o Horizon Cloud com o domínio do Active Directory pretendido do pod, será possível usar todos os recursos fornecidos do Horizon Cloud, especialmente para o provisionamento de áreas de trabalho VDI de sessão única, áreas de trabalhos de várias sessões, áreas de trabalhos de sessão baseadas em RDSH ou aplicativos remotos para os usuários finais por meio desse pod. Quando a sua conta de cliente está configurada para usar os recursos do App Volumes com os pods no Microsoft Azure, você também pode provisionar aplicativos desses recursos do App Volumes e autorizá-los aos usuários finais.

Observação: Esse fluxo de trabalho é especificamente para implantar um pod do Horizon Cloud no Microsoft Azure e não para implantar um pod do Horizon na Solução da VMware do Azure (AVS), que usa a tecnologia Horizon Connection Server.
Importante: O console administrativo é dinâmico e reflete o que está disponível no nível de serviço atual. No entanto, quando você tiver pods conectados à nuvem ainda não atualizados para o nível mais recente do software do pod, o console não exibirá os recursos que variam de acordo com o nível de software mais recente do pod. Além disso, em uma versão específica, o Horizon Cloud pode incluir recursos ou recursos licenciados separadamente que só estão disponíveis para configurações de contas de tenant específicas. O console reflete dinamicamente os elementos relacionados a esses recursos somente quando sua licença ou configuração de conta de tenant inclui o uso desses recursos. Para obter exemplos, consulte o Tour do console com base na nuvem para tarefas administrativas no Horizon Cloud.

Quando você espera ver um recurso no console administrativo, mas ele não está visível, entre em contato com seu representante de contas da VMware para verificar se sua configuração de conta de licença e ou de tenant autoriza seu uso.

Execute as seguintes etapas quando for implantar seu primeiro pod conectado à nuvem e usar o assistente de implantação de pod no Horizon Universal Console para implantá-lo no Microsoft Azure.

  1. Atenda aos pré-requisitos. Consulte a Lista de verificação de requisitos do VMware Horizon Cloud Service on Microsoft Azure para novas implantações de pod.
  2. Execute as tarefas preparatórias fora do Horizon Cloud. Consulte Preparação da implantação de um pod do Horizon Cloud no Microsoft Azure.
  3. Verifique se você atende aos requisitos de DNS, de portas e de protocolo para a implantação do pod. 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 posterior.
  4. Implante o pod.
  5. Registre seu domínio do Active Directory com o pod implantado, o que inclui fornecer os nomes de contas de serviço. Certifique-se de que essas contas de serviço atendem aos requisitos descritos em Contas de serviço que o Horizon Cloud exige para suas operações
  6. Atribua as funções apropriadas a indivíduos na sua organização para autenticação no Console Administrativo e execução de operações nele. Há dois tipos de funções que são usadas no Horizon Cloud. Consulte Boas práticas sobre os dois tipos de função que você concede às pessoas para usarem o console com base na nuvem para trabalhar no ambiente do Horizon Cloud.
  7. Na situação rara e atípica em que o ambiente de tenant já tem pods do Horizon Cloud no Microsoft Azure que estão executando manifestos anteriores ao 1600.0, você deve dar a função de superadministrador do Horizon Cloud a um grupo do Active Directory que inclui a conta de ingresso no domínio como um membro. Consulte o tópico Atribuir funções administrativas do Horizon Cloud a grupos do Active Directory no Guia de administração.
  8. Selecione o tipo de intermediação que você deseja que os pods do tenant utilizem ao realizar a intermediação de recursos provisionados pelo pod para os usuários finais. Consulte o tópico Introdução ao Universal Broker e à intermediação de pod único, bem como os tópicos e subtópicos relacionados.
    Atenção: A conclusão desta etapa de seleção de intermediação antes de implantar pods adicionais no Microsoft Azure é uma boa prática.
  9. Crie os registros CNAME necessários no servidor DNS. Para obter informações sobre a finalidade desses CNAMEs, consulte Como obter as informações do balanceador de carga do gateway do pod do Horizon Cloud para mapear no servidor DNS. Quando o tenant do estiver configurado com o Universal Broker, consulte também os requisitos de registro CNAME incluídos em Definir as configurações do Universal Broker.
    Observação: Quando você tiver a configuração de gateway externo usando um endereço IP privado para o balanceador de carga do Azure da configuração, deverá ter um firewall ou NAT gerenciando o tráfego de Internet para esse endereço IP privado e esse firewall ou NAT deverá fornecer um endereço IP público e ser configurado de forma que o FQDN especificado durante a implantação da configuração do gateway externo possa ser resolvido publicamente. A camada de controle do Horizon Cloud deve ser capaz de se comunicar com o FQDN especificado para o gateway externo.
  10. Relacionado à etapa anterior, se você selecionar a configuração do agente de pod único na etapa anterior e planejar usar o Workspace ONE Access com o pod, execute estas etapas:
    • No servidor DNS, mapeie um nome de domínio completo (FQDN) para o endereço IP do balanceador de carga do Microsoft Azure do gerenciador de pods.
    • Obter um certificado SSL com base nesse FQDN mapeado

    Você carregará um certificado SSL para o pod que é baseado no FQDN que você mapeou para o endereço IP do balanceador de carga do Microsoft Azure do gerenciador de pods no DNS, para que as conexões que vão às VMs do gerenciador de pods façam conexões confiáveis. O Workspace ONE Access Connector usado quando você integra o Workspace ONE Access ao pod em uma configuração de agente de pod único deve fazer essa conexão confiável. O Workspace ONE Access Connector deve se conectar ao pod usando um FQDN mapeado para o endereço IP do balanceador de carga do Microsoft Azure do gerenciador de pods.

    Atenção: Quando seu ambiente estiver configurado para intermediação de pod único e você estiver integrando o Workspace ONE Access ao pod, deverá carregar um certificado SSL para o pod e configurar o Workspace ONE Access Connector para apontar para o pod, não para as configurações do Unified Gateway Access do pod.

    No entanto, tenha em mente que, após carregar um certificado SSL com base no FQDN mapeado para DNS, se você tentar se conectar digitando diretamente esse FQDN em um navegador - sem passar por um Workspace ONE Access corretamente configurado - esse uso de FQDN puro aparecerá como conexões não confiáveis com o navegador. A razão é porque apenas carregar esse FQDN em um navegador é uma conexão usando o HTML Access (Blast) e é assim que o HTML Access (Blast) se comporta. Como resultado, quando você carrega esse FQDN em um navegador, ele exibe o erro de certificado não confiável típico.

    Na ausência do Workspace ONE Access nesse tipo de configuração, para que as conexões que usam o HTML Access (Blast) (utilizando basicamente um navegador) evitem o erro de certificado não confiável exibido, você deverá colocar uma configuração de gateway no pod e fazer com que essas conexões usem o balanceador de carga e as instâncias do Unified Access Gateway dessa configuração de gateway. Se você não deseja expor seu FQDN à Internet, poderá implantar uma configuração interna do Unified Access Gateway. Essa configuração interna do Unified Access Gateway usa um balanceador de carga interno do Microsoft Azure com o qual os usuários finais, que são internos à sua rede corporativa, podem realizar conexões.

  11. Carregue um certificado SSL para o pod diretamente, usando a página de resumo do pod no Console Administrativo, se você pretender ter um ou ambos os casos de uso descritos na etapa anterior. Consulte Configurar certificados SSL nas VMs do Gerenciador do Pod do Horizon Cloud.
    Dica: Se o único caso de uso de acesso que você deseja suportar é onde as conexões irão para as instâncias do Unified Access Gateway do pod por meio do balanceador de carga conectado a essas instâncias, então carregar o certificado SSL diretamente para o pod será supérfluo. Ainda assim, realizar a etapa anterior imediatamente acima e esta etapa aqui é uma prática recomendada, pois garante que, se você um dia informar esse FQDN para que os usuários digitem em seus Horizon Clients, esses clientes poderão ter conexões confiáveis. Executar a etapa imediatamente anterior e esta também fornece a capacidade no dia um de integrar mais rapidamente o pod a um ambiente de agente de pod único com o Workspace ONE Access, pois você teria o FQDN mapeado e o certificado SSL já presente no pod.
  12. Opcional: se a sua conta de tenant do Horizon Cloud ainda não estiver integrada à Plataforma de envolvimento do VMware Cloud Services, considere fazer a integração dela agora. A integração com a Plataforma de envolvimento do VMware Cloud Services é um pré-requisito para ativar os recursos do Monitoramento de Infraestrutura do Horizon para os seus pods implantados no Microsoft Azure. Consulte Integração do seu tenant do Horizon Cloud à Plataforma de envolvimento VMware Cloud Services usando o console com base na nuvem.
  13. Opcional: ative o Monitoramento de Infraestrutura do Horizon. Um pré-requisito para essa ativação é que o seu tenant do Horizon Cloud deve ser integrado à Plataforma de envolvimento do VMware Cloud Services. Consulte Monitoramento de infraestrutura do Horizon e dos pods no seu ambiente de Horizon Cloud.
  14. Crie uma golden image. Criar uma golden image é um processo de várias etapas. Para obter uma visão geral de alto nível das várias maneiras de criar uma golden image que possa ser usada no tenant do Horizon Cloud, consulte Criação de imagens da área de trabalho para um pod do Horizon Cloud no Microsoft Azure. A criação de uma golden image começa com a importação de uma VM base, que você personaliza para as necessidades da sua empresa e do usuário final.
  15. Dependendo do tipo de atribuição de usuário final para o qual a imagem será usada, execute uma ou mais das etapas a seguir, conforme apropriado.
  16. Converta essa imagem em uma imagem atribuível, também conhecida como selamento ou publicação da imagem. Consulte Converter uma máquina virtual configurada em uma imagem atribuível.
  17. Para provisionar áreas de trabalho de sessão e aplicativos remotos por meio de uma imagem de várias sessões publicada:
    1. Crie um farm de áreas de trabalho para fornecer áreas de trabalho de sessão e crie atribuições autorizar os usuários finais a usarem essas áreas de trabalho. Consulte Criar um farm e Criar uma atribuição de área de trabalho de sessão RDSH.
    2. Crie um farm de aplicativos para fornecer aplicativos remotos, adicionar os aplicativos ao seu inventário de aplicativos e criar atribuições para autorizar os usuários a usarem esses aplicativos remotos. Consulte Criar um farm, Importar novos aplicativos remotos de farms RDSH e Criar uma atribuição de aplicativo remoto.
  18. Para provisionar as áreas de trabalho VDI de sessão única por meio de uma imagem da área de trabalho VDI de sessão única publicada, crie uma atribuição de área de trabalho VDI dedicada ou flutuante. Consulte Sobre atribuições de área de trabalho para pods do ambiente Horizon Cloud no Microsoft Azure e a seção relacionada sobre a criação dessas atribuições de área de trabalho.
  19. Para provisionar aplicativos do App Volumes aos usuários finais, adicione os aplicativos do App Volumes ao inventário de aplicativos e crie uma atribuição de aplicativo para autorizar os usuários finais a usá-los. Em seguida, crie uma atribuição de área de trabalho que autorize esses usuários finais para as áreas de trabalho de base nas quais eles podem usar esses aplicativos. A atribuição do aplicativo autoriza o uso dos aplicativos do App Volumes autorizados do usuário no sistema operacional Windows da área de trabalho do usuário. Consulte Aplicativos App Volumes - Visão geral e pré-requisitos.
  20. Quando um pod é implantado para ter a autenticação de dois fatores RADIUS para os gateways do pod, você deve concluir as seguintes tarefas:
    • Se você tiver configurado um gateway externo com configurações RADIUS, e esse servidor RADIUS não estiver acessível na mesma VNet usada pelo pod, ou na topologia VNet emparelhada se você tiver implantando o gateway externo na própria VNet, configure o servidor RADIUS a permitir conexões de cliente a partir do endereço IP do balanceador de carga do gateway externo. Em uma configuração gateway externo, as instâncias do Unified Access Gateway tentam entrar em contato com o servidor RADIUS usando esse endereço do balanceador de carga. Para permitir as conexões, verifique se o endereço IP do recurso do balanceador de carga que está no grupo de recursos do gateway externo está especificado como um cliente na configuração do seu servidor RADIUS.
    • Se você tiver configurado um gateway interno ou externo e seu servidor RADIUS estiver acessível na mesma VNet usada pelo pod, configure o servidor RADIUS para permitir conexões dos NICs apropriados que foram criados no grupo de recursos do gateway no Microsoft Azure que deve se comunicar com o servidor RADIUS. O administrador de rede determina a visibilidade da rede do servidor RADIUS para as sub-redes e a rede virtual do Azure do pod. Seu servidor RADIUS deve permitir conexões de cliente a partir dos endereços IP desses NICs de gateway que correspondem à sub-rede para a qual o administrador de rede forneceu visibilidade de rede ao servidor RADIUS. O grupo de recursos do gateway no Microsoft Azure tem quatro NICs que correspondem a essa sub-rede, duas que estão ativas atualmente para as duas instâncias do Unified Access Gateway e duas que estão ociosas e se tornarão as ativas após o pod passar por uma atualização. Para oferecer suporte à conectividade entre o gateway e o servidor RADIUS tanto para operações de pod contínuo quanto após cada atualização de pod, certifique-se de que os endereços IP dessas quatro NICs sejam especificados como clientes na configuração do servidor RADIUS.

    Para obter informações sobre como obter esses endereços IP, consulte Atualizar o seu sistema RADIUS com as informações necessárias do gateway do pod do Horizon Cloud.

Após a conclusão das etapas do fluxo de trabalho acima, seus usuários finais podem usar o Horizon Client ou o Horizon HTML Access (o Web Client) para iniciar as áreas de trabalho e os aplicativos remotos autorizados:

  • Em um ambiente configurado com o Universal Broker, usando seu FQDN de intermediação do Universal Broker no cliente.
  • Em um ambiente configurado com a intermediação de pod único, usando seu FQDN no cliente, aquele que você mapeou usando os registros CNAME no seu DNS.

Você pode encontrar mais detalhes sobre como concluir cada etapa do fluxo de trabalho nos tópicos vinculados de cada etapa acima.