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. Si sigue esta lista de comprobación, podrá ejecutar correctamente el implementador de pods y completar las tareas del día 1.

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 fecha de publicación de la versión de servicio, el 20 de octubre de 2022. 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
  • Cuenta de arrendatario del plano de control
  • Elementos de suscripción de Microsoft Azure
  • Redes
  • Puertos y protocolos
  • Elementos de Unified Access Gateway opcionales
  • Active Directory
  • Unified Access Gateway opcional (agregado después de la implementación)
  • Universal Broker
  • Registros de DNS
  • Capacidades de imágenes maestras, escritorios y granjas
  • Licencias de sistema operativo de Microsoft Windows

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 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 Contributor se asigna en el nivel de suscripción del pod.

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 Contributor para la entidad de servicio de esa suscripción de puerta de enlace.

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).
Pod
  • Administradores de pods: 2 Standard_D4_v3 (en ausencia de Standard_D4_v3 en la región, utilizar 2 Standard_D3_v2)
  • Base de datos de Microsoft Azure para el servicio PostgreSQL: generación 5, memoria optimizada, 2 VCore, almacenamiento de 10 GB
  • Cuando el pod ya está listo para utilizarse, su capacidad en la nube de Microsoft Azure también tendrá que incorporar las máquinas virtuales importadas, las imágenes maestras, los escritorios virtuales, las granjas RDSH y las máquinas virtuales de captura de aplicación de App Volumes que cree en ese pod. Consulte la sección siguiente Imágenes base, escritorios y granjas de Horizon Cloud.
  • Cuando la cuenta de arrendatario está habilitada para utilizar la función de Supervisión de la infraestructura de Horizon y está pensando habilitar esa función en el pod tras implementar el pod, la capacidad también tendrá que admitir en ese momento la implementación de Dispositivo virtual de Horizon Edge. Consulte la sección Requisitos de supervisión de la infraestructura de Horizon a continuación.
  • En una situación especial en la que se abre una solicitud de soporte y el equipo de soporte de VMware determina que la forma de abordar esa solicitud es implementar temporalmente una máquina virtual de Jump Box relacionada con la asistencia, su capacidad tendrá que acomodar la implementación de una máquina virtual de modelo Standard_F2 en ese momento.
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.
Instancia de Unified Access Gateway externa en la misma red virtual del pod
2 x Standard_A4_v2 o 2 x Standard_F8s_v2
Instancia de Unified Access Gateway externa en su propia red virtual
  • Conector de puerta de enlace externa: 1 Standard_A1_v2
  • Instancias de Unified Access Gateway externas: 2 x Standard_A4_v2 o 2 x Standard_F8s_v2.
Unified Access Gateway interno
2 x Standard_A4_v2 o 2 x Standard_F8s_v2

Si no se proporciona la región de la suscripción para los tamaños de Standard_F8s_v2 VM, el asistente del implementador de pods no mostrará esa opción en el selector del paso del asistente Especificar puertas de enlace.

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 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.
  • Subred de administración: /27 (mínimo)
  • Subred de la máquina virtual - Principal (arrendatario): /27 como mínimo con /24 - /22 preferido, en función del número de escritorios y servidores RDS
  • Subred DMZ: /28 mínimo cuando se implementa Unified Access Gateway en la VNet del pod (opcional)
Las subredes pueden crearse manualmente en la VNet o mediante Horizon Cloud durante la implementación. Si utiliza subredes creadas manualmente, no se pueden asociar otros recursos.
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.
  • Subred de administración: /27 (mínimo)
  • Subred del back-end: /27 como mínimo con /24 - /22 preferido, en función del número de escritorios y servidores RDS
  • Subred DMZ (front-end): /28 como mínimo
