Conditions préalables à la migration d'un espace Horizon Cloud de première génération

Cette page décrit les zones que vous devez évaluer, préparer et mettre à jour si nécessaire avant de démarrer la migration de votre premier espace.

Introduction

La plupart de ces évaluations et étapes de préparation peuvent s'effectuer à tout moment avant de vous connecter à votre nouvel environnement Horizon Cloud et d'afficher l'UI de migration.

Certaines de ces évaluations et étapes de préparation impliquent l'environnement d'abonnement Microsoft Azure et le réseau dans lequel l'espace de première génération est déployé. Pour celles-ci, vous aurez peut-être besoin de l'aide de votre équipe informatique qui gère cet environnement.

Souvenez-vous que : au moment de la rédaction de ce document, la condition à remplir pour migrer un espace de première génération est un déploiement progressif vers des locataires de première génération. Lorsque la condition sera remplie, vous recevrez un message direct du service de communications de l'équipe de migration d'Horizon.

Terminologie

Horizon Cloud Service introduit de nouveaux concepts et une nouvelle terminologie. Dans Horizon Cloud Service, le déploiement est appelé dispositif Horizon Edge (au lieu du terme espace).

La migration en libre-service est conçue pour déployer un dispositif Horizon Edge de Microsoft Azure dans le même abonnement Microsoft Azure que celui utilisé pour la migration de l'espace de première génération, et en utilisant les mêmes informations d'abonnement, réseaux virtuels et sous-réseaux.

Lorsque chaque espace est migré, le processus réutilise les éléments suivants par défaut à partir de cet espace :

ID d'abonnement Microsoft Azure, ID d'annuaire, ID d'application de principal de service et clé secrète.
vNet
Sous-réseau de gestion, sous-réseau de locataire et sous-réseau de zone DMZ
Informations de domaine Active Directory et comptes de service de liaison de domaine et de jonction de domaine enregistrés dans le locataire de première génération (utilisateurs de liaison de domaine et de jonction de domaine, utilisateurs de liaison de domaine et utilisateurs de jonction de domaine auxiliaires).

Lorsque la migration de votre premier espace est planifiée, le système copie toutes les informations du domaine Active Directory et les informations du compte de service enregistrées du locataire de première génération et les enregistre dans l'environnement Horizon Cloud.

Certains éléments de l'espace de première génération ne sont pas réutilisés. Pour certains d'entre eux, vous devez configurer de nouvelles ressources supplémentaires.

Par conséquent, vous devez évaluer les points suivants et vous préparer, le cas échéant, à répondre aux conditions requises d'Horizon Cloud.

Remarque : pour les espaces ayant des caractéristiques spéciales, le processus de migration peut nécessiter l'utilisation d'un nouveau réseau virtuel et d'un sous-réseau de gestion différents de ceux de l'espace de première génération. Ce cas spécial est décrit dans la section de cette page.

Tableau des conditions préalables

Les sections qui suivent ce tableau fournissent les détails de chacune de ces conditions préalables. Ce tableau est inclus comme plan pratique.

☐	Obtenez un nouveau nom de domaine complet et un nouveau certificat pour l'instance d'Unified Access Gateway d'Horizon Cloud.
☐	Évaluez les versions de l'espace et de l'agent de première génération et mettez-les à jour si nécessaire.
☐	Assurez-vous que toutes les images qui doivent être migrées sont valides.
☐	Déterminez si le réseau virtuel ou les réseaux connectés de l'espace contiennent des adresses IP restreintes par AKS.
☐	Choisissez le type de déploiement et remplissez ses conditions requises.
☐	Dans la première génération, si le nom de votre abonnement à Microsoft Azure inclut des caractères non anglais, renommez l'abonnement pour utiliser des caractères anglais uniquement avant de migrer vers Horizon Cloud.
☐	Déterminez si l'abonnement Microsoft Azure de l'espace dispose de stratégies autour des balises de groupe de ressources. Si oui, préparez un plan pour gérer les conditions requises de migration.
☐	Mise en réseau : évaluez les paramètres existants pour votre trafic réseau et mettez-les à jour si nécessaire.
☐	Vérifiez que la clé secrète de l'application associée de l'espace est toujours valide.
☐	Réseau virtuel : évaluez le routage actuel que vous utilisez pour l'accès interne aux postes de travail.
☐	Évaluez les quotas de la famille vCPU de Microsoft Azure et augmentez-les si nécessaire.
☐	Évaluez les stratégies Azure sur l'abonnement et le groupe de ressources de l'espace et assurez-vous que les stratégies autorisent le provisionnement des comptes de stockage et des partages de fichiers d'Horizon Edge Gateway.
☐	Lorsque l'espace dispose d'applications App Volumes, respectez les instructions pour vous assurer que les stratégies autorisent le basculement de l'accès réseau sur les comptes de stockage.
☐	Lorsque vous disposez d'une adresse IP publique pour l'équilibreur de charge d'Unified Access Gateway, suivez les instructions de la section Dans le cas d'une adresse IP publique pour cet équilibreur de charge.
☐	Lorsque vous disposez d'une adresse IP privée pour l'équilibreur de charge d'Unified Access Gateway, suivez les instructions de la section Dans le cas d'une adresse IP privée pour cet équilibreur de charge.
☐	Évaluez la capacité à vous connecter à votre nouvel environnement Horizon Cloud et affichez l'instance d'Horizon Cloud Horizon Universal Console.
☐	Choisissez votre fournisseur d'identité et synchronisez les utilisateurs et les groupes AD avec celui-ci.
☐	Évaluez votre utilisation des utilisateurs intégrés ou des groupes intégrés Active Directory et mettez-les à jour si nécessaire.
☐	Évaluez votre utilisation des attributions des applications App Volumes.
☐	Cas spécial : si l'enregistrement d'application de votre espace de première génération utilise un rôle personnalisé, mettez à jour les autorisations requises pour un déploiement d'Horizon Cloud en suivant les instructions de la section Si l'enregistrement de l'application de votre espace de première génération utilise un rôle personnalisé.

Obtenez un nouveau nom de domaine complet et un nouveau certificat pour l'instance d'Unified Access Gateway d'Horizon Cloud.

Remarque : le nom de domaine complet du déploiement de l'instance d'Unified Access Gateway d'Horizon Cloud doit être différent de celui déjà utilisé pour le déploiement de première génération devant être migré. Pour prendre en charge la restauration vers le déploiement de première génération dans les rares cas où des problèmes postérieurs à la migration surviennent, le nom de domaine complet de la passerelle du déploiement de première génération et son certificat SSL doivent rester tels que configurés pour le déploiement de première génération. Ce n'est qu'après avoir finalisé la migration que vous pouvez mettre à jour le nom de domaine complet et le certificat SSL du déploiement de passerelles Horizon Cloud si vous le souhaitez.

