Información sobre el proceso de transición del agente de pod único a Universal Broker

Este tema presenta el proceso de transición de agente para el arrendatario de Horizon Cloud y los beneficios que pueden obtenerse al realizar la transición. Obtenga información sobre las diferencias entre un agente de pod único y un entorno de Universal Broker, y lo que puede esperar antes, durante y después de la transición del agente.

¿Cuál es el proceso de transición del agente?

Cuando se completa la transición del agente, el entorno de arrendatario de Horizon Cloud cambia de usar el agente de pod único a usar Universal Broker para el brokering de recursos de las asignaciones de usuario final. Como nuevo agente para todo el arrendatario, Universal Broker administra las solicitudes de conexión de los usuarios y las enruta al mejor recurso disponible de la asignación solicitada.

El proceso de transición del agente realiza los siguientes cambios en las asignaciones de usuario final.

• Las asignaciones de escritorios VDI se convierten en asignaciones de varias nubes con brokering de Universal Broker. Una asignación de varias nubes puede incluir escritorios VDI de varios pods.
• Las asignaciones de aplicaciones y escritorios basados en sesiones no se modifican. Una asignación de aplicaciones o escritorios basados en sesiones puede incluir recursos de pod único, pero el brokering de la asignación ahora lo lleva a cabo Universal Broker.

La función de transición está disponible si el entorno utiliza actualmente el brokering de pod único y cumple los requisitos previos descritos en Horizon Cloud: requisitos del sistema para la transición a Universal Broker.

¿Por qué debe realizarse la transición a Universal Broker?

Cuando se pasa a utilizar Universal Broker, la tecnología de brokering basada en la nube más reciente de VMware, se obtienen las siguientes ventajas clave.

Asignaciones de usuario final con escritorios VDI de varios pods

Con el brokering de pod único, todos los escritorios de una asignación de VDI deben ser del mismo pod. El brokering de escritorio se realiza por pod.

Con Universal Broker, puede crear una asignación de escritorios VDI desde varios pods, una acción también denominada asignación de varias nubes. Un usuario final puede acceder a la asignación y recibir un escritorio desde cualquier pod incluido en esa asignación. Para obtener más información, consulte Introducción a VMware Horizon Service Universal Broker y sus subtemas.

También puede seguir usando las asignaciones de aplicaciones y escritorios basados en sesiones como antes. La diferencia es que el brokering de las aplicaciones y los escritorios basados en sesiones de estas asignaciones lo lleva a cabo Universal Broker en lugar de realizarse un brokering por pod.

FQDN de conexión única para todos los recursos remotos

Con el brokering de pod único, los usuarios finales deben conectarse al nombre de dominio completo (FQDN) de cada pod de forma individual para acceder a las asignaciones desde el pod. El brokering se realiza por pod.

Con Universal Broker, los usuarios pueden acceder a todas las asignaciones conectándose a un solo FQDN, que se define en los ajustes de configuración de Universal Broker. A través del FQDN único, los usuarios pueden acceder a las asignaciones desde todos los pods participantes, incluidos los pods de Horizon Cloud en Microsoft Azure y los pods de Horizon en una plataforma basada en VMware SDDC, desde cualquier sitio del entorno. No se requiere ninguna red interna entre los pods.

Conectividad de pods global y detección de un rendimiento óptimo

Universal Broker mantiene la conectividad directa con cada pod que participa en las asignaciones de varias nubes y sigue detectando el estado de disponibilidad de cada pod. Como resultado, Universal Broker puede administrar las solicitudes de conexión de los usuarios finales y enrutarlas directamente a los recursos virtuales desde los pods. No se precisa recurrir al equilibrio de carga del servidor global (Global Server Load Balancing, GSLB) ni a ninguna comunicación de red entre pods que pueda causar problemas de reducción de rendimiento y latencia.

Brokering inteligente

Universal Broker puede realizar brokering de recursos de las asignaciones a los usuarios finales en la ruta de red más corta, según el reconocimiento de los sitios geográficos y la topología del pod.

¿Hay alguna razón para no realizar la transición?

Esta versión de Universal Broker tiene algunas limitaciones de funciones. Si el caso práctico requiere una función que Universal Broker no admite, considere la posibilidad de mantener el entorno de arrendatario mediante brokering de pod único hasta que Universal Broker admita la función. Para obtener una lista de las limitaciones actuales de Universal Broker, consulte Universal Broker: consideraciones sobre funciones y limitaciones conocidas.

¿Qué sucede durante la transición del agente?

El flujo de trabajo de transición consta de varias etapas. Para obtener instrucciones detalladas paso a paso sobre cómo realizar la transición, consulte Programar y completar la transición del agente de pod único a Universal Broker.

A continuación se presenta una descripción de nivel general de los procesos que se producen antes y durante la transición.

1. Para iniciar el flujo de trabajo, primero debe programar una fecha y una hora para que se lleve a cabo la transición. Junto con esta tarea de programación, se definen las opciones de configuración que se utilizarán para configurar el servicio de Universal Broker durante la transición.
2. Al menos 15 minutos antes de la hora de inicio programada, complete todas las operaciones en curso en la consola y guarde los cambios que desee conservar. Cierre todos los cuadros de diálogo y los asistentes de configuración. Asegúrese también de que todos los pods de Microsoft Azure estén en línea y en un estado correcto y a punto.
3. Cuando la transición esté a punto de iniciarse, se le pedirá que cierre sesión en la consola y que vuelva a iniciarla.
4. Durante la primera etapa de la transición, este es el escenario previsto:
   • No podrá acceder a ninguno de los controles de edición de la consola, y la consola muestra un banner que indica que la transición está en curso.
   • Todos los pods de Microsoft Azure se agregan a un sitio denominado Default-Site.
   • Las asignaciones de escritorios VDI se convierten en asignaciones de varias nubes con brokering de Universal Broker. En la configuración de asignación predeterminada, la afinidad de conexión se establece en Sitio más cercano y el ámbito se establece en Dentro del sitio.
   • Las asignaciones de aplicaciones y escritorios basados en sesiones permanecen sin cambios. Después de la transición, el brokering de los recursos de estas asignaciones lo llevará a cabo Universal Broker.
   • Todas las asignaciones permanecen disponibles para los usuarios finales y todas las sesiones de usuario activas permanecen abiertas y completamente operativas durante este tiempo.
   Nota: Esta etapa de la transición suele tardar unos 10 minutos, pero puede tardar hasta una hora si el entorno de arrendatario contiene un gran número de asignaciones.

   Cuando se complete esta etapa de la transición, se le pedirá que cierre sesión en la consola y que vuelva a iniciarla.

