En este tema se enumeran los problemas conocidos que se pueden encontrar al utilizar el servicio y las soluciones alternativas conocidas, si existen.

En este tema de la documentación se incluyen los problemas conocidos de Horizon Cloud Connector. Sin embargo, aunque utilice Horizon Cloud Connector para conectar pods de Horizon a Horizon Cloud, los problemas conocidos de software que se ejecutan dentro de los pods de Horizon se proporcionan en otro lugar. Los problemas conocidos de las versiones de software de los pods de Horizon se encuentran en las Notas de la versión del propio producto de software. Los documentos de la versión 7.x del software de Horizon están vinculados desde la página de documentación de VMware Horizon 7. Los documentos de la versión de 2006 del software de Horizon se vinculan desde esta página de documentación de VMware Horizon (a veces referida como Horizon 8, además de Horizon 2006).

Para ver los problemas conocidos de cualquier servicio de administración de imágenes (IMS), consulte la página de problemas conocidos de Administrar imágenes de Horizon desde la nube.

Nota: Los números entre paréntesis que se especifican en cada problema conocido hacen referencia a los sistemas de seguimiento de problemas internos de VMware.

Problemas conocidos relacionados con el inicio de sesión

Aunque haya creado correctamente una contraseña para la cuenta de My VMware que contiene una barra diagonal inversa (\), se produce un error al iniciar sesión en Horizon Cloud con las credenciales (2595757)
Cuando se utilizan credenciales de My VMware para iniciar sesión en Horizon Cloud, no se admiten las contraseñas que contienen una barra diagonal inversa. Para ver la lista de caracteres especiales compatibles, inicie sesión en my.vmware.com y desplácese hasta la sección Cambiar contraseña del perfil. La página mostrará los caracteres especiales compatibles. Solución alternativa: Restablezca la contraseña de la cuenta de My VMware a una nueva y asegúrese de que la nueva no contenga una barra diagonal inversa (\).

Problemas conocidos relacionados con Active Directory

El bloqueo de cuenta de enlace principal no se detecta hasta que se realiza una acción que involucra a Active Directory en la consola administrativa. (2010669)
Debido a este problema, un administrador que haya iniciado sesión en la consola administrativa basada en web no verá ninguna notificación de bloqueo de cuenta de enlace principal hasta que se realice una acción que involucre a Active Directory en la interfaz de usuario, como cuando se busca en Active Directory para agregar usuarios a las asignaciones. Los servicios subyacentes solo detectan una cuenta de servicio bloqueada cuando se realiza una solicitud para comunicarse con Active Directory a fin de autenticarse o buscar (usuarios o grupos). Solución alternativa: ninguna.
La consola administrativa basada en web tarda hasta 15 minutos en reflejar un estado de bloqueo o desbloqueo de la cuenta de dominio de enlace principal. (2009434)
El objeto de conexión del sistema con Active Directory se almacena en caché durante 15 minutos. Como resultado, podrían pasar hasta 15 minutos desde el momento en el que la cuenta de enlace principal pasa al estado de bloqueo y el sistema emite la notificación al administrador. Por otro lado, después de que el administrador borre la condición de bloqueo de la cuenta, pueden pasar hasta 15 minutos hasta que el sistema detenga las notificaciones acerca de la cuenta borrada. Solución alternativa: ninguna.
Para las granjas de un pod de Microsoft Azure, la reutilización del mismo nombre de granja con un dominio diferente en el mismo bosque de Active Directory puede producir errores de unión al dominio debido a la duplicación de nombres de proveedor de servicio (SPN). (1969172)
Debido a una nueva función para controladores de dominio en Microsoft Windows Server 2012 R2 y versiones posteriores, una comprobación de SPN duplicados en el controlador de dominio provoca errores de unión al dominio. Consulte el artículo de la base de conocimientos (KB) de Microsoft 3070083. Soluciones alternativas:
  • Evite reutilizar nombres de granja.
  • Como se describe en el artículo de Knowledge Base de Microsoft, desactive las comprobaciones de SPN duplicados en el dominio de Active Directory.
Al utilizar Azure AD Domain Services, falla el flujo de trabajo de registro de Active Directory en el paso de unión al dominio, con un error de falta de permiso para restablecer la contraseña. (2218180)
El equipo de Horizon Cloud ha verificado que la adición de los permisos de cuenta de unión al dominio requeridos funciona igual cuando se utiliza Azure Active Directory (AD) Domain Services con el pod que con otras implementaciones de dominio de Active Directory. Consulte el tema de la documentación de Microsoft Creación de una unidad organizativa en un dominio administrado de Azure AD Domain Services, que describe los equipos AADDC de contenedor integrados, y consulte también la nota importante al principio de ese tema sobre cómo habilitar la sincronización de hash de contraseña en Azure AD Domain Services. Antes de configurar los permisos en la cuenta de servicio de unión al dominio, es importante que siga la documentación de Microsoft sobre cómo habilitar la sincronización de hash de contraseña en Azure AD Domain Services para las cuentas de servicio de unión al dominio. Si sigue experimentando un error de unión al dominio en el flujo de trabajo de registro de Active Directory después de seguir la documentación de Microsoft, póngase en contacto con el soporte de VMware y haga referencia al número de informe de problemas 2218180.

Problemas conocidos relacionados con Cloud Connector