L'interface utilisateur de l'assistant de planification vous oblige à spécifier ce nom de domaine complet dans l'assistant et à fournir le certificat SSL selon ce nom de domaine complet.

Pour l'environnement Horizon Cloud, le certificat SSL peut être au format PEM ou PFX.

Le nom commun ou le nom de domaine complet défini dans le certificat doit correspondre au nom de domaine complet que vous prévoyez d'entrer dans l'assistant de planification. L'assistant confirme que les données du certificat correspondent au nom de domaine complet entré dans l'assistant.

Remarque : si votre espace de première génération dispose d'une configuration d'Unified Access Gateway externe et d'une configuration d'Unified Access Gateway interne, le type d'accès de l'instance d'Unified Access Gateway du dispositif Edge après la migration est défini sur Accès interne et externe, avec le nom de domaine complet externe et le nom de domaine complet interne définis sur le même nom de domaine complet par défaut (le nom de domaine complet que vous entrez dans l'assistant de planification). Si, après la migration, vous souhaitez utiliser un nom de domaine complet différent pour l'accès interne, modifiez alors les détails de l'instance d'Unified Access Gateway du dispositif Edge pour remplacer son nom de domaine complet interne par celui que vous souhaitez utiliser, et configurez les plages réseau pour les utilisateurs internes de manière appropriée. Notez que le certificat chargé doit inclure le nom de domaine complet externe et le nom de domaine complet interne dans les informations du certificat (par exemple, avoir le nom de domaine complet interne dans les données de nom alternatif du sujet).

Évaluez les versions de l'espace et de l'agent de première génération et mettez-les à jour si nécessaire.

Avant de migrer un espace, les versions de l'espace et de l'agent doivent répondre aux critères suivants :

Les espaces Horizon Cloud Azure doivent exécuter le manifeste d'espace 5041.0 ou une version ultérieure. Si vous exécutez un manifeste antérieur, lancez une demande de service pour mettre à niveau l'espace.
Les postes de travail VDI dédiés de l'espace doivent exécuter Horizon Agents Installer version 24.2.0 ou ultérieure.

Assurez-vous que toutes les images qui doivent être migrées sont valides.

Pour éviter les problèmes lors de la phase de pré-génération de la migration, assurez-vous que toutes les images de première génération qui doivent être migrées sont à l'état Publié et que leurs machines virtuelles et leurs snapshots sont intacts dans Microsoft Azure.

Déterminer si le réseau virtuel ou les réseaux connectés de l'espace contiennent des adresses IP restreintes par AKS

Important : le résultat de votre détermination fournit des conseils sur le type de déploiement d'Horizon Edge Gateway que vous choisissez d'utiliser pour la migration. Les types sont décrits dans la section suivante intitulée Choisir votre type de déploiement de passerelle Edge.

Déterminez si le sous-réseau de gestion, le réseau virtuel ou les réseaux de l'espace de première génération auxquels le réseau virtuel est connecté (tels que votre réseau sur site connecté via ExpressRoute) contiennent des adresses IP provenant des plages restreintes par AKS répertoriées ici :

169.254.0.0/16
172.30.0.0./16
172.31.0.0/16
192.0.2.0/24

Si oui, pour migrer cet espace, vous devez ensuite évaluer si le type de déploiement de VM unique peut répondre à vos besoins ou si seul le type de déploiement AKS peut répondre à vos conditions requises.

Utilisez le type de déploiement de VM unique pour migrer cet espace, ou
Si vos conditions requises imposent d'utiliser le type de déploiement AKS, vous devez configurer un nouveau réseau virtuel et un sous-réseau de gestion d'un CIDR minimal de /26 dans ce réseau virtuel de l'abonnement de l'espace et appairer ce nouveau réseau virtuel au réseau virtuel existant de l'espace. Le CIDR minimal de /26 est fortement recommandé pour le type de déploiement AKS.

Assurez-vous que rien dans le nouveau réseau virtuel ne contient ou n'utilise les adresses IP provenant des plages restreintes. Avec le nouveau réseau virtuel et le sous-réseau de gestion, vous pouvez utiliser le type de déploiement AKS qui fournit la haute disponibilité (HA).

Pour obtenir des instructions détaillées, reportez-vous à la section suivante sur le choix de votre type de déploiement de passerelle Edge.

La raison pour laquelle ces plages spécifiques sont restreintes par AKS s'explique par le fait que Microsoft impose cette règle concernant ses clusters AKS (Azure Kubernetes Service) utilisés pour le type AKS du déploiement de la passerelle Horizon Edge.

Si ces adresses IP limitées sont contenues dans le sous-réseau de gestion ou le réseau virtuel de l'espace, ou contenues dans le réseau sur site connecté au réseau virtuel, le processus de migration utilisant le type AKS ne peut pas réutiliser le réseau virtuel existant de l'espace.

Choisissez le type de déploiement et remplissez ses conditions requises.

Lors de la migration d'un espace de première génération vers l'environnement Horizon Cloud, le système déploie ce que l'on appelle une passerelle Horizon Edge Gateway dans l'abonnement Microsoft Azure de l'espace.

Le déploiement est disponible en deux types : le type Machine virtuelle unique (VM unique) ou le type AKS (Azure Kubernetes Service).

Le système vous permet de spécifier le type à utiliser pour la migration de chaque espace.

Par conséquent, vous devez choisir le type à utiliser, en fonction des qualités requises, selon le tableau suivant.

Déploiement de la passerelle Edge	Qualités clés	Détails
VM unique	Prend en charge jusqu'à 5K (5 000) sessions. Moins de conditions préalables impliquées dans l'abonnement Microsoft Azure que pour le type AKS Prend en charge des migrations d'espaces qui ne peuvent pas répondre facilement aux conditions requises d'AKS. Si, ultérieurement, le dispositif déployé n'est pas disponible, le comportement qui en résulte est le suivant : Les utilisateurs finaux devront se connecter sans Single Sign-On (SSO). Les données de surveillance des postes de travail ne sont pas enregistrées pendant la période d'indisponibilité de la VM.	Le type VM unique permet plus de simplicité lors de la migration d'un espace de première génération que le type AKS. Ce choix permet plus de simplicité, car le type VM unique exige moins de nouvelles conditions requises dans l'abonnement Azure de l'espace que le type AKS. Par conséquent, il prend en charge les déploiements d'espaces de première génération qui ne peuvent pas répondre facilement aux conditions requises du type AKS. Outre la simplicité, le type VM unique diffère du type AKS dans son comportement si la VM déployée n'est plus disponible. Lorsqu'il n'est pas disponible : Les utilisateurs finaux verront le flux de connexion sans expérience de connexion SSO. Par exemple, avant d'afficher leur poste de travail, ils devront se connecter à l'aide de leurs informations d'identification d'Active Directory. Les données de surveillance des postes de travail qui sont envoyées à la VM de la passerelle Edge ne sont pas enregistrées pendant la période d'indisponibilité de la VM.
AKS	Prend en charge plus de 5K (5 000) sessions. Azure Kubernetes Service présente des conditions requises liées à Microsoft qui doivent être remplies Prend en charge les migrations d'espaces qui peuvent répondre aux conditions requises d'AKS. L'expérience de connexion SSO et la collecte de données de surveillance sont gérées via des services répliqués qui permettent une distribution hautement disponible de ces fonctions	AKS est une norme Microsoft Azure pour les applications cloud natives d'entreprise dans les centres de données Microsoft Azure. Le type AKS fournit une passerelle Edge d'une architecture en cluster, qui fournit des services répliqués prenant en charge l'expérience de connexion SSO et la collecte de données de surveillance.

