Esta lista de comprobación le guiará para preparar las suscripciones y las redes de Microsoft Azure para la implementación de un pod de Horizon Cloud en Microsoft Azure. Si se asegura de que estos requisitos se cumplan como se describe a continuación, podrá completar una implementación correcta del pod nuevo y también completar correctamente las tareas clave que se requieren para finalizar después de implementar un pod.

Esta lista de comprobación se utiliza principalmente para cuentas de clientes de Horizon Cloud que nunca hayan implementado un pod localmente o conectados a la nube a su entorno de arrendatario antes de la fecha de publicación de la versión de servicio de julio de 2021. Estos entornos se pueden denominar entornos limpios o entornos nuevos. Las nuevas implementaciones de pod que se produzcan después de que los binarios del plano de nube y las nuevas versiones de manifiesto del pod se envíen al plano de nube en la fecha de publicación de la versión de servicio se implementarán con la nueva versión de manifiesto del pod. Los requisitos para la implementación correcta de un pod están determinados principalmente por la versión de manifiesto del pod. Los archivos binarios del plano de nube que se encuentran en el plano de nube de producción también pueden determinar los requisitos para una implementación correcta.

Algunos de los requisitos enumerados a continuación son los necesarios para la implementación del pod. Algunos requisitos son los que se necesitan para las tareas clave que se realizan después de la implementación de pod para obtener un entorno de arrendatario productivo y poder proporcionar aplicaciones y escritorios aprovisionados mediante un pod a los usuarios finales.

Requisitos para la propia implementación del pod
Requisitos para un entorno productivo después de la implementación de un pod
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 del plano de control de Horizon Cloud

Cuenta de My VMware activa para iniciar sesión en el plano de control de Horizon Cloud.

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, necesitará una suscripción de Microsoft Azure válida adicional 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 de Microsoft Azure válidos en esa suscripción de Microsoft Azure. Para obtener más información, consulte Introducción al control de acceso basado en funciones en el portal de Azure en la documentación de Microsoft.
Capacidad mínima de Microsoft Azure disponible para la infraestructura de Horizon Cloud, además de la carga de trabajo de aplicaciones y escritorios esperada. Tenga en cuenta que, siempre que esta capacidad esté disponible, Horizon Cloud implementará automáticamente estas máquinas virtuales y no se requerirá ninguna instalación manual.
  • Motor de implementación de pods, también conocido como Jump Box (transitorio): 1 Standard_F2
  • Pod/administrador de pods con alta disponibilidad habilitada: 2 Standard_D4_v3 (si ningún Standard_D4_v3 está en la región, 2 Standard_D3_v2)
  • Pod/administrador de pods sin alta disponibilidad habilitada: 1 Standard_D4_v3 (si ningún Standard_D4_v3 está en la región, 1 Standard_D3_v2)
  • Base de datos de Microsoft Azure para el servicio PostgreSQL: generación 5, memoria optimizada, 2 VCore, almacenamiento de 10 GB
  • Instancias de Unified Access Gateway externas (opcional, a menos que no se especifique ninguna puerta de enlace interna): 2 x Standard_A4_v2 o 2 x Standard_F8s_v2
  • Instancias de Unified Access Gateway internas (opcional, a menos que no se especifique ninguna puerta de enlace externa): 2 x Standard_A4_v2 o 2 x Standard_F8s_v2
Importante: Como se indica en Límites del servicio de VMware Horizon Cloud Service on Microsoft Azure, 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. Utilice F8s_v2 si prevé que el entorno se amplíe a más de 1000 sesiones activas por pod.
  • A partir de la versión de servicio de julio de 2020, en entornos limpios, 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. Como resultado, la capacidad mínima de Microsoft Azure disponible debe alojar las máquinas virtuales para una de las configuraciones de puerta de enlace, como se describe en la lista anterior.
  • Si no se proporciona la región de la suscripción para los tamaños de máquina virtual Standard_F8s_v2, el asistente del implementador de pods no muestra esa opción en el selector del paso del asistente Especificar puertas de enlace.
  • Una vez finalizada la implementación del pod, 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 y las granjas RDSH que cree en ese pod. Cuando la cuenta está habilitada para utilizar funciones de App Volumes y se utiliza el flujo de trabajo de captura de aplicaciones de la consola, la capacidad también tendrá que alojar las máquinas virtuales en la asignación de escritorios generados por el sistema que se utiliza para ese proceso de captura. 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.

