Avant d'exécuter l'assistant de déploiement de l'espace de première génération, vérifiez que votre environnement répond à ces conditions préalables. Vous devez disposer des éléments suivants afin de pouvoir fournir les valeurs demandées dans l'assistant de déploiement de l'espace et poursuivre l'exécution de l'assistant.

Important : Ces informations s'appliquent uniquement lorsque vous avez accès à un environnement de locataire de première génération dans le plan de contrôle de première génération. Comme décrit dans l' article 92424 de la base de connaissances, le plan de contrôle de première génération a atteint la fin de disponibilité (EOA). Pour plus d'informations, consultez cet article.
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 :
  • 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. Deux exemples d'éléments devant être autorisés : vous et votre équipe informatique 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 et que vos stratégies Microsoft Azure autorisent resourceType de Microsoft.MarketplaceOrdering/*. Le processus de déploiement de l'espace repose sur l'acceptation des offres Azure Marketplace de vmware-inc publisherID de VMware. Pour plus d'informations sur les stratégies Azure, reportez-vous à la documentation correspondante. Pour plus d'informations sur la manière dont le service utilise le type de ressource Microsoft.MarketplaceOrdering/*, reportez-vous à la section Lorsque votre organisation informatique ou de sécurité présente des restrictions sur l'utilisation des offres Azure Marketplace ou les commandes Marketplace.
  • Le système de déploiement de l'espace exige que votre compte de stockage Azure lui permette de créer le type de compte Azure StorageV2 dans le groupe de ressources de l'espace dans l'abonnement. Ce compte de stockage est utilisé pour les fonctionnalités App Volumes de l'espace. Lors du processus de déploiement de l'espace, assurez-vous que vos stratégies Microsoft Azure ne limitent pas ni ne refusent la création de contenu nécessitant le type de compte Azure StorageV2.
  • 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 préalables à tous les déploiements

  • Vérifiez que toutes les tâches de préparation sont terminées, comme décrit dans Locataires de première génération - Préparation du déploiement d'un espace Horizon Cloud de première génération sur Microsoft Azure.
  • Vérifiez que vous disposez des informations d'abonnement, comme indiqué à la section Locataires de première génération - Informations liées à l'abonnement pour l'assistant de déploiement de l'espace Horizon Cloud.
  • Vérifiez que vous disposez d'un réseau virtuel existant dans votre abonnement Microsoft Azure et dans la région dans laquelle vous déployez l'espace, comme décrit à la section Horizon Cloud de première génération - Configurer le réseau virtuel requis dans Microsoft Azure.
    Important : Les régions de Microsoft Azure ne prennent pas toutes en charge les machines virtuelles avec GPU activé. Si vous voulez utiliser l'espace pour des postes de travail compatibles avec le GPU ou des applications distantes, assurez-vous que la région Microsoft Azure que vous sélectionnez pour l'espace fournit ces types de VM des série NV, NVv4 et NCv2 que vous voulez utiliser et qui sont pris en charge dans cette version d' Horizon Cloud. Pour plus de détails, reportez-vous à la documentation de Microsoft à l'adresse suivante : https://azure.microsoft.com/fr-fr/regions/services/.
  • Vérifiez que votre réseau virtuel est configuré pour pointer vers un service DNS capable de résoudre les adresses externes. Le système de déploiement de l'espace doit être capable d'accéder aux adresses externes dans le plan de contrôle d'Horizon Cloud pour télécharger en toute sécurité le logiciel de l'espace dans votre environnement Microsoft Azure.
  • Vérifiez que les conditions requises en matière de DNS, de ports et de protocoles du système de déploiement de l'espace sont remplies, comme décrit dans les sections Locataires de première génération - Déploiements d'Horizon Cloud on Microsoft Azure - Conditions requises de résolution de noms d'hôtes, Noms DNS et Locataires de première génération - Espace Horizon Cloud - Conditions requises des ports et des protocoles.
  • Si vous devez utiliser un proxy pour l’accès à Internet sortant, vérifiez que vous disposez des informations de mise en réseau pour la configuration de votre proxy et des informations d’identification d’authentification dont elle a besoin, le cas échéant. Le processus de déploiement de l'espace nécessite un accès Internet sortant.
    Important : La modification ou la mise à jour des paramètres de proxy d'un espace après son déploiement dans Microsoft Azure ne sont actuellement pas prises en charge. En outre, l'ajout d'une configuration de proxy à un espace déployé sans paramètres de proxy n'est actuellement pas pris en charge.
  • Vérifiez que vous disposez des informations pour au moins un serveur NTP dont vous voulez que les instances du gestionnaire d'espace et d'Unified Access Gateway se servent pour la synchronisation de l'heure. Le serveur NTP peut être un serveur NTP public ou votre propre serveur NTP que vous avez configuré à cet effet. Le serveur NTP que vous spécifiez doit être accessible à partir des réseaux virtuels dans lesquels vous prévoyez de déployer les instances du gestionnaire d'espace et d'Unified Access Gateway. Lorsque vous prévoyez d’utiliser un serveur NTP à l’aide de son nom de domaine au lieu d’une adresse IP numérique, vérifiez également que le serveur DNS configuré pour le réseau virtuel peut résoudre le nom du serveur NTP.
    Note : Il est recommandé d'utiliser le même serveur NTP pour les instances du gestionnaire d'espace, les instances d' Unified Access Gateway et vos serveurs Active Directory. Lorsque ces instances utilisent des serveurs NTP différents, cela peut entraîner une différence de temps. Ces différences de temps peuvent entraîner ultérieurement des échecs lorsque la passerelle tente d'authentifier les sessions des utilisateurs finaux sur leurs postes de travail et applications.
  • Si vous ne voulez pas que le système de déploiement crée automatiquement les sous-réseaux dont il a besoin, vérifiez que les sous-réseaux requis ont été créés à l'avance et qu'ils se trouvent sur le réseau virtuel. Pour découvrir les étapes de la création des sous-réseaux préalablement requis, reportez-vous aux sections Locataires de première génération - Avant le déploiement de l'espace, créer les sous-réseaux requis de l'espace Horizon Cloud sur votre réseau virtuel dans Microsoft Azure et Locataires de première génération - Cas d'utilisation de sous-réseaux pour un espace Horizon Cloud dans Microsoft Azure.
    Attention : Les sous-réseaux que vous créez manuellement à l'avance dans votre réseau virtuel pour le déploiement de l'espace doivent rester vides. Ne réutilisez pas les sous-réseaux existants qui disposent déjà d'éléments qui utilisent des adresses IP sur ces sous-réseaux. Si une adresse IP est déjà utilisée sur les sous-réseaux, des problèmes tels que l'échec du déploiement de l'espace et d'autres problèmes de conflit d'adresses IP en aval ont une forte chance de se produire. Ne placez pas de ressources sur ces sous-réseaux ou sinon utilisez une adresse IP quelconque. Cette mise en garde inclut les espaces déployés depuis Horizon Cloud — ne réutilisez pas les sous-réseaux sur lesquels un espace est déjà déployé.
  • Si vous configurez le système de déploiement afin qu'il crée les sous-réseaux requis, veillez à connaître les plages d'adresses que vous allez entrer dans l'assistant pour le sous-réseau de gestion, de poste de travail et de zone DMZ. Le sous-réseau de zone DMZ est requis lorsque vous souhaitez la configuration externe d'Unified Access Gateway. Vérifiez également que ces plages ne se chevauchent pas. Vous devez entrer les plages d'adresses en utilisant la notation CIDR (routage interdomaines sans classe). L'assistant affichera un message d'erreur si les plages de sous-réseaux entrées se chevauchent. Pour la plage de sous-réseaux de gestion, un CIDR d'au moins /27 est requis. Pour la plage de sous-réseaux de zone DMZ, un CIDR d'au moins /28 est requis. Si vous souhaitez conserver les plages des sous-réseaux de gestion et de zone DMZ au même endroit, vous pouvez spécifier la même plage de sous-réseaux de zone DMZ que le sous-réseau de gestion avec une adresse IP spécifiée. Par exemple, si le sous-réseau de gestion est 192.168.8.0/27, un sous-réseau de zone DMZ correspondant sera 192.168.8.32/27.
    Important : Les CIDR que vous entrez dans les champs de l'assistant doivent être définis de sorte que chaque combinaison de préfixe et de masque de bits donne lieu à une plage d’adresses IP ayant le préfixe comme adresse IP de début. Microsoft Azure nécessite que le préfixe CIDR soit le début de la plage. Par exemple, un CIDR correct de 192.168.182.48/28 donnerait lieu à une plage d’adresses IP de 192.168.182.48 à 192.168.182.63, et le préfixe est identique à l’adresse IP de début (192.168.182.48). Cependant, un CIDR incorrect de 192.168.182.60/28 donnerait lieu à une plage d’adresses IP de 192.168.182.48 à 192.168.182.63, où l’adresse IP de début n'est pas la même que le préfixe de 192.168.182.60. Assurez-vous que vos CIDR donnent lieu à des plages d’adresses IP où l’adresse IP de début correspond au préfixe CIDR.
  • Si vous configurez le système de déploiement afin qu'il crée les sous-réseaux requis, vérifiez que des sous-réseaux ayant ces plages d'adresses n'existent pas déjà sur le réseau virtuel. Dans ce scénario, le système de déploiement lui-même créera automatiquement les sous-réseaux en utilisant les plages d'adresses que vous indiquez dans l'assistant. Si l’assistant détecte que des sous-réseaux avec ces plages existent déjà, il affichera un message d'erreur sur le chevauchement des adresses et ne poursuivra pas plus loin. Si votre réseau virtuel est lié, vérifiez également que les espaces d'adresses CIDR que vous prévoyez d'entrer dans l'assistant sont déjà contenus dans l'espace d'adresses du réseau virtuel.