Las subredes pueden crearse manualmente en la VNet o mediante Horizon Cloud durante la implementación. Si utiliza subredes creadas manualmente, no se pueden asociar otros recursos. Para este caso práctico, por lo general, las subredes se crean manualmente. En este caso práctico, el propósito de la subred de back-end es similar al de la Subred de máquina virtual (principal) que se describe en la fila de la tabla anterior.
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:

  • Direcciones de DNS para Unified Access Gateway para resolver el nombre del servidor de autenticación
  • Rutas de Unified Access Gateway para resolver el enrutamiento de red al servidor de autenticación
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 Implementación del primer pod de Horizon Cloud on Microsoft Azure: flujo de trabajo 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
  • Servidor local de Active Directory conectado a través de un VPN/Express Route
  • Servidor de Active Directory ubicado en Microsoft Azure
  • Servicios de dominio de Active Directory de Microsoft Azure.
Niveles funcionales de dominios de Active Directory Domain Services (AD DS) de Microsoft Windows admitidos:
  • Microsoft Windows Server 2008 R2
  • Microsoft Windows Server 2012 R2
  • Microsoft Windows Server 2016
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.
Cuenta de enlace de dominio
Cuenta de enlace de dominio de Active Directory (usuario estándar con acceso de lectura) que tiene el atributo sAMAccountName. El atributo sAMAccountName debe tener 20 caracteres o menos, y no puede contener ninguno de los siguientes caracteres: "/ \ [ ] : ; | = , + * ? < >

La cuenta debe tener los siguientes permisos:

  • Mostrar contenido
  • Lectura de todas las propiedades
  • Permisos de lectura
  • Lectura de tokenGroupsGlobalAndUniversal (implícito en Lectura de todas las propiedades)

También debe establecer la contraseña de la cuenta en Nunca caducar para garantizar el acceso continuado al inicio de sesión en el entorno de Horizon Cloud.

  • Si está familiarizado con las opciones de VMware Horizon local, puede ver que los permisos anteriores constituyen el mismo conjunto que se requiere para las cuentas de credenciales secundarias de dicha versión.
  • Por lo general, se debe conceder a las cuentas de enlace de dominio los permisos de acceso de lectura predeterminados que se conceden normalmente a los Usuarios autenticados en una implementación de Microsoft Active Directory. Sin embargo, si los administradores de AD de su organización han decidido bloquear los permisos relacionados con el acceso de lectura para los usuarios normales, debe solicitar que los administradores de AD conserven los valores predeterminados estándar de los Usuarios autenticados para las cuentas de enlace de dominio que utilizará para Horizon Cloud.

Referencia: Cuentas de servicio que requiere Horizon Cloud para sus operaciones

Cuenta auxiliar de enlace de dominio
Debe ser independiente de la cuenta de enlace de dominio principal. La interfaz de usuario impedirá que se vuelva a utilizar la misma cuenta en ambos campos.

Cuenta de enlace de dominio de Active Directory (usuario estándar con acceso de lectura) que tiene el atributo sAMAccountName. El atributo sAMAccountName debe tener 20 caracteres o menos, y no puede contener ninguno de los siguientes caracteres: "/ \ [ ] : ; | = , + * ? < >

La cuenta debe tener los siguientes permisos:

  • Mostrar contenido
  • Lectura de todas las propiedades
  • Permisos de lectura
  • Lectura de tokenGroupsGlobalAndUniversal (implícito en Lectura de todas las propiedades)

También debe establecer la contraseña de la cuenta en Nunca caducar para garantizar el acceso continuado al inicio de sesión en el entorno de Horizon Cloud.

  • Si está familiarizado con las opciones de VMware Horizon local, puede ver que los permisos anteriores constituyen el mismo conjunto que se requiere para las cuentas de credenciales secundarias de dicha versión.
  • Por lo general, se debe conceder a las cuentas de enlace de dominio los permisos de acceso de lectura predeterminados que se conceden normalmente a los Usuarios autenticados en una implementación de Microsoft Active Directory. Sin embargo, si los administradores de AD de su organización han decidido bloquear los permisos relacionados con el acceso de lectura para los usuarios normales, debe solicitar que los administradores de AD conserven los valores predeterminados estándar de los Usuarios autenticados para las cuentas de enlace de dominio que utilizará para Horizon Cloud.

