EnglishFrançaisDeutschEspañolItaliano日本語한국어NederlandsPortuguês (Brasil)中文 (简体)中文 (繁體, 台灣)
Skip to main content

27 de agosto de 2025

Pré-requisitos para migrar um pod do Horizon Cloud de primeira geração

Esta página descreve as áreas que você deve avaliar, preparar e atualizar conforme necessário antes de iniciar a migração do primeiro pod.

Introdução

A maioria dessas avaliações e etapas de preparação podem ser feitas a qualquer momento antes de fazer login em seu novo ambiente do Horizon Cloud e ver a UI de migração.

Algumas dessas avaliações e etapas de preparação envolvem o ambiente de assinatura e a rede do Microsoft Azure na qual o pod de primeira geração é implantado. Para essas, talvez você precise de assistência da sua equipe de TI que lida com esse ambiente.

Lembre-se: no momento em que este artigo foi escrito, a elegibilidade para migrar um pod de primeira geração era uma implementação progressiva para locatários de primeira geração. Quando elegível, você receberá uma comunicação direta das Comunicações de Migração do Horizon.

Terminologia

O serviço do Horizon Cloud tem novos conceitos e terminologia. No serviço do Horizon Cloud, a implantação é chamada de Horizon Edge (em vez do termo pod).

A migração de autoatendimento foi projetada para implantar um Microsoft Azure Horizon Edge na mesma assinatura do Microsoft Azure usada para o pod de primeira geração migrando e usando as mesmas informações de assinatura, VNets e sub-redes.

À medida que cada pod é migrado, o processo reutiliza os seguintes itens por padrão desse pod:

  • ID da assinatura do Microsoft Azure, ID do diretório, ID do aplicativo da entidade de serviço e chave secreta.

  • VNet

  • Sub-rede de gerenciamento, sub-rede de locatário, sub-rede DMZ

  • Informações de domínio do Active Directory e BIND de domínio, e contas de serviço de BIND de domínio registradas no locatário de primeira geração (BIND de domínio e usuários de BIND de domínio, BIND de domínio auxiliar e usuário de BIND de domínio).

    Quando a migração do primeiro pod é agendada, o sistema copia todas as informações de domínio do Active Directory e as informações da conta de serviço do locatário de primeira geração e as registra no ambiente do Horizon Cloud.

Alguns itens do pod de primeira geração não são reutilizados. Para alguns desses, você deve configurar recursos novos e adicionais.

Portanto, você deve avaliar as seguintes áreas e se preparar conforme necessário para acomodar os requisitos do Horizon Cloud.

Observação: para pods com algumas características especiais, o processo de migração pode exigir o uso de uma nova VNet e sub-rede de gerenciamento diferente do pod de primeira geração. Este caso especial está descrito na seção desta página.

Tabela de Pré-requisitos

As seções que seguem esta tabela fornecem os detalhes de cada um desses pré-requisitos. Esta tabela está incluída como um contorno conveniente.

☐Obtenha novo FQDN e certificado para o Horizon Cloud Unified Access Gateway.
☐Avalie as versões do pod e do agente de primeira geração e atualize conforme necessário.
☐Verifique se todas as imagens que precisam ser migradas são válidas.
☐Determine se a VNet do pod ou as redes conectadas contêm endereços IP restritos ao AKS.
☐Decida sobre seu tipo de implantação e cumpra seus requisitos.
☐Na primeira geração, se o nome de sua assinatura do Microsoft Azure incluir caracteres que não estejam em inglês, renomeie a assinatura para usar somente caracteres em inglês antes de migrar para o Horizon Cloud.
☐Determine se a assinatura do Microsoft Azure do pod tem políticas em torno de tags de grupo de recursos. Em caso afirmativo, faça um plano de como lidar com o requisito de migração.
☐Rede: avalie as configurações existentes para o tráfego de rede e atualize conforme necessário.
☐Verifique se a chave secreta do aplicativo associada do pod ainda é válida.
☐VNet: avalie o roteamento atual que você está usando para acesso interno às áreas de trabalho.
☐Avalie as cotas da família de vCPUs do Microsoft Azure e aumente conforme necessário.
☐Avalie as Políticas do Azure na assinatura e no grupo de recursos do pod e verifique se as políticas permitem o provisionamento de contas de armazenamento e compartilhamentos de arquivos do Horizon Edge Gateway.
☐Quando o pod tiver aplicativos do App Volumes, siga as diretrizes em garantir que as políticas permitam a alternância do acesso à rede nas contas de armazenamento.
☐Quando você tiver um IP público para o balanceador de carga Unified Access Gateway, siga as orientações em quando um IP público para esse balanceador de carga.
☐Quando você tiver um IP privado para o balanceador de carga Unified Access Gateway, siga as orientações em quando um IP privado para esse balanceador de carga.
☐Avalie a capacidade de efetuar login em seu novo ambiente do Horizon Cloud e consulte o Horizon Cloud Horizon Universal Console.
☐Decida sobre o seu provedor de identidade e sincronize usuários e grupos do AD com ele.
☐Avalie seu uso de usuários ou grupos integrados do Active Directory e atualize conforme necessário.
☐Avalie o uso de atribuições do aplicativo do App Volumes.
☐Caso especial: se o registro do aplicativo do pod de primeira geração estiver usando uma função personalizada, atualize as permissões necessárias para uma implantação do Horizon Cloud seguindo as diretrizes em Se o registro do aplicativo do pod de primeira geração estiver usando uma função personalizada.

Obtenha um novo FQDN e um certificado para o Horizon Cloud Unified Access Gateway

