Espaces Horizon Cloud - Maintenance et mises à jour

Cette page de documentation décrit les principales informations à connaître sur la maintenance des composants logiciels qui composent l'espace Horizon Cloud déployé.

Introduction

Les activités de maintenance du système incluent une mise à jour automatisée des composants logiciels de l'espace afin d'inclure de nouvelles fonctionnalités, des correctifs et des améliorations pour la prise en charge et la résilience du service.

Pour effectuer une mise à jour des dispositifs d'espace et de passerelle quasiment sans interruption de service, le système utilise le nombre de sessions d'utilisateurs finaux. Le système utilise le nombre de sessions pour déterminer le délai optimal de mise à jour lorsqu'un faible nombre d'utilisateurs est connecté à l'environnement avec des sessions actives.

l'activité de maintenance qui met à jour un espace existant vers un manifeste plus récent est initiée par le système depuis le plan de cloud pour se produire à un jour et à une heure déterminés par le système.

Pour indiquer que vous préférez que cette activité de maintenance du système commence à une heure et un jour particuliers de la semaine, vous pouvez utiliser la console pour spécifier la fenêtre de maintenance préférée de chaque espace.

Un espace sans fenêtre de maintenance préférée spécifiée dans la console sera considéré comme signifiant que l'équipe Horizon Cloud peut planifier une maintenance sur cet espace à tout moment et à notre convenance.

Remarque : Comme décrit sur cette page de documentation, à partir du début de l'année civile 2022, le service a amélioré le code de mise à niveau afin d'utiliser par programmation les offres que nous fournissons dans Azure Marketplace. Lorsque les vérifications préalables à la mise à niveau déterminent que l'utilisation par programmation de nos offres est empêchée dans l'abonnement, vous devez effectuer les actions décrites sur cette page de documentation pour résoudre les erreurs de blocage des mises à jour.

Par exemple, si le principal du service Horizon Cloud associé aux abonnements utilisés pour l'espace et ses configurations de passerelle utilise un rôle personnalisé (atypique), assurez-vous que le rôle personnalisé inclut ces deux autorisations. Le code d'API de mise à niveau améliorée s'appuie sur ces autorisations pour récupérer la liste des offres de Marketplace et obtenir nos offres. Si le rôle personnalisé n'inclut pas déjà ces deux autorisations, ajoutez-les au rôle personnalisé avant le démarrage du processus de mise à niveau de l'espace et de la passerelle.

Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/read
Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/write

Lorsque les composants logiciels utilisés dans un espace déployé sont mis à jour vers une nouvelle version, le numéro de manifeste de l'espace passe à un numéro de version supérieur, tel que 2632.0. Si des améliorations sont jugées importantes pour la facilité de maintenance et les opérations de support de l'espace, nous pouvons créer un manifeste qui correspond à une version ponctuelle, telle que 2632.1. La console affiche le manifeste d'un espace sur la page Capacité.

Informations importantes sur la mise à jour d'un espace à partir de manifestes antérieurs à 3328

À partir de février 2022, les cartes réseau des VM du gestionnaire d'espace suivent le même modèle de conception d'infrastructure que les cartes réseau des VM Unified Access Gateway.

Dans les nouveaux déploiements de l'espace à partir de cette date et dans les mises à jour de l'espace à partir de manifestes antérieurs au manifeste 3328, le système de déploiement instancie l'ensemble de la mise en réseau nécessaire pour prendre en charge l'exécution de l'espace et pour les mises à jour suivantes dans le temps. Le groupe de ressources de l'espace disposera désormais de 8 cartes réseau :

• 4 cartes réseau qui réservent 4 adresses IP du sous-réseau de gestion de l'espace
• 4 cartes réseau qui réservent 4 adresses IP du sous-réseau de VM principal de l'espace (appelé traditionnellement sous-réseau de locataire).

Ces 8 cartes réseau d'espace seront conservées et continueront de réserver leurs adresses IP attribuées pendant toute la durée de vie de l'espace.

Cette conception prend en charge des mises à jour de l'espace plus rapides et plus résilientes. Avant cette conception, une mise à jour de l'espace nécessitait la création de cartes réseau dans le cadre de la construction de l'espace vert et l'obtention d'adresses IP pour ces cartes réseau à partir des sous-réseaux de l'espace au moment de la mise à jour. Avec cette conception, des délais d'expiration dans Azure peuvent se produire et interrompre le processus de mise à jour.

