Requisitos previos para migrar un pod de Horizon Cloud

En esta página se describen las áreas que se deben evaluar, preparar y actualizar según sea necesario antes de iniciar la primera migración de pods.

Introducción

La mayoría de estas evaluaciones y pasos de preparación se pueden realizar en cualquier momento antes de iniciar sesión en el nuevo entorno de next-gen y ver la interfaz de usuario de migración.

Algunos de estos pasos de evaluaciones y preparación incluyen el entorno de suscripción de Microsoft Azure y la red en la que se implementa el pod de first-gen. En ese caso, es posible que necesite ayuda del equipo de TI que controla ese entorno.

Recordatorio: A partir de la publicación de este documento, la elegibilidad para migrar un pod de first-gen es una implementación progresiva para los arrendatarios de first-gen. Cuando sea apto, recibirá una comunicación directa del equipo de Comunicaciones de migración de Horizon.

Terminología

El servicio next-gen tiene nuevos conceptos y terminología. En el servicio next-gen, la implementación se denomina Horizon Edge (en lugar del término pod).

La migración de autoservicio está diseñada para implementar una instancia de Horizon Edge de Microsoft Azure en la misma suscripción de Microsoft Azure que se utiliza para migrar el pod de first-gen y con la misma información de suscripción y las mismas redes virtuales y subredes.

A medida que se migra cada pod, el proceso reutiliza los siguientes elementos de forma predeterminada desde el pod:

ID de suscripción de Microsoft Azure, ID de directorio, y clave secreta e ID de aplicación de entidad de servicio.
VNet
Subred de administración, subred de arrendatario y subred de zona perimetral (Demilitarized Zone, DMZ).
La información de dominio de Active Directory y las cuentas de servicio de enlace de dominio y unión a dominio que están registradas en el arrendatario de first-gen (usuarios de unión a dominio y enlace de dominio, usuarios de enlace de dominio auxiliar y usuarios de unión a dominio).
Cuando se programa la migración del primer pod, el sistema copia toda la información del dominio y de la cuenta de servicio registrada del arrendatario de Active Directory de first-gen y registra la misma información en el entorno de next-gen.

Algunos elementos del pod de first-gen no se reutilizan. Para algunos de ellos, debe configurar nuevos recursos adicionales.

Por lo tanto, debe evaluar las siguientes áreas y prepararse según sea necesario para satisfacer los requisitos de next-gen.

Nota: Para los pods que tienen algunas características especiales, el proceso de migración puede requerir el uso de una nueva red virtual y una subred de administración diferentes a las del pod de first-gen. Este caso especial se describe en la sección de esta página.

Tabla de requisitos previos

Las secciones que siguen a esta tabla proporcionan los detalles de cada uno de estos requisitos previos. Esta tabla se incluye como esquema facilitador.


☐	Obtener nuevo FQDN y certificado para Unified Access Gateway. - next-gen
☐	Evaluar las versiones de agente y pod de first-gen, y actualizarlas según sea necesario.
☐	Determinar si la red virtual del pod o las redes conectadas contienen direcciones IP restringidas por AKS.
☐	Decidir el tipo de implementación y cumplir sus requisitos.
☐	Determinar si la suscripción de Microsoft Azure del pod tiene directivas en torno a etiquetas de grupo de recursos. Si es así, planificar cómo controlar el requisito de migración.
☐	Redes: evaluar la configuración existente para el tráfico de red y actualizarla según sea necesario.
☐	Comprobar que la clave secreta de la aplicación asociada al pod siga siendo válida.
☐	Red virtual: evaluar el enrutamiento actual que se utiliza para el acceso interno a los escritorios.
☐	Evaluar las cuotas de la familia de vCPU de Microsoft Azure y aumentarlas según sea necesario.
☐	Si se dispone de una dirección IP pública para el equilibrador de carga de Unified Access Gateway, seguir las instrucciones de cuando se dispone de una IP pública para este equilibrador de carga.
☐	Si se dispone de una dirección IP privada para el equilibrador de carga de Unified Access Gateway, seguir las instrucciones de cuando se dispone de una IP privada para este equilibrador de carga.
☐	Evaluar la capacidad de iniciar sesión en el nuevo entorno de next-gen y consultar Horizon Universal Console - next-gen.
☐	Decidir el proveedor de identidad y sincronizar los usuarios y los grupos de AD con él.
☐	Evaluar el uso de usuarios o grupos integrados de Active Directory y actualizarlos según sea necesario.
☐	Evaluar el uso de asignaciones de aplicaciones de App Volumes.
☐	Caso especial: si el registro de aplicaciones del pod de first-gen utiliza una función personalizada, actualizar los permisos necesarios para una implementación de next-gen siguiendo las instrucciones de Si el registro de aplicaciones del pod de first-gen utiliza una función personalizada.

Obtener nuevo FQDN y certificado para Unified Access Gateway - next-gen

