Utilice la información de esta página junto con las Novedades de las Notas de la versión. Además de los elementos que aparecen en el documento de Notas de la versión, esta página está destinada a los usuarios que ya tenían pods conectados a la nube incorporados en su entorno antes de la fecha de actualización de servicio de octubre de 2020 o tienen experiencia previa con funciones y flujos de trabajo de Horizon Cloud. Esta página describe la importancia que las nuevas funciones y cambios pueden tener para el usuario y estos pods. Solo se describen los cambios significativos en las funciones y los flujos de trabajo. Los cambios menores, como los diseños nuevos y los esquemas de color de la consola administrativa que no cambian significativamente los flujos de trabajo, no se detallan aquí.

Para ver la información actualizada sobre los distintos flujos de trabajo que se realizan en el entorno de arrendatario de Horizon Cloud, lea los temas de la documentación que se encuentran en las guías individuales vinculadas desde la página de documentación de Horizon Cloud Service.

Importante: Para obtener más información sobre los términos que se utilizan en esta página, consulte la información del documento de Notas de la versión antes de leer la información de esta página. El documento de Notas de la versión tiene información relevante clave, como el número de manifiesto del pod más reciente para los pods que se implementan en Microsoft Azure. Tenga en cuenta también que las cuestiones clave que se describen en la siguiente sección se aplican en cada versión de Horizon Cloud.

Las siguientes secciones retroceden a septiembre de 2019. No se puede publicar información similar para versiones anteriores.

Cinco cuestiones clave sobre cada versión de Horizon Cloud

  • Todas las nuevas funciones basadas en el plano de nube que no dependen del nivel de versión del manifiesto del pod, del nivel de versión de Horizon Cloud Connector, del nivel de versión del pod de Horizon ni de las diferencias regionales del plano de control se proporcionan automáticamente tanto para clientes existentes como para clientes nuevos. A modo de ejemplo, los clientes existente podrán ver y aprovechar una nueva función que no dependa de las nuevas API para las llamadas de API entre el plano de nube y los pods o una función que esté relacionada con Horizon Cloud Connector, a menos que se indique lo contrario a continuación o en las guías de producto. Para ilustrar este punto, una de estas funciones es el envío de comentarios mejorado de la consola. A pesar de que este icono de comentarios se publicó el 9 de julio de 2020, el icono y el flujo están disponibles para su uso por parte de los entornos de arrendatario que ya existían antes del 9 de julio de 2020, incluso antes de actualizar los pods o Horizon Cloud Connector a sus versiones más recientes.
  • A partir del día en que se publica la versión del manifiesto en el plano de control de nube, el implementador de pods para Microsoft Azure siempre implementa los pods de la versión más reciente del manifiesto del pod.
  • Los pods ya implementados que existen en el arrendatario de servicio antes del día en el que la versión del nuevo manifiesto del pod se publica en el plano de nube, seguirán ejecutándose en su versión de manifiesto existente hasta que se actualicen al manifiesto que sea nuevo para la versión. Se aplican las cuestiones siguientes:
    • Las nuevas funciones de servicio sin dependencias en las API que requieran el nivel de manifiesto más reciente estarán disponibles para los pods existentes.
    • Las funciones de servicio nuevas que dependan de las API en el nivel de manifiesto más reciente no estarán disponibles para los pods existentes hasta que se actualicen esos pods.
    • Algunas características de servicio nuevas pueden depender de la región del plano de nube en la que se encuentra la cuenta del arrendatario. Estas funciones se indican en la documentación, donde corresponda. La región del plano de control se indica en el correo electrónico de bienvenida a Horizon Service que se envía cuando se crea la cuenta del cliente, como se describe en Incorporación a Horizon Cloud para Microsoft Azure, Horizon local y Horizon on VMware Cloud on AWS.
  • El asistente Importar máquina virtual - Catálogo de soluciones de la consola utiliza la instancia de Horizon Agents Installer (HAI) integrada en el manifiesto del pod. Como resultado, los pods implementados en la versión de manifiesto más reciente tendrán el HAI más reciente integrado y, si se ejecuta el asistente Importar máquina virtual y se selecciona un pod en el nivel más reciente, se instalarán los agentes del HAI más reciente. Para los pods que aún no se han actualizado al nivel de manifiesto más reciente, el asistente Importar máquina virtual - Catálogo de soluciones utiliza la versión de HAI que estaba disponible cuando se integraron sus respectivos manifiestos de pod.
  • Los pods de Horizon se incorporan a Horizon Cloud para dos casos prácticos principales: activar el uso de una licencia de suscripción con esos pods y habilitar el uso de servicios alojados en la nube que Horizon Cloud proporciona a los pods de Horizon. Cada pod se incorpora mediante Horizon Cloud Connector. El origen de la incorporación de pods de Horizon a Horizon Cloud comenzó con los entornos de Horizon 7 versión 7.6 y Horizon Cloud Connector versión 1.0 para activar las licencias de suscripción en pods de Horizon. Posteriormente, con cada nueva versión de Horizon combinada con una nueva versión de Horizon Cloud Connector, los servicios adicionales alojados en la nube quedarán disponibles para pods de Horizon conectados a la nube que ejecutan la versión más reciente de Horizon emparejada con la versión más reciente de Horizon Cloud Connector. Recomendamos a los clientes que tengan versiones anteriores de Horizon Cloud Connector que actualicen a esta última versión para aprovechar las nuevas funciones, así como las correcciones de seguridad y resistencia. Además, consulte la herramienta de Matrices de interoperabilidad de productos de VMware para obtener la matriz de versiones compatibles actualmente del software de pods de Horizon con Horizon Cloud Connector. Si está ejecutando una combinación de versiones de Servidor de conexión de Horizon y de Horizon Cloud Connector que ya no coincide con esa matriz, actualice lo antes posible a una combinación admitida.