Dans cette conception où le système de déploiement instancie toute la mise en réseau nécessaire à l'avance, les cartes réseau et leurs adresses IP des sous-réseaux de gestion et de VM (locataire) sont conservées pour être utilisées dans les mises à jour de l'espace suivantes. Cette conception s'aligne sur le modèle utilisé pour les instances d'Unified Access Gateway.

Lorsque votre espace ne dispose pas encore des 8 cartes réseau dans le groupe de ressources de l'espace et que celui-ci est planifié pour être mis à jour vers le manifeste 3328 ou une version ultérieure, vous devez prendre les mesures suivantes.

• Avant de mettre à jour cet espace, assurez-vous que les adresses IP du sous-réseau de gestion de l'espace et les adresses IP du sous-réseau de VM principal (locataire) sont uniquement utilisées par les éléments qu'Horizon Cloud on Microsoft Azure crée et configure

  • Sous-réseau de gestion : seules les cartes réseau spécifiques du déploiement d'Horizon Cloud on Microsoft Azure que le système de déploiement de l'espace a créées et configurées doivent utiliser des adresses IP à partir du sous-réseau de gestion de l'espace. Ces cartes réseau sont celles des gestionnaires d'espace et les cartes réseau de l'instance d'Unified Access Gateway de l'espace. Le sous-réseau de gestion de l'espace ne doit pas disposer de ressources non déployées dans l'espace ni d'éléments qui lui sont associés, ni utiliser d'adresses IP à partir du sous-réseau.
  • Sous-réseau de locataire : seules les cartes réseau et les équilibrages de charge spécifiques du déploiement d'Horizon Cloud on Microsoft Azure que le système de déploiement de l'espace crée et configure doivent utiliser les adresses IP du sous-réseau de locataire de l'espace. Le sous-réseau de locataire de l'espace ne doit disposer d'aucune ressource hors déploiement, ni d'éléments qui lui sont associés, ni utiliser d'adresses IP à partir du sous-réseau. Le Guide de déploiement indique précisément que les sous-réseaux utilisés par l'espace ne doivent disposer d'aucune ressource supplémentaire qui leur est associée, autres que les ressources du déploiement de l'espace. Si vous avez créé manuellement des ressources et attribué des adresses IP du sous-réseau de gestion ou de locataire de l'espace à ces ressources supplémentaires, vous devez supprimer ces adresses IP de ces ressources avant l'exécution de la mise à jour de l'espace. Sinon, la mise à jour de l'espace échouera et nécessitera le support d'Horizon Cloud.

• Après la mise à jour de l'espace, veillez à ajouter toutes les adresses IP réservées par les cartes réseau créées par le système de déploiement dans le groupe de ressources de l'espace aux règles de pare-feu que vous avez mises en place avant la mise à jour

  Vous pouvez disposer de règles de pare-feu existantes qui régissent le trafic à partir des adresses IP des cartes réseau des VM du gestionnaire d'espace. Pour que la communication du trafic fonctionne comme avant après la mise à jour de l'espace, vous devez vous assurer que toutes les 8 adresses IP réservées par les cartes réseau dans le groupe de ressources de l'espace sont reflétées dans vos règles de pare-feu après la mise à jour.

Ce qu'il faut savoir sur la maintenance des espaces

La maintenance de nos composants logiciels qui composent l'espace Horizon Cloud déployé est une opération nécessaire et requise pour maintenir la santé et la stabilité des postes de travail virtuels et des applications provisionnées par cet espace. Comme décrit dans la base de connaissances Horizon Cloud - Informations supplémentaires sur le service (87894), nous sommes responsables des composants logiciels qui résident dans l'espace et qui sont téléchargés vers cet espace à partir du plan de contrôle. Le PDF Horizon Cloud - Informations supplémentaires sur le service joint à cet article de la base de connaissances décrit les éléments suivants :

• Notre rôle et nos responsabilités (ceux de) concernant les procédures de gestion des modifications pour maintenir la santé des composants logiciels qui sont téléchargés dans l'espace. Les activités de maintenance incluent la mise à jour des composants logiciels de l'espace.
• Le rôle et les responsabilités du client (vous) concernant les procédures de gestion du changement, y compris la coopération avec nous lorsqu'une maintenance planifiée ou d'urgence est nécessaire.

