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

Brève introduction

Les activités de maintenance du système incluent une mise à jour automatisée des composants logiciels du groupe 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 de la semaine particuliers, 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 indiquant que VMware peut planifier une maintenance sur cet espace à tout moment à sa convenance.

Note : 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 fournies par VMware dans Azure Marketplace. Lorsque les vérifications préalables à la mise à niveau déterminent l'impossibilité d'utiliser par programmation ces offres VMware 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 de 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é s'appuie sur ces autorisations pour récupérer la liste des offres de Marketplace et obtenir les offres VMware. 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é d'utilisation des espaces et les opérations de support, VMware peut créer un nouveau 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 à la version 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 de l'espace seront conservées et continueront de réserver leurs adresses IP attribuées pendant la durée de vie de l'espace.

Cette conception prend en charge des mises à jour de l'espace plus rapides et plus robustes. 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. Cette conception peut entraîner des délais d'expiration dans Azure et interrompre le processus de mise à jour.

Dans cette conception où le système de déploiement instancie initialement l'ensemble de la mise en réseau nécessaire, 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 avait 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 ou utiliser des 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 des adresses IP à partir 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 échoue et nécessite l'intervention du support VMware.

Une fois l'espace mis à jour, 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 des composants logiciels VMware qui composent l'espace Horizon Cloud déployé est une opération nécessaire et requise pour assurer la santé et la stabilité des postes de travail et applications virtuels provisionnés par cet espace. Comme décrit dans la base de connaissances VMware Horizon Cloud Service - Informations de service supplémentaires (87894), VMware est responsable 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 VMware Horizon Cloud Service - Informations de service supplémentaires associé à cet article de la base de connaissances décrit les éléments suivants :

  • Les rôles et responsabilités de VMware concernant les procédures de gestion des changements 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 des changements, y compris la coopération avec VMware lorsqu'une maintenance planifiée ou d'urgence est nécessaire.

Le document VMware Horizon Cloud Service - Informations 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 VMware Horizon Cloud Service - Informations de service supplémentaires, le document VMware Horizon Cloud Service - Informations de service supplémentaires est prioritaire.

Attention : 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 possèdent toutes le dernier agent disponible pour l'espace. Si vous ne les mettez pas à jour avec le dernier agent avant la mise à jour de l'espace, elles risquent d'exécuter des versions d'agent incompatibles après la mise à jour de l'espace, ce qui mettrait 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 faire disparaître tous les points bleus de la console avant la mise à jour de l'espace. Reportez-vous à la section Mises à jour des espaces d'Horizon Cloud — Mesures à prendre 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 particuliers de la semaine, 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 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 module séparément dans la page de détails de chaque espace dans la console.

Note : Un espace sans fenêtre de maintenance préférée spécifiée dans la console sera considéré comme une indication que vous autorisez VMware à planifier une maintenance sur cet espace à tout moment à sa 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 du 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. Généralement, 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 comprennent 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.
    Exemple de capture d'écran de la bannière dans la console qui fournit des informations sur la maintenance planifiée d'un espace.
  • Dans l'onglet Journaux d'audit de l'espace et dans l'onglet Activité > Journaux d'audit de la console, un journal d'audit indique qu'une mise à niveau de l'espace est planifiée par VMware Operations. La ligne du journal d'audit comprendra 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 les paramètres Paramètres généraux > Comptes My VMware de la console. Il s'agit d'un e-mail indiquant la date et l'heure spécifiques de la maintenance planifiée qui est envoyé lorsque le système les a définies. Cela concerne par exemple de rappels périodiques dans les jours et les semaines précédant cette date et cette heure planifiées, ainsi que de rappels lorsque l'activité de maintenance a commencé et lorsqu'elle est terminée.
Note : Si vous souhaitez replanifier une date et une heure de maintenance planifiée, vous devez contacter le support VMware.

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

Si vous recevez un e-mail de notification indiquant qu'un espace présente des erreurs de mise à jour d'espace, ou si vous voyez la console signaler des erreurs de mise à jour d'espace pour un 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. Généralement, pour résoudre de telles erreurs, vous devez suivre des étapes dans le portail Microsoft Azure, dans l'abonnement de l'espace. Pour plus d'informations sur les solutions aux erreurs typiques de mise à jour des espaces, reportez-vous à la rubrique Horizon Cloud Espaces — Mesures pour les défaillances courantes de la vérification préalable.

Quel est le but de ces vérifications préalables ? L'activité de maintenance pour une mise à jour d'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 l'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 d'un nombre suffisant 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 intervention pour être corrigée, voici ce qui se produit :

  • Un e-mail de notification vous est envoyé pour vous en avertir ; il 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.