Observação: o FQDN para a implantação do Horizon Cloud Unified Access Gateway deve ser diferente do FQDN já em uso para a implantação de primeira geração a ser migrada. Para oferecer suporte à reversão para a implantação de primeira geração no caso raro de problemas pós-migração, o FQDN do gateway da implantação de primeira geração e seu certificado SSL devem permanecer configurados para a implantação de primeira geração. Somente após finalizar a migração, você poderá atualizar o FQDN e o certificado SSL da implantação do gateway do Horizon Cloud, se desejar.

A UI do assistente de agendamento exige que você especifique esse FQDN no assistente e forneça o certificado SSL com base nesse FQDN.

Para o ambiente Horizon Cloud, o certificado SSL pode estar no formato PEM ou PFX.

O nome comum ou o FQDN definido no certificado deve corresponder ao FQDN que você planeja digitar no assistente de agendamento. O assistente valida se os dados no certificado correspondem ao FQDN digitado no assistente.

Observação: se seu pod de primeira geração tiver uma configuração externa do Unified Access Gateway e uma configuração interna do Unified Access Gateway, o Unified Access Gateway do Edge pós-migração terá seu tipo de acesso definido como Acesso interno e externo com o FQDN externo e o FQDN interno definidos como o mesmo FQDN por padrão (o FQDN que você insere no assistente de agendamento). Se, após a migração, você quiser usar um FQDN diferente para acesso interno, edite os detalhes do Unified Access Gateway do Edge para alterar seu FQDN interno para aquele que você deseja usar e configure os intervalos de rede para usuários internos adequadamente. Observe que o certificado carregado deve incluir o FQDN externo e o FQDN interno nas informações do certificado (como ter o FQDN interno nos dados do Nome Alternativo do Assunto).

Avalie as versões do Pod e do Agente de Primeira Geração e atualize conforme necessário

Antes que um pod possa ser migrado, as versões do pod e do agente devem atender a estes critérios:

  • Os pods do Horizon Cloud Azure devem executar o manifesto de pod 5041.0 ou posterior. Se estiver executando um manifesto anterior, inicie uma solicitação de serviço para fazer upgrade do pod.
  • As áreas de trabalho VDI dedicadas do pod devem estar executando o Horizon Agents Installer versão 24.2.0 ou posterior.

Garantir que todas as imagens a serem migradas sejam válidas

Para evitar problemas durante a fase de pré-compilação da migração, verifique se todas as imagens de primeira geração que precisam ser migradas estão no estado Publicado e se suas VMs e instantâneos estão intactos no Microsoft Azure.

Determinar se a VNet ou as redes conectadas do pod contêm endereços IP restritos do AKS

Importante: o resultado de sua determinação fornecerá diretrizes sobre qual tipo de implantação do Horizon Edge Gateway você escolherá usar para a migração. Os tipos estão descritos na próxima seção intitulada Decidir o tipo de implantação do Edge Gateway.

Determine se a sub-rede de gerenciamento do pod de primeira geração, a VNet ou as redes às quais a VNet está conectada (como sua rede local conectada por meio do ExpressRoute) contêm endereços IP dos intervalos restritos ao AKS listados aqui:

  • 169.254.0.0/16
  • 172.30.0.0./16
  • 172.31.0.0/16
  • 192.0.2.0/24

Se sim, para migrar esse pod, você deverá avaliar novamente se suas necessidades podem ser atendidas pelo tipo de implantação de VM única ou se você tem requisitos que apenas o tipo de implantação do AKS pode atender.

  • Use o tipo de implantação de VM única para migrar esse pod ou

  • Se os seus requisitos determinarem que você usa o tipo de implantação do AKS, deverá configurar uma nova VNet e uma sub-rede de gerenciamento de um CIDR /26 mínimo nessa VNet na assinatura do pod e emparelhar essa nova VNet com a VNet existente do pod. O CIDR mínimo /26 é uma recomendação forte para o tipo de implantação do AKS.

    Certifique-se de que nada na nova VNet contenha ou use endereços IP dos intervalos restritos. Com a nova VNet e a sub-rede de gerenciamento, você pode usar o tipo de implantação do AKS que o fornece para HA.

Consulte a próxima seção sobre como decidir sobre seu tipo de implantação do Edge Gateway para obter orientação detalhada.

O motivo pelo qual esses intervalos específicos são intervalos restritos ao AKS é porque a Microsoft impõe essa regra em relação aos seus clusters do Serviço do Azure Kubernetes (AKS) que são usados para o tipo AKS de implantação do Horizon Edge Gateway.

Se esses IPs restritos estiverem contidos na sub-rede ou VNet de gerenciamento do pod ou contidos na rede local conectada à VNet, o processo de migração usando o tipo AKS não poderá reutilização da VNet existente do pod.

Decida sobre seu tipo de implantação e cumpra seus requisitos

Na migração de um pod de primeira geração para o ambiente Horizon Cloud, o sistema implanta o que é chamado de Horizon Edge Gateway na assinatura do Microsoft Azure do pod.

A implantação vem em dois tipos: o tipo de Máquina Virtual Única (VM Única) ou o tipo do Serviço do Azure Kubernetes (AKS).

O sistema permite que você especifique o tipo a ser usado para a migração de cada pod.

Portanto, você deve decidir qual tipo usar, com base nas qualidades necessárias, de acordo com a tabela a seguir.

Implantação do Edge GatewayPrincipais QualidadesDetalhes
VM Única
  • Oferece suporte a até 5K (5.000) sessões.
  • Menos pré-requisitos envolvidos na assinatura do Microsoft Azure do que para o tipo AKS
  • Acomoda migrações de pods que não podem atender facilmente aos requisitos do AKS.
  • Se, em algum momento futuro, o implantado não estiver disponível, o comportamento resultante será:
    • Os usuários finais terão que fazer login sem single sign-on (SSO).
    • Os dados de monitoramento das áreas de trabalho não serão registrados durante o período em que a VM não estiver disponível.