Le document Horizon Cloud - Détails de service supplémentaires contient une définition de la maintenance planifiée, des fenêtres de maintenance et de la maintenance d'urgence. Consultez ce document pour plus de détails. En cas de divergence entre le contenu de cette page de documentation et le contenu du document Horizon Cloud - Informations de service supplémentaires , le document Horizon Cloud - Informations de service supplémentaires est prioritaire.

À l'attention de : Avant de mettre à jour l'espace, vous devez vous assurer que les VM d'image, les VM de batterie de serveurs et les VM de poste de travail VDI de l'espace disposent toutes du dernier agent disponible pour l'espace. Si vous ne les mettez pas à jour vers le dernier agent avant la mise à jour de l'espace, ils risquent d'exécuter des versions d'agent incompatibles après la mise à jour de l'espace, ce qui placera l'espace dans un état non pris en charge. Comment pouvez-vous savoir si vous devez mettre à jour l'un des agents ? Dans la console, vérifiez s'il y a des points bleus à côté d'une image ou d'une attribution. Si vous voyez des points bleus, l'objectif est de les faire tous disparaître de la console avant la mise à jour de l'espace. Reportez-vous à la section Mises à jour des espaces Horizon Cloud — Étapes pour assurer la compatibilité et la prise en charge continues des agents.

Spécification de la fenêtre de maintenance préférée de l'espace

Pour indiquer que vous préférez que toute activité de maintenance sur votre espace commence à une heure et un jour de la semaine particuliers, utilisez la console pour spécifier ce que l'on appelle la fenêtre de maintenance préférée pour cet espace. Sur la page Capacité, accédez à l'onglet Maintenance de la page de détails de l'espace. Recherchez l'étiquette Durée de maintenance préférée , puis suivez les commandes à l'écran pour choisir un jour de la semaine et une heure (UTC) dans cette journée. Vous pouvez uniquement choisir parmi les valeurs par défaut prédéfinies du système.

Spécifiez l'heure de maintenance préférée de chaque espace séparément sur la page de détails de chaque espace dans la console.

Remarque : Un espace sans fenêtre de maintenance préférée spécifiée dans la console sera considéré comme signifiant que vous nous autorisez à planifier une maintenance sur cet espace à tout moment et à notre convenance.

Le système lira le jour de la semaine et l'heure que vous spécifiez dans la console et intégrera ces données dans son algorithme de planification. Lorsqu'un nouveau manifeste d'espace est défini par défaut dans le plan de cloud, le planificateur du système calcule le jour et l'heure de mise à jour qu'il a déterminés pour chaque espace de votre flotte d'espaces. Bien que le système fasse de son mieux pour tenir compte des heures de début de maintenance préférées spécifiées dans l'onglet Maintenance de cet espace, il n'y a aucune garantie que le système pourra tenir compte de cette heure de début de maintenance préférée pour une opération de mise à jour spécifique.

Au moment de la rédaction du présent document, le planificateur du système alloue quatre (4) heures pour la durée de l'activité de maintenance. En général, la mise à jour d'un espace prend moins de temps que cette durée allouée.

Alertes et notifications de maintenance

Le système alertera et notifiera les administrateurs de votre environnement de locataire lorsqu'il aura planifié une date et une heure précises pour la maintenance spécifique d'un espace donné. Ces alertes et notifications incluent les éléments suivants :

• Dans la console

  • Une bannière persistante en haut de la console. l'heure indiquée dans la bannière correspond à l'heure de maintenance locale dans le fuseau horaire de votre navigateur, lorsque vous consultez la console. La capture d'écran suivante est un exemple où la mise à jour de l'espace est planifiée pour se produire à 16 heures, heure de l'Est aux États-Unis, le 7 juillet 2020. Utilisez le bouton Afficher pour accéder à la page de détails de l'espace et voir plus d'informations sur la maintenance planifiée dans l'onglet Maintenance de l'espace.

    

  • Dans l'onglet Journaux d'audit de l'espace et dans Activité > Journaux d'audit de la console, un journal d'audit indique qu'une mise à niveau de l'espace est planifiée par Opérations. La ligne du journal d'audit inclut l'UUID de l'espace.

  • Dans l'onglet Maintenance de l'espace, la section Maintenance planifiée affiche des informations sur la maintenance planifiée.