Nota: El FQDN de la implementación de Unified Access Gateway - next-gen debe ser diferente del FQDN que ya se usa en la implementación de first-gen que se va a migrar. Para poder revertir a la implementación de first-gen en el caso excepcional de que se produzcan problemas tras la migración, el FQDN de la puerta de enlace de la implementación de first-gen y su certificado SSL deben mantener la configuración que tienen en la implementación de first-gen. El certificado SSL y el FQDN de la implementación de puerta de enlace de next-gen solo se pueden actualizar cuando finaliza la migración.

La interfaz de usuario del asistente de programación requiere que se especifique este FQDN en el asistente y que se proporcione el certificado SSL basado en ese FQDN.

Para el entorno de next-gen, el certificado SSL puede estar en formato PEM o PFX.

El nombre común o FQDN establecido en el certificado debe coincidir con el FQDN que tiene previsto introducir en el asistente de programación. El asistente valida que los datos del certificado coincidan con el FQDN introducido en el asistente.

Evaluar las versiones del agente y el pod de first-gen y actualizarlas según sea necesario

Antes de poder migrar un pod, las versiones del pod y del agente deben cumplir estos criterios:

Horizon Cloud pod debe ejecutar el manifiesto del pod 4136.0 o una versión posterior. Si ejecuta un manifiesto anterior, inicie una solicitud de servicio para actualizar el pod.
Los escritorios VDI dedicados del pod deben ejecutar versiones de agente compatibles con el proceso de migración, que son Horizon Agents Installer versión 23.1.0.22973254 y versiones posteriores. Si los escritorios VDI dedicados ejecutan agentes de versiones anteriores a 23.1.0.22973254, actualice los agentes a la versión 23.1.0.22973254 o una versión posterior antes de la migración.
Las imágenes y los escritorios de VDI flotantes pueden tener agentes de versiones anteriores a la 22.3.x, siempre que dichas versiones se ajusten a la matriz de interoperabilidad de VMware para Horizon Cloud on Microsoft Azure, versión 2210.

Determinar si la red virtual o las redes conectadas del pod contienen direcciones IP restringidas por AKS

Importante: El resultado de la determinación proporcionará instrucciones sobre el tipo de implementación de Horizon Edge Gateway que se utilizará para la migración. Los tipos se describen en la siguiente sección titulada Decidir el tipo de implementación de Edge Gateway.

Determine si las redes, la red virtual o la subred de administración del pod de first-gen, a las que está conectada la red virtual (como la red local conectada a través de ExpressRoute) contienen direcciones IP de los rangos restringidos de AKS que se enumeran aquí:

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

En caso afirmativo, para migrar el pod, es necesario que a continuación evalúe si el tipo de implementación de máquina virtual única puede satisfacer sus necesidades o si tiene requisitos que solo puede cumplir el tipo de implementación de AKS.

Puede utilizar el tipo de implementación de una Máquina virtual única para migrar el pod, o bien
Si los requisitos indican que se utiliza el tipo de implementación de AKS, debe configurar una nueva red virtual y una subred de administración de un CIDR de /26 como mínimo en esa red virtual dentro de la suscripción del pod y emparejar esa nueva red virtual con la red virtual existente del pod. El CIDR de /26 como mínimo es una recomendación segura para el tipo de implementación de AKS.
Asegúrese de que nada en la nueva red virtual contenga o utilice direcciones IP de los rangos restringidos. Con la nueva red virtual y la subred de administración, puede utilizar el tipo de implementación de AKS que proporciona para HA.

Consulte la siguiente sección sobre cómo decidir el tipo de implementación de Edge Gateway para obtener instrucciones detalladas.

El motivo por el cual esos rangos específicos son rangos restringidos por AKS se debe a que Microsoft impone esta regla con respecto a sus clústeres del Servicio Kubernetes de Azure (AKS) que se utilizan para el tipo AKS de implementación de Horizon Edge Gateway.

Si estas direcciones IP restringidas se encuentran en la red virtual o la subred de administración del pod, o se encuentran en la red local conectada a la red virtual, el proceso de migración mediante el tipo de AKS no puede volver a utilizar la red virtual existente del pod.

Decidir el tipo de implementación y cumplir sus requisitos

En la migración de un pod de first-gen al entorno de next-gen, el sistema implementa lo que se denomina Horizon Edge Gateway en la suscripción de Microsoft Azure del pod.

La implementación se ofrece en dos tipos: tipo de Máquina virtual única o tipo de Servicio Kubernetes de Azure (AKS).

El sistema permite especificar el tipo que se utilizará para la migración de cada pod.

Por lo tanto, debe decidir qué tipo utilizar, en función de las calidades que necesite, según la tabla siguiente.