Octubre de 2020 - v2010

Use la siguiente información cuando sea un cliente existente con pods conectados a la nube desde antes de octubre de 2020 y desee comprender los efectos en su experiencia a partir de las funciones que se describen en las Notas de la versión nuevas de octubre de 2020.

Las nuevas versiones de los siguientes archivos binarios importantes se han publicado en octubre de 2020: una nueva versión de manifiesto del pod para pods implementados por el servicio, nuevas versiones de Horizon Cloud Connector, Universal Broker Plugin Installer y Horizon Agents Installer (HAI).

Esta lista se basa en los elementos que aparecen en la sección Novedades de octubre de 2020 de la página de Notas de la versión.

Elementos nuevos relacionados con Horizon Cloud Connector y su uso con pods de Horizon
  • la versión 1.8 de Horizon Cloud Connector se publica en los formatos OVA y VHD.
  • Horizon Cloud Connector 1.8 ofrece la posibilidad de seleccionar un perfil de implementación para habilitarlo únicamente con el soporte de licencias de suscripción o con funciones de Horizon Cloud. Esta selección se realiza durante la implementación del dispositivo.
  • Horizon Cloud Connector ahora es compatible con pods de Horizon que se implementan en la Solución de Azure VMware (AVS). Actualmente, esta compatibilidad sirve para utilizar la licencia de suscripción con esas implementaciones. Aún no se proporciona el conjunto completo de servicios alojados en la nube para estos tipos de implementación.
Nuevos elementos relacionados con los pods implementados por el servicio en Microsoft Azure
Los pods de Horizon Cloud on Microsoft Azure ahora admiten la posibilidad de especificar etiquetas de recursos de Azure personalizadas durante una implementación de pod o una implementación de puerta de enlace. El implementador de pods aplica las etiquetas especificadas en los grupos de recursos que crea el implementador de pods. Para obtener una descripción de los grupos de recursos que crea el implementador de pods, consulte Grupos de recursos creados para un pod implementado en Microsoft Azure. Esta nueva función no depende de la versión de manifiesto del pod.