O tipo de VM Única proporciona mais simplicidade ao migrar um pod de primeira geração por meio do tipo AKS. O motivo pelo qual essa escolha pode proporcionar mais simplicidade é porque o tipo de VM Única envolve menos requisitos novos na assinatura do Azure do pod do que o tipo do AKS requer. Como resultado, ele acomoda implantações de pod de primeira geração que não podem atender facilmente aos requisitos do tipo AKS. Além da simplicidade, o tipo de VM Única será diferente do tipo AKS em seu comportamento se a VM implantada ficar indisponível. Quando indisponível:
  • Os usuários finais verão o fluxo de login sem a experiência de login do SSO. Por exemplo, antes de ver a área de trabalho, eles terão que fazer login usando suas credenciais do Active Directory.
  • Os dados de monitoramento das áreas de trabalho que são enviados para a VM do Edge Gateway não são registrados durante o período em que a VM não está disponível.
AKS
  • Oferece suporte a mais de 5K (5.000) sessões.
  • O Serviço do Azure Kubernetes tem requisitos relacionados à Microsoft que devem ser cumpridos
  • Acomoda migrações de pod que podem atender aos requisitos do AKS.
  • A experiência de login do SSO e a coleta de dados de monitoramento são realizadas por meio de serviços replicados que permitem a entrega altamente disponível dessas funções
O AKS é um padrão do Microsoft Azure para aplicativos nativos da nuvem corporativa nos centros de dados do Microsoft Azure. O tipo AKS fornece um Edge Gateway de uma arquitetura agrupada em cluster, que fornece serviços replicados que oferecem suporte à experiência de login do SSO e à coleta de dados de monitoramento.
  • Duas perguntas para a tabela de decisão a seguir:
    1. Você tem requisitos para sessões >5K ou para ter a experiência de login do SSO e a coleta de dados de monitoramento compatíveis por meio de serviços com capacidade completa de failover em caso de falha?
    2. Você tem algum dos intervalos de IP restritos do AKS contidos na sub-rede de gerenciamento do pod, na VNet do pod ou em uso por máquinas conhecidas por essa VNet conectada à sua rede local?
Suas respostasAbordagem a usarPré-requisitos a serem cumpridos
  1. Sim
  2. Não
Sim para a primeira pergunta requer o tipo AKS. Quando você precisa de sessões >5K e precisa atender aos requisitos da experiência de login do SSO e da coleta de dados de monitoramento, o tipo AKS é necessário para fornecê-los.Pré-requisitos do tipo AKS
  1. Sim
  2. Sim
Sim para a primeira pergunta requer o tipo AKS. Nesse caso, você precisa do tipo AKS para fornecer sessões >5K e atender aos requisitos sobre a experiência de login do SSO e a coleta de dados de monitoramento, mas a VNet do pod é contrária às restrições de endereço IP do tipo AKS. Para oferecer suporte aos requisitos do tipo AKS, você deve:
  1. Configure outra VNet e uma sub-rede de gerenciamento nessa VNet na assinatura do pod, que não contenham os endereços IP restritos.
  2. Certifique-se de que a nova VNet e a sub-rede de gerenciamento atendam aos requisitos do Edge Gateway do AKS.
  3. Emparelhe essa nova VNet com a VNet existente do pod
Em seguida, ao executar o assistente de migração, você selecionará essa nova VNet e sub-rede de gerenciamento e a opção Serviço do Azure Kubernetes.		Pré-requisitos do tipo AKS
  1. Não
  2. Não
Não à primeira pergunta significa que o tipo de VM Única atende às suas necessidades. Ao mesmo tempo, como a VNet do pod satisfaz as restrições de IP do tipo AKS, você pode optar por usar o tipo AKS para a migração.O tipo de VM única não tem requisitos específicos além daqueles detalhados na página 'Pré-requisitos para migrar um pod do Horizon Cloud de primeira geração' e todas as suas subseções.
  1. Não
  2. Sim
Não à primeira pergunta significa que o tipo de VM Única atende às suas necessidades. Sua escolha de qualquer um:
  • A opção mais simples é usar o tipo de VM Única.
  • A opção mais complexa é contornar os IPs restritos ao AKS:
    1. Configurar outra VNet e uma sub-rede de gerenciamento nessa VNet na assinatura do pod que não contém os endereços IP restritos.
    2. Garantir que a nova VNet e a sub-rede de gerenciamento atendam aos requisitos do Edge Gateway do AKS.
    3. Emparelhar essa nova VNet com a VNet existente do pod
    Cumprir os itens acima; depois, como alternativa, você poderá escolher o tipo AKS, se quiser.
O tipo de VM única não tem requisitos específicos além daqueles detalhados na página 'Pré-requisitos para migrar um pod do Horizon Cloud de primeira geração' e todas as suas subseções.

Determinar se a assinatura do Microsoft Azure do pod tem políticas em torno de tags de grupo de recursos

No dia da redação deste artigo, o processo de implantação do Horizon Edge requer que a assinatura do Microsoft Azure permita a criação de grupos de recursos que não têm tags.

Imediatamente após agendar o dia e a hora da janela de manutenção de migração, o sistema cria grupos de recursos para as instâncias do Horizon Edge Gateway e do Unified Access Gateway.

Portanto, se a assinatura do pod tiver Políticas do Microsoft Azure que bloqueiam a criação de grupos de recursos não marcados ou se a assinatura tiver qualquer tipo de requisito de tag de recurso, o processo de migração falhará logo após essa etapa de agendamento.