La Unified Access Gateway externa se puede implementar de forma opcional en su propia red virtual (VNet) de Microsoft Azure, ya sea usando la misma suscripción que el pod o mediante una suscripción diferente. Cuando se implementa la instancia de Unified Access Gateway externa en su propia red virtual, se necesita la capacidad siguiente en la suscripción que utiliza la Unified Access Gateway externa:

  • Motor de implementación de Unified Access Gateway externa, también conocido como Jump Box de puerta de enlace (transitorio), 1 Standard_F2
  • 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.
Importante: Repita este texto aquí para que quede claramente visible en esta área acerca de la implementación opcional de la puerta de enlace externa en una VNet independiente. Como se indica en Límites del servicio de VMware Horizon Cloud Service on Microsoft Azure, 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. Utilice F8s_v2 si prevé que el entorno se amplíe a más de 1000 sesiones activas por pod.
Entidad de servicio y clave de autenticación creadas para cada suscripción. Para obtener detalles adicionales, consulte Utilizar un portal para crear una aplicación de Azure Active Directory y la entidad de servicio que puede acceder a recursos. Consulte también Crear la entidad de servicio requerida que necesita el implementador de pods de Horizon Cloud mediante la creación de un registro de aplicaciones.
A cada entidad de servicio se le debe asignar la función adecuada que permite las acciones que Horizon Cloud debe realizar en la suscripción. Esta puede ser una función de Colaborador o una función personalizada con las acciones permitidas requeridas en el nivel de la suscripción. Cuando se implementa la configuración de puerta de enlace externa en un grupo de recursos existente en una suscripción independiente, se pueden establecer permisos más detallados para la entidad de servicio de esa suscripción. Para obtener más información sobre las acciones de función requeridas, consulte Operaciones requeridas por Horizon Cloud en las suscripciones de Microsoft Azure.
Importante: La función debe asignarse directamente a la entidad de servicio utilizada para Horizon Cloud. El uso de una asignación basada en grupos de una función a la entidad de servicio (en la que la función está asignada a un grupo y la entidad de servicio es miembro de ese grupo) no se admite.
Proveedores de recursos necesarios registrados en cada suscripción de Microsoft Azure. Consulte Proveedores de recursos que Horizon Cloud requiere que deben estar en estado registrado en la suscripción de Microsoft Azure.
ID de suscripción de Microsoft Azure, ID de directorio, ID de aplicación y clave identificados.
Si va a implementar la instancia de Unified Access Gateway externa en una red virtual independiente con su propia suscripción y su organización requiere el uso de un grupo de recursos controlado por usted que no haya creado el implementador de pods, utilizará la función para implementar la instancia de Unified Access Gateway externa en su propio grupo de recursos con nombre. El uso de esa 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 de actualización del pod estándar. Para obtener más información acerca de los permisos necesarios, consulte Operaciones requeridas por Horizon Cloud en las suscripciones de Microsoft Azure.

Requisitos de red