Conditions préalables pour les configurations de Unified Access Gateway

Si vous prévoyez que l'espace utilisera une configuration d'Unified Access Gateway, vous devez fournir les éléments suivants :

  • Le nom de domaine complet (FQDN) que vos utilisateurs finaux utiliseront pour accéder au service. Si vous prévoyez d'utiliser le même nom de domaine complet pour les configurations de passerelles externe et interne, après le déploiement de l'espace, vous devez configurer le trafic client entrant de l'utilisateur final à acheminer vers l'équilibrage de charge de passerelle approprié. L'objectif est de configurer le routage pour que le trafic client d'Internet soit acheminé vers l'équilibrage de charge public Microsoft Azure de la passerelle externe et que le trafic client de votre intranet soit acheminé vers l'équilibrage de charge interne Microsoft Azure de la passerelle interne. Dans le cas où les deux passerelles disposent du même nom de domaine complet, 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.
    Important : Ce FQDN ne peut pas contenir de traits de soulignement. Dans cette version, les connexions aux instances d' Unified Access Gateway échoueront lorsque le FQDN contient des traits de soulignement.
  • Un certificat de serveur SSL signé (au format PEM) basé sur ce FQDN. Les capacités d’Unified Access Gateway requièrent SSL pour les connexions client, comme décrit dans la documentation du produit Unified Access Gateway. Le certificat doit être signé par une autorité de certification approuvée. Le fichier PEM doit contenir la chaîne de certificats complète avec la clé privée. Par exemple, le fichier PEM doit contenir le certificat de serveur SSL, des certificats d’autorité de certification intermédiaires nécessaires, le certificat d’autorité de certification racine et la clé privée. OpenSSL est un outil que vous pouvez utiliser pour créer le fichier PEM.
    Important : Tous les certificats de la chaîne doivent comprendre des périodes valides. Les machines virtuelles Unified Access Gateway requièrent que tous les certificats de la chaîne, y compris les certificats intermédiaires, aient des périodes valides. Si un certificat dans la chaîne est expiré, des défaillances inattendues peuvent se produire ultérieurement, car le certificat est téléchargé dans la configuration d' Unified Access Gateway.
  • Si vous effectuez un déploiement avec une configuration externe d'Unified Access Gateway, vous devez spécifier un sous-réseau de zone DMZ (zone démilitarisée). Vous devez indiquer un sous-réseau de DMZ en utilisant l'une des deux manières suivantes :
    • Création du sous-réseau de zone DMZ à l'avance sur le réseau virtuel. Avec cette méthode, vous devez également créer les sous-réseaux de locataire de poste de travail et de gestion à l'avance. Reportez-vous aux instructions décrites dans la section Locataires de première génération - Avant le déploiement de l'espace, créer les sous-réseaux requis de l'espace Horizon Cloud sur votre réseau virtuel dans Microsoft Azure.
    • Configuration du système de déploiement pour qu'il crée le sous-réseau de zone DMZ lors du déploiement. Avec cette méthode, vous devez disposer de la plage d'adresses que vous allez entrer dans l'assistant du sous-réseau de DMZ et vérifier que la plage n'interfère pas avec celles des sous-réseaux de locataire de poste de travail et de gestion. Vous devez entrer les plages d'adresses en utilisant la notation CIDR (routage interdomaines sans classe). L'assistant affichera un message d'erreur si les plages de sous-réseaux entrées se chevauchent. Pour la plage de sous-réseaux de zone DMZ, un CIDR d'au moins /28 est requis. Si vous souhaitez conserver les plages des sous-réseaux de gestion et de zone DMZ au même endroit, vous pouvez spécifier la même plage de sous-réseaux de zone DMZ que le sous-réseau de gestion avec une adresse IP spécifiée. Par exemple, si le sous-réseau de gestion est 192.168.8.0/27, un sous-réseau de zone DMZ correspondant sera 192.168.8.32/27. Reportez-vous également à la remarque importante de la section Conditions préalables à tous les déploiements à propos de la vérification que la plage d'adresses IP possède une combinaison de préfixe et de masque de bits permettant d'avoir la plage ayant le préfixe comme adresse IP de début.
  • Si vous effectuez un déploiement avec une configuration externe d'Unified Access Gateway et que vous ne souhaitez aucune adresse IP publique pour l'équilibrage de charge de la configuration, vous devez indiquer une adresse IP que vous avez mappée dans vos paramètres DNS au nom de domaine complet que vos utilisateurs finaux utiliseront pour les connexions PCoIP dans leurs instances d'Horizon Client.

