Antes de ejecutar el asistente de implementación de pods, 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: 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:
  • A partir de la versión de servicio de julio de 2020, en entornos nuevos, se requieren nuevos pods para implementar con al menos una configuración de puerta de enlace. Si la cuenta de cliente se creó antes de la versión de julio de 2020, pero aún no se ha implementado el primer pod, la implementación del primer pod requerirá la configuración de al menos una configuración de puerta de enlace en el momento de la implementación del pod.
  • 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 ejemplo, usted y su equipo de TI deben comprobar que ninguna de sus directivas de Microsoft Azure bloqueen, denieguen o restrinjan la creación de componentes en la cuenta de almacenamiento de Azure. Para obtener información sobre las directivas de Azure, consulte la documentación de directivas de Azure.
  • El implementador de pods requiere que la cuenta de almacenamiento de Azure permita al implementador utilizar los tipos de cuenta StorageV1 y StorageV2 de Azure. Asegúrese de que las directivas de Microsoft Azure no restrinjan ni denieguen la creación de contenido que requiere los tipos de cuenta StorageV1 y StorageV2 de Azure.
  • Como parte de los procesos de implementación del pod y la puerta de enlace, a menos que se especifiquen etiquetas de recursos personalizadas en el asistente de implementación, Horizon Cloud crea grupos de recursos en la suscripción de Microsoft Azure que no tienen etiquetas, incluido el grupo de recursos inicial que se crea para la instancia de Jump Box temporal que orquesta esos procesos de implementación. A partir de la actualización del plano de nube del 8 de octubre de 2020, el asistente de implementación tiene una función en la que puede especificar las etiquetas de recursos personalizadas que desea que se apliquen a los grupos de recursos creados por el implementador. Si no especifica etiquetas de recursos personalizadas y la suscripción de Microsoft Azure tiene algún tipo de requisito de etiqueta de recurso, se producirá un error en la implementación del pod si se intenta implementar un pod en esa suscripción, o en el momento de actualizar el pod o agregar una configuración de puerta de enlace a un pod. Si no tiene pensado utilizar la función de etiquetas de recursos personalizadas del asistente de implementación, debe comprobar que las directivas de Microsoft Azure permitan la creación de grupos de recursos sin etiqueta del pod en la suscripción de destino. Para obtener la lista de grupos de recursos que crea el implementador, consulte el tema Grupos de recursos creados para un pod implementado en Microsoft Azure de la Guía de administración.
  • 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 tenant 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 para aplicaciones remotas o escritorios con GPU habilitado, asegúrese de que la región de Microsoft Azure que seleccione para el pod disponga de los tipos de máquina virtual de la serie NV que desea utilizar y 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 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.
  • 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.
  • Compruebe que tenga la información de al menos un servidor NTP que desee que el pod utilice 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 la red virtual que configuró. 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.
  • 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 Antes de implementar el pod, cree las subredes requeridas del pod de Horizon Cloud en la VNet en Microsoft Azure y 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 se puede volver a utilizar una subred existente que esté siendo utilizada por un pod existente.
  • 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 pensado utilizar una configuración de Unified Access Gateway para el pod, debe proporcionar:

  • El nombre de dominio completo (FQDN) necesario que utilizarán sus usuarios finales para acceder al servicio. A partir del nuevo manifiesto del pod, disponible en la versión de servicio trimestral de julio de 2020, cuando se implementan las dos configuraciones de puerta de enlace en un pod, se solicita que se especifique el mismo FQDN para ambas configuraciones de puerta de enlace. Después de implementar el pod con la configuración de puerta de enlace interna y externa, debe configurar el tráfico de cliente de usuario final entrante para que se enrute al equilibrador de carga 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. Dado que 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 tenant de escritorio y de administración. Consulte los pasos en 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 tenant 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 el hecho de tener una dirección IP pública para el equilibrador de carga de la configuración, 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 Convertir un archivo de certificado al formato PEM requerido para la implementación del pod.

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

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 utilizada en la configuración de su servidor de autenticación, para que pueda proporcionarla en los campos adecuados en el asistente de implementación de pods. Si tiene un servidor principal y uno secundario, 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.
  • Los números de puerto de autenticación, por lo general, el puerto UDP 1812.
  • 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.