Se a assinatura tiver essa política, você poderá gerenciar esse requisito fazendo com que um plano desative essa Política do Azure pouco antes do momento em que conclui o assistente de agendamento de migração e deixe a política desativada até que as instâncias do Horizon Edge Gateway e do Unified Access Gateway sejam implantadas na assinatura. Quando você vir que as instâncias do Horizon Edge Gateway e do Unified Access Gateway foram implantadas com êxito, a Política do Azure para exigir tags ao criar grupos de recursos pode ser reativada sem afetar as atividades de migração.

Rede: avaliar as configurações existentes para o tráfego de rede e atualizar conforme necessário

Avalie se as configurações atuais do firewall permitem conectividade com os endpoints, portas e protocolos exigidos pelo Horizon Cloud Horizon Edge.

Os URLs e portas de endpoint exigidos pelo serviço do Horizon Cloud provavelmente são diferentes daqueles que sua equipe de rede já permitiu para o pod de primeira geração.

Para obter a lista de pontos de extremidade, portas e protocolos necessários, consulte as páginas a seguir no guia Usando o Horizon Cloud e determine as alterações a serem feitas no ambiente do pod de primeira geração.

Para situações em que não é possível usar URLs, consulte artigo KB 6000374: endereços IP para componentes de serviço.

Quando um pod de primeira geração é configurado com um proxy, os pools migrados herdam a configuração do proxy. Durante a migração, os pools da área de trabalho dedicados devem se conectar diretamente a URLs específicas pela Internet, ignorando o proxy. Se um firewall estiver instalado para conectividade de saída da sub-rede VDI da área de trabalho, esses URLs deverão ser permitidos durante o processo de migração. Após a conclusão da migração, você pode remover esses URLs da lista de permissões.

URLs para permitir VMs dedicadas durante a migração
US:
cloud-sg-us-r-westus2.horizon.omnissa.com
cloud-sg-us-r-eastus2.horizon.omnissa.com

EU:
cloud-sg-eu-r-northeurope.horizon.omnissa.com
cloud-sg-eu-r-germanywestcentral.horizon.omnissa.com
cloud-sg-eu-r-uksouth.horizon.omnissa.com

JP:
cloud-sg-jp-r-japaneast.horizon.omnissa.com
cloud-sg-jp-r-australiaeast.horizon.omnissa.com
cloud-sg-jp-r-centralindia.horizon.omnissa.com

Verificar se a chave secreta do aplicativo associada do pod ainda é válida

Faça login no Portal do Azure para sua implantação de pod e verifique se a chave do aplicativo usada pelo pod não expirou.

O Portal do Azure usa o termo chave segredo do cliente, na área Registro de Aplicativo. Procure o registro de aplicativo associado ao pod.

VNet: avaliar o roteamento para acesso interno a áreas de trabalho

Dependendo do roteamento que você tiver implementado para o pod de primeira geração e o acesso interno aos desktops, poderá ser necessário ajustar esse roteamento para continuar a funcionar para acesso interno aos desktops no Horizon Cloud Horizon Edge.

Avaliar as cotas da família de vCPUs do Microsoft Azure e aumentar conforme necessário

Dependendo das cotas atuais da família de vCPU na assinatura do Microsoft Azure do pod de primeira geração, talvez você precise aumentar a cota de famílias de vCPU específicas para oferecer suporte ao processo de migração.

O processo de migração implanta um Horizon Edge que consiste em um mínimo de uma instância do Horizon Edge Gateway e duas instâncias do Unified Access Gateway.

Um Horizon Edge implantado no Microsoft Azure tem um Horizon Edge Gateway de tipo de implantação de VM Única ou tipo de implantação do AKS.

Decida qual tipo usar para a migração de pod, conforme descrito em Decidir sobre o tipo de implantação do Edge Gateway.

FinalidadeNecessidades adicionais de vCPU/cota
Instâncias do Unified Access GatewayCota adicional para acomodar dois (2) Standard_F8s_v2
Horizon Edge Gateway: tipo de implantação de VM Única, se você optar por esse tipoCota adicional para acomodar 1 VM dos seguintes tamanhos de SKU de VM:
  • Standard_D4s_v3: 4 vCPU
  • Standard_D4s_v4: 4 vCPU
  • Standard_D4s_v5: 4 vCPU
Horizon Edge Gateway: tipo de implantação do AKS, se você optar por esse tipo Cota adicional para acomodar 5 dos seguintes tamanhos de SKU de VM:
  • Standard_D2s_v3: 2 vCPU
  • Standard_D2ds_v5: 2 vCPU
  • Standard_D2a_v4: 2 vCPU
Se a assinatura do pod tiver capacidade para acomodar cinco (5) de pelo menos um dos tamanhos de SKU da VM listados acima, o requisito de migração do Edge Gateway (AKS) de 4 nós será atendido, e o requisito de um nó para atualizações futuras do AKS também será cumprido. O plano de fundo desses requisitos de SKU da VM é que uma implantação do Edge Gateway (AKS) faz uso de um cluster do Serviço do Azure Kubernetes (AKS), que requer quatro nós de VM de um dos tamanhos de VM listados a seguir para capacidade. Em seguida, um (1) nó adicional é necessário e usado durante o processo da atualização. Isso representa um total de 5 SKUs de VM necessárias.
Imagens Cada imagem é duplicada e migrada para o Horizon Cloud.

Como resultado, você deve ter o dobro de vCPUs por imagem na família.

Por exemplo, para migrar uma imagem com Standard_DS2_v2 com 2 núcleos vCPU, são necessários dois núcleos vCPU adicionais durante a migração. Portanto, a assinatura do Azure deve ter pelo menos 4 núcleos vCPU da família Standard DSv2 na região correspondente.

No entanto, como as imagens são migradas em lotes de 20, essa cota excedente não precisa exceder 20 vezes o número de núcleos de vCPU por imagem. Em outras palavras, você precisa da sua cota existente mais uma cota excessiva de 20 vezes a vCPU da imagem, não apenas uma cota de 20 vezes a vCPU da imagem.

