Para que pueda realizar el mejor trabajo posible con Horizon Cloud first-gen, tenga en cuenta estas limitaciones conocidas.

Importante: Esta información se aplica únicamente cuando tenga acceso a un entorno de arrendatario de first-gen en el plano de control de first-gen. Como se describe en el artículo 92424 de la base de conocimientos, el plano de control de first-gen ha llegado a la fecha de fin de disponibilidad (EOA). Consulte el artículo para obtener información.

Todos los tipos de implementación

  • Todos los pods asociados con el arrendatario de Horizon Cloud y conectados a Horizon Cloud deben tener una conexión directa con el mismo conjunto de dominios de Active Directory. Si el grupo de pods del arrendatario tiene una combinación de tipos de pod, como los tipos Horizon 8 y Horizon Cloud, además de este requisito de conexión directa, se requiere una confianza unidireccional o bidireccional entre todos los dominios registrados en el mismo arrendatario de Horizon Cloud.
    Nota: Una conexión directa en este contexto significa que un pod determinado debe tener acceso de red a cada dominio para poder acceder a ese dominio para las comprobaciones de estado.
  • El sistema recupera los datos de los informes de Utilización, Simultaneidad, Historial de sesiones y Aplicaciones principales, una vez al día, a una hora UTC específica. Los datos para los informes de Utilización y Simultaneidad se recuperan a las 02:00 UTC, los datos para el informe de Historial de sesiones se recuperan a las 02:10 UTC, y los datos para el informe de Aplicaciones principales se recuperan a las 02:30 UTC. Como resultado, es posible que la información notificada que se muestra en la consola administrativa no refleje los datos recopilados entre la última vez que se ha producido la recuperación y el momento en que se visualizan los informes en la consola. Como ejemplo, debido a que la lógica de los datos de Usuarios y Simultaneidad máxima en el informe de Simultaneidad se calculan en base al día para el que se recuperan los datos, los datos de la actividad del usuario del 23 de abril se calculan a las 02:00 UTC del 24 de abril (el día siguiente). Una vez que ha transcurrido este momento y el sistema recupera los datos recopilados, los datos del 23 de abril se muestran en el informe. Si uno de los usuarios finales inicia una sesión después de las 02:00 UTC del 23 de abril, los datos de la sesión del usuario no se reflejarán en el informe en pantalla hasta después de las 02:00 UTC del 24 de abril.

Implementaciones: pods de Horizon Cloud en Microsoft Azure

