En esta página se describen los elementos que actualmente se excluyen del proceso de migración de autoservicio para migrar implementaciones de Horizon Cloud on Microsoft Azure - first-gen a arrendatarios de Horizon Cloud Service - next-gen. En esta página también se describen algunos casos especiales de implementaciones de primera generación.

Nota: Este contenido es un documento vivo. Esta información se actualiza según se amplía el soporte disponible.

Exclusiones de claves actuales

Importante: Este contenido no menciona todas las exclusiones posibles. A continuación se indican las características relevantes que actualmente se excluyen del proceso de migración.

Esta primera lista indica lo que se incluye, seguida de la lista de elementos excluidos.

Incluido a partir del 25 de abril de 2024
A partir de la publicación de este documento, se puede migrar un pod de Horizon Cloud on Microsoft Azure que cumpla los siguientes criterios.
  • Está Implementado en un entorno de Azure Commercial.
  • Tiene asignaciones dentro de ese único pod. Es decir, cuando se realiza una asignación en el pod-1, esa misma asignación no existe para ningún otro pod.

    Por ejemplo, si asignación-A usa pod-1 y pod-2, y asignación-B utiliza solo pod-3, pod-3 se puede migrar.

  • El pod de Horizon Cloud on Microsoft Azure debe ejecutar una versión de manifiesto mínima del pod, debe tener un estado de Online (verde) en la página Capacidad de la consola de first-gen y los agentes deben ejecutar una versión mínima. Para obtener más información, consulte la sección Comprobar las versiones requeridas de los agentes y la implementación para la migración.
  • Configuraciones de puerta de enlace interna que el implementador de pods de first-gen proporcionó para los pods de first-gen.
  • Configuraciones de puerta de enlace externa que el implementador de pods de first-gen proporcionó para los pods de first-gen.
  • Cuando las subredes o la red virtual de un pod tienen conflictos con lo que se denominan rangos de IP restringidos por AKS o se superponen con ellos, el pod se puede migrar siempre y cuando se elija el tipo de implementación de Máquina virtual única, o bien se implemente la solución alternativa de crear una nueva red virtual y una subred de administración para la implementación de next-gen. Para obtener más información acerca de este escenario, consulte Determinar si la red virtual o las redes conectadas del pod contienen direcciones IP restringidas por AKS.
  • Los pods que proporcionan aplicaciones remotas al inventario del arrendatario son aptos para la migración. Tanto las aplicaciones remotas analizadas automáticamente como las aplicaciones remotas que se agregaron al inventario mediante la opción Manualmente desde la granja se pueden migrar en este momento. Como se describe aquí en la documentación de first-gen, estas aplicaciones remotas se proporcionan mediante granjas de aplicaciones desde el pod.
    Nota: Si instaló las aplicaciones manuales directamente en las máquinas virtuales de granja de first-gen, aunque sus metadatos se migren como parte del proceso de migración, dichas aplicaciones no se instalarán de forma predeterminada en las máquinas virtuales del grupo del entorno de next-gen. Tendrá que volver a instalar estas aplicaciones en las máquinas virtuales del grupo en las rutas de acceso específicas exactas en las que se instalaron en las máquinas virtuales de granja de first-gen.

    Para obtener más información sobre el aspecto que tendrán las granjas de aplicaciones migradas en Horizon Universal Console - next-gen, consulte la sección Después de la ventana de mantenimiento en esta guía de migración.

  • Las opciones de configuración de proxy que admite el servicio de first-gen en pods de first-gen. El proceso de migración configurará los mismos ajustes de proxy en el dispositivo Horizon Edge Gateway resultante.
    Nota: Si decide migrar mediante el tipo de implementación de AKS y el pod de first-gen utiliza un proxy autenticado, donde su configuración de proxy incluye un nombre de usuario y una contraseña para la autenticación, el proceso de migración solo copia la URL del proxy en el dispositivo Horizon Edge Gateway. Esto se debe a que el tipo de AKS utiliza el Servicio Kubernetes de Microsoft Azure (AKS), que no admite un proxy autenticado en este momento.

    Cuando se migra mediante el tipo de implementación de AKS y el pod de first-gen utiliza un proxy autenticado, antes de ejecutar la interfaz de usuario del asistente de programación y programar la migración, debe desactivar la autenticación en el proxy. Una vez completada la ventana de mantenimiento de la migración, puede volver a habilitar la autenticación en el proxy si actualiza las opciones de configuración de Horizon Edge.

    Para obtener más información sobre cómo decidir qué tipo de implementación de Horizon Edge Gateway se debe seleccionar al migrar, consulte Decidir el tipo de implementación de Horizon Edge Gateway.

  • Si el grupo de pods del arrendatario de first-gen incluye pods de Horizon además de un pod de Horizon Cloud on Microsoft Azure, siempre y cuando esos pods de Horizon solo utilicen la licencia de suscripción y no usen ningún otro servicio basado en la nube, el pod de Horizon Cloud on Microsoft Azure puede participar en el proceso de migración de autoservicio.

    En este escenario, puede utilizar el proceso de migración de autoservicio descrito en esta guía para migrar el pod de Horizon Cloud on Microsoft Azure al entorno de next-gen. Después de migrar el pod de Horizon Cloud on Microsoft Azure, los pods de Horizon permanecen en el entorno de arrendatario de first-gen, recibiendo sus licencias de suscripción a través del arrendatario de first-gen. Aún no se proporcionó un proceso de migración de autoservicio para los pods de Horizon.

  • Los clientes ligeros de Horizon que se enumeran para Horizon Cloud Service next-gen en la matriz de compatibilidad de VMware se admiten después de la migración. Cuando se encuentre con un caso práctico en el que los usuarios finales utilicen clientes ligeros de Horizon, compruebe la matriz de compatibilidad entre el dispositivo y el modelo de cliente ligero de Horizon y Horizon Cloud Service next-gen antes de continuar con la migración. Solo se admiten clientes ligeros de Horizon que aparecen como compatibles con Horizon Cloud Service next-gen después de la migración.

    La matriz de compatibilidad entre los clientes ligeros de Horizon y la versión de la plataforma de Horizon = Horizon Cloud Service next-gen se encuentra aquí: https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vdm&details=1&horizonVersion=666&page=1&display_interval=10&sortColumn=Partner&sortOrder=Asc