La configuración de host sin proxy especificada en el campo Sin proxy durante la implementación de la plantilla de OVF no se guarda en el dispositivo implementado (2454245, 2466306, 2467017, DPM-5388)
Este problema se ha resuelto en Horizon Cloud Connector versión 1.6 o versiones posteriores. Al ejecutar el flujo de trabajo Implementar plantilla de OVF en el entorno de vSphere, tiene la opción de especificar una configuración de host sin proxy en el campo Sin proxy para. Sin embargo, debido a este problema conocido, los ajustes introducidos no se capturan en los archivos de configuración del dispositivo implementado. Como resultado, el dispositivo implementado no respeta la configuración de host sin proxy especificada.

Problemas conocidos relacionados con Universal Broker

El cliente de Universal Broker de Horizon en Horizon Cloud Connector no consume las actualizaciones relacionadas con el proxy que se realizan en el dispositivo conector después de implementar el dispositivo por primera vez (HD-35551)
Este problema se ha resuelto en Horizon Cloud Connector versión 1.6 o versiones posteriores. El cliente de Universal Broker de Horizon en el dispositivo conector recopila los detalles de proxy durante el primer arranque del dispositivo. Debido a que el primer arranque se ejecuta solo la primera vez que se enciende el dispositivo después de implementar la plantilla de OVF, el cliente de Universal Broker de Horizon no consumirá los cambios que se realicen posteriormente en la configuración de proxy del dispositivo. Como resultado de este problema conocido y del problema conocido anterior sobre la configuración sin proxy durante la implementación de la plantilla de OVF, los hosts relacionados con el Universal Broker de Horizon no podrán establecerse como hosts sin proxy.

Problemas conocidos relacionados con imágenes, granjas y asignaciones

Los problemas conocidos que se indican aquí se aplican a los pods que se implementan en Microsoft Azure.

En los pods implementados en las suscripciones de nube de Microsoft Azure Government, se produce un error al utilizar la función de cifrado de disco en granjas y asignaciones de escritorios. (2572579)
Cuando el pod se encuentra en las nubes de Microsoft Azure Government e intenta crear una granja o una asignación de VDI con la función de cifrado de disco seleccionada, se produce el siguiente error en el proceso de creación: Azure error encrypting the VM. Solución alternativa: ninguna.
En la pestaña Servidores de una granja existente, todas las opciones del modo de inicio de sesión del usuario dan un mensaje de error que indica que Horizon Agent debe actualizarse. (2528295)
El uso de la consola administrativa para establecer el modo de inicio de sesión del usuario depende de la detección de la versión 20.1.0 del agente que se ejecuta en la máquina virtual de la granja. Sin embargo, esa versión del agente todavía puede no estar disponible en el plano de control de nube para utilizarla de cara a actualizar los agentes en las máquinas virtuales existentes de la granja. Solución alternativa: ninguna. Cuando la versión 20.1.0 del agente está disponible en el plano de nube y los pods se actualizan a la versión del manifiesto que puede consumir esa versión del agente, puede actualizar las máquinas virtuales de granja a ese agente para que usen las opciones del modo de inicio de sesión del usuario.
En algunas ocasiones, algunas máquinas virtuales de escritorio de una gran asignación de escritorios VDI flotantes informan de un estado de agente desconocido. (DPM-3201)
En las asignaciones de escritorios VDI flotantes con gran cantidad de máquinas virtuales de escritorio, debido a un problema conocido, una pequeña cantidad de esas máquinas virtuales de escritorio pueden entrar en un estado de agente desconocido, ya que algunos servicios de Windows, como el servicio Blast de Horizon Agent o el servicio de Microsoft Azure, no se inician o tardan en iniciarse. Como resultado, en la consola administrativa, la columna Estado del agente de esas máquinas virtuales de escritorio muestra el estado "Desconocido", con los errores de agente informados. Solución alternativa: En la consola administrativa, utilice la acción Reiniciar para reiniciar esas máquinas virtuales.
El asistente Importar máquina virtual - Catálogo de soluciones crea imágenes de Windows Server 2012 sin la experiencia de escritorio habilitada. (2101856)
Debido a un problema conocido, cuando se utiliza el asistente automatizado Importar máquina virtual - Catálogo de soluciones para crear una imagen con un sistema operativo Windows Server 2012, la imagen resultante no tiene habilitada la experiencia de escritorio. Solución alternativa: Si desea que la imagen resultante incluya la experiencia de escritorio, debe habilitarla manualmente. Tenga en cuenta también que el sistema operativo Windows Server 2012, para instalar Horizon Agent con la opción de redireccionamiento del escáner, requiere que la experiencia de escritorio esté habilitada en el sistema operativo.
Cuando se publica (proceso también conocido como sellado) una máquina virtual importada, el proceso puede provocar un tiempo de espera u otros errores de publicación debido a fallos de sysprep. (2036082, 2080101, 2120508, 2118047)
Después de hacer clic en Convertir a escritorio en una máquina virtual importada y en Publicar para que resulte una imagen publicada (sellada), se realizan varias operaciones en la máquina virtual. Estas operaciones incluyen ejecutar el proceso de preparación del sistema Windows (sysprep), apagar la máquina virtual y desconectarla, entre otras. Debido a problemas conocidos en el sector relacionados con el proceso sysprep de Windows y la personalización de máquinas virtuales, en ocasiones el proceso de publicación falla por distintos motivos. En la página Actividad, puede ver mensajes como "Timeout Error Waited 20 minutes for virtual machine to power off" (Error de tiempo de espera agotado. Se han esperado 20 minutos a que se apague la máquina virtual) y otro mensaje de error de sysprep.