Deux questions pour le tableau de décision suivant :
1. Avez-vous des conditions requises pour la prise en charge de plus de 5K sessions ou de l'expérience de connexion SSO et la collecte des données de surveillance via des services avec une capacité de basculement complète en cas de panne ?
2. Disposez-vous de plages d'adresses IP restreintes par AKS contenues dans le sous-réseau de gestion de l'espace, le réseau virtuel de l'espace ou utilisées par les machines connues de ce réseau virtuel connecté à votre réseau sur site ?

Vos réponses	Méthode à utiliser	Conditions préalables à remplir
Oui Non	Si vous répondez Oui à la première question, le type AKS est requis. Lorsque vous avez besoin de plus de 5K sessions et que vous devez répondre aux conditions requises relatives à l'expérience de connexion SSO et à la collecte de données de surveillance, le type AKS est requis pour les fournir.	Conditions préalables du type AKS
Oui Oui	Si vous répondez Oui à la première question, le type AKS est requis. Dans ce cas, vous avez besoin du type AKS pour fournir plus de 5K sessions et répondre aux conditions requises relatives à l'expérience de connexion SSO et à la collecte des données de surveillance, mais le réseau virtuel de l'espace s'oppose aux restrictions d'adresses IP du type AKS. Pour prendre en charge les conditions requises du type AKS, vous devez effectuer les opérations suivantes : Configurez un autre réseau virtuel et un autre sous-réseau de gestion dans ce réseau virtuel de l'abonnement de l'espace, qui ne contient pas les adresses IP restreintes. Assurez-vous que le nouveau réseau virtuel et le sous-réseau de gestion répondent aux conditions requises de la passerelle Edge AKS. Appairez ce nouveau réseau virtuel au réseau virtuel existant de l'espace. Ensuite, lors de l'exécution de l'assistant de migration, sélectionnez le nouveau réseau virtuel et le sous-réseau de gestion, ainsi que l'option Azure Kubernetes Service.	Conditions préalables du type AKS
Non Non	Si vous répondez Non à la première question, le type VM unique répond à vos besoins. Parallèlement, étant donné que le réseau virtuel de l'espace répond aux restrictions d'adresses IP du type AKS, vous pouvez également décider d'utiliser le type AKS pour la migration.	Le type VM unique ne présente pas de conditions requises spécifiques en dehors de celles qui sont détaillées dans la section « Conditions préalables à la migration d'un espace Horizon Cloud de première génération » et de toutes ses sous-sections.
Non Oui	Si vous répondez Non à la première question, le type VM unique répond à vos besoins. Vous avez choisi l'une des deux options : L'option la plus simple consiste à utiliser le type VM unique. L'option plus complexe consiste à contourner les adresses IP restreintes par AKS des manières suivantes : Configuration d'un autre réseau virtuel et d'un sous-réseau de gestion dans ce réseau virtuel dans l'abonnement de l'espace qui ne contient pas les adresses IP restreintes. Vérification que le nouveau réseau virtuel et le sous-réseau de gestion répondent aux conditions requises de la passerelle Edge AKS. Appairage de ce nouveau réseau virtuel au réseau virtuel existant de l'espace En exécutant les éléments ci-dessus, vous pouvez également choisir le type AKS, si vous le souhaitez.	Le type VM unique ne présente pas de conditions requises spécifiques en dehors de celles qui sont détaillées dans la section « Conditions préalables à la migration d'un espace Horizon Cloud de première génération » et de toutes ses sous-sections.

Déterminer si l'abonnement Microsoft Azure de l'espace dispose de stratégies autour des balises de groupes de ressources

Au moment de la rédaction de ce document, le processus de déploiement d'Horizon Edge nécessite que l'abonnement Microsoft Azure autorise la création de groupes de ressources sans balises.

Immédiatement après la planification du jour et de l'heure de la fenêtre de maintenance de la migration, le système crée des groupes de ressources pour la passerelle Horizon Edge et les instances d'Unified Access Gateway.

Par conséquent, si l'abonnement de l'espace dispose de stratégies Microsoft Azure qui bloquent la création de groupes de ressources non balisés, ou si l'abonnement présente un type de condition de balise de ressource, le processus de migration échoue peu après cette étape de planification.

Si l'abonnement dispose de cette stratégie, vous pouvez gérer cette condition en établissant un plan pour désactiver cette stratégie Azure juste avant l'exécution de l'assistant de planification de la migration et laisser la stratégie désactivée jusqu'au déploiement de la passerelle Horizon Edge et des instances d'Unified Access Gateway dans l'abonnement. Lorsque vous voyez que la passerelle Horizon Edge et les instances d'Unified Access Gateway sont déployées, la stratégie Azure pour exiger des balises lors de la création de groupes de ressources peut être réactivée sans affecter les activités de migration.

Mise en réseau : évaluer les paramètres existants pour votre trafic réseau et les mettre à jour si nécessaire

Déterminez si vos paramètres de pare-feu actuels autorisent la connectivité aux points de terminaison, ainsi qu'aux ports et protocoles requis par le dispositif Horizon Cloud Horizon Edge.

Les URL et les ports des points de terminaison requis par Horizon Cloud Service sont probablement différents de ceux que votre équipe réseau a déjà autorisés pour l'espace de première génération.

Pour obtenir la liste des points de terminaison, des ports et des protocoles requis, reportez-vous aux pages suivantes du guide Utilisation d'Horizon Cloud et déterminez les modifications à apporter dans l'environnement de l'espace de première génération.

Lorsqu'il n'est pas possible d'utiliser une URL, reportez-vous à l'article 6000374 de la base de connaissances - Adresses IP des composants de service.

