En esta página de documentación se describen los aspectos clave que se deben conocer sobre el mantenimiento de los componentes de software de VMware que componen el pod de Horizon Cloud implementado.

Breve introducción

Las actividades de mantenimiento del sistema incluyen una actualización automatizada de los componentes de software del pod para incluir nuevas funciones, correcciones y mejoras en la resistencia y la compatibilidad del servicio.

Para completar una actualización de los dispositivos de puerta de enlace y pod con tiempo de inactividad prácticamente nulo, el sistema utiliza los recuentos de las sesiones de usuario final. El sistema utiliza los recuentos de sesiones con el fin de determinar el tiempo óptimo para completar la actualización cuando hay pocos usuarios conectados al entorno con sesiones activas.

La actividad de mantenimiento que actualiza un pod existente a un manifiesto más reciente se inicia desde el plano de nube para que se produzca en un día y a una hora determinados por el sistema.

Para indicar su preferencia de que dicha actividad de mantenimiento del sistema debe iniciarse a una hora y un día determinados de la semana, use la consola para especificar la ventana de mantenimiento preferida de cada pod.

Se entenderá que un pod sin una ventana de mantenimiento preferida especificada significa que VMware puede programar un mantenimiento en ese pod en cualquier momento, cuando VMware lo considere oportuno.

Nota: Como se describe en esta página de la documentación, a partir de principios del año 2022, el servicio mejoró el código de actualización para utilizar de forma programática ofertas de VMware que VMware proporciona en Azure Marketplace. Cuando las comprobaciones previas a la actualización determinan que se evita el uso programático de esas ofertas de VMware en la suscripción, debe completar las acciones que se describen en esa página de documentación para resolver los errores de bloqueo de actualización.

Por ejemplo, si la entidad de servicio de Horizon Cloud asociada a las suscripciones utilizadas en el pod y sus configuraciones de puerta de enlace emplea una función personalizada (atípica), asegúrese de que la función personalizada incluye estos dos permisos. El código de API de actualización mejorada se basa en estos permisos para recuperar la lista de ofertas de Marketplace y obtener las ofertas de VMware. Si la función personalizada aún no incluye estos dos permisos, haga que se agreguen a dicha función antes de que tenga lugar el proceso de actualización del pod y la puerta de enlace.

Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/read
Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/write

Cuando los componentes de software utilizados en un pod implementado se actualizan a una nueva versión, el número de manifiesto del pod aumenta a un número de versión superior, como 2632.0. Si hay mejoras consideradas importantes para las operaciones de mantenimiento y compatibilidad del pod, VMware puede crear un nuevo manifiesto que es una versión de punto, como 2632.1. La consola muestra el manifiesto de un pod en la página Capacidad.

Información importante sobre la actualización de un pod desde manifiestos anteriores a la versión 3328

A partir de febrero de 2022, las NIC de las máquinas virtuales del administrador de pods siguen el mismo patrón de diseño de infraestructura que aquellas de las máquinas virtuales de Unified Access Gateway.

En las nuevas implementaciones de pods a partir de ese momento y en las actualizaciones de pods de manifiestos anteriores al manifiesto 3328, el implementador crea una instancia de todas las redes necesarias para admitir la ejecución del pod y para las actualizaciones posteriores a lo largo del tiempo. El grupo de recursos del pod ahora tendrá 8 NIC:

  • 4 NIC que reservan 4 direcciones IP de la subred de administración del pod
  • Las 4 NIC que reservan 4 direcciones IP de la subred de máquina virtual principal del pod (anteriormente denominada subred de arrendatario).

Las 8 NIC del pod persistirán y seguirán reservando sus direcciones IP asignadas durante la vida útil del pod.

Este diseño admite actualizaciones de pods más rápidas y resistentes. Antes de este diseño, una actualización del pod requería la creación de nuevas NIC como parte de la compilación del pod verde y la obtención de direcciones IP para esas NIC de las subredes del pod en el momento de la actualización. Con ese diseño, podían producirse tiempos de espera en Azure e interrumpir el proceso de actualización.