Por lo general, puede evitar que se produzcan estos problemas de sysprep al crear la máquina virtual si utiliza el asistente Importar máquina virtual - Catálogo de soluciones y seleccionar en la opción Optimizar imagen de Windows del asistente. Si observa este error para una máquina virtual importada en la que no se utiliza esta opción, o si ha creado manualmente la máquina virtual, consulte el artículo de la base de conocimientos (KB) 2079196 de VMware, el artículo de la base de conocimientos (KB) 2769827 de Microsoft, el artículo 615 de Microsoft MVP sobre las prácticas recomendadas para configurar la máquina virtual de imagen de cara a minimizar la probabilidad de que haya problemas de sysprep cuando vaya a publicar la imagen. Si sigue teniendo problemas de sysprep, consulte la información de los artículos Elegir optimizar la imagen de Windows al utilizar el asistente Importar máquina virtual - Catálogo de soluciones y Uso de la opción para eliminar las aplicaciones de la Tienda Windows al utilizar el asistente de importación de escritorios para ver las distintas alternativas que el asistente automatizado Importar máquina virtual - Catálogo de soluciones sigue para reducir los cambios de los problemas de sysprep. Si ve los errores de tiempo de espera en la página Actividad, puede intentar esta solución alternativa: en la página Imágenes, utilice la acción Convertir la imagen en escritorio sobre la imagen. Cuando la página Actividad indique que la conversión de imagen en escritorio es correcta, vaya a la página Máquinas virtuales importadas. Conéctese a la máquina virtual y aplique las prácticas recomendadas descritas en los artículos de la base de conocimientos (KB). Después de ver que la página Máquinas virtuales importadas notifica que la máquina virtual está encendida, seleccione la máquina virtual y haga clic en Convertir en imagen para volver a ejecutar el proceso de publicación.

En ocasiones, durante la creación de una granja, las máquinas virtuales del servidor se bloquean en el paso de personalización. (2010914, 2041909)
En ocasiones, durante el proceso de sysprep en las máquinas virtuales del servidor de la granja, un servicio de Windows llamado tiledatamodelsvc impide que sysprep acceda a los archivos de Windows que necesita para completar el proceso de personalización de sysprep. Como resultado, las máquinas virtuales del servidor de la granja no avanzan más allá del paso de personalización. El registro de errores de sysprep contiene la línea "Error SYSPRP setupdigetclassdevs generó el error 0". Solución alternativa: Si detecta este problema y ve ese mensaje de error en el archivo de registro de errores de sysprep, intente deshabilitar el servicio tiledatamodelsvc en la imagen y, a continuación, cree la granja.
El estado del agente se puede mostrar como "No definido" en la página Máquinas virtuales importadas después de duplicar una imagen o crear manualmente una imagen en Microsoft Azure. (2002798)
Cuando se utiliza el botón Duplicar en la página Imágenes para clonar una imagen publicada, o cuando se crea manualmente una máquina virtual de imagen en Microsoft Azure, la máquina virtual resultante aparece en la página Máquinas virtuales importadas. Debido a este problema, aunque la máquina virtual esté completamente encendida, es posible que el estado del agente aparezca como "No definido". Sin embargo, cuando se seleccione la máquina virtual y se elija Convertir en imagen para publicarla, la interfaz de usuario mostrará el agente con el estado "Activo". Solución alternativa: ninguna. Si los flujos de trabajo Restablecer emparejamiento de agente, Nueva imagen o Convertir en imagen muestran el agente como "Activo", puede ignorar el estado "No definido" en la página Máquinas virtuales importadas.

Problemas conocidos relacionados con App Volumes en los pods de Microsoft Azure

Los problemas conocidos que se indican aquí se aplican a los pods que se implementan en Microsoft Azure.

Cuando el entorno tiene varios pods en Microsoft Azure, el proceso de captura a veces puede pasar a un estado desconocido tras completarse. (2600573)
Cuando el entorno tiene varios pods con los que se utiliza App Volumes, a veces, después de ejecutar el proceso de captura, la consola indica que la captura se encuentra en un estado desconocido, aunque se haya completado el proceso de captura en la máquina virtual. Para solucionar este problema, vuelva a importar el paquete de la aplicación con Inventario > Aplicaciones > Nueva > Importar. Como resultado, el paquete de la aplicación se importa correctamente como una aplicación independiente y el inicio de la aplicación y la asignación posteriores funciona.

Problemas conocidos relacionados con la actualización del agente

Los problemas conocidos que se indican aquí se aplican a los pods que se implementan en Microsoft Azure.

Al intentar una actualización del agente en una imagen que tiene pendiente una actualización de Windows, el proceso de actualización puede fallar. (2234964)
Si la imagen necesita una actualización en el sistema operativo Windows, en lugar de una actualización secundaria que no sea de sistema operativo, esto puede hacer que algunos recursos del sistema operativo queden sin conexión y no estén disponibles para la actualización del agente. Solución alternativa: Espere hasta que finalice la actualización de Windows e intente actualizar el agente de nuevo. Para confirmar que todas las actualizaciones de Windows están completas, puede capturar la imagen sin conexión, realizar todas las actualizaciones pendientes y volver a publicar la imagen antes de iniciar la actualización del agente.

Problemas conocidos relacionados con los informes y la supervisión

Los problemas conocidos que se indican aquí se aplican a los pods que se implementan en Microsoft Azure.