• E-mails

  Le système enverra des e-mails sur la maintenance de l'espace aux administrateurs de votre environnement de locataire, c'est-à-dire ceux spécifiés dans la zone Comptes de l'interface utilisateur Paramètres généraux de la console. Il s'agit d'un e-mail indiquant que le système a défini la date et l'heure spécifiques de la maintenance planifiée. Ces e-mails sont par exemple des rappels périodiques dans les jours et les semaines précédant cette date et cette heure planifiées, ainsi que lorsque l'activité de maintenance a commencé et lorsqu'elle est terminée.

Remarque : Si vous souhaitez replanifier une date et une heure de maintenance planifiée, vous devez contacter le support Horizon Cloud.

Vérifications préalables du système avant d'effectuer la maintenance de l'espace

Si vous recevez un e-mail de notification indiquant qu'un espace présente des erreurs de mise à jour de l'espace ou si vous voyez la console signaler des erreurs de mise à jour de l'espace pour l'espace, vous devez prendre des mesures pour rectifier la situation. Dans ce cas, suivez les indications à l'écran de la console ou les instructions contenues dans l'e-mail. La résolution habituelle de ces erreurs implique généralement que vous effectuiez des étapes dans le portail Microsoft Azure dans l'abonnement de l'espace à cet emplacement. Pour plus d'informations sur les solutions aux erreurs typiques de mise à jour des espaces, reportez-vous à la section Espaces Horizon Cloud — Remèdes aux échecs courants de vérification préalable.

Quel est l'objectif de ces vérifications préalables ? l'activité de maintenance pour une mise à jour de l'espace a lieu dans l'abonnement Microsoft Azure et les groupes de ressources de l'espace. Peu de temps avant que le système ne planifie une date et une heure particulières pour une mise à jour spécifique sur un espace donné, le système exécute une opération de vérification préalable pour déterminer s'il existe des conditions qui empêcheraient un espace de réussir sa mise à jour. Par exemple, l'une de ces vérifications préalables vérifie si votre abonnement Microsoft Azure dispose de suffisamment de vCores de la série de VM appropriée pour répondre aux exigences de la mise à jour. Si l'une des vérifications préalables échoue et que la condition nécessite votre action pour être corrigée, les problèmes suivants se produisent :

• Un e-mail de notification vous est envoyé pour vous en avertir et contient des détails sur les actions requises pour rectifier l'erreur.
• La console affiche une alerte visuelle indiquant que des actions sont requises de votre part pour rectifier les erreurs de vérification préalable pour cet espace.

À noter : Si vous recevez des notifications concernant des erreurs de mise à niveau de l'espace, prenez les mesures spécifiées pour remédier aux erreurs en temps utile. Le temps presse. Si vous n'agissez pas pour remédier à ces erreurs dans les délais requis, l'espace passera à un état non pris en charge en raison de l'échec de la correction du processus de mise à jour de l'espace.

Mises à jour des espaces — Présentation générale

Lorsque l'activité de maintenance est la mise à jour d'un espace vers une version plus récente du manifeste, le système déplace de manière appropriée les composants d'infrastructure actuels de l'espace vers un niveau supérieur du manifeste logiciel. Les composants de l'infrastructure sont principalement les machines virtuelles du gestionnaire de l'espace et toutes les machines virtuelles Unified Access Gateway configurées pour l'espace. Par exemple, une mise à jour de l'espace peut inclure des mises à jour du logiciel de gestion de l'espace et/ou du logiciel Unified Access Gateway.

Le processus de mise à jour de l'espace est basé sur une technique de l'industrie des logiciels connue sous le nom de déploiement bleu-vert. Les composants existants de l'espace à mettre à jour sont considérés comme des composants bleus.

Bien que, dans la plupart des cas, la mise à jour de l'espace suive le modèle bleu-vert de l'industrie, il existe quelques différences mineures par rapport à une mise à jour bleu-vert canonique. La mise à jour de l'espace ne reproduit pas à 100 % toutes les ressources bleues dans la construction verte. Certaines des ressources bleues existantes sont réutilisées dans la nouvelle construction verte, telles que les cartes réseau pour les instances d'Unified Access Gateway. Une autre différence est que dans le processus de mise à jour de l'espace, lorsque les instances plus récentes sont créées parallèlement aux instances existantes, les plus récentes sont mises sous tension et restent en cours d'exécution jusqu'à ce que l'espace ait terminé la migration vers les nouvelles instances. En outre, une fois que le système a migré l'espace vers la construction verte et validé que l'espace s'exécute avec succès sur la nouvelle version du manifeste, les anciennes VM bleues sont supprimées du groupe de ressources. (Une mise à jour bleu-vert canonique conserve généralement les anciens artefacts bleus après le passage au vert, en gardant les plus anciens dans un état inactif.)