5. Durante la segunda etapa de la transición, el servicio de Universal Broker completa su proceso de configuración y se habilita por completo. Puede acceder a todas las operaciones de edición en la consola, excepto la creación y edición de asignaciones.
   Nota: Esta etapa de la transición suele tardar hasta 30 minutos. Sin embargo, en función de las condiciones del sistema y de la red, así como del número total de asignaciones y asignaciones de usuario a escritorio dedicadas en el entorno, esta fase puede tardar varias horas en completarse.

   Cuando se completa esta etapa de la transición, la página Configuración > Agente muestra el estado Habilitado con un punto verde.

   En este punto, se completa la transición general del agente.

¿Qué se puede esperar después de la transición del agente?

Para obtener una lista detallada de los cambios realizados en el entorno de arrendatario después de la transición del agente, consulte Novedades en el entorno de arrendatario después de la transición a Universal Broker.

Después de completar la transición, puede comenzar a aprovechar las ventajas que ofrece un entorno de Universal Broker. La siguiente lista explica brevemente qué debe hacer a continuación e incluye vínculos a páginas con más detalles.

• Modifique la configuración de la asignación de VDI de varias nubes y el sitio para aprovechar al máximo las capacidades de Universal Broker. Por ejemplo, puede agregar más pods a una asignación existente o puede ajustar la configuración del sitio para detallar mejor la forma en que Universal Broker asigna recursos a los usuarios. Para obtener información detallada, consulte Crear y administrar asignaciones en el entorno de Universal Broker y Trabajar con sitios de en un entorno de Universal Broker.
• Si ya existe una integración entre el arrendatario de Horizon Cloud y Workspace ONE Access, debe actualizar la integración para acomodar el uso de Universal Broker. Para obtener instrucciones completas, consulte Entorno de Horizon Cloud con Universal Broker: integrar el arrendatario con los Servicios de Intelligent Hub y Workspace ONE Access.
  Nota: Como confirmó el equipo de producto de VMware Workspace ONE Access, cuando se usa Universal Broker con implementaciones de Horizon Cloud on Microsoft Azure, la función de colecciones de aplicaciones virtuales del producto VMware Workspace ONE Access no es compatible con esa configuración. Universal Broker es una tecnología de brokering más moderna que el antiguo brokering por pod, y en la integración de Universal Broker con Workspace ONE Access se reemplaza el uso de las colecciones de aplicaciones virtuales por pod heredadas para las implementaciones de Horizon Cloud on Microsoft Azure. Por lo tanto, Universal Broker no tiene ningún concepto de colecciones de aplicaciones virtuales para implementaciones de Horizon Cloud on Microsoft Azure, y esto hace que el uso de colecciones de aplicaciones virtuales con configuraciones de Universal Broker y Horizon Cloud on Microsoft Azure sea incompatible.

  Si se configura Universal Broker para las implementaciones de Horizon Cloud on Microsoft Azure y piensa utilizar los Servicios de Workspace ONE Access e Intelligent Hub con dichas implementaciones de Horizon Cloud on Microsoft Azure, en el proceso de integración, en el transcurso de la acción Limpiar de la consola, se le pedirá que limpie todas las colecciones de aplicaciones virtuales existentes que puedan tener esas implementaciones. Cuando se completen las actividades de limpieza, las mismas aplicaciones seguirán funcionando en los Servicios de Workspace ONE Access e Intelligent Hub, utilizando las funciones modernas de Universal Broker y los Servicios de Workspace ONE Access e Intelligent Hub.

Horizon Cloud: requisitos del sistema para la transición a Universal Broker

En este artículo se describen los requisitos que el entorno de arrendatario de Horizon Cloud debe cumplir para poder programar y completar la transición del arrendatario desde el uso de brokering de pod único a Universal Broker. También sigue los pasos de planificación y preparación para admitir el nuevo FQDN de conexión Universal Broker.

Para admitir el proceso de transición y las operaciones en curso de las asignaciones de varias nubes con brokering de Universal Broker después de la transición, compruebe que el entorno de arrendatario cumpla con los siguientes requisitos.

Precaución: Si el grupo de pods del arrendatario contiene una combinación de pods de Horizon que ya utilizan Universal Broker y pods de Horizon Cloud que utilizan brokering de pod único, debe tener un cuidado especial en que la configuración de autenticación en dos fases de la configuración de Universal Broker ya configurada coincida con los pods de Horizon Cloud.

• A menos que los pods de Horizon Cloud cumplan los criterios de habilitación y manifiesto mínimos del pod de la opción RSA SecurID en el entorno de arrendatario, dichos pods solo admiten la autenticación RADIUS. (Para obtener más información, consulte Prácticas recomendadas al implementar una autenticación en dos fases en un entorno de Universal Broker).
• Si los pods de Horizon Cloud no cumplen con ese criterio para tener RSA SecurID configurados en sus puertas de enlace externas, si desea utilizar la autenticación en dos fases con todos los pods del grupo (tanto los pods de Horizon como los pods de Horizon Cloud), cada pod tendrá que tener un Unified Access Gateway externo con autenticación en dos fases RADIUS configurada en él.

Requisitos para pods de Horizon Cloud

Compruebe que los pods de Horizon Cloud en Microsoft Azure cumplan los siguientes requisitos.

• El arrendatario tiene al menos un pod de Horizon Cloud. Un pod de Horizon Cloud se basa en la tecnología del administrador de pods, que se ejecuta en Microsoft Azure.
• Todos los pods de Horizon Cloud del arrendatario se ejecutan en el manifiesto del pod 2298.0 o una versión posterior. Los siguientes requisitos también se aplican a determinados casos prácticos.
  • Si existe una integración entre el arrendatario de Horizon Cloud y Workspace ONE Access, todos los pods deben ejecutarse en el manifiesto 2474.0 o una versión posterior. Después de completar la transición del agente, debe actualizar la integración para adoptar el uso de Universal Broker, como se describe en Entorno de Horizon Cloud con Universal Broker: integrar el arrendatario con los Servicios de Intelligent Hub y Workspace ONE Access.
  • Si desea utilizar la función de cancelación de tareas o la función de protección contra eliminación después de la transición del agente, todos los pods de Horizon Cloud deben ejecutarse en el manifiesto 2474.0 o una versión posterior. Estas funciones no se admiten si los pods se ejecutan en manifiestos anteriores a la versión 2474.0.
  Importante: Asegúrese de que todos los pods de Horizon Cloud estén en línea y en un estado correcto y listo. El servicio de Universal Broker debe comunicarse con los pods y realizar algunos pasos de configuración en los pods para completar el proceso de transición. Si alguno de esos pods está sin conexión o no está disponible, no puede programar la transición. Si programa la transición, pero alguno de los pods se desconecta o deja de estar disponible mientras la transición está en curso, se produce un error en la configuración de Universal Broker.