Garantir que suas políticas do Azure permitam o provisionamento de contas de armazenamento e compartilhamentos de arquivos

Antes de agendar a migração, verifique com o proprietário da assinatura do Azure do pod se as políticas do Microsoft Azure no nível da assinatura ou no grupo de recursos do pod não bloqueiam, negam ou restringem o provisionamento de contas de armazenamento e compartilhamentos de arquivos no grupo de recursos do pod de primeira geração.

Se você estiver migrando um pod para um Horizon Edge existente, verifique se as políticas do Microsoft Azure na assinatura e no grupo de recursos do Horizon Edge existente não bloqueiam, negam ou restringem o provisionamento de contas de armazenamento e compartilhamentos de arquivos.

A implantação bem-sucedida do Horizon Edge Gateway requer o provisionamento da conta de armazenamento e dos compartilhamentos de arquivos do App Volumes.

Quando o Pod de Primeira Geração tiver aplicativos do App Volumes, verifique se suas políticas do Azure permitam a alternância do acesso à rede nas contas de armazenamento

Se o pod de primeira geração tiver aplicativos do App Volumes, verifique com o proprietário da assinatura do Azure do pod se as políticas do Microsoft Azure no nível da assinatura ou no grupo de recursos do pod não bloqueiam, negam ou restringem a capacidade de ativar o acesso à rede pública.

A migração de aplicativos do App Volumes do sistema envolve a cópia desses recursos da conta de armazenamento do Azure do pod para a conta de armazenamento do Horizon Edge Gateway.

Para facilitar essa cópia, o processo de migração precisa de acesso a ambas as contas de armazenamento. Durante a migração, o sistema ativa temporariamente o acesso à rede pública nas contas de armazenamento e o desativa após a conclusão da cópia.

Se uma política do Azure impedir que o processo de migração ative o acesso à rede pública nas contas de armazenamento antes de começar a copiar os aplicativos do App Volumes, a migração falhará. O sistema precisa ter a capacidade de ativar e desativar o acesso à rede durante a fase de construção da migração e durante a janela de manutenção.

Quando você tem um IP público para o balanceador de carga do Unified Access Gateway

Quando seu pod de primeira geração estiver usando um IP público para o balanceador de carga da configuração do Unified Access Gateway externo, o sistema configurará o Horizon Cloud Horizon Edge para usar um IP público para a configuração do Unified Access Gateway do Horizon Edge.

A assinatura do pod precisará de um IP público adicional nesse caso. Portanto, antes de agendar a migração, certifique-se de que a assinatura tenha capacidade para fornecer a esse IP público adicional.

Quando você tem um IP privado para o balanceador de carga do Unified Access Gatewayr

Quando o balanceador de carga de sua implantação externa do Unified Access Gateway de primeira geração estiver usando um IP privado, obtenha o endereço IP público que você deseja rotear para o balanceador de carga da implantação do Horizon Cloud.

Se a sua configuração de gateway externo de primeira geração a ser migrada estiver usando um IP privado para seu balanceador de carga, com um IP público roteado para esse IP privado, o sistema detectará essa configuração quando você começar a agendar a migração.

Esse cenário foi usado em implantações de primeira geração quando você tinha um firewall ou NAT configurado na frente do balanceador de carga do Azure da configuração do gateway externo com a finalidade de controlar o tráfego baseado na Internet antes de permitir o acesso aos dispositivos Unified Access Gateway da configuração do gateway externo.

O sistema detecta a configuração de primeira geração durante o processo de digitalização, quando determina o estado Ready to migrate.

Quando o sistema detecta essa configuração, a UI do Assistente de Agendamento de Migração exibe um campo IP Público Manual. Nesse campo, você inserirá o endereço IP público que deseja usar para a implantação do Horizon Cloud Unified Access Gateway.

Observação: esse IP público deve ser diferente do IP público já em uso para o gateway do pod a ser migrado, para dar suporte à reversão para o estado de implantação de primeira geração, caso a reversão seja necessária.

Portanto, se você tiver essa configuração, obtenha um novo endereço IP público para usar, um endereço diferente do atualmente usado para o gateway externo do pod de primeira geração.

Avalie a capacidade de efetuar login em seu novo ambiente Horizon Cloud e consulte o Horizon Cloud Horizon Universal Console

Tente fazer login em connect.omnissa.com e, após o login, verifique se você vê um cartão chamado Workspace ONE Cloud na UI de serviços. A captura de tela a seguir é um exemplo.

  1. Primeiro, verifique se você vê um cartão denominado Workspace ONE Cloud na UI de serviços. A captura de tela a seguir é um exemplo.

    Captura de tela do cartão Workspace ONE Cloud na UI de serviços

  2. Se você vir esse cartão, clique no link Iniciar serviço e verifique se há um cartão rotulado como Horizon Cloud. Essa captura de tela ilustra esse cartão nos serviços. Seu conjunto específico de cartões pode diferir.

    Captura de tela do cartão Horizon Cloud com uma seta verde apontando para ele.

    Clicar no cartão do Horizon Cloud iniciará a abertura do Horizon Cloud Horizon Universal Console.

    • Se você já tiver integrado seu ambiente do Horizon Cloud, verá o Horizon Cloud Horizon Universal Console com a tela Migração disponível.
    • Se você ainda não tiver concluído a integração a seu ambiente Horizon Cloud, o sistema apresentará a UI de seleção de região, conforme descrito na seção Seleção de região da nuvem e você poderá executar as etapas descritas para concluir a integração e ver o console com a tela Migração disponível.

Se a execução das etapas acima não resultar na exibição do Horizon Cloud Horizon Universal Console e você já estiver interagindo com a equipe de Migração do Horizon, entre em contato com a pessoa da equipe com quem você está trabalhando. Se você ainda não estiver envolvido com a equipe de migração do Horizon, entre em contato com o Suporte global e solicite assistência para a migração do Horizon Cloud.

