Arrendatarios de first-gen: requisitos previos para ejecutar el asistente de implementación de pods de first-gen

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 solicitados en el asistente de implementación de pods y seguir los pasos del asistente.

Importante: Esta información se aplica únicamente cuando se tiene 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 más 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 hayan establecido en el entorno de Microsoft Azure bloqueen, denieguen o restrinjan la creación de los componentes del pod. También debe comprobar 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 comprobar que las directivas de Microsoft Azure permitan resourceType de Microsoft.MarketplaceOrdering/*. El proceso de implementación del pod se basa en aceptar las ofertas de Azure Marketplace de nuestro publisherID. 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 Microsoft.MarketplaceOrdering/* tipo de recurso, consulte 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 en que se implementan 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 tiene pensado usar suscripciones diferentes, debe realizar los pasos descritos en la guía de implementación de first-gen 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.

• Cuando el arrendatario está configurado para utilizar 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 VNet en la región en la que desea implementar el pod y que dicha VNet cumpla los requisitos descritos en Configurar la red virtual obligatoria en Microsoft Azure.

  Importante: No todas las regiones de Microsoft Azure son compatibles con máquinas virtuales que admiten GPU. Si desea utilizar el pod para 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 serie NV, NVv4 y NCv2 que desee utilizar y que sean compatibles con esta versión de Horizon Cloud. Consulte la documentación de Microsoft en https://azure.microsoft.com/en-us/regions/services/ para obtener más información.

• 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: requisitos de puertos y protocolos del pod de Horizon Cloud.

• Si necesita utilizar un proxy para acceder a Internet de salida, compruebe que dispone de la información de red para la configuración de proxy y las credenciales de autenticación que necesita, si las hubiera. El proceso de implementación del pod requiere 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 las instancias del administrador de pods y las instancias de Unified Access Gateway utilicen 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. Se debe poder acceder al servidor NTP que especifique desde las redes virtuales en las que tiene pensado implementar las instancias del administrador de pods y las instancias de Unified Access Gateway. Cuando planee utilizar 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 pueda 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 que existan en la VNet. Para conocer los pasos para crear las subredes requeridas con anticipación, consulte Arrendatarios de first-gen: antes de la implementación del pod, crear las subredes requeridas del pod de Horizon Cloud en la VNet en Microsoft Azure y Arrendatarios de first-gen: cuándo usar subredes existentes para un pod de Horizon Cloud en Microsoft Azure.

  PRECAUCIÓN:

  Las subredes que cree manualmente 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 estas subredes o, de lo contrario, utilice cualquiera de las direcciones IP. Este aviso de precaución incluye pods implementados desde Horizon Cloud: no reutilice subredes en las que ya tenga 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 está en uso por 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 VNet independiente para cada pod. Esta recomendación proviene de las instrucciones para tener en cuenta la cantidad de pods que se implementan en una sola suscripción, como se describe en Aspectos a tener en cuenta antes y durante el uso de Horizon Cloud. Para evitar los límites de Microsoft Azure dentro de una sola 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 conoce 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 necesaria cuando se desea la configuración externa de Unified Access Gateway. Compruebe también que esos rangos no se superpongan. Los rangos de direcciones se introducen 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 de /27 como mínimo. Para el rango de subredes 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 definirse 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 daría como resultado un rango de IP de 192.168.182.48 a 192.168.182.63, y el prefijo es el mismo 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 la misma que el prefijo de 192.168.182.60. Asegúrese de que los CIDR den como resultado rangos de direcciones IP en los que la dirección IP inicial coincida con el prefijo CIDR.

• Si va a hacer que el implementador cree las subredes requeridas, compruebe que las subredes con esos rangos de direcciones no existan ya en la VNet. En este escenario, el implementador en sí creará automáticamente las subredes con 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 sobre las direcciones superpuestas y no continuará. Si la VNet está emparejada, compruebe también que los espacios de direcciones CIDR que tiene pensado introducir en el asistente ya 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, debe proporcionar lo siguiente:

• El nombre de dominio completo (FQDN) que utilizarán los 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 adecuado. 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 configura 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 está 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 producirá un error en 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 capacidades de Unified Access Gateway requieren SSL para las conexiones de cliente, como se describe en la documentación del producto de 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 cuando el certificado se cargue 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 debe crear de antemano las subredes de arrendatario de escritorio y administración. Consulte los pasos en Arrendatarios de first-gen: antes de la implementación del 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 administración. Los rangos de direcciones se introducen 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 subredes 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 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 en Requisitos previos para todas las implementaciones sobre cómo 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 sea 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 sobre archivos 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 Horizon Cloud first-gen.

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

Nota: Al implementar una puerta de enlace externa mediante su propia VNet, 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 cadena como hcs-ID, donde ID es el identificador del implementador de la puerta de enlace, y una node parte.

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 especial de uso de su propia VNet, ya que la suscripción independiente debe tener su propia VNet, puesto que las VNet están dentro del ámbito de una suscripción.

• La VNet de la puerta de enlace debe estar emparejada con la VNet del pod.

• Compruebe que las subredes requeridas se hayan creado previamente y que existan en la VNet, o que los espacios de direcciones CIDR que tiene pensado introducir en el asistente ya estén incluidos en el espacio de direcciones de la VNet. Debido a que las VNet están emparejadas, el implementador no podrá expandir la VNet automáticamente si introduce en el asistente espacios de direcciones CIDR que aún no estén incluidos en el espacio de direcciones de la VNet. Si esto ocurre, se producirá un error en el proceso de implementación.

  Propina: La práctica recomendada es crear las subredes por adelantado. Para conocer los pasos para crear las subredes requeridas con anticipación, consulte Arrendatarios de first-gen: antes de la implementación del pod, crear las subredes requeridas del pod de Horizon Cloud en la VNet en Microsoft Azure y Arrendatarios de first-gen: cuándo usar subredes existentes para un pod de Horizon Cloud en Microsoft Azure.

• Si utiliza una suscripción independiente para la puerta de enlace externa, compruebe que dispone de la información de la suscripción, como se describe en Información relacionada con la suscripción para el asistente de implementación de pods de Horizon Cloud.

• Si utiliza una suscripción independiente para la puerta de enlace externa y planea implementar la puerta de enlace en un grupo de recursos designado que cree en lugar de hacer que el implementador cree automáticamente el grupo de recursos, compruebe que haya creado ese grupo de recursos en esa suscripción. En el asistente, seleccione el grupo de recursos por su nombre. Compruebe también que ha concedido el acceso necesario a ese grupo de recursos para que el implementador funcione en él, como se describe en Arrendatarios de first-gen: cuando la organización prefiere utilizar una función personalizada.

Requisitos previos cuando se implementa con una configuración de autenticación en dos fases

Si planea utilizar la capacidad de 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 obligatorios del asistente Agregar pod.

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

• RADIUS

  Si va a configurar los ajustes de un servidor RADIUS principal y auxiliar, obtenga la información de cada uno de ellos.

  • Dirección IP o nombre DNS del servidor de autenticación

  • El secreto compartido que se utiliza para cifrar y descifrar en los mensajes de protocolo del servidor de autenticación.

  • Números de puerto de autenticación, por lo general, 1812/UDP para RADIUS.

  • Tipo de autenticación Entre los tipos de autenticación se incluyen PAP (Protocolo de autenticación de contraseña), CHAP (Protocolo de autenticación por desafío mutuo), MSCHAP1 MSCHAP2 (Protocolo de autenticación por desafío mutuo de Microsoft, versiones 1 y 2).

    Nota: Compruebe la documentación del proveedor de RADIUS para el protocolo de autenticación que el proveedor de RADIUS recomiende y siga el tipo de protocolo indicado. Las instancias de Unified Access Gateway proporcionan la capacidad del pod para admitir la autenticación en dos fases con RADIUS y Unified Access Gateway admite PAP, CHAP, MSCHAP1 y MSCHAP2. Por lo general, PAP es menos seguro que MSCHAP2. PAP también es un protocolo más simple que MSCHAP2. Como resultado, aunque la mayoría de los proveedores RADIUS son compatibles con el protocolo PAP más simple, algunos proveedores RADIUS no son tan compatibles con el MSCHAP2 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 de 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.

  • Clave de acceso del servidor de RSA SecurID Authentication Manager.
  • 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 de RSA SecurID Authentication Manager.
  • Dirección IP del servidor del administrador de autenticación RSA SecurID.
  • Si el servidor de RSA SecurID Authentication Manager o su servidor de equilibrador de carga tienen un certificado autofirmado, necesitará el certificado de CA para proporcionarlo en el asistente Agregar pod. El certificado debe estar en formato PEM (tipos .cer de archivo o.cert ).pem