Pour plus d’informations sur les considérations du fichier PEM requises par Unified Access Gateway, reportez-vous à la section Locataires de première génération - Convertir un fichier de certificat au format PEM requis pour les déploiements d'espaces Horizon Cloud de première génération.

Conditions préalables lors du déploiement avec une configuration Unified Access Gateway externe à l'aide de son propre réseau virtuel ou abonnement distinct du réseau virtuel ou de l'abonnement de l'espace

Note : Le déploiement d'une passerelle externe utilisant son propre réseau virtuel déploiera une VM de connecteur de passerelle. Dans Conditions requises de ports et de protocoles pour un espace Horizon Cloud, la section qui décrit les ports et protocoles de la VM de connecteur de passerelle contient également une description de cette VM de connecteur de passerelle, qui indique qu'elle porte un nom qui contient une partie comme vmw-hcs-ID, où ID est l'ID du système de déploiement de la passerelle, et une partie node.

Outre les conditions préalables ci-dessus lors du déploiement avec une configuration Unified Access Gateway, ces conditions préalables sont spécifiques au cas de déploiement de la passerelle externe dans son propre réseau virtuel ou abonnement. L'utilisation de son propre abonnement est un cas particulier d'utilisation de son propre réseau virtuel, car l'abonnement distinct doit disposer de son propre réseau virtuel, les réseaux virtuels étant limités à un abonnement.