A captura de tela a seguir ilustra a aparência da parte superior do lado de navegação do Horizon Cloud Console no final da Etapa 2 acima. A área principal pode ou não exibir o conteúdo de boas-vindas mostrado nesta captura de tela. A área principal pode exibir automaticamente a tela Migração. Ver esse tipo de navegação significa que você está no Horizon Cloud Console.

Captura de tela da parte superior da navegação do Horizon Cloud Console.

Decida sobre o seu provedor de identidade e sincronize usuários e grupos do AD com ele

No ambiente do Horizon Cloud, o serviço depende do uso de um provedor de identidade externo e de um domínio do Active Directory.

Fundo

No seu locatário de primeira geração, seus domínios Active Directory registrados foram usados para identidade da máquina e identidade do usuário, para autenticar o acesso do usuário final a áreas de trabalho e aplicativos publicados.

No ambiente do Horizon Cloud, você traz para o serviço um provedor de identidade externo para cumprir a parte de identidade do usuário.

O uso de um provedor de identidade externo permite a integração com soluções de terceiros para fornecer recursos como a autenticação multifator.

Na migração de um pod de primeira geração para um Horizon Cloud Horizon Edge, esse Horizon Edge pós-migração usará seu domínio do Active Directory para identidade de máquina, da mesma forma que no ambiente de primeira geração. As áreas de trabalho virtuais migradas e as máquinas virtuais que fornecem aplicativos publicados (remotos) são associadas ao domínio do Active Directory.

Observação: o provedor de identidade escolhido para seu ambiente do Horizon Cloud deve estar conectado aos domínios do Active Directory dos pods de primeira geração, aqueles registrados em seu locatário de primeira geração.

Decidir sobre o provedor de identidade que você usará

O provedor de identidade que você decidir registrar no serviço do Horizon Cloud deverá atender aos requisitos do Horizon Cloud.

No momento da redação deste texto:

  • Somente um provedor de identidade pode ser usado com o ambiente Horizon Cloud.
  • Os tipos compatíveis são:
    • Microsoft Entra ID Commercial (para ambientes de negócios do Azure) e Microsoft Entra ID Government (para ambientes do Azure US Government). Quando seu pod de primeira geração for implantado em ambientes do Azure US Government, você usará o Microsoft Entra ID Government.
    • Omnissa Access (nuvem ou local)

Para obter mais informações, consulte Conectando seu provedor de identidade na documentação do Horizon Cloud.

Pré-requisitos: microsoft Entra ID Comercial ou Microsoft Entra ID Government

Você executará um assistente no Horizon Cloud Horizon Universal Console para definir as configurações do Horizon Cloud para usar o Microsoft Entra ID.

Você precisará dos itens a seguir para concluir esse assistente.

Item obrigatórioDetalhes
Usuário que tem privilégios de Administrador GlobalEsse usuário no Microsoft Entra ID é necessário para:
  • Aprove as permissões solicitadas
  • Forneça consentimento para toda a organização
Como parte da UI do assistente, você gera um link para fornecer ao usuário para efetuar login no Microsoft Entra ID, aprovar as permissões e fornecer consentimento para que o serviço do Horizon Cloud acesse as informações do usuário no Microsoft Entra ID. Se você for um Administrador Global em seu Microsoft Entra ID, o assistente solicitará que você faça login no Microsoft Entra ID e aprove as permissões e forneça o consentimento. Siga as instruções na tela.
Subdomínio do locatárioO assistente solicitará que você insira uma cadeia em um campo denominado Subdomínio do locatário. Ele deve começar e terminar com uma letra [a-Z] ou um número [0-9] e conter apenas letras, números e traços [-]. Essa cadeia de caracteres é sua própria criação, uma cadeia de caracteres que você e sua equipe compõem para usar. A maioria das pessoas digita uma cadeia de caracteres relacionada ao nome da empresa ou organização ou domínio da empresa.

No entanto, lembre-se de que, mais tarde, quando os usuários finais efetuarem login em suas áreas de trabalho e aplicativos usando o ambiente migrado do Horizon Cloud, eles inserirão essa cadeia de caracteres no campo Usar domínio da empresa. Esse campo é apresentado como parte do fluxo de login do usuário final.

Pré-requisitos: Omnissa Access Cloud ou On Premises

Você executará um assistente no Horizon Cloud Horizon Universal Console para configurar as definições do Horizon Cloud para usar o Access.

Você precisará dos itens a seguir para concluir esse assistente.

Item obrigatórioDetalhes
Usuário com privilégios de administradorEsse usuário em seu Omnissa Access é necessário para:
  • Aprove as permissões solicitadas
  • Forneça consentimento para toda a organização
Subdomínio do locatárioO assistente solicitará que você insira uma cadeia em um campo denominado Subdomínio do locatário. Ele deve começar e terminar com uma letra [a-Z] ou um número [0-9] e conter apenas letras, números e traços [-]. Essa cadeia de caracteres é sua própria criação, uma cadeia de caracteres que você e sua equipe compõem para usar. A maioria das pessoas digita uma cadeia de caracteres relacionada ao nome da empresa ou organização ou domínio da empresa. No entanto, lembre-se de que, mais tarde, quando os usuários finais efetuarem login em suas áreas de trabalho e aplicativos usando o ambiente migrado do Horizon Cloud, eles inserirão essa cadeia de caracteres no campo Usar domínio da empresa. Esse campo é apresentado como parte do fluxo de login do usuário final.
Acessar FQDN do locatárioNo assistente, digite o FQDN do locatário do Access. Esse FQDN normalmente está no formato yourcompany.workspaceoneaccess.com. Você pode obter esse FQDN em seu console do Access.
ID do cliente do locatário de acesso e segredo do cliente (se estiver usando o Access On-Premises)Ao usar o Access On-Premises, o assistente solicita a ID do cliente OAuth e o segredo do cliente OAuth que você configurou para fins de integração com seu ambiente Horizon Cloud.

