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 do Horizon Cloud na capacidade do Microsoft Azure. Após esse primeiro pod conectado à nuvem ser totalmente implantado e você tiver concluído as etapas para registrar o Horizon Cloud com o domínio do Active Directory pretendido do pod, você poderá usar todos os recursos fornecidos do Horizon Cloud, especialmente para o provisionamento de áreas de trabalho VDI, áreas de trabalhos baseadas em sessão RDSH ou aplicativos remotos baseados em RDSH para os seus usuários finais a partir 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.

Para obter uma introdução geral a pods no Microsoft Azure, consulte Introdução aos pods do Horizon Cloud no Microsoft Azure.

Execute as seguintes etapas quando for implantar seu primeiro pod conectado à nuvem e usar o assistente de implantação de pod 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 posteriores.
  4. Implante o pod. Consulte Implantação de um pod do Horizon Cloud no Microsoft Azure.
  5. Registre seu domínio do Active Directory com o pod implantado, o que inclui fornecer o nome de uma conta de ingresso no domínio. Consulte Realizando seu primeiro registro de domínio do Active Directory no ambiente do Horizon Cloud.
  6. Conceda a função de Superadministradores do Horizon Cloud a um grupo do Active Directory que inclua essa conta de ingresso no domínio como um membro.
    Importante: Você deve garantir que a conta de ingresso no domínio inserida ao registrar o domínio também esteja em um dos grupos do Active Directory ao qual você atribuiu a função de Superadministradores do Horizon Cloud. As operações de ingresso no domínio do sistema com o pod precisam que a conta de ingresso no domínio tenham a função de Superadministradores do Horizon Cloud. Consulte Atribuir funções a grupos do Active Directory que controlam quais áreas do Console administrativo do Horizon Cloud são ativadas para indivíduos nesses grupos após a autenticação em seu ambiente de tenant do Horizon Cloud
  7. 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 Introdução ao Universal Broker e ao agente 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.
  8. 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 ou se planejar a conexão do Horizon Clients diretamente ao pod (não por meio de uma configuração de gateway de 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. Essas conexões incluem o Horizon Clients para seus usuários aos quais você concede esse FQDN mapeado e o Workspace ONE Access Connector que é usado quando você integra o Workspace ONE Access ao pod em uma configuração de agente de pod único. 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.

  9. 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 diretamente nas VMs do gerenciador de pod, por exemplo, ao integrar o dispositivo Workspace ONE Access Connector ao pod do Horizon Cloud no Microsoft Azure, para que o Connector confie nas conexões com as VMs do gerenciador de pod.
    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.
  10. Importe uma imagem de base. Na página VMs Importadas, use a ação Redefinir Emparelhamento de Agente para emparelhar a nova imagem com o Horizon Cloud. Consulte Criação de imagens da área de trabalho para um pod do Horizon Cloud no Microsoft Azure.
    Observação: Visualização técnica: o uso do sistema operacional Microsoft Windows 10 Enterprise Multi-Session com o App Volumes está na visualização técnica por enquanto. Para importar uma imagem de base nesse caso de uso, use as seguintes etapas: Visualização técnica - Como configurar uma imagem com várias sessões do Microsoft Windows 10 para uso com os recursos do App Volumes nos pods do Horizon Cloud no Microsoft Azure.
  11. 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.
  12. Converta essa imagem em uma imagem atribuível, também conhecida como selamento ou publicação da imagem. Consulte Converter uma VM da imagem configurada em uma imagem atribuível no Horizon Cloud.
  13. Para provisionar áreas de trabalho RDSH baseadas em sessão RDSH e aplicativos remotos a partir de uma imagem de servidor publicada:
    1. Crie um farm RDSH 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 Farms no Horizon Cloud e Criar uma atribuição de área de trabalho de sessão RDSH.
    2. Crie um farm RDSH 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 Farms no Horizon Cloud, Aplicativos remotos – Importando de farms RDSH provisionados por pods Horizon Cloud no Microsoft Azure e Aplicativos remotos – criar uma atribuição de aplicativo remoto para aplicativos remotos provisionados por pods Horizon Cloud no Microsoft Azure.
  14. Para provisionar as áreas de trabalho VDI a partir de uma imagem da área de trabalho VDI publicada, crie uma atribuição de área de trabalho VDI dedicada ou flutuante. Consulte Criar uma atribuição de área de trabalho VDI flutuante provisionada por um único pod no Microsoft Azure e Criar uma atribuição de área de trabalho VDI dedicada provisionada por um único pod no Microsoft Azure.
  15. 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 com base na mesma imagem publicada para autorizar os usuários finais às áreas de trabalho em que eles podem inicializar esses aplicativos. Consulte Aplicativos App Volumes para Horizon Cloud no Microsoft Azure – visão geral e pré-requisitos.
  16. Quando um pod é implantado com uma configuração de gateway, você deve criar um registro CNAME no servidor DNS que mapeie o nome de domínio completo (FQDN) inserido no assistente de implantação para o recurso apropriado do balanceador de carga do Microsoft Azure configurado no pod para esse gateway.
    • Para um gateway externo habilitado com um endereço IP público, mapeie o FQDN que você inseriu no assistente de implantação para o FQDN público gerado automaticamente do recurso do balanceador de carga do Microsoft Azure do gateway. Seu registro do servidor DNS mapeia esse FQDN público gerado automaticamente do balanceador de carga do Microsoft Azure com o FQDN que os usuários finais usarão e que é usado no certificado enviado. A linha de código a seguir mostra um exemplo. Você localiza a ID a ser usada na página de detalhes do pod no console, após ter registrado o domínio do Active Directory. Se o gateway externo tiver sido implantado na própria VNet, use a ID exibida no campo ID de Implantação.
      ourApps.ourOrg.example.com   vwm-hcs-ID-uag.região.cloudapp.azure.com
    • Para um gateway interno ou externo sem um endereço IP público, mapeie o FQDN que você inseriu no assistente de implantação para o endereço IP privado do recurso do balanceador de carga do Microsoft Azure do gateway. Seu registro do servidor DNS mapeia esse endereço IP do balanceador de carga do Microsoft Azure com o FQDN que os usuários finais usarão e que é usado no certificado carregado. A linha de código a seguir mostra um exemplo.
      ourApps.ourOrg.example.com   Azure-load-balancer-private-IP

    Quando o pod estiver integrado, e você puder acessar a página Capacidade no console administrativo, navegue até a página Capacidade para ver o valor vmw-hcs-ID-uag.region.cloudapp.azure.com necessário para mapear o FQDN no DNS.

    Para obter detalhes sobre como localizar o FQDN do balanceador de carga do Microsoft Azure no console, consulte Como obter as informações do balanceador de carga do gateway do pod do Horizon Cloud para mapear no servidor DNS.

  17. 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 sistema RADIUS com as informações de gateway de pod do Horizon Cloud necessárias.

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 na etapa 16.

Você pode encontrar mais detalhes sobre como concluir cada etapa do fluxo de trabalho nos tópicos vinculados de cada etapa acima ou no guia complementar. Consulte Introdução ao VMware Horizon Cloud Service on Microsoft Azure.