implementación de Edge Gateway	Calidades clave	Detalles
Máquina virtual única	Admite hasta 5000 sesiones. Menos requisitos previos involucrados en la suscripción de Microsoft Azure que para el tipo de AKS Admite migraciones de pods que no pueden cumplir fácilmente los requisitos de AKS. Si en algún momento la instancia de implementada no está disponible, el comportamiento resultante es: Los usuarios finales tendrán que iniciar sesión sin inicio de sesión único (SSO). Los datos de supervisión de los escritorios no se registrarán durante el período en el que la máquina virtual no esté disponible.	El tipo de máquina virtual única proporciona más simplicidad al migrar un pod de first-gen a través del tipo AKS. El motivo por el cual esta opción puede proporcionar una mayor simplicidad es que el tipo de Máquina virtual única implica menos requisitos nuevos en la suscripción de Azure del pod de los que requiere el tipo de AKS. Como resultado, admite implementaciones de pods de first-gen que no pueden cumplir fácilmente los requisitos del tipo AKS. Además de la simplicidad, el tipo de Máquina virtual única difiere del tipo de AKS en su comportamiento si la máquina virtual implementada deja de estar disponible. Cuando no está disponible: Los usuarios finales verán el flujo de inicio de sesión sin la experiencia de inicio de sesión SSO. Por ejemplo, antes de ver su escritorio, tendrán que iniciar sesión con sus credenciales de Active Directory. Los datos de supervisión de los escritorios que se envían a la máquina virtual de Edge Gateway no se registran durante el período en el que la máquina virtual no está disponible.
AKS	Admite más de 5000 sesiones. El Servicio Kubernetes de Azure tiene requisitos relacionados con Microsoft que se deben cumplir Admite migraciones de pods que pueden cumplir los requisitos de AKS. La experiencia de inicio de sesión SSO y la recopilación de datos de supervisión se gestionan a través de servicios replicados que permiten una entrega de alta disponibilidad de estas funciones	AKS es un estándar de Microsoft Azure para aplicaciones empresariales nativas de nube en centros de datos de Microsoft Azure. El tipo de AKS proporciona una instancia de Edge Gateway de una arquitectura en clúster, que proporciona servicios replicados compatibles con la experiencia de inicio de sesión SSO y la supervisión de la recopilación de datos.

Dos preguntas para la siguiente tabla de toma de decisiones:

¿Tiene requisitos para más de 5000 sesiones o tiene la experiencia de inicio de sesión SSO y la recopilación de datos de supervisión bien resueltos con servicios con capacidad de conmutación por error completa en caso de error?
¿Tiene alguno de los rangos de IP restringidos por AKS incluidos en la subred de administración del pod, la red virtual del pod o en uso por parte de equipos conocidos para esa red virtual conectados a la red local?


Sus respuestas	Enfoque de uso	Requisitos previos necesarios
Sí No	Responder sí a la primera pregunta requiere el tipo AKS. Cuando necesite más de 5000 sesiones y tenga que cumplir los requisitos de la experiencia de inicio de sesión SSO y la recopilación de datos de supervisión, se requiere el tipo AKS para proporcionarlas.	Requisitos previos del tipo de AKS
Sí Sí	Responder sí a la primera pregunta requiere el tipo AKS. En este caso, se necesita el tipo AKS para proporcionar más de 5000 sesiones y cumplir los requisitos de la experiencia de inicio de sesión SSO y la recopilación de datos de supervisión, pero la red virtual del pod es contraria a las restricciones de dirección IP del tipo de AKS. Para admitir los requisitos del tipo de AKS, debe: Configure otra red virtual y otra subred de administración en esa red virtual en la suscripción del pod, que no contenga las direcciones IP restringidas. Asegúrese de que la nueva red virtual y la subred de administración cumplan los requisitos de Edge Gateway de AKS. Emparejar esa nueva red virtual con la red virtual existente del pod A continuación, al ejecutar el asistente de migración, seleccione la nueva red virtual y subred de administración, y la opción Servicio Kubernetes de Azure.	Requisitos previos del tipo de AKS
No No	Responder no a la primera pregunta significa que el tipo de Máquina virtual única satisface sus necesidades. Al mismo tiempo, dado que la red virtual del pod cumple las restricciones de IP del tipo de AKS, puede optar por utilizar el tipo de AKS para la migración.	El tipo de Máquina virtual única no tiene ningún requisito específico más allá de los que se detallan en la página Requisitos previos para migrar un pod de Horizon Cloud - first-gen y todas sus subsecciones.
No Sí	Responder no a la primera pregunta significa que el tipo de Máquina virtual única satisface sus necesidades. Su elección entre las siguientes opciones: La opción más sencilla es el tipo de Máquina virtual única. Una opción más compleja es solucionar las direcciones IP restringidas por AKS llevando a cabo lo siguiente: Configurando otra red virtual y otra subred de administración en esa red virtual en la suscripción del pod no contenga las direcciones IP restringidas. Asegurándose de que la nueva red virtual y la subred de administración cumplan los requisitos de Edge Gateway de AKS. Emparejando esa nueva red virtual con la red virtual existente del pod Si cumple los elementos anteriores, puede utilizar el tipo de AKS como alternativa, si así lo desea.	El tipo de Máquina virtual única no tiene ningún requisito específico más allá de los que se detallan en la página Requisitos previos para migrar un pod de Horizon Cloud - first-gen y todas sus subsecciones.