• No hay actualizaciones de pod programadas para que se produzcan al mismo tiempo que la transición.
• La ubicación del pod se configura seleccionando una ubicación válida en las opciones de menú del asistente de configuración del pod. Si se configuró la ubicación del pod escribiéndola manualmente en un campo de texto, se producirá un error en la transición.
  Nota: Este problema relacionado con una ubicación escrita manualmente es más probable que se produzca para los pods que se implementaron inicialmente antes de marzo de 2019 (versión de servicio 1.9). A partir de la versión de marzo de 2019, las ubicaciones deben seleccionarse por menú entre los valores de la base de datos de nombres de ciudades del mundo del sistema.

  Para reducir la probabilidad de que ocurra esta situación, donde se produce un error en la transición debido a la ubicación configurada del pod, desplácese hasta la página Capacidad de la consola y examine el valor de la columna Ubicación de cada pod de Horizon Cloud. Si el valor de la columna Ubicación parece un nombre escrito manualmente, utilice la acción Editar en el pod, vaya al paso Detalles del pod y edite el campo Ubicación para establecer su valor en uno de los nombres de ciudad del sistema.

• Durante el flujo de trabajo de transición, si el arrendatario aún no tiene configuración de Universal Broker de ningún pod de Horizon del grupo de pods, la consola le solicitará la configuración de Universal Broker. Cuando planea establecer el ajuste de autenticación en dos fases en la configuración de Universal Broker, cada pod debe tener una instancia de Unified Access Gateway externa y esa instancia debe configurarse con el tipo de autenticación en dos fases adecuado. (Para obtener información de referencia, consulte Prácticas recomendadas al implementar una autenticación en dos fases en un entorno de Universal Broker).

  Los requisitos dependen de si los pods de Horizon Cloud cumplen los criterios para tener el tipo RSA SecurID configurado en sus puertas de enlace externas:

  • Cuando los pods de Horizon Cloud cumplen los criterios de habilitación y manifiesto mínimos del pod de la opción RSA SecurID en el entorno de arrendatario, se deben configurar todas las instancias de Unified Access Gateway externas en todos los pods para que usen el mismo servicio de autenticación. Esto incluye todos los pods de Horizon del arrendatario que están en estado administrado. El resultado es que todos utilizarán un tipo de autenticación coincidente, todos RADIUS o todos RSA SecurID.
  • Cuando los pods de Horizon Cloud no cumplen con ese criterio para tener RSA SecurID configurado en sus puertas de enlace externas, si desea utilizar la autenticación en dos fases con todos los pods del grupo; tanto los pods de Horizon como los pods de Horizon Cloud, debe configurar todas las instancias de Unified Access Gateway externas en todos los pods para que usen el mismo servicio de autenticación RADIUS. Esto incluye todos los pods de Horizon del arrendatario que están en estado administrado.

Nota: Si un pod incluye solo una instancia interna de Unified Access Gateway, Universal Broker anula la directiva de redes definida en la pestaña Rangos de redes de la página Agente y enruta a todos los usuarios a esa instancia de Unified Access Gateway, independientemente de su dirección IP.

Requisitos de DNS, puertos y protocolos para admitir Universal Broker

Compruebe los siguientes requisitos.

• Cada pod está configurado de forma tal que los nombres DNS requeridos para la instancia regional de Universal Broker se puedan resolver y se pueda acceder a ellos. Consulte la tabla "Requisitos de DNS de operaciones e implementación de pods" en Requisitos de DNS para un pod de Horizon Cloud en Microsoft Azure.
• Cada pod está configurado con los puertos y los protocolos necesarios, como se describe en la sección "Puertos y protocolos requeridos por Universal Broker" de Requisitos de puertos y protocolos para un pod de Horizon Cloud en el manifiesto publicado en septiembre de 2019 o posteriormente.

Requisitos de FQDN para admitir Universal Broker

Con el brokering de pod único, los usuarios finales se conectan al nombre de dominio completo (FQDN) de cada pod de forma individual para acceder a las asignaciones desde el pod.

Después de la transición a Universal Broker, los usuarios pueden acceder a cualquier asignación, desde cualquier pod de cualquier sitio del entorno, mediante la conexión al FQDN del servicio de nube de Universal Broker. Universal Broker enruta cada solicitud de usuario al FQDN individual del pod más adecuado que puede satisfacer la solicitud.

Designe el FQDN Universal Broker en los ajustes de configuración de Universal Broker, como se describe en Programar y completar la transición del agente de pod único a Universal Broker. Puede crear el FQDN si agrega un prefijo con su subdominio válido al dominio estándar proporcionado por VMware, o bien puede configurar un FQDN totalmente personalizado.

Nota: Si decide configurar un FQDN personalizado, tenga en cuenta que este FQDN representa a su empresa u organización. Asegúrese de que es el propietario del nombre de dominio especificado en el FQDN personalizado, que pueda proporcionar un certificado que valide ese dominio y que tenga la autorización adecuada para usar el FQDN personalizado. El FQDN personalizado para Universal Broker debe ser único y distinto de los FQDN de todas las instancias de Unified Access Gateway dentro de los pods.

Planificar y preparar la transición del agente

Dado que la transición del agente implica cambios clave en el flujo de trabajo de asignación y de redes, asegúrese de realizar las acciones necesarias para preparar el entorno y los usuarios para el nuevo flujo de trabajo. Consulte la siguiente guía de planificación para ver los pasos adecuados de preparación y administración de cambios en función del caso práctico de transición.

