Utilice la siguiente información y los subtemas vinculados al prepararse para utilizar Horizon Cloud y durante su uso. Vuelva a consultar esta información mientras utilice Horizon Cloud.

Requisitos previos de configuración, Descargas de software, Persistencia de la configuración del usuario, Documentación del producto y Recursos útiles adicionales

Requisitos de configuración
Para las implementaciones de Microsoft Azure, revise los requisitos previos de configuración antes de iniciar la implementación.

Para las conexiones a los pods de Horizon, revise los requisitos previos de configuración antes de iniciar. Consulte los siguientes documentos:

Descargas de software
Revise las descargas de software que posiblemente quiera para el entorno de My VMware ®. A pesar de que es opcional realizar estas descargas antes de comenzar con la implementación, según su escenario de caso práctico, es posible que desee revisarlas antes de implementarlas. Consulte la página de descargas de VMware Horizon Cloud Service y vaya a los vínculos de descargas para esta versión específica de octubre de 2020. Dentro de esa misma página, verá la fila de Horizon Cloud Connector; en ella podrá hacer clic en Ir a descargas para obtener las versiones más recientes de Horizon Cloud Connector y el instalador del complemento de Universal Broker de VMware.
Persistencia de la configuración del usuario
Para todas las implementaciones de Microsoft Azure, se puede proporcionar persistencia de los perfiles de usuario mediante VMware Dynamic Environment Manager™ con redireccionamiento de carpetas. Puede descargar el software Dynamic Environment Manager admitido para usarse con esta versión desde la página de descargas de VMware Horizon Cloud Service y acceder a los vínculos de descargas para esta versión específica.
Documentación del producto y recursos útiles adicionales

Para acceder a toda la documentación del producto para los diversos modelos de implementación de Horizon Cloud, consulte la página de destino de la documentación de VMware Horizon Cloud Service.

Visite el sitio de la comunidad para ver sugerencias útiles y hacer preguntas. Los informes técnicos también están disponibles en la sección de recursos de la página de producto de Horizon Cloud.

Datos útiles a tener en cuenta antes de utilizar Horizon Cloud

Antes de realizar cualquier tipo de implementación
  • Cuando el entorno de Horizon Cloud no está integrado con el entorno de Workspace ONE, la autenticación de inicio de sesión en la consola administrativa basada en la nube y en web se basa en las credenciales de la cuenta de My VMware. Si el sistema de la cuenta de My VMware está experimentando una interrupción del sistema y no puede aceptar solicitudes de autenticación, no podrá iniciar sesión en la consola durante dicho período de tiempo. Si tiene algún problema al iniciar sesión en la primera pantalla de inicio de sesión de la consola, compruebe la página Estado del sistema de Horizon Cloud en https://status.horizon.vmware.com para ver el estado del sistema más reciente. En esa página, podrá suscribirse para recibir actualizaciones.
  • Cuando se implementa un pod mediante el asistente de implementación de pods de la consola y cuando se conecta un pod de Horizon a través de Horizon Cloud Connector, se debe poder acceder a los nombres de DNS específicos y se deben permitir puertos y protocolos específicos. Consulte Requisitos de DNS, puertos y protocolos cuando se utiliza Horizon Cloud Connector y un pod de Horizon, 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 de septiembre de 2019 o posterior para conocer los requisitos de conectividad.
  • Cada uno de los pods emparejado con el plano de control de Horizon Cloud y asociado con la misma cuenta de cliente debe tener una conexión directa con los dominios de Active Directory conectados a esos pods y tener configurada una confianza unidireccional o bidireccional junto con esa conexión directa. Por ejemplo, cuando tiene tres pods donde un pod está en Microsoft Azure, otro pod es local y el otro pod está en VMware Cloud on AWS, cada uno de dichos pods debe tener una conexión directa y configurada una confianza unidireccional o bidireccional en el mismo conjunto de dominios de Active Directory.