Determinar si la suscripción de Microsoft Azure del pod tiene directivas en torno a etiquetas de grupo de recursos

En el momento de publicarse este documento, el proceso de implementación de Horizon Edge requiere que la suscripción de Microsoft Azure permita la creación de grupos de recursos que no tienen etiquetas.

Inmediatamente después de programar el día y la hora de la ventana de mantenimiento de la migración, el sistema crea grupos de recursos para las instancias de Horizon Edge Gateway y Unified Access Gateway.

Por lo tanto, si la suscripción del pod tiene directivas de Microsoft Azure que bloquean la creación de grupos de recursos sin etiquetar, o si la suscripción tiene algún tipo de requisito de etiqueta de recurso, se producirá un error en el proceso de migración poco después de ese paso de programación.

Si la suscripción tiene esa directiva, puede administrar este requisito realizando un plan para que esa directiva de Azure esté desactivada justo antes de que se complete el asistente de programación de migración y dejar la directiva desactivada hasta que las instancias de Horizon Edge Gateway y Unified Access Gateway se implementen en la suscripción. Cuando vea que las instancias de Horizon Edge Gateway y Unified Access Gateway se implementan correctamente, se puede volver a habilitar la directiva de Azure para requerir etiquetas al crear grupos de recursos sin que esto afecte a las actividades de migración.

Redes: evaluar la configuración existente para el tráfico de red y actualizar según sea necesario

Evalúe si la configuración actual del firewall permite la conectividad con los endpoints, puertos y protocolos requeridos por Horizon Edge - next-gen.

Es probable que las URL y los puertos de endpoint requeridos por el servicio next-gen sean diferentes de los que el equipo de red ya ha permitido para el pod de first-gen.

Para obtener la lista de endpoints, puertos y protocolos requeridos, consulte las siguientes páginas de la guía Uso de Horizon Cloud Service - next-gen y determine los cambios que se deben realizar en el entorno del pod de first-gen.

Comprobar que la clave secreta de la aplicación asociada al pod sigue siendo válida

Inicie sesión en Azure Portal para la implementación del pod y compruebe que la clave de aplicación utilizada por el pod no haya caducado.

Azure Portal utiliza el término "clave secreta de cliente", en el área de registro de la aplicación. Busque el registro de la aplicación asociado con el pod.

Red virtual: evaluar el enrutamiento para el acceso interno a los escritorios

Según el enrutamiento que haya implementado para el pod de first-gen y el acceso interno a los escritorios, es posible que deba ajustar ese enrutamiento para que siga funcionando con el acceso interno a los escritorios en la instancia de Horizon Edge - next-gen.

Evaluar las cuotas de la familia de vCPU de Microsoft Azure y aumentarlas según sea necesario

Según las cuotas de la familia de vCPU actuales en la suscripción de Microsoft Azure del pod de first-gen, es posible que deba aumentar la cuota de las familias de vCPU específicas para admitir el proceso de migración.

El proceso de migración implementa una instancia de Horizon Edge que consta, como mínimo, una instancia de Horizon Edge Gateway y dos de Unified Access Gateway.

Una instancia de Horizon Edge implementada en Microsoft Azure tiene una instancia de Horizon Edge Gateway de tipo de implementación de Máquina virtual única o de tipo de implementación de AKS.

El usuario decide qué tipo se utilizará para la migración del pod, como se describe en Decidir el tipo de implementación de Edge Gateway.