Sincronizar os usuários e grupos do Active Directory (AD) com esse provedor de identidade

Antes de selecionar os pods a serem migrados, verifique se todos os usuários do AD e os grupos do AD com direito a áreas de trabalho e aplicativos dos pods a serem migrados estão sincronizados com seu provedor de identidade escolhido.

Durante as verificações de pré-validação do sistema, o sistema obtém o conjunto de usuários e grupos do AD das atribuições de área de trabalho e aplicativo do pod de primeira geração e verifica o provedor de identidade registrado no ambiente do Horizon Cloud para esses usuários e grupos do AD. Se o sistema não localizar um desses usuários ou grupos do AD no provedor de identidade registrado, a etapa de pré-validação falhará. O relatório de falha que você obtém da interface do usuário relatará o usuário ou grupo AD ausente.

Avaliar seu uso de usuários ou grupos incorporados do Active Directory e atualizar conforme necessário

Se sua implantação de primeira geração do Horizon Cloud on Microsoft Azure estiver configurada para usar o Azure Active Directory (Azure AD), você precisará atualizar sempre que tiver especificado usuários ou grupos integrados antes de migrar e alterar para grupos e usuários não integrados.

O sistema verifica os pods de primeira geração para determinar se eles atendem aos critérios de migração, depois coleta as informações sobre os usuários e grupos especificados em cada atribuição e tenta criar a configuração equivalente no provedor de identidade configurado do ambiente do Horizon Cloud. Se você tiver o Microsoft Azure AD como seu provedor de identidade em seu ambiente do Horizon Cloud, o Microsoft Azure AD Connect sincronizará seu domínio do Active Directory com o Microsoft Azure AD.

No entanto, conforme declarado na documentação da Microsoft, a sincronização do Microsoft Azure AD Connect que lida com a sincronização de um grupo do Active Directory para o Azure AD exclui grupos de segurança internos de sua sincronização de diretório. Como resultado, quando o sistema tenta criar nesse provedor de identidade a configuração de primeira geração equivalente na qual você usou grupos internos e usuários internos, o sistema não encontra nenhuma entidade equivalente no Azure AD, porque esses itens internos nunca são sincronizados. O sistema relatará que os pods nos quais os usuários integrados e os grupos integrados estão envolvidos não podem ser migrados.

Nesse cenário, crie grupos regulares do Active Directory que tenham as mesmas associações que os grupos e usuários integrados e, onde quer que você tenha especificado os grupos e usuários integrados para receber áreas de trabalho ou aplicativos remotos, atualize essas configurações para usar os grupos regulares do Active Directory.

Avalie seu uso de atribuições de aplicativos do App Volumes

Se seu locatário de primeira geração tiver atribuições de aplicativos do App Volumes, verifique se seu ambiente do Horizon Cloud tem uma assinatura de licença válida do App Volumes.

Durante as verificações de pré-validação do sistema, o sistema verifica seu ambiente do Horizon Cloud para verificar a presença de uma assinatura de licença válida do App Volumes.

Se não for encontrado, o sistema impedirá a programação da migração do pod com um erro.

No Horizon Cloud Console, você pode verificar a presença de licenças em seu ambiente do Horizon Cloud usando as etapas descritas em Usar o Horizon Universal Console para rastrear suas licenças do Horizon.

Caso especial: se o registro do aplicativo do pod de primeira geração estiver usando uma função personalizada

Se seu pod de primeira geração estiver configurado para usar uma função personalizada para o registro do aplicativo Horizon Cloud da assinatura, um pré-requisito de migração será atualizar essa função personalizada com as permissões necessárias em um ambiente Horizon Cloud.

O uso de uma função personalizada é atípico. A maioria das implantações de pod de primeira geração está usando a função Contributor para o registro do aplicativo principal do serviço do Horizon Cloud.

Quando seu pod de primeira geração foi implantado, ele pode ter usado uma função personalizada conforme descrito na página de documentação da primeira geração Quando sua organização prefere usar uma função personalizada.

Se seu pod se enquadrar nesse cenário, essa função personalizada existente deverá ser atualizada para incluir as permissões exigidas pelo ambiente do Horizon Cloud para fazer as chamadas de API necessárias.

Na assinatura do pod de primeira geração, confirme se as operações a seguir são permitidas na função personalizada do registro de aplicativo do Horizon Cloud, o registro de aplicativo usado pelo pod.

Algumas delas são as mesmas necessárias para uma implantação de pod de primeira geração. A tabela indica quais são adicionalmente necessários para o ambiente Horizon Cloud.

Importante: não remova operações já permitidas na função personalizada.

Permissões obrigatórias do Horizon Cloud

As operações de recursos do Microsoft Azure que devem ser permitidas na função personalizada ao atribuir permissões no nível da assinatura
 Operações
Novos adicionais para permitir o Horizon Cloud 

Microsoft.ContainerService/managedClusters/delete
Microsoft.ContainerService/managedClusters/read
Microsoft.ContainerService/managedClusters/write
Microsoft.ContainerService/managedClusters/commandResults/read
Microsoft.ContainerService/managedClusters/runcommand/action
Microsoft.ContainerService/managedClusters/upgradeProfiles/read

Microsoft.ManagedIdentity/userAssignedIdentities/*/assign/action
Microsoft.ManagedIdentity/userAssignedIdentities/*/read

