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 Limitaciones conocidas de Universal Broker.

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 grupo 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 podría tener un máximo 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 9 caracteres.

Como resultado, todos los prefijos de nombres de máquina virtual que antes tenían más de 9 caracteres se truncan automáticamente después de la transición.

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.

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.
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.