Cette liste de vérification vous guide dans la préparation de vos abonnements Microsoft Azure et réseaux pour le déploiement d'un espace depuis Horizon Cloud dans Microsoft Azure. En veillant à remplir ces conditions préalables comme décrit ci-dessous, cela fournit un déploiement réussi de nouveaux espaces et la réalisation de ces tâches clés nécessaires après le déploiement d'un espace.

Cette liste de vérification est principalement destinée aux comptes clients Horizon Cloud sur lesquels un espace n'a jamais été déployé depuis ou connecté au cloud à leur environnement de locataire avant la date de publication de service de mai 2021. Ces environnements peuvent être désignés sous le terme d'environnements vierges ou environnements nus. Les nouveaux déploiements d'espace qui se produisent après le transfert dans le plan du cloud des fichiers binaires du plan du cloud et des nouvelles versions de manifeste d'espace à la date de la version de service sont déployés en utilisant la nouvelle version de manifeste d'espace. Les conditions préalables à un déploiement réussi de l'espace sont principalement déterminées par la version de manifeste de l'espace. Les fichiers binaires du plan de cloud qui se trouvent dans le plan de cloud de production peuvent également déterminer les conditions requises pour un déploiement réussi.

Certaines conditions préalables répertoriées ci-dessous sont celles nécessaires au déploiement de l'espace. Certaines conditions sont celles nécessaires à l'exécution des tâches clés après le déploiement de l'espace pour obtenir un environnement de locataire productif et fournir à vos utilisateurs finaux des postes de travail et des applications provisionnés par l'espace.

Conditions préalables au déploiement de l'espace
Conditions préalables à un environnement productif après le déploiement de l'espace
Important : Avant de lancer l'assistant de déploiement de l'espace et de commencer à déployer votre espace, outre les conditions requises ci-dessous, vous devez avoir connaissance des points clés suivants :
  • À partir de la version de juillet 2020, dans les nouveaux environnements, les nouveaux espaces sont requis pour déployer avec au moins une configuration de passerelle. Si votre compte client a été créé avant la version de juillet 2020, mais que vous n'avez pas encore déployé votre premier espace, le déploiement de ce premier espace nécessitera la configuration d'au moins une configuration de passerelle lors du déploiement de l'espace.
  • Un déploiement réussi de l'espace exige qu'aucune des stratégies Microsoft Azure que votre équipe informatique ou vous avez définies dans votre environnement Microsoft Azure ne bloque, refuse ou limite la création des composants de l'espace. Vous devez également vérifier que les définitions de stratégie intégrées de vos stratégies Microsoft Azure ne bloquent pas, ne refusent pas et ne limitent pas la création des composants de l'espace. Par exemple, votre équipe informatique et vous devez vérifier qu'aucune de vos stratégies Microsoft Azure ne bloque, refuse ou limite la création de composants sur un compte de stockage Azure. Pour plus d'informations sur les stratégies Azure, reportez-vous à la documentation correspondante.
  • Le système de déploiement de l'espace exige que votre compte de stockage Azure permette au système de déploiement d'utiliser les types de comptes Azure StorageV1 et StorageV2. Vérifiez que vos stratégies Microsoft Azure ne limitent pas ou ne refusent pas la création de contenu nécessitant les types de comptes Azure StorageV1 et StorageV2.
  • Dans le cadre des processus de déploiement de l'espace et de la passerelle, à moins que vous ne spécifiiez des balises de ressources personnalisées dans l'assistant de déploiement, Horizon Cloud crée des groupes de ressources (RG) dans votre abonnement Microsoft Azure qui ne comportent aucune balise, y compris le groupe de ressources initial créé pour la VM JumpBox temporaire qui orchestre ces processus de déploiement. À partir de l'actualisation du plan de cloud du 8 octobre 2020, l'assistant de déploiement dispose d'une fonctionnalité dans laquelle vous pouvez spécifier des balises de ressources personnalisées à appliquer aux groupes de ressources créés par le système de déploiement. Si vous ne spécifiez aucune balise de ressource personnalisée et que votre abonnement Microsoft Azure comporte un type de condition requise de balise de ressource, le déploiement de l'espace échoue si vous tentez de déployer un espace dans cet abonnement ou au moment des mises à jour de l'espace ou de l'ajout d'une configuration de passerelle à un espace. Si vous ne prévoyez pas d'utiliser la fonctionnalité de balises de ressources personnalisées de l'assistant de déploiement, vous devez vérifier que vos stratégies Microsoft Azure permettent la création des groupes de ressources non balisées de l'espace dans l'abonnement cible. Pour obtenir la liste des groupes de ressources créés par le système de déploiement, reportez-vous à la rubrique Groupes de ressources créés pour un espace déployé dans Microsoft Azure du Guide d'administration.
  • Tous les espaces connectés au cloud doivent disposer d'une vue directe sur le même ensemble de domaines Active Directory au moment où vous déployez ces espaces.

Conditions requises pour le plan de contrôle d'Horizon Cloud

Compte My VMware actif pour la connexion au plan de contrôle d'Horizon Cloud.

Conditions requises pour les abonnements Microsoft Azure