Un pod de Horizon Cloud es el tipo que está integrado en la tecnología del administrador de pods de Horizon Cloud.

  • Debido a limitaciones en la forma en que las VNet de Microsoft Azure gestionan las operaciones simultáneas de creación y eliminación de subredes, la ejecución de operaciones simultáneas relacionadas con el pod que requieren la modificación de la misma VNet puede provocar un error al completar dichas operaciones. Para evitar que se produzca este problema, evite ejecutar implementaciones de pods, eliminación de pods u operaciones de edición de pods que incluyan subredes al mismo tiempo cuando esos pods estén utilizando la misma VNet. A continuación se describen algunos ejemplos de operaciones relacionadas con el pod que afectan a la modificación de la VNet, donde se pueden producir acciones de subred simultáneas en la VNet, lo que provoca errores en la realización de las operaciones:
    • Cuando no se crean las subredes por adelantado y se hace que el implementador de pods cree las subredes mediante CIDR, y se inicia la creación de dos pods de forma simultánea en la misma VNet. Se están agregando subredes a la VNet para ambas creaciones del pod de forma simultánea.
    • Cuando se implementa un pod y se inicia la eliminación de otro en la misma VNet. Se agregan subredes a la VNet para el pod de implementación al mismo tiempo que se eliminan subredes del pod de la misma VNet.
    • Cuando se edita un pod para agregar una configuración de puerta de enlace externa en la VNet del pod mediante bloques CIDR mientras otro pod está en proceso de eliminación. Se agregan subredes a la VNet para la configuración de la puerta de enlace al mismo tiempo que se eliminan las subredes del otro pod de la VNet.
  • Actualmente no se admite la ampliación del tamaño de las subredes de un pod una vez implementado. Antes de implementar un pod, debe asegurarse de que los espacios de direcciones de las subredes especificadas en el asistente de implementación sean lo suficientemente grandes para admitir el uso esperado.
    Nota: Como solución alternativa a esta limitación, una nueva función disponible en los pods de la versión de manifiesto 2298.0 o una versión posterior incluye la adición de subredes de arrendatarios para que las granjas y asignaciones de escritorios VDI puedan usarlas después de implementar el pod. Esta función proporciona flexibilidad para agregar subredes de arrendatarios ubicadas en la misma VNet del pod o en una VNet emparejada para que las granjas y máquinas virtuales de escritorio puedan usarlas después de implementar el pod. Para obtener más detalles, consulte la Guía de administración.
  • Varios pods no pueden compartir el mismo nombre de dominio completo que está establecido en sus configuraciones de Unified Access Gateway. Cada pod configurado con instancias de Unified Access Gateway tiene su propio nombre de dominio completo (FQDN) único. El FQDN no puede contener caracteres de subrayado.
    Nota: A partir del 15 de diciembre de 2020, se admite la actualización del plano de nube con FQDN diferentes para y las configuraciones de puerta de enlace interna y puerta de enlace externa del pod. Antes del 15 de diciembre de 2020, el sistema aplica el mismo FQDN para un pod de manifiesto 2298 y versiones posteriores. Ahora el usuario decide si desea que las puertas de enlace del pod utilicen FQDN diferentes o el mismo FQDN. Si desea usar el mismo FQDN en las dos puertas de enlace, tras la implementación del pod, debe configurar un DNS dividido (Sistema de nombres de dominio dividido) para resolver la dirección de la puerta de enlace a la puerta de enlace externa o interna, en función de la red de origen de la consulta de DNS del cliente del usuario final. A continuación, el mismo FQDN utilizado en el cliente del usuario final puede enrutarse a la puerta de enlace externa cuando el cliente se encuentra en Internet, y enrutar a la puerta de enlace interna cuando el cliente se encuentra en la red interna.
  • Actualmente no se admite la edición o actualización de la configuración de proxy en un pod después de implementar el pod en Microsoft Azure. Además, actualmente no se admite agregar una configuración de proxy a un pod implementado sin configuración de proxy.
  • Las capacidades de NSX Cloud de esta versión no se admiten en Microsoft Windows Server 2019.
  • Cuando se implementa un pod de Horizon Cloud on Microsoft Azure después de haber configurado True SSO para pods implementados anteriormente, el sistema no empareja automáticamente el pod nuevo con los servidores de inscripción. Debe repetir los pasos manualmente para exportar el paquete de emparejamiento e importarlo en los servidores de inscripción. Para conocer los pasos, consulte el tema Configurar True SSO para usarlo con el entorno de Horizon Cloud y sus subtemas.
  • En los flujos de trabajo que tienen como resultado la creación de máquinas virtuales, como la creación de granjas, imágenes y asignaciones, si intenta escribir un nombre que sea más largo que la longitud admitida por el sistema para el elemento que va a crearse, el sistema impide que pueda introducir más caracteres que el número admitido. El número de caracteres admitidos para el nombre de un elemento depende del flujo de trabajo.
  • En un entorno de varios pods de Microsoft Azure, no se pueden volver a utilizar los nombres usados en un pod al crear elementos en otro pod. El motivo de esta limitación es que los pods en el entorno de varios pods comparten el mismo dominio de Active Directory y la misma VNet. Como resultado, si los nombres se comparten dentro de esos entornos de varios pods, puede producirse un comportamiento inesperado. Esta limitación se aplica a los nombres de imagen, granjas y las asignaciones de escritorios VDI. Asegúrese de que se utilicen nombres únicos para sus imágenes, granjas y asignaciones de escritorios VDI.
  • Siga estas reglas al introducir caracteres en la consola administrativa:
    • Utilice solo caracteres ASCII estándar en los nombres de usuario y las contraseñas, y para la contraseña al descargar el archivo de arranque DaaS SSL. Si utiliza caracteres distintos a ASCII en estos elementos, es posible que se produzcan resultados no esperados.
    • Al introducir los nombres de granjas, asignaciones e imágenes importadas, y otros activos que deriven en la creación de una máquina virtual de Microsoft Azure, no debe introducir más de 12 caracteres para el nombre.
    • No use comas en contraseñas de usuarios.
    • Al utilizar el asistente Importar máquina virtual para crear una máquina virtual base desde Microsoft Azure Marketplace:
      • Introduzca un nombre de usuario y una contraseña que cumplan con los requisitos de Microsoft Azure para las contraseñas y los nombres de usuario de administrador de máquina virtual. Consulte la página de preguntas más frecuentes de Microsoft Azure para obtener más información.
      • No escriba un nombre para la imagen que termine con un guion (-).
      • No incluya un carácter de subrayado (_) en el nombre de la imagen.