En el informe de actividad del usuario, la media semanal (horas) mostrada no es intuitiva. (1817065)
Debido a este problema, las estadísticas semanales fluctúan con el tiempo debido a que la lógica de cálculo está dividiendo la duración de la semana actual por siete (7) y no la redondea a una semana completa. Por ejemplo, cuando se seleccionan los últimos 30 días, los datos para las semanas completadas no cambian, pero los datos de la semana actual se dividen por siete (7). La lógica actual es media semanal (horas) = promedio diario (horas) * 7 días, lo que da como resultado media semanal de los últimos 30 días = (duración total / 30 días) * 7 días. Solución alternativa: ninguna
El informe de estado del escritorio no refleja un nombre de granja o de asignación de escritorios VDI actualizado recientemente hasta una hora después del cambio de nombre. (1756889)
Si cambia el nombre de una granja o de una asignación de escritorios VDI, transcurre una hora hasta que se refleja el nuevo nombre en el menú desplegable Asignación y la columna Asignación del informe de estado del escritorio. Solución alternativa: Espere una hora antes de empezar a comprobar que el nuevo nombre aparece en el informe.
El formato de algunos de los archivos CSV que puede exportar desde las pantallas de la interfaz de usuario Informes no coincide con las tablas que aparecen en pantalla. (2015500)
Algunas de las sub-pantallas de la página Informes proporcionan una función de exportación para exportar los datos mostrados en formato CSV. Debido a este problema, el formato de los archivos CSV exportados desde los informes Estado del escritorio, Simultaneidad e Historial de sesiones no coincide exactamente con el formato que puede ver que se muestra en la pantalla. Por ejemplo, los encabezados de columna podrían ser diferentes y los archivos CSV pueden tener más columnas de datos que en las tablas que aparecen en pantalla. Solución alternativa: ninguna.

Problemas conocidos relacionados con la administración de identidades, Workspace ONE Access y True SSO

Los problemas conocidos que se indican aquí se aplican a los pods que se implementan en Microsoft Azure.

Cuando un pod de versiones de manifiesto anteriores a la 1763 se actualiza al manifiesto 1763 o una versión posterior, y el pod tiene RADIUS de dos factores configurado en sus instancias de Unified Access Gateway y también está integrado con Workspace ONE Access, verá que al iniciar un escritorio desde Workspace ONE Access mediante el navegador se mostrará el formulario de inicio de sesión de RADIUS con el campo de nombre de usuario rellenado previamente con el UPN del usuario. (2248160)
Este síntoma se produce debido a un cambio publicado en VMware Horizon HTML Access 4.10. Cuando el pod de Microsoft Azure de una versión anterior de Horizon Cloud está configurado con instancias de Unified Access Gateway y autenticación de RADIUS de dos factores y se configura el pod para que use Workspace ONE Access, anteriormente cuando se inicia un escritorio desde Workspace ONE Access mediante el navegador, el formulario de inicio de sesión de RADIUS solicita el nombre de usuario y el código de acceso. El usuario final debía escribir el nombre de usuario y el código de acceso en el formulario. Sin embargo, debido a este problema, después de actualizar ese pod a esta versión y utilizando los mismos pasos de inicio de escritorio, el formulario de inicio de sesión RADIUS tiene el campo de nombre de usuario relleno previamente con el UPN del usuario de dominio. Esto solo ocurre cuando se utiliza el navegador para iniciar el escritorio. No pasa cuando se usa Horizon Client. Solución alternativa: Si se produce esta situación, el usuario final puede borrar el campo de nombre de usuario relleno previamente e introducir su información. Por lo general, para la mayoría de entornos que están integrados con Workspace ONE Access, la autenticación en dos fases se configurará en Workspace ONE Access y no en las instancias subyacentes de Unified Access Gateway, en cuyo caso este problema no se producirá.
Es posible que se produzca un error al iniciar un segundo escritorio desde Workspace ONE Access con Horizon Client con el mensaje "No tiene autorización para ese escritorio o esa aplicación". (1813881, 2201599)
Este síntoma se produce en la siguiente situación. El usuario tiene autorización para dos asignaciones de VDI dedicadas a través de una autorización de grupo. Ambas asignaciones de escritorios VDI dedicados se indican en Workspace ONE Access cuando el usuario inicia sesión. El usuario inicia el primer escritorio mediante Horizon Client. Se conecta ese escritorio. A continuación, el usuario intenta iniciar del otro escritorio desde la otra asignación, también mediante Horizon Client. El inicio de dicho escritorio falla con un error que indica que el usuario no tiene autorización. Sin embargo, este problema se produce solo para el primer intento en el segundo escritorio. Si el usuario inicia el segundo escritorio mediante el explorador, los siguientes intentos para iniciar el segundo escritorio mediante Horizon Client se realizan correctamente. Solución alternativa: Si se produce esta situación, intente iniciar el segundo escritorio mediante el explorador.
Workspace ONE Access no muestra los nombres de las aplicaciones remotas configurados en la consola administrativa de Horizon Cloud. (2131583)
Este problema se resuelve usando Workspace ONE Access Connector versión 19.03. Debido a un problema conocido en las versiones de Workspace ONE Access Connector anteriores a la 19.03, cuando Workspace ONE Access muestra las aplicaciones remotas que se sincronizan desde Horizon Cloud, Workspace ONE Access no muestra los nombres para mostrar que estableció para dichas aplicaciones remotas en Horizon Cloud. A pesar de que Horizon Cloud envía los nombres para mostrar a Workspace ONE Access, Workspace ONE Access utiliza alternativamente los launchID de las aplicaciones remotas. Como resultado, Workspace ONE Access muestra los nombres básicos de las aplicaciones remotas.

