Arrendatarios de first-gen: problemas conocidos de Horizon Cloud

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

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.

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 los pods de Horizon a Horizon Cloud, para acceder a los problemas conocidos del software que se ejecuta dentro de esos pods de Horizon, consulte las notas de la versión en las siguientes ubicaciones, de acuerdo con la versión de software de Connection Server del pod:

Versión 7.13: disponible en la documentación de Horizon 7.
Versiones VMware Horizon 8: disponibles en la documentación de Horizon .

Para ver los problemas conocidos del servicio de administración de imágenes (IMS) relacionados con las funciones de IMS que están disponibles en producción para todos los clientes de Horizon Cloud, consulte la página de problemas conocidos en 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 la suscripción de Microsoft Azure

Después de usar Horizon Universal Console para actualizar la clave secreta de la configuración de suscripción de Azure de un pod, las máquinas virtuales del administrador de pods se deben reiniciar para que se apliquen las nuevas credenciales (2979394, 3007687 y 3017415)

Debido a este problema conocido, después de editar y guardar la configuración de la Clave de aplicación en la ventana Administrar suscripción de la consola, la clave secreta recién introducida no surte efecto en las máquinas virtuales del administrador de pods hasta que se reinicie el servicio de administración en los sistemas operativos de las máquinas virtuales. Si no se reinicia el servicio de administración, se producirán errores en las llamadas de API que utiliza el servicio para trabajar con los recursos de la suscripción. Solución alternativa: si la clave secreta de suscripción del pod debe actualizarse por algún motivo (por ejemplo, que haya caducado o esté próxima a hacerlo), abra una solicitud de servicio con el fin de obtener asistencia de los equipos de soporte de VMware y operaciones de Horizon Cloud para garantizar que se sigan los pasos correctamente. En un nivel alto, los pasos son:

En el portal de Azure, genere una nueva clave secreta.
En Horizon Universal Console, siga los pasos estándares para actualizar la clave secreta que utilizan el pod o los pods asociados con la clave anterior, como se describe en la página Cambiar, modificar y actualizar la información de suscripción asociada con los pods de Horizon Cloud implementados.
Solicite al servicio de soporte de VMware que reinicie el servicio de administración en ambas máquinas virtuales del administrador de pods.

No es adecuado publicar aquí el comando específico para reiniciar el servicio de administración porque solo los equipos de VMware podrán ejecutarlo. Estos equipos pueden hacer referencia al problema interno 3007687-update-9.

Problemas conocidos relacionados con Cloud Connector

El estado del servicio de supervisión de servidor de conexión (CSMS) se muestra como No listo en el área Estado del portal de configuración de Horizon Cloud Connector (3236634): Como se describe en el artículo de la base de conocimientos de VMware 91124, para Horizon Cloud Connector versión 2.3, tras un reinicio del dispositivo Horizon Cloud Connector o tras un reinicio del clúster de Kubernetes del dispositivo, el estado de CSMS se muestra como No listo.
Este problema se resuelve en Horizon Cloud Connector a partir de la versión 2.4. Para solucionar el problema en versiones anteriores, siga los pasos descritos en el artículo de la base de conocimientos.
Problema de caducidad del certificado (3083444): Se detectó que un certificado en las versiones de Horizon Cloud Connector anteriores a la 2.4 tiene una caducidad de un año a partir del momento de implementación del dispositivo. Cuando este certificado caduque, Horizon Cloud Connector ya no podrá ponerse en contacto con el plano de control de Horizon Cloud, y esto supondrá que no funcionen los servicios basados en la nube proporcionados por Horizon Cloud Connector. Consulte el artículo 90505 de la base de conocimientos para obtener más detalles y los pasos de resolución.
A partir de Horizon Cloud Connector versión 2.4, el sistema renueva automáticamente los certificados antes de que caduquen.
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 la configuración de la puerta de enlace de los pods de Horizon Cloud

