A continuación se muestra una lista de nivel general de los pasos necesarios al llegar al primer pod conectado a la nube mediante la ejecución del implementador de pods para implementar un pod basado en el administrador de pods en la suscripción de Microsoft Azure. Este tipo de pod se basa en la tecnología del administrador de pods de VMware Horizon Cloud (a diferencia de un pod de Horizon basado en componentes de software de Horizon Connection Server). Después de que el primer pod conectado a la nube se haya implementado por completo y el usuario haya completado los pasos para registrar Horizon Cloud con el dominio de Active Directory previsto del pod, se pueden utilizar todas las funciones proporcionadas por Horizon Cloud, especialmente para aprovisionar escritorios VDI de sesión única, escritorios multisesión, escritorios de sesión basados en RDSH o aplicaciones remotas basadas a los usuarios finales desde ese pod. Cuando la cuenta de cliente está configurada para usar funciones de App Volumes con los pods en Microsoft Azure, también se pueden aprovisionar aplicaciones desde dichas funciones de App Volumes y autorizarlas a los usuarios finales.

Importante: Este flujo de trabajo a continuación no se puede aplicar a un pod de Horizon en la solución de VMware en Azure (AVS). Un pod de Horizon en AVS es un pod de Horizon en VMware SDDC, ya que AVS es un clúster de vSphere, como se describe en la documentación de Microsoft Tutorial: Implementación de una nube privada de Azure VMware Solution en Azure, y un clúster de vSphere es un VMware SDDC según la definición de VMware SDDC (centro de datos definido por software). Los siguientes artículos de la zona tecnológica proporcionan detalles sobre un pod de Horizon en AVS: Configuración de Horizon en la solución de VMware en Azure y Arquitectura de Horizon en la solución de VMware en Azure.
Importante: La consola administrativa es dinámica y refleja los elementos disponibles en el nivel de servicio actual. Sin embargo, cuando existen pods conectados a la nube que aún no están actualizados con sus niveles de software más recientes, la consola no muestra las funciones que dependen de dichos niveles. Además, en una versión concreta, Horizon Cloud puede incluir características con licencia por separado o características que solo están disponibles para configuraciones de cuentas de arrendatario específicas. La consola solo refleja de forma dinámica los elementos relacionados con estas funciones cuando la licencia o la configuración de cuenta de arrendatario permiten utilizarlas. Para ver ejemplos, consulte Recorrido por la consola basada en la nube utilizada para realizar tareas administrativas en Horizon Cloud.

Si no ve en la consola administrativa una función que, en su opinión, debería ver, póngase en contacto con su representante de cuenta de VMware para verificar si su licencia y su configuración de cuenta de arrendatario permiten el uso de dicha función.