La red virtual (VNet) de Microsoft Azure creada en la región de Microsoft Azure deseada con el espacio de direcciones aplicable para cubrir las subredes requeridas. Para obtener más información, consulte Red virtual de 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.
Nota: Para los pods implementados nuevos en el manifiesto 2298.0 o una versión posterior, después de implementar el pod, puede editarlo para agregar subredes de arrendatario adicionales para 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 información, consulte la Guía de administración.
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 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 Requisitos de puertos y protocolos para un pod de Horizon Cloud en el manifiesto de la versión de septiembre de 2019 o posterior.
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)
VPN/Express Route de Microsoft Azure configurada (opcional)
FQDN para el acceso de usuario interno, externo o ambos (se requiere cuando se implementa un pod con Unified Access Gateway).
Nota: A partir del 15 de diciembre de 2020, se admite la actualización del plano de nube con FQDN diferentes para y las configuraciones de puerta de enlace interna y puerta de enlace externa del pod. Antes del 15 de diciembre de 2020, el sistema aplica el mismo FQDN para un pod de manifiesto 2298 y versiones posteriores. Ahora el usuario decide si desea que las puertas de enlace del pod utilicen FQDN diferentes o el mismo FQDN. Si desea usar el mismo FQDN en las dos puertas de enlace, tras la implementación del pod, debe 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.
Certificado o certificados para Unified Access Gateway en formato PEM que coincide con el FQDN (se requiere para implementar un pod con Unified Access Gateway).
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.
Autenticación de dos factores a un servidor de autenticación RADIUS local (opcional)
  • 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, cuando se planea establecer el entorno que va a utilizar Universal Broker para realizar el brokering de los escritorios de los usuarios finales, se necesita una configuración adicional cuando se desea omitir la autenticación en dos fases para los usuarios finales en la red interna. Las instancias internas de Unified Access Gateway del pod dirigen las solicitudes de conexión a las aplicaciones y los escritorios virtuales con los usuarios finales internos. Cuando tenga una configuración de puerta de enlace interna en el pod, si se tiene pensado configurar el entorno para que use Universal Broker y se desea realizar una autenticación en dos fases para los usuarios finales externos, pero omitir la autenticación en dos fases para los usuarios finales internos, después de implementar el pod deberán introducirse rangos de IP para que Universal Broker los utilice para identificar a los usuarios finales internos de los usuarios finales externos, a fin de omitir la autenticación en dos fases. Para obtener más información, consulte el tema de la documentación Configurar un método de brokering y asignaciones de usuarios finales en el entorno de arrendatario de Horizon Cloud y sus subtemas.

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 Requisitos de puertos y protocolos para un pod de Horizon Cloud en el manifiesto de la versión de septiembre de 2019 o posterior.

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 Flujo de trabajo de nivel general para agregar un pod de Horizon en Microsoft Azure como primer pod al entorno de arrendatario de Horizon Cloud 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 requiere los elementos que se indican a continuación. Para obtener información 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. Puede ver la lista de comprobación para estos pods de Horizon en Lista de comprobación de requisitos de pods de VMware Horizon con Horizon Cloud: actualizada según corresponda para conectar los pods a partir de la versión de servicio de julio de 2021.
Importante: Lea Cuentas de servicio que requiere Horizon Cloud para sus operaciones para ver las características clave que debe tener esta cuenta.

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)
  • 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, tal y como se indica en este tema de la documentación de Horizon local.
  • 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.

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.

Para obtener más detalles y requisitos, consulte Cuentas de servicio que requiere Horizon Cloud para sus operaciones

Importante: Lea Cuentas de servicio que requiere Horizon Cloud para sus operaciones para ver las características clave que debe tener esta cuenta.

Cuenta de enlace de dominio auxiliar: no se puede utilizar la misma cuenta que la anterior

  • 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)
  • 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, tal y como se indica en este tema de la documentación de Horizon local.
  • 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.

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.

Importante: Lea Cuentas de servicio que requiere Horizon Cloud para sus operaciones para ver las características clave que debe tener esta cuenta.

