Antes de ejecutar el asistente de implementación de pods de first-gen, compruebe que el entorno cumpla estos requisitos previos. Debe contar con los siguientes elementos para poder proporcionar los valores necesarios en el asistente de implementación de pods y seguir los pasos de este.

Importante: Esta información se aplica únicamente cuando tenga acceso a un entorno de arrendatario de first-gen en el plano de control de first-gen. Como se describe en el artículo 92424 de la base de conocimientos, el plano de control de first-gen ha llegado a la fecha de fin de disponibilidad (EOA). Consulte el artículo para obtener información.
Importante: Antes de iniciar el asistente de implementación de pods y comenzar a implementar el pod, además de los requisitos que se indican a continuación, debe tener en cuenta los siguientes puntos clave:
  • Una implementación correcta del pod requiere que ninguna de las directivas de Microsoft Azure que usted o su equipo de TI haya establecido en el entorno de Microsoft Azure bloqueen, denieguen o restrinjan la creación de los componentes del pod. También debe verificar que las definiciones de directivas integradas de las directivas de Microsoft Azure no bloqueen, denieguen ni restrinjan la creación de los componentes del pod. Como dos ejemplos de elementos que se deben permitir, usted y su equipo de TI deben comprobar que ninguna de sus directivas de Microsoft Azure bloquee, deniegue o restrinja la creación de componentes en la cuenta de almacenamiento de Azure y deben verificar que las directivas de Microsoft Azure permitan un resourceType con el valor Microsoft.MarketplaceOrdering/*. El proceso de implementación de pods se basa en aceptar las ofertas de Azure Marketplace desde el publisherID de vmware-inc de VMware. Para obtener información sobre las directivas de Azure, consulte la documentación de directivas de Azure. Para obtener información sobre cómo el servicio utiliza el tipo de recurso Microsoft.MarketplaceOrdering/*, consulte la información relativa a Cuando una organización de seguridad o TI tiene restricciones de uso de ofertas de Azure Marketplace o pedidos de Marketplace.
  • El implementador de pods requiere que la cuenta de almacenamiento de Azure permita al implementador crear el tipo de cuenta Azure StorageV2 en el grupo de recursos del pod en la suscripción. Esta cuenta de almacenamiento se utiliza para las funciones de App Volumes del pod. Durante el proceso de implementación del pod, asegúrese de que las directivas de Microsoft Azure no restrinjan ni denieguen la creación de contenido que requiere el tipo de cuenta de Azure StorageV2.
  • Todos los pods conectados a la nube deben tener conexión directa con el mismo conjunto de dominios de Active Directory en el momento que implementa esos pods.

Requisitos previos para todas las implementaciones

  • Cuando se agrega otro pod, se puede utilizar la misma suscripción que se utilizó antes para los pods anteriores, o se puede utilizar una suscripción diferente si así lo exige su organización. Si va a usar suscripciones diferentes, debe realizar los pasos descritos en la Guía de implementación para obtener el identificador de suscripción, el identificador de directorio, el identificador de la aplicación y la clave de aplicación. Debe asegurarse de que la suscripción que utilice cumpla los requisitos descritos en esa guía, especialmente que la entidad de servicio tenga los permisos de función adecuados concedidos en los niveles relevantes de su suscripción. Puede desplazarse hasta el documento de introducción en línea desde la página de Documentación de Horizon Cloud.
  • Cuando el arrendatario está configurado para utilizar el Universal Broker para los pods de Microsoft Azure, al ejecutar el asistente de implementación de pods para agregar un nuevo pod, debe especificar un sitio. Puede seleccionar un sitio existente o especificar uno nuevo.
  • Compruebe que haya una red virtual en la región en la que desea implementar el pod, y que dicha red virtual cumpla los requisitos descritos en Configurar la red virtual obligatoria en Microsoft Azure.
    Importante: No todas las regiones de Microsoft Azure son compatibles con las máquinas virtuales que admiten GPU. Si desea utilizar el pod con aplicaciones remotas o escritorios habilitados para GPU, asegúrese de que la región de Microsoft Azure que seleccione para el pod disponga de los tipos de máquina virtual series NV, NVv4 y NCv2 que desee utilizar y de que sean compatibles con esta versión de Horizon Cloud. Consulte la documentación de Microsoft en https://azure.microsoft.com/es-es/regions/services/ para obtener más detalles.
  • Compruebe que la VNet esté configurada para apuntar a un DNS que pueda resolver direcciones externas. El implementador de pods debe poder conectarse con las direcciones externas en el plano de control de Horizon Cloud para descargar de forma segura el software del pod en su entorno de Microsoft Azure.
  • Compruebe que se cumplan los requisitos de protocolos, puertos y DNS del implementador de pods, como se describe en Arrendatarios de first-gen - Implementaciones de Horizon Cloud on Microsoft Azure: requisitos de resolución de nombres de host, nombres DNS y Arrendatarios de first-gen: pod de Horizon Cloud - Requisitos de puertos y protocolos.
  • Si necesita utilizar un proxy para acceso saliente a Internet, compruebe que cuenta con la información de red para la configuración de proxy y las credenciales de autenticación que necesita, si las hubiere. El proceso de implementación del pod requiere de acceso saliente a Internet.
    Importante: Actualmente no se admite la edición o actualización de la configuración de proxy en un pod después de implementar el pod en Microsoft Azure. Además, actualmente no se admite agregar una configuración de proxy a un pod implementado sin configuración de proxy.
  • Compruebe que tenga la información de al menos un servidor NTP que desee que el utilicen las instancias del administrador de pods y las instancias de Unified Access Gateway para la sincronización de hora. El servidor NTP puede ser un servidor NTP público o su propio servidor NTP que configuró para este fin. El servidor NTP que especifique debe ser accesible desde las redes virtuales en las que tiene pensado implementar las instancias del administrador de pods y las instancias de Unified Access Gateway. Cuando vaya a usar un servidor NTP, utilizando su nombre de dominio en lugar de una dirección IP numérica, asegúrese también de que el DNS configurado para la red virtual puede resolver el nombre del servidor NTP.
    Nota: Se recomienda utilizar el mismo servidor NTP para las instancias del administrador de pods, las instancias de Unified Access Gateway y los servidores de Active Directory. Pueden producirse sesgos horarios cuando estas instancias utilizan servidores NTP diferentes. Estos sesgos horarios posteriormente pueden provocar errores cuando la puerta de enlace intenta autenticar las sesiones de usuario final en sus escritorios y aplicaciones.
  • Si no desea que el implementador cree automáticamente las subredes que necesita, compruebe que las subredes necesarias se hayan creado con anticipación y se encuentren en la VNet. Para ver los pasos que debe seguir a fin de crear las subredes necesarias con anticipación, consulte Arrendatarios de first-gen: antes de implementar el pod, cree las subredes requeridas del pod de Horizon Cloud en la VNet en Microsoft Azure y Arrendatarios de first-gen: cuándo usar las subredes existentes para un pod de Horizon Cloud en Microsoft Azure.
    Precaución: Las subredes que se creen de forma manual en la VNet antes de la implementación del pod deben permanecer vacías. No reutilice las subredes existentes que ya tienen elementos que utilizan direcciones IP en dichas subredes. Si una dirección IP ya está en uso en las subredes, es muy probable que se produzcan problemas, como un pod que no se implementa u otros problemas de conflictos de IP descendentes. No ponga ningún recurso en las subredes o, de lo contrario, utilice cualquiera de las direcciones IP. Este aviso de precaución incluye pods implementados desde Horizon Cloud: no reutiliza las subredes en las que ya se dispone de un pod implementado.
    Importante: Al implementar pods adicionales después del primero, no reutilice una subred existente que esté siendo utilizada por un pod existente. No intente compartir una subred que ya esté en uso por parte de un pod. Si selecciona una subred que ya utiliza otro pod, se interrumpirán las operaciones del pod para ese pod existente y para el que implemente con su subred.

    La práctica recomendada es utilizar una red virtual independiente para cada pod. Esta recomendación proviene de las instrucciones para tener en cuenta la cantidad de pods que se implementan en una única suscripción, como se describe en Aspectos a tener en cuenta antes y durante el uso de Horizon Cloud. Para evitar la presencia de límites de Microsoft Azure dentro de una única suscripción, cuando se tiene un solo pod por suscripción, se evita la posibilidad de alcanzar esos límites. Dado que Microsoft Azure requiere que cada suscripción tenga su propia red virtual, al seguir la práctica recomendada de tener un solo pod por suscripción, se sigue automáticamente la práctica recomendada de usar una red virtual independiente para cada pod.

  • Si va a hacer que el implementador cree las subredes obligatorias, compruebe que conozca los rangos de direcciones que va a introducir en el asistente para la subred de administración, la subred de escritorio y la subred DMZ. La subred DMZ es obligatoria cuando se desea la configuración de Unified Access Gateway externa. Asimismo, compruebe que los rangos no se superpongan. Introduzca los rangos de direcciones en notación CIDR (notación de enrutamiento de interdominios sin clases). El asistente mostrará un error si los rangos de subredes introducidos se superponen. Para el rango de subred de administración, se requiere una CIDR /27 como mínimo. Para el rango de subred DMZ, se requiere una CIDR de /28 como mínimo. Si desea mantener los rangos de subredes DMZ y administración ubicados de forma conjunta, puede hacer que el rango de subredes DMZ sea similar al de la subred de administración con una dirección IP especificada. Por ejemplo, si la subred de administración es 192.168.8.0/27, una subred DMZ coincidente sería 192.168.8.32/27.
    Importante: Los CIDR que introduzca en los campos del asistente deben configurarse de tal modo que cada combinación de máscara de bits y prefijo dé como resultado un rango de direcciones IP con el prefijo como la dirección IP inicial. Microsoft Azure requiere que el prefijo CIDR sea el principio del rango. Por ejemplo, un CIDR correcto de 192.168.182.48/28 podría provocar un rango de IP de 192.168.182.48 a 192.168.182.63, y el prefijo es igual que la dirección IP inicial (192.168.182.48). Sin embargo, un CIDR incorrecto de 192.168.182.60/28 podría provocar un rango de IP de 192.168.182.48 a 192.168.182.63, donde la dirección IP inicial no es igual al prefijo de 192.168.182.60. Asegúrese de que sus CIDR deriven en rangos de direcciones IP en los que la dirección IP inicial coincida con el prefijo de CIDR.
  • Si va a hacer que el implementador cree las subredes requeridas, compruebe que las subredes con dichos rangos de direcciones no existan ya en la VNet. En este escenario, el implementador en sí creará automáticamente las subredes a través de los rangos de direcciones que proporcione en el asistente. Si el asistente detecta que ya existen subredes con esos rangos, el asistente mostrará un error acerca de las direcciones superpuestas y no continuará. Si la VNet tiene elementos del mismo nivel, compruebe también que los espacios de direcciones de CIDR que va a introducir en el asistente estén incluidos en el espacio de direcciones de la VNet.

Requisitos previos para las configuraciones de Unified Access Gateway

Si tiene previsto que el pod use una configuración de Unified Access Gateway, deberá proporcionar lo siguiente:

  • El nombre de dominio completo (FQDN) necesario que utilizarán sus usuarios finales para acceder al servicio. Si tiene pensado utilizar el mismo FQDN para las configuraciones de puerta de enlace interna y externa, después de implementar el pod, debe configurar el tráfico entrante de cliente del usuario final para que se enrute al equilibrador de carga de la puerta de enlace correspondiente. El objetivo es configurar el enrutamiento de modo que el tráfico de cliente de Internet se enrute al equilibrador de carga público de Microsoft Azure de la puerta de enlace externa, y que el tráfico de cliente de la intranet se enrute al equilibrador de carga interno de Microsoft Azure de la puerta de enlace interna. En este escenario, donde ambas puertas de enlace tendrán el mismo FQDN, se configurará un DNS dividido (Sistema de nombres de dominio dividido) para resolver la dirección de la puerta de enlace a la puerta de enlace externa o interna, en función de la red de origen de la consulta de DNS del cliente del usuario final. A continuación, el mismo FQDN utilizado en el cliente del usuario final puede enrutarse a la puerta de enlace externa cuando el cliente se encuentra en Internet, y enrutar a la puerta de enlace interna cuando el cliente se encuentra en la red interna.
    Importante: Este FQDN no puede contener caracteres de subrayado. En esta versión, se generará un error con las conexiones a las instancias de Unified Access Gateway cuando el FQDN contenga caracteres de subrayado.
  • Un certificado de servidor SSL firmado (formato PEM) basado en dicho FQDN. Las funciones de Unified Access Gateway requieren SSL para las conexiones cliente, como se describe en la documentación del producto Unified Access Gateway. El certificado debe estar firmado por una entidad de certificación (CA) de confianza. El archivo PEM único debe contener la cadena de certificados completa con la clave privada. Por ejemplo, el archivo PEM único debe contener el certificado de servidor SSL, los certificados de CA intermedios que sean necesarios, el certificado de CA raíz y la clave privada. OpenSSL es una herramienta que puede utilizar para crear el archivo PEM.
    Importante: Todos los certificados de la cadena de certificados deben tener intervalos de tiempo válidos. Las máquinas virtuales de Unified Access Gateway requieren que todos los certificados de la cadena, incluidos los certificados intermedios, tengan plazos válidos. Si no ha caducado ningún certificado de la cadena, se pueden producir errores inesperados más adelante al cargar el certificado en la configuración de Unified Access Gateway.
  • Si va a realizar la implementación con una configuración de Unified Access Gateway externa, debe especificar una subred DMZ (zona desmilitarizada). Para proporcionar esta subred DMZ puede elegir una de estas dos formas:
    • Crear la subred DMZ con anticipación en la VNet. Con este método, también tiene que crear de antemano las subredes de arrendatario de escritorio y de administración. Consulte los pasos en Arrendatarios de first-gen: antes de implementar el pod, cree las subredes requeridas del pod de Horizon Cloud en la VNet en Microsoft Azure.
    • Hacer que el implementador cree automáticamente la subred DMZ durante la implementación. Con este método, debe tener el rango de direcciones que va a introducir en el asistente para la subred DMZ y comprobar que el rango no se superponga con los rangos de las subredes de arrendatario de escritorio y de administración. Introduzca los rangos de direcciones en notación CIDR (notación de enrutamiento de interdominios sin clases). El asistente mostrará un error si los rangos de subredes introducidos se superponen. Para el rango de subred DMZ, se requiere una CIDR de /28 como mínimo. Si desea mantener los intervalos de subredes DMZ y administración ubicados de forma conjunta, puede hacer que el rango de subredes DMZ sea el mismo que el rango de subredes de administración con una dirección IP especificada. Por ejemplo, si la subred de administración es 192.168.8.0/27, una subred DMZ coincidente sería 192.168.8.32/27. Consulte también la nota importante que se encuentra en Requisitos previos para todas las implementaciones sobre la importancia de garantizar que el rango de direcciones IP tenga una combinación de máscara de bits y prefijo que dé como resultado un rango donde el prefijo aparezca como la dirección IP inicial.
  • Si va a realizar la implementación con una configuración de Unified Access Gateway externa y desea evitar que el equilibrador de carga de la configuración tenga una dirección IP pública, debe especificar una dirección IP que haya asignado en la configuración de DNS al FQDN que los usuarios finales utilizarán para las conexiones PCoIP en sus clientes de Horizon.

Para obtener más información sobre las consideraciones de archivo PEM requeridas por Unified Access Gateway, consulte Arrendatarios de first-gen: convertir un archivo de certificado al formato PEM requerido para las implementaciones de pods de first-gen Horizon Cloud.

Requisitos previos cuando se implementa con una configuración de Unified Access Gateway externa que utiliza su propia VNet o una suscripción independiente de la de la VNet o suscripción del pod

Nota: Al implementar una puerta de enlace externa mediante su propia red virtual, se implementará una máquina virtual del conector de puerta de enlace. En Requisitos de puertos y protocolos para un pod de Horizon Cloud, la sección que describe los protocolos y los puertos de la máquina virtual del conector de puerta de enlace también tiene una descripción de esta máquina virtual del conector de puerta de enlace, que indica que esta máquina virtual del conector de puerta de enlace tiene un nombre que contiene una parte de tipo vmw-hcs-ID, donde ID es el identificador del responsable de la implementación de la puerta de enlace, y una parte de tipo node.

Junto con los requisitos previos anteriores al implementar con una configuración de Unified Access Gateway, estos requisitos previos son específicos del caso práctico de implementación de la puerta de enlace externa en su propia VNet o suscripción. El uso de su propia suscripción es un caso práctico especial de su propia VNet, puesto que la suscripción independiente debe tener su propia VNet, puesto que las VNet están en el ámbito de una suscripción.

Requisitos previos cuando se implementa con una configuración de autenticación de doble factor

Si planea utilizar la capacidad de la autenticación en dos fases y utilizarla con un servidor de autenticación en dos fases local, compruebe que tenga la siguiente información de la configuración de su servidor de autenticación, para que pueda proporcionarla en los campos adecuados en el asistente de adición de pods.

Obtenga la siguiente información de la lista, según el tipo que tenga.

RADIUS

Si está configurando ajustes para un servidor principal y un servidor auxiliar RADIUS, obtenga la información de cada uno de ellos.

  • La dirección IP o el nombre DNS del servidor de autenticación.
  • El secreto compartido que se utiliza para cifrar y descifrar los mensajes de protocolo del servidor de autenticación.
  • Números de puerto de autenticación, por lo general, 1812/UDP para RADIUS.
  • El tipo de protocolo de autenticación. Entre los tipos de autenticación se encuentran PAP (Protocolo de autenticación de contraseña), CHAP (Protocolo de autenticación por desafío mutuo), MSCHAP1 y MSCHAP2 (Protocolo de autenticación por desafío mutuo de Microsoft, versiones 1 y 2).
    Nota: Compruebe la documentación del proveedor RADIUS para el protocolo de autenticación que el proveedor RADIUS recomiende y siga el tipo de protocolo especificado. Las instancias de Unified Access Gateway le permiten al pod admitir la autenticación en dos fases con RADIUS, y Unified Access Gateway es compatible con PAP, CHAP, MSCHAP1 y MSCHAP2. PAP es generalmente menos seguro que MSCHAP2. PAP también es un protocolo más simple que MSCHAP2. Como consecuencia, aunque la mayoría de los proveedores RADIUS es compatible con el protocolo PAP más simple, algunos proveedores RADIUS no son tan compatibles con MSCHAP2 que es más seguro.
RSA SecurID
Nota: El tipo RSA SecurID es compatible con las implementaciones de Horizon Cloud on Microsoft Azure que ejecutan el manifiesto 3139.x o una versión posterior. La opción de interfaz de usuario para especificar el tipo RSA SecurID en los asistentes Agregar pod y Editar pod estará visible para su selección en los asistentes a partir de mediados de marzo de 2022.
  • La clave de acceso del servidor del administrador de autenticación RSA SecurID.
  • Número de puerto de comunicación de RSA SecurID. Por lo general, es 5555, como se establece en la configuración del sistema RSA Authentication Manager para la API de autenticación de RSA SecurID.
  • Nombre de host del servidor del administrador de autenticación RSA SecurID.
  • Dirección IP de ese servidor del administrador de autenticación RSA SecurID.
  • Si el servidor del administrador de autenticación RSA SecurID o su servidor de equilibrador de carga tiene un certificado autofirmado, necesitará el certificado de CA para proporcionarlo en el asistente Agregar pod. El certificado debe estar en formato PEM (tipos de archivo .cer, .cert o .pem)