Lleve a cabo los siguientes pasos cuando implemente su primer pod conectado a la nube y esté utilizando el asistente de implementación de pods en Horizon Universal Console para implementar el pod en Microsoft Azure.

  1. Complete los requisitos previos. Consulte Lista de comprobación de requisitos de VMware Horizon Cloud Service on Microsoft Azure para uso con nuevas implementaciones de pods.
  2. Realice las tareas de preparación fuera de Horizon Cloud. Consulte Preparar la implementación de un pod de Horizon Cloud en Microsoft Azure.
  3. Compruebe que cumple con los requisitos de DNS, puertos y protocolos para la implementación del pod. Consulte Requisitos de DNS para un pod de Horizon Cloud en Microsoft Azure y Requisitos de puertos y protocolos para un pod de Horizon Cloud en el manifiesto de la versión 2019 de septiembre o una versión posterior.
  4. Implementar el pod.
  5. Registrar su dominio de Active Directory en el pod implementado, lo que incluye proporcionar el nombre de las cuentas de servicio. Asegúrese de que estas cuentas de servicio cumplan con los requisitos descritos en Cuentas de servicio que requiere Horizon Cloud para sus operaciones
  6. Asigne las funciones adecuadas a las personas de la organización para autenticarse en la consola administrativa y realizar operaciones en ella. Existen dos tipos de funciones que se utilizan en Horizon Cloud. Consulte Prácticas recomendadas sobre los dos tipos de funciones que se conceden a los usuarios para que usen la consola basada en la nube para trabajar en su entorno de Horizon Cloud.
  7. En el muy improbable caso de que el entorno de arrendatario ya tenga pods de Horizon Cloud en Microsoft Azure que ejecutan manifiestos anteriores a la versión de manifiesto 1600.0, debe dar la función de superadministrador de Horizon Cloud a un grupo de Active Directory que incluya la cuenta de unión al dominio como miembro. Consulte el tema Asignar funciones administrativas de Horizon Cloud a grupos de Active Directory en la Guía de administración.
  8. Seleccione el tipo de brokering que desea que utilicen los pods del arrendatario en el brokering de los recursos aprovisionados por el pod para los usuarios finales. Consulte el tema de Introducción al Universal Broker de Horizon y el brokering de pod único y los temas y subtemas relacionados.
    Atención: Se recomienda completar este paso de selección de brokering antes de implementar pods adicionales en Microsoft Azure.
  9. Cree los registros CNAME necesarios en el servidor DNS. Para obtener información sobre la finalidad de estos CNAME, consulte Cómo obtener la información del equilibrador de carga de puerta de enlace del pod de Horizon Cloud para asignarlo en el servidor DNS. Cuando el arrendatario esté configurado con Universal Broker, consulte también los requisitos de registro de CNAME incluidos en Configurar los ajustes de Universal Broker.
    Nota: Cuando la configuración de la puerta de enlace externa utiliza una dirección IP privada para el equilibrador de carga de Azure de la configuración, debe tener un firewall o una NAT que administre el tráfico de Internet a la dirección IP privada, y el firewall o la NAT deben proporcionar una dirección IP pública y configurarse de modo que el FQDN especificado al implementar la configuración de la puerta de enlace externa se pueda resolver públicamente. El plano de control de Horizon Cloud debe poder comunicarse con el FQDN especificado para la puerta de enlace externa.
  10. En relación con el paso anterior, si selecciona la configuración del agente de pod único en ese paso anterior y tiene pensado utilizar Workspace ONE Access con el pod, siga estos pasos:
    • En el servidor DNS, asigne un nombre de dominio completo (FQDN) a la dirección IP del equilibrador de carga de Microsoft Azure del administrador de pods
    • Obtenga un certificado SSL basado en ese FQDN asignado.

    Se cargará un certificado SSL en el pod basado en el FQDN que se haya asignado a la dirección IP del equilibrador de carga de Microsoft Azure del administrador de pods en su DNS, de modo que las conexiones que vayan a las máquinas virtuales del administrador de pods establecerán conexiones de confianza. La instancia de Workspace ONE Access Connector que se utiliza al integrar Workspace ONE Access con el pod en una configuración de agente de pod único debe establecer dicha conexión de confianza. Workspace ONE Access Connector debe conectarse al pod mediante un FQDN que esté asignado a la dirección IP del equilibrador de carga de Microsoft Azure del administrador de pods.

    Atención: Cuando el entorno se configura para brokering de pod único y se integra Workspace ONE Access con el pod, debe cargar un certificado SSL en el pod y configurar Workspace ONE Access Connector para que señale al pod, no a las configuraciones de Unified Gateway Access del pod.

    Sin embargo, tenga en cuenta que, cuando se carga un certificado SSL basado en el FQDN asignado por DNS, si se intenta conectar directamente con ese FQDN en un navegador (no está configurando correctamente Workspace ONE Access), el uso de FQDN puro aparecerá como conexiones que no son de confianza en el navegador. La razón es que la carga de ese FQDN en un navegador es una conexión que utiliza HTML Access (Blaster) y que este es el comportamiento de HTML Access (Blaster). Como resultado, cuando se carga el FQDN en un navegador, muestra el error típico de certificado que no es de confianza.

    Al no tener Workspace ONE Access en este tipo de configuración, para que las conexiones que utilizan HTML Access (Blaster) —básicamente con un navegador— eviten mostrar el error de certificado que no es de confianza, debe colocar una configuración de puerta de enlace en el pod y hacer que las conexiones utilicen el equilibrador de carga y las instancias de Unified Access Gateway de la configuración de esa puerta de enlace. Si no desea que su FQDN se exponga en Internet, puede implementar una configuración interna de Unified Access Gateway. La configuración interna de Unified Access Gateway utiliza un equilibrador de carga interno de Microsoft Azure en el cual pueden realizar sus conexiones los usuarios finales que son internos de la red corporativa.

  11. Si espera que se dé uno de los casos prácticos descritos en el paso anterior (o los dos), cargue un certificado SSL para el pod directamente desde su correspondiente página de resumen en la consola administrativa. Consulte Configurar certificados SSL en las máquinas virtuales del administrador de pods de Horizon Cloud.
    Sugerencia: Si el único caso práctico de acceso que desea admitir es que las conexiones vayan a las instancias de Unified Access Gateway del pod a través del equilibrador de carga conectado a las instancias, cargar el certificado SSL directamente en el pod resulta superfluo. Sin embargo, se recomienda realizar tanto el paso inmediatamente anterior como este, porque así se garantiza que, si en algún momento proporciona el FQDN a los usuarios para que accedan a sus instancias de Horizon Clients, estos clientes tendrán conexiones de confianza. Al realizar estos dos pasos, también tiene la posibilidad de integrar más rápidamente en un futuro el pod en un entorno de agente de pod único con Workspace ONE Access, porque el FQDN ya queda asignado y el certificado SSL colocado en el pod.
  12. Opcional: Si la cuenta de arrendatario de Horizon Cloud aún no está incorporada con la plataforma de contratación de VMware Cloud Services, considere la posibilidad de incorporarla ahora. La incorporación a la plataforma de contratación de VMware Cloud Services es un requisito previo para activar las funciones de Supervisión de la infraestructura de Horizon para los pods implementados en Microsoft Azure. Consulte Incorporar el arrendatario de Horizon Cloud a VMware Cloud Services mediante la consola basada en la nube.
  13. Opcional: Active Supervisión de la infraestructura de Horizon. Un requisito previo a esta activación es que el arrendatario de Horizon Cloud debe incorporarse a la plataforma de contratación de VMware Cloud Services. Consulte Supervisión de la infraestructura de Horizon y los pods del entorno de Horizon Cloud.
  14. Cree una imagen maestra. La creación de una imagen maestra es un proceso de varios pasos. Para obtener una descripción de nivel general sobre las diversas formas de crear una imagen maestra que se pueda utilizar en el arrendatario de Horizon Cloud, consulte Crear imágenes de escritorio para un pod de Horizon Cloud en Microsoft Azure. La creación de una imagen maestra comienza con la importación de una máquina virtual base, que luego se personaliza según las necesidades empresariales y de los usuarios finales.
  15. Según el tipo de asignación de usuario final para la cual se utilizará finalmente la imagen, realice uno o varios de los siguientes pasos, según corresponda.
  16. Convierta esa imagen en una imagen asignable, también conocida como sellado o publicación de la imagen. Consulte Convertir una máquina virtual de imagen configurada en una imagen asignable.
  17. Para aprovisionar aplicaciones remotas y escritorios de sesión desde una imagen multisesión publicada:
    1. Cree una granja de escritorios para proporcionar escritorios de sesión y, a continuación, cree asignaciones para autorizar a los usuarios finales a utilizar dichos escritorios. Consulte Crear una granja y Crear una asignación de escritorios de sesión RDSH.
    2. Cree una granja de aplicaciones para proporcionar aplicaciones remotas, agregue las aplicaciones al inventario de aplicaciones y, a continuación, cree asignaciones para autorizar a los usuarios finales a utilizar dichas aplicaciones remotas. Consulte Crear una granja, Importar nuevas aplicaciones remotas desde una granja RDSH y Crear una asignación de aplicación remota.
  18. Para aprovisionar escritorios VDI de sesión única desde una imagen de escritorio VDI de sesión única publicada, cree una asignación de escritorios VDI dedicados o flotantes. Consulte Acerca de las asignaciones de escritorios para los pods del entorno de Horizon Cloud en Microsoft Azure y su sección acerca de la creación de estas asignaciones de escritorio.
  19. Para aprovisionar aplicaciones App Volumes a los usuarios finales, agregue las aplicaciones App Volumes al inventario de aplicaciones y cree una asignación de aplicaciones para autorizar a los usuarios finales a utilizar dichas aplicaciones. A continuación, cree una asignación de escritorios para que esos usuarios finales puedan utilizar los escritorios base en los que puedan usar dichas aplicaciones. La asignación de aplicaciones autoriza el uso de las aplicaciones App Volumes autorizadas del usuario en el sistema operativo Windows del escritorio autorizado del usuario. Consulte Aplicaciones App Volumes: información general y requisitos previos.
  20. Cuando se implementa un pod de modo que tenga una autenticación en dos fases RADIUS para las puertas de enlace del pod, debe completar las siguientes tareas:
    • Si configuró una puerta de enlace externa con la configuración de RADIUS y no se puede acceder a ese servidor RADIUS en la misma VNet que utiliza el pod, o dentro de la topología de VNet emparejada si implementó la puerta de enlace externa en su propia VNet, compruebe y configure que el servidor RADIUS permita las conexiones de cliente desde la dirección IP del equilibrador de carga de la puerta de enlace externa. En una configuración de puerta de enlace externa, las instancias de Unified Access Gateway intentan ponerse en contacto con el servidor RADIUS mediante la dirección del equilibrador de carga. Para permitir estas conexiones, asegúrese de que la dirección IP del recurso del equilibrador de carga que se encuentra en el grupo de recursos de la puerta de enlace externa esté especificada como un cliente en la configuración del servidor RADIUS.
    • Si configuró una puerta de enlace interna, o una puerta de enlace externa, y se puede acceder al servidor RADIUS en la misma VNet que utiliza el pod, configure el servidor RADIUS para permitir las conexiones desde las NIC correspondientes que se crearon en el grupo de recursos de la puerta de enlace en Microsoft Azure y que deben comunicarse con el servidor RADIUS. El administrador de red determina la visibilidad de red del servidor RADIUS en las subredes y la red virtual de Azure del pod. El servidor RADIUS debe permitir conexiones de cliente desde las direcciones IP de las NIC de puerta de enlace que correspondan a la subred para la cual el administrador de red haya otorgado visibilidad de red en el servidor RADIUS. El grupo de recursos de la puerta de enlace en Microsoft Azure tiene cuatro NIC que corresponden a esa subred: dos que están activas actualmente para las dos instancias de Unified Access Gateway, y dos que están inactivas y se convertirán en las instancias activas después de que se actualice el pod. Si desea permitir la conectividad entre la puerta de enlace y el servidor RADIUS para las operaciones del pod en curso y después de cada actualización del pod, asegúrese de que las direcciones IP de esas cuatro NIC estén especificadas como clientes en la configuración del servidor RADIUS.

    Para obtener información sobre cómo obtener esas direcciones IP, consulte Actualizar el sistema RADIUS con la información requerida de puerta de enlace del pod de Horizon Cloud.

Después de que se hayan completado los pasos de flujo de trabajo anteriores, los usuarios finales pueden utilizar Horizon Client o Horizon HTML Access (el cliente web) para iniciar sus escritorios y aplicaciones remotas autorizados:

  • En un entorno configurado con Universal Broker, utilizando el FQDN de brokering de Universal Broker en el cliente.
  • En un entorno configurado con brokering de pod único, utilizando el FQDN en su cliente, el que se asignó con los registros CNAME en el DNS.

Puede encontrar información detallada sobre cómo realizar cada paso del flujo de trabajo en los temas que están vinculados desde cada paso anterior.