Lorsque votre espace de première génération utilise un proxy :
* Vous devez autoriser l'URL softwareupdate.omnissa.com dans votre pare-feu, car le trafic proxy n'est actuellement pas pris en charge pour cette URL. Sans cette configuration, le processus de mise à jour de l'agent ne fonctionnera pas.
* Si vous disposez de pools dédiés, vous devez autoriser le Hub de VM global et les points de terminaison du Hub de VM régional appropriés dans votre pare-feu pour le sous-réseau de locataire (poste de travail) pendant la fenêtre de migration planifiée (fenêtre de maintenance). Cela est dû au fait que les machines virtuelles dédiées de première génération n'obtiennent pas automatiquement la configuration du proxy et que les agents de ces machines virtuelles doivent atteindre les points de terminaison du Hub de machine virtuelle pour les opérations liées à l'agent, telles que la signature de certificats à l'aide du Hub de VM et le renouvellement. Si vous ne souhaitez pas autoriser les points de terminaison du Hub de machine virtuelle dans votre pare-feu pour la migration, avant d'exécuter la migration, vous pouvez définir directement la configuration du proxy dans le registre des machines virtuelles dédiées de première génération à l'aide des commandes. Cela permettra aux agents des VM dédiées de communiquer avec les points de terminaison du Hub de VM. Reportez-vous aux sections Nom d'hôte DNS du Hub de VM global et Noms d'hôtes DNS du Hub de VM régional de la documentation d'Horizon Cloud.

Lorsqu'un espace de première génération est configuré avec un proxy, les pools migrés héritent de la configuration du proxy. Pendant la migration, les pools de postes de travail dédiés doivent se connecter directement à des URL spécifiques via Internet, contournant ainsi le proxy. Si un pare-feu est en place pour la connectivité sortante à partir du sous-réseau VDI de poste de travail, ces URL doivent être autorisées pendant le processus de migration. Une fois la migration terminée, vous pouvez supprimer ces URL de la liste autorisée.

URL permettant d'autoriser des machines virtuelles dédiées pendant la migration
USA : cloud-sg-us-r-westus2.horizon.omnissa.com cloud-sg-us-r-eastus2.horizon.omnissa.com EUROPE : cloud-sg-eu-r-northeurope.horizon.omnissa.com cloud-sg-eu-r-germanywestcentral.horizon.omnissa.com cloud-sg-eu-r-uksouth.horizon.omnissa.com JAPON : cloud-sg-jp-r-japaneast.horizon.omnissa.com cloud-sg-jp-r-australiaeast.horizon.omnissa.com cloud-sg-jp-r-centralindia.horizon.omnissa.com

URL permettant d'autoriser des machines virtuelles dédiées pendant la migration

USA :
cloud-sg-us-r-westus2.horizon.omnissa.com
cloud-sg-us-r-eastus2.horizon.omnissa.com

EUROPE :
cloud-sg-eu-r-northeurope.horizon.omnissa.com
cloud-sg-eu-r-germanywestcentral.horizon.omnissa.com
cloud-sg-eu-r-uksouth.horizon.omnissa.com

JAPON :
cloud-sg-jp-r-japaneast.horizon.omnissa.com
cloud-sg-jp-r-australiaeast.horizon.omnissa.com
cloud-sg-jp-r-centralindia.horizon.omnissa.com

Vérifier que la clé secrète de l'application associée de l'espace est toujours valide

Connectez-vous au portail Azure pour le déploiement de votre espace et vérifiez que la clé d'application utilisée par l'espace n'a pas expiré.

Le portail Azure utilise le terme clé secrète du client dans la zone Enregistrement de l'application. Recherchez l'enregistrement d'application associé à l'espace.

VNet : évaluer le routage pour l'accès interne aux postes de travail

Selon le routage que vous avez mis en place pour l'espace de première génération et l'accès interne aux postes de travail, vous devrez peut-être ajuster ce routage pour qu'il continue à fonctionner pour l'accès interne aux postes de travail dans le dispositif Horizon Cloud Horizon Edge.

Évaluer les quotas de la famille de vCPU Microsoft Azure et les augmenter si nécessaire

En fonction des quotas actuels de la famille de vCPU dans l'abonnement Microsoft Azure de votre espace de première génération, vous devrez peut-être augmenter le quota pour des familles de vCPU spécifiques afin de prendre en charge le processus de migration.

Le processus de migration déploie un dispositif Horizon Edge qui se compose d'au moins une passerelle Horizon Edge et de deux instances d'Unified Access Gateway.

Un dispositif Horizon Edge déployé dans Microsoft Azure dispose d'une passerelle Horizon Edge de type de déploiement VM unique ou de type de déploiement AKS.

Décidez du type à utiliser pour la migration de l'espace, comme décrit dans la section Choisir votre type de déploiement de passerelle Edge.

Objectif	Besoins de vCPU/quota supplémentaires
Instances d'Unified Access Gateway	Quota supplémentaire pour prendre en charge deux (2) Standard_F8s_v2
Passerelle Horizon Edge : type de déploiement VM unique, si vous optez pour ce type	Quota supplémentaire pour prendre en charge 1 VM avec les tailles de SKU de VM suivantes : Standard_D4s_v3 - 4 vCPU Standard_D4s_v4 - 4 vCPU Standard_D4s_v5 - 4 vCPU
Passerelle Horizon Edge : type de déploiement AKS, si vous optez pour ce type	Quota supplémentaire pour prendre en charge 5 des tailles de SKU de VM suivantes : Standard_D2s_v3 - 2 vCPU Standard_D2ds_v5 - 2 vCPU Standard_D2a_v4 - 2 vCPU Si l'abonnement de l'espace peut prendre en charge cinq (5) d'au moins une des tailles de SKU de VM répertoriées ci-dessus, la migration requise de la passerelle Edge à 4 nœuds (AKS) est remplie ainsi que la condition d'un nœud pour les futures mises à niveau d'AKS. Ces conditions requises de SKU de VM reposent sur le fait qu'un déploiement de passerelle Edge (AKS) utilise un cluster AKS (Azure Kubernetes Service), ce qui nécessite quatre nœuds de VM de l'une des tailles de VM répertoriées suivantes pour la capacité. Ensuite, un (1) nœud supplémentaire est requis et utilisé pendant le processus de mise à niveau. Cela nécessite un total de 5 SKU de VM.
Images	Chaque image est dupliquée et migrée vers Horizon Cloud. Vous devez donc disposer de deux fois plus de vCPU par image dans la famille. Par exemple, pour migrer une image avec Standard_DS2_v2 et 2 cœurs de vCPU, vous avez besoin de deux cœurs de vCPU supplémentaires lors de la migration. Par conséquent, l'abonnement Azure doit disposer d'au moins 4 cœurs de vCPU de la famille DSv2 standard sur la région correspondante. Toutefois, puisque les images sont migrées par lots de 20, ce quota excédentaire ne doit pas dépasser 20 fois le nombre de cœurs de vCPU par image. En d'autres termes, vous devez disposer de votre quota existant, plus un quota excédentaire égal à 20 fois le vCPU de l'image, et pas seulement un quota égal à 20 fois le vCPU de l'image.