Conditions préalables au déploiement avec une configuration de l'authentification à deux facteurs

Si vous prévoyez d'utiliser la capacité d'authentification à deux facteurs ou de l'utiliser avec un serveur d'authentification à deux facteurs sur site, vérifiez que vous disposez des informations suivantes de la configuration de votre serveur d'authentification, afin de pouvoir les fournir dans les champs obligatoires de l'assistant Ajouter un espace.

Obtenez les informations répertoriées ci-dessous en fonction du type que vous possédez.

RADIUS

Si vous configurez les paramètres d'un serveur RADIUS principal et auxiliaire, procurez-vous les informations pour chacun d'eux.

  • Adresse IP ou nom DNS du serveur d'authentification
  • Secret partagé utilisé pour le chiffrement et le déchiffrement dans les messages de protocole du serveur d'authentification
  • Numéros de port d'authentification, généralement 1812/UDP pour RADIUS.
  • Type de protocole d'authentification. Les types d'authentification incluent PAP (Password Authentication Protocol), CHAP (Challenge Handshake Authentication Protocol), MSCHAP1, MSCHAP2 (Microsoft Challenge Handshake Authentication Protocol, versions 1 et 2).
    Note : Consultez la documentation de votre fournisseur RADIUS pour connaître le protocole d'authentification recommandé par votre fournisseur RADIUS et suivez le type de protocole indiqué. La capacité de l'espace à prendre en charge l'authentification à deux facteurs avec RADIUS est fournie par les instances d'Unified Access Gateway. En outre, Unified Access Gateway prend en charge PAP, CHAP, MSCHAP1 et MSCHAP2. PAP est généralement moins sécurisé que MSCHAP2. PAP est également un protocole plus simple que MSCHAP2. Par conséquent, même si la plupart des fournisseurs RADIUS sont compatibles avec le protocole PAP plus simple, certains fournisseurs RADIUS ne sont pas aussi compatibles avec le protocole MSCHAP2 plus sécurisé.
RSA SecurID
Note : Le type RSA SecurID est pris en charge avec les déploiements Horizon Cloud on Microsoft Azure qui exécutent le manifeste 3139.x ou version ultérieure. L'option de l'interface utilisateur permettant d'indiquer le type RSA SecurID dans les assistants Ajouter un espace et Modifier l'espace s'affichera pour la sélection dans les assistants à partir de la mi-mars 2022.
  • Clé d'accès à partir du serveur RSA SecurID Authentication Manager.
  • Numéro de port de communication RSA SecurID. En général, 5555, tel que défini dans les paramètres système de RSA Authentication Manager pour l'API d'authentification RSA SecurID.
  • Nom d'hôte du serveur RSA SecurID Authentication Manager.
  • Adresse IP de ce serveur RSA SecurID Authentication Manager.
  • Si le serveur RSA SecurID Authentication Manager ou son serveur d'équilibrage de charge dispose d'un certificat auto-signé, vous devrez fournir le certificat d'autorité de certification dans l'assistant Ajouter un espace. Le certificat doit être au format PEM (types de fichiers .cer, .cert ou .pem)