Problemas conocidos relacionados con la interfaz de usuario

A menos que se especifique lo contrario en el texto del problema conocido, los problemas conocidos que se indican aquí se aplican a los pods que se implementan en Microsoft Azure.

El contenido de la ventana Ayuda > Acerca de de la consola administrativa no es preciso.
Al hacer clic en Ayuda > Acerca de en la consola, la información de la ventana no es precisa. Debido a este problema, el texto aparece protegido y muestra siempre la versión 2.2, en lugar de indicar algo preciso y relevante sobre el entorno de arrendatario o sobre el entorno del plano de control de nube en el que está trabajando. Solución alternativa: ninguna.
A pesar de que un pod en el manifiesto 2298.0 o una versión posterior debe tener al menos una configuración de puerta de enlace para las operaciones compatibles, la consola administrativa no le impide eliminar la única configuración de puerta de enlace del pod y dejarla en el estado no compatible.
La consola administrativa proporciona un flujo de trabajo en el que se puede eliminar la configuración de puerta de enlace existente de un pod con el fin de volver a implementar la puerta de enlace con una nueva configuración de implementación. Este flujo de trabajo se proporciona porque, en este momento, la consola no proporciona una manera de utilizar el flujo de trabajo Editar pod para actualizar la configuración de implementación de la puerta de enlace, aunque se pueda utilizar el flujo de trabajo Editar pod para actualizar la configuración de software de la puerta de enlace en cualquier momento específico.

Ahora, un pod en el manifiesto 2298 o una versión posterior debe tener al menos una configuración de puerta de enlace para que las operaciones sean compatibles. Cuando se elimina la configuración única de la puerta de enlace de este pod para poder actualizar la configuración de implementación de la puerta de enlace, como se describe en el párrafo anterior, la consola muestra un mensaje de advertencia. Sin embargo, la consola no impide la eliminación de la única puerta de enlace implementada del pod, ya que proporciona el caso práctico que se describe en el párrafo anterior. La expectativa es que vuelva a implementar la configuración de puerta de enlace poco después con nuevas opciones para la implementación de la puerta de enlace que no tenía la configuración eliminada. El problema es que la consola actualmente permite eliminar la configuración única de puerta de enlace de un pod en el que se requiere al menos una puerta de enlace para las operaciones compatibles, mientras que, al mismo tiempo, la consola no requiere que se vuelva a implementar una nueva puerta de enlace en el pod poco después. Si deja el pod sin una configuración de puerta de enlace, el pod tiene una configuración no compatible.

Solución alternativa: Para estar bajo una configuración compatible, debe asegurarse de que cada pod del manifiesto 2298.0 o una versión posterior tenga al menos una configuración de puerta de enlace. Se debe implementar una de las siguientes configuraciones en el pod:

  • Una puerta de enlace externa
  • Una puerta de enlace interna
  • Puertas de enlace externas e internas

Si elimina la configuración única de puerta de enlace de un pod del manifiesto 2298.0 o una versión posterior con el fin de cambiar una configuración de puerta de enlace que solo se pueda cambiar si elimina y vuelve a implementar la puerta de enlace, debe volver a implementar una nueva puerta de enlace en el pod para que permanezca bajo una configuración admitida. El equipo de servicio de VMware Horizon está trabajando en mejoras que ya no requerirán que la consola proporcione un flujo de trabajo para eliminar una puerta de enlace implementada para el caso práctico en que se cambia la configuración de implementación de la puerta de enlace. Cuando esto sea posible, se evitará la posibilidad de eliminar la configuración única de puerta de enlace del pod mediante la consola.

