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 no seu novo ambiente de próxima geração 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.

Lembrete: No momento da redação deste artigo, a elegibilidade para migrar um pod de primeira geração é uma implementação progressiva para tenants 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 de próxima geração tem novos conceitos e terminologia. No serviço de próxima geração, 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 tenant, 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 tenant 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 seu primeiro pod está agendada, o sistema copia todas as informações registradas do Active Directory do tenant de primeira geração e as informações da conta de serviço e registra o mesmo no ambiente de próxima geração.

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 áreas a seguir e se preparar conforme necessário para acomodar os requisitos de próxima geração.

Observação: Para pods com algumas características especiais, o processo de migração pode exigir o uso de uma nova VNet e uma 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.

☐	Obter novo FQDN e certificado para o Unified Access Gateway. de próxima geração
☐	Avalie as versões do pod e do agente de primeira geração e atualize conforme necessário.
☐	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.
☐	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.
☐	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 fazer login no seu novo ambiente de próxima geração e ver o Horizon Universal Console de próxima geração.
☐	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 de aplicativo do seu pod de primeira geração estiver usando uma função personalizada, atualize as permissões necessárias para uma implantação de próxima geração seguindo as orientações em Se o registro de aplicativo do pod de primeira geração estiver usando uma função personalizada.

Obter novo FQDN e certificado para o Unified Access Gateway de próxima geração

Observação: O FQDN para a implantação do Unified Access Gateway next-gen 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 depois de finalizar a migração você poderá atualizar o FQDN e o certificado SSL da implantação do gateway de próxima geração, se desejar nesse momento.

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 de próxima geração, 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.

Avaliar versões do agente e do pod de primeira geração e atualizar conforme necessário

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

• O pod do Horizon Cloud deve estar executando o manifesto do pod 4136.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 versões do agente às quais o processo de migração oferece suporte, que são Horizon Agents Installer versão 23.1.0.22973254 e posteriores. Se as áreas de trabalho VDI dedicadas estiverem executando agentes de versões anteriores à 23.1.0.22973254, atualize os agentes para a versão 23.1.0.22973254 ou posterior antes da migração.
• As imagens e áreas de trabalho VDI flutuantes podem ter agentes de versões anteriores à 22.3.x, desde que as versões do agente sigam a Matriz de Interoperabilidade VMware para o Horizon Cloud on Microsoft Azure versão 2210.

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

Importante: O resultado da sua determinação fornecerá orientação sobre qual tipo de implantação do Horizon Edge Gateway você escolhe 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.

Decidir sobre seu tipo de implantação e atender aos seus requisitos

Na migração de um pod de primeira geração para o ambiente de próxima geração, 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 Gateway	Principais Qualidades	Detalhes
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 respostas	Abordagem a usar	Pré-requisitos a serem cumpridos
Sim 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
Sim 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: Configure outra VNet e uma sub-rede de gerenciamento nessa VNet na assinatura do pod, que não contenham os endereços IP restritos. Certifique-se de que a nova VNet e a sub-rede de gerenciamento atendam aos requisitos do Edge Gateway do AKS. 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
Não 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 nenhum requisito específico 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.
Não 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: 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. Garantir que a nova VNet e a sub-rede de gerenciamento atendam aos requisitos do Edge Gateway do AKS. 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 nenhum requisito específico 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 de firewall permitem a conectividade com os endpoints, portas e protocolos exigidos pelo Horizon Edge de próxima geração.

As URLs de endpoint e as portas exigidas pelo serviço de próxima geração provavelmente são diferentes daquelas que sua equipe de rede já permitiu para o pod de primeira geração.

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

• Tornar portas e URLs apropriadas acessíveis para implantar um Horizon Edge Gateway em um ambiente do Microsoft Azure
• Requisitos de porta e protocolo de next-gen do Horizon Cloud para sua implantação no Microsoft Azure

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ê tem em vigor para o pod de primeira geração e o acesso interno às áreas de trabalho, talvez seja necessário ajustar esse roteamento para continuar a funcionar para o acesso interno às áreas de trabalho no Horizon Edge de próxima geração.

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.

Finalidade	Necessidades adicionais de vCPU/cota
Instâncias do Unified Access Gateway	Cota adicional para acomodar dois (2) Standard_F8s_v2
Horizon Edge Gateway: tipo de implantação de VM Única, se você optar por esse tipo	Cota 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 a next-gen. 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.

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 seu balanceador de carga da configuração do Unified Access Gateway externo, o sistema colocará o Horizon Edge de próxima geração 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 Gateway