Julio de 2020 - v3.1

Use la siguiente información cuando tenga pods conectados a la nube desde antes de julio de 2020 y desee comprender los efectos en su experiencia a partir de las funciones que se describen en las Notas de la versión nuevas de julio de 2020.

Específico para pods de Horizon existentes conectados a la nube
Publicación de Horizon Cloud Connector 1.7. Para sus funciones, consulte la sección Novedades de las Notas de la versión de julio de 2020.
Específico para pods existentes en Microsoft Azure
Para las nuevas funciones que se describen en la sección Novedades del documento de Notas de la versión de julio de 2020 que se va a utilizar con un pod existente, primero debe actualizar el pod a la versión de manifiesto 2298.0 o una versión posterior, para aprovechar la función.
  • Varias subredes de arrendatarios para usar con granjas y asignaciones de escritorios VDI. Esta función aún no está disponible para su uso con asignaciones de escritorios de varias nubes, que se utilizan en un arrendatario configurado con Universal Broker.
  • Uso del equilibrio de carga de sesiones avanzadas para granjas RDSH.
  • Capacidad de cancelar las tareas de expansión de granjas y escritorios que se encuentran en cola o en estado de ejecución, y admiten la asignación automática de escritorios y el cambio de tamaño de granja. Esta función aún no está disponible para su uso con asignaciones de escritorios de varias nubes, que se utilizan en un arrendatario configurado con Universal Broker.
  • Para mejorar los tiempos de inicio de sesión de los usuarios finales, se ha reducido el tiempo que tarda una máquina virtual en llegar al estado listo para el agente en máquinas virtuales de escritorio aprovisionadas por el pod que están apagadas y que deben encenderse para satisfacer la solicitud de un usuario final de un escritorio.
  • Uso de las funciones de App Volumes: los pods deben actualizarse a la versión actual del manifiesto, y la cuenta de cliente debe estar ubicada en una de las siguientes regiones de plano de control de Horizon Cloud: USA-2 (PROD1_NORTHCENTRALUS2_CP1), Europe-2 (PROD1_NORTHEUROPE_CP1) o Australia-2 (PROD1_AUSTRALIAEAST_CP1). La región del plano de control se indica en el correo electrónico de bienvenida a Horizon Cloud Service.

Al implementar una configuración de puerta de enlace en el pod, además del tamaño de la máquina virtual Standard_A4_v2 en versiones anteriores, ahora tiene la opción de utilizar el tamaño de la máquina virtual Standard_F8s_v2, que proporciona más vCPU para cada instancia de Unified Access Gateway. Para los pods existentes, esta nueva función está disponible cuando se edita el pod para agregarle una nueva configuración de puerta de enlace.

Otros aspectos importantes para los clientes actuales
Ahora hay una mejora en el envío de comentarios de producto disponible en la barra de encabezado de la consola para todos los clientes existentes.

Los pods que pueden tener la función de alta disponibilidad ahora son compatibles con Microsoft Azure Government (US Gov Virginia, US Gov Arizona, US Gov Texas). Si tiene un pod existente en Microsoft Azure Government para el cual desea esta función, póngase en contacto con su representante de VMware para esa habilitación.

Marzo de 2020 - v3

Use la siguiente información cuando tenga pods conectados a la nube desde antes de marzo de 2020 y desee comprender los efectos en su experiencia a partir de las funciones que se describen en las Notas de la versión nuevas de marzo de 2020.