Actualizaciones de pods de Horizon Cloud en Microsoft Azure

  • Durante el proceso de actualización de un pod de un nivel de software anterior al más reciente, las sesiones activas conectadas al nodo en actualización de los usuarios finales se desconectarán. No se producirá pérdida de datos, excepto en el caso en el que la asignación del escritorio VDI o la granja RDSH que presta servicio a las sesiones tenga la opción Cerrar sesión en las sesiones desconectadas configurada como Inmediatamente. Para las asignaciones de escritorios VDI y granjas de este tipo, las sesiones desconectadas también cerrarán la sesión de forma inmediata y se perderá el trabajo de usuario en curso en estas condiciones. Una vez completado el proceso de actualización, esos usuarios pueden volver a conectarse. Por lo general, el proceso de actualización del pod tarda menos de media hora. Sin embargo, algunas actualizaciones de pod pueden tardar más.
  • Cuando los pods que ejecutan manifiestos anteriores al manifiesto 2474 de la versión 2020 se actualizan a 2474 o una versión posterior, si utilizó Microsoft Azure Portal para agregar manualmente etiquetas directamente a los recursos o grupos de recursos creados por Horizon Cloud en la suscripción (como la creación de etiquetas personalizadas en los grupos de recursos de las asignaciones de escritorios VDI o la granja), cuando dichos pods se actualizan, el proceso de actualización del pod no conserva las etiquetas personalizadas que se agregaron directamente mediante el portal de Microsoft Azure. Estas etiquetas personalizadas se eliminarán. Después de actualizar el pod, posteriormente debe usar las funciones de Horizon Universal Console para editar las granjas y las asignaciones de escritorio VDI para que el sistema aplique esas etiquetas en los grupos de recursos para las granjas y las asignaciones de escritorios VDI. La función Etiquetas de recursos de Azure de la consola es el método admitido para agregar etiquetas de recursos a los grupos de recursos creados por el pod para las granjas y las asignaciones de escritorios VDI. En cada uno de los siguientes temas de la documentación, lea las descripciones de los campos de Etiquetas de recursos de Azure ubicados en ellos. Se utilizan los mismos campos al editar una granja o una asignación de escritorios VDI.