En la tarjeta de usuario, al hacer clic en Restablecer en una sesión de escritorio VDI desde un pod de Microsoft Azure, se muestra un mensaje de error a pesar de que la máquina virtual se restablece correctamente. (2567272)
Debido a este problema, a pesar de que la operación de restablecimiento se inicia correctamente y, finalmente, se restablece la máquina virtual, la consola administrativa muestra un cuadro de mensaje de error. El mensaje implica que el sistema no pudo completar su solicitud, a pesar de que en realidad la máquina virtual se ha restablecido. Este problema puede observarse en una sesión de escritorio desde una asignación de escritorios VDI flotante. Solución alternativa: ninguna. La operación de restablecimiento se inicia de forma correcta y, finalmente, se restablece la máquina virtual. Cierre el cuadro de mensaje de error que se muestra.
El gráfico Segmentos de inicio de sesión que se muestra en el panel de control de sesiones no tiene datos.
Este problema se aplica a todos los tipos de pods. El servicio de VMware Logon Monitor proporciona los datos del gráfico Segmentos de inicio de sesión que aparece en el panel de control de sesiones. Sin embargo, esta versión no admite el uso del servicio de VMware Logon Monitor. y, de forma predeterminada, Horizon Agents Installer desactiva en todas las instalaciones que realiza el instalador. Como consecuencia, aunque no haya datos que pueda mostrar el servicio de VMware Logon Monitor., el gráfico de Segmentos de inicio de sesión seguirá siendo visible en el panel de control de sesiones. Solución alternativa: ninguna.
Cuando se utiliza la consola administrativa en la pestaña de un navegador, si se intenta iniciar un escritorio desconectado que está en otra pestaña del mismo navegador, se cierra la sesión en el portal de HTML Access y se debe volver a iniciar sesión en él. (2118293)
Por lo general, cuando se inicia un escritorio y se desconecta de él sin cerrar sesión, la sesión del portal de HTML Access se mantiene abierta y se puede volver a conectar con el escritorio desconectado sin tener que introducir las credenciales en el portal de HTML Access. Debido a este problema, si se encuentra en una ventana del navegador donde ha iniciado sesión en la consola en una pestaña del navegador, y utiliza otra pestaña del mismo navegador para iniciar sesión en el portal de HTML Access e iniciar un escritorio, cuando se desconecte de dicho escritorio e intente volver a conectarse a él, se cerrará la sesión del portal de HTML Access. A continuación, deberá volver a introducir las credenciales del portal de HTML Access para poder volver a conectarse a dicho escritorio. Solución alternativa: Para evitar este problema, inicie sesión en la consola administrativa en una ventana independiente del navegador donde tiene el portal de HTML Access. Esto solo ocurre si se ha iniciado sesión en la consola en una pestaña de la misma ventana del navegador en el que también se está utilizando el portal de HTML Access.
En la pantalla de la tarjeta de usuario para un usuario específico, se eliminan las asignaciones de escritorios dedicados VDI de la pestaña Asignaciones después de que el usuario inicie por primera vez el escritorio dedicado desde la asignación. (1958046)
Cuando se especifica un usuario en una asignación de escritorios dedicados VDI como usuario individual, no a través de un grupo de Active Directory, la asignación de escritorios dedicados VDI aparece en la pestaña Asignaciones en la pantalla de la tarjeta de usuario para el usuario solo hasta que el usuario inicie por primera un escritorio dedicado desde la asignación. Después de que el usuario inicie por primera vez un escritorio dedicado VDI desde la asignación, la pestaña Asignaciones de la tarjeta de usuario ya no mostrará la asignación de escritorios dedicados VDI para dicho usuario. El inicio por primera vez por parte del usuario tiene como resultado que el usuario solicita un escritorio dedicado específico desde el grupo subyacente definido por la asignación y el sistema asigna este escritorio dedicado específico al usuario en particular. Cuando se realiza esa asignación, el escritorio dedicado específico obtiene el estado Asignado y se muestra en la pestaña Escritorios de la tarjeta de usuario para el usuario.

Solución alternativa: En lugar de confiar en la pestaña Asignaciones de la tarjeta de usuario, en este caso, para ver los escritorios dedicados VDI ya iniciados asignados a un usuario específico, puede utilizar la pestaña Escritorios. Si tiene que localizar la asignación de escritorios dedicados VDI específica en la cual se realiza la asignación del escritorio del usuario, obtenga el nombre del escritorio desde la pestaña Escritorio de la tarjeta de usuario y utilice la función de búsqueda por máquinas virtuales de la búsqueda del banner superior para que aparezca la máquina virtual de escritorio específica. En los resultados de la búsqueda por máquinas virtuales, haga clic en el nombre para abrir la página de asignación específica que tiene el escritorio dedicado concreto. A continuación, puede localizar al usuario en los detalles de la asignación.