Referencia: Cuentas de servicio que requiere Horizon Cloud para sus operaciones

Cuenta de unión de dominio
Cuenta de unión de dominio de Active Directory que puede utilizar el sistema para realizar operaciones de Sysprep y unir los equipos virtuales al dominio. Por lo general, es una nueva cuenta que se crea para este propósito explícito. (Una cuenta de usuario de unión de dominio)

La cuenta debe tener el atributo sAMAccountName. El atributo sAMAccountName debe tener 20 caracteres o menos, y no puede contener ninguno de los siguientes caracteres: "/ \ [ ] : ; | = , + * ? < >

Actualmente, no se admite el uso de espacios en blanco en el nombre de usuario de la cuenta.

También debe establecer la contraseña de la cuenta en Nunca caducar para garantizar la capacidad permanente de Horizon Cloud para realizar las operaciones de Sysprep y unir los equipos virtuales al dominio.

Esta cuenta requiere los siguientes permisos de Active Directory, que se aplican a la unidad organizativa Equipos o a la unidad organizativa que se especifique en la interfaz de usuario de unión de dominio de la consola.

  • Leer todas las propiedades: Solo este objeto
  • Crear objetos de equipo: Este objeto y todos los descendientes
  • Eliminar objetos de equipo: Este objeto y todos los descendientes
  • Escribir todas las propiedades: Objetos de equipo descendientes
  • Restablecer contraseña: Objetos de equipo descendientes

En relación con la unidad organizativa (OU) de destino que planea usar para las granjas y las asignaciones de escritorios VDI, esta cuenta también requiere el permiso de Active Directory denominado Escribir todas las propiedades en todos los objetos descendientes de esa unidad organizativa (OU) de destino.

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 Prevent Accidental Deletion, que aplica un Deny al permiso para eliminar todos los objetos secundarios para la unidad organizativa recién creada y todos los objetos descendientes. Como resultado, si asigna de forma explícita el permiso para eliminar objetos de equipo a la cuenta de unión al dominio, en el caso de una unidad organizativa recién creada, Active Directory podría haber aplicado un reemplazo al permiso para eliminar objetos de equipo asignado explícitamente. Dado que borrar la marca para Evitar la eliminación accidental no borra automáticamente el Deny que Active Directory aplicó al permiso para eliminar todos los objetos secundarios, en el caso de una unidad organizativa recién agregada, es posible que tenga que verificar y borrar manualmente el conjunto de permisos Deny para eliminar todos los objetos secundarios en la unidad organizativa y todas las unidades organizativas secundarias antes de usar la cuenta de unión al dominio en Horizon Cloud.

Cuenta de unión de dominio auxiliar opcional
Cuenta de unión de dominio de Active Directory que puede utilizar el sistema para realizar operaciones de Sysprep y unir los equipos virtuales al dominio. Por lo general, es una nueva cuenta que se crea para este propósito explícito. (Una cuenta de usuario de unión de dominio)

La cuenta debe tener el atributo sAMAccountName. El atributo sAMAccountName debe tener 20 caracteres o menos, y no puede contener ninguno de los siguientes caracteres: "/ \ [ ] : ; | = , + * ? < >

Actualmente, no se admite el uso de espacios en blanco en el nombre de usuario de la cuenta.

También debe establecer la contraseña de la cuenta en Nunca caducar para garantizar la capacidad permanente de Horizon Cloud para realizar las operaciones de Sysprep y unir los equipos virtuales al dominio.

Esta cuenta requiere los siguientes permisos de Active Directory, que se aplican a la unidad organizativa Equipos o a la unidad organizativa que se especifique en la interfaz de usuario de unión de dominio de la consola.

  • Leer todas las propiedades: Solo este objeto
  • Crear objetos de equipo: Este objeto y todos los descendientes
  • Eliminar objetos de equipo: Este objeto y todos los descendientes
  • Escribir todas las propiedades: Objetos de equipo descendientes
  • Restablecer contraseña: Objetos de equipo descendientes