Caso práctico de transición	Pasos de planificación y preparación
El entorno consta de un solo pod y desea utilizar el FQDN existente del pod como FQDN de Universal Broker	Durante la fase de configuración del proceso de programación de transición designe el FQDN existente del pod como FQDN personalizado para el servicio de Universal Broker. Programe la transición para una fecha y una hora que provocarán una interrupción mínima de las cargas de trabajo de asignación de los usuarios finales. Notifique y prepare a los usuarios finales para la próxima transición. Recuérdeles que deben guardar su trabajo y cerrar sesión en sus sesiones de conexión activas a medida que se aproxima el tiempo de transición. Poco antes de la transición, asigne una nueva dirección IP y un FQDN al pod. Una vez completada la transición, informe a los usuarios finales de que pueden reanudar sus sesiones de conexión con el FQDN anterior del pod, que ahora es el FQDN de Universal Broker.
El entorno consta de varios pods y desea configurar un nuevo FQDN como FQDN de Universal Broker	Actualice los runbooks para incluir los procedimientos necesarios que deben seguirse antes, durante y después del proceso de transición. Durante la fase de configuración del proceso de programación de la transición, configure el nuevo FQDN para el servicio de Universal Broker. Programe la transición para una fecha y una hora que provocarán una interrupción mínima de las cargas de trabajo de asignación de los usuarios finales. Asigne un tiempo adecuado a la formación del usuario y la reconfiguración del software cliente, conforme a la escala de las implementaciones de pods. Notifique y prepare a los usuarios finales para la próxima transición. Recuérdeles que deben guardar su trabajo y cerrar sesión en sus sesiones de conexión activas a medida que se aproxima el tiempo de transición. Durante la transición, o poco después de la transición, vuelva a configurar Horizon Client en los sistemas cliente de los usuarios para conectarse al nuevo FQDN de Universal Broker, en lugar de los FQDN de los pods individuales. Informe a los usuarios finales de que ahora deben utilizar el nuevo FQDN de conexión de agente y que, en consecuencia, pueden obtener acceso universal a todos los pods de su entorno.

Programar y completar la transición del agente de pod único a Universal Broker

Este tema sigue los pasos de programación, preparación y finalización de la transición a Universal Broker. Consulte el siguiente procedimiento para obtener información sobre cómo configurar el servicio de Universal Broker, definir una fecha y hora de inicio para la transición y navegar sin problemas por las etapas del proceso para lograr una transición correcta.

Aparece un banner de notificación con un botón Programación en la parte superior de Horizon Universal Console cuando la transición del agente está lista para programarse.

Nota: Si el banner muestra una condición de error que impide que se programe la transición, es probable que no se hayan cumplido uno o varios de los requisitos previos para la transición. Haga clic en Ver errores en el banner y, a continuación, haga clic en el icono de error junto al vínculo Transición requerida de la página Agente para ver detalles sobre la condición de error. Debe realizar los pasos necesarios para borrar la condición de error antes de programar la transición.

Requisitos previos

Verifique que el entorno de arrendatario cumpla con todos los requisitos previos indicados en Horizon Cloud: requisitos del sistema para la transición a Universal Broker.

Procedimiento

1. Haga clic en Programación en el banner de notificación de la transición del agente.
   
   
   
   Esta acción le redirigirá a la página Agente. La página indica que el agente de pod único está habilitado actualmente para el arrendatario y proporciona un vínculo para programar la transición del agente.

   
   
   
2. En la página Agente, haga clic en el vínculo Programación.
   Al realizar esta acción, aparece el asistente de configuración para el Universal Broker. Debe completar los pasos de este asistente para configurar Universal Broker para sus pods en Microsoft Azure y para programar la transición a Universal Broker.

   
   
   
3. En la página FQDN del asistente, configure los ajustes para el FQDN de conexión de brokering. Esta configuración define la dirección de la conexión dedicada que utilizarán los usuarios finales para acceder a los recursos asignados por Universal Broker.
   Nota: Cuando se modifica la configuración de un subdominio o FQDN, es posible que el cambio demore algún tiempo en aplicarse a todos los servidores DNS.
   1. Para Tipo, seleccione una de las siguientes opciones para el nombre de dominio completo (FQDN): Proporcionado por VMware o Personalizado.
   2. Especifique la configuración adicional para el tipo de FQDN seleccionado.
      • Si seleccionó el tipo Proporcionado por VMware, especifique la configuración de la siguiente manera.

        Configuración	Descripción
        Sub Domain	Introduzca el nombre DNS único de un subdominio válido en la configuración de red que representa a su empresa u organización. Este subdominio se antepone al dominio proporcionado por VMware para formar el FQDN de brokering. Nota: Algunas cadenas no están permitidas o están reservadas por el sistema. Esta categoría de cadenas incluye palabras genéricas como book, términos conocidos que son propiedad de una empresa, como gmail, y términos relacionados con protocolos, codificación y código abierto como php y sql. El sistema tampoco permite una categoría de patrones de estas cadenas, como mail0, mail1, mail2, etc. Sin embargo, cuando escribe un nombre no permitido en este campo, el sistema no valida la entrada en ese momento. Solo cuando llegue al paso de resumen final del asistente, el sistema validará el nombre que ha introducido aquí y mostrará un error si la entrada coincide con uno de los nombres no permitidos. Si esto ocurre, introduzca un nombre diferente y más exclusivo aquí.
        Brokering FQDN	Este campo de solo lectura muestra el FQDN configurado. El FQDN utiliza el formato https://<your sub-domain>vmwarehorizon.com. Proporcione este FQDN a los usuarios finales para permitir que se conecten al servicio de Universal Broker con Horizon Client. Universal Broker administra la validación de DNS y SSL de este FQDN.

      • Si seleccionó el tipo Personalizado, especifique los ajustes de la siguiente manera.

        Configuración	Descripción
        Brokering FQDN	Introduzca el FQDN personalizado que utilizarán los usuarios finales para acceder al servicio de Universal Broker. El FQDN personalizado funciona como un alias para el FQDN proporcionado por VMware generado automáticamente que completa la conexión al servicio. Debe ser el propietario del nombre de dominio especificado en el FQDN personalizado y proporcionar un certificado que pueda validar ese dominio. Nota: El FQDN personalizado, también conocido como URL de conexión, representa a su empresa u organización. Asegúrese de contar con la autorización adecuada para utilizar este FQDN personalizado. Nota: El FQDN personalizado debe ser único y distinto de los FQDN de todas las instancias de Unified Access Gateway dentro de los pods. Importante: Debe crear un registro CNAME en el servidor DNS que asigne el FQDN personalizado al FQDN proporcionado por VMware que representa la dirección de conexión interna del servicio de Universal Broker. Por ejemplo, el registro puede asignar vdi.examplecompany.com a <cadena generada automáticamente>.vmwarehorizon.com.
        Certificate	Haga clic en Examinar y cargue el certificado (en formato PFX protegido con contraseña) que valide el FQDN de gestión de agente. El certificado debe cumplir con todos los siguientes criterios: El certificado debe ser válido durante al menos 90 días El certificado debe estar firmado por una entidad de certificación de confianza El nombre común (CN) del certificado o cualquiera de sus nombres alternativos del sujeto (SAN) deben coincidir con el FQDN El contenido del certificado debe tener el formato X.509 estándar El archivo PFX debe contener la cadena de certificados completa y la clave privada: el certificado del dominio, los certificados intermedios, el certificado de CA raíz y la clave privada. El servicio de Universal Broker utiliza este certificado para establecer sesiones de conexión de confianza con los clientes.
        Password	Introduzca la contraseña para el archivo de certificado PFX.
        VMware Provided FQDN	Este campo de solo lectura muestra el FQDN proporcionado por VMware que se genera automáticamente para el servicio de brokering. El FQDN adopta el formato https://<cadena generada automáticamente>.vmwarehorizon.com. El FQDN proporcionado por VMware no resulta visible para los usuarios finales y representa la dirección de conexión interna del servicio del Universal Broker. El FQDN personalizado funciona como un alias para el FQDN proporcionado por VMware. Importante: Debe configurar una asociación de alias mediante la creación de un registro CNAME en el servidor DNS que asigne el FQDN personalizado al FQDN proporcionado por VMware. Por ejemplo, el registro puede asignar vdi.examplecompany.com a <cadena generada automáticamente>.vmwarehorizon.com.

        
        

        

        
        
   3. Una vez configurados los ajustes del FQDN, haga clic en Siguiente para avanzar una página en el asistente.