En este diseño, donde el implementador crea instancias de todas las redes necesarias por adelantado, las NIC y sus direcciones IP de las subredes de administración y de máquina virtual (arrendatario) se conservan para utilizarse en las actualizaciones de pod posteriores. Este diseño se alinea con el patrón utilizado para las instancias de Unified Access Gateway.

Cuando el pod aún no tiene las 8 NIC en el grupo de recursos del pod y está programado para actualizarse al manifiesto 3328 o una versión posterior, debe realizar estas acciones.

Antes de actualizar el pod, asegúrese de que solo los elementos que crea y configura Horizon Cloud on Microsoft Azure tomen las direcciones IP de la subred de administración del pod y las direcciones IP de la subred de máquina virtual principal (arrendatario).
  • Subred de administración: solo las NIC específicas de la implementación de Horizon Cloud on Microsoft Azure que el implementador de pods haya creado y configurado deben utilizar direcciones IP de la subred de administración del pod. Estas NIC son las de los administradores de pods y las de la instancia de Unified Access Gateway del pod. La subred de administración del pod no debe tener elementos ni recursos no implementados por el pod asociados a ella ni que tomen direcciones IP de ella.
  • Subred de arrendatario: solo los equilibradores de carga y las NIC específicas de la implementación de Horizon Cloud on Microsoft Azure que crea y configura el implementador de pods deben utilizar las direcciones IP de la subred de arrendatario del pod. La subred de arrendatario del pod no debe tener elementos ni recursos que no sean de implementación asociados a ella ni que tomen direcciones IP de ella.

La Guía de implementación indica exactamente que las subredes utilizadas por el pod no deben tener recursos adicionales asociados a ellas que no sean los recursos de la implementación del pod. Si creó recursos manualmente y asignó direcciones IP de la subred de arrendatario o de administración del pod a dichos recursos adicionales, debe eliminar esas direcciones IP de los recursos antes de que se ejecute la actualización del pod. De lo contrario, se producirá un error en la actualización del pod y se deberá recurrir al soporte de VMware.

Después de actualizar el pod, asegúrese de agregar todas las direcciones IP reservadas por aquellas de las NIC creadas por el implementador en el grupo de recursos del pod a las reglas de firewall vigentes antes de la actualización.
Es posible que las reglas de firewall existentes rijan el tráfico desde las direcciones IP de las NIC de las máquinas virtuales del administrador de pods. Para que la comunicación del tráfico funcione después de la actualización del pod tal como funcionaba antes de ella, debe asegurarse de que las 8 direcciones IP reservadas por las NIC en el grupo de recursos del pod se reflejen en las reglas de firewall después de la actualización.

Aspectos que debe conocer sobre el mantenimiento del pod

El mantenimiento de los componentes de software de VMware que componen el pod de Horizon Cloud implementado es una operación imprescindible para mantener el buen estado y la estabilidad de las aplicaciones y los escritorios virtuales aprovisionados por ese pod. Como se describe en el artículo de la base de conocimientos VMware Horizon Cloud Service: detalles adicionales del servicio (87894), VMware es responsable de los componentes de software que residen en el pod y que se descargan en ese pod desde el plano de control. El PDF VMware Horizon Cloud Service: detalles adicionales del servicio adjunto a ese artículo de la base de conocimientos describe:

  • Funciones y responsabilidades de VMware en relación con los procedimientos de administración de cambios para mantener el buen estado de los componentes de software que se descargan en el pod. Las actividades de mantenimiento incluyen la actualización de los componentes de software del pod.
  • Función y responsabilidades del cliente en torno a los procedimientos de administración de cambios, incluidos la cooperación con VMware cuando se requiera un mantenimiento programado o de emergencia.

El documento VMware Horizon Cloud Service: detalles adicionales del servicio incluye una definición de mantenimiento programado, ventanas de mantenimiento y mantenimiento de emergencia. Consulte el documento para obtener información. En caso de discrepancias entre el contenido de esta página de documentación y el contenido del documento VMware Horizon Cloud Service: detalles adicionales del servicio, el documento VMware Horizon Cloud Service: detalles adicionales del servicio tendrá prioridad.