La función Horizon Universal Console para habilitar la configuración del servidor syslog en la configuración de la puerta de enlace está desactivada de forma predeterminada. (3005985, 3023935, 3026855): Debido a un problema identificado con la llamada API del sistema para actualizar la configuración de Unified Access Gateway con la información del servidor syslog, la función publicada anteriormente se desactiva del uso en la consola. Solución alternativa: ninguna.

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

Aparece el mensaje de error "No se pudo conectar a Connection Server" cuando Horizon Client u Horizon HTML Access en el navegador empiezan a conectarse a Universal Broker (2714266)

Este problema afecta a pods de Horizon Cloud en Microsoft Azure que ejecutan el manifiesto 2632.x, en arrendatarios configurados para usar Universal Broker para brokering de escritorios de usuarios finales. Otro síntoma de este problema es que se observan las siguientes situaciones al mismo tiempo:

En la página de detalles del pod donde reside la máquina virtual de escritorio, verá que el estado de la máquina virtual del administrador de pods se notifica como Error para todas las máquinas virtuales del administrador de pods.
Se muestra el mensaje de error "En este momento, este escritorio no se encuentra disponible. Vuelva a intentar conectarse a este escritorio más tarde o póngase en contacto con el administrador del sistema" cuando Horizon Client u Horizon HTML Access del navegador comienzan a conectarse a Universal Broker.

Este problema puede ocurrir de forma intermitente para pods de Horizon Cloud en Microsoft Azure que ejecutan el manifiesto 2632.x si se reinicia la instancia del administrador de pods. En ocasiones, cuando se reinicia la instancia del administrador de pods (una situación inusual y atípica), una vez que se apaga la instancia del administrador de pods y Universal Broker intenta conectarse al pod, no se puede realizar una conexión autenticada. Solución alternativa: ninguna. Si se encuentra con esta situación, abra una solicitud de servicio de asistencia y cite el número de informe de problemas internos 2714266.

Para los pods en el manifiesto 2747.x y versiones posteriores, este problema se ha resuelto.

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.

Durante el proceso de publicación de imágenes se produce un error de tiempo de espera, y la máquina virtual permanece encendida e impide que el flujo de publicación se complete correctamente. (2954270, 2962049)

Este problema es el resultado de otro conflicto que se produce en el hipervisor de Microsoft Azure al ejecutar el paso de sysprep del proceso de publicación. y aparece en algunos modelos de máquina virtual de Azure. Para obtener más detalles, consulte el artículo KB88343 de la base de conocimientos de VMware.

De acuerdo con la recomendación del equipo de Microsoft Azure, para proporcionar una resolución a los clientes de Horizon Cloud, el modelo predeterminado de máquina virtual de Azure que se utiliza en el asistente automatizado Importar máquina virtual - Catálogo de soluciones del servicio cambia en la versión 2204 de este y pasa a utilizar el modelo Standard_DS2_v2 para la importación automatizada de máquinas virtuales Windows 10 sin GPU (tanto de sesión única como multisesión):

Con las imágenes de pod único, el modelo predeterminado de máquina virtual que se usa en la automatización cambia del Standard_D4_v3, que se utilizaba anteriormente, al Standard_DS2_v2.
Con las imágenes de varios pods, el modelo predeterminado de máquina virtual que se usa en la automatización cambia del Standard_D2_v2, que se utilizaba anteriormente, al Standard_DS2_v2.

A partir de la versión 2204, debe incluir la cuota de la serie DSv2 de Azure en las suscripciones de Azure del pod.

Puede que las máquinas virtuales y sus recursos relacionados no se eliminen por completo de la suscripción de Microsoft Azure. (2824239, 2681761, 2750176)