Específico para pods de Horizon existentes conectados a la nube
La publicación de Horizon Cloud Connector 1.6.x ofrece una herramienta de diagnóstico de línea de comandos, para que pueda comprobar el estado de los servicios y los componentes del sistema del pod de Horizon necesarios para que Horizon Cloud Connector empareje correctamente el pod con Horizon Cloud. Antes de iniciar sesión en el portal de configuración en línea y ejecutar el asistente de configuración de pods, puede ejecutar esta herramienta de diagnóstico para comprobar los elementos que podrían impedir un resultado correcto. Si se detectan problemas, la herramienta informará sobre el nombre del componente, los detalles y los pasos de corrección recomendados.
Específico para pods existentes en Microsoft Azure
Para las nuevas funciones que se describen en la sección Novedades del documento de Notas de la versión de marzo de 2020 que se va a utilizar con un pod existente, primero debe actualizar el pod a la versión de manifiesto 1976.0 o una versión posterior, para aprovechar la función, a menos que se indique de otro modo.
  • Para admitir configuraciones de implementación avanzadas, cuando se utiliza una suscripción independiente para la configuración de la instancia de Unified Access Gateway externa, se puede optar por implementar los recursos de Unified Access Gateway en un el grupo de recursos existente creado por el cliente, en lugar del predeterminado creado por el implementador de pods. Para que un pod existente aproveche esta función nueva, es necesario actualizar antes el pod a una versión de manifiesto 1763 o posterior (el manifiesto de diciembre de 2019). A continuación, debe cumplir todos los requisitos documentados para usar independientemente una suscripción, una red virtual y un grupo de recursos personalizado para la configuración de la puerta de enlace externa, incluido el emparejamiento de la red virtual con la red virtual del pod y la creación del grupo de recursos en la suscripción. A continuación, debe eliminar la configuración de Unified Access Gateway externa existente del pod mediante el flujo de trabajo de la consola para eliminar esa puerta de enlace externa existente. Cuando la eliminación se haya completado correctamente, puede ejecutar el flujo de trabajo Editar pod para agregar la puerta de enlace externa con la nueva opción para colocar la instancia externa de Unified Access Gateway en el grupo de recursos existente.
  • Compatibilidad para que los administradores especifiquen que los nombres de las asignaciones de escritorios VDI dedicados se muestren en los clientes de usuario final después de que se asigne una máquina virtual de escritorio VDI al usuario final, en lugar de mostrar el nombre de la máquina virtual de escritorio. Anteriormente, cuando un usuario final reclamaba una máquina virtual de escritorio VDI específica, su cliente mostraba el nombre de la máquina virtual de escritorio de forma predeterminada y no se podía configurar ese comportamiento. Esta opción no cambia lo que se muestra para las conexiones de los usuarios finales que pasan a través de Workspace ONE Access. Workspace ONE Access siempre muestra el nombre de la asignación de escritorios VDI dedicados y, cuando el usuario final inicia la máquina virtual de escritorio desde Workspace ONE Access, el nombre del escritorio se muestra en el cliente de usuario final. A pesar de que verá la opción de esta función en la página Configuración general, un pod debe estar ejecutando la versión de manifiesto 1976.0 o una versión posterior para poder beneficiarse de esta función.
  • El manifiesto del pod 1976.0 o una versión posterior permite a los administradores colocar una máquina virtual de granja individual en modo de mantenimiento, para que el administrador pueda realizar acciones de mantenimiento en la máquina virtual. Antes de poder aprovechar esta función para establecer un modo de mantenimiento por máquina virtual, el pod debe ejecutar la versión de manifiesto de esta versión. Además, debido a un problema conocido en la consola, aunque se muestren las opciones de esta función en la pestaña Servidores de la granja en la consola, estas opciones de interfaz de usuario no establecerán el modo hasta que los agentes de las máquinas virtuales de la granja ejecuten la versión 20.1.0 o una versión posterior.
Otros aspectos importantes para los clientes actuales
Mejoras en los informes disponibles en la página Informes y la página Panel de información de la consola. Cloud Monitoring Service proporciona los datos de estos informes. Los pods existentes pueden beneficiarse de esta función.

Diciembre de 2019 -v2.2

Use la siguiente información cuando tenga pods conectados a la nube desde antes de diciembre de 2019 y desee comprender los efectos en su experiencia a partir de las funciones que se describen en las Notas de la versión nuevas de diciembre de 2019.

