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

En este tema se presenta el proceso de transición del 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 brokering 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 permanecen sin cambios. Una asignación de aplicaciones o escritorios basados en sesiones puede incluir recursos de un solo pod, pero el brokering de la asignación ahora lo realiza 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 al uso de Universal Broker, 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, lo que también se conoce como 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 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 hacerlo 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 las opciones 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 SDDC basada en vSphere, 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 conoce el estado de disponibilidad de cada pod. Como resultado, Universal Broker puede administrar las solicitudes de conexión de los usuarios finales y enrutarlas a los recursos virtuales directamente desde estos pods. No es necesario el equilibrio de carga del servidor global (GSLB) ni ninguna comunicación de red entre pods que pueda provocar problemas de reducción de rendimiento y latencia.

• Gestión de agente inteligente

Universal Broker puede realizar brokering de recursos de las asignaciones a los usuarios finales a lo largo de 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 su 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 al Universal Broker).

A continuación se ofrece una descripción general de alto nivel 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 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. Además, asegúrese de que todos los pods de Microsoft Azure estén en línea y en un estado correcto y listo.
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, se puede esperar lo siguiente:

• No puede 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 será realizado por 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 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 proporciona una breve visión de lo que se debe hacer a continuación y vínculos a páginas detalladas.

• 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 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 en un entorno de Universal Broker.
• Si ya existe una integración entre el arrendatario de Horizon Cloud y Omnissa Access, debe actualizar la integración para permitir el uso de Universal Broker. Para obtener instrucciones completas, consulte Entorno de Horizon Cloud con Universal Broker: integrar el arrendatario con los servicios de Omnissa Access e Intelligent Hub.

Nota: Como confirmó el equipo de producto de Access, cuando se utiliza Universal Broker con las implementaciones de Horizon Cloud on Microsoft Azure, la función de colecciones de aplicaciones virtuales del producto de Access no es compatible con esa configuración. La razón es que Universal Broker es la tecnología de brokering más moderna que el antiguo brokering por pod, lo que significa que la integración de Universal Broker con Access 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, lo que hace que el uso de colecciones de aplicaciones virtuales con las configuraciones de Universal Broker y Horizon Cloud on Microsoft Azure no sea compatible.

Cuando Universal Broker está configurado para las implementaciones de Horizon Cloud on Microsoft Azure y tiene pensado utilizar los servicios de Access e Intelligent Hub con dichas implementaciones de Horizon Cloud on Microsoft Azure, en el proceso de integración como parte de la acción Limpiar de la consola, se le pedirá que limpie 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 Access e Intelligent Hub utilizando las funciones modernas de los servicios integrados Universal Broker y 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 del uso del brokering de pod único a Universal Broker. También lo guiará por los pasos de planificación y preparación para admitir el nuevo FQDN de conexión para 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 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 usan 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 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 de Horizon Cloud), cada pod deberá tener una instancia externa de Unified Access Gateway con autenticación en dos fases RADIUS configurada.

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 de, 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 ciertos casos prácticos.

• Si existe una integración entre el arrendatario de Horizon Cloud y 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 admitir el uso de Universal Broker, como se describe en Entorno de Horizon Cloud con Universal Broker: integrar el arrendatario con los servicios de Access e Intelligent Hub.

• 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, en buen estado y listos. El servicio Universal Broker debe comunicarse con esos 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 se 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 la ubicación del pod se configuró 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 este escenario en el que 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 la 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 planifique la configuración de la autenticación en dos fases en los ajustes de Universal Broker, cada pod debe tener una instancia externa de Unified Access Gateway 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 externas de Unified Access Gateway 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 de Horizon Cloud), debe configurar todas las instancias externas de Unified Access Gateway 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 reemplaza 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 manera tal que los nombres DNS necesarios 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 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.

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, conectándose 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 de Universal Broker en las opciones de configuración de Universal Broker, como se describe en Programación y Completar la transición de un agente de pod único a un Universal Broker. Para crear el FQDN, puede prefijar su subdominio válido al dominio estándar proporcionado por el sistema, 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 puede proporcionar un certificado que valide ese dominio y que tiene 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 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 conocer 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	En la etapa de configuración del proceso de programación de la transición, designe el FQDN existente del pod como FQDN personalizado para el servicio 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 las 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 se deben seguir antes, durante y después del proceso de transición. En la etapa de configuración del proceso de programación de la transición, configure el nuevo FQDN para el servicio 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 para la formación del usuario y la reconfiguración del software cliente, de acuerdo con la escala de las implementaciones del pod. Notifique y prepare a los usuarios finales para la próxima transición. Recuérdeles que deben guardar su trabajo y cerrar las 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 del 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 al 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 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.

Cuando la transición del agente está lista para programarse, aparece un banner de notificación con un botón Programar en la parte superior de Horizon Universal Console.

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

Compruebe que el entorno de arrendatario cumpla con todos los requisitos previos descritos 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 .

Aparece el asistente de configuración para Universal Broker. Debe completar los pasos de este asistente para configurar Universal Broker para los pods de Microsoft Azure y programar la transición a Universal Broker.