Propósito	Necesidades de cuota/vCPU adicionales
Instancias de Unified Access Gateway	Cuota adicional para dos (2) Standard_F8s_v2
Horizon Edge Gateway: tipo de implementación de Máquina virtual única, si opta por este tipo	Cuota adicional para alojar 1 máquina virtual de los siguientes tamaños de SKU de máquina virtual: Standard_D4s_v3: 4 vCPU Standard_D4s_v4: 4 vCPU Standard_D4s_v5: 4 vCPU
Horizon Edge Gateway: tipo de implementación de AKS, si opta por este tipo	Cuota adicional para alojar 5 de los siguientes tamaños de SKU de máquina virtual: Standard_D2s_v3: 2 vCPU Standard_D2ds_v5: 2 vCPU Standard_D2a_v4: 2 vCPU Si la suscripción del pod tiene capacidad para alojar cinco (5) de al menos uno de los tamaños de SKU de máquina virtual indicados anteriormente, se cumple el requisito de migración de Edge Gateway de 4 nodos (AKS) y también se cumple el requisito de un nodo para futuras actualizaciones de AKS. El trasfondo de estos requisitos de SKU de máquina virtual es que una implementación de Edge Gateway (AKS) utiliza un clúster de Servicio Kubernetes de Azure (AKS), que requiere cuatro nodos de máquina virtual de uno de los siguientes tamaños de máquina virtual indicados para capacidad. Se requiere un nodo (1) adicional y se utiliza durante el proceso de actualización. Esto hace necesario un total de 5 de estas SKU de máquina virtual.
Imágenes	Cada imagen se duplica y se migra a next-gen. Por lo tanto, debe tener el doble de cantidad de vCPU por imagen en la familia. Por ejemplo, para migrar una imagen con Standard_DS2_v2 con 2 núcleos de vCPU, se requieren dos núcleos de vCPU adicionales durante la migración. Por lo tanto, la suscripción de Azure debe tener al menos 4 núcleos de vCPU de la familia DSv2 estándar en la región correspondiente. Sin embargo, dado que las imágenes se migran en lotes de 20, esta cuota de exceso no debe superar 20 veces la cantidad de núcleos de vCPU por imagen. En otras palabras, necesita su cuota existente más una cuota de exceso que sea 20 veces la vCPU de imagen, no solo una cuota que sea 20 veces la vCPU de imagen.

Cuando se dispone de una IP pública para el equilibrador de carga de Unified Access Gateway

Cuando el pod de first-gen utiliza una IP pública para su equilibrador de carga de configuración de Unified Access Gateway externo, el sistema pondrá en espera la instancia de Horizon Edge - next-gen para utilizar una IP pública para la configuración de Unified Access Gateway de Horizon Edge.

En este caso, la suscripción del pod necesitará una dirección IP pública adicional. Por lo tanto, antes de programar la migración, asegúrese de que la suscripción tenga capacidad para proporcionar esta dirección IP pública adicional.

Cuando se dispone de una IP privada para el equilibrador de carga de Unified Access Gateway

Si el equilibrador de carga de la implementación de Unified Access Gateway - first-gen externa utiliza una IP privada, obtenga la dirección IP pública que se debe enrutar al equilibrador de carga de la implementación de next-gen.

Si la configuración de puerta de enlace externa de first-gen que se va a migrar utiliza una IP privada en su equilibrador de carga, con una IP pública enrutada a esa IP privada, el sistema detectará esta configuración cuando comience a programar la migración.

Este escenario se utilizaba en las implementaciones de first-gen cuando se tenía un firewall o NAT configurado frente al equilibrador de carga de Azure de la configuración de puerta de enlace externa. Así se controlaba el tráfico basado en Internet antes de permitir el acceso a los dispositivos Unified Access Gateway de la configuración de puerta de enlace externa.

El sistema detecta la configuración de first-gen durante el proceso de análisis cuando determina el estado Listo para migrar.

Cuando el sistema detecta esa configuración, la interfaz de usuario del asistente de Programar migración muestra el campo IP pública. En ese campo, introducirá la dirección IP pública que desea utilizar para la implementación de Unified Access Gateway - next-gen.

Nota: Esta IP pública debe ser diferente de la IP pública que ya se utiliza en la puerta de enlace del pod que se va a migrar para poder revertir al estado de implementación de first-gen si es preciso.

Por lo tanto, si tiene esta configuración, obtenga una nueva dirección IP pública para utilizarla, diferente de la que se usa actualmente para la puerta de enlace externa del pod de first-gen.

Evaluar la capacidad de iniciar sesión en el nuevo entorno de next-gen y ver Horizon Universal Console de next-gen

Intente iniciar sesión en console.cloud.vmware.com y, después de iniciar sesión, compruebe si ve una tarjeta con la etiqueta Workspace ONE Cloud en la interfaz de usuario de servicios. La siguiente captura de pantalla es un ejemplo.

En primer lugar, compruebe si ve una tarjeta etiquetada como Workspace ONE Cloud en la interfaz de usuario de servicios. La siguiente captura de pantalla es un ejemplo.
Si ve esa tarjeta, haga clic en el vínculo Iniciar servicio y, a continuación, compruebe si ve una tarjeta etiquetada como Horizon Cloud. Esta captura de pantalla muestra la tarjeta dentro de los servicios de Workspace ONE. El conjunto específico de tarjetas puede diferir.

Al hacer clic en esa tarjeta de Horizon Cloud, se empezará a abrir Horizon Universal Console de next-gen.
- Si se incorporó previamente al entorno de next-gen, verá Horizon Universal Console de next-gen con la pantalla Migración disponible.
- Si no completó previamente la incorporación al entorno de next-gen, el sistema presenta la interfaz de usuario de selección de región, como se describe en la sección Selección de región de nube, y puede realizar los pasos descritos allí para completar la incorporación y ver la consola con la pantalla Migración disponible.