Específico para pods de Horizon existentes conectados a la nube
A partir de esta versión:
  • Algunos elementos que se encuentran bajo el control del usuario pueden impedir una actualización automática correcta de Cloud Connector, como un espacio insuficiente en el almacén de datos en el entorno de vCenter para acomodar la actualización. A partir de esta versión, si está habilitada la actualización automatizada para la cuenta de arrendatario de Horizon Cloud, estos elementos se identifican en la consola para que pueda resolver y borrar esos elementos.
  • Las actualizaciones automatizadas de Horizon Cloud Connector ya son compatibles con los pods de Horizon implementados en VMware Cloud on AWS.
  • Las mejoras en la pantalla de incorporación correcta de Horizon Cloud Connector incluyen una pantalla de estado de mantenimiento para los componentes de Cloud Connector y una opción para activar y desactivar SSH en el dispositivo de Horizon Cloud Connector.
Específico para pods existentes en Microsoft Azure
Para las nuevas funciones que se describen en la sección Novedades del documento de Notas de la versión de diciembre de 2019 que se va a utilizar con un pod existente, primero debe actualizar el pod a la versión de manifiesto 1763.0 o una versión posterior, para aprovechar la función, a menos que se indique de otro modo.
  • Para admitir configuraciones de implementación avanzadas, el implementador de pods proporciona opciones para:
    • Usar una VNet independiente para las instancias de Unified Access Gateway de la configuración de la puerta de enlace externa, independiente de la red virtual del pod y los elementos básicos del pod. Las redes virtuales deben estar emparejadas.
    • Usar una suscripción independiente para la configuración de la instancia de Unified Access Gateway externa, independiente de la suscripción utilizada para los elementos principales del pod. Dado que una VNet está dentro del ámbito de una suscripción, el escenario de implementación de una suscripción independiente también es el escenario de una VNet independiente. Las redes virtuales deben estar emparejadas.
    • Para que un pod existente saque partido de esta función, primero debe actualizarse el pod a la versión de manifiesto 1763.0 o una versión posterior. A continuación, debe cumplir todos los requisitos documentados para usar una VNet independiente para la configuración de la puerta de enlace externa, incluido el emparejamiento de la red virtual con la red virtual del pod. A continuación, debe eliminar la configuración de Unified Access Gateway externa existente del pod mediante el flujo de trabajo de la consola para eliminar esa puerta de enlace externa existente. Cuando la eliminación se haya completado correctamente, puede ejecutar el flujo de trabajo Editar pod para agregar de nuevo una puerta de enlace externa con las nuevas opciones.
  • A partir del manifiesto de esta versión, puede usar tipos de disco SSD para asignaciones de escritorios de VDI y granjas RDSH.
  • A partir del manifiesto de esta versión, puede personalizar los tamaños de disco del sistema operativo para asignaciones de escritorios de VDI y granjas RDSH. En los manifiestos de pods anteriores, los tamaños de disco del sistema operativo se establecían para ser iguales que los de la imagen base publicada, que era de 127 GB de forma predeterminada y no se podía cambiar.
  • Como novedad en esta versión, en el asistente para importar una máquina virtual desde el catálogo de soluciones, verá una opción que ofrece la posibilidad de omitir la unión de la máquina virtual resultante a un dominio de Active Directory. Anteriormente, este flujo de trabajo unía la máquina virtual al dominio de forma predeterminada y no se podía cambiar ese comportamiento. Esta nueva alternancia está disponible para pods existentes antes de la versión del manifiesto de esta versión.
  • Con el rediseño de la página Capacidad en esta versión, se elimina la vista Tipo. Con la eliminación de la vista Tipo de la página Capacidad, hay dos cambios que se deben tener en cuenta sobre elementos a los que antes se accedía desde esa vista: la acción para ver el uso actual por parte del pod de los límites de Microsoft Azure de su suscripción se ha movido a la página de detalles del pod, y la acción Quitar suscripción que estaba presente en esa vista se ha eliminado por completo.