Atención: Antes de actualizar el pod, debe asegurarse de que todas las máquinas virtuales de imagen del pod, las máquinas virtuales de granja y las máquinas virtuales de escritorio VDI tengan el agente más reciente disponible para el pod. Si no los actualiza al agente más reciente antes de la actualización del pod, es posible que, después de la actualización del pod, ejecuten versiones de agente incompatibles, lo cual pondrá el pod en un estado no compatible. ¿Cómo puede saber si necesita actualizar alguno de los agentes? En la consola, consulte si hay algún punto azul junto a una imagen o una asignación. Si ve algún punto azul, el objetivo es conseguir que todos los puntos azules desaparezcan de la consola antes de la actualización del pod. Consulte Actualizaciones de pods de Horizon Cloud: pasos para obtener compatibilidad y soporte continuados con los agentes.

Especificar la ventana de mantenimiento preferida del pod

Para indicar su preferencia para que cualquier actividad de mantenimiento en el pod se inicie a una hora y un día determinados de la semana, use la consola para especificar lo que se denomina la ventana de mantenimiento preferida para ese pod. En la página Capacidad, desplácese hasta la pestaña Mantenimiento en la página de detalles del pod. Busque la etiqueta Hora preferente de mantenimiento y, a continuación, siga los controles en pantalla para elegir el nombre y la hora (UTC) del día de la semana en ese día. Solo puede elegir entre los valores predeterminados predefinidos del sistema que se muestran.

Especifique la hora preferente de mantenimiento de cada pod por separado en la página de detalles de cada pod en la consola.

Nota: Se entenderá que un pod sin una ventana de mantenimiento preferida especificada significa que usted permite que VMware pueda programar un mantenimiento en ese pod en cualquier momento, cuando VMware lo considere oportuno.

El sistema leerá el día de la semana y la hora que especifique en la consola e incorporará los datos en su algoritmo de programación. Cuando se establece un nuevo manifiesto del pod como predeterminado en el plano de nube, el programador del sistema calculará el día de actualización real y la hora a la que ha determinado que la actualización puede ocurrir en cada pod del conjunto de pods. Aunque el sistema intentará en la medida de lo posible respetar las horas de inicio de mantenimiento preferidas especificadas en la pestaña Mantenimiento del pod, no hay garantías de que el sistema pueda amoldarse a esta hora de inicio de mantenimiento preferida para una operación de actualización específica.

Una vez establecido esto, el programador del sistema asigna cuatro (4) horas para la duración de la actividad de mantenimiento. La actualización típica del pod tarda menos tiempo que esta duración asignada.

Alertas y notificaciones de mantenimiento

El sistema alertará y notificará a los administradores del entorno de arrendatario cuando el sistema haya programado una fecha y una hora de calendario específicas para que se produzca el mantenimiento específico de un pod determinado. Estas alertas y notificaciones incluyen lo siguiente:

En la consola
  • Un banner persistente en la parte superior de la consola. La hora del banner es la hora de mantenimiento local de la zona horaria del navegador, tal como se visualiza en la consola. La siguiente captura de pantalla es un ejemplo en el que la actualización del pod se programa para que se produzca a las 16:00 de la zona horaria oriental de los Estados Unidos, el 7 de julio de 2020. Utilice el botón Ver para hacer clic en la página de detalles del pod y ver más información sobre el mantenimiento programado en la pestaña Mantenimiento del pod.
    Captura de pantalla de ejemplo del banner de la consola que proporciona información sobre el mantenimiento programado de un pod
  • En la pestaña Registros de auditoría del pod y en la pestaña Actividad > Registros de auditoría de la consola, un registro de auditoría mostrará que el equipo de operaciones de VMware tiene programada una actualización del pod. La línea del registro de auditoría incluirá el UUID del pod.
  • En la pestaña Mantenimiento del pod, la sección Mantenimiento programado mostrará información sobre el mantenimiento programado.