Cuenta de unión de dominio

  • Cuenta de unión de dominio de Active Directory que el sistema puede utilizar para realizar operaciones de Sysprep y unir equipos al dominio, normalmente una cuenta nueva (cuenta de usuario de unión de dominio)
  • La cuenta debe tener el nombre sAMAccountName. El atributo sAMAccountName debe tener 20 caracteres o menos, y no puede contener ninguno de los siguientes caracteres: "/ \ [ ] : ; | = , + * ? < >
  • Establecer la contraseña de la cuenta en Nunca caducar
  • Esta cuenta requiere los siguientes permisos de Active Directory: leer todas las propiedades, restablecer contraseña, crear objetos de equipo, eliminar objetos de equipo, escribir todas las propiedades
    Nota: A partir del manifiesto del pod 2474.0, los permisos necesarios para la cuenta de unión de dominio se reducen del conjunto anterior utilizado para los manifiestos anteriores a 2474 y ahora incluyen la escritura de todas las propiedades en objetos de equipos descendientes. Los pods que ejecutan manifiestos anteriores aún requieren el conjunto anterior de permisos. Para obtener más información, consulte Cuentas de servicio que requiere Horizon Cloud para sus operaciones.
  • Esta cuenta también requiere el permiso de Active Directory para escribir todas las propiedades en todos los objetos descendientes de unidad organizativa de la unidad organizativa (OU) de destino que vaya a utilizar para las asignaciones de escritorios VDI y granjas.
  • Para obtener más detalles y requisitos, consulte Cuentas de servicio que requiere Horizon Cloud para sus operaciones
Nota:
  • Actualmente, no se admite el uso de espacios en blanco en el nombre de usuario de la cuenta. Si el nombre contiene un espacio en blanco, se producirán resultados inesperados en las operaciones del sistema que dependen de esa cuenta.
  • 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.
  • Antes de la versión de manifiesto 1600.0, esta cuenta requería los permisos de la función de superadministrador del sistema. Si el entorno de arrendatario tiene pods de Horizon Cloud en Microsoft Azure que ejecutan manifiestos anteriores a la versión de manifiesto 1600.0, la cuenta de unión al dominio debe estar en el grupo de administradores de Horizon Cloud descrito. El sistema utiliza esta cuenta de unión al dominio con todos los pods de Horizon Cloud del arrendatario en Microsoft Azure. Cuando el arrendatario tiene pods de manifiestos anteriores a la versión 1600.0, la cuenta de unión al dominio debe cumplir este requisito. Para obtener más información, consulte Cuentas de servicio que requiere Horizon Cloud para sus operaciones.
Importante: Lea Cuentas de servicio que requiere Horizon Cloud para sus operaciones para ver las características clave que debe tener esta cuenta.

Cuenta de unión de dominio auxiliar (opcional; no se puede utilizar la misma cuenta que la anterior)

  • Cuenta de unión de dominio de Active Directory que el sistema puede utilizar para realizar operaciones de Sysprep y unir equipos al dominio, normalmente una cuenta nueva (cuenta de usuario de unión de dominio)
  • La cuenta debe tener el nombre sAMAccountName. El atributo sAMAccountName debe tener 20 caracteres o menos, y no puede contener ninguno de los siguientes caracteres: "/ \ [ ] : ; | = , + * ? < >
  • Establecer la contraseña de la cuenta en Nunca caducar
  • Esta cuenta requiere los siguientes permisos de Active Directory: leer todas las propiedades, restablecer contraseña, crear objetos de equipo, eliminar objetos de equipo, escribir todas las propiedades
    Nota: A partir del manifiesto del pod 2474.0, los permisos necesarios para la cuenta de unión de dominio se reducen del conjunto anterior utilizado para los manifiestos anteriores a 2474 y ahora incluyen la escritura de todas las propiedades en objetos de equipos descendientes. Los pods que ejecutan manifiestos anteriores aún requieren el conjunto anterior de permisos. Para obtener más información, consulte Cuentas de servicio que requiere Horizon Cloud para sus operaciones.
  • Esta cuenta también requiere el permiso de Active Directory para escribir todas las propiedades en todos los objetos descendientes de unidad organizativa de la unidad organizativa (OU) de destino que vaya a utilizar para escritorios virtuales VDI y granjas.
  • Para obtener más detalles y requisitos, consulte Cuentas de servicio que requiere Horizon Cloud para sus operaciones