Otros aspectos importantes para los clientes actuales
  • Mejoras en los informes disponibles en la página Informes de la consola administrativa. Cloud Monitoring Service proporciona los datos de estos informes.
  • Mejoras en la página Capacidad de la consola administrativa de Horizon Cloud. En lugar de tener que profundizar en la página de detalles de un pod para modificar los detalles configurables del pod o para eliminar un pod del entorno del arrendatario, ahora puede iniciar la edición del pod y eliminar los flujos de trabajo de pod desde la página Capacidad. Como resultado de este nuevo diseño, los flujos de trabajo para modificar la información de ubicación que se realizaban previamente mediante la vista Ubicación de la página Capacidad, ahora son opciones dentro de los flujos de trabajo de Editar pod. Por ejemplo, para especificar un nuevo nombre de ubicación, si utiliza la acción Editar en un pod, puede especificar un nuevo nombre de ubicación como opción para el flujo de trabajo Editar pod. Tenga en cuenta que el flujo de trabajo de la vista Ubicación anterior para eliminar la información de suscripción de Microsoft Azure guardada cuando todos los pods asociados a la suscripción se eliminaron ya no está disponible.
  • El producto anteriormente conocido bajo el nombre VMware Identity Manager™ ahora se denomina VMware Workspace ONE™ Access.
  • Horizon Agents Installer ya no instala un DaaS Agent inactivo. En la versión anterior, HAI instalaba el MSI de DaaS Agent en el sistema operativo invitado, pero estaba inactivo y no se usaba. En esta versión, el MSI no se instala de ningún modo.

Septiembre de 2019 - v2.1

Use la siguiente información cuando tenga pods conectados a la nube desde antes de septiembre de 2019 y desee comprender los efectos en su experiencia a partir de las funciones que se describen en las Notas de la versión nuevas de septiembre de 2019.

Específico para pods de Horizon existentes conectados a la nube
A partir de esta versión:
  • Ahora se admite la actualización automática en las versiones 1.3 y 1.4 de Cloud Connector. Se recomienda que los clientes de las versiones anteriores de Cloud Connector se actualicen a la versión más reciente para aprovechar esta función.
  • Servicios de supervisión en la nube (Cloud Monitoring Services, CMS) con detalles de uso de las sesiones se proporciona como parte de Horizon Cloud Service.