3. En la página FQDN del asistente, configure los ajustes del FQDN de conexión de brokering. Esta configuración define la dirección de la conexión dedicada que utilizan 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 Proporcionado por Omnissa o Nombre de dominio completo (FQDN) personalizado .

2. Especifique la configuración adicional para el tipo de FQDN seleccionado.

• Si seleccionó el tipo Omnissa Proporcionado , especifique la configuración de la siguiente manera.

Ajuste	Descripción
Subdominio	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 el sistema 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 libro, términos conocidos propiedad de la empresa como gmail y protocolo, codificación y términos de 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 haya escrito 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.firstgen.omnissahorizon.com. Proporcione este FQDN a los usuarios finales para permitir que se conecten al servicio Universal Broker mediante Horizon Client. Universal Broker administra la validación de DNS y SSL de este FQDN.

• Si seleccionó el tipo Personalizado , especifique la configuración de la siguiente manera.

Ajuste	Descripción
Brokering FQDN	Introduzca el FQDN personalizado que utilizarán los usuarios finales para acceder al servicio Universal Broker. El FQDN personalizado funciona como un alias para el FQDN proporcionado por el sistema generado automáticamente que completa la conexión con el 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 el sistema que representa la dirección de conexión interna del servicio Universal Broker. Por ejemplo, el registro puede asignar vdi.examplecompany.com a string.firstgen.omnissahorizon.com generadas automáticamente.
Certificados	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 CA 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: certificado de dominio, certificados intermedios, certificado de CA raíz y clave privada. El servicio Universal Broker utiliza este certificado para establecer sesiones de conexión de confianza con los clientes.
Contraseña	Introduzca la contraseña para el archivo de certificado PFX.
FQDN proporcionado por Omnissa	Este campo de solo lectura muestra el FQDN proporcionado por el sistema que se genera automáticamente para el servicio de brokering. El FQDN adopta el formato https://auto-generated-string.firstgen.omnissahorizon.com. Este FQDN proporcionado por el sistema no es visible para los usuarios finales y representa la dirección de conexión interna del servicio Universal Broker. El FQDN personalizado funciona como un alias para este FQDN proporcionado por el sistema. 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 el sistema. Por ejemplo, el registro puede asignar vdi.examplecompany.com a auto-generated-string.firstgen.omnissahorizon.com .

3. Una vez configurados los ajustes de 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. 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 al implementar una autenticación en dos fases en un entorno de Universal Broker.

Importante: Para utilizar la autenticación en dos fases para Universal Broker, primero debe configurar el servicio de autenticación adecuado en cada instancia externa de Unified Access Gateway dentro de 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 cada instancia externa de Unified Access Gateway en todos los pods de Horizon y Microsoft Azure participantes.

No elimine ninguna instancia de Unified Access Gateway dentro de los pods participantes. Dado que Universal Broker depende de 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.

Ajuste	Descripción
Autenticación de dos factores	Para utilizar la autenticación en dos fases, habilite esta opción. Cuando se habilita la opción, se presentan opciones adicionales para configurar la autenticación en dos fases.
Mantener nombre de usuario	Habilite esta opción para mantener el nombre de usuario de Active Directory del usuario durante la autenticación en Universal Broker. Cuando se habilita: El usuario debe tener las mismas credenciales de nombre de usuario para el método de autenticación adicional que para su autenticación de Active Directory en Universal Broker. 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.
Tipo	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 RADIUS aquí, las solicitudes de autenticación de 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 está seleccionado aquí, las solicitudes de autenticación 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 de pods de Horizon o de Horizon Cloud. Si las implementaciones de Horizon Cloud on Microsoft Azure tienen configurado el tipo RSA SecurID, las solicitudes de autenticación RSA de los usuarios se intentan a través de instancias de Unified Access Gateway de ambos tipos de pod.
Mostrar texto de sugerencia	Habilite esta opción para configurar una cadena de texto que se muestre en la pantalla de inicio de sesión del cliente para ayudar a solicitar al usuario sus credenciales para el método de autenticación adicional.
Texto de sugerencia personalizado	Introduzca la cadena de texto que desea mostrar en la pantalla de inicio de sesión del cliente. La sugerencia especificada se muestra al usuario final como Introduzca su nombre de usuario y contraseña de DisplayHint, donde DisplayHint es la cadena de texto que introduce en este 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 de 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: Introduzca el nombre de usuario de su empresa y la contraseña de dominio a continuación para nombre de usuario y contraseña.
Omitir autenticación en dos fases	Habilite esta opción para omitir la autenticación en dos fases para los usuarios de red interna que se conectan al servicio Universal Broker. Asegúrese de haber especificado los rangos de IP públicas pertenecientes a la red interna, 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 Universal Broker. Los usuarios externos deben introducir sus 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.
Rangos de IP públicas	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 un usuario interno a todo usuario que se conecte desde una dirección IP dentro de uno de estos rangos. Para obtener más información sobre el propósito 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, establezca 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.