Si al realizar los pasos anteriores no se muestra Horizon Universal Console de next-gen y ya está en el proceso con el equipo de migración de VMware Horizon, póngase en contacto con la persona de ese equipo con el que está trabajando. Si aún no está en el proceso con el equipo de migración de VMware Horizon, póngase en contacto con el soporte global de VMware y solicite asistencia para la migración de Horizon Cloud.

La siguiente captura de pantalla muestra cómo se ve la parte superior de navegación de la consola de next-gen al final del paso 2 anterior. El área principal puede mostrar o no el contenido de bienvenida que se muestra en esta captura de pantalla. El área principal puede mostrar automáticamente la pantalla Migración. Si ve este tipo de navegación, significa que está en la consola de next-gen.

Captura de pantalla de la parte superior de la navegación de la consola de next-gen.

Decidir el proveedor de identidad y sincronizar usuarios y grupos de AD con él

En el entorno de next-gen, el servicio se basa en el uso de un proveedor de identidad externo y un dominio de Active Directory.

Fondo

En el arrendatario de first-gen, los dominios de Active Directory registrados se utilizaron para la identidad de la máquina y la identidad del usuario, a fin de autenticar el acceso de los usuarios finales a los escritorios y las aplicaciones publicadas.

En el entorno de next-gen, se proporciona al servicio un proveedor de identidad externo para completar la parte de identidad del usuario.

El uso de un proveedor de identidad externo permite la integración con soluciones de terceros para proporcionar capacidades como la autenticación multifactor.

En la migración de un pod de first-gen a una instancia de Horizon Edge - next-gen, esa instancia de Horizon Edge posterior a la migración utilizará el dominio de Active Directory para la identidad de la máquina, al igual que en el entorno de first-gen. Los escritorios virtuales migrados y las máquinas virtuales que proporcionan aplicaciones (remotas) publicadas se unen al dominio de Active Directory.

Nota: El proveedor de identidad que elija para el entorno de next-gen debe estar conectado a los dominios de Active Directory de los pods de first-gen, los registrados en el arrendatario de first-gen.

Decidir el proveedor de identidad que se utilizará

El proveedor de identidad que decida registrar con el servicio next-gen debe cumplir los requisitos de Horizon Cloud Service - next-gen.

En el momento de redactarse este documento:

Solo se puede utilizar un proveedor de identidad con el entorno de next-gen.
Los tipos admitidos son:
- Microsoft Entra ID
- Workspace ONE Access (en la nube o local)

Para obtener contexto adicional, consulte Configurar el proveedor de identidad en la documentación de Horizon Cloud Service next-gen.

Requisitos previos: Microsoft Entra ID

Ejecutará un asistente Horizon Universal Console - next-gen para configurar los ajustes de next-gen para usar Microsoft Entra ID.

Sugerencia: Para ver ejemplos de vídeo de la configuración de Microsoft Entra ID como proveedor de identidad, comience en el minuto 3 de este vídeo de Tech Zone: Programación de una migración de pods de Horizon Cloud on Microsoft Azure.

Necesitará los siguientes elementos para completar ese asistente.


Elemento requerido	Detalles
Usuario que tiene privilegios de administrador global	Este usuario en Microsoft Entra ID es necesario para: Aprobar los permisos solicitados Proporcionar el consentimiento de toda la organización Como parte de la interfaz de usuario del asistente, se genera un vínculo para proporcionarlo al usuario y que inicie sesión en Microsoft Entra ID y apruebe los permisos y proporcione el consentimiento para que el servicio next-gen acceda a la información del usuario en Microsoft Entra ID. Si es administrador global en Microsoft Entra ID, el asistente le solicitará que inicie sesión en Microsoft Entra ID, apruebe los permisos y proporcione el consentimiento. Siga las instrucciones en pantalla.
Subdominio de arrendatario	El asistente le pedirá que introduzca una cadena en un campo etiquetado como Subdominio de arrendatario. Debe comenzar y terminar con una letra [a-Z] o un número [0- -9] y contener solo letras, números y guiones [-]. Esta cadena es de su propia creación, una cadena que usted y su equipo acuerdan utilizar. La mayoría de las personas introducen una cadena relacionada con su empresa, el nombre de la organización o el dominio de la empresa. Sin embargo, tenga en cuenta que más adelante, cuando los usuarios finales inicien sesión en sus escritorios y aplicaciones mediante el entorno de next-gen migrado, introducirán esta cadena en el campo Usar dominio de empresa. Este campo se presenta como parte del flujo de inicio de sesión del usuario final. Sugerencia: Para ver ejemplos en vídeo del flujo de inicio de sesión del usuario final y donde se utiliza la cadena de Subdominio de arrendatario, empiece en el minuto 3:30 de este video de Tech Zone que compara los flujos de inicio de sesión del usuario final y del administrador.

Requisitos previos: Workspace ONE Access en la nube o local

Ejecutará un asistente Horizon Universal Console - next-gen para configurar los ajustes de next-gen para usar Workspace ONE Access.