Nota: Actualmente no se pueden migrar las preferencias de escritorio de los usuarios finales establecidas en Horizon Client para cada escritorio. Los usuarios finales que deseen incluirlas deberán volver a establecerlas en sus clientes después de la migración.
Elementos excluidos
Actualmente no se admiten los siguientes escenarios para la migración:
  • Pods implementados en entornos de Azure Government.
  • Los pods de Horizon Cloud on Microsoft Azure que participan en asignaciones que implican dos o más pods.
  • Las situaciones en las que los usuarios finales o sus clientes deben usar PCoIP con la implementación de Horizon Cloud on Microsoft Azure.
    Nota: La migración de autoservicio automatizada no puede detectar si los usuarios finales quieren o precisan usar PCoIP. Usted y los administradores de VDI deben comprobar si esta situación se aplica a los usuarios finales.
  • Los clientes ligeros de Horizon que no se encuentran en la matriz de compatibilidad de VMware no se admiten para el uso posterior a la migración. Cuando se encuentre con un caso práctico en el que los usuarios finales utilicen clientes ligeros de Horizon, compruebe la matriz de compatibilidad entre el dispositivo y el modelo de cliente ligero de Horizon y Horizon Cloud Service next-gen antes de continuar con la migración. Solo se admiten clientes ligeros de Horizon que aparecen como compatibles con Horizon Cloud Service next-gen.

    La matriz de compatibilidad entre los clientes ligeros de Horizon y la versión de la plataforma de Horizon = Horizon Cloud Service next-gen se encuentra aquí: https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vdm&details=1&horizonVersion=666&page=1&display_interval=10&sortColumn=Partner&sortOrder=Asc

Nota: Como se describe en el artículo 91183 de la base de conocimientos de VMware del 30 de junio de 2023, los paneles de control históricos y los informes basados en datos de Cloud Monitoring Service (CMS) solo están disponibles a través de Workspace ONE Intelligence. Si seguía los pasos del artículo de la base de conocimientos antes del 30 de junio de 2023, los datos del pod de Horizon Cloud on Microsoft Azure - first-gen inicialmente estaban disponibles en la consola de Workspace ONE Intelligence.