Nota:
  • Actualmente, no se admite el uso de espacios en blanco en el nombre de usuario de la cuenta. Si el nombre contiene un espacio en blanco, se producirán resultados inesperados en las operaciones del sistema que dependen de esa cuenta.
  • 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.
  • Antes de la versión de manifiesto 1600.0, esta cuenta requería los permisos de la función de superadministrador del sistema. Si el entorno de arrendatario tiene pods de Horizon Cloud en Microsoft Azure que ejecutan manifiestos anteriores a la versión de manifiesto 1600.0, la cuenta de unión al dominio debe estar en el grupo de administradores de Horizon Cloud descrito. El sistema utiliza esta cuenta de unión al dominio con todos los pods de Horizon Cloud del arrendatario en Microsoft Azure. Cuando el arrendatario tiene pods de manifiestos anteriores a la versión 1600.0, la cuenta de unión al dominio debe cumplir este requisito. Para obtener más información, consulte Cuentas de servicio que requiere Horizon Cloud para sus operaciones.
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.
Nota: 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.
Nota: 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.

Requisitos de Universal Broker

A partir de la versión de julio de 2020, cuando el entorno de arrendatario de Horizon Cloud es una nueva cuenta a partir de esa fecha y acaba de completar la implementación del primer pod en Microsoft Azure, puede optar por utilizar Universal Broker como método de brokering para su entorno. Si decide configurar el Universal Broker para su entorno, se necesitan los siguientes elementos. Consulte Configurar el 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 Requisitos de puertos y protocolos para un pod de Horizon Cloud en el manifiesto de la versión de septiembre de 2019 o posterior.
Opcional: configure las puertas de enlace del pod para la autenticación en dos fases en un servidor de autenticación RADIUS, si desea que el Universal Broker pueda utilizar la autenticación en dos fases para el pod.
  • 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 (opcional)

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.

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.
Si configuró el Universal Broker 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 del Universal Broker. Consulte Configurar el Universal Broker.
Registro de DNS público creado para el acceso de usuarios finales externos que coincide con el FQDN en la configuración de puerta de enlace externa y que se dirige al equilibrador de carga externo de Microsoft Azure en la configuración de Unified Access Gateway externa del pod (se requiere cuando el pod implementado tiene esa configuración). Para obtener más información, consulte Configurar un nombre de dominio personalizado para el servicio de nube de Azure.
Registro de DNS interno creado para el acceso de usuarios finales internos que coincide con el FQDN en la configuración de puerta de enlace interna y que se dirige al equilibrador de carga interno de Microsoft Azure en la configuración de Unified Access Gateway interna del pod (se requiere cuando el pod implementado tiene esa configuración).
El registro de DNS interno creado cuando se planea elegir brokering de pod único para la implementación y se va a integrar la implementación con VMware Workspace ONE Access. En este escenario, este registro de DNS interno es compatible con las conexiones de VMware Workspace ONE Access con el pod, en las cuales VMware Workspace ONE Access Connector sincroniza la información sobre las asignaciones de usuarios desde el pod. Este registro de DNS interno coincide con el FQDN del certificado que se cargará en el propio pod y apuntará al equilibrador de carga interno de Microsoft Azure del administrador de pods. Se requiere cuando se desea utilizar VMware Workspace ONE Access con un pod en un entorno configurado para brokering de pod único.
Nota: Este registro de DNS interno y un certificado que coincide y se carga en el propio pod también se utilizan en el caso práctico inusual y poco frecuente de que se indique a los usuarios finales internos que se conecten directamente al pod, en lugar de indicarles que se conecten a la configuración de una instancia de Unified Access Gateway interna en el pod. Estas conexiones directas son un caso práctico poco habitual. Por lo general, se utiliza una instancia de Unified Access Gateway interna, como alternativa.
Cadena de certificados (certificado de CA, certificado SSL, archivo de clave SSL) que coincide con el registro de DNS interno anterior creado para las conexiones de VMware Workspace ONE Access con el pod. Para obtener más información, consulte Cargar certificados SSL en un pod de Horizon Cloud para conexiones directas. (También se requiere si se utiliza el caso práctico atípico de hacer que los usuarios finales internos se conecten directamente al pod. Las conexiones directas son inusuales, poco comunes. Por lo general, se utiliza una instancia de Unified Access Gateway interna, como alternativa).

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.
Base para la imagen maestra, una o más de las configuraciones de máquina virtual de Microsoft Azure admitidas.
  • Standard_D3_v2, Standard_D4_v3
  • Standard_D2_v2, Standard_D2_v3
  • Standard_NV6