Máquinas virtuales importadas, imágenes maestras, granjas o asignaciones de escritorios VDI: pods de Horizon Cloud en Microsoft Azure

  • Aunque la consola no le impide utilizar imágenes obtenidas de orígenes distintos de Azure Marketplace en los flujos de trabajo de la consola, no se admite el uso de dichas imágenes. Para que se admita su uso en Horizon Cloud on Microsoft Azure, todas las imágenes base importadas deben estar creadas a partir de máquinas virtuales basadas en Windows procedentes de Azure Marketplace. Incluso si intenta utilizar una imagen obtenida de otros orígenes y la consola no le impide usarla dentro de los flujos de trabajo de la consola, no se admite el uso de dichas imágenes.

    Asimismo, las imágenes de Windows 11 deben provenir directamente de Azure Marketplace, sin someterse a ningún tipo de procesamiento posterior. Actualmente no se admite la importación de máquinas virtuales de Windows 11 desde ningún otro origen, como Shared Image Gallery (SIG), imágenes administradas de Azure, instantáneas de máquina virtual de Azure o similares.

  • Actualmente, las máquinas virtuales de Azure Gen 2 solo son compatibles con los sistemas operativos Windows 11 de sesión única y Windows 11 Enterprise multisesión.
  • Actualmente, las máquinas virtuales NVv4 habilitadas para GPU de Azure que utilizan controladores de gráficos AMD Radeon Instinct solo se pueden usar si se importan con el método de importación personalizado. El método de importación personalizado también se conoce como importación manual en esta documentación. El asistente Importar máquina virtual - Catálogo de soluciones automatizado no proporciona esta función en este momento.

    El servicio tampoco permite usar actualmente Windows 11 con estas máquinas virtuales NVv4 ni con los controladores de gráficos AMD Radeon Instinct. El uso descrito tiene carácter limitado.

  • La compatibilidad del servicio con Windows 11 presenta ciertas consideraciones, limitaciones y problemas conocidos. Para obtener más información, consulte Compatibilidad con el sistema operativo invitado Windows 11: consideraciones, limitaciones y problemas conocidos .
  • El uso de True SSO con escritorios de sesión, aplicaciones remotas o escritorios VDI basados en imágenes que ejecutan Windows 10 versión 2004, Windows 10 versión 20H2, Windows Server versión 2004 o Windows Server versión 20H2 requiere la instalación de una revisión de Microsoft en dichos sistemas operativos. La revisión soluciona un problema de Microsoft que impide que True SSO se autentique con estos sistemas operativos. Para obtener más información, consulte el artículo de la base de conocimientos (KB) 79644 de VMware que hace referencia a la actualización KB4598291 de Microsoft.
  • El uso de la función de cifrado de disco para granjas y asignaciones de escritorios VDI no se admite actualmente para pods de nubes de Microsoft Azure Government.
  • Actualmente, no se admite el uso de las siguientes funciones de Horizon Agent: el servicio VMware Logon Monitor. De forma predeterminada, Horizon Agents Installer desactiva el servicio de VMware Logon Monitor en todas las instalaciones que realiza el instalador.
  • La capacidad de redireccionamiento USB no se admite cuando se utiliza VMware Horizon Client para Android para acceder a los escritorios virtuales y las aplicaciones remotas a los cuales presta servicio el entorno de Horizon Cloud.
  • Para imágenes maestras que admiten GPU basadas en sistemas operativos de tipo servidor, se recomienda usar Microsoft Windows Server 2016 y 2019 para no limitar el número de sesiones de usuario final. Debido a una limitación del controlador NVIDIA en Windows Server 2012 R2, se admite un máximo de 20 sesiones para cada servidor de escritorio RDS.
  • Si tiene una imagen con Microsoft Windows 10 1709 (RS3) y desea actualizarla a Windows 10 1803 (RS4) o Windows 10 1809 (RS5), actualice primero Windows 10 1709 a la versión más reciente de Horizon Agent (19.4), antes de continuar con la actualización del sistema operativo Windows.
  • De forma predeterminada, cuando se utiliza el asistente Importar máquina virtual - Catálogo de soluciones automatizado para crear una imagen con un sistema operativo Windows Server 2012, la imagen resultante no tiene habilitada la experiencia de escritorio. Si desea que la imagen resultante incluya la experiencia de escritorio, debe habilitarla manualmente.
  • Si se inicia la conversión de un escritorio en una imagen, pero la tarea se cancela antes de que finalice, es posible que se produzca un error en el segundo intento de convertir el escritorio en una imagen. Para evitar este problema, debe apagar el escritorio y encenderlo de nuevo antes de intentar convertirlo en una imagen por segunda vez.
  • En una personalización de redireccionamiento de URL, se distingue entre mayúsculas y minúsculas en los patrones de URL cuando son interceptados por Horizon Client. Por ejemplo, el redireccionamiento de URL no ocurre para los patrones de URL especificados como *GOOGLE.com y *Google.com aunque se redireccione el patrón *google.com. El redireccionamiento para los usuarios finales no se produce si el patrón especificado no coincide con las mayúsculas/minúsculas reales de los caracteres que se utilizan en los sistemas de archivos de destino.

Implementaciones: pods de Horizon

Un pod de Horizon es el tipo que está basado en el software Connection Server de Horizon. Para obtener información general sobre las diversas arquitecturas de implementación utilizadas para pods de Horizon, consulte Arrendatarios de first-gen: arquitecturas de implementación de pods de Horizon con Horizon Cloud first-gen. Para obtener información detallada sobre los distintos servicios del plano de nube, consulte la guía de administración.

Las siguientes limitaciones se aplican en la versión actual y se actualizan según corresponda para cada versión de Horizon Cloud Service.

  • La función de actualización automatizada de Horizon Cloud Connector solo es compatible con los pods de Horizon implementados en las instalaciones. Para actualizar una instancia de Horizon Cloud Connector que esté emparejada con un pod de Horizon implementado en un entorno de nube, siga las instrucciones de Actualizar manualmente el dispositivo virtual de Horizon Cloud Connector.
  • Actualmente, Servicio de administración de imágenes de Horizon (IMS) solo se admite para usarse con un subconjunto de los modelos de implementación de Horizon que se describen en la Arquitectura de referencia de Horizon de la zona tecnológica de VMware. Para obtener información sobre los modelos de implementación específicos compatibles actualmente con IMS, consulte Requisitos del sistema de IMS. A medida que más modelos de la Arquitectura de referencia de Horizon son compatibles con IMS, se agregan a la lista los nuevos modelos admitidos.