4. (Opcional) En la página Autenticación del asistente, configure la autenticación en dos fases.
   De forma predeterminada, Universal Broker autentica a los usuarios únicamente a través de su nombre de usuario y contraseña de Active Directory. Si lo desea, puede implementar la autenticación en dos fases especificando un método de autenticación adicional. Para obtener más información, consulte Prácticas recomendadas para implementar una autenticación en dos fases en un entorno de Universal Broker.
   Importante: Para utilizar la autenticación en dos fases con el Universal Broker, en primer lugar debe configurar el servicio de autenticación adecuado en las distintas instancias externas de Unified Access Gateway para cada pod participante. Las configuraciones de las instancias externas de Unified Access Gateway deben ser idénticas dentro de los pods participantes y entre ellos.

   Por ejemplo, si desea utilizar la autenticación RADIUS, debe configurar el servicio RADIUS en todas las instancias externas de Unified Access Gateway para todos los pods de Horizon y Microsoft Azure participantes.

   No elimine ninguna instancia de Unified Access Gateway en los pods participantes. Dado que Universal Broker se basa en Unified Access Gateway para el tráfico de protocolo entre Horizon Client y los recursos virtuales, los usuarios no podrán acceder a los recursos aprovisionados desde un pod participante si elimina la instancia de Unified Access Gateway en ese pod.

   Configuración	Descripción
   Two-Factor Authentication	Para utilizar la autenticación en dos fases, habilite esta función. Cuando se habilita esta función, se presentan opciones adicionales para configurar la autenticación de dos factores.
   Maintain User Name	Habilite esta opción para mantener el nombre de usuario de Active Directory del usuario durante la autenticación en Universal Broker. Cuando está habilitada: En el caso del Universal Broker, el usuario debe tener las mismas credenciales de nombre de usuario para la autenticación de Active Directory y para el método de autenticación adicional. El usuario no puede cambiar el nombre de usuario en la pantalla de inicio de sesión del cliente. Si se desactiva esta opción, el usuario puede escribir otro nombre de usuario en la pantalla de inicio de sesión.
   Type	Especifique el método de autenticación que Universal Broker debe utilizar con los usuarios finales, además del nombre de usuario y la contraseña de Active Directory. La interfaz de usuario muestra dos opciones, RADIUS y RSA SecurID. Esta opción se aplica a todo el arrendatario. El comportamiento en el cliente del usuario final dependerá de la composición del grupo de pods del arrendatario y del tipo de autenticación en dos fases configurado en las puertas de enlace de los pods, como se indica a continuación: Solo pods de Horizon El tipo que seleccione aquí es el que se utiliza en el cliente. Solo pods de Horizon Cloud Seleccione el tipo que coincida con el que está configurado en las puertas de enlace externas de los pods. Combinación de pods de Horizon e implementaciones de Horizon Cloud on Microsoft Azure En un grupo combinado, cuando se selecciona aquí RADIUS, las solicitudes de autenticación RADIUS de los usuarios se intentan a través de instancias de Unified Access Gateway de ambos tipos de pods. En un grupo combinado, cuando se selecciona aquí RSA SecurID, el comportamiento del cliente depende de si las implementaciones de Horizon Cloud on Microsoft Azure están configuradas con RSA SecurID en sus puertas de enlace externas. Si las implementaciones de Horizon Cloud on Microsoft Azure no tienen configurado el tipo RSA SecurID en sus puertas de enlace y RSA SecurID se selecciona aquí, las solicitudes de autenticación de RSA de los usuarios se intentan a través de las instancias de Unified Access Gateway solo de los pods de Horizon. Las solicitudes de autenticación de nombre de usuario y contraseña de Active Directory se intentan a través de las instancias de Unified Access Gateway en pods de Horizon o pods de Horizon Cloud. Si las implementaciones de Horizon Cloud on Microsoft Azure tienen configurado el tipo de RSA SecurID, las solicitudes de autenticación RSA de los usuarios se intentan a través de las instancias Unified Access Gateway de ambos tipos de pod.
   Show Hint Text	Habilite esta opción para configurar una cadena de texto que se muestre en la pantalla de inicio de sesión del cliente para facilitar la solicitud de las credenciales del usuario correspondientes al método de autenticación adicional.
   Custom Hint Text	Introduzca la cadena de texto que desea mostrar en la pantalla de inicio de sesión del cliente. Aparece la sugerencia especificada para el usuario final como Enter your DisplayHint user name and password, donde DisplayHint es la cadena de texto que introduce en el cuadro de texto. Nota: Universal Broker no permite los siguientes caracteres en el texto de sugerencia personalizado: & < > ' " Si incluye alguno de estos caracteres no permitidos en el texto de sugerencia, se producirá un error en las conexiones del usuario al FQDN de Universal Broker. Esta sugerencia puede servir de orientación a los usuarios para introducir las credenciales correctas. Por ejemplo, introducir la frase Nombre de usuario de la empresa y contraseña de dominio a continuación para derivará en una solicitud para el usuario final que indica: Enter your Company user name and domain password below for user name and password.
   Skip Two-Factor Authentication	Habilite esta opción para omitir la autenticación en dos fases para los usuarios de red internos que se conectan al servicio de Universal Broker. Asegúrese de que especificó los rangos de IP públicas pertenecientes a la red interna, tal como se describe en Definir rangos de redes internas para Universal Broker. Cuando esta opción está habilitada, los usuarios internos deben introducir solo sus credenciales de Active Directory para autenticarse en el servicio de Universal Broker. Los usuarios externos deben introducir las credenciales de Active Directory y sus credenciales para el servicio de autenticación adicional. Cuando esta opción está desactivada, los usuarios internos y externos deben introducir sus credenciales de Active Directory y sus credenciales para el servicio de autenticación adicional.
   Public IP Ranges	Este campo está visible cuando Omitir autenticación en dos fases está habilitado. Cuando uno o varios rangos de IP públicas ya están especificados en la pestaña Rangos de redes de la página Agente, este campo es de solo lectura e indica los rangos de IP. Cuando la pestaña Rangos de redes de la página Agente no tiene rangos de IP públicas ya especificados, puede utilizar este campo para especificar los rangos de IP públicas que representan la red interna, con el fin de omitir las solicitudes de autenticación en dos fases para el tráfico proveniente de esos rangos. Universal Broker considera que los usuarios que se conectan desde una dirección IP dentro de uno de estos rangos son usuarios internos. Para obtener más información sobre la finalidad de especificar estos rangos, consulte Definir rangos de redes internas para Universal Broker.

   Una vez configurada la autenticación en dos fases, haga clic en Siguiente para avanzar una página en el asistente.