Vérifier que les stratégies Azure autorisent le provisionnement de comptes de stockage et de partages de fichiers

Avant de planifier la migration, vérifiez auprès du propriétaire de l'abonnement Azure de l'espace que les stratégies Microsoft Azure au niveau de l'abonnement ou sur le groupe de ressources de l'espace ne bloquent, ne refusent pas ou ne limitent pas le provisionnement des comptes de stockage et des partages de fichiers dans le groupe de ressources de l'espace de première génération.

Si vous migrez un espace vers un dispositif Horizon Edge existant, assurez-vous que les stratégies Microsoft Azure sur l'abonnement et le groupe de ressources d'Horizon Edge existants ne bloquent pas, ne refusent pas ou ne restreignent pas le provisionnement des comptes de stockage et des partages de fichiers.

Un déploiement réussi d'Horizon Edge Gateway nécessite le provisionnement du compte de stockage App Volumes et des partages de fichiers.

Lorsque l'espace de première génération dispose d'applications App Volumes, assurez-vous que les stratégies Azure autorisent le basculement de l'accès réseau sur les comptes de stockage

Si l'espace de première génération dispose d'applications App Volumes, vérifiez auprès du propriétaire de l'abonnement Azure de l'espace que les stratégies Microsoft Azure au niveau de l'abonnement ou sur le groupe de ressources de l'espace ne bloquent pas, ne refusent pas ou ne limitent pas la possibilité de basculer sur l'accès réseau public.

La migration d'applications App Volumes du système implique la copie de ces ressources du compte de stockage Azure de l'espace vers le compte de stockage d'Horizon Edge Gateway.

Pour faciliter cette copie, le processus de migration doit accéder aux deux comptes de stockage. Pendant la migration, le système active temporairement l'accès réseau public sur les comptes de stockage, puis le désactive une fois la copie terminée.

Si une stratégie Azure empêche le processus de migration d'activer l'accès au réseau public sur les comptes de stockage avant de commencer à copier les applications App Volumes, la migration échoue. Le système doit pouvoir activer et désactiver l'accès réseau pendant la phase de génération de la migration et pendant la fenêtre de maintenance.

Lorsque vous disposez d'une adresse IP publique pour l'équilibreur de charge d'Unified Access Gateway

Lorsque votre espace de première génération utilise une adresse IP publique pour l'équilibreur de charge de sa configuration de l'instance d'Unified Access Gateway externe, le système met en place le dispositif Horizon Cloud Horizon Edge pour utiliser une adresse IP publique pour la configuration de l'instance d'Unified Access Gateway d'Horizon Edge.

Dans ce cas, l'abonnement de l'espace nécessite une adresse IP publique supplémentaire. Avant de planifier la migration, assurez-vous donc que l'abonnement dispose de la capacité nécessaire pour fournir cette adresse IP publique supplémentaire.

Lorsque vous disposez d'une adresse IP privée pour l'équilibreur de charge d'Unified Access Gateway

Lorsque l'équilibreur de charge de votre déploiement d'Unified Access Gateway externe de première génération utilise une adresse IP privée, obtenez l'adresse IP publique que vous souhaitez acheminer vers l'équilibreur de charge du déploiement d'Horizon Cloud.

Si votre configuration de passerelle externe de première génération à migrer utilise une adresse IP privée pour son équilibreur de charge, avec une adresse IP publique acheminée vers cette adresse IP privée, le système détecte cette configuration lorsque vous commencez à planifier la migration.

Ce scénario était utilisé dans les déploiements de première génération avec un pare-feu ou une NAT configuré(e) devant l'équilibreur de charge Azure de la configuration de la passerelle externe dans le but de contrôler le trafic Internet avant d'autoriser l'accès aux dispositifs Unified Access Gateway de la configuration de la passerelle externe.

Le système détecte la configuration de première génération lors du processus d'analyse, lorsqu'il détermine l'état Ready to migrate.

Lorsque le système détecte cette configuration, l'interface utilisateur de l'assistant Planifier la migration affiche un champ Adresse IP publique manuelle. Dans ce champ, entrez l'adresse IP publique que vous souhaitez utiliser pour le déploiement de l'instance d'Unified Access Gateway d'Horizon Cloud.

Remarque : cette adresse IP publique doit être différente de celle qui est déjà utilisée pour la passerelle de l'espace à migrer, afin de prendre en charge la restauration, si elle nécessaire, vers l'état du déploiement de première génération.

Par conséquent, si vous disposez de cette configuration, obtenez une nouvelle adresse IP publique à utiliser, une adresse différente de celle actuellement utilisée pour la passerelle externe de l'espace de première génération.

Évaluer la capacité à vous connecter au nouvel environnement Horizon Cloud et à afficher la console Horizon Cloud Horizon Universal Console.

Essayez de vous connecter à connect.omnissa.com et, après vous être connecté, vérifiez si une carte intitulée Workspace ONE Cloud s'affiche dans l'UI de Services. La capture d'écran suivante en est un exemple.

Vérifiez d'abord si une carte intitulée Workspace ONE Cloud s'affiche dans l'UI de Services. La capture d'écran suivante en est un exemple.
Si cette carte s'affiche, cliquez sur son lien Lancer le service, puis vérifiez si une carte intitulée Horizon Cloud apparaît. Cette capture d'écran illustre cette carte dans les services. Votre ensemble spécifique de cartes peut différer.

Cliquez sur cette carte Horizon Cloud pour ouvrir le dispositif Horizon Cloud Horizon Universal Console.
- Si vous avez précédemment effectué l'intégration à votre environnement Horizon Cloud, la console Horizon Cloud Horizon Universal Console s'affiche avec l'écran Migration disponible.
- Si vous n'avez pas encore terminé l'intégration à votre environnement Horizon Cloud, le système présente l'UI de sélection de la région, comme décrit dans la section Sélection d'une région de cloud. Vous pouvez alors effectuer les étapes décrites ici pour terminer l'intégration et afficher la console avec l'écran Migration disponible.

Si l'exécution des étapes ci-dessus n'entraîne pas l'affichage de la console Horizon Cloud Horizon Universal Console et que vous êtes déjà en relation avec l'équipe de migration Horizon, contactez la personne de cette équipe avec laquelle vous travaillez. Si vous n'êtes pas encore en relation avec l'équipe de migration Horizon, contactez le support international et demandez de l'aide pour la migration d'Horizon Cloud.