Correos electrónicos
El sistema enviará correos electrónicos sobre el mantenimiento del pod a los administradores del entorno de arrendatario, que se especifican en los ajustes de Configuración general > Cuentas de My VMware de la consola. Entre los correos electrónicos se incluye uno acerca del momento en que el sistema ha establecido la fecha y la hora de calendario específicos del mantenimiento programado. Algunos ejemplos de estos correos electrónicos son recordatorios periódicos en los días y las semanas anteriores a esa fecha y hora programadas, así como cuando la actividad de mantenimiento ha comenzado y cuando se ha completado.
Nota: Si desea volver a programar una fecha y una hora de mantenimiento programado, debe ponerse en contacto con el soporte técnico de VMware.

Comprobaciones previas del sistema antes de realizar el mantenimiento del pod

Si recibe un correo electrónico de notificación que indica que un pod tiene errores de actualización del pod, o si ve que la consola notifica errores de actualización para el pod, debe tomar medidas para rectificar la situación. Si esto sucede, siga las instrucciones en pantalla de la consola o las instrucciones del correo electrónico. La resolución habitual para estos errores normalmente implica realizar pasos en el portal de Microsoft Azure, en la suscripción del pod. Para obtener información adicional sobre las soluciones frente a errores típicos de actualización del pod, consulte Pods de Horizon Cloud: soluciones a errores comunes de comprobación previa.

¿Cuál es el objetivo de estas comprobaciones previas? La actividad de mantenimiento de una actualización del pod tiene lugar en los grupos de recursos del pod y la suscripción de Microsoft Azure. Un poco antes de que el sistema programe una fecha y una hora concretas para una actualización específica en un pod determinado, el sistema ejecuta una operación de comprobación previa para determinar si existen condiciones que pueden bloquear la actualización correcta de un pod. Como ejemplo de una de estas comprobaciones previas, el sistema comprueba si la suscripción de Microsoft Azure tiene suficientes vCores de la serie de máquinas virtuales apropiada para satisfacer los requisitos de la actualización. Si se produce un error en una de las comprobaciones previas y la condición requiere que se corrija su acción, se producen los siguientes problemas:

  • Se enviará un correo electrónico de notificación al usuario para alertarle de este hecho, con detalles sobre las acciones necesarias para rectificar el error.
  • La consola muestra una alerta visual que indica que se requieren acciones para rectificar los errores de comprobación previa de ese pod.
Importante: Si recibe notificaciones sobre errores de actualización del pod, realice las acciones especificadas para solucionar los errores de manera oportuna. Actuar a tiempo es fundamental. Si no se puede actuar para solucionar estos errores en el tiempo que VMware requiere, el pod pasará a un estado no compatible debido a la imposibilidad de solucionar el proceso de actualización del pod.

Actualizaciones del pod: descripción de nivel general

Cuando la actividad de mantenimiento es una actualización del pod a una versión de manifiesto más reciente, el sistema mueve correctamente los componentes de infraestructura actuales del pod a un nivel de manifiesto de software superior. Los componentes de infraestructura son principalmente las máquinas virtuales del administrador de pods y las máquinas virtuales de Unified Access Gateway que están configuradas para el pod. Por ejemplo, una actualización de pod puede incluir actualizaciones para el software de administración de pods o para el software de Unified Access Gateway, o ambos.

El proceso de actualización del pod sigue el modelo de una técnica de la industria del software conocida como implementación azul-verde. Los componentes existentes del pod que se deben actualizar se consideran componentes azules.


Ilustración conceptual del proceso de actualización azul-verde.