Específico para pods existentes en Microsoft Azure
Para las nuevas funciones que se describen en la sección Novedades del documento de Notas de la versión de septiembre de 2019 que se va a utilizar con un pod existente, primero debe actualizar el pod a la versión de manifiesto 1600.0 o una versión posterior, para aprovechar la función, a menos que se indique de otro modo.
  • La arquitectura del pod cambió en esta versión. Todos los pods de la versión de manifiesto de la versión de septiembre de 2019 tienen un equilibrador de carga de Microsoft Azure del pod y una instancia de servidor Microsoft Azure Database for PostgreSQL (nivel optimizado de memoria de generación 5). Esto significa que antes de actualizar los pods existentes a la versión de manifiesto de esta versión, debe asegurarse de que la configuración de red existente cumpla los requisitos de DNS, puertos y protocolos necesarios para acomodar el equilibrador de carga de Microsoft Azure del pod y la instancia de servidor Microsoft Azure Database for PostgreSQL. Si tiene firewalls o grupos de seguridad de red que bloquean puertos y protocolos específicos, compare la configuración de red actual con la información de los siguientes temas y actualice la configuración de redes según corresponda.
  • En esta versión se proporciona una alerta mejorada para los errores de actualización del pod que requieren acciones del cliente para resolverlos. Algunas cosas que están completamente bajo su control pueden impedir que un pod se actualice correctamente, como no tener suficientes núcleos en la suscripción asociada del pod para crear la máquina virtual de Jump Box que orquesta la actualización del pod. A partir de esta versión, estos elementos se identifican en la consola para que pueda resolverlos y eliminarlos.
  • A partir de esta versión, puede revisar las siguientes opciones relacionadas con la puerta de enlace en un pod ya implementado: agregar una configuración de autenticación en dos fases a una puerta de enlace que no tenga, editar la configuración de autenticación en dos fases de una puerta de enlace y cambiar la configuración de tiempo de espera de brokering de la puerta de enlace. En las versiones anteriores, era necesario configurar la autenticación en dos fases RADIUS la primera vez que se implementa el pod, y no se podía cambiar esa configuración posteriormente. Otra novedad en esta versión es que se pueden eliminar puertas de enlace de un pod ya implementado y se puede implementar un nuevo pod para que tenga una puerta de enlace externa sin una dirección IP pública en su equilibrador de carga de Azure y, en su lugar, tenga una dirección IP privada en dicho equilibrador de carga.
  • Compatibilidad con la definición de etiquetas de recursos de Microsoft Azure al crear una nueva asignación de escritorios VDI dedicados o flotante o una nueva granja para Horizon Cloud on Microsoft Azure.
  • La alta disponibilidad ahora está disponible. Para admitir la alta disponibilidad en los pods en Microsoft Azure, la arquitectura del pod se actualizó para utilizar el servicio Microsoft Azure Database for PostgreSQL (nivel optimizado de memoria de generación 5 actualizado), un equilibrador de carga de Microsoft Azure y un conjunto de disponibilidad. Para un pod de nueva implementación en esta versión, tiene la opción de habilitar la alta disponibilidad para el pod en el momento de la implementación o puede habilitar la alta disponibilidad más adelante. Para los pods que ya existían antes de esta versión, antes de habilitarlos para alta disponibilidad, primero debe actualizarlos a la versión de manifiesto 1600.0 o una versión posterior y también actualizar los agentes en las imágenes, las granjas y las asignaciones de escritorios VDI de los pods a este nivel de versión. Una vez completadas las actualizaciones del pod y de los agentes, puede habilitar la alta disponibilidad en el pod editando su página de detalles en la consola administrativa. Esta nueva función conlleva requisitos adicionales para habilitar el endpoint del servicio Microsoft SQL en la subred de administración del pod cuando el pod utiliza subredes creadas personalmente y para permitir el acceso saliente para el puerto 5432.

    En septiembre de 2019, la función de alta disponibilidad (HA) para pods en Microsoft Azure solo es compatible con pods implementados en las regiones de Microsoft Azure Commercial (regiones mundiales estándar). La función de HA de pod no se admite actualmente para los pods implementados en Microsoft Azure China, Microsoft Azure Alemania y Microsoft Azure Government (US Gov Virginia, US Gov Arizona, US Gov Texas). El equipo de VMware está trabajando para agregar compatibilidad con la función de HA para pods en los entornos de nube indicados anteriormente. Si tiene un pod existente en Microsoft Azure en China, Microsoft Azure Alemania o Microsoft Azure Government que desea actualizar a la versión del manifiesto de esta versión sin HA, póngase en contacto con su representante de VMware para obtener asistencia.

    Antes de actualizar un pod existente en una de las regiones mundiales de Microsoft Azure estándar al manifiesto 1600 o una versión posterior, dado que la nueva arquitectura de pod utiliza el servicio de Microsoft Azure Database for PostgreSQL, debe asegurarse de que los siguientes elementos estén bien definidos:

  • Para aumentar la resiliencia del proceso de emparejamiento de Horizon Agent, esta versión aporta una mayor evolución de cómo mover las funciones de DaaS Agent a Horizon Agent. DaaS Agent se incorpora ahora a Horizon Agent. Aunque tanto el flujo de trabajo automatizado Importar imagen como la instalación manual de Horizon Agents Installer instalan el archivo MSI de DaaS Agent en el sistema operativo invitado del mismo modo que en las versiones anteriores, a partir de esta versión, DaaS Agent está inactivo y no se utiliza. Sin embargo, el servicio de DaaS Agent sigue apareciendo en la lista de servicios de Windows. No inicie ese servicio o podrían producirse resultados inesperados.
  • Al mover las funciones de DaaS Agent a Horizon View Agent, han cambiado tanto la importación automatizada de imágenes del flujo de trabajo de Azure Marketplace como los pasos para generar manualmente una máquina virtual base. Anteriormente, la máquina virtual base resultante del flujo de trabajo automatizado se emparejaba con la nube al final del flujo de trabajo, mientras que para una máquina virtual creada de forma manual, era necesario arrancar y emparejar manualmente la máquina virtual. Ahora, para las imágenes base de un pod nuevo o actualizado a esta versión, la máquina virtual base resultante aparece en la página Máquinas virtuales importadas con el estado de agente Sin emparejar. Para emparejar la máquina virtual, puede:
    • Ejecutar la acción Restablecer emparejamiento de agente en la máquina virtual que se muestra en la página Máquinas virtuales importadas, si desea emparejarla con la nube antes de personalizarla.
    • Ejecutar la acción Nueva imagen directamente en la máquina virtual, si la máquina virtual tiene todas las personalizaciones que desea y está listo para publicarla. En este caso, el flujo de trabajo Nueva imagen ejecutará primero el proceso de emparejamiento para activar el agente y, a continuación, el usuario podrá completar el resto de los campos y hacer clic en Publicar para publicar la imagen.
  • Al mover las funciones de DaaS Agent a Horizon View Agent, el flujo de trabajo Restablecer emparejamiento de agente ahora está disponible para su uso en máquinas virtuales importadas, máquinas virtuales de servidor de granja y máquinas virtuales de escritorio de asignaciones de escritorios VDI dedicados. En los detalles de la granja o de la asignación de escritorios VDI dedicados, si ve un estado de error en la columna Estado del agente para una máquina virtual de servidor de granja o de escritorio, puede usar la acción Restablecer emparejamiento de agente en la consola para reparar el estado de emparejamiento de esa máquina virtual. (La acción no está disponible para las asignaciones de escritorios VDI flotantes). En la página Máquinas virtuales importadas, puede usar la acción Restablecer emparejamiento de agente para emparejar inicialmente una máquina virtual que aún no se haya emparejado, o para reparar el estado de emparejamiento de una máquina virtual que emparejó anteriormente.
  • La función de cifrado de disco ahora utiliza la versión más reciente de AzureDiskEncryption v2.2. Esta versión más reciente permite el cifrado de disco para máquinas virtuales con un proxy en el invitado configurado para comunicarse con Internet. Para aprovechar esta nueva compatibilidad, actualice los agentes de las máquinas virtuales a la versión 19.3.0 o una versión posterior.
  • Se actualizaron las instrucciones para utilizar modelos de máquina virtual que tienen un mínimo de dos (2) CPU para las granjas y las asignaciones de escritorios VDI. Las pruebas a escala de VMware demostraron que, en entornos de producción, el uso de un mínimo de 2 CPU evita problemas de conexión de usuario final inesperados. A pesar de que el sistema no le impide elegir un modelo de máquina virtual con una sola CPU, debe utilizar esos modelos de máquina virtual solo para pruebas o pruebas de concepto.
  • Mejoras de uso en la página Tamaños y tipos de máquina virtual.
Otros aspectos importantes para los clientes actuales
  • Mejor facilidad de uso y optimización de la vista de mapas interactivos del panel unificado, incluido un reflejo más preciso de la ubicación del pod y la funcionalidad de zoom.
  • Mejoras en los informes disponibles en la página Informes de la consola administrativa. Cloud Monitoring Service proporciona los datos de estos informes.
  • Para los pods de Horizon 7 conectados a la nube, se muestran detalles adicionales en la página de detalles del pod. El pod y Cloud Connector deben tener la versión más reciente para poder ver esta función.
  • El producto anteriormente conocido bajo el nombre VMware User Environment Manager™ ahora se denomina VMware Dynamic Environment Manager™.