La pantalla Novedades aparece incluso si anteriormente seleccionó la opción de no seguir mostrándola. (2075825)
Este problema se aplica a los entornos con cualquier tipo de pod. Debido a este problema, si desactiva la caché del navegador o utiliza un navegador distinto de aquel en el cual seleccionó previamente la opción para no mostrar la pantalla Novedades, la pantalla puede aparecer cuando inicie sesión en la consola administrativa. El indicador para determinar si se debe mostrar la pantalla Novedades se almacena en la caché local del navegador, en lugar de almacenarse por usuario. Solución alternativa: ninguna.
A pesar de que el proceso de creación de la imagen no se ha completado totalmente, la pantalla Primeros pasos muestra Completado para el paso Crear imagen. (2100467)
Debido a este problema, el paso Crear imagen aparece marcado como completado prematuramente. Solución alternativa: Utilice la página Actividad para verificar que se ha completado el proceso de creación de la imagen.
Cuando se utiliza la consola administrativa, es posible que se vean marcadores de posición en lugar de las cadenas de texto real, o que se haga clic en un botón de una página y no ocurra nada. (2045967)
Este problema se aplica a los entornos con cualquier tipo de pod. VMware actualiza periódicamente el entorno de administración en la nube que aloja a la consola basada en web. Este problema puede ocurrir cuando el contenido estático se ha almacenado en caché en el navegador antes de la actualización más reciente en la nube. Es un problema temporal que desaparecerá cuando se borre la caché del navegador. Solución alternativa: Intente cerrar la sesión en la consola, borre la caché del navegador, reinicie el navegador y, a continuación, inicie sesión de nuevo en la consola.
Los nombres de las aplicaciones se muestran en caracteres en minúscula cuando los usuarios finales acceden a ellos mediante Workspace ONE Access. (1967245)
Cuando el entorno de Horizon Cloud está integrado con Workspace ONE Access, los usuarios finales acceden a los escritorios y las aplicaciones asignadas a través de Workspace ONE Access. Debido a este problema conocido, los usuarios ven los nombres de las aplicaciones mostrados con caracteres en minúscula, sin tener en cuenta el uso real de mayúsculas y minúsculas en los nombres de aplicación. Esta limitación se debe a la forma en que Workspace ONE Access crea identificadores de inicio desde Horizon Cloud mediante el uso de REST API antiguas de Horizon Cloud. Solución alternativa: ninguna.
Los porcentajes de uso de memoria notificados para los informes de estado del escritorio y utilizados para las alertas de estado del escritorio se basan en un porcentaje de memoria asignada, lo que es igual a la memoria física más el tamaño de archivo de paginación, y no solo en el porcentaje de memoria física. (2015772)
La memoria asignada para una máquina virtual de escritorio se calcula como la memoria física más el tamaño de archivo de paginación. Al calcular el porcentaje de uso de memoria en un escritorio, el sistema toma el porcentaje utilizado del total (memoria física más el tamaño de archivo de paginación). Las alertas de estado del escritorio y el informe de uso de memoria en los informes de estado del escritorio utilizan el cálculo de porcentaje. Sin embargo, cuando se inicia sesión en una máquina virtual de escritorio y se abre el Administrador de tareas de Windows para ver el uso de memoria en el sistema operativo de Windows del escritorio, el Administrador de tareas de Windows muestra el porcentaje solo en función de la memoria física. Como resultado, el porcentaje de uso de memoria que muestra el Administrador de tareas de Windows del escritorio no coincide con el porcentaje de uso de memoria mostrado en los informes de estado del escritorio ni en la alerta de estado del escritorio. Solución alternativa: Tenga en cuenta esta diferencia si decide realizar una comparación entre el porcentaje de uso de memoria notificado por el Administrador de tareas de Windows de un escritorio y el porcentaje de uso de memoria notificado en el informe de estado del escritorio de la consola y las alertas de estado del escritorio de dicho escritorio.
Si el uso de CPU de una máquina virtual de escritorio es del 100 %, o se aproxima a esta cifra, no se activa la alerta de escritorio. (1446496)
Si una aplicación o un elemento de la máquina virtual de escritorio hace que el uso de CPU de la máquina virtual alcance el 100 %, el agente de escritorio no envía tantas muestras de datos como de costumbre a Horizon Cloud debido a que la CPU está muy ocupada. Como resultado del bajo recuento de muestras devueltas, el cálculo que utiliza el sistema para activar la alerta de escritorio se ve afectado. Solución alternativa: ninguna.

Problemas conocidos relacionados con el usuario final, Horizon Agent, Horizon Client

Los problemas conocidos que se indican aquí se aplican a los pods que se implementan en Microsoft Azure.