Ajuste	Descripción
Intervalo de latidos de Client	Controla el intervalo, en minutos, entre los latidos de Horizon Client y el estado de conexión del usuario a Universal Broker. Estos latidos notifican a Universal Broker cuánto tiempo de inactividad ha 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 subyacente 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.
Usuario en espera de Client	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, el usuario debe volver a introducir sus credenciales de autenticación en la pantalla de inicio de sesión de Universal Broker. Nota: Para evitar desconectar a los 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 que el Intervalo de latidos de Client.
Sesión de agente de cliente	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 empieza cuando el usuario se autentica en Universal Broker. Cuando se agota el tiempo de espera de la sesión, el usuario puede seguir trabajando en el escritorio asignado. Sin embargo, si realizan una acción (como cambiar la configuración) que requiera comunicación con Universal Broker, Horizon Client les solicitará 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 de Intervalo de latidos de Client y el tiempo de espera del usuario en espera de Client.
Tiempo de espera de la caché de las credenciales del cliente	Controla si se almacenan 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 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 coincidir con la hora inicial.

Al establecer la hora de inicio, deje tiempo suficiente para que la transición continúe sin interrupciones.

Cuando haya terminado, haga clic en Siguiente para continuar con el siguiente paso 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 los ajustes 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, a continuación, haga clic en Finalizar para guardar la configuración de Universal Broker y los ajustes de programación.

Aparece 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 falta más de una hora para la hora de inicio, puede volver a programar la transición haciendo clic en el vínculo Programar .
• 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 de Horizon Cloud. Tenga en cuenta que el soporte de Horizon Cloud 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 y listo mientras dure la transición. El servicio Universal Broker debe comunicarse con los pods y realizar algunos pasos de configuración en los pods para completar la etapa 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 SDDC basada en vSphere, el servicio Universal Broker no estará disponible para los pods de Horizon mientras dure 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 puede 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 realiza 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 Horizon Cloud 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 Horizon Cloud corrija la causa del error, puede utilizar 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 Universal Broker complete su proceso de configuración y se habilite por completo.

Por lo general, las opciones de configuración tardan hasta 30 minutos en surtir efecto en el servicio 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 Universal Broker no está disponible durante este tiempo para el brokering de asignaciones.

Cuando la configuración se completa 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 verde.

Universal Broker ahora realiza el brokering de sus asignaciones y se completa la transición.

Importante: Si se produce un error en la configuración de 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 Universal Broker, abra una solicitud de soporte, tal como se describe en el artículo 2006985 de la base de conocimientos.

¿Qué hacer a continuación?

• Si ya existe una integración entre el arrendatario de Horizon Cloud y Access, debe actualizar la integración para permitir el uso de Universal Broker. Para obtener instrucciones completas, consulte Entorno de Horizon Cloud con Universal Broker: integrar el arrendatario con los servicios de Access e Intelligent Hub.
• 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 las asignaciones. Para obtener información detallada, consulte Crear y administrar asignaciones 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 completar correctamente la transición de agente de pod único a Universal Broker. Los cambios incluyen un nuevo comportamiento de las funciones y algunas limitaciones de las mismas.

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

Cambios en las asignaciones de usuarios finales

• 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 utilizar 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 se puedan agregar grupos de escritorios con nombre exclusivo de diferentes pods a una sola 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 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 máquina virtual y el nombre de grupo, realice una actualización de la asignación en transición mediante el asistente Editar.

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 manifiestos anteriores a la versión 2474.0. Para usar esta función, debe actualizar los pods al manifiesto 2474.0 o una versión posterior.
• Si las implementaciones de Horizon Cloud on Microsoft Azure tienen una integración previa a la transición con 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 Omnissa Access e Intelligent Hub.

Tenga en cuenta que, cuando actualice esa integración, se le pedirá que utilice el flujo de trabajo Limpieza de Horizon Universal Console para limpiar las colecciones de aplicaciones virtuales existentes que puedan tener esas implementaciones. El flujo de trabajo de limpieza hará que las mismas aplicaciones sigan funcionando en los servicios de Access e Intelligent Hub mediante el uso de las funciones modernas de Universal Broker integrado y los servicios de Access e Intelligent Hub en lugar de la función heredada Colecciones de aplicaciones virtuales por pod. Como confirmó el equipo de producto de Access, cuando se utiliza Universal Broker con las implementaciones de Horizon Cloud on Microsoft Azure, la función de colecciones de aplicaciones virtuales del producto de Access no es compatible con esa configuración. La razón es que Universal Broker es la tecnología de brokering más moderna que el antiguo brokering por pod, lo que significa que la integración de Universal Broker con Access reemplaza el uso de las colecciones de aplicaciones virtuales por pod heredadas. Por lo tanto, Universal Broker no tiene ningún concepto de colecciones de aplicaciones virtuales para 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 al manifiesto 2474.0 o una versión 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 al manifiesto 2474.0 o una versión posterior, la función de protección contra eliminación vuelve a funcionar.