En relación con la unidad organizativa (OU) de destino que planea usar para las granjas y las asignaciones de escritorios VDI, esta cuenta también requiere el permiso de Active Directory denominado Escribir todas las propiedades en todos los objetos descendientes de esa unidad organizativa (OU) de destino.

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 Prevent Accidental Deletion, que aplica un Deny al permiso para eliminar todos los objetos secundarios para la unidad organizativa recién creada y todos los objetos descendientes. Como resultado, si asigna de forma explícita el permiso para eliminar objetos de equipo a la cuenta de unión al dominio, en el caso de una unidad organizativa recién creada, Active Directory podría haber aplicado un reemplazo al permiso para eliminar objetos de equipo asignado explícitamente. Dado que borrar la marca para Evitar la eliminación accidental no borra automáticamente el Deny que Active Directory aplicó al permiso para eliminar todos los objetos secundarios, en el caso de una unidad organizativa recién agregada, es posible que tenga que verificar y borrar manualmente el conjunto de permisos Deny para eliminar todos los objetos secundarios en la unidad organizativa y todas las unidades organizativas secundarias antes de usar la cuenta de unión al dominio en Horizon Cloud.

Grupos de Active Directory

  • Administradores de Horizon Cloud: grupo de seguridad de Active Directory para administradores de Horizon Cloud. Contiene los usuarios administrativos de Horizon Cloud. A este grupo se le concede la función de superadministrador en Horizon Cloud.
  • Horizon Cloud usuarios: grupo de seguridad de Active Directory para los usuarios que tendrán acceso a los escritorios virtuales y a las aplicaciones publicadas y los escritorios basados en sesiones RDS en Horizon Cloud.

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 Prevent Accidental Deletion, que aplica un Deny al permiso para eliminar todos los objetos secundarios para la unidad organizativa recién creada y todos los objetos descendientes. Como resultado, si asigna de forma explícita el permiso para eliminar objetos de equipo a la cuenta de unión al dominio, en el caso de una unidad organizativa recién creada, Active Directory podría haber aplicado un reemplazo al permiso para eliminar objetos de equipo asignado explícitamente. Dado que borrar la marca para Evitar la eliminación accidental no borra automáticamente el Deny que Active Directory aplicó al permiso para eliminar todos los objetos secundarios, en el caso de una unidad organizativa recién agregada, es posible que tenga que verificar y borrar manualmente el conjunto de permisos Deny para eliminar todos los objetos secundarios en la unidad organizativa y todas las unidades organizativas secundarias antes de usar la cuenta de unión al dominio en Horizon Cloud.

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 Requisitos de DNS para un pod de Horizon Cloud en Microsoft y las funciones de servicio relacionadas y Pod de Horizon Cloud: requisitos de puertos y protocolos.
Según los tipos de conexiones de usuario final que desee proporcionar para:
  • Para las conexiones de usuario final desde Internet y el inicio de sus aplicaciones y escritorios virtuales, un pod debe tener una instancia de Unified Access Gateway externa configurada.
  • Si todas las conexiones de usuario final se realizarán siempre desde la red interna, no se requiere ninguna instancia de Unified Access Gateway en el pod, excepto cuando se desea que Universal Broker aplique la autenticación en dos fases con esas conexiones internas de usuario final.
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:

  • Direcciones de DNS para Unified Access Gateway para resolver el nombre del servidor de autenticación
  • Rutas de Unified Access Gateway para resolver el enrutamiento de red al servidor de autenticación
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.

Nota: Si ha implementado el pod con configuraciones de puerta de enlace interna y externa que tienen el mismo FQDN, tras la implementación del pod, configure 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.
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.