5. En la página Configuración del asistente de configuración, especifique los ajustes de Duraciones para Horizon Client.
   Esta configuración de tiempo de espera se aplica a la sesión de conexión entre Horizon Client y el escritorio asignado por Universal Broker. Esta configuración no se aplica a la sesión de inicio de sesión del usuario en el sistema operativo invitado del escritorio asignado. Cuando Universal Broker detecta las condiciones de tiempo de espera especificadas por esta configuración, cierra la sesión de conexión de Horizon Client del usuario.

   Configuración	Descripción
   Client Heartbeat Interval	Controla el intervalo en minutos, entre latidos de Horizon Client y el estado de conexión del usuario con Universal Broker. Estos latidos informan a Universal Broker sobre la cantidad de tiempo de inactividad transcurrido durante la sesión de conexión de Horizon Client. El tiempo de inactividad se mide cuando no se produce ninguna interacción con el dispositivo endpoint que ejecuta Horizon Client. Este tiempo de inactividad no se ve afectado por la inactividad en la sesión de inicio de sesión en el sistema operativo invitado que subyace al escritorio asignado del usuario. En implementaciones de escritorios de gran tamaño, aumentar la opción Intervalo de latidos de Client puede reducir el tráfico de red y mejorar el rendimiento.
   Client Idle User	Tiempo de inactividad máximo, en minutos, permitido durante una sesión de conexión entre Horizon Client y Universal Broker. Cuando se alcanza el tiempo máximo, el período de autenticación del usuario caduca, y Universal Broker cierra todas las sesiones activas de Horizon Client. Para volver a abrir una sesión de conexión, los usuarios deben volver a introducir sus credenciales de autenticación en la pantalla de inicio de sesión de Universal Broker. Nota: Para evitar desconectar usuarios de forma inesperada de sus escritorios asignados, establezca el tiempo de espera de Usuario en espera de Client en un valor que sea al menos el doble del que aparece en Intervalo de latidos de Client.
   Client Broker Session	Tiempo máximo, en minutos, permitido para una sesión de conexión de Horizon Client antes de que caduque la autenticación del usuario. El tiempo comienza cuando el usuario realiza la autenticación en Universal Broker. Cuando se agota el tiempo de espera de la sesión, los usuarios pueden seguir trabajando en el escritorio asignado. Sin embargo, si realizan una acción (como cambiar la configuración), que requiere comunicación con Universal Broker, Horizon Client les solicita que vuelvan a introducir sus credenciales de Universal Broker. Nota: El tiempo de espera de la Sesión de agente de Client debe ser mayor o igual a la suma del valor Intervalo de latidos de Client y el tiempo de espera del Usuario en espera de Client.
   Client Credential Cache	Controla si se deben almacenar las credenciales de inicio de sesión del usuario en la memoria caché del sistema cliente. Introduzca 1 para almacenar las credenciales de usuario en la memoria caché. Introduzca 0 si no desea almacenar las credenciales de usuario en la memoria caché.

   Una vez configurados los ajustes de las duraciones, haga clic en Siguiente para avanzar una página en el asistente.
6. En la página Programación del asistente, utilice los controles para especificar una Fecha y una Hora de inicio para que se lleve a cabo la transición del agente.
   
   

   

   
   
   Puede programar una hora de inicio con un adelanto de una hora respecto a la hora local actual y de hasta 3 meses respecto a la fecha actual. La hora de inicio debe suceder al principio de la hora.
   Al establecer la hora de inicio, deje tiempo suficiente para que la transición continúe sin interrupciones.
   Cuando finalice, haga clic en Siguiente para avanzar al paso siguiente del asistente de configuración de Universal Broker.
   Nota: Si la consola muestra un mensaje que indica que la hora de inicio especificada no está disponible, vuelva a las opciones de Fecha y Hora de inicio para especificar una hora diferente para la transición.