La capture d'écran suivante illustre l'apparence de la partie supérieure du volet latéral de navigation d'Horizon Cloud Console à la fin de l'étape 2 ci-dessus. La zone principale peut afficher ou non le contenu de bienvenue qui s'affiche dans cette capture d'écran. La zone principale peut afficher automatiquement l'écran Migration. L'affichage de ce type de navigation signifie que vous êtes dans Horizon Cloud Console.

Capture d'écran de la partie supérieure du volet de navigation d'Horizon Cloud Console.

Choisir votre fournisseur d'identité et synchroniser les utilisateurs et les groupes AD avec celui-ci

Dans l'environnement Horizon Cloud, le service repose sur l'utilisation d'un fournisseur d'identité externe et d'un domaine Active Directory.

Arrière-plan

Dans votre locataire de première génération, vos domaines Active Directory enregistrés ont été utilisés pour l'identité de la machine et l'identité de l'utilisateur, afin d'authentifier l'accès de l'utilisateur final aux postes de travail et aux applications publiées.

Dans l'environnement Horizon Cloud, vous apportez au service un fournisseur d'identité externe pour exécuter la partie identité de l'utilisateur.

L'utilisation d'un fournisseur d'identité externe permet l'intégration à des solutions tierces pour fournir des fonctionnalités telles que l'authentification multifacteur.

Lors de la migration d'un espace de première génération vers un dispositif Horizon Cloud Horizon Edge, ce dispositif Horizon Edge postérieur à la migration utilise votre domaine Active Directory pour l'identité de la machine, comme dans l'environnement de première génération. Les postes de travail virtuels migrés et les machines virtuelles qui fournissent des applications publiées (distantes) sont joints au domaine Active Directory.

Remarque : le fournisseur d'identité que vous choisissez pour votre environnement Horizon Cloud doit être connecté aux domaines Active Directory des espaces de première génération, ceux qui sont enregistrés dans votre locataire de première génération.

Choisir le fournisseur d'identité que vous allez utiliser

Le fournisseur d'identité que vous décidez d'enregistrer dans Horizon Cloud Service doit répondre aux conditions requises d'Horizon Cloud.

Au moment de la rédaction de ce document :

Vous ne pouvez utiliser qu'un seul fournisseur d'identité avec l'environnement Horizon Cloud.
Types pris en charge :
- Microsoft Entra ID Commercial (pour les environnements Azure Commercial) et Microsoft Entra ID Government (pour les environnements Azure US Government). Lorsque votre espace de première génération est déployé dans des environnements Azure US Government, vous allez utiliser Microsoft Entra ID Government.
- Omnissa Access (Cloud ou sur site)

Pour plus d'informations, reportez-vous à la section Connexion de votre fournisseur d'identité dans la documentation d'Horizon Cloud.

Conditions préalables : Microsoft Entra ID Commercial ou Microsoft Entra ID Government

Exécutez un assistant dans l'instance Horizon Cloud Horizon Universal Console pour configurer les paramètres d'Horizon Cloud afin d'utiliser Microsoft Entra ID.

Vous aurez besoin des éléments suivants pour terminer l'exécution de cet assistant.

Élément requis	Détails
Utilisateur disposant de privilèges d'administrateur global	Cet utilisateur de Microsoft Entra ID est nécessaire dans les cas suivants : Approuver les autorisations demandées Donner son consentement à l'ensemble de l'organisation Dans le cadre de l'UI de l'assistant, vous générez un lien à fournir à cet utilisateur pour qu'il se connecte à Microsoft Entra ID, approuve les autorisations et autorise Horizon Cloud Service à accéder aux informations utilisateur dans Microsoft Entra ID. Si vous êtes administrateur global dans Microsoft Entra ID, l'assistant vous invite à vous connecter à Microsoft Entra ID, approuver les autorisations et donner votre consentement. Suivez les directives qui s'affichent à l'écran.
Sous-domaine de locataire	L'assistant vous demande d'entrer une chaîne dans un champ intitulé Sous-domaine de locataire. Elle doit commencer et se terminer par une lettre [a-Z] ou un chiffre [0-9] et contenir uniquement des lettres, des chiffres et des tirets [-]. Vous avez créé cette chaîne que vous et votre équipe prévoyez d'utiliser. La plupart des utilisateurs entrent une chaîne liée au nom de leur société ou de leur organisation, ou au domaine de la société. Notez toutefois que lorsque vos utilisateurs finaux se connecteront ultérieurement à leurs postes de travail et applications à l'aide de l'environnement Horizon Cloud migré, ils entreront cette chaîne dans le champ Utiliser le domaine de la société. Ce champ est présenté dans le cadre du flux de connexion de l'utilisateur final.

Élément requis

Détails

Utilisateur disposant de privilèges d'administrateur global

Cet utilisateur de Microsoft Entra ID est nécessaire dans les cas suivants :

Approuver les autorisations demandées
Donner son consentement à l'ensemble de l'organisation

Dans le cadre de l'UI de l'assistant, vous générez un lien à fournir à cet utilisateur pour qu'il se connecte à Microsoft Entra ID, approuve les autorisations et autorise Horizon Cloud Service à accéder aux informations utilisateur dans Microsoft Entra ID. Si vous êtes administrateur global dans Microsoft Entra ID, l'assistant vous invite à vous connecter à Microsoft Entra ID, approuver les autorisations et donner votre consentement. Suivez les directives qui s'affichent à l'écran.

Sous-domaine de locataire

L'assistant vous demande d'entrer une chaîne dans un champ intitulé Sous-domaine de locataire. Elle doit commencer et se terminer par une lettre [a-Z] ou un chiffre [0-9] et contenir uniquement des lettres, des chiffres et des tirets [-]. Vous avez créé cette chaîne que vous et votre équipe prévoyez d'utiliser. La plupart des utilisateurs entrent une chaîne liée au nom de leur société ou de leur organisation, ou au domaine de la société.

Notez toutefois que lorsque vos utilisateurs finaux se connecteront ultérieurement à leurs postes de travail et applications à l'aide de l'environnement Horizon Cloud migré, ils entreront cette chaîne dans le champ Utiliser le domaine de la société. Ce champ est présenté dans le cadre du flux de connexion de l'utilisateur final.

Conditions préalables : Omnissa Access cloud ou sur site

Exécutez un assistant dans l'instance d'Horizon Cloud Horizon Universal Console pour configurer les paramètres d'Horizon Cloud afin d'utiliser Access.

Vous aurez besoin des éléments suivants pour terminer l'exécution de cet assistant.