Para una máquina virtual que ejecuta Microsoft Windows 10 Enterprise multisesión 2004 o una versión posterior, las funciones de sincronización de PPP y ajuste de escala de la pantalla presentan problemas (2587685, DPM-6352)
Debido a la imposibilidad de consultar los PPP actuales en las máquinas virtuales que ejecutan Microsoft Windows 10 Enterprise multisesión 2004 o una versión posterior, estas funciones con esas máquinas virtuales no se ejecutan según lo establecido en la documentación de Horizon Client. Las funciones de sincronización de PPP y ajuste de escala de la pantalla no se ejecutan para las reconexiones de sesión de PCoIP. La función de ajuste de escala de PPP no se ejecuta para las reconexiones de sesión de Blast. Solución alternativa: Cierre sesión y vuelva a ingresar.
Para una máquina virtual que ejecuta el sistema operativo Microsoft Windows 10 Enterprise 1903 o una versión posterior, las funciones de sincronización de PPP y ajuste de escala de la pantalla presentan problemas (2589129)
Debido a la imposibilidad de consultar las PPP actuales en las máquinas virtuales que ejecutan el sistema operativo cliente Microsoft Windows 10 Enterprise 1903 o una versión posterior, al volver a conectar una sesión de PCoIP o de Blast, las funciones no se ejecutan según lo indicado en la documentación de Horizon Client. Solución alternativa: Cierre sesión y vuelva a ingresar.
En ocasiones, al iniciar un escritorio VDI mediante VMware HTML Access, aparece un mensaje de error que indica que se va a desconectar y, después, el inicio se realiza correctamente. (2243471)
Las máquinas virtuales de escritorio VDI tienen un tiempo de espera predeterminado para la conexión de la sesión, y cuando se agota ese tiempo de espera, la sesión se desconecta. En ocasiones, si, al iniciar un escritorio, la sesión de HTML Access del usuario final ha agotado el tiempo de espera de la sesión en el momento en que se agota el tiempo de espera de la conexión de la sesión predeterminada del escritorio, el escritorio inicialmente arrojará ese error y luego seguirá iniciando el escritorio. Solución alternativa: ninguna.
Cuando una asignación de escritorios VDI tiene el cifrado de disco seleccionado y un modelo de la máquina virtual de uno o dos núcleos, si la máquina virtual subyacente de un escritorio se apaga, puede fallar la opción de reintento automático de Horizon Client para realizar una conexión. (2167432)
Cuando una máquina virtual de un escritorio VDI se apaga debido a la configuración de gestión de energía de la asignación de escritorios VDI, la máquina virtual debe encenderse y estar preparada para poder realizar una conexión de usuario final a dicho escritorio. Cuando un cliente del usuario final intenta conectarse a la máquina virtual de una asignación de escritorios de VDI y la máquina virtual está apagada, el sistema comienza a encender esa máquina virtual. En el caso de las máquinas virtuales sin cifrar, estas suelen estar listas para aceptar una conexión de cliente en menos de 10 minutos. Sin embargo, las máquinas virtuales cifradas con uno o dos núcleos suelen tardar más de 10 minutos en estar listas para aceptar una conexión. La opción Reintento del cliente de Horizon Client tiene un límite máximo de 12 minutos. Debido a este límite superior de la opción Reintento del cliente, cuando el usuario final hace que el cliente vuelva a intentar automáticamente la conexión mientras la máquina virtual subyacente del escritorio se está encendiendo y preparando, pero se tarda más de 12 minutos, el reintento automático del cliente se detiene. Debido a que las máquinas virtuales cifradas suelen tardar más de 12 minutos en estar listas para realizar la conexión con el cliente, es posible que el usuario final considere que el reintento automático de Horizon Client para completar la conexión con la máquina virtual de escritorio cifrada ha fallado. Solución alternativa: Si desea tener cifrado de disco para una asignación de escritorios VDI, seleccione un modelo de máquina virtual que tenga más de dos núcleos. De lo contrario, si la asignación de escritorios de VDI tiene cifrado de disco y un modelo de máquina virtual con uno o dos núcleos, informe a los usuarios finales de que pueden experimentar este problema al utilizar la opción Reintento del cliente con estas máquinas virtuales de escritorio cifradas.
En el caso de un escritorio virtual de una asignación de escritorios VDI dedicados, es posible que el vínculo de acceso directo en la página Recientes de Horizon Client no inicie el escritorio. (1813881, HD-3686, DPM-1140)
Las versiones de iOS y Android de Horizon Client tienen una página Recientes que muestra vínculos a los escritorios iniciados recientemente. Cuando el usuario inicia un escritorio virtual de grupo dedicado, el escritorio se inicia de la forma habitual y el cliente crea un icono de inicio en la página Recientes. Sin embargo, cuando el usuario se desconecta del escritorio y, a continuación, intenta iniciar el escritorio desde la página Recientes, el escritorio no se inicia porque el icono de inicio utiliza una versión abreviada del nombre del escritorio. Solución alternativa: Inicie el escritorio desde la página principal del cliente y no desde la página Recientes.
Pods en la versión de manifiesto 1976.0 y máquinas virtuales de granja que ejecutan el nivel de agente 19.4: los usuarios se desconectan después de una hora de sus sesiones de aplicación remotas o escritorios al utilizar HTML Access (Blast) y los protocolos de PCoIP. (2519400)
Este problema se debe a un problema en los servicios de terminal de Microsoft en sistemas Microsoft Windows 10 Enterprise multisesión. Para escritorios basados en sesiones y aplicaciones remotas aprovisionadas desde granjas RDSH basadas en el sistema operativo Microsoft Windows 10 Enterprise multisesión, cuando un usuario final se vuelve a conectar a una sesión de aplicación remota o de escritorio existente mediante el protocolo PCoIP o HTML Access (Blast) después de que haya transcurrido una hora, se forzará la desconexión de la sesión del usuario. No hay pérdida de datos. A pesar de que el usuario puede volver a conectarse y de que la sesión se encuentra en el mismo estado que en el momento de la desconexión, este comportamiento se repite y la sesión que se volvió a conectar se desconecta de nuevo después de una hora.

Este problema se resuelve con Horizon Agents Installer (HAI) 20.1 o una versión posterior. Cuando el pod 1976.0 se actualiza al manifiesto 1976.1 o una versión posterior, el asistente Importar máquina virtual - Catálogo de soluciones instalará automáticamente el software de agente que incluya esta solución. Si el pod aún está en el nivel de manifiesto 1976.0, la ejecución del asistente seguirá instalando el software del agente que presenta el problema. Sin embargo, cuando se sella la máquina virtual, la página Imágenes muestra el punto azul, lo cual significa que se puede utilizar la función Actualizar agente para actualizar el agente al nivel que incluye la solución.

Pods en versiones de manifiesto anteriores a la 2298: al cambiar los protocolos en el cliente, si selecciona la opción Conectar en lugar de Cerrar sesión y volver a conectar, el cliente puede dejar de responder. (2528014)
Este problema está resuelto en los pods que se actualizan a la versión de manifiesto 2298 o versiones posteriores. Este problema se produce al cambiar los protocolos en el cliente después de establecer una sesión en una granja RDSH mediante un protocolo. Al iniciar el escritorio o la aplicación con un protocolo, desconectar esa sesión, utilizar el menú del cliente para cambiar a otro protocolo e iniciar el mismo escritorio o aplicación, el cliente recibe un cuadro de diálogo que indica que "Este escritorio está abierto en el servidor pero está ejecutando un protocolo diferente". y presenta una opción para conectarse o cerrar sesión y volver a conectarse. Si selecciona el botón Conectar, el cuadro de diálogo aparece una segunda vez, y si selecciona Conectar de nuevo, el cliente deja de responder.
Cuando se utiliza la función Actualizar agente para actualizar imágenes que tiene una versión del agente anterior a la 18.2.2, es posible que se produzca un error durante el proceso (2200962)
Las imágenes que creó en los nodos en el nivel de manifiesto anterior a la versión 965 pueden experimentar este problema. En ocasiones, la imagen tiene valores de registro RunOnce que bloquean la finalización del proceso de actualización del agente. Solución alternativa: Realice la actualización del agente de nuevo agregando el siguiente argumento de la línea de comandos en la pestaña Línea de comandos del asistente de actualización del agente: VDM_SUPPRESS_RUNONCE_CHECK=1