Aunque básicamente la actualización del pod sigue un patrón azul-verde del sector, existen algunas diferencias menores con respecto a una actualización clásica de tipo azul-verde. La actualización del pod no duplica al 100 % cada recurso azul de la compilación verde. Algunos de los recursos azules existentes se reutilizan en la nueva compilación verde, como las NIC para las instancias de Unified Access Gateway. Otra diferencia es que en el proceso de actualización del pod, cuando las instancias más recientes se crean junto con las ya existentes, las más recientes se encienden y continúan en ejecución hasta que el pod ha completado la migración a las instancias nuevas. Además, después de que el sistema migre el pod a la compilación verde y valide que el pod se esté ejecutando correctamente en la nueva versión de manifiesto, las máquinas virtuales azules más antiguas se eliminarán del grupo de recursos. (Una actualización clásica de tipo azul-verde por lo general conservaría los artefactos azules más antiguos después del cambio a verde, manteniendo las más antiguas en estado inactivo).

  • Los componentes del pod existentes que se actualizarán, como las máquinas virtuales del administrador de pods y las máquinas virtuales de Unified Access Gateway, se consideran los componentes azules.
  • El servicio crea automáticamente el conjunto verde necesario de componentes para el pod en la suscripción de Microsoft Azure: nuevas máquinas virtuales del administrador de pods verdes, máquinas virtuales Unified Access Gateway y la máquina virtual del conector de puerta de enlace (si la puerta de enlace externa se implementa en su propia red virtual).
  • Los componentes recién creados en la compilación verde se crean junto con los componentes azules, en los mismos grupos de recursos.
  • El proceso de creación de la compilación verde no genera ningún tiempo de inactividad ni pérdida de datos, y las máquinas virtuales paralelas no afectan a las operaciones del pod.
  • El conjunto verde es un entorno paralelo que está a la espera de la actividad de mantenimiento programado que hará que cambie de azul a verde. La forma en que el sistema programa la actividad de mantenimiento en un pod se trata en las secciones anteriores.
  • Estas máquinas virtuales verdes se inician y se mantienen en ejecución hasta que se completa la actividad de mantenimiento programada, la actividad de mantenimiento que migra el azul al verde.
  • Después de que se haya completado la actividad de mantenimiento programada para migrar a la compilación verde y de que el pod se esté ejecutando correctamente en las nuevas instancias, el sistema elimina las máquinas virtuales azules de los grupos de recursos del pod. Algunos recursos, como las NIC para las instancias de Unified Access Gateway, se mantienen para conservar los valores de configuración necesarios para la próxima actualización del pod.
Nota: Debe evitar realizar cambios en el portal de Microsoft Azure y en la suscripción del pod que afecten a la compilación del sistema a través de los componentes verdes o afecten a los procesos de actualización y mantenimiento del pod del sistema.

Secuencia de actividad de mantenimiento