Abonnement Microsoft Azure valide dans un environnement Microsoft Azure pris en charge (Azure Commercial, Azure Chine ou Azure Government). Si vous déployez la passerelle externe d'Unified Access Gateway facultative dans un réseau virtuel distinct à l'aide de son propre abonnement, vous avez besoin d'un abonnement Microsoft Azure valide supplémentaire dans le même environnement Microsoft Azure.
Note : Horizon Cloud prend en charge la plupart des régions Microsoft Azure. Pour obtenir la liste des régions Microsoft Azure non prises en charge actuellement, consultez l'article Régions Microsoft Azure avec Horizon Cloud Service on Microsoft Azure (77121) de la base de connaissances VMware.
Privilèges administratifs Microsoft Azure valides dans cet abonnement Microsoft Azure. Pour plus d'informations, reportez-vous à la section relative au démarrage avec le contrôle d'accès basé sur les rôles dans le portail Azure de la documentation de Microsoft.
Capacité minimale de Microsoft Azure disponible pour l'infrastructure Horizon Cloud, outre la charge de travail de poste de travail et d'application attendue. Notez que, tant que cette capacité est mise à disposition, Horizon Cloud déploie automatiquement ces machines virtuelles et aucune installation manuelle n'est requise.
  • Moteur de déploiement d'espaces, également appelé JumpBox (provisoire) : 1 x Standard_F2
  • Gestionnaire espace/espace avec la haute disponibilité activée : 2 x Standard_D4_v3 (en l'absence de Standard_D4_v3 dans la région, 2 x Standard_D3_v2)
  • Gestionnaire espace/espace sans la haute disponibilité activée : 1 x Standard_D4_v3 (en l'absence de Standard_D4_v3 dans la région, 1 x Standard_D3_v2)
  • Base de données Microsoft Azure pour le service PostgreSQL : génération 5, mémoire optimisée, 2 vCore, 10 Go de stockage
  • Unified Access Gateway externe (facultatif, sauf si aucune passerelle interne n'est spécifiée) : 2 x Standard_A4_v2 ou 2 x Standard_F8s_v2
  • Unified Access Gateway interne (facultatif, sauf si aucune passerelle externe n'est spécifiée) : 2 x Standard_A4_v2 ou 2 x Standard_F8s_v2
Note :
  • À partir de la version de service de juillet 2020, dans les environnements vierges, les nouveaux espaces doivent être déployés avec au moins une configuration de passerelle. Si votre compte client a été créé avant la version de juillet 2020, mais que vous n'avez pas encore déployé votre premier espace, le déploiement de ce premier espace nécessitera la configuration d'au moins une configuration de passerelle lors du déploiement de l'espace. Par la suite, votre capacité Microsoft Azure minimale disponible doit accueillir les machines virtuelles pour l'une des configurations de passerelle, comme décrit dans la liste précédente.
  • Si la région de votre abonnement ne fournit pas les tailles de VM Standard_F8s_v2, l'assistant de déploiement de l'espace n'affiche pas ce choix dans le sélecteur de l'étape de l'assistant Spécifier les passerelles.
  • Une fois le déploiement de l'espace terminé, votre capacité dans le cloud Microsoft Azure doit également intégrer les VM importées, les images standard, les postes de travail virtuels et les batteries de serveurs RDSH que vous créez dans cet espace. Lorsque votre compte est activé pour utiliser les fonctionnalités d'App Volumes et que vous utilisez le workflow de capture d'applications de la console, votre capacité doit également accueillir les machines virtuelles dans l'attribution de poste de travail générée par le système utilisée pour ce processus de capture. Reportez-vous à la section Images de base, postes de travail et batteries de serveurs Horizon Cloud ci-dessous.
  • Lorsque votre compte de locataire est activé pour utiliser la fonctionnalité Surveillance de l'infrastructure Horizon et que vous prévoyez d'activer cette fonctionnalité sur l'espace après le déploiement de l'espace, votre capacité doit également être prise en charge à ce moment-là pour le déploiement du dispositif Dispositif virtuel Horizon Edge. Reportez-vous à la section Exigences de surveillance de l'infrastructure Horizon. ci-dessous.

La passerelle d'Unified Access Gateway externe peut être déployée de manière facultative dans son propre réseau virtuel Microsoft Azure, soit en utilisant le même abonnement que celui de l'espace, soit en utilisant un autre abonnement. Lors du déploiement de l'instance externe d'Unified Access Gateway dans son propre réseau virtuel, la capacité suivante est nécessaire dans l'abonnement que l'instance externe d'Unified Access Gateway est déployée :

  • Moteur de déploiement de l'instance externe d'Unified Access Gateway, également appelé JumpBox de passerelle (provisoire) : 1 x Standard_F2
  • Connecteur de passerelle externe : 1 x Standard_A1_v2
  • Unified Access Gateway externe : 2 x Standard_A4_v2 ou 2 x Standard_F8s_v2.
Principal de service et clé d'authentification créés pour chaque abonnement. Pour plus d'informations, reportez-vous à la section Utilisation du portail pour créer une application Azure Active Directory et le principal de service pouvant accéder aux ressources. Reportez-vous également à la section Création du principal de service requis par le système de déploiement de l'espace Horizon Cloud par le biais de l'enregistrement d'une application.
Le rôle approprié doit être attribué à chaque principal de service, ce qui permet d'effectuer les actions qu'Horizon Cloud doit effectuer dans l'abonnement. Il peut s'agir du rôle Contributeur ou d'un rôle personnalisé avec les actions autorisées requises au niveau de l'abonnement. Lorsque vous déployez la configuration de la passerelle externe dans un groupe de ressources existant d'un abonnement distinct, vous pouvez définir des autorisations plus granulaires pour le principal de service de cet abonnement. Pour plus d'informations sur les actions de rôle requises, reportez-vous à la section Opérations requises par Horizon Cloud dans vos abonnements Microsoft Azure.
Important : Le rôle doit être attribué directement au principal de service utilisé pour Horizon Cloud. L'utilisation d'une attribution basée sur un groupe d'un rôle au principal de service, dans laquelle le rôle est attribué à un groupe et le principal de service est membre de ce groupe, n'est pas prise en charge.
Fournisseurs de ressources requis enregistrés dans chaque abonnement Microsoft Azure. Reportez-vous à l'étape 8.b de la section Création du principal de service requis par le système de déploiement de l'espace Horizon Cloud par le biais de l'enregistrement d'une application.
ID d'abonnement Microsoft Azure, ID de répertoire, ID d'application et clé identifiés.
Si vous déployez l'instance externe d'Unified Access Gateway facultative dans un réseau virtuel séparé à l'aide de son propre abonnement, et si votre organisation nécessite l'utilisation d'un groupe de ressources que vous contrôlez et qui n'est pas créé par le système de déploiement de l'espace, vous devez utiliser la fonctionnalité de déploiement de l'instance externe d'Unified Access Gateway dans votre propre groupe de ressources nommé. L'utilisation de cette fonctionnalité vous oblige à créer ce groupe de ressources dans cet abonnement avant d'exécuter le système de déploiement de l'espace. Vous devez également vous assurer que les autorisations nécessaires sont en place pour que le système de déploiement de l'espace déploie la configuration d'Unified Access Gateway dans ce groupe de ressources, gère la configuration et mette à jour le logiciel Unified Access Gateway dans le processus de mise à jour de l'espace standard. Pour plus d'informations sur les autorisations nécessaires, reportez-vous à la section Opérations requises par Horizon Cloud dans vos abonnements Microsoft Azure.

Conditions requises pour le réseau

Réseau virtuel Microsoft Azure créé dans la région Microsoft Azure souhaitée avec l'espace d'adresses applicable pour couvrir les sous-réseaux requis. Pour plus d'informations, reportez-vous à la section relative au réseau virtuel Azure.

Lors du déploiement de la passerelle externe d'Unified Access Gateway facultative dans son propre réseau virtuel distinct du réseau virtuel de l'espace, créez le réseau virtuel Unified Access Gateway dans la même région Microsoft Azure que celle du réseau virtuel de l'espace avec l'espace d'adresses applicable pour couvrir les sous-réseaux requis, et liez les deux réseaux virtuels.

3 plages d'adresses qui ne se chevauchent pas au format CIDR dans le réseau virtuel de l'espace, réservées aux sous-réseaux.
  • Sous-réseau de gestion : /27 minimum
  • Sous-réseau de VM - principal (locataire) : 27 minimum avec une préférence pour /24 - /22, en fonction du nombre de postes de travail et de serveurs RDS
  • Sous-réseau de zone DMZ : /28 minimum lorsque Unified Access Gateway est déployé dans le réseau virtuel de l'espace (facultatif)
Les sous-réseaux peuvent être créés manuellement sur le réseau virtuel ou par Horizon Cloud pendant le déploiement. Si vous utilisez des sous-réseaux créés manuellement, aucune autre ressource ne peut être liée.
Note : Pour les espaces faisant l'objet d'un nouveau déploiement au niveau du manifeste 2298.0 ou une version ultérieure, une fois l'espace déployé, vous pouvez modifier celui-ci pour ajouter des sous-réseaux de locataires supplémentaires à utiliser avec les machines virtuelles de vos batteries de serveurs et attributions de poste de travail. Les sous-réseaux de locataire supplémentaires peuvent se trouver dans le même réseau virtuel que celui dans lequel l'espace est déployé ou dans un réseau virtuel homologue. Pour obtenir des informations détaillées, reportez-vous au Guide d'administration.
Lors du déploiement de l'instance externe d'Unified Access Gateway dans son propre réseau virtuel distinct du réseau virtuel de l'espace, 3 plages d'adresses qui ne se chevauchent pas au format CIDR dans le réseau virtuel d'Unified Access Gateway, réservées aux sous-réseaux.
  • Sous-réseau de gestion : /27 minimum
  • Sous-réseau principal : /27 minimum avec une préférence pour /24 - /22, en fonction du nombre de postes de travail et de serveurs RDS
  • Sous-réseau de zone DMZ (frontal) : /28 minimum
Les sous-réseaux peuvent être créés manuellement sur le réseau virtuel ou par Horizon Cloud pendant le déploiement. Si vous utilisez des sous-réseaux créés manuellement, aucune autre ressource ne peut être liée. Pour ce cas d'utilisation, les sous-réseaux sont généralement créés manuellement. Dans ce cas d'utilisation, l'objectif du sous-réseau principal est semblable à l'objectif du sous-réseau de machine virtuelle (principal) décrit dans la ligne précédente du tableau.
Serveurs NTP disponibles et accessibles à partir de l'espace Horizon Cloud et des instances de Unified Access Gateway.
Configurez le serveur DNS du réseau virtuel, pointant vers un serveur DNS valide qui peut résoudre les noms de machines internes et externes.
L'accès Internet sortant sur les réseaux virtuels que vous utilisez pour le déploiement de l'espace et de la passerelle doit résoudre et atteindre des noms DNS spécifiques à l'aide de ports et de protocoles spécifiques. Cette condition est requise pour le déploiement et les opérations en cours. Pour obtenir la liste des noms et des ports DNS, reportez-vous aux sections Conditions requises de DNS pour un espace Horizon Cloud dans les fonctionnalités de service associées et Microsoft et Conditions requises des ports et des protocoles pour un espace Horizon Cloud dans la version de manifeste de septembre 2019 ou une version ultérieure.
Informations sur le serveur proxy, si cela s'avère nécessaire pour l'accès Internet sortant sur le réseau virtuel qui est utilisé pendant le déploiement et les opérations en cours de l'environnement Horizon Cloud (facultatif).
Microsoft Azure VPN/ExpressRoute configuré (facultatif).
Nom de domaine complet pour l'accès de l'utilisateur externe ou interne, ou les deux (requis lors du déploiement d'un espace avec Unified Access Gateway).
Note : À compter de l'actualisation du plan de cloud au 15 décembre 2020, il est possible d'utiliser des noms de domaine complets différents pour les configurations de passerelle externe et de passerelle interne. Avant le 15 décembre 2020, le système imposait l'utilisation du même nom de domaine complet pour un espace de manifeste 2298 et les versions ultérieures. Vous pouvez désormais choisir si vous souhaitez que les passerelles de l'espace utilisent des noms de domaine complets différents ou un nom de domaine complet identique. Si vous souhaitez utiliser le même nom de domaine complet sur les deux passerelles, après le déploiement de l'espace, configurez le DNS fractionné (système de noms de domaine fractionné) pour résoudre l'adresse de passerelle vers la passerelle externe ou interne en fonction du réseau d'origine de la requête DNS du client de l'utilisateur final. Ensuite, le même nom de domaine complet utilisé dans le client de l'utilisateur final peut effectuer l'acheminement vers la passerelle externe lorsque le client se trouve sur Internet et effectuer l'acheminement vers la passerelle interne lorsque le client se trouve sur votre réseau interne.
Certificat ou certificats pour Unified Access Gateway au format PEM correspondant au nom de domaine complet (requis lors du déploiement d'un espace avec Unified Access Gateway).
Note : Si le ou les certificats que vous fournissez à cet effet utilisent des paramètres CRL (listes de révocation des certificats) ou OCSP (Online Certificate Status Protocol) qui font référence à des noms DNS spécifiques, vous devez vous assurer que l'accès Internet sortant sur le réseau virtuel peut être résolu et accessible. Lors de la configuration de votre certificat fourni dans la configuration de la passerelle Unified Access Gateway, le logiciel Unified Access Gateway accédera à ces noms DNS pour vérifier l'état de révocation du certificat. Si ces noms DNS ne sont pas accessibles, le déploiement de l'espace échouera lors de la phase de connexion. Ces noms dépendent fortement de l'autorité de certification que vous avez utilisée pour obtenir les certificats, et VMware n'en a donc pas le contrôle.
Authentification à deux facteurs sur un serveur d'authentification RADIUS sur site (facultatif).
  • Adresses DNS pour Unified Access Gateway pour résoudre le nom du serveur d'authentification
  • Routes pour Unified Access Gateway pour résoudre le routage réseau vers le serveur d'authentification
Note : Une fois l'espace déployé, lorsque vous prévoyez de configurer l'environnement pour qu'il utilise Universal Broker pour présenter les postes de travail à vos utilisateurs finaux, une configuration supplémentaire est nécessaire lorsque vous souhaitez ignorer l'authentification à deux facteurs pour les utilisateurs finaux sur votre réseau interne. Les instances internes d' Unified Access Gateway de l'espace acheminent les demandes de connexion vers les applications et les postes de travail virtuels pour ces utilisateurs finaux internes. Lorsque vous disposez d'une configuration de passerelle interne sur l'espace, vous prévoyez de configurer l'environnement pour utiliser Universal Broker. Vous souhaitez l'authentification à deux facteurs pour vos utilisateurs finaux externes, mais souhaitez l'ignorer pour vos utilisateurs finaux internes. Après le déploiement de l'espace, vous devez alors entrer des plages d'adresses IP que Universal Broker utilisera pour distinguer les utilisateurs finaux internes des utilisateurs finaux externes afin de passer outre l'authentification à deux facteurs. Pour plus d'informations, reportez-vous à la rubrique de la documentation Configuration d'une méthode d'intermédiation et d'attributions d'utilisateurs finaux dans votre environnement de locataire Horizon Cloud et à ses sous-rubriques.

Conditions requises pour les ports et les protocoles

Des ports et protocoles spécifiques sont requis pour les espaces d'intégration et les opérations en cours de votre environnement Horizon Cloud. Reportez-vous à la section Conditions requises des ports et des protocoles pour un espace Horizon Cloud dans la version de manifeste de septembre 2019 ou une version ultérieure.

Workflow du déploiement de l'espace

Les éléments précédents sont ceux requis avant de démarrer l'assistant de déploiement de l'espace. Après avoir vérifié que vous disposez des éléments précédents, suivez les étapes de déploiement de l'espace jusqu'à l'étape 4 dans Workflow général permettant l'ajout d'un espace Horizon sur Microsoft Azure comme premier espace à votre environnement de locataire Horizon Cloud pour déployer votre espace.

Ensuite, une fois l'espace déployé, vérifiez que vous disposez des éléments décrits dans la section suivante afin de pouvoir effectuer les étapes clés restantes de ce workflow général.

Conditions requises pour Active Directory

Les éléments suivants sont nécessaires au workflow d'enregistrement d'Active Directory. Pour comprendre ce workflow, reportez-vous à la section Enregistrement de votre premier domaine Active Directory dans l'environnement Horizon Cloud.

Une des configurations Active Directory prises en charge suivantes :
  • Serveur Active Directory sur site connecté via un VPN/ExpressRoute
  • Serveur Active Directory situé dans Microsoft Azure
  • Active Directory Domain Services de Microsoft Azure
Niveaux fonctionnels de domaine des services de domaine Microsoft Windows Active Directory (AD DS) pris en charge :
  • Microsoft Windows Server 2008 R2
  • Microsoft Windows Server 2012 R2
  • Microsoft Windows Server 2016
Tous les espaces connectés au cloud du même compte client Horizon Cloud doivent avoir une vue directe sur le même ensemble de domaines Active Directory lors du déploiement de ces espaces. Cette condition requise s'applique non seulement aux espaces supplémentaires que vous déployez par la suite dans Microsoft Azure après le premier espace, mais également aux espaces Horizon connectés au cloud au même compte client à l'aide d'Horizon Cloud Connector. Vous pouvez afficher la liste de contrôle de ces espaces Horizon dans Espaces VMware Horizon avec Horizon Cloud - Liste de vérification des conditions requises : mise à jour selon le cas pour connecter les espaces à partir de la version de service de mai 2021.
Important : Lisez la section Comptes de service dont Horizon Cloud a besoin pour ses opérations pour connaître les caractéristiques clés que ce compte doit avoir.

Compte de liaison de domaine

  • Compte de liaison de domaine Active Directory (utilisateur standard avec accès en lecture) disposant de l'attribut sAMAccountName. La longueur de l'attribut sAMAccountName ne doit pas dépasser 20 caractères et il ne peut contenir aucun des caractères suivants : "/ \ [ ] : ; | = , + * ? < >
  • Le compte doit disposer des autorisations suivantes :
    • Contenu de la liste
    • Toutes les propriétés - accès en lecture
    • Autorisations d'accès en lecture
    • tokenGroupsGlobalAndUniversal - accès en lecture (sous-entendu par Toutes les propriétés - accès en lecture)
  • Si vous connaissez bien l'offre VMware Horizon sur site, les autorisations ci-dessus sont les mêmes que celles requises pour les comptes d'informations d'identification secondaires de l'offre Horizon sur site, mentionnées dans cette rubrique de la documentation d'Horizon sur site.
  • En règle générale, les comptes de liaison de domaine doivent se voir accorder les autorisations prêtes à l'emploie liées à l'accès en lecture par défaut et en général accordées aux utilisateurs authentifiés dans un déploiement Microsoft Active Directory. Cependant, si les administrateurs AD de votre organisation ont choisi de verrouiller les autorisations liées à l'accès en lecture pour les utilisateurs standard, vous devez demander aux administrateurs AD de conserver les valeurs standard par défaut des utilisateurs authentifiés pour les comptes de liaison de domaine que vous utiliserez pour Horizon Cloud.

Vous devez également définir le mot de passe du compte sur N'expire jamais pour garantir un accès continu à la connexion à votre environnement Horizon Cloud.

Pour obtenir des informations et des conditions requises supplémentaires, reportez-vous à la section Comptes de service dont Horizon Cloud a besoin pour ses opérations.

Important : Lisez la section Comptes de service dont Horizon Cloud a besoin pour ses opérations pour connaître les caractéristiques clés que ce compte doit avoir.

Compte de liaison de domaine auxiliaire : impossible d'utiliser le même compte que celui indiqué ci-dessus.

  • Compte de liaison de domaine Active Directory (utilisateur standard avec accès en lecture) disposant de l'attribut sAMAccountName. La longueur de l'attribut sAMAccountName ne doit pas dépasser 20 caractères et il ne peut contenir aucun des caractères suivants : "/ \ [ ] : ; | = , + * ? < >
  • Le compte doit disposer des autorisations suivantes :
    • Contenu de la liste
    • Toutes les propriétés - accès en lecture
    • Autorisations d'accès en lecture
    • tokenGroupsGlobalAndUniversal - accès en lecture (sous-entendu par Toutes les propriétés - accès en lecture)
  • Si vous connaissez bien l'offre VMware Horizon sur site, les autorisations ci-dessus sont les mêmes que celles requises pour les comptes d'informations d'identification secondaires de l'offre Horizon sur site, mentionnées dans cette rubrique de la documentation d'Horizon sur site.
  • En règle générale, les comptes de liaison de domaine doivent se voir accorder les autorisations prêtes à l'emploie liées à l'accès en lecture par défaut et en général accordées aux utilisateurs authentifiés dans un déploiement Microsoft Active Directory. Cependant, si les administrateurs AD de votre organisation ont choisi de verrouiller les autorisations liées à l'accès en lecture pour les utilisateurs standard, vous devez demander aux administrateurs AD de conserver les valeurs standard par défaut des utilisateurs authentifiés pour les comptes de liaison de domaine que vous utiliserez pour Horizon Cloud.

Vous devez également définir le mot de passe du compte sur N'expire jamais pour garantir un accès continu à la connexion à votre environnement Horizon Cloud.

Important : Lisez la section Comptes de service dont Horizon Cloud a besoin pour ses opérations pour connaître les caractéristiques clés que ce compte doit avoir.

Compte de jonction de domaine

  • Compte de jonction de domaine Active Directory qui peut être utilisé par le système pour effectuer des opérations Sysprep et joindre des ordinateurs au domaine, généralement un nouveau compte (compte d'utilisateur de jonction de domaine).
  • Le compte doit disposer de l'attribut sAMAccountName. La longueur de l'attribut sAMAccountName ne doit pas dépasser 20 caractères et il ne peut contenir aucun des caractères suivants : "/ \ [ ] : ; | = , + * ? < >
  • Définissez le mot de passe du compte sur N'expire jamais.
  • Ce compte nécessite les autorisations Active Directory suivantes : Toutes les propriétés - accès en lecture, Réinitialiser le mot de passe, Créer des objets d'ordinateur, Supprimer des objets d'ordinateur et Toutes les propriétés - accès en écriture.
    Note : À partir du manifeste d'espace 2474.0, les autorisations requises pour le compte de jonction de domaine sont réduites par rapport à l'ensemble précédent utilisé pour les manifestes antérieurs à 2474 et incluent désormais l'autorisation Toutes les propriétés - accès en écriture sur les objets d'ordinateur descendants. Les espaces exécutant des manifestes antérieurs requièrent toujours l'ensemble d'autorisations précédent. Pour plus d'informations, reportez-vous à Comptes de service dont Horizon Cloud a besoin pour ses opérations.
  • Ce compte nécessite également l'autorisation Active Directory nommée Toutes les propriétés - accès en écriture sur tous les objets descendants de l'unité d'organisation (OU) cible que vous prévoyez d'utiliser pour les batteries de serveurs et les attributions de poste de travail VDI.
  • Pour obtenir des informations et des conditions requises supplémentaires, reportez-vous à la section Comptes de service dont Horizon Cloud a besoin pour ses opérations.
Note :
  • L'utilisation d'espaces blancs dans le nom d'utilisateur du compte n'est actuellement pas prise en charge. Si le nom contient un espace blanc, des résultats inattendus se produisent dans les opérations système qui reposent sur ce compte.
  • Dans Microsoft Active Directory, lorsque vous créez une unité d'organisation, le système peut définir automatiquement l'attribut Prevent Accidental Deletion qui applique un Deny à l'autorisation Supprimer tous les objets enfants de l'unité d'organisation récemment créée et de tous les objets descendants. Par conséquent, si vous avez explicitement attribué l'autorisation Supprimer des objets de l'ordinateur au compte de jonction de domaine, dans le cas d'une unité d'organisation récemment créée, Active Directory peut avoir appliqué un remplacement à cette autorisation de suppression d'objets de l'ordinateur explicitement attribuée. Étant donné que l'effacement de l'indicateur Empêcher la suppression accidentelle peut ne pas effacer automatiquement le Deny qu'Active Directory a appliqué à l'autorisation de suppression de tous les objets enfants, dans le cas d'une unité d'organisation récemment ajoutée, vous devrez peut-être vérifier et effacer manuellement l'autorisation Deny définie pour supprimer tous les objets enfants dans l'unité d'organisation et toutes les unités d'organisation enfants avant d'utiliser le compte de jonction de domaine dans la console Horizon Cloud.
  • Avant le manifeste 1600.0, ce compte nécessitait les autorisations du rôle Super administrateur du système. Si votre environnement de locataire dispose d'espaces Horizon Cloud dans Microsoft Azure exécutant des manifestes antérieurs au manifeste 1600.0, le compte de jonction de domaine doit se trouver dans le groupe d'administrateurs Horizon Cloud décrit. Le système utilise ce compte de jonction de domaine avec tous les espaces Horizon Cloud de locataire dans Microsoft Azure. Lorsque votre locataire dispose d'espaces de manifestes antérieurs à 1600.0, le compte de jonction de domaine doit répondre à cette condition requise. Pour plus d'informations, reportez-vous à la section Comptes de service dont Horizon Cloud a besoin pour ses opérations.
Important : Lisez la section Comptes de service dont Horizon Cloud a besoin pour ses opérations pour connaître les caractéristiques clés que ce compte doit avoir.

Compte de jonction de domaine auxiliaire (facultatif, impossible d'utiliser le même compte que celui indiqué ci-dessus)

  • Compte de jonction de domaine Active Directory qui peut être utilisé par le système pour effectuer des opérations Sysprep et joindre des ordinateurs au domaine, généralement un nouveau compte (compte d'utilisateur de jonction de domaine).
  • Le compte doit disposer de l'attribut sAMAccountName. La longueur de l'attribut sAMAccountName ne doit pas dépasser 20 caractères et il ne peut contenir aucun des caractères suivants : "/ \ [ ] : ; | = , + * ? < >
  • Définissez le mot de passe du compte sur N'expire jamais.
  • Ce compte nécessite les autorisations Active Directory suivantes : Toutes les propriétés - accès en lecture, Réinitialiser le mot de passe, Créer des objets d'ordinateur, Supprimer des objets d'ordinateur et Toutes les propriétés - accès en écriture.
    Note : À partir du manifeste d'espace 2474.0, les autorisations requises pour le compte de jonction de domaine sont réduites par rapport à l'ensemble précédent utilisé pour les manifestes antérieurs à 2474 et incluent désormais l'autorisation Toutes les propriétés - accès en écriture sur les objets d'ordinateur descendants. Les espaces exécutant des manifestes antérieurs requièrent toujours l'ensemble d'autorisations précédent. Pour plus d'informations, reportez-vous à Comptes de service dont Horizon Cloud a besoin pour ses opérations.
  • Ce compte nécessite également l'autorisation Active Directory nommée Toutes les propriétés - accès en écriture sur tous les objets descendants de l'unité d'organisation (OU) cible que vous prévoyez d'utiliser pour les batteries de serveurs et les postes de travail virtuels VDI.
  • Pour obtenir des informations et des conditions requises supplémentaires, reportez-vous à la section Comptes de service dont Horizon Cloud a besoin pour ses opérations.
Note :
  • L'utilisation d'espaces blancs dans le nom d'utilisateur du compte n'est actuellement pas prise en charge. Si le nom contient un espace blanc, des résultats inattendus se produisent dans les opérations système qui reposent sur ce compte.
  • Dans Microsoft Active Directory, lorsque vous créez une unité d'organisation, le système peut définir automatiquement l'attribut Prevent Accidental Deletion qui applique un Deny à l'autorisation Supprimer tous les objets enfants de l'unité d'organisation récemment créée et de tous les objets descendants. Par conséquent, si vous avez explicitement attribué l'autorisation Supprimer des objets de l'ordinateur au compte de jonction de domaine, dans le cas d'une unité d'organisation récemment créée, Active Directory peut avoir appliqué un remplacement à cette autorisation de suppression d'objets de l'ordinateur explicitement attribuée. Étant donné que l'effacement de l'indicateur Empêcher la suppression accidentelle peut ne pas effacer automatiquement le Deny qu'Active Directory a appliqué à l'autorisation de suppression de tous les objets enfants, dans le cas d'une unité d'organisation récemment ajoutée, vous devrez peut-être vérifier et effacer manuellement l'autorisation Deny définie pour supprimer tous les objets enfants dans l'unité d'organisation et toutes les unités d'organisation enfants avant d'utiliser le compte de jonction de domaine dans la console Horizon Cloud.
  • Avant le manifeste 1600.0, ce compte nécessitait les autorisations du rôle Super administrateur du système. Si votre environnement de locataire dispose d'espaces Horizon Cloud dans Microsoft Azure exécutant des manifestes antérieurs au manifeste 1600.0, le compte de jonction de domaine doit se trouver dans le groupe d'administrateurs Horizon Cloud décrit. Le système utilise ce compte de jonction de domaine avec tous les espaces Horizon Cloud de locataire dans Microsoft Azure. Lorsque votre locataire dispose d'espaces de manifestes antérieurs à 1600.0, le compte de jonction de domaine doit répondre à cette condition requise. Pour plus d'informations, reportez-vous à la section Comptes de service dont Horizon Cloud a besoin pour ses opérations.
Groupes Active Directory.
  • Administrateurs Horizon Cloud : groupe de sécurité Active Directory pour les administrateurs d'Horizon Cloud. Contient les utilisateurs administratifs d'Horizon Cloud. Le rôle Super administrateur est accordé à ce groupe dans Horizon Cloud.
  • Utilisateurs d'Horizon Cloud : groupe de sécurité Active Directory pour les utilisateurs qui auront accès aux postes de travail virtuels et aux postes de travail basés sur une session RDS, ainsi qu'aux applications publiées dans Horizon Cloud.
Note : Si votre environnement de locataire dispose d'espaces Horizon Cloud dans Microsoft Azure exécutant des manifestes dont la version est postérieure à 1600.0, le compte de jonction de domaine et tous les comptes de jonction de domaine auxiliaires doivent également se trouver dans le groupe d'administrateurs Horizon Cloud, ou dans un groupe Active Directory disposant du rôle Super administrateur dans Horizon Cloud.
Unités d'organisation Active Directory pour les postes de travail virtuels et les postes de travail basés sur une session RDS et/ou les applications publiées.
Note : Dans Microsoft Active Directory, lorsque vous créez une unité d'organisation, le système peut définir automatiquement l'attribut Prevent Accidental Deletion qui applique un Deny à l'autorisation Supprimer tous les objets enfants de l'unité d'organisation récemment créée et de tous les objets descendants. Par conséquent, si vous avez explicitement attribué l'autorisation Supprimer des objets de l'ordinateur au compte de jonction de domaine, dans le cas d'une unité d'organisation récemment créée, Active Directory peut avoir appliqué un remplacement à cette autorisation de suppression d'objets de l'ordinateur explicitement attribuée. Étant donné que l'effacement de l'indicateur Empêcher la suppression accidentelle peut ne pas effacer automatiquement le Deny qu'Active Directory a appliqué à l'autorisation de suppression de tous les objets enfants, dans le cas d'une unité d'organisation récemment ajoutée, vous devrez peut-être vérifier et effacer manuellement l'autorisation Deny définie pour supprimer tous les objets enfants dans l'unité d'organisation et toutes les unités d'organisation enfants avant d'utiliser le compte de jonction de domaine dans la console Horizon Cloud.

Conditions requises pour Universal Broker

À partir de la version de juillet 2020, lorsque votre environnement de locataire Horizon Cloud est un nouveau compte à partir de cette date et que vous venez de terminer le déploiement de votre premier espace dans Microsoft Azure, vous pouvez choisir d'utiliser Universal Broker comme méthode d'intermédiation pour votre environnement. Lorsque vous choisissez de configurer Universal Broker pour votre environnement, les éléments suivants sont nécessaires. Reportez-vous à la section Configurer Universal Broker.

L'accès Internet sortant sur les réseaux virtuels que vous utilisez pour l'espace doit résoudre et atteindre des noms DNS spécifiques à l'aide de ports et de protocoles spécifiques. Cela est nécessaire pour la configuration Universal Broker et les opérations en cours. Pour obtenir la liste des noms et des ports DNS, reportez-vous aux sections Conditions requises de DNS pour un espace Horizon Cloud dans les fonctionnalités de service associées et Microsoft et Conditions requises des ports et des protocoles pour un espace Horizon Cloud dans la version de manifeste de septembre 2019 ou une version ultérieure.
Facultatif : configurez les passerelles de votre espace pour l'authentification à deux facteurs sur un serveur d'authentification RADIUS, si vous souhaitez qu'Universal Broker utilise l'authentification à deux facteurs pour l'espace.
  • Adresses DNS pour Unified Access Gateway pour résoudre le nom du serveur d'authentification
  • Routes pour Unified Access Gateway pour résoudre le routage réseau vers le serveur d'authentification
Facultatif : nom de domaine complet personnalisé que vos utilisateurs finaux utiliseront pour accéder au service Universal Broker et le certificat basé sur ce nom de domaine complet (facultatif)

Conditions préalables des enregistrements DNS

Une fois que l'espace est déployé dans le cloud Microsoft Azure et en fonction de votre situation professionnelle et des fonctionnalités que vous souhaitez utiliser, il est important de configurer les enregistrements de votre serveur DNS qui mappent des noms de domaine complets (FQDN) aux adresses IP liées à l'espace.

Note : Si vous avez déployé l'espace alors que les configurations de passerelles externe et interne portaient le même nom de domaine complet, après le déploiement de l'espace, configurez le DNS fractionné (système de noms de domaine fractionné) pour résoudre l'adresse de passerelle vers la passerelle externe ou interne en fonction du réseau d'origine de la requête DNS du client de l'utilisateur final.
Si vous avez configuré Universal Broker avec un nom de domaine complet personnalisé, créez un enregistrement DNS public qui mappe votre nom de domaine complet personnalisé au nom de domaine complet d'intermédiation indiqué par VMware dans votre configuration Universal Broker. Reportez-vous à la section Configurer Universal Broker.
Enregistrement DNS public créé pour l'accès externe des utilisateurs finaux, qui correspond au nom de domaine complet sur la configuration de passerelle externe, désignant l'équilibrage de charge externe Microsoft Azure dans la configuration externe de Unified Access Gateway de l'espace (requis lorsque l'espace déployé dispose de cette configuration). Pour plus d'informations, reportez-vous à la section Configuration d'un nom de domaine personnalisé pour un service cloud Azure.
Enregistrement DNS interne créé pour l'accès interne des utilisateurs finaux, qui correspond au nom de domaine complet sur la configuration de passerelle interne, désignant l'équilibrage de charge interne Microsoft Azure dans la configuration interne d'Unified Access Gateway de l'espace (requis lorsque l'espace déployé dispose de cette configuration).
Enregistrement DNS interne créé lorsque vous prévoyez de choisir l'intermédiation d'un espace unique pour votre déploiement et que vous intégrez le déploiement à VMware Workspace ONE Access. Dans ce scénario, cet enregistrement DNS interne prend en charge les connexions VMware Workspace ONE Access à l'espace, dans lequel VMware Workspace ONE Access Connector synchronise les informations sur les attributions d'utilisateur à partir de l'espace. Cet enregistrement DNS interne correspond au nom de domaine complet dans le certificat que vous allez charger vers l'espace lui-même et pointe vers l'équilibrage de charge interne Microsoft Azure du gestionnaire de l'espace. Requis lorsque vous souhaitez utiliser VMware Workspace ONE Access avec un espace dans un environnement configuré pour l'intermédiation à espace unique.
Note : Cet enregistrement DNS interne, ainsi qu'un certificat qui correspond et qui est téléchargé dans l'espace, sont également utilisés dans le cas d'utilisation rare et atypique où vous indiquez aux utilisateurs finaux internes de se connecter directement à l'espace, au lieu de leur indiquer de se connecter à une configuration interne d' Unified Access Gateway sur l'espace. Ces connexions directes sont un cas d'utilisation inhabituel. Généralement , une instance interne d' Unified Access Gateway est utilisée à la place.
Chaîne de certificats (certificat d'autorité de certification, certificat SSL, fichier de clé SSL) qui correspond à l'enregistrement DNS interne ci-dessus créé pour les connexions de VMware Workspace ONE Access à l'espace. Pour plus d'informations, reportez-vous à la section Télécharger des certificats SSL vers un espace Horizon Cloud pour des connexions directes. (Également requis si vous utilisez le cas d'utilisation atypique pour que les utilisateurs finaux internes se connectent directement à l'espace. Les connexions directes sont une utilisation rare et inhabituelle. En général, on utilise plutôt une instance interne d'Unified Access Gateway.)

Image standard, postes de travail et batteries de serveurs Horizon Cloud

Votre abonnement Microsoft Azure doit intégrer les conditions préalables suivantes en fonction des types d'images standard, des postes de travail VDI et des batteries de serveurs RDS à provisionner depuis l'espace déployé.

Note : Lorsque votre compte est activé pour utiliser les fonctionnalités d' App Volumes et que vous utilisez l'action de capture de la console pour ajouter des applications App Volumes à votre inventaire, le système génère une attribution de poste de travail de deux machines virtuelles de poste de travail pour prendre en charge ce workflow de capture. Votre capacité devra également prendre en charge la création de ces postes de travail pendant que vous effectuez le workflow de capture. Vous pouvez supprimer cette attribution de poste de travail une fois que vous avez terminé de capturer les applications pour votre environnement.
Base de l'image standard : l'une des configurations de VM Microsoft Azure prises en charge.
  • Standard_D3_v2, Standard_D4_v3
  • Standard_D2_v2, Standard_D2_v3
  • Standard_NV6
Note : Lors de l'utilisation de l'assistant automatisé Importer une machine virtuelle depuis Marketplace pour créer une VM de base, le système utilise automatiquement par défaut l'une des tailles de VM ci-dessus. Le choix par défaut du système est basé sur des algorithmes internes qui comprennent la vérification des tailles disponibles dans la région Microsoft Azure de l'espace. Lorsque vous utilisez l'assistant pour créer une VM avec GPU activé, la VM de taille Standard_NV6 est créée par défaut. Lorsque vous utilisez l'assistant pour créer une VM basée sur un système d'exploitation de serveur, une VM de type Standard_D2_v2 ou Standard_D2_v3 est créée. Lorsque vous créez une VM basée sur un système d'exploitation client ou une VM Windows 10 multisession, une VM de type Standard_D3_v2 ou de type Standard_D4_v3 est créée.
Sélection du modèle de VM de poste de travail pour les attributions de poste de travail VDI : toutes les configurations de machine virtuelle Microsoft Azure disponibles dans la région Microsoft Azure, à l'exception de celles qui ne sont pas compatibles avec les opérations de poste de travail Horizon Cloud.

Pour les environnements de production, le test de dimensionnement de VMware recommande d'utiliser des modèles disposant d'au moins 2 CPU.

Sélection du modèle de VM RDSH pour les batteries de serveurs : toutes les configurations de machine virtuelle Microsoft Azure disponibles dans la région Microsoft Azure, à l'exception de celles qui ne sont pas compatibles avec les opérations de batterie de serveurs RDS Horizon Cloud.

Cette condition préalable s'applique également à une VM exécutant Microsoft Windows 10 Enterprise multisession lorsque cette VM est utilisée avec Horizon Cloud. Comme indiqué aux FAQ sur Windows 10 Enterprise multisession de la documentation de Microsoft Azure Windows Virtual Desktop, Microsoft Windows 10 Enterprise multisession est un type d'hôte de session Bureau à distance (RDSH) qui autorise plusieurs sessions interactives simultanées, qui ne pouvaient être fournies auparavant que par les systèmes d'exploitation Microsoft Windows Server. Les workflows Horizon Cloud qui s'appliquent aux serveurs RDS s'appliquent également à Microsoft Windows 10 Enterprise multi-session.

Pour les environnements de production, le test de dimensionnement de VMware recommande d'utiliser des modèles disposant d'au moins 2 CPU.

Attribution de licence pour les systèmes d'exploitation Microsoft Windows

Ces éléments sont associés aux systèmes d'exploitation Microsoft Windows dans vos VM importées, les images standard, les VM de serveur de batterie de serveurs compatibles RDSH et les VM de poste de travail virtuel. Pour obtenir la liste des systèmes d'exploitation Microsoft Windows pris en charge par Horizon Cloud, reportez-vous à l'article 78170 de la base de connaissances VMware et à l'article 70965 de la base de connaissances VMware.

Horizon Cloud n'attribue aucune licence de système d'exploitation invité requise pour utiliser les systèmes d'exploitation Microsoft Windows que vous utilisez dans le cadre de l'utilisation des workflows Horizon Cloud. En tant que client, il vous incombe de disposer de licences Microsoft valides et éligibles qui vous autorisent à créer et à utiliser des VM de poste de travail Windows et des VM RDSH que vous choisissez d'utiliser dans votre environnement de locataire Horizon Cloud. Vous êtes également autorisé à effectuer des workflows sur ces VM. L'attribution de licence requise dépend de votre utilisation prévue.

Info-bulle : Pour plus d'informations sur l'attribution de licence Microsoft Windows Virtual Desktop pour Windows 10 Enterprise multisession et Windows 7 Enterprise, reportez-vous à la rubrique de la documentation de Microsoft Azure Tarification de Windows Virtual Desktop.
Attribution de licence pour un ou plusieurs des types suivants : Microsoft Windows 7 Enterprise, Microsoft Windows 10 (types de clients)
Attribution de licence pour Microsoft Windows 10 Enterprise multisession
Attribution de licence pour un ou plusieurs des types suivants : Microsoft Windows Server 2012 R2, Microsoft Server 2016, Microsoft Server 2019
Serveurs de licences RDS Microsoft Windows : pour la haute disponibilité, des serveurs de licence redondants sont recommandés.
Licences d'accès client pour appareil et/ou utilisateur RDS Microsoft.

Exigences de surveillance de l'infrastructure Horizon.

Si votre locataire Horizon Cloud est activé pour utiliser Surveillance de l'infrastructure Horizon, vous pouvez utiliser Horizon Universal Console pour activer cette fonctionnalité sur votre sélection d'espaces. Lorsque vous choisissez d'activer cette fonctionnalité sur un espace, le système crée automatiquement un dispositif virtuel dans le même abonnement Microsoft Azure sur lequel réside cet espace et configure ce dispositif pour collecter les données d'infrastructure. Avant de pouvoir activer cette fonctionnalité de surveillance, votre locataire doit être intégré à VMware Cloud Services. Reportez-vous aux sections Intégrer votre locataire Horizon Cloud à VMware Cloud Services et Surveillance de l'infrastructure Horizon et espaces de votre environnement Horizon Cloud.

Intégration de votre locataire à VMware Cloud Services.
Pour chaque espace sur lequel vous allez activer la fonctionnalité Surveillance de l'infrastructure Horizon, l'abonnement Microsoft Azure de l'espace doit satisfaire ces conditions requises supplémentaires.
  • Dispositif virtuel Horizon Edge : 1 x Standard_D4_v3

Architecture de référence

Utilisez les schémas d'architecture ci-dessous pour référence.

Figure 1. Illustration de l'architecture Cloud Pod d'Horizon pour un espace avec la haute disponibilité activée et configurée avec des configurations de passerelle externe et interne, la passerelle externe déployée dans le même réseau virtuel que l'espace, trois cartes réseau sur les machines virtuelles de passerelle externe, deux cartes réseau sur les machines virtuelles de passerelle interne et une adresse IP publique activée pour l'équilibrage de charge de la passerelle externe.

Illustration de l'architecture des groupes de ressources, machines virtuelles et sous-réseaux d'un espace dont la haute disponibilité est activée et présentant deux types de configuration Unified Access Gateway, avec la passerelle externe résidant dans le même réseau virtuel que l'espace.

Figure 2. Illustration des éléments d'architecture de la passerelle externe lorsque celle-ci est déployée dans son propre réseau virtuel, séparée du réseau virtuel de l'espace avec trois cartes réseau et dans un groupe de ressources créé par le système de déploiement de l'espace

Illustration des éléments d'architecture de la passerelle externe lorsque celle-ci est déployée dans son propre réseau virtuel, séparée du réseau virtuel de l'espace et dans un groupe de ressources créé par le système de déploiement de l'espace

Ressources

Reportez-vous aux ressources suivantes pour plus d'informations.