El propósito de esta lista de comprobación es informarle de los elementos necesarios en una implementación de Horizon Cloud on Microsoft Azure first-gen. Si sigue esta lista de comprobación, podrá ejecutar correctamente el implementador de pods y completar las tareas del día 1.
A partir de agosto de 2022, Horizon Cloud Service - next-gen tiene disponibilidad general y cuenta con su propia guía, Uso del plano de control de Horizon next gen.
Una indicación del entorno que se tiene (next-gen o first-gen) es el patrón que aparece en el campo de URL del navegador después de iniciar sesión en el entorno y ver la etiqueta Horizon Universal Console. En entornos de next-gen, la dirección URL de la consola contiene un fragmento como /hcsadmin/. La URL de la consola de first-gen muestra una sección diferente (/horizonadmin/).
Destinatarios de la lista de comprobación
Esta lista de comprobación se utiliza principalmente con cuentas de cliente de Horizon Cloud que nunca han tenido una implementación de Horizon Cloud on Microsoft Azure en su entorno de arrendatario antes de la actualización de servicio del 2 de noviembre de 2023. Posiblemente haya oído hablar de estos tenants como entornos limpios o entornos nuevos.
El conjunto que se describe aquí se utiliza principalmente para implementaciones de producción. Por lo general, las pruebas y la mayoría de las implementaciones de validación técnica se pueden manejar con un subconjunto, como se ilustra en una implementación de validación técnica simplificada.
Algunas de las secciones incluidas aquí se deben poner en marcha antes de ejecutar el asistente de implementación de nuevo pod.
Algunos elementos se pueden aplazar hasta que la implementación se haya completado y esté en funcionamiento.
Otros aparecen como opcionales, ya que guardan relación con las opciones que el usuario seleccione para su implementación de Horizon Cloud on Microsoft Azure.
Por ejemplo, se puede ejecutar el asistente de nuevo pod sin seleccionar una configuración de Unified Access Gateway y agregar la configuración de puerta de enlace posteriormente. En este caso, no será necesario cumplir los requisitos de Unified Access Gateway hasta más adelante.
| Cumplir estos requisitos antes de ejecutar el asistente de nuevo pod | Puede llevarse a cabo tras implementar el pod |
|---|---|
|
|
Algunas consideraciones clave
Cuando se realiza una implementación de Horizon Cloud on Microsoft Azure de prueba o de validación técnica, quien se encargue de ello puede ser el propietario de la suscripción de Microsoft Azure que se usará en la implementación, o bien puede ser alguien que esté realizando la validación técnica en nombre de una organización que posee la suscripción.
El propietario de la suscripción debe asegurarse de que ninguna de las directivas de Microsoft Azure que hay vigentes en la suscripción del pod bloquee, deniegue o restrinja la creación de los componentes del pod.
El motivo de cerciorarse de ello es que, durante el proceso de implementación del pod, el implementador de pods utiliza llamadas de API para crear recursos en la suscripción especificada en el asistente de nuevo pod. Si esa suscripción tiene directivas de Microsoft Azure vigentes que puedan bloquear, denegar o restringir la creación de los componentes del pod, la implementación no se llevará a cabo correctamente y será necesario tramitar una solicitud de soporte técnico de VMware.
Como ejemplo, el implementador de pods requiere que ninguna de las directivas de Microsoft Azure vigentes en la suscripción del pod bloquee, deniegue o restrinja la creación de componentes en la cuenta de almacenamiento de Azure.
Antes de ejecutar el asistente de nuevo pod, confirme con el propietario de la suscripción que las definiciones de directiva integrada de las directivas de Microsoft Azure no bloquean, deniegan ni restringen la creación de los componentes del pod.
Requisitos del plano de control de Horizon Cloud
| ☐ | Cuenta de VMware Customer Connect que VMware haya configurado para iniciar sesión en el plano de control de Horizon Cloud. Para ver una descripción general de la relación de esta cuenta con su cuenta de tenant de Horizon Cloud, puede consultar la página Implementaciones e incorporación de pods de Horizon Service. |
Requisitos de suscripción de Microsoft Azure
| ☐ | Suscripción de Microsoft Azure válida en un entorno compatible de Microsoft Azure (Azure Commercial, Azure China y Azure Government). Si va a implementar la Unified Access Gateway externa en una VNet independiente mediante su propia suscripción, obtenga una suscripción de Microsoft Azure válida más en el mismo entorno de Microsoft Azure.
Nota:
Horizon Cloud es compatible con la mayoría de las regiones de Microsoft Azure. Para obtener una lista de las regiones de Microsoft Azure que no se admiten en este momento, consulte el
artículo de la base de conocimientos de VMware sobre las regiones de Microsoft Azure en Horizon Cloud Service on Microsoft Azure (77121).
|
| ☐ | Privilegios administrativos válidos de Microsoft Azure en esa suscripción de Microsoft Azure para poder utilizar Microsoft Azure Portal y realizar los pasos de preparación de implementación de un pod. |
| ☐ | Registro de aplicación y clave secreta de cliente de Horizon Cloud creados en la suscripción del pod. Consulte Arrendatarios de first-gen: crear un registro de la aplicación de Horizon Cloud en la suscripción del pod. Si usted o su organización van a utilizar la función para implementar la configuración de puerta de enlace externa en una suscripción distinta de la suscripción del pod, esa suscripción de puerta de enlace también necesita un registro de la aplicación y una clave secreta de cliente de Horizon Cloud. |
| ☐ | Al crear el registro de la aplicación de Horizon Cloud en una suscripción, se crea automáticamente una entidad de servicio siguiendo el comportamiento estándar de Microsoft Azure. Asigne a esta entidad de servicio una función que permita a Horizon Cloud realizar llamadas de API en la suscripción del pod. Por lo general, la función La función puede ser también una función personalizada asignada en el nivel de suscripción del pod. Al implementar la configuración de puerta de enlace externa en un grupo de recursos existente en una suscripción aparte, puede asignar o una función personalizada o la función Si usted o su organización prefieren que el registro de la aplicación de Horizon Cloud use una función personalizada, consulte la siguiente página, donde se describen las acciones que debe tener la función personalizada: Cuando la organización prefiere utilizar una función personalizada.
Nota: La función debe asignarse directamente a la entidad de servicio del registro de la aplicación de
Horizon Cloud. En esta entidad de servicio no se puede usar una asignación basada en grupo de una función.
|
| ☐ | Proveedores de recursos necesarios registrados en cada suscripción de Microsoft Azure. Consulte Registrar proveedores de recursos. |
| ☐ | ID de suscripción, ID de directorio, ID de aplicación y clave pertenecientes a la suscripción que se va a especificar en el asistente de implementación. |
| ☐ | La suscripción debe permitir el uso del tipo de cuenta de Azure StorageV2. Asegúrese de que las directivas de Microsoft Azure de la suscripción no restringen ni deniegan la creación de contenido que requiere el tipo de cuenta de Azure StorageV2. |
| ☐ | La suscripción debe permitir la creación de grupos de recursos que no tengan etiquetas, a menos que se especifiquen etiquetas de recursos personalizadas en el asistente de implementación de pods. Durante la implementación del pod se crean grupos de recursos en la suscripción del pod sin etiquetas, a menos que se especifiquen etiquetas de recursos personalizadas en el asistente. 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. Si no especifica etiquetas de recursos personalizadas en el asistente 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. Para conocer los nombres de los grupos de recursos creados por el implementador, consulte Grupos de recursos que crea el implementador de pods. |
| ☐ | Opcional. Para la instancia externa de Unified Access Gateway, su organización podría especificar que requiere el uso de un grupo de recursos específico creado previamente y con el nombre dado por la organización en una VNet y una suscripción independientes de la suscripción del pod. Si su organización especifica que requiere el uso de un grupo de recursos específico creado previamente y con el nombre dado por la organización, deberá utilizar la función para implementar la instancia de Unified Access Gateway externa en su propio grupo de recursos con nombre. Si no se usa esa función, el implementador de pods crea automáticamente un grupo de recursos con su propia convención de nomenclatura. El uso de la función requiere que se cree ese grupo de recursos en esa suscripción antes de ejecutar el implementador de pods. También debe asegurarse de que los permisos necesarios estén en vigor para que el implementador de pods implemente la configuración de Unified Access Gateway en el grupo de recursos, administre la configuración y actualice el software de Unified Access Gateway en el proceso estándar de actualización del pod. Para obtener más información sobre los permisos necesarios que incluir en la función personalizada, consulte Cuándo la organización prefiere utilizar una función personalizada. |
Requisitos de capacidad de Microsoft Azure
En los casos en los que la siguiente tabla hace referencia a una capacidad de Microsoft Azure, no se requiere una instalación manual. Siempre que las capacidades indicadas estén disponibles en la suscripción, el implementador de pods creará automáticamente instancias de las máquinas virtuales descritas.
Para hacer referencia a la capacidad en relación con las familias de máquinas virtuales, el portal de Microsoft Azure también utiliza el término cuota.
| ☐ | Capacidad de Microsoft Azure para los artefactos de pod principales de Horizon Cloud que se implementarán en esa suscripción. (Esta lista excluye las capacidades necesarias para las configuraciones opcionales de Unified Access Gateway y para las cargas de trabajo de aplicaciones y escritorios anticipadas).
|
| ☐ | Opcional. Capacidad necesaria al especificar el uso de Unified Access Gateway para el pod.
Nota: El modelo de máquina virtual de
A4_v2 solo es suficiente para pruebas de concepto (PoC), pruebas piloto o entornos más pequeños en los que se sabe que no se superarán las 1000 sesiones activas en el pod.
Si no se proporciona la región de la suscripción para los tamaños de |
Requisitos de red
| ☐ | La red virtual (VNet) de Microsoft Azure creada en la región de Microsoft Azure de destino con el espacio de direcciones aplicable para cubrir las subredes requeridas. Consulte Horizon Cloud first-gen: configurar la red virtual obligatoria en Microsoft Azure. Al implementar la Unified Access Gateway externa en su propia VNet independiente de la VNet del pod, cree esa VNet de Unified Access Gateway en la misma región de Microsoft Azure que la VNet del pod con el espacio de direcciones aplicable para cubrir las subredes requeridas y empareje las dos VNet. |
| ☐ | 3 rangos de direcciones que no se superponen en formato CIDR en la VNet del pod, reservados para subredes.
Sugerencia: Después de implementar el pod, puede editarlo para agregar subredes de arrendatario a fin de usarlas con las máquinas virtuales de las granjas y las asignaciones de escritorios. Las subredes de arrendatario adicionales pueden encontrarse en la misma red virtual en la que se implementa el pod o en una red virtual emparejada. Para obtener más información, consulte la
Descripción general sobre el uso de varias subredes de arrendatario.
|
| ☐ | Al implementar la Unified Access Gateway externa en su propia VNet independiente de la VNet del pod, 3 rangos de direcciones que no se superponen en formato CIDR en la VNet de Unified Access Gateway, reservados para subredes.
|
| ☐ | Servidor NTP o servidores disponibles y accesibles desde el pod de Horizon Cloud y las instancias de Unified Access Gateway. |
| ☐ | Configure el servidor DNS de la VNet (red virtual) para que se señale a un servidor DNS válido que puede resolver los nombres máquinas internos y externos. |
| ☐ | El acceso saliente a Internet en las redes virtuales que está utilizando para la implementación de la puerta de enlace y el pod debe resolver y alcanzar nombres DNS específicos mediante protocolos y puertos específicos. Esto es necesario para la implementación y las operaciones en curso. Para ver la lista de nombres DNS y puertos, consulte Requisitos de DNS y Requisitos de puertos y protocolos. |
| ☐ | Opcional. Información del servidor proxy si se requiere para el acceso a Internet saliente en la VNet que se utiliza durante la implementación y las operaciones en curso del entorno de Horizon Cloud. |
| ☐ | Opcional. Configuración de una VPN de Microsoft Azure/Express Route, en caso de querer establecer una red entre la VNet y la red corporativa local. |
Requisitos de puertos y protocolos
| ☐ | Se requieren puertos y protocolos específicos para los pods de incorporación y las operaciones en curso de su entorno de Horizon Cloud. Consulte Puertos y protocolos . |
Requisitos de Unified Access Gateway
Puede ejecutar el asistente de nuevo pod sin seleccionar una configuración de Unified Access Gateway y agregar la configuración de puerta de enlace posteriormente. En este caso, no será necesario cumplir los requisitos de Unified Access Gateway hasta más adelante. Por definición, una instancia de Unified Access Gateway externa permite que los clientes de redes externas inicien las aplicaciones y los escritorios virtuales, mientras que una instancia de Unified Access Gateway interna permite que los clientes de las redes internas tengan conexiones de HTML Access (Blast) de confianza. Para admitir conexiones de usuario final desde Internet e iniciar sus aplicaciones y escritorios virtuales, el pod debe tener una instancia de Unified Access Gateway externa configurada.
Si selecciona las opciones de Unified Access Gateway en el asistente de nuevo pod, dicho asistente requiere los siguientes elementos específicos.
| ☐ | FQDN para la configuración de Unified Access Gateway. |
| ☐ | Certificado o certificados para Unified Access Gateway en formato PEM que coincide con el FQDN.
Nota: Si el certificado o los certificados que proporciona para este propósito usan ajustes de CRL (Lista de revocación de certificados) o OCSP (Protocolo de estado de certificados en línea) que hacen referencia a nombres de DNS específicos, debe asegurarse de que el acceso a Internet saliente en la red virtual se pueda resolver y que se pueda acceder a ellos. Durante la configuración del certificado proporcionado en la configuración de la puerta de enlace de
Unified Access Gateway, el software de
Unified Access Gateway accederá a esos nombres DNS para comprobar el estado de revocación del certificado. Si no se puede acceder a esos nombres DNS, se producirá un error en la implementación del pod durante la fase de
Conexión. Estos nombres dependen en gran medida de la entidad de certificación que se utilizó para obtener los certificados y, por lo tanto, no quedan bajo el control de VMware.
|
| ☐ | Opcional, excepto cuando desee que los usuarios finales utilicen la autenticación en dos fases. En ese caso, Unified Access Gateway debe configurarse para la autenticación en dos fases con uno de los tipos de sistema de autenticación admitidos para su uso con implementaciones de Horizon Cloud on Microsoft Azure. La configuración debe incluir:
Nota: Después de implementar el pod y haber configurado la autenticación en dos fases en los ajustes de
Universal Broker, se necesita una configuración adicional cuando también se desea que los usuarios finales internos omitan el uso de esa autenticación en dos fases. Cuando un pod tiene una configuración de
Unified Access Gateway interna, esa configuración dirige las solicitudes de conexión a las aplicaciones y los escritorios virtuales para dichos usuarios finales internos. Cuando desee que
Universal Broker omita el paso de autenticación en dos fases para los usuarios finales internos, después de implementar el pod y configurar
Universal Broker, introduzca los rangos de direcciones NAT de salida que correspondan al tráfico de usuario final interno. Estos rangos permiten a
Universal Broker identificar el tráfico de cliente de los usuarios finales internos de forma distinta de los usuarios finales externos, con el fin de omitir la autenticación en dos fases. Para obtener más información, consulte el tema de la documentación
Definir rangos de redes internas para Universal Broker
|
Flujo de trabajo de implementación de un pod
Los elementos anteriores son los que se necesitan antes de iniciar el asistente de implementación de pods. Tras asegurarse de que cuenta con los elementos anteriores, siga hasta el paso 4 de la implementación de pods de Arrendatarios de first-gen: implementaciones de Horizon Cloud on Microsoft Azure - Secuencia de nivel general para implementar el pod.
Después de implementar correctamente el pod, asegúrese de que tiene los elementos descritos en la sección siguiente para poder completar los pasos clave restantes de ese flujo de trabajo de nivel general.
Requisitos de Active Directory
El flujo de trabajo de registro de Active Directory de la consola requiere los siguientes elementos. Para obtener información completa sobre este flujo de trabajo, consulte Registrar el primer dominio de Active Directory en el entorno de Horizon Cloud.
| ☐ | Una de las siguientes configuraciones de Active Directory admitidas
|
| ☐ | Niveles funcionales de dominios de Active Directory Domain Services (AD DS) de Microsoft Windows admitidos:
|
| ☐ | Cuando se implementan los pods conectados a la nube en una misma cuenta de cliente de Horizon Cloud, todos ellos deben tener una conexión directa con el mismo conjunto de dominios de Active Directory. Este requisito no solo se aplica a los pods adicionales que se implementan en Microsoft Azure después del primer pod, sino también a pods de Horizon que están conectados a la nube con la misma cuenta de cliente a través de Horizon Cloud Connector. |
| ☐ |
Referencia: Cuentas de servicio que requiere Horizon Cloud para sus operaciones |
| ☐ |
Referencia: Cuentas de servicio que requiere Horizon Cloud para sus operaciones |
| ☐ |
Para obtener más información, consulte Cuentas de servicio que requiere Horizon Cloud para sus operaciones En Microsoft Active Directory, cuando se crea una nueva unidad organizativa, el sistema puede establecer automáticamente el atributo |
| ☐ |
Para obtener más información, consulte Cuentas de servicio que requiere Horizon Cloud para sus operaciones En Microsoft Active Directory, cuando se crea una nueva unidad organizativa, el sistema puede establecer automáticamente el atributo |
| ☐ | Grupos de Active Directory
Horizon Cloud admite el uso de grupos de seguridad de Active Directory para inicios de sesión de administrador y autorizaciones de usuario final. Se admiten grupos anidados. La pertenencia a grupos se evalúa al solicitar el atributo informático tokenGroups, lo que significa que Horizon Cloud no tiene limitaciones de profundidad de anidamiento, pero admite lo que se establezca en Active Directory. Cuando se pregunta si hay consideraciones adicionales o limitaciones adicionales en el contexto de los grupos de Active Directory y la combinación de Horizon Cloud, Universal Broker y Workspace ONE Access Cloud, la respuesta es que no las hay. Si el entorno de arrendatario tiene pods Horizon Cloud en Microsoft Azure que ejecutan manifiestos anteriores a la versión de manifiesto 1600.0, la cuenta de unión de dominio y cualquier cuenta de unión de dominio auxiliar también debe estar en un grupo de administradores de Horizon Cloud, o en un grupo de Active Directory al que se conceda la función de superadministrador en Horizon Cloud. |
| ☐ | Unidad organizativa (OU) o unidades organizativas (OU) de Active Directory para escritorios virtuales y aplicaciones publicadas o escritorios basados en sesiones RDS, o ambos. En Microsoft Active Directory, cuando se crea una nueva unidad organizativa, el sistema puede establecer automáticamente el atributo |
Si desea utilizar una instancia de Active Directory configurada para LDAPS, debe solicitar que se habiliten las funciones compatibles con LDAPS con su tenant de Horizon Cloud. Para obtener más información, consulte Usar entornos de Active Directory configurados para LDAPS.
Configuración de Universal Broker
Para la configuración de Universal Broker, asegúrese de completar los elementos de la siguiente tabla que se apliquen a las opciones que desee. Para obtener más información, consulte Configurar Universal Broker.
| ☐ | El acceso saliente a Internet en las redes virtuales que está utilizando para el pod debe resolver y alcanzar nombres DNS específicos mediante protocolos y puertos específicos. Esto es necesario para las operaciones en curso y la configuración del Universal Broker. Para obtener una lista de los puertos y los nombres DNS, consulte 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. |
| ☐ | Según los tipos de conexiones de usuario final que desee proporcionar para:
|
| ☐ | Opcional. Si desea que Universal Broker aplique la autenticación en dos fases, los pods deben tener una instancia de Unified Access Gateway externa configurada para la autenticación en dos fases con uno de los tipos de sistema de autenticación compatibles para su uso con implementaciones de Horizon Cloud on Microsoft Azure. Universal Broker envía la solicitud de autenticación a Unified Access Gateway, que se comunica con el servidor de autenticación y, a continuación, retransmite la respuesta de nuevo a Universal Broker. Esa configuración de Unified Access Gateway externa requiere los siguientes elementos:
|
| ☐ | Opcional: un FQDN personalizado que los usuarios finales usarán para acceder al servicio del Universal Broker y el certificado basado en el FQDN. Si desea utilizar el FQDN de brokering proporcionado por VMware, no se requiere un FQDN personalizado. |
Requisitos de registros de DNS
Tras implementar el pod en la nube de Microsoft Azure y según la situación empresarial y las características que desee aprovechar, es importante configurar registros en el servidor DNS que asignen nombres de dominio completos (FQDN) a las direcciones IP relacionadas con el pod. Para obtener información de referencia sobre la asignación de registros de DNS, consulte la página de documentación de los servicios en la nube de Microsoft Configuración de un nombre de dominio personalizado para un servicio en la nube de Azure.
- Cuando se configura Universal Broker del arrendatario con un FQDN personalizado
-
☐ Cree un registro de DNS público que asigne el FQDN personalizado al FQDN de brokering proporcionado por VMware en la configuración de Universal Broker. Consulte Configurar el Universal Broker. - Cuando el pod tiene una instancia de Unified Access Gateway externa
-
☐ Cree un registro de DNS público para el acceso de usuarios finales externos que coincida con el FQDN en la configuración de la puerta de enlace externa. Este registro de DNS apunta el FQDN al equilibrador de carga externo de Microsoft Azure en la configuración de Unified Access Gateway externa del pod. Para obtener información general sobre la asignación de registros de DNS, consulte la página de documentación de Microsoft Configuración de un nombre de dominio personalizado para un servicio en la nube de Azure.
- Cuando el pod tiene una instancia de Unified Access Gateway interna
-
☐ Cree un registro de DNS interno para el acceso de usuarios finales internos que coincida con el FQDN en la configuración de la puerta de enlace interna. Este registro de DNS apunta el FQDN al equilibrador de carga interno de Microsoft Azure en la configuración de Unified Access Gateway interna del pod.
Imágenes maestras, escritorios y granjas de Horizon Cloud
La suscripción de Microsoft Azure debe incluir los siguientes requisitos según los tipos de imágenes maestras, los escritorios VDI y las granjas RDS que desee aprovisionar desde el pod implementado.
Tenga también en cuenta la siguiente matriz de compatibilidad para el uso de modelos de máquina virtual de Microsoft Azure de Generación 1 y Generación 2, con respecto a los sistemas operativos invitados Windows 10 y Windows 11.
| Modelo de máquina virtual de Azure | Windows 10 | Windows 11 |
|---|---|---|
| Máquina virtual de Generación 1 | Admitido | No admitido |
| Máquina virtual de Generación 2 | No admitido | Admitido |
| ☐ | Base para la imagen maestra, una o más de las configuraciones de máquina virtual de Microsoft Azure admitidas.
Cuando se crea una máquina virtual base con el asistente automatizado Importar máquina virtual - Catálogo de soluciones de la consola, el sistema utiliza de forma automática y predeterminada uno de los tamaños de máquina virtual anteriores. La opción predeterminada del sistema se basa en su configuración interna y el sistema operativo (SO) específico. El sistema utiliza los modelos indicados para las imágenes de un único pod y de varios pods. |
| ☐ | Selección de modelo para las máquinas virtuales de escritorio en las asignaciones de escritorios VDI: cualquiera de las configuraciones de máquina virtual de Microsoft Azure disponibles en la región de Microsoft Azure, excepto aquellas que no son compatibles con las operaciones de escritorio de Horizon Cloud. Para los entornos de producción, las pruebas de escala de VMware recomiendan el uso de modelos que tengan un mínimo de 2 CPU o más. |
| ☐ | Selección de modelo para las máquinas virtuales RDSH en granjas: cualquiera de las configuraciones de máquina virtual de Microsoft Azure disponibles en la región de Microsoft Azure, excepto aquellas que no son compatibles con las operaciones de granjas de RDS de Horizon Cloud. Este requisito también se aplica a las máquinas virtuales que ejecutan Microsoft Windows 10 Enterprise multisesión o Windows 11 Enterprise multisesión cuando se utilizan con Horizon Cloud. Como se describe en las preguntas frecuentes sobre Microsoft Windows Enterprise multisesión, en la documentación sobre Microsoft Azure Virtual Desktop, Microsoft Windows Enterprise multisesión es un tipo de host de sesión de escritorio remoto (RDSH) que permite mantener varias sesiones interactivas simultáneas, cosa que antes solo ofrecían los sistemas operativos Microsoft Windows Server. Los flujos de trabajo de Horizon Cloud que se aplican a los servidores RDS también pueden aplicarse a Microsoft Windows Enterprise multisesión. Para los entornos de producción, las pruebas de escala de VMware recomiendan el uso de modelos que tengan un mínimo de 2 CPU o más. |
Requisitos del Servicio de administración de imágenes (IMS)
A partir de la versión de julio de 2021, cuando los pods de Horizon Cloud ejecutan el manifiesto 2632 o una versión posterior y el arrendatario tiene Universal Broker habilitado, las funciones de Servicio de administración de imágenes de Horizon están disponibles para su uso con dichos pods. El uso de las funciones de imagen de varios pods proporcionadas por el servicio tiene requisitos adicionales. Para obtener detalles completos sobre los requisitos del sistema para el uso de dichas funciones, consulte la sección correspondiente a Microsoft Azure de Requisitos del sistema de Servicio de administración de imágenes de Horizon. En la siguiente tabla se detallan los requisitos adicionales sobre la suscripción del pod y el registro de la aplicación de Horizon Cloud y su entidad de servicio de dicha suscripción cuando se utilizan imágenes de varios pods.
| ☐ | Las suscripciones que utilizan los pods que participan en imágenes de varios pods deben estar dentro de un solo arrendatario de Microsoft Azure Active Directory (AAD). |
| ☐ | La entidad de servicio del registro de la aplicación de Horizon Cloud utilizada por los pods que participan en imágenes de varios pods debe cumplir uno de los siguientes requisitos:
Dado que es probable que los pods estén en suscripciones diferentes, el requisito de acceso de lectura permite que la suscripción de cada pod participante tenga conexión directa con las suscripciones de los otros pods participantes. Esta conexión directa es necesaria para que el servicio utilice las funciones de Azure Shared Image Gallery para crear imágenes de varios pods. |
| ☐ | Todas las funciones personalizadas utilizadas por las entidades de servicio de los pods participantes deben incluir los siguientes permisos relacionados con el uso de Azure Shared Image Gallery.
|
Concesión de licencias para los sistemas operativos Microsoft Windows
Los elementos están relacionados con los sistemas operativos Microsoft Windows en las máquinas virtuales importadas, las imágenes maestras, las máquinas virtuales de granja compatibles con RDSH y las máquinas virtuales de escritorio virtual. Para obtener la lista de sistemas operativos Microsoft Windows compatibles con Horizon Cloud, consulte el artículo 78170 de la base de conocimientos de VMware y el artículo 70965 de la base de conocimientos de VMware.
Horizon Cloud no ofrece ninguna licencia de sistema operativo invitado que requiera el uso de los sistemas operativos Microsoft Windows que se utilizan en el uso de los flujos de trabajo de Horizon Cloud. Usted, el cliente, tiene la responsabilidad de tener licencias válidas y aptas de Microsoft que le permitan crear, realizar flujos de trabajo en, y utilizar las máquinas virtuales RDSH y las máquinas virtuales de escritorio basadas en Windows que elija utilizar en su entorno de arrendatario de Horizon Cloud. Las licencias requeridas dependen del uso que se pretenda realizar.
| ☐ | Concesión de licencias para uno o varios de los siguientes tipos: Microsoft Windows 7 Enterprise, Microsoft Windows 10 y Microsoft Windows 11 (sesión única, tipos de cliente VDI) |
| ☐ | Concesión de licencias para Microsoft Windows 10 Enterprise multisesión o Microsoft Windows 11 Enterprise multisesión |
| ☐ | Concesión de licencias para uno o varios de los siguientes tipos: Microsoft Windows Server 2012 R2, Microsoft Server 2016, Microsoft Server 2019 |
| ☐ | Servidores de licencias de Microsoft Windows RDS: para alta disponibilidad, se recomiendan servidores de licencias redundantes |
| ☐ | CAL de dispositivo o usuario de Microsoft RDS o ambos |
Arquitectura de referencia
Utilice los diagramas de la arquitectura que aparecen a continuación a modo de referencia.