• Les composants existants de l'espace à mettre à jour, tels que les machines virtuelles du gestionnaire d'espace et les machines virtuelles Unified Access Gateway, sont considérés comme les composants bleus.
• Le service crée automatiquement l'ensemble vert de composants nécessaires pour l'espace dans votre abonnement Microsoft Azure : de nouvelles machines virtuelles vertes du gestionnaire d'espace, des machines virtuelles Unified Access Gateway et la machine virtuelle du connecteur de passerelle (si votre passerelle externe est déployée sur son propre réseau virtuel).
• Les composants nouvellement créés dans la construction verte sont créés aux côtés des composants bleus, dans les mêmes groupes de ressources.
• Le processus de création de l'ensemble vert n'entraîne pas de temps d'arrêt ni de perte de données, et les machines virtuelles parallèles n'affectent pas les opérations de l'espace.
• l'ensemble vert est un environnement parallèle, en attente de l'activité de maintenance planifiée qui permettra de passer du bleu au vert. La façon dont le système planifie l'activité de maintenance sur un espace est expliquée dans les sections précédentes.
• Ces machines virtuelles vertes sont démarrées et maintenues en cours d'exécution jusqu'à ce que cette activité de maintenance planifiée soit terminée, l'activité de maintenance qui migre le bleu vers le vert.
• Une fois que l'activité de maintenance planifiée pour la migration vers la construction verte est terminée et que l'espace est correctement exécuté sur les nouvelles instances, le système supprime les machines virtuelles bleues des groupes de ressources de l'espace. Certaines ressources, telles que les cartes réseau pour les instances d'Unified Access Gateway, sont conservées pour conserver les valeurs de configuration qui seront nécessaires lors de la prochaine mise à jour de l'espace.

Remarque : Vous devez éviter d'effectuer des modifications dans le portail Microsoft Azure et dans l'abonnement de l'espace qui auront une incidence sur la construction des composants verts du système ou sur les processus de mise à jour et de maintenance de l'espace du système.

Séquence d'activité de maintenance

Cette séquence décrit la migration vers la construction verte : le passage du bleu au vert dans la mise à jour de l'espace.

1. Le système vérifie la fenêtre de maintenance préférée de l'espace que vous avez spécifiée dans la console, afin d'utiliser ces informations dans l'algorithme de son planificateur pour planifier la date et l'heure réelles de l'activité de maintenance de l'espace.
2. Le planificateur du système choisit la date et l'heure réelles de la maintenance. Comme décrit dans les sections précédentes, la console affiche visuellement la date et l'heure planifiées, et un e-mail est envoyé aux administrateurs du locataire.
3. À noter : Avant l'exécution de la maintenance planifiée :

• Assurez-vous que les machines virtuelles d'image, les machines virtuelles de batterie de serveurs et les machines virtuelles de poste de travail VDI de l'espace disposent toutes du dernier agent disponible pour l'espace. Si vous voyez des points bleus dans la console, l'objectif est de les faire tous disparaître avant la mise à jour de l'espace. Reportez-vous à la section Mises à jour des espaces Horizon Cloud — Étapes pour une compatibilité et une prise en charge continues des agents

• Supprimez tous les verrous de gestion dans Microsoft Azure que vous avez pu définir sur les machines virtuelles (VM) de l'espace. Toutes les machines virtuelles portant des noms qui contiennent une chaîne telle que hcs-, où podID est la valeur de l'ID de l'espace, appartiennent à celui-cipodID. Microsoft Azure permet d'utiliser le portail Microsoft Azure pour verrouiller des ressources afin d'empêcher leur modification. Ces verrous de gestion peuvent être appliqués sur l'intégralité d'un groupe de ressources ou sur des ressources individuelles. Si vous ou votre organisation avez appliqué des verrous de gestion sur les VM de l'espace, ces verrous doivent être supprimés avant l'exécution de la mise à jour. Sinon, le processus de mise à jour ne se terminera pas correctement. Vous pouvez localiser la valeur ID de l'espace sur la page de détails de l'espace à partir de la page Capacité. Si les besoins de votre organisation l'exigent, vous pouvez demander une autre date pour la maintenance en contactant le support Horizon Cloud à tout moment avant l'heure de maintenance planifiée.

  À noter : l'heure planifiée qui s'affiche dans la console est locale pour le fuseau horaire de votre navigateur.