Este problema se ha resuelto en los manifiestos de pod de las versiones 2915.x en adelante. Si esto sucede en pods de manifiestos anteriores, se pueden producir problemas como la expansión de las asignaciones de VDI. Esto se debe a un problema en Azure Resource Manager (ARM) de Microsoft y a retrasos en la replicación del estado de los recursos en las diferentes regiones de la nube de Microsoft Azure. A causa de este problema de Microsoft ARM, puede que algunos de esos recursos de máquina virtual se dejen sin eliminar y, por lo tanto, no se asocien a una máquina virtual en la suscripción de Azure. Algunos ejemplos de estos elementos no asociados que pueden aparecer son los discos y las NIC. Solución alternativa: Este problema se ha resuelto en los pods que ejecutan manifiestos de las versiones 2915.x en adelante. Si se encuentra con este problema, tramite una solicitud de servicio para pedir ayuda para borrar los datos obsoletos y programar una actualización del pod a fin de evitar que el problema se repita. Consulte el artículo de la base de conocimientos 2006985 para saber cómo tramitar una solicitud de soporte.

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 la 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 Sí 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 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 detener y desactivar el servicio tiledatamodelsvc en la imagen. 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.

La carga de paquetes de aplicación (archivos .vhd) con el mismo nombre de archivo en la misma ubicación (recurso compartido de archivos), capturados en diferentes momentos, puede evitar que el servicio de App Volumes conecte aplicaciones a los escritorios VDI cuando el usuario inicia sesión (2783560): Cada vez que App Volumes captura un paquete de aplicación (archivo .vhd), el sistema genera un GUID único para identificar la sesión de captura o el volumen. Cuando se intenta cargar un paquete de aplicación en el recurso compartido de archivos provisional de pods de Horizon Cloud Azure con un nombre de archivo (.vhd) cargado anteriormente, se produce una falta de coincidencia entre los GUID que ya están presentes en los pods de Horizon Cloud Azure y los servicios de nube.
El servicio de App Volumes Manager que se ejecuta en los pods de Horizon Cloud Azure importa periódicamente los paquetes de aplicación del recurso compartido de archivos. Cuando se intentan importar las aplicaciones desde la página para importar Inventario > Aplicaciones de Horizon Universal Console, los paquetes de aplicación recién importados y sus GUID correspondientes no coinciden con los GUID presentes en el servicio de App Volumes Manager que ejecuta los pods de Horizon Cloud Azure. Debido a esta falta de coincidencia, las aplicaciones asignadas no se asocian a los usuarios autorizados.
Si se eliminan algunos usuarios o grupos de una asignación de App Volumes en la consola, es posible que se eliminen las autorizaciones de algunos de los usuarios o grupos restantes de la asignación (2704889): Debido a este problema, en un escenario en el que se ha creado una asignación de App Volumes que contiene un conjunto de aplicaciones y grupos o usuarios especificados y, a continuación, se edita esa asignación y se elimina algunos de esos usuarios o grupos específicos, algunos de los usuarios y grupos que permanecen configurados en esa asignación no pueden ver las aplicaciones en sus escritorios autorizados.
A pesar de que este problema está resuelto en el manifiesto del pod 2747 y versiones posteriores, es posible que este problema se encuentre en pods de versiones de manifiesto anteriores. Si se encuentra con este problema, puede crear una nueva asignación de App Volumes con las aplicaciones y los usuarios y grupos necesarios, y eliminar la asignación de App Volumes creada anteriormente.
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.
En una implementación de Microsoft Windows 10 Enterprise multisesión, es posible que un trabajo de impresión finalice cuando otro usuario inicia sesión en la misma máquina.: En este entorno, cuando un usuario con una asignación de paquete de aplicación que contiene un controlador de impresora inicia sesión por primera vez, un trabajo de impresión continuo de otro usuario en esa máquina de sesión múltiple podría entrar en un estado de error. Para evitar este problema, espere unos minutos o más después de que finalice el trabajo de impresión y vuelva a intentar el trabajo de impresión. Consulte la guía Administración de su entorno de arrendatario de Horizon Cloud y el conjunto de pods incorporados para obtener información sobre las prácticas recomendadas relacionadas.
En una implementación de Microsoft Windows 10 Enterprise multisesión, los usuarios que no tienen asignado un paquete de aplicación reciben aspectos de la aplicación: En este entorno, ocasionalmente, cuando no se desactivan las actualizaciones automáticas de una aplicación durante el aprovisionamiento, la parte actualizada de la aplicación se vuelve visible de forma involuntaria para todos los usuarios (no solo los asignados a la aplicación) en el escritorio multisesión, como en forma de acceso directo de escritorio y archivos binarios de aplicaciones. Para evitar este problema, para las aplicaciones con servicios de actualización automática, agregue el nombre del servicio de la aplicación a la configuración del registro de svservice de varias cadenas DisableAppServicesList para asegurarse de que los servicios de actualización automática no se inicien. Consulte la guía Administración de su entorno de arrendatario de Horizon Cloud y el conjunto de pods incorporados para obtener información sobre las prácticas recomendadas relacionadas.

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