Sugerencia: Para ver ejemplos en vídeo sobre la configuración de Workspace ONE Access como proveedor de identidad, consulte el vídeo de Ejercicio de Tech Zone: conectar Workspace ONE Access como proveedor de identidad de usuarios para Horizon Cloud.

Necesitará los siguientes elementos para completar ese asistente.


Elemento requerido	Detalles
Usuario que tiene privilegios de administrador	Este usuario de Workspace ONE Access es necesario para: Aprobar los permisos solicitados Proporcionar el consentimiento de toda la organización
Subdominio de arrendatario	El asistente le pedirá que introduzca una cadena en un campo etiquetado como Subdominio de arrendatario. Debe comenzar y terminar con una letra [a-Z] o un número [0- -9] y contener solo letras, números y guiones [-]. Esta cadena es de su propia creación, una cadena que usted y su equipo acuerdan utilizar. La mayoría de las personas introducen una cadena relacionada con su empresa, el nombre de la organización o el dominio de la empresa. Sin embargo, tenga en cuenta que más adelante, cuando los usuarios finales inicien sesión en sus escritorios y aplicaciones mediante el entorno de next-gen migrado, introducirán esta cadena en el campo Usar dominio de empresa. Este campo se presenta como parte del flujo de inicio de sesión del usuario final. Sugerencia: Para ver ejemplos en vídeo del flujo de inicio de sesión del usuario final y donde se utiliza la cadena de Subdominio de arrendatario, empiece en el minuto 3:30 de este video de Tech Zone que compara los flujos de inicio de sesión del usuario final y del administrador.
FQDN de arrendatario de Workspace ONE Access	En el asistente, introduzca el FQDN del arrendatario de Workspace ONE Access. Este FQDN suele tener el formato yourcompany.workspaceoneaccess.com. Puede obtener este FQDN en la consola de Workspace ONE Access.
El secreto de cliente y el identificador de cliente del arrendatario de Workspace ONE Access (si utiliza la versión de Workspace ONE Access local)	Cuando se utiliza la versión de Workspace ONE Access local, el asistente solicita el identificador de cliente de OAuth y el secreto de cliente de OAuth que configuró, con el fin de realizar la integración con el entorno de next-gen.

Sincronizar los usuarios y los grupos de Active Directory (AD) con el proveedor de identidad

Antes de seleccionar los pods que desea migrar, compruebe que todos los usuarios y los grupos de AD autorizados para escritorios y aplicaciones de dichos pods están sincronizados con el proveedor de identidad elegido.

Durante las comprobaciones previas a la validación del sistema, el sistema obtiene el conjunto de usuarios y grupos de AD de las asignaciones de aplicaciones y escritorios del pod de first-gen, y comprueba el proveedor de identidad registrado en el entorno de next-gen para esos usuarios y grupos de AD. Si el sistema no encuentra uno de esos usuarios o grupos de AD en el proveedor de identidades registrado, se producirá un error en el paso de validación previa. El informe de errores que se obtiene de la interfaz de usuario informará sobre el grupo o el usuario de AD que falta.

Evaluar el uso de usuarios o grupos integrados de Active Directory y actualizar según sea necesario

Si su implementación de Horizon Cloud on Microsoft Azure - first-gen está configurada para utilizar Azure Active Directory (Azure AD), tiene que actualizar siempre que haya especificado grupos integrados o usuarios integrados antes de migrar y cambiar a grupos y usuarios no integrados.

El sistema explora los pods de first-gen para determinar si cumplen los criterios de migración y, posteriormente, recopila la información sobre los usuarios y los grupos que se especifican para cada asignación e intenta crear la configuración equivalente en el proveedor de identidades configurado del entorno de next-gen. Si tiene Microsoft Azure AD como proveedor de identidad en el entorno de next-gen, Microsoft Azure AD Connect sincroniza el dominio de Active Directory con Microsoft Azure AD.

Sin embargo, como se indica en la documentación de Microsoft, la sincronización de Microsoft Azure AD que controla la sincronización de un grupo de Active Directory con Azure AD excluye los grupos de seguridad integrados de su sincronización de directorios. Como resultado, cuando el sistema intenta crear en ese proveedor de identidades la configuración equivalente de first-gen en la que se utilizaron grupos integrados y usuarios integrados, el sistema no encuentra ninguna entidad equivalente en Azure AD, ya que esos componentes integrados nunca se sincronizan. El sistema informará de que los pods en los que están involucrados los usuarios y los grupos integrados no se pueden migrar.

En este escenario, creará grupos de Active Directory normales que tengan las mismas pertenencias que los grupos integrados y los usuarios integrados, y, dondequiera que haya especificado los grupos integrados y los usuarios integrados para recibir aplicaciones remotas o escritorios, actualice esa configuración para utilizar los grupos de Active Directory normales.

Cómo evaluar el uso de asignaciones de aplicaciones de App Volumes