4. Au moment de la maintenance planifiée, le service démarre l'activité de mise à jour. Le processus complet prend généralement entre 20 et 30 minutes du début à la fin pour les espaces disposant d'une configuration d'Unified Access Gateway externe et interne.

   Remarque : Pendant les 20 à 30 minutes nécessaires à l'exécution du processus, la console vous empêche d'effectuer des tâches administratives sur l'espace en cours de mise à jour. Par exemple, jusqu'à ce que les dispositifs du gestionnaire d'espace informent le plan de cloud que la mise à jour est terminée, il n'est pas possible de cliquer sur l'action Modifier sur la page de détails de l'espace pour modifier les caractéristiques de cet espace.

   • À propos des sessions d'utilisateurs finaux et de l'activité de mise à jour sur les dispositifs Unified Access Gateway

     Pour n'obtenir quasiment aucune interruption de service pour les sessions d'utilisateurs finaux, dans le délai d'activité de maintenance global, le système utilise le nombre de sessions d'utilisateurs finaux sur les dispositifs afin de déterminer le délai optimal de mise à jour de ces dispositifs.

     l'heure d'achèvement est optimisée pour se produire lorsque le nombre d'utilisateurs connectés à l'environnement avec des sessions actives est faible.

     Dans cette fenêtre de temps proche de zéro, les sessions actives des utilisateurs finaux seront déconnectées. Ensuite, en quelques minutes, ces utilisateurs peuvent se reconnecter.

     Aucune perte de données ne se produit, sauf dans le scénario où vous avez défini l'option Immédiatement pour le traitement du délai d'expiration dans les batteries de serveurs et les attributions de poste de travail VDI. Dans ce scénario, les utilisateurs disposant de sessions actives dans lesquelles vous avez utilisé l'option Immédiatement pour le traitement du délai d'expiration seront immédiatement déconnectés. Ces sessions sont également fermées immédiatement, conformément à ce paramètre. Dans ces conditions, tout travail d'utilisateur en cours est perdu. Pour éviter la perte de données d'utilisateur final en cours avant le démarrage de l'activité de maintenance, ajustez le paramètre Fermer les sessions déconnectées dans les batteries de serveurs et les attributions de poste de travail VDI sur une valeur temporelle qui donnera suffisamment de temps pour enregistrer le travail. Une fois la mise à jour terminée, vous pouvez rétablir l'état initial du paramètre.

     En outre, pendant cette fenêtre de temps proche de zéro, si un utilisateur final qui ne dispose pas déjà d'une session connectée à son poste de travail virtuel ou application distante à partir de l'espace et qui tente de se connecter ne pourra pas se connecter tant que le processus n'est pas terminé.

5. Une fois l'activité de maintenance terminée, le système supprime les composants qui ne sont plus nécessaires, tels que les composants bleus qui ne sont pas réutilisés dans la construction verte, tels que les VM du gestionnaire d'espace et les VM Unified Access Gateway. Certains artefacts, tels que certaines cartes réseau des instances du gestionnaire d'espace et des instances d'Unified Access Gateway, restent en place pour conserver les valeurs de configuration requises pour la prochaine maintenance.

Après l'activité de maintenance

Lorsque l'activité de maintenance se termine, vous pouvez effectuer des tâches administratives sur l'espace. Pour voir la version logicielle en cours d'exécution par un espace, sélectionnez Paramètres > Capacité , puis cliquez sur l'espace pour ouvrir sa page de résumé. La page affiche la version logicielle actuelle en cours d'exécution.