7. Revise la configuración en la página Resumen y haga clic en Finalizar para guardar la configuración de y los ajustes de programación de Universal Broker.
   Se muestra un mensaje que confirma que la transición se ha programado correctamente.
   
   

   

   
   
   Después de programar la transición:

   • La página Agente muestra detalles sobre la próxima transición. Si para la hora de inicio falta más de una hora, puede volver a programar la transición haciendo clic en el vínculo Programación vínculo.
   • Si desea cancelar una transición programada o reprogramar una transición que comience en menos de una hora, debe ponerse en contacto con el soporte técnico de VMware. Tenga en cuenta que el soporte técnico de VMware no puede cancelar ni reprogramar una transición que comience en menos de 15 minutos.
   • La consola sigue mostrando un banner de notificación sobre la próxima transición hasta que se llegue a la hora de inicio. Al hacer clic en Ver detalles en el banner, se le redirigirá a la página Agente.
   • Los mensajes de notificación y recordatorio sobre la próxima transición se envían a la cuenta de correo electrónico principal registrada para el arrendatario.
8. Asegúrese de completar las siguientes tareas de preparación al menos 15 minutos antes de que se programe el inicio de la transición. Durante la transición, no se puede acceder a ninguna de las operaciones de edición de la consola.
   • Complete todas las operaciones en curso en la consola y guarde los cambios que desee conservar.
   • Cierre todos los cuadros de diálogo y los asistentes de configuración.

   Importante: Asegúrese de que todos los pods de Horizon Cloud en Microsoft Azure estén en línea y en buen estado mientras dure la transición. El servicio de Universal Broker debe comunicarse con los pods y realizar algunos pasos de configuración en los pods para completar la fase de habilitación del agente de la transición. Si alguno de los pods está sin conexión o no está disponible, se produce un error en la transición.

   Importante: Si tiene un entorno híbrido que consta de pods de Horizon Cloud en Microsoft Azure y pods de Horizon en una plataforma basada en VMware SDDC, el servicio de Universal Broker no estará disponible para los pods de Horizon durante la transición. Además, no puede cambiar el estado de un pod de Horizon de supervisado a administrado durante este tiempo.
9. Poco antes de que comience la transición, siga las instrucciones de la solicitud en pantalla para cerrar sesión en la consola y volver a iniciarla.
   
   

   

   
   
10. Permita que la primera etapa de la transición continúe sin interrupciones.
    Durante esta etapa de la transición:

    • No podrá acceder a ninguno de los controles de edición de la consola, y la consola muestra un banner que indica que la transición está en curso.
      
      
      
      
    • Todos los pods de Microsoft Azure se agregan a un sitio denominado Default-Site.
    • Las asignaciones de escritorios VDI se convierten en asignaciones de varias nubes con brokering de Universal Broker. En la configuración de asignación predeterminada, la afinidad de conexión se establece en Sitio más cercano y el ámbito se establece en Dentro del sitio.
    • Las asignaciones de aplicaciones y escritorios basados en sesiones permanecen sin cambios. Después de la transición, el brokering de los recursos de estas asignaciones lo lleva a cabo Universal Broker.
    • Todas las asignaciones permanecen disponibles para los usuarios finales y todas las sesiones de usuario activas permanecen abiertas y completamente operativas durante este tiempo.
    Nota: Esta etapa de la transición suele tardar unos 10 minutos, pero puede tardar más si el entorno de arrendatario contiene un gran número de asignaciones. Para supervisar el progreso, haga clic en Ver estado en el banner de notificación. Si esta etapa no se completa en una hora, se agota el tiempo de espera de la transición y se marca como error.

    El siguiente mensaje aparece cuando se completa esta etapa de la transición.
    

    

    
    

    Nota: Si se produce un error durante esta etapa de la transición, el soporte técnico de VMware recibirá una notificación automática e investigará y corregirá la causa del error. Puede ver más información en la página Agente y en los mensajes de notificación enviados a la cuenta de correo electrónico principal registrada para el arrendatario. Después de que el soporte técnico de VMware corrija la causa del error, puede usar el vínculo de la página Agente para volver a programar la transición.
11. Después de volver a iniciar sesión en la consola, permita que el servicio de Universal Broker complete su proceso de configuración y se habilite por completo.
    Por lo general, las opciones de configuración tardan unos 30 minutos en entrar en vigencia en el servicio de Universal Broker, ya que los registros de DNS se propagan entre los servidores DNS en todas las regiones globales. Sin embargo, en función de las condiciones del sistema y de la red, así como del número total de asignaciones y asignaciones de usuario a escritorio dedicadas en el entorno, este proceso puede tardar varias horas en completarse. Si el proceso no se completa en cuatro horas, se agota el tiempo de espera de la transición y se marca como error.

    Durante esta etapa de la transición, puede acceder a todas las operaciones de edición en la consola, excepto la creación y edición de asignaciones. Además, el servicio de Universal Broker no está disponible durante este tiempo para el brokering de las asignaciones.

    Cuando la configuración se complete correctamente, aparece un mensaje de notificación en la consola bajo el icono de campana y la página Configuración > Agente muestra el estado Habilitado con un punto de color verde.

    Universal Broker ya ha realizado el brokering de las asignaciones y la transición se ha completado.

    
    
    

    Importante: Si se produce un error en la configuración de la Universal Broker, la página Configuración > Agente muestra el estado Error con un icono de alerta de color rojo. Para corregir el error de configuración y configurar el servicio de Universal Broker, póngase en contacto con el Soporte de VMware, como se describe en el artículo 2006985 de la base de conocimientos (KB) de VMware.

Qué hacer a continuación

• Si ya existe una integración entre el arrendatario de Horizon Cloud y Workspace ONE Access, debe actualizar la integración para acomodar el uso de Universal Broker. Para obtener instrucciones completas, consulte Entorno de Horizon Cloud con Universal Broker: integrar el arrendatario con los Servicios de Intelligent Hub y Workspace ONE Access.
• Modifique la configuración de la asignación de VDI de varias nubes y el sitio para aprovechar al máximo las capacidades de Universal Broker. Por ejemplo, puede agregar más pods a una asignación existente o puede ajustar la configuración del sitio para detallar mejor la forma en que Universal Broker realiza el brokering de las asignaciones. Para obtener información detallada, consulte Crear y administrar una asignación de varias nubes en el entorno de arrendatario de Horizon Cloud y Trabajar con sitios en un entorno de Universal Broker.

Novedades en el entorno de arrendatario después de la transición a Universal Broker