Cuando se crea una máquina virtual base con el asistente automatizado Importar máquina virtual - Catálogo de soluciones de la página Imágenes, el sistema utiliza automáticamente y de forma predeterminada uno de los tamaños de máquina virtual anteriores. La opción predeterminada del sistema se basa en algoritmos internos que comprueban los tamaños disponibles en la región de Microsoft Azure del pod. Cuando se crea una máquina virtual habilitada para la unidad de procesamiento gráfico (Graphics Processing Unit, GPU) con el asistente, se utiliza de forma predeterminada el tamaño Standard_NV6. Cuando se crea una máquina virtual basada en el sistema operativo de servidor con el asistente, se utilizan los tamaños Standard_D2_v2 o Standard_D2_v3. Cuando se crea una máquina virtual en Windows 10 multisesión o basada en el sistema operativo de cliente, se utilizan los tamaños Standard_D3_v2 o Standard_D4_v3.

Nota: 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 entorno de arrendatario está configurado para usar Universal Broker, las funciones de Servicio de administración de imágenes de Horizon para las imágenes de varios pods están disponibles para crear imágenes maestras para escritorios VDI de sesión única. Al ejecutar el flujo de trabajo Nueva imagen desde la página Imágenes de varios pods, se creará una máquina virtual de tipo Standard_D2_v2 de forma predeterminada. Cuando la opción para GPU está habilitada, al ejecutar el flujo de trabajo Nueva imagen desde la página Imágenes de varios pods se creará una máquina virtual de tipo Standard_NV6 de forma predeterminada.
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 granja RDS de Horizon Cloud.

Este requisito también se aplica a las máquinas virtuales que ejecutan Microsoft Windows 10 Enterprise multisesión cuando la máquina virtual se utiliza con Horizon Cloud. Como se describe en las Preguntas frecuentes de Microsoft Windows 10 Enterprise multisesión, en la documentación de Microsoft Azure Windows Virtual Desktop, Microsoft Windows 10 Enterprise multisesión es un tipo de host de sesión de escritorio remoto (RDSH) que permite varias sesiones interactivas simultáneas, característica que anteriormente solo podían ofrecer los sistemas operativos Microsoft Windows Server. Los flujos de trabajo de Horizon Cloud que se aplican a los servidores RDS pueden aplicarse a Microsoft Windows 10 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 entorno de arrendatario está configurado para usar Universal Broker, 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 y la entidad de servicio 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 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.

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 Windows Virtual Desktop para Windows 10 Enterprise multisesión y Windows 7 Enterprise, consulte el tema de la documentación de Microsoft Azure Precios de Windows Virtual Desktop.
Concesión de licencias para uno o varios de los siguientes tipos: Microsoft Windows 7 Enterprise, Microsoft Windows 10 (tipos de cliente)
Concesión de licencias para Microsoft Windows 10 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 Horizon Cloud pod para un pod con alta disponibilidad habilitada y con configuraciones de puerta de enlace externa e interna, 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 del pod para un pod que tiene habilitada la alta disponibilidad y los dos tipos de configuraciones de Unified Access Gateway, con la puerta de enlace externa que 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

Recursos

Consulte los siguientes recursos para obtener más información.