• Après la mise à jour d'un espace, assurez-vous que les agents de toutes les images, batteries de serveurs et attributions VDI existantes sont mis à jour vers la dernière version disponible. Si les agents installés de ces VM ne sont pas mis à jour, la configuration de l'espace n'est pas prise en charge. Le processus de maintenance ne met pas automatiquement à jour ces agents installés. Si vous voyez des points bleus dans la console pour vos images ou vos attributions, cela signifie que les agents doivent être mis à jour. Mises à jour des espaces Horizon Cloud : étapes pour une compatibilité et une prise en charge continues des agents.
• Si cette mise à jour provenait d'un manifeste antérieur au manifeste 3328, après la mise à jour de l'espace, veillez à ajouter à vos règles de pare-feu toutes les adresses IP des cartes réseau créées par le système de déploiement qui se trouvent dans le groupe de ressources de l'espace. Vous pouvez disposer de règles de pare-feu existantes qui régissent le trafic à partir des adresses IP des cartes réseau des VM du gestionnaire d'espace. Pour que la communication du trafic fonctionne comme avant après la mise à jour de cet espace et les mises à jour suivantes, vous devez vous assurer que toutes les 8 adresses IP réservées par les cartes réseau dans le groupe de ressources de l'espace sont reflétées dans vos règles de pare-feu après cette mise à jour.
• Si votre serveur d'authentification à deux facteurs configuré est déployé dans le même réseau virtuel, après l'activité de maintenance, vous devez mettre à jour les paramètres sur votre serveur d'authentification à deux facteurs pour accepter les nouvelles adresses IP privées pour les nouvelles VM Unified Access Gateway internes. Il s'agit d'une condition requise ponctuelle pour la première mise à jour de l'espace. Elle ne doit pas être répétée pour les futures mises à jour de cet espace. Reportez-vous à la section Mettre à jour votre système d'authentification à deux facteurs avec les informations de passerelle requises.
• À partir de la version de service trimestrielle de septembre 2019, l'architecture de l'espace est mise à jour pour prendre en charge la fonctionnalité de haute disponibilité (HA). Même lorsque la fonctionnalité de haute disponibilité n'est pas activée, la nouvelle architecture compatible HA inclut un équilibrage de charge Microsoft Azure devant la machine virtuelle du gestionnaire de l'espace. Après la mise à jour de votre espace vers la version de manifeste 1600, si votre espace a été configuré pour des connexions directes, vous devez remapper vos paramètres DNS pour qu'ils pointent vers l'adresse IP de l'équilibrage de charge Azure du gestionnaire d'espace, qui s'affichera dans la page des détails de l'espace mis à jour. Tant que vous n'avez pas mis à jour le mappage DNS, même si ces connexions utilisateur directes fonctionnent toujours, si la VM du gestionnaire d'espace actif tombe en panne, ces connexions ne disposent pas du basculement de haute disponibilité qu'un espace prenant en charge HA est censé fournir. Pour ce cas d'utilisation, vous mappez un nom de domaine complet à l'adresse IP dans le champ Adresse IP de l'équilibrage de charge de gestion de l'espace qui s'affiche sur la page de détails de l'espace, comme décrit dans la section Configurer les certificats SSL directement sur les machines virtuelles du gestionnaire d'espace, par exemple lors de l'intégration du dispositif Access Connector à l'espace Horizon Cloud dans Microsoft Azure, Pour que Connector puisse approuver les connexions aux VM du gestionnaire d'espace. Avant la version 1600 du manifeste de l'espace, cette adresse IP était attribuée à la carte réseau de la machine virtuelle du gestionnaire de l'espace sur le sous-réseau du locataire. À partir du manifeste de l'espace 1600 ou version ultérieure, l'adresse IP de l'espace à mapper est l'adresse IP privée de l'équilibrage de charge Microsoft Azure utilisé pour les machines virtuelles du gestionnaire de l'espace. Pour les espaces existants mis à jour vers la version de manifeste de cette version, si vous avez configuré un nom DNS pour pointer vers l'adresse IP du dispositif locataire pour un espace au niveau de version de manifeste 1493.1 ou version antérieure, vous devez remapper vos paramètres DNS pour qu'ils pointent vers l'adresse IP affichée pour le libellé Adresse IP de l'équilibrage de charge de gestion de l'espace sur la page des détails de l'espace mis à jour.
• Avant le manifeste 2474.x, le système ne vérifiait pas les variations d'horloge de vos serveurs Active Directory enregistrés. Avec la version 2474.x, une vérification de la variation d'horloge a été ajoutée. Si les serveurs Active Directory enregistrés rencontrent désormais des problèmes de synchronisation de l'heure (clockSkew > 4 minutes), cette validation système démarre sur cet espace lorsque celui-ci est mis à niveau vers la version 2474.x ou une version ultérieure. Par conséquent, la détection du serveur Active Directory peut commencer à échouer tant que vous n'avez pas résolu le problème de variation d'horloge. La détection défaillante aura alors une incidence sur les demandes de connexion de poste de travail de l'utilisateur final à cet espace.