Quando o balanceador de carga da 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 roteado para o balanceador de carga da implantação de próxima geração.

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 verificação, quando determina o estado Pronto para migrar.

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 Unified Access Gateway next-gen.

Observação: Esse IP público deve ser diferente do IP público que já está em uso para o gateway do pod a ser migrado, para oferecer suporte à reversão para o estado de implantação de primeira geração se a reversão for 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.

Avaliar a capacidade de fazer login no seu novo ambiente de próxima geração e ver o Horizon Universal Console de próxima geração

Tente fazer login em console.cloud.vmware.com e, após o login, verifique se você vê um cartão rotulado 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 rotulado Workspace ONE Cloud na UI de Serviços. A captura de tela a seguir é um exemplo.
   
   
2. Se você vir esse cartão, clique no link Iniciar Serviço e verifique se você vê um cartão rotulado Horizon Cloud. Esta captura de tela ilustra esse cartão nos serviços do Workspace ONE. Seu conjunto específico de cartões pode diferir.
   
   

   Clicar nesse cartão do Horizon Cloud começará a abrir o Horizon Universal Console de próxima geração.

   • Se você tiver integrado anteriormente ao seu ambiente de próxima geração, verá o Horizon Universal Console de próxima geração com a tela Migração disponível.
   • Se você ainda não tiver concluído a integração ao seu ambiente de próxima geração, o sistema apresentará a UI de seleção de região, conforme descrito na seção Seleção de Região da Nuvem e poderá realizar 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 Universal Console de próxima geração e você já estiver envolvido com a equipe de Migração do VMware Horizon, entre em contato com a pessoa dessa equipe com quem está trabalhando. Se você ainda não estiver envolvido com a equipe de Migração do VMware Horizon, entre em contato com o Suporte Global da VMware e solicite assistência de migração do Horizon Cloud.

A captura de tela a seguir ilustra a aparência do lado de navegação do console de próxima geração 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 console de próxima geração.

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

No ambiente de próxima geração, o serviço depende do uso de um provedor de identidade externo e de um domínio do Active Directory.

Fundo

No seu tenant 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 de próxima geração, você traz ao serviço um provedor de identidade externo para preencher 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 Edge de próxima geração, esse Horizon Edge pós-migração usará seu domínio 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 que você escolher para o seu ambiente de próxima geração deve estar conectado aos domínios Active Directory dos pods de primeira geração, os registrados no seu tenant de primeira geração.

Decidir sobre o provedor de identidade que você usará

O provedor de identidade que você decidir registrar com o serviço de próxima geração deve atender aos requisitos de Horizon Cloud Service - next-gen.

No momento da redação deste texto:

• Apenas um provedor de identidade pode ser usado com o ambiente de próxima geração.
• Os tipos compatíveis são:
  • Microsoft Entra ID
  • Workspace ONE Access (na nuvem ou no local)

Para obter informações adicionais, consulte Configurar seu provedor de identidade na documentação do Horizon Cloud Service next-gen.

Pré-requisitos: Microsoft Entra ID

Você executará um assistente no Horizon Universal Console de próxima geração para definir as configurações de próxima geração para usar o Microsoft Entra ID.

Dica: Para obter uma ilustração de vídeo de configuração do Microsoft Entra ID como o provedor de identidade, comece no minuto 3 neste vídeo da Tech Zone Agendamento de uma migração de pod do Horizon Cloud on Microsoft Azure.

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

Item obrigatório	Detalhes
Usuário que tem privilégios de Administrador Global	Esse 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 conceder a esse usuário que faça login no Microsoft Entra ID e aprove as permissões e forneça o consentimento para que o serviço de próxima geração 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 tenant	O assistente solicitará que você insira uma cadeia em um campo denominado Subdomínio do tenant. 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, tenha em mente que, mais tarde, quando seus usuários finais fizerem login em suas áreas de trabalho e aplicativos usando o ambiente de próxima geração migrado, eles vão digitar essa cadeia de caracteres no campo Usar Domínio da Empresa. Esse campo é apresentado como parte do fluxo de login do usuário final. Dica: Para obter uma ilustração de vídeo do fluxo de login do usuário final e onde a cadeia Subdomínio do tenant é usada, comece no minuto:segundo às 3:30 nesse vídeo da Tech Zone que compara os fluxos de login do administrador e do usuário final.

Pré-requisitos: Workspace ONE Access Cloud ou no local

Você executará um assistente no Horizon Universal Console de próxima geração para definir as configurações de última geração para usar o Workspace ONE Access.

Dica: Para obter uma ilustração em vídeo da configuração do Workspace ONE Access como o provedor de identidade, consulte o vídeo em Exercício da zona técnica: Conectar o Workspace ONE Access como o provedor de identidade do usuário para o Horizon Cloud.

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