En este artículo se describen los cambios que se pueden esperar en el entorno de arrendatario de Horizon Cloud después de completarse correctamente la transición de agente de pod único a Universal Broker. Los cambios incluyen un nuevo comportamiento y algunas limitaciones de las funciones.

Para obtener más información sobre ciertas limitaciones de funciones en el entorno de Universal Broker, consulte Universal Broker: consideraciones sobre funciones y limitaciones conocidas.

Cambios en las asignaciones de usuario final

• Todos los pods de Microsoft Azure se agregan a un sitio denominado Default-Site.
• Las asignaciones de escritorios VDI se convierten en asignaciones de varias nubes con brokering de Universal Broker. En la configuración de asignación predeterminada, la afinidad de conexión se establece en Sitio más cercano y el ámbito se establece en Dentro del sitio.
  Nota: Un usuario específico puede recibir como máximo un escritorio asignado de una asignación dedicada con brokering de Universal Broker, incluso si la asignación incluye escritorios de varios pods.
  Importante: Si un usuario recibió previamente varios escritorios asignados de una asignación dedicada en un entorno de agente de pod único, no podrá acceder a estos escritorios después de la transición a un entorno de Universal Broker. Para acceder a los escritorios asignados, el usuario puede conectarse directamente al FQDN del pod en lugar de usar el FQDN de Universal Broker.
• El brokering de las asignaciones de aplicaciones y escritorios basados en sesiones ahora lo realiza Universal Broker.

Cambios en los grupos de escritorios con nombres idénticos

Si algún grupo de escritorios de los pods tenía el mismo nombre antes de la transición del agente, se edita para tener nombres distintos. Este cambio garantiza que pueda agregar grupos de escritorios con nombre exclusivo de diferentes pods a una única asignación con brokering de Universal Broker.

Por ejemplo, supongamos que tenía el siguiente escenario antes de la transición del agente:

• El Pod1 contenía un grupo denominado TestPoolName.
• El Pod2 contenía un grupo también denominado TestPoolName.

Después de la transición, los nombres de los grupos de ejemplo cambian de la siguiente manera:

• En Pod1, el nombre del grupo sigue siendo TestPoolName.
• En Pod2, se cambia el nombre del grupo a TestPoolName1.

Cambios en el prefijo de nombres de máquina virtual

En un entorno de agente de pod único antes de la transición, el prefijo de nombres de máquina virtual de un grupo puede tener un máximo de 11 caracteres personalizables. Para formar el nombre del grupo, se anexa un número secuencial (con un máximo de cuatro dígitos) al prefijo de 11 caracteres.

Después de la transición a Universal Broker, el prefijo de nombres de máquina virtual puede constar de un máximo de nueve caracteres personalizables. Todos los prefijos de nombres de máquina virtual que antes tenían más de nueve caracteres se truncan automáticamente después de la transición.

Para formar el nombre del grupo en un entorno de Universal Broker, se anexan los siguientes caracteres al prefijo de nueve caracteres: dos caracteres alfanuméricos o alfabéticos aleatorios, seguidos de un número secuencial (con un máximo de cuatro dígitos).

Si varias asignaciones utilizan el mismo prefijo de nombres de máquina virtual, puede producirse un error al intentar editar una de las asignaciones. Para solucionar el error, cambie el prefijo de nombres de máquina virtual de la asignación en el asistente Editar.

Nota: Si un grupo de escritorios está configurado con la opción Escritorios máximos establecida en 0, el prefijo de nombre de la máquina virtual y el nombre del grupo aparecen sin cambios en Horizon Universal Console después de la transición. Para actualizar la consola para que muestre el nuevo prefijo de nombre de la máquina virtual y el nombre del grupo, realice una actualización de la asignación en transición mediante el asistente de edición.

Consideraciones sobre funciones después de la transición

Las siguientes consideraciones se aplican a ciertas funciones después de la transición a Universal Broker.

• No se admiten asignaciones de personalización (también conocidas como asignaciones de redireccionamiento de URL).
• La función de cancelación de tareas no se admite si los pods se ejecutan en un manifiesto anterior a la versión 2474.0. Para usar esta función, debe actualizar los pods con una versión de manifiesto 2474.0 o posterior.
• Si las implementaciones de Horizon Cloud on Microsoft Azure tienen una integración existente previa a la transición con Workspace ONE Access, debe actualizar la integración a un estado posterior a la transición para poder usar Universal Broker. Para obtener instrucciones completas, consulte Entorno de Horizon Cloud con Universal Broker: integrar el arrendatario con los Servicios de Intelligent Hub y Workspace ONE Access.

  Tenga en cuenta que, cuando actualice esa integración, se le pedirá que ejecute el flujo de trabajo Limpiar de Horizon Universal Console para limpiar las colecciones de aplicaciones virtuales existentes que puedan tener esas implementaciones. En el flujo de trabajo Limpiar, las mismas aplicaciones seguirán funcionando en los Servicios de Workspace ONE Access e Intelligent Hub, utilizando las funciones modernas de Universal Broker y los Servicios de Workspace ONE Access e Intelligent Hub, en lugar de la función heredada Colecciones de aplicaciones virtuales por pod. Como confirmó el equipo de producto de VMware Workspace ONE Access, cuando se usa Universal Broker con implementaciones de Horizon Cloud on Microsoft Azure, la función de colecciones de aplicaciones virtuales del producto VMware Workspace ONE Access no es compatible con esa configuración. Universal Broker es una tecnología de brokering más moderna que el antiguo brokering por pod, y en la integración de Universal Broker con Workspace ONE Access se reemplaza el uso de las colecciones de aplicaciones virtuales por pod heredadas. Por lo tanto, Universal Broker no contempla en absoluto el concepto de colecciones de aplicaciones virtuales para las implementaciones de Horizon Cloud on Microsoft Azure.

Importante: No se admite la función de protección contra eliminación para interrupciones del inventario si los pods se ejecutan en manifiestos anteriores a la versión 2474.0. Para usar esta función, debe actualizar los pods a una versión de manifiesto 2474.0 o posterior.

Por ejemplo, si los pods se ejecutaban en un manifiesto anterior a la versión 2474.0 y tenían habilitada la protección contra eliminación antes de la transición, la función deja de funcionar después de la transición. Si, a continuación, actualiza los pods a una versión de manifiesto 2474.0 o posterior, la función de protección contra eliminación vuelve a funcionar.