Esta secuencia describe la migración a la compilación verde: el cambio de azul a verde en la actualización del pod.

  1. El sistema comprueba la ventana de mantenimiento preferida del pod que especificó en la consola para utilizar esa información en el algoritmo del programador, con el objeto de programar la fecha y la hora real de la actividad de mantenimiento del pod.
  2. El programador del sistema selecciona la fecha y la hora reales para que se produzca el mantenimiento. Como se describe en las secciones anteriores, la consola muestra visualmente la fecha y la hora programadas y se envía un correo electrónico a los administradores del arrendatario.
  3. Importante: Antes de que se ejecute el mantenimiento programado:
    • Asegúrese de que todas las máquinas virtuales de imagen del pod, las máquinas virtuales de granja y las máquinas virtuales de escritorio VDI tengan el agente más reciente disponible para el pod. Si ve algún punto azul en la consola, el objetivo es conseguir que todos los puntos azules desaparezcan de la consola antes de que se produzca la actualización del pod. Consulte Actualizaciones de pods de Horizon Cloud: pasos para obtener compatibilidad y soporte continuados con los agentes
    • Elimine en Microsoft Azure los bloqueos de administración que haya establecido en cualquiera de las máquinas virtuales (VM) del pod. Las máquinas virtuales con nombres que tengan una parte como vmw-hcs-podID, donde podID es el valor de ID del pod, pertenecen al pod. Microsoft Azure ofrece la posibilidad de usar el portal de Microsoft Azure para bloquear recursos con el fin de evitar que se realicen cambios en ellos. Estos bloqueos de administración se pueden aplicar en un grupo de recursos completo o en recursos individuales. Si usted o su organización aplicaron bloqueos de administración en las máquinas virtuales del pod, dichos bloqueos deben eliminarse antes de que se ejecute la actualización. De lo contrario, el proceso de actualización no se completará correctamente. Puede localizar el valor de ID del pod en la página de detalles del pod de la página Capacidad.

    Si las necesidades de su organización lo requieren, puede solicitar una fecha programada diferente para el mantenimiento. Para ello, póngase en contacto con el soporte técnico de VMware en cualquier momento antes de la hora de mantenimiento programada.

    Importante: La hora programada que aparece en la consola es local para la zona horaria del navegador.
  4. En el momento del mantenimiento programado, el servicio inicia la actividad de actualización. Por lo general, el proceso completo tarda entre 20 y 30 minutos desde el principio hasta el final para los pods que tienen una configuración de Unified Access Gateway externa e interna.
    Nota: Durante los 20 o 30 minutos que tarda en completarse el proceso, la consola no permite realizar tareas administrativas en el pod en el que se realiza la actualización. Por ejemplo, hasta que los dispositivos del administrador de pods no notifiquen al plano de nube que se completó la actualización, no se podrá hacer clic en la acción Editar de la página de detalles del pod para cambiar las características de ese pod.
    Acerca de las sesiones de usuario final y la actividad de actualización en los dispositivos Unified Access Gateway
    Para que las sesiones de usuario final tengan un tiempo de inactividad prácticamente nulo, dentro del tiempo de actividad de mantenimiento general, el sistema utiliza los recuentos de las sesiones de usuario final en los dispositivos a fin de determinar el tiempo óptimo para completar la actualización de dichos dispositivos.

    La hora de finalización se optimiza para que se produzca en el momento en que haya pocos usuarios conectados al entorno con sesiones activas.

    En esa ventana de tiempo prácticamente nulo, se desconectarán las sesiones activas de los usuarios finales. Luego de unos minutos, esos usuarios podrán volver a conectarse.

    No se producen pérdidas de datos, excepto en el caso de que se haya configurado la opción Inmediatamente para el control del tiempo de espera en las granjas y las asignaciones de escritorios VDI. En ese caso, los usuarios con sesiones activas en las que haya utilizado la opción Inmediatamente para el control del tiempo de espera se desconectarán inmediatamente, y esas sesiones también se cerrarán de inmediato, de acuerdo con esa configuración. En estas condiciones, se pierden todos los trabajos en curso del usuario. Para evitar la pérdida de datos en proceso de los usuarios finales en esta situación, antes de que se inicie la actividad de mantenimiento, asigne al ajuste Cerrar sesión en las sesiones desconectadas en las granjas y asignaciones de escritorios VDI un valor de tiempo que permita a los usuarios guardar su trabajo. A continuación, cuando se completa la actualización, puede volver a establecer la configuración en su valor anterior.

    Además, durante esa ventana de tiempo prácticamente nulo, si un usuario final que aún no tiene una sesión conectada a su escritorio virtual o aplicación remota desde el pod intenta conectarse, no podrá conectarse hasta que se complete el proceso.

  5. Una vez completada la actividad de mantenimiento, el sistema elimina los componentes que ya no se necesitan, como los componentes azules que no se reutilizan en la compilación verde, las máquinas virtuales del administrador de pods y las máquinas virtuales Unified Access Gateway. Algunos artefactos, como ciertas NIC para las instancias del administrador de pods y de Unified Access Gateway, se mantienen a fin de conservar los valores de configuración necesarios para el siguiente mantenimiento.

Después de la actividad de mantenimiento