Élément requis	Détails
Utilisateur disposant de privilèges d'administrateur	Cet utilisateur d'Omnissa Access est nécessaire dans les cas suivants : Approuver les autorisations demandées Donner son consentement à l'ensemble de l'organisation
Sous-domaine de locataire	L'assistant vous demande d'entrer une chaîne dans un champ intitulé Sous-domaine de locataire. Elle doit commencer et se terminer par une lettre [a-Z] ou un chiffre [0-9] et contenir uniquement des lettres, des chiffres et des tirets [-]. Vous avez créé cette chaîne que vous et votre équipe prévoyez d'utiliser. La plupart des utilisateurs entrent une chaîne liée au nom de leur société ou de leur organisation, ou au domaine de la société. Notez toutefois que lorsque vos utilisateurs finaux se connecteront ultérieurement à leurs postes de travail et applications à l'aide de l'environnement Horizon Cloud migré, ils entreront cette chaîne dans le champ Utiliser le domaine de la société. Ce champ est présenté dans le cadre du flux de connexion de l'utilisateur final.
Nom de domaine complet de locataire Access	Dans l'assistant, entrez votre nom de domaine complet de locataire Access. Ce nom de domaine complet est généralement au format `yourcompany.workspaceoneaccess.com`. Vous pouvez obtenir ce nom de domaine complet à partir de votre console Access.
ID de client du locataire et le secret du client (si vous utilisez Access sur site)	Lorsque vous utilisez Access sur site, l'assistant demande l'ID de client OAuth et le secret du client OAuth que vous avez configurés afin d'intégrer votre environnement Horizon Cloud.

Synchroniser les utilisateurs et les groupes Active Directory (AD) avec ce fournisseur d'identité

Avant de sélectionner les espaces à migrer, vérifiez que tous les utilisateurs AD et groupes AD autorisés à accéder aux postes de travail et aux applications des espaces à migrer sont synchronisés avec votre fournisseur d'identité choisi.

Pendant les vérifications de validation préalable du système, celui-ci obtient l'ensemble des utilisateurs et groupes AD à partir des attributions de poste de travail et d'application de l'espace de première génération et vérifie le fournisseur d'identité enregistré dans l'environnement Horizon Cloud pour ces utilisateurs et groupes AD. Si le système ne trouve pas l'un de ces utilisateurs ou groupes AD dans le fournisseur d'identité enregistré, l'étape de validation préalable échoue. Le rapport d'échec que vous obtenez à partir de l'interface utilisateur signale l'utilisateur ou le groupe AD manquant.

Évaluer votre utilisation des utilisateurs intégrés ou des groupes intégrés Active Directory et les mettre à jour si nécessaire

Si votre déploiement d'Horizon Cloud on Microsoft Azure de première génération est configuré pour utiliser Azure Active Directory (Azure AD), vous devrez effectuer une mise à jour chaque fois que vous avez des utilisateurs ou des groupes intégrés spécifiés avant la migration et passer à des groupes et des utilisateurs non intégrés.

Le système analyse les espaces de première génération pour déterminer s'ils répondent aux critères de migration, puis collecte les informations sur les utilisateurs et les groupes spécifiés dans chaque attribution, puis tente de créer la configuration équivalente dans le fournisseur d'identité configuré de l'environnement Horizon Cloud. Si Microsoft Azure AD est votre fournisseur d'identité dans votre environnement Horizon Cloud, Microsoft Azure AD Connect synchronise votre domaine Active Directory avec Microsoft Azure AD.

Toutefois, comme indiqué dans la documentation de Microsoft, Microsoft Azure AD Connect qui gère la synchronisation d'un groupe Active Directory avec Azure AD exclut les groupes de sécurité intégrés de sa synchronisation d'annuaire. Par conséquent, lorsque le système tente de créer dans ce fournisseur d'identité la configuration de première génération équivalente dans laquelle vous avez utilisé des groupes intégrés et des utilisateurs intégrés, le système ne trouve aucune entité équivalente dans Azure AD, car ces éléments intégrés ne sont jamais synchronisés. Le système signale que les espaces dans lesquels les utilisateurs intégrés et les groupes intégrés sont impliqués ne peuvent pas être migrés.

Dans ce scénario, créez des groupes Active Directory standard ayant les mêmes appartenances que les groupes intégrés et les utilisateurs intégrés, et lorsque vous avez spécifié ces derniers pour recevoir des postes de travail ou des applications distantes, mettez à jour ces paramètres pour utiliser les groupes Active Directory standard.

Évaluer votre utilisation des attributions d'applications App Volumes

Si votre locataire de première génération dispose d'attributions d'application App Volumes, vérifiez que votre environnement Horizon Cloud dispose d'un abonnement de licence valide à App Volumes.

Lors des vérifications de la validation préalable du système, ce dernier vérifie dans votre environnement Horizon Cloud la présence d'un abonnement de licence valide à App Volumes.

S'il est introuvable, le système empêche la planification de la migration de l'espace avec une erreur.

Dans Horizon Cloud Console, vous pouvez vérifier la présence de licences dans votre environnement Horizon Cloud en suivant les étapes décrites dans la section Utiliser Horizon Universal Console pour suivre vos licences Horizon.

Cas spécial : si l'enregistrement de l'application de votre espace de première génération utilise un rôle personnalisé

Si votre espace de première génération est configuré pour utiliser un rôle personnalisé pour l'enregistrement de l'application Horizon Cloud de son abonnement, une condition préalable à la migration consiste à mettre à jour ce rôle personnalisé avec les autorisations requises dans un environnement Horizon Cloud.

L'utilisation d'un rôle personnalisé est atypique. La plupart des déploiements d'espaces de première génération utilisent le rôle Contributor pour l'enregistrement de l'application du principal d'Horizon Cloud Service.

Au moment du déploiement de votre espace de première génération, il était possible d'utiliser un rôle personnalisé, comme décrit sur la page de documentation de première génération Dans le cas où votre organisation préfère utiliser un rôle personnalisé.

Si votre espace s'inscrit dans ce scénario, ce rôle personnalisé existant doit être mis à jour pour inclure les autorisations requises par l'environnement Horizon Cloud afin d'effectuer ses appels d'API requis.

Dans l'abonnement de l'espace de première génération, vérifiez que les opérations suivantes sont autorisées dans le rôle personnalisé de l'enregistrement d'application Horizon Cloud, l'enregistrement d'application utilisé par l'espace.

Certaines d'entre elles sont identiques à celles requises pour le déploiement d'un espace de première génération. Le tableau indique celles qui sont également requises pour l'environnement Horizon Cloud.

Important : ne supprimez pas les opérations déjà autorisées dans le rôle personnalisé.

Autorisations obligatoires d'Horizon Cloud