Microsoft.ResourceGraph/*

Microsoft.Resources/subscriptions/read

Microsoft.Network/privateEndpoints/read
Microsoft.Network/privateEndpoints/write
Microsoft.Network/privateEndpoints/delete
Microsoft.Network/locations/availablePrivateEndpointTypes/read
Necessário para o Horizon Cloud, que já deve ser permitido na função personalizada do pod de primeira geraçãoSe qualquer uma delas ainda não estiver permitida na função personalizada, inclua as ausentes quando você atualizar a função para as operações anteriores.
  • Microsoft.Authorization/*/read
  • Microsoft.Compute/*/read
  • Microsoft.Compute/availabilitySets/*
  • Microsoft.Compute/disks/*
  • Microsoft.Compute/galleries/read
  • Microsoft.Compute/galleries/write
  • Microsoft.Compute/galleries/delete
  • Microsoft.Compute/galleries/images/*
  • Microsoft.Compute/galleries/images/versions/*
  • Microsoft.Compute/images/*
  • Microsoft.Compute/locations/*
  • Microsoft.Compute/snapshots/*
  • Microsoft.Compute/virtualMachines/*
  • Microsoft.Compute/virtualMachineScaleSets/*
  • Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/read
  • Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/write
  • Microsoft.Network/loadBalancers/*
  • Microsoft.Network/networkInterfaces/*
  • Microsoft.Network/networkSecurityGroups/*
  • Microsoft.Network/virtualNetworks/read
  • Microsoft.Network/virtualNetworks/write
  • Microsoft.Network/virtualNetworks/checkIpAddressAvailability/read
  • Microsoft.Network/virtualNetworks/subnets/*
  • Microsoft.Network/virtualNetworks/virtualNetworkPeerings/read
  • Microsoft.Resources/deployments/*
  • Microsoft.Resources/subscriptions/resourceGroups/*
  • Microsoft.ResourceHealth/availabilityStatuses/read
  • Microsoft.Storage/*/read
  • Microsoft.Storage/storageAccounts/*

Permissões opcionais

Embora as seguintes permissões não sejam obrigatórias para a implantação do Horizon Cloud Horizon Edge no Microsoft Azure, os recursos do serviço que dependem dessas permissões opcionais não funcionarão se você não as incluir.

Para dar suporte aos recursos do Horizon Cloud, operações de recursos do Microsoft Azure que são necessárias para a função personalizada ao atribuir permissões no nível da assinatura
 OperaçõesFinalidade
Novos adicionais para permitir o Horizon Cloud 

Microsoft.Network/natGateways/join/action
Microsoft.Network/natGateways/read


Microsoft.Network/privateEndpoints/write 
Microsoft.Network/privateEndpoints/read


Microsoft.Network/routeTables/join/action
Microsoft.Network/routeTables/read

Microsoft.Network/natGateways/join/action e Microsoft.Network/natGateways/read são operações necessárias quando você usará o tipo de implantação AKS para a migração e tiver escolhido usar um gateway NAT na sub-rede de gerenciamento em seus ' pré-requisitos do tipo AKS '.

Microsoft.Network/privateEndpoints/write e Microsoft.Network/privateEndpoints/read são necessários quando você usará o tipo de implantação AKS para sua migração e o pod for implantado em um ambiente comercial do Azure. Essas permissões são necessárias para criar os recursos de endpoint privado e validar se o gateway NAT da sub-rede de gerenciamento está configurado corretamente. Essas permissões de endpoint privado estão relacionadas ao uso do Horizon Edge (AKS) com o Azure Private Link na migração. Observação: quando o pod de primeira geração é implantado em um ambiente do Azure do Governo dos EUA e você usa o tipo de implantação do AKS para a migração, o Horizon Edge (AKS) é configurado para usar a conectividade com a Internet por padrão, em vez do Azure Private Link. O uso do Azure Private Link em ambientes do Azure do Governo dos EUA não tem suporte.

As permissões Microsoft.Network/routeTables/join/action e Microsoft.Network/routeTables/read são necessárias quando você for usar o tipo de implantação AKS e tiver escolhido usar uma tabela de rotas na sub-rede de gerenciamento em seus ' pré-requisitos do tipo AKS '. O serviço do requer essas permissões para criar os recursos de endpoint privados e validar a tabela de rotas associada à sub-rede de gerenciamento para garantir que a rota padrão esteja configurada corretamente.

Necessário pelo Horizon Cloud, que pode já ser permitido na função personalizada do pod de primeira geraçãoSe qualquer uma delas ainda não estiver permitida na função personalizada, inclua as ausentes quando você atualizar a função para as operações anteriores.
  • Microsoft.KeyVault/*/read
  • Microsoft.KeyVault/vaults/*
  • Microsoft.KeyVault/vaults/secrets/*
  • Microsoft.Network/publicIPAddresses/*

As permissões do repositório de chaves são necessárias para a criptografia de disco das VMs do pool.

É necessária a permissão de endereços IP públicos para implantar uma instância do Horizon Edge com instâncias do Unified Access Gateway atrás de um balanceador de carga com um endereço IP público. Além disso, essa permissão de endereço IP público é necessária para implantar e adicionar um endereço IP público a uma imagem.

Observação: essas informações foram adicionadas aqui por conveniência, visando o ambiente do Horizon Cloud pós-migração. Quando você estiver atualizando permissões antes da migração do pod, poderá considerar a inclusão dessa permissão ao mesmo tempo.

Esse cenário ocorre quando o provedor de identidade para seu ambiente do Horizon Cloud é o Microsoft Entra ID e você deseja usá-lo para identidade do computador.

Para obter detalhes, consulte a Nota sobre o Microsoft Entra ID na página de documentação do Horizon Cloud.

Esta página foi útil?

Enviar feedback sobre este tópico

Este tópico foi útil?

Não inclua informações pessoais ou confidenciais.

Gerando o link…