Servicios de Workspace ONE Hub y Universal Broker: integración

  • Esta función solo está disponible para la nube de VMware Workspace ONE® Access™. No es compatible con VMware Workspace ONE Access a nivel local.
  • Con esta integración, los usuarios finales pueden acceder a sus aplicaciones y escritorios de Horizon Cloud desde el catálogo de Hub. Asegúrese de configurar los ajustes necesarios para VMware Workspace ONE® Intelligent Hub, como se describe en Workspace ONE Access: Configurar Intelligent Hub para la integración con Horizon Cloud.
  • En esta versión, esta integración admite el acceso de usuarios finales mediante estos clientes: catálogo de Hub basado en navegador, Workspace ONE Intelligent Hub para Windows y Workspace ONE Intelligent Hub para macOS. La versión mínima de las aplicaciones de escritorio de Windows y macOS necesaria para esta compatibilidad es 21.05.
  • El almacenamiento en caché de contraseñas no está activado de forma predeterminada en nuevos arrendatarios de Workspace ONE Access. Si True SSO no está habilitado en su entorno de Horizon, puede habilitar el almacenamiento en caché de contraseñas para almacenar las contraseñas de los usuarios, de modo que no sea necesario que vuelvan a introducir sus contraseñas durante el inicio de los escritorios y las aplicaciones de Horizon Cloud. Para obtener más información, consulte Configurar el almacenamiento en caché de contraseñas para aplicaciones virtuales (solo nube de Workspace ONE Access).
  • Las directivas de acceso establecidas en Workspace ONE Access no se aplican a los escritorios y las aplicaciones desde un entorno de Horizon Cloud que tenga Universal Broker habilitado.
  • No se admite el inicio de varias sesiones de usuario final simultáneas en varios clientes en el mismo endpoint de cliente físico. En otras palabras, los usuarios finales no pueden iniciar más de una sesión por endpoint de cliente físico en varias aplicaciones remotas o escritorios virtuales asignados, independientemente de si se trata de una asignación de escritorios VDI flotantes o dedicados. Por ejemplo, el sistema no puede realizar esta experiencia de usuario final: usar un sistema cliente físico conectado a dos monitores en paralelo y tener dos sesiones de escritorios virtuales independientes que se ejecutan simultáneamente desde ese mismo sistema cliente, y mostrar cada escritorio en un monitor distinto. Esta limitación es propia del sistema, que funciona según lo diseñado.

Horizon Universal Console: advertencias y limitaciones relacionadas

  • La consola no recupera los nombres efectivos actuales de los usuarios y grupos de Active Directory que ya están especificados en los detalles de una asignación. Cuando se cambia el nombre de un usuario o grupo en Active Directory, la consola sigue mostrando el nombre anterior del usuario o del grupo en los detalles de la asignación desde el momento en que ese usuario o ese grupo se agregaron inicialmente a la asignación. Al editar una asignación y buscar un usuario o un grupo en el campo de búsqueda, los nombres efectivos actuales de los usuarios o grupos se muestran en la consola. Sin embargo, incluso después de guardar la asignación actualizada, seguirá viendo el nombre inicial anterior en los detalles de la asignación. Esta limitación no tiene ningún impacto funcional.
  • La consola administrativa basada en web no se admiten en el navegador Apple Safari. Es posible que algunas funciones de la interfaz de usuario no funcionen correctamente. En Mac OS, como alternativa a Apple Safari, se pueden usar los navegadores Chrome o Firefox.
  • Su sesión autenticada (con sesión iniciada) en la consola agotará el tiempo de espera una vez transcurrido el ajuste de tiempo que esté configurado en la página Configuración general de la consola. El valor predeterminado es 30 minutos. Si tiene al menos un pod conectado a la nube, puede cambiar el valor predeterminado a uno entre 30 y 180 minutos. En la mayoría de los casos, cuando se llegue a la hora configurada, el sistema cerrará sesión de forma explícita automáticamente y le presentará un mensaje informándole que debe volver a iniciar sesión. Sin embargo, en ocasiones, el sistema finaliza la sesión autenticada y no cierra sesión de forma explícita. Cuando esto ocurre, al realizar ciertas tareas en la consola, es posible que se muestren mensajes de error que no reflejen el estado actual de un modo preciso, como cuando el asistente de implementación de nodos no puede validar las entradas de suscripción y los valores no se muestran en los menús desplegables, y cuando la página Granjas informa de que no hay ningún nodo disponible para crear una granja y aparecen mensajes de error que indican "No se han proporcionado service_sessions de tipo identity_node". Si detecta este comportamiento y ha utilizado la consola durante treinta minutos o más, cierre la sesión manualmente y, a continuación, vuelva a iniciarla.