Opérations sur les ressources Microsoft Azure qui doivent être autorisées dans le rôle personnalisé lors de l'attribution d'autorisations au niveau de l'abonnement
	Opérations
Ajouts supplémentaires à autoriser pour Horizon Cloud	`Microsoft.ContainerService/managedClusters/delete Microsoft.ContainerService/managedClusters/read Microsoft.ContainerService/managedClusters/write Microsoft.ContainerService/managedClusters/commandResults/read Microsoft.ContainerService/managedClusters/runcommand/action Microsoft.ContainerService/managedClusters/upgradeProfiles/read` `Microsoft.ManagedIdentity/userAssignedIdentities//assign/action Microsoft.ManagedIdentity/userAssignedIdentities//read` `Microsoft.ResourceGraph/*` `Microsoft.Resources/subscriptions/read` `Microsoft.Network/privateEndpoints/read Microsoft.Network/privateEndpoints/write Microsoft.Network/privateEndpoints/delete Microsoft.Network/locations/availablePrivateEndpointTypes/read`
Requis par Horizon Cloud qui doit déjà être autorisé dans le rôle personnalisé de votre espace de première génération	Si l'un de ces éléments n'est pas déjà autorisé dans le rôle personnalisé, incluez ceux qui manquent lorsque vous mettez à jour le rôle pour les opérations précédentes. `Microsoft.Authorization//read` `Microsoft.Compute//read` `Microsoft.Compute/availabilitySets/` `Microsoft.Compute/disks/` `Microsoft.Compute/galleries/read` `Microsoft.Compute/galleries/write` `Microsoft.Compute/galleries/delete` `Microsoft.Compute/galleries/images/` `Microsoft.Compute/galleries/images/versions/` `Microsoft.Compute/images/` `Microsoft.Compute/locations/` `Microsoft.Compute/snapshots/` `Microsoft.Compute/virtualMachines/` `Microsoft.Compute/virtualMachineScaleSets/` `Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/read` `Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/write` `Microsoft.Network/loadBalancers/` `Microsoft.Network/networkInterfaces/` `Microsoft.Network/networkSecurityGroups/` `Microsoft.Network/virtualNetworks/read` `Microsoft.Network/virtualNetworks/write` `Microsoft.Network/virtualNetworks/checkIpAddressAvailability/read` `Microsoft.Network/virtualNetworks/subnets/` `Microsoft.Network/virtualNetworks/virtualNetworkPeerings/read` `Microsoft.Resources/deployments/` `Microsoft.Resources/subscriptions/resourceGroups/` `Microsoft.ResourceHealth/availabilityStatuses/read` `Microsoft.Storage//read` `Microsoft.Storage/storageAccounts/*`

Autorisations facultatives

Bien que les autorisations suivantes ne soient pas obligatoires pour le déploiement du dispositif Horizon Cloud Horizon Edge dans Microsoft Azure, les fonctionnalités du service qui dépendent de ces autorisations facultatives ne fonctionneront pas si vous ne les incluez pas.

Opérations sur les ressources Microsoft Azure qui doivent être autorisées pour le rôle personnalisé lors de l'attribution d'autorisations au niveau de l'abonnement afin de prendre en charge les fonctionnalités d'Horizon Cloud
	Opérations	Objectif
Ajouts supplémentaires à autoriser pour Horizon Cloud	Microsoft.Network/natGateways/join/action Microsoft.Network/natGateways/read Microsoft.Network/privateEndpoints/write Microsoft.Network/privateEndpoints/read Microsoft.Network/routeTables/join/action Microsoft.Network/routeTables/read	Les opérations `Microsoft.Network/natGateways/join/action` et `Microsoft.Network/natGateways/read` sont requises lorsque vous utilisez le type de déploiement AKS pour la migration et que vous avez choisi d'utiliser une passerelle NAT sur le sous-réseau de gestion dans vos conditions préalables du type AKS. `Microsoft.Network/privateEndpoints/write` et `Microsoft.Network/privateEndpoints/read` sont requises lorsque vous utilisez le type de déploiement AKS pour votre migration et que l'espace est déployé dans un environnement Azure Commercial. Ces autorisations sont requises pour créer les ressources du point de terminaison privé et pour confirmer que la passerelle NAT du sous-réseau de gestion est correctement configurée. Ces autorisations de point de terminaison privé sont liées à l'utilisation par la migration d'Horizon Edge (AKS) avec Azure Private Link. Remarque : lorsque l'espace de première génération est déployé dans un environnement Azure US Government et que vous utilisez le type de déploiement AKS pour la migration, Horizon Edge (AKS) est configuré pour utiliser la connectivité Internet par défaut au lieu d'Azure Private Link. L'utilisation d'Azure Private Link dans les environnements Azure US Government n'est pas prise en charge. Les autorisations `Microsoft.Network/routeTables/join/action` et `Microsoft.Network/routeTables/read` sont requises lorsque vous utilisez le type de déploiement AKS et que vous avez choisi d'utiliser une table de routage sur le sous-réseau de gestion dans vos conditions préalables du type AKS. Le service requiert ces autorisations pour créer les ressources du point de terminaison privé et valider la table de routage associée au sous-réseau de gestion afin de s'assurer que la route par défaut est correctement configurée.
Requis par Horizon Cloud qui peut déjà être autorisé dans le rôle personnalisé de votre espace de première génération	Si l'un de ces éléments n'est pas déjà autorisé dans le rôle personnalisé, incluez ceux qui manquent lorsque vous mettez à jour le rôle pour les opérations précédentes. `Microsoft.KeyVault//read` `Microsoft.KeyVault/vaults/` `Microsoft.KeyVault/vaults/secrets/` `Microsoft.Network/publicIPAddresses/`	Des autorisations du coffre de clés sont requises pour le chiffrement du disque des VM de pool. Une autorisation d'adresses IP publiques est requise pour déployer une instance d'Horizon Edge avec des instances d'Unified Access Gateway derrière un équilibreur de charge avec une adresse IP publique. En outre, cette autorisation d'adresses IP publiques est requise pour déployer et ajouter une adresse IP publique à une image.

Remarque : ces informations sont ajoutées ici à des fins pratiques, en prévision de l'environnement Horizon Cloud postérieur à la migration. Lorsque vous mettez à jour les autorisations avant la migration de l'espace, vous pouvez envisager d'inclure cette autorisation en même temps.

Ce scénario se produit lorsque le fournisseur d'identité pour votre environnement Horizon Cloud est Microsoft Entra ID et que vous souhaitez l'utiliser pour l'identité de la machine.

Pour plus d'informations, reportez-vous à la section Remarque sur Microsoft Entra ID sur la page de documentation d'Horizon Cloud.

Cette page vous a-t-elle été utile ?