Important : Si vous recevez des notifications concernant des erreurs de mise à niveau d'espace, prenez les mesures spécifiées pour corriger les erreurs en temps voulu. Le temps est un facteur essentiel. Si vous n'agissez pas pour remédier à ces erreurs dans les délais requis par VMware, l'espace passera à un état non pris en charge en raison de l'échec de sa mise à jour.

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 VM du gestionnaire de l'espace et toutes les VM 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.

Ce 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 à niveau sont considérés comme des composants bleus.


Illustration conceptuelle du processus de mise à jour bleu-vert.

Bien que, dans la plupart des cas, la mise à jour d'un 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, comme les cartes réseau pour les instances d'Unified Access Gateway. Par exemple, dans le processus de mise à jour d'espace, lorsque les instances plus récentes sont créées parallèlement aux instances existantes, les plus récentes sont activées et restent en cours d'exécution jusqu'à ce que l'espace ait terminé la migration vers les nouvelles instances. De plus, une fois que le système a migré l'espace vers la construction verte et validé que l'espace fonctionne avec succès sur la nouvelle version du manifeste, les anciennes VM bleues sont supprimées du groupe de ressources. (En général, une mise à jour bleu-vert canonique conserverait 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 (comme les VM du gestionnaire d'espaces et les VM Unified Access Gateway) sont considérés comme les composants bleus.
  • Le service construit automatiquement l'ensemble vert de composants nécessaires pour l'espace dans votre abonnement Microsoft Azure ; de nouvelles VM vertes du gestionnaire d'espace, des VM Unified Access Gateway et la VM de connecteur de passerelle (si votre passerelle externe est déployée sur son propre VNet).
  • 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 aucun temps d'arrêt ni aucune perte de données, et les VM 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 VM vertes sont démarrées et maintenues actives jusqu'à ce que l'activité de maintenance planifiée soit terminée, l'activité de maintenance qui fait migrer 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 fonctionne avec succès sur les nouvelles instances, le système supprime les VM 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 afin de préserver les valeurs de configuration qui seront nécessaires lors de la prochaine mise à jour de l'espace.
Note : Vous devez éviter d'effectuer des changements 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 des espaces 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. Important : Avant l'opération de maintenance planifiée :
    • Assurez-vous 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 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 d'Horizon Cloud — Mesures à prendre pour assurer la compatibilité et la 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. Les machines virtuelles ayant des noms contenant une partie telle que vmw-hcs-podID, où podID est la valeur de l'ID de l'espace, appartiennent à celui-ci. 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 un groupe de ressources entier ou sur des ressources individuelles. Si vous ou votre organisation avez appliqué des verrous de gestion sur des 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 termine pas correctement. Vous pouvez localiser la valeur d'ID de l'espace sur la page de détails de l'espace depuis la page Capacité.

    Si les besoins de votre entreprise l'exigent, vous pouvez demander une autre date pour la maintenance en contactant le Support VMware à tout moment avant l'heure prévue de la maintenance.

    Important : 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.
    Note : Pendant la durée d'exécution de 20 à 30 minutes 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.

    Cela s'effectue sans perte de données, 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 alors également fermées immédiatement, conformément à ce paramètre. Dans ces conditions, tout travail d'utilisateur en cours est perdu. Pour éviter que les utilisateurs finaux perdent des données 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 leur donnera suffisamment de temps pour enregistrer leurs données. 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 au poste de travail virtuel ou à l'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, comme 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 de gestionnaire d'espace et 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é et 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 avec la dernière version disponible. Si les agents installés dans ces VM ne sont pas mis à jour, l'espace se trouvera dans une configuration non 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 d'Horizon Cloud — Mesures à prendre pour assurer la compatibilité et la 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, vous devez mettre à jour les paramètres sur votre serveur d'authentification à deux facteurs après l'activité de maintenance 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 si 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 d'é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 la haute disponibilité qu'un espace prenant en charge HA est censé fournir. Pour ce cas d'utilisation, mappez un nom de domaine complet à l'adresse IP dans le champ Adresse IP de l'équilibreur de charge de gestion de l'espace qui s'affiche sur la page des détails de l'espace, en suivant la procédure décrite dans la section Configurez les certificats SSL directement sur les VM du gestionnaire d'espace, par exemple lors de l'intégration du dispositif Workspace ONE Access Connector au dispositif Horizon Cloud dans Microsoft Azure, afin que le connecteur puisse approuver les connexions aux VM du gestionnaire d'espace. Avant la version de manifeste de l'espace 1600, 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ée pour les machines virtuelles du gestionnaire de l'espace. Pour les espaces existants mis à niveau vers la version de manifeste de cette version, si vous avez configuré un nom DNS pour pointer vers l'adresse IP du dispositif de locataire pour un espace au niveau de version de manifeste 1493.1 ou version antérieure, vous devez remapper les paramètres DNS pour qu'ils pointent vers 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 la variation 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 ce dernier est mis à niveau vers la version 2474.x ou une version ultérieure. Par conséquent, la détection du serveur Active Directory risque d'échouer tant que vous n'aurez 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.