Cuando el pod de Horizon Cloud on Microsoft Azure de first-gen se migra al entorno de next-gen, el tipo de datos de serie temporal para ese pod seguirá estando disponible en Workspace ONE Intelligence después de la migración.

Si VMware le habilitó acceso al asistente de migración de next-gen en Horizon Universal Console - first-gen, en este asistente se mostrarán las funciones disponibles en Horizon Cloud on Microsoft Azure - first-gen que dejan de estarlo tras la migración a Horizon Cloud Service - next-gen.

Los administradores deben informar a los usuarios finales sobre la migración y dejarles saber que la experiencia de usuario de Horizon Cloud Service - next-gen difiere en algunos aspectos de la que ofrece Horizon Cloud on Microsoft Azure - first-gen. Por ejemplo, en el vídeo VMware Horizon Cloud Service Login Flows de Tech Zone se explican las diferencias en la experiencia de inicio de sesión.

¿La implementación de first-gen utiliza funciones que el equipo de operaciones de VMware Horizon Cloud habilitó o le proporcionó de forma selectiva, o están integradas con Workspace ONE Access?

Es posible que el equipo de operaciones de VMware Horizon Cloud haya habilitado de forma selectiva algunas funciones para su implementación de first-gen. Puede que se le permita usar algunos elementos con condiciones especiales, por ejemplo, API privadas.

Revise con su equipo si alguno de los siguientes factores afecta a su implementación:

  • ¿Está configurado el arrendatario para el brokering de pod único y la instancia de Workspace ONE Access integrada con dicho arrendatario y su pod? Si aún no contactó con el equipo de VMware Horizon Cloud para migrar el pod, envíe una solicitud de soporte para ponerse en contacto con él y obtener ayuda.
  • ¿Está configurado el arrendatario con Universal Broker e integrado con Workspace ONE Access y Servicios de Intelligent Hub? Si aún no contactó con el equipo de VMware Horizon Cloud para migrar el pod, envíe una solicitud de soporte para ponerse en contacto con él y obtener ayuda.
  • ¿Requirió la habilitación de alguna de las funciones descritas en la documentación de first-gen como disponibles cuando el arrendatario se habilita explícitamente para usarlas por solicitud? Por ejemplo, utilizar LDAPS al registrar el dominio de Active Directory, transferir máquinas virtuales individuales entre asignaciones en un mismo pod o usar permisos de ámbito limitado en granjas y asignaciones de escritorios con las funciones predefinidas integradas. Si la respuesta es sí, envíe una solicitud de soporte para ponerse en contacto con el equipo de VMware Horizon Cloud para obtener instrucciones.
  • ¿Desarrolló scripts basados en API que VMware le proporcionó para usarlas con el plano de control de first-gen? Será necesario escribir de nuevo esos scripts o herramientas con las API del plano de control de next-gen. Consulte la documentación de la API de Horizon Cloud Service - next-gen para obtener información sobre esas API.
  • ¿Definió su equipo (o el equipo de operaciones de VMware Horizon Cloud en su nombre) funciones o propiedades específicas en la configuración de Unified Access Gateway de la implementación? Por ejemplo, syslog, opciones avanzadas de RADIUS, enrutamiento personalizado en las subredes de arrendatarios o de administración, o cambio de los tamaños predeterminados de la unidad máxima de transferencia (Maximum Transmissible Unit, MTU) en las instancias de Unified Access Gateway. Si la respuesta es sí, envíe una solicitud de soporte para ponerse en contacto con el equipo de VMware Horizon Cloud para obtener instrucciones.
  • ¿Configuró el equipo de operaciones de VMware Horizon Cloud en su nombre propiedades específicas relacionadas con las instancias del administrador de pods de la implementación? Por ejemplo, al cambiar el valor de tiempo de espera predeterminado del subproceso de memoria caché de usuario o deshabilitar la validación de permisos de cuentas de unión de dominio. Si la respuesta es sí, envíe una solicitud de soporte para ponerse en contacto con el equipo de VMware Horizon Cloud para obtener instrucciones.
  • ¿Configuró el equipo de operaciones de VMware Horizon Cloud otros elementos de la implementación que no se describen en la documentación de first-gen como funciones disponibles para el público general o por solicitud? Si la respuesta es sí, envíe una solicitud de soporte para ponerse en contacto con el equipo de VMware Horizon Cloud para obtener instrucciones.