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.

Las secciones de este tema de la documentación son las siguientes:

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 tenant antes de la fecha de publicación de la versión de servicio de octubre de 2020. 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 trimestral de octubre de 2020 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 tenant productivo, que pueda 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
Nota:
  • 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.

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.
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 el paso 8.b de Crear la entidad de servicio requerida que necesita el implementador de pods de Horizon Cloud mediante la creación de un registro de aplicaciones.
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 (tenant): 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 tenant adicionales para usarlas con las máquinas virtuales de las granjas y las asignaciones de escritorios. Las subredes de tenant 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 Azure y Requisitos de puertos y protocolos para un pod de Horizon Cloud en el manifiesto de la versión de septiembre de 2019 o posterior.
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: Para los pods implementados nuevos a partir de la versión de manifiesto 2298.0 o una versión posterior, cuando un pod tiene ambos tipos de puertas de enlace, las configuraciones de puerta de enlace externa y puerta de enlace interna en el pod deben especificar el mismo FQDN. Dado que ambas puertas de enlace usarán el mismo FQDN, tras la implementación del pod, se configurará un DNS dividido (Sistema de nombres de dominio dividido) para resolver la dirección de la puerta de enlace a la puerta de enlace externa o interna, en función de la red de origen de la consulta de DNS del cliente del usuario final.
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:
  • Para los pods implementados nuevos a partir de la versión de manifiesto 2298.0 o una versión posterior, las configuraciones de puerta de enlace externa y puerta de enlace interna en el pod deben especificar el mismo FQDN. Dado que el certificado debe coincidir con el FQDN, cuando un pod tiene ambos tipos de puertas de enlace, se utiliza el mismo certificado en ambas configuraciones de puerta de enlace.
  • 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

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 cuando el primer pod conectado a la nube de Horizon Cloud proviene de usar el implementador de pods para implementar un pod en Microsoft Azure 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 octubre de 2020.
Cuenta de enlace de dominio
  • Cuenta de enlace de dominio de Active Directory (usuario estándar con acceso de lectura) que tiene los siguientes permisos:
    • Mostrar contenido
    • Lectura de todas las propiedades
    • Permisos de lectura
    • Lectura de tokenGroupsGlobalAndUniversal (implícito en Lectura de todas las propiedades)
    Nota:
    • 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

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 los siguientes permisos:
    • Mostrar contenido
    • Lectura de todas las propiedades
    • Permisos de lectura
    • Lectura de tokenGroupsGlobalAndUniversal (implícito en Lectura de todas las propiedades)
    Nota:
    • 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

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)
  • Es miembro del grupo de administradores de Horizon Cloud
  • Establecer la contraseña de la cuenta en Nunca caducar
  • Esta cuenta requiere los siguientes permisos de Active Directory: mostrar contenido, leer todas las propiedades, permisos de lectura, restablecer contraseña, crear objetos de equipo y eliminar objetos de equipo.
  • 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: 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; 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)
  • Es miembro del grupo de administradores de Horizon Cloud
  • Establecer la contraseña de la cuenta en Nunca caducar
  • Esta cuenta requiere los siguientes permisos de Active Directory: mostrar contenido, leer todas las propiedades, permisos de lectura, restablecer contraseña, crear objetos de equipo y eliminar objetos de equipo.
  • 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: 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 la cuenta de unión de dominio y los usuarios administrativos de Horizon Cloud. Este grupo se agrega a la función Superadministradores 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.
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 tenant 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 Azure y Requisitos de puertos y protocolos para un pod de Horizon Cloud en el manifiesto de la versión de septiembre de 2019 o posterior.
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: Para los pods implementados a partir del manifiesto 2298.0 o versiones posteriores, cuando un pod tiene ambos tipos de puertas de enlace, las configuraciones de puerta de enlace externa y puerta de enlace interna en el pod deben especificar el mismo FQDN. Dado que ambas puertas de enlace usarán el mismo FQDN, tras la implementación del pod, se configurará un DNS dividido (Sistema de nombres de dominio dividido) para resolver la dirección de la puerta de enlace a la puerta de enlace externa o interna, en función de la red de origen de la consulta de DNS del cliente del usuario final.
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 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 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 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
Nota: Cuando se crea una máquina virtual base con el asistente automatizado Importar máquina virtual - Catálogo de soluciones, 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.
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.

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 tenant 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

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.