Antes de realizar implementaciones de Microsoft Azure
  • Suscripciones y número de pods: tenga en cuenta la cantidad de pods que implemente en una sola suscripción de Microsoft Azure, especialmente si tiene pensado que cada pod se ejecute a mayor escala. Aunque se pueden implementar varios pods en una sola suscripción a Microsoft Azure, ya sea en una sola región o en varias, Microsoft Azure impone ciertos límites dentro de una sola suscripción. Debido a los límites de Microsoft Azure, la implementación de muchos pods en una sola suscripción aumenta la probabilidad de alcanzar los límites. Numerosas variables, y combinaciones de estas variables, condicionan el alcance de dichos límites, como la cantidad de pods, la cantidad de granjas y asignaciones en cada pod, la cantidad de servidores en cada pod, la cantidad de escritorios en cada asignación, y así sucesivamente. Si tiene pensado que haya pods que se ejecuten a mayor escala, considere la posibilidad de contar con varias suscripciones en una sola cuenta de Microsoft Azure. Los clientes de Microsoft Azure pueden, y a menudo prefieren, este enfoque, ya que ofrece algunas ventajas para la administración continua de las suscripciones. Este enfoque consiste en implementar un único pod por suscripción, acumular las suscripciones en una sola "cuenta maestra" y evitar las posibilidades de alcanzar los límites de Microsoft Azure que afectan a una sola suscripción.
  • Se requiere acceso saliente a Internet en la red virtual (VNet) de Microsoft Azure que está conectada a la máquina virtual de Jump Box temporal del nodo y la máquina virtual del administrador de pods (o a máquinas virtuales plurales en el caso de que la alta disponibilidad esté habilitada en el pod). La autenticación basada en proxy se admite en esta versión. Debe proporcionar los detalles de su proxy en el asistente de implementación del pod. Para la implementación de pods, debe poder accederse a nombres DNS específicos y deben admitirse protocolos y puertos específicos. Consulte Requisitos de DNS para un pod de Horizon Cloud en Microsoft Azure para conocer los requisitos de conectividad.
  • Tamaño de subred: actualmente no se admite la ampliación del tamaño de las subredes de un pod una vez implementado. Como resultado, en entornos de producción, se deben usar tamaños de subred lo suficientemente grandes para cumplir los siguientes requisitos:
    • Administración de subredes: Al implementar un pod, a partir de marzo de 2019, es necesario que la subred de administración del pod tenga un CIDR mínimo de /27, mientras que anteriormente se permitía un CIDR mínimo de /28. Este cambio se realizó para reducir la aparición de problemas que puedan ocurrir durante la actualización de pods debido a una falta de direcciones IP disponibles en la subred. Un CIDR de /27 admite 32 direcciones IP.
    • Subred de máquina virtual - principal: Use un CIDR en un rango con el tamaño suficiente para admitir la conexión de máquinas virtuales de los escritorios VDI previstos, las imágenes de RDS y todas las máquinas virtuales de las granjas de RDS del pod. Las máquinas virtuales del administrador de pods y las máquinas virtuales de Unified Access Gateway también necesitan algunas direcciones IP de esta subred (12 direcciones en total para admitir la actualización azul-verde de un pod habilitado para HA con ambos tipos de puertas de enlace). Por lo general, el rango de /24 a /21 sería suficiente para casos prácticos típicos. Nota: En ocasiones, esta subred de la máquina virtual se conoce como subred de escritorio o subred de arrendatarios.
    • A partir de la versión de servicio de julio de 2020 y del manifiesto del pod 2298.0, se proporciona una nueva función para usar subredes de arrendatarios adicionales para los escritorios VDI y las máquinas virtuales de granjas de RDS. Estas subredes adicionales pueden encontrarse en la misma VNet del pod o en VNet emparejadas. Para un pod en el manifiesto 2298.0 o una versión posterior, puede editar la configuración del pod para incluir esas subredes adicionales. A continuación, puede especificar el uso de las subredes de arrendatarios adicionales en las definiciones de las granjas y las asignaciones de escritorios VDI, en lugar de que utilicen la subred de la máquina virtual principal. El uso de estas subredes secundarias para las máquinas virtuales de granja y las máquinas virtuales de escritorio VDI permite una administración simplificada, ya que se pueden especificar las granjas y las asignaciones de escritorios VDI que se encuentran en la subred de arrendatario y la VNet.
  • Para aprovechar la función y hacer que implemente la puerta de enlace externa en su propia VNet, las VNet deben estar emparejadas. Como resultado, debe crear las subredes manualmente antes de ejecutar el asistente de implementación. Para la VNet de la puerta de enlace externa, la subred de administración y la subred de back-end deben cumplir con la misma CIDR/27 mínima.
Antes de conectar pods mediante Horizon Cloud Connector
  • Si la cuenta de arrendatario de Horizon Cloud se creó el 17 de marzo de 2020 en una de las siguientes regiones: US-2, Europe-2, Australia-2 (también conocidas como PROD1_NORTHCENTRALUS2_CP1, PROD1_NORTHEUROPE_CP1 PROD1_AUSTRALIAEAST_CP1), debe usar Horizon Cloud Connector 1.6 o una versión posterior para conectar los pods a Horizon Cloud. La fecha del correo electrónico de bienvenida a Horizon Cloud Service es la que se utilizará para determinar si la cuenta de arrendatario se creó después del 17 de marzo de 2020. El correo electrónico también indica la región en la que se creó la cuenta. Las versiones anteriores de Cloud Connector tendrán problemas de compatibilidad si se utilizan con cuentas de arrendatario creadas a partir del 17 de marzo de 2020 en las regiones indicadas.
  • Se requiere acceso a Internet saliente para que Horizon Cloud Connector se comunique con el plano de nube del servicio, especialmente para recibir los detalles de la licencia. Se debe poder acceder a los nombres de DNS específicos, y se deben permitir puertos y protocolos específicos. Consulte Requisitos de DNS, puertos y protocolos cuando se utiliza Horizon Cloud Connector y un pod de Horizon para conocer los requisitos de conectividad.
  • Antes de conectar un segundo pod de Horizon a Horizon Cloud, debe iniciar sesión en la consola administrativa de Horizon Cloud y completar el proceso de registro de dominio de Active Directory después de conectar el primer pod de Horizon mediante el proceso de incorporación de Horizon Cloud Connector. Si empareja varios pods de Horizon con Horizon Cloud antes de completar dicho registro de dominio de Active Directory, puede que ocurran resultados inesperados cuando finalmente inicie sesión en la consola para intentar el proceso de registro de dominio.
  • Debido a un problema conocido, cuando se utiliza un dominio local de Active Directory para prestar servicio a un pod en VMware Cloud on AWS, se pueden producir tiempos de acceso lentos, debido a congestión de red o latencia de red entre ese dominio de Active Directory local y el pod de VMware Cloud on AWS, que generen llamadas al agotarse el tiempo de espera del dominio. Los síntomas habituales de esta latencia son una pantalla de inicio de sesión de Active Directory que no completa el inicio de sesión antes de agotarse el tiempo de espera. Si experimenta síntomas de este tipo, puede resultar útil configurar un controlador de dominio grabable en cada centro de datos definido por software en la nube (SDDC).