Cuando finalice la actividad de mantenimiento, puede realizar tareas administrativas en el pod. Para ver la versión del software que ejecuta actualmente un pod, seleccione Configuración > Capacidad y haga clic en el pod para abrir su página de resumen. La página muestra la versión del software que se está ejecutando en este momento.

  • Después de una actualización del pod, asegúrese de que los agentes de todas las imágenes, las granjas y las asignaciones de VDI existentes estén actualizados a la versión disponible más reciente. Si los agentes instalados de esas máquinas virtuales no se actualizan, el pod tendrá una configuración no compatible. El proceso de mantenimiento no actualiza automáticamente esos agentes instalados. Si ve algún punto azul en la consola para sus imágenes o asignaciones, significa que es necesario actualizar los agentes. Actualizaciones de pods de Horizon Cloud: pasos para obtener compatibilidad y soporte continuados con los agentes.
  • Si esta actualización se realizó desde un manifiesto anterior al manifiesto 3328, después de actualizar el pod, asegúrese de agregar a las reglas de firewall todas las direcciones IP de las NIC creadas por el implementador que se encuentran en el grupo de recursos del pod. Es posible que las reglas de firewall existentes rijan el tráfico desde las direcciones IP de las NIC de las máquinas virtuales del administrador de pods. Para que la comunicación del tráfico funcione después de esta actualización del pod (y las actualizaciones posteriores) tal como funcionaba antes de ella, debe asegurarse de que las 8 direcciones IP reservadas por las NIC en el grupo de recursos del pod se reflejen en las reglas de firewall después de la actualización.
  • Si el servidor de autenticación en dos fases configurado está implementado en la misma red virtual, tras la actividad de mantenimiento, deberá actualizar la configuración del servidor de autenticación en dos fases para aceptar las nuevas direcciones IP privadas de las nuevas máquinas virtuales internas de Unified Access Gateway. Este es un requisito único para la primera actualización en el pod y no es necesario que se repita para las actualizaciones futuras del pod. Consulte Actualizar el sistema de autenticación en dos fases con la información requerida de puerta de enlace.
  • A partir de la versión de servicio trimestral de septiembre de 2019, la arquitectura del pod se actualiza para admitir la capacidad de tener alta disponibilidad (high availability, HA). Incluso cuando la función de alta disponibilidad no está habilitada, la nueva arquitectura compatible con HA incluye un equilibrador de carga de Microsoft Azure delante de la máquina virtual del administrador del pod. Después de actualizar el pod al manifiesto 1600, y si el pod se configuró para conexiones directas, debe volver a asignar la configuración de DNS para que apunte a la nueva dirección IP del equilibrador de carga Azure del administrador de pods que se mostrará en la página de detalles del pod actualizado. Hasta que actualice la asignación de DNS (a pesar de que esas conexiones directas de usuario seguirán funcionando), si la máquina virtual activa del administrador de pods se queda sin servicio, dichas conexiones no incluirán la conmutación por error de alta disponibilidad que un pod compatible con HA está diseñado para proporcionar. Para este caso de uso, debe asignar un FQDN a la dirección IP en el campo Dirección IP del equilibrador de carga del administrador de pods que se muestra en la página de detalles del pod, como se describe en Configurar certificados SSL directamente en las máquinas virtuales del administrador de pods, como cuando se integra el dispositivo de Workspace ONE Access Connector con el pod de Horizon Cloud en Microsoft Azure, para que Connector pueda confiar en las conexiones con las máquinas virtuales del administrador de pods. Antes de este manifiesto del pod 1600, esa dirección IP era la que se asignaba a la NIC de la máquina virtual del administrador del pod en la subred de arrendatario. A partir del manifiesto del pod 1600 o versiones posteriores, la dirección IP del pod que se asignará es la dirección IP privada del equilibrador de carga de Microsoft Azure que se utiliza para las máquinas virtuales del administrador de pods. Para los pods existentes que se actualizaron a la versión de manifiesto de esta versión, si configuró un nombre DNS para que apunte a la dirección IP del dispositivo arrendatario de un pod con el manifiesto 1493.1 o anterior, debe volver a asignar la configuración de DNS para que apunte a la nueva dirección IP que aparece para la etiqueta Dirección IP del equilibrador de carga del administrador de pods en la página de detalles del pod.
  • Antes del manifiesto de 2474.x, el sistema no comprobaba la desviación del reloj de los servidores de Active Directory registrados. Con 2474.x, se introdujo una comprobación del sesgo de reloj. Si los servidores registrados de Active Directory tienen en este momento algún problema de sincronización de hora (clockSkew > 4 minutes), cuando se actualice el manifiesto a la versión 2474.x u otra posterior en el pod, esta validación del sistema se iniciará en ese pod. Como resultado, hasta que solucione el problema de la desviación del reloj, es posible que se produzcan errores en la detección de servidores de Active Directory, que afectarán a las solicitudes de conexión de escritorio de los usuarios finales a ese pod.