Es posible que el inicio de un escritorio dedicado desde Horizon Client con una opción reciente abierta (o una opción equivalente según el tipo de cliente) no inicie correctamente el escritorio dedicado (SR23422432704, HCS-39121)

Varias instancias de Horizon Client proporcionan mecanismos por los que el cliente recuerda una aplicación remota o un escritorio iniciados anteriormente, y el usuario final puede iniciar esos escritorios o aplicaciones publicadas abiertos anteriormente sin ir a la lista completa de escritorios y aplicaciones para los que tiene autorización.

Por ejemplo, en Horizon Client para iOS y Horizon Client para Android, sus pantallas etiquetadas como Reciente proporcionan acceso a estas aplicaciones remotas y escritorios iniciados anteriormente. Como se describe en la documentación de Horizon Client para Mac, Horizon Client por Mac ofrece dos formas de abrir aplicaciones remotas y escritorios recientes: mediante la opción Archivo > Abrir reciente del cliente y, si el cliente está agregado al Dock, mediante el icono del Dock. Como se describe en la documentación de Horizon Client para Windows, Horizon Client para Windows tiene una configuración de GPO para lo que se denomina integración de lista de salto (jump list integration), que generalmente está habilitada de forma predeterminada y permite a los usuarios conectarse a escritorios recientes y aplicaciones publicadas mediante el icono de Horizon Client de la barra de tareas de Windows.

En el caso de un escritorio dedicado aprovisionado por Horizon Cloud on Microsoft Azure, después del primer inicio del escritorio, es posible que Horizon Client no almacene la identidad correcta del escritorio como un inicio reciente.

Debido a este problema, cuando el usuario final posteriormente utiliza uno de los mecanismos de cliente recientes descritos anteriormente para abrir de nuevo el escritorio, es posible que el escritorio no se inicie.

Este problema también se puede producir si se utiliza Workspace ONE Access con la implementación de Horizon Cloud on Microsoft Azure y Horizon Client redirecciona al usuario a Workspace ONE para organizar el inicio del escritorio dedicado. Cuando el usuario final inició previamente el escritorio directamente desde el portal de Workspace ONE y, a continuación, el usuario intenta utilizar uno de los mecanismos recientes del cliente para iniciar el escritorio, cuando el cliente redirecciona a Workspace ONE para organizar el inicio, es posible que el escritorio no se inicie debido a este problema.

Solución alternativa: Para evitar este problema, inicie siempre el escritorio seleccionando directamente el escritorio de la lista completa de escritorios en el cliente o, cuando el entorno esté configurado para que todos los inicios se realicen desde el portal de Workspace ONE, realizando el inicio seleccionando el escritorio en el portal de Workspace ONE. Evite utilizar el mecanismo reciente del cliente (utilice Archivo > Abrir Reciente o la lista Reciente de cualquiera de los mecanismos de tipo reciente que ofrecen los clientes).

Nota: Cuando el redireccionamiento de Workspace ONE está habilitado para la implementación de Horizon Cloud on Microsoft Azure y un usuario final utiliza un mecanismo reciente y el escritorio no se inicia, se escribe un evento de auditoría de Workspace ONE para indicar el inicio erróneo.

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

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

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