Item obrigatório	Detalhes
Usuário com privilégios de administrador	Este usuário na sua Workspace ONE Access é necessário para: Aprove as permissões solicitadas Forneça consentimento para toda a organização
Subdomínio do tenant	O assistente solicitará que você insira uma cadeia em um campo denominado Subdomínio do tenant. 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, tenha em mente que, mais tarde, quando seus usuários finais fizerem login em suas áreas de trabalho e aplicativos usando o ambiente de próxima geração migrado, eles vão digitar essa cadeia de caracteres no campo Usar Domínio da Empresa. Esse campo é apresentado como parte do fluxo de login do usuário final. Dica: Para obter uma ilustração de vídeo do fluxo de login do usuário final e onde a cadeia Subdomínio do tenant é usada, comece no minuto:segundo às 3:30 nesse vídeo da Tech Zone que compara os fluxos de login do administrador e do usuário final.
FQDN do tenant do Workspace ONE Access	No assistente, digite seu FQDN de tenant do Workspace ONE Access. Esse FQDN normalmente está no formato suaempresa.workspaceoneaccess.com. Você pode obter esse FQDN no console Workspace ONE Access.
Workspace ONE Access ID do cliente do tenant e o segredo do cliente (se estiver usando Workspace ONE Access no local)	Ao usar Workspace ONE Access no Local, o assistente solicita a ID do cliente OAuth e o segredo do cliente OAuth que você configurou para a integração com o seu ambiente de próxima geração.

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 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 next-gen para esses AD usuários e grupos. 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 implementação de primeira geração do Horizon Cloud on Microsoft Azure estiver configurada para usar o Azure Active Directory (Azure AD), você terá que atualizar sempre que tiver especificado usuários ou grupos integrados antes de migrar e mudar 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 e, em seguida, 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 next-gen. Se você tiver o Microsoft Azure AD como seu provedor de identidade no seu ambiente de próxima geração, o Microsoft Azure AD Connect sincroniza seu domínio 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.

Avaliar o uso de atribuições de aplicativos do App Volumes

Se o seu tenant de primeira geração tiver atribuições de aplicativo do App Volumes, verifique se o seu ambiente next-gen tem uma assinatura de licença do App Volumes válida.

Durante as verificações de pré-validação do sistema, o sistema verifica em seu ambiente de próxima geração 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 console next-gen, você pode verificar a presença de licenças em seu ambiente next-gen usando as etapas descritas em Usar o Horizon Universal Console para rastrear suas licenças do Horizon.

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

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

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 Colaborador para o registro de aplicativo entidade do Horizon Cloud Service.

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 o seu pod cair nesse cenário, essa função personalizada existente deverá ser atualizada para incluir as permissões exigidas pelo ambiente de próxima geração 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 observa quais são adicionalmente necessários para o ambiente de próxima geração.

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

Permissões obrigatórias de próxima geração

Tabela 1. 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
Additional new ones to allow for next-gen	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
Needed by next-gen which should be already allowed in your first-gen pod's custom role	Se 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 permissões a seguir não sejam obrigatórias para a implantação do Horizon Edge de próxima geração no Microsoft Azure, os recursos do serviço que dependem dessas permissões opcionais não funcionarão se você não as incluir.

Tabela 2. Para oferecer suporte aos recursos de próxima geração, as 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ções	Finalidade
Additional new ones to allow for next-gen	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ê estiver usando o tipo de implantação AKS para a migração e tiver escolhido usar um gateway NAT na sub-rede de gerenciamento nos pré-requisitos do tipo AKS. O serviço requer essas permissões para criar os recursos de endpoint privados e validar se o gateway NAT da sub-rede de gerenciamento está configurado corretamente. Essas permissões de endpoint privado são necessárias quando você vai usar o tipo de implantação do AKS para sua migração. Elas estão relacionadas ao uso da migração do Horizon Edge (AKS) com o Link Privado do Azure. Essas permissões de tabelas de rota são necessárias quando você usar o tipo de implantação do AKS e optar por usar uma tabela de rotas na sub-rede de gerenciamento nos 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.
Needed by next-gen which could be already allowed in your first-gen pod's custom role	Se 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 é obrigatória. para implantar e para adicionar um endereço IP público a uma imagem.

Observação: Essas informações aqui são adicionadas para conveniência, analisando o ambiente de próxima geração 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 o seu ambiente de próxima geração é o Microsoft Entra ID e você deseja usá-lo para a identidade da máquina.

Para obter detalhes, consulte a página de documentação de próxima geração Nota sobre o Microsoft Entra ID.