Si el arrendatario de first-gen tiene asignaciones de aplicaciones de App Volumes, compruebe que el entorno de next-gen tenga una suscripción de licencia de App Volumes válida.

Durante las comprobaciones previas a la validación del sistema, el sistema comprueba el entorno de next-gen en busca de una suscripción de licencia de App Volumes válida.

Si no la encuentra, el sistema impide programar la migración del pod y muestra un error.

En la consola de next-gen, puede comprobar la presencia de licencias en el entorno de next-gen mediante los pasos descritos en Usar Horizon Universal Console para realizar un seguimiento de las licencias de Horizon.

Caso especial: si el registro de aplicaciones del pod de first-gen utiliza una función personalizada

Si el pod de first-gen está configurado para utilizar una función personalizada para el registro de aplicaciones de Horizon Cloud de su suscripción, un requisito previo de migración es actualizar esa función personalizada con los permisos necesarios en un entorno de next-gen.

El uso de una función personalizada es atípico. La mayoría de las implementaciones de pods de first-gen utilizan la función de Colaborador para el registro de aplicaciones de la entidad de servicio de Horizon Cloud.

Cuando implementó el pod de first-gen, es posible que utilizara una función personalizada, como se describe en la página de documentación de first-gen Cuando la organización prefiere utilizar una función personalizada.

Si el pod se encuentra en este escenario, la función personalizada existente debe actualizarse para incluir los permisos requeridos por el entorno de next-gen para realizar las llamadas de API requeridas.

En la suscripción del pod de first-gen, confirme que se permitan las siguientes operaciones en la función personalizada del registro de aplicaciones de Horizon Cloud, el registro de aplicaciones que utiliza el pod.

Algunas de estas son las mismas que se requerían para una implementación de pods de first-gen. En la tabla se señalan las que se requieren adicionalmente para el entorno de next-gen.

Importante: No elimine las operaciones que ya están permitidas en la función personalizada.

Permisos obligatorios de next-gen

Tabla 1. Operaciones de recursos de Microsoft Azure que se deben permitir en la función personalizada al asignar permisos en el nivel de suscripción
	Operaciones
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	Si aún no se permite alguno de las siguientes en la función personalizada, incluya las que faltan cuando actualice la función para las operaciones 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/

Permisos opcionales

Aunque los siguientes permisos no son obligatorios para la implementación de Horizon Edge - next-gen en Microsoft Azure, las funciones del servicio que dependen de estos permisos opcionales no funcionarán si no los incluye.

Tabla 2. Para admitir las funciones de next-gen, operaciones de recursos de Microsoft Azure que se requieren para la función personalizada al asignar permisos en el nivel de suscripción
	Operaciones	Propósito
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 y Microsoft.Network/natGateways/read son operaciones obligatorias cuando se utilice el tipo de implementación de AKS para la migración y se ha elegido utilizar una puerta de enlace NAT en la subred de administración en los requisitos previos del tipo de AKS. El servicio requiere estos permisos para crear los recursos de endpoint privado y validar que la puerta de enlace NAT de la subred de administración está configurada correctamente. Estos permisos de endpoint privado son necesarios cuando se va a utilizar el tipo de implementación de AKS para la migración. Están relacionados con el uso que hace la migración de Horizon Edge (AKS) con Azure Private Link. Estos permisos de tablas de rutas son necesarios cuando se utiliza el tipo de implementación de AKS y se elige utilizar una tabla de rutas en la subred de administración en los requisitos previos del tipo de AKS. El servicio requiere estos permisos para crear los recursos de endpoint privado y para validar la tabla de rutas asociada con la subred de administración para garantizar que la ruta predeterminada esté configurada correctamente.
Needed by next-gen which could be already allowed in your first-gen pod's custom role	Si aún no se permite alguno de las siguientes en la función personalizada, incluya las que faltan cuando actualice la función para las operaciones anteriores. Microsoft.KeyVault//read Microsoft.KeyVault/vaults/ Microsoft.KeyVault/vaults/secrets/* Microsoft.Network/publicIPAddresses/*	Se requieren permisos de almacén de claves para el cifrado de disco de las máquinas virtuales de grupo. Se requiere permiso de direcciones de IP pública para implementar una instancia de Horizon Edge con instancias de Unified Access Gateway detrás de un equilibrador de carga con una dirección IP pública. Además, este permiso es obligatorio para implementar y agregar una dirección IP pública a una imagen.

Nota: Esta información se agrega para mayor comodidad, de cara al entorno de next-gen posterior a la migración. Cuando actualice los permisos antes de la migración del pod, es posible que considere la posibilidad de incluir este permiso al mismo tiempo.

Este escenario se produce cuando el proveedor de identidad para el entorno de next-gen es Microsoft Entra ID y quiere utilizarlo para la identidad de la máquina.

Para obtener más información, consulte la Note sobre Microsoft Entra ID en la página de documentación de next-gen.