Nota: Cuando la cuenta está habilitada para utilizar las funciones de App Volumes y se utiliza la acción Captura de la consola para agregar aplicaciones App Volumes al inventario, el sistema genera una asignación de escritorios de dos máquinas virtuales de escritorio para admitir ese flujo de trabajo de captura. Su capacidad también tendrá que admitir la creación de esos escritorios mientras realiza el flujo de trabajo de captura. Puede eliminar esa asignación de escritorios cuando haya terminado de capturar aplicaciones para su entorno.

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.
  • Standard_DS2_v2
  • Standard_NV12s_v3 (para el asistente automatizado Importar máquina virtual desde Marketplace o la importación manual del servicio, y el controlador de gráficos NVIDIA GRID) y Standard_NV8as_v4 (para el método de importación manual y el controlador de gráficos AMD)
  • Standard_D4s_v3

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.

El asistente Importar máquina virtual desde Marketplace crea lo siguiente:
  • Una máquina virtual Standard_DS2_v2 sin GPU ni Windows 11
  • Una máquina virtual Standard_D4s_v3 sin GPU con Windows 11
  • Una máquina virtual Standard_NV12s_v3 compatible con GPU
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:
  • Se utiliza la misma entidad de servicio en todos los pods y las suscripciones participantes.
  • Cada entidad de servicio debe tener acceso de lectura a cada suscripción de Microsoft Azure utilizada por los pods participantes.

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.
  • Microsoft.Compute/galleries/read
  • Microsoft.Compute/galleries/write
  • Microsoft.Compute/galleries/delete
  • Microsoft.Compute/galleries/images/*
  • Microsoft.Compute/galleries/images/versions/*

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.

Sugerencia: Para obtener información sobre las licencias de Microsoft Azure Virtual Desktop para Windows 11 Enterprise multisesión, Windows 10 Enterprise multisesión y Windows 7 Enterprise, consulte el tema Precios de Azure Virtual Desktop de la documentación de Microsoft Azure.
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

Requisitos de supervisión de la infraestructura de Horizon

Si el arrendatario de Horizon Cloud está habilitado para utilizar Supervisión de la infraestructura de Horizon, puede utilizar Horizon Universal Console para activar la función en los pods que elija. Cuando se elige activar la función en un pod, el sistema crea automáticamente un dispositivo virtual en la misma suscripción a Microsoft Azure en la que reside el pod y configura dicho dispositivo para que recopile los datos de la infraestructura. Para poder activar esta función de supervisión, el arrendatario debe incorporarse a VMware Cloud Services. Consulte Incorporar el arrendatario de Horizon Cloud a VMware Cloud Services mediante la consola administrativa de Horizon y Supervisión de la infraestructura de Horizon y los pods del entorno de Horizon Cloud.

Incorpore el arrendatario a VMware Cloud Services.
Para cada pod en el que se activará la función Supervisión de la infraestructura de Horizon, la suscripción de Microsoft Azure del pod debe cumplir estos requisitos adicionales.
  • Dispositivo virtual de Horizon Edge: 1 x Standard_D4_v3

Arquitectura de referencia

Utilice los diagramas de la arquitectura que aparecen a continuación a modo de referencia.

Figura 1. Ilustración de la Arquitectura Cloud Pod de Horizon de un pod con configuraciones de puerta de enlace externa e interna, con la puerta de enlace externa implementada en la misma VNet que el pod, tres NIC en las máquinas virtuales de puerta de enlace externa, dos NIC en las máquinas virtuales de puerta de enlace interna y una IP pública habilitada para el equilibrador de carga de la puerta de enlace externa.

Ilustración de la arquitectura de los grupos de recursos, las máquinas virtuales y las subredes de un pod que tiene dos tipos de configuraciones de Unified Access Gateway. La puerta de enlace externa reside en la misma VNet que el pod.

Figura 2. Ilustración de los elementos de la arquitectura de puerta de enlace externa cuando la puerta de enlace externa se implementa en su propia red virtual, independiente de la red virtual del pod, con tres NIC, y en un grupo de recursos creado por el implementador de pods

Ilustración de los elementos de la arquitectura de puerta de enlace externa cuando la puerta de enlace externa se implementa en su propia red virtual, independiente de la red virtual del pod, y en un grupo de recursos creado por el implementador de pods