Cette rubrique répertorie les problèmes connus que vous pouvez rencontrer lors de l'utilisation du service et les solutions connues, le cas échéant.

Important : Ces informations s'appliquent uniquement lorsque vous avez accès à un environnement de locataire de première génération dans le plan de contrôle de première génération. Comme décrit dans l' article 92424 de la base de connaissances, le plan de contrôle de première génération a atteint la fin de disponibilité (EOA). Pour plus d'informations, consultez cet article.

Cette rubrique de la documentation comprend les problèmes connus d'Horizon Cloud Connector. Cependant, même si vous utilisez Horizon Cloud Connector pour connecter des espaces Horizon à Horizon Cloud, pour connaître les problèmes connus du logiciel exécuté dans ces espaces Horizon, reportez-vous aux notes de mise à jour aux emplacements suivants, conformément à la version du logiciel du Serveur de connexion de l'espace :

Pour plus d'information sur les problèmes connus du service de gestion d'images (IMS) impliquant des fonctionnalités IMS disponibles en production pour tous les clients Horizon Cloud, reportez-vous à la page des problèmes connus dans Gestion d'images Horizon à partir du cloud.

Note : Les nombres entre parenthèses indiqués dans chaque problème connu se rapportent aux systèmes de suivi des problèmes internes de VMware.

Problèmes connus liés à la connexion

Bien que vous ayez créé un mot de passe pour votre compte My VMware qui contient une barre oblique inverse (\), la connexion à Horizon Cloud à l'aide de ces informations d'identification échoue (2595757)
Lorsque vous utilisez les informations d'identification de My VMware pour vous connecter à Horizon Cloud, les mots de passe qui contiennent une barre oblique inverse ne sont pas pris en charge. Pour consulter la liste des caractères spéciaux pris en charge, connectez-vous à my.vmware.com et accédez à la section Modifier le mot de passe de votre profil. Cette page affiche les caractères spéciaux pris en charge. Solution : réinitialisez votre mot de passe de compte My VMware pour en obtenir un nouveau et assurez-vous que celui-ci ne contient aucune barre oblique inverse (\).

Problèmes connus liés à Active Directory

Le verrouillage du compte de liaison principal n'est pas détecté jusqu'à ce que vous effectuiez une action impliquant Active Directory dans la console d'administration. (2010669)
En raison de ce problème, un administrateur connecté à la console d'administration Web voit uniquement la notification de verrouillage du compte de liaison principal lorsqu'une action impliquant Active Directory est effectuée dans l'interface utilisateur, telle qu'une recherche dans Active Directory pour ajouter des utilisateurs aux attributions. Les services sous-jacents détectent uniquement un compte de service verrouillé lorsqu'ils effectuent une demande de communication à Active Directory pour l'authentification ou la recherche (utilisateur ou groupe). Solution : aucune.
La console d'administration Web met jusqu'à 15 minutes pour refléter l'état Verrouillé ou Déverrouillé du compte de liaison principal de domaine. (2009434)
L'objet de connexion du système à Active Directory est mis en cache pendant 15 minutes. Par conséquent, 15 minutes peuvent s'écouler entre le moment où le compte de liaison principal passe à l'état Verrouillé et le moment où le système envoie une notification à l'administrateur. À l'inverse, une fois que l'administrateur efface la condition Verrouillé du compte, 15 minutes peuvent s'écouler avant que le système arrête d'envoyer des notifications relatives au compte dont la condition a été effacée. Solution : aucune.
Pour les batteries de serveurs d'un espace de Microsoft Azure, la réutilisation du même nom de batterie de serveurs avec un domaine différent dans la même forêt Active Directory peut entraîner des échecs de la jonction de domaine en raison de noms de fournisseur de services en double. (1969172)
En raison d'une nouvelle fonctionnalité pour les contrôleurs de domaine dans Microsoft Windows Server 2012 R2 et versions ultérieures, un contrôle de SPN en double sur le contrôleur de domaine provoque des échecs de la jonction de domaine. Reportez-vous à l'article  3070083 de la base de connaissances de Microsoft. Solutions :
  • évitez de réutiliser des noms de batterie de serveurs.
  • Comme décrit dans cet article de la base de connaissances de Microsoft, désactivez les contrôles de noms de fournisseur de services en double dans le domaine Active Directory.
Lors de l'utilisation des services Azure AD Domain Services, le workflow d'enregistrement d'Active Directory échoue à l'étape de jonction de domaine avec une erreur indiquant que l'autorisation Réinitialiser le mot de passe est manquante. (2218180)
L'équipe d'Horizon Cloud a vérifié que l'ajout des autorisations de compte de jonction de domaine requises fonctionne de la même manière lors de l'utilisation des services Azure Active Directory (AD) Domain Services avec votre espace comme pour d'autres déploiements de domaine Active Directory. Reportez-vous à la rubrique de la documentation Microsoft Créer une unité d'organisation (UO) sur un domaine géré par les services de domaine Azure AD qui décrit les ordinateurs AADDC de conteneur intégrés et reportez-vous également à la remarque importante au début de cette rubrique sur l'activation de la synchronisation du hachage de mot de passe pour les services Azure AD Domain Services. Avant de définir les autorisations sur le compte de service de jonction de domaine, il est important de suivre la documentation Microsoft sur l'activation de la synchronisation du hachage de mot de passe pour les services Azure AD Domain Services pour les comptes de service de jonction de domaine. Si l'erreur d'autorisations de jonction de domaine dans le workflow Enregistrer Active Directory persiste après avoir suivi la procédure de la documentation Microsoft, contactez le support VMware et indiquez le numéro de rapport de problème 2218180.

Problèmes connus liés à l'abonnement Microsoft Azure

Après avoir utilisé Horizon Universal Console pour mettre à jour la clé secrète des paramètres d'abonnement Azure d'un espace, vous devez redémarrer les VM du gestionnaire d'espace pour que les nouvelles informations d'identification prennent effet (2979394, 3007687, 3017415)
En raison de ce problème connu, après avoir modifié et enregistré le paramètre Clé d'application dans la fenêtre Gérer l'abonnement de la console, la clé secrète récemment entrée ne prend pas effet sur les VM du gestionnaire d'espace tant que le service de gestion n'a pas été redémarré dans les systèmes d'exploitation des VM. Si le service de gestion n'est pas redémarré, les appels d'API utilisés par le service pour fonctionner avec des ressources dans l'abonnement commenceront à échouer. Solution : si votre espace se trouve dans cette situation, dans laquelle la clé secrète de l'abonnement nécessite une mise à jour pour une raison quelconque, telle qu'une date d'expiration imminente ou écoulée, ouvrez une demande de service auprès du support VMware et des équipes chargées des opérations Horizon Cloud pour obtenir de l'aide afin de vous assurer que la séquence d'étapes a été effectuée. À un niveau élevé, les étapes sont les suivantes :
  1. Dans le portail Azure, générez une clé secrète.
  2. Dans Horizon Universal Console, suivez les étapes standard pour mettre à jour la clé secrète utilisée par un ou plusieurs espaces associés à l'ancienne clé, comme décrit sur la page Modifier et mettre à jour les informations d'abonnement associées aux espaces Horizon Cloud déployés.
  3. Demandez au support VMware d'effectuer le redémarrage du service de gestion sur les deux VM du gestionnaire d'espace.

La commande spécifique de redémarrage du service de gestion n'est pas adaptée à l'affichage public ici, car seules les équipes VMware pourront exécuter cette commande. Ces équipes peuvent faire référence au problème interne 3007687-update-9.

Problèmes connus liés à Cloud Connector

L'état du service de surveillance du Serveur de connexion (CSMS) indique Non prêt dans la zone Santé du portail de configuration d' Horizon Cloud Connector (3236634)
Comme décrit dans l' article 91124 de la base de connaissances VMware, pour Horizon Cloud Connector version 2.3, après un redémarrage du dispositif Horizon Cloud Connector ou du cluster Kubernetes du dispositif, l'état CSMS indique Non prêt.

Ce problème est résolu dans Horizon Cloud Connector à partir de la version 2.4. Pour contourner ce problème dans les versions antérieures, suivez les étapes décrites dans l'article de la base de connaissances.

Problème d'expiration de certificat (3083444)
Un certificat dans les versions d' Horizon Cloud Connector antérieures à la version 2.4 a été trouvé avec une expiration d'un an à compter du déploiement du dispositif. Lorsque ce certificat expire, Horizon Cloud Connector ne pourra plus contacter le plan de contrôle Horizon Cloud, ce qui rend inopérables les services basés sur le cloud fournis par Horizon Cloud Connector. Pour obtenir plus de détails et les étapes de correction, reportez-vous à l' article 90505 de la base de connaissances.

À partir de Horizon Cloud Connector version 2.4, le système renouvelle automatiquement les certificats avant leur expiration.

La configuration de l'hôte sans proxy spécifiée dans le champ Aucun proxy pour lors du déploiement du modèle OVF n'est pas enregistrée dans le dispositif déployé (2454245, 2466306, 2467017, DPM-5388)
Ce problème est résolu dans Horizon Cloud Connector version 1.6 ou ultérieure. Lors de l'exécution du workflow Déployer le modèle OVF dans votre environnement vSphere, vous avez la possibilité de spécifier une configuration d'hôte sans proxy dans le champ Aucun proxy pour. Toutefois, en raison de ce problème connu, les paramètres entrés ne sont pas capturés dans les fichiers de configuration du dispositif déployé. Par conséquent, le dispositif déployé ne respecte pas le paramètre d'hôte sans proxy spécifié.

Problèmes connus liés à la configuration de la passerelle des espaces Horizon Cloud

La fonctionnalité Horizon Universal Console permettant d'activer les paramètres du serveur Syslog dans la configuration de la passerelle est désactivée par défaut. (3005985, 3023935, 3026855)
En raison d'un problème identifié avec l'appel d'API du système pour mettre à jour la configuration d' Unified Access Gateway avec les informations du serveur Syslog, l'utilisation de la fonctionnalité précédemment publiée est désactivée dans la console. Solution : aucune.

Problèmes connus liés à Universal Broker

Le client Horizon Universal Broker sur Horizon Cloud Connector n'utilise pas de mises à jour liées au proxy que vous effectuez dans le dispositif du connecteur après le déploiement initial du dispositif (HD-35551)
Ce problème est résolu dans Horizon Cloud Connector version 1.6 ou ultérieure. Le client Horizon Universal Broker dans le dispositif du connecteur collecte les informations du proxy lors du démarrage initial du dispositif. Du fait que le démarrage initial ne s'exécute que lors de la toute première mise sous tension du dispositif après le déploiement du modèle OVF, les modifications ultérieures apportées aux paramètres de configuration du proxy du dispositif ne sont pas utilisées par le client Horizon Universal Broker. La combinaison de ce problème connu avec le problème connu ci-dessus concernant la configuration sans proxy lors du déploiement du modèle OVF implique que les hôtes associés au Horizon Universal Broker ne peuvent pas être définis en tant qu'hôtes sans proxy.
Le message d'erreur « Échec de la connexion au Serveur de connexion » s'affiche lorsqu'Horizon Client ou Horizon HTML Access dans le navigateur se connecte à Universal Broker (2714266)
Ce problème a une incidence sur les espaces Horizon Cloud dans Microsoft Azure qui exécutent le manifeste 2632.x, dans les locataires configurés pour utiliser Universal Broker pour l'intermédiation des postes de travail d'utilisateurs finaux. Vous pouvez également observer les deux problèmes suivants en même temps :
  • Sur la page de détails de l'espace sur lequel réside la VM de poste de travail, la santé de la VM du gestionnaire d'espace indique Erreur pour toutes les VM du gestionnaire d'espace.
  • Le message d'erreur « Ce poste de travail n'est actuellement pas disponible. Réessayez de vous connecter à ce poste de travail ultérieurement ou contactez votre administrateur système » S'affiche lorsqu'Horizon Client ou Horizon HTML Access dans le navigateur commence à se connecter à Universal Broker.
Ce problème peut se produire par intermittence pour les espaces Horizon Cloud dans Microsoft Azure qui exécutent le manifeste 2632.x si l'instance du gestionnaire d'espace a été redémarrée. Parfois, lorsque l'instance du gestionnaire d'espace a été redémarrée (situation rare et atypique), une fois que l'instance du gestionnaire d'espace est activée et qu'Universal Broker tente de se connecter à l'espace, elle ne peut établir aucune connexion authentifiée. Solution : aucune. Si vous rencontrez cette situation, ouvrez une demande de service pour obtenir de l'aide et indiquez le numéro 2714266 de rapport du problème interne.

Pour les espaces de manifeste 2747.x et versions ultérieures, ce problème est résolu.

Problèmes connus liés aux images, aux batteries de serveurs et aux attributions

les problèmes connus répertoriés ici s'appliquent à des espaces déployés dans Microsoft Azure.

Pendant le processus de publication de l'image, une erreur de délai d'expiration se produit et la VM reste sous tension et empêche l'exécution du flux de publication (2954270, 2962049)
Cette erreur est due à un problème dans l'hyperviseur Microsoft Azure qui se produit lors de l'exécution de l'étape Sysprep du processus de publication. Ce problème se produit dans certains modèles de VM Azure. Pour plus d'informations, reportez-vous à l'article  KB88343 de la base de connaissances VMware.

Pour fournir une résolution aux clients Horizon Cloud en fonction des recommandations de l'équipe Microsoft Azure, le modèle de VM Azure par défaut utilisé par l'assistant automatisé Importer une VM à partir de Marketplace du service est modifié dans la version v2204 du service afin d'utiliser le modèle Standard_DS2_v2 pour l'importation automatisée de VM Windows 10 sans GPU (à session unique ou multisession) :

  • Pour les images à espace unique, le modèle de VM par défaut de l'automatisation est modifié par rapport au modèle de VM Standard_D4_v3 précédemment utilisé pour utiliser Standard_DS2_v2.
  • Pour les images à plusieurs espaces, le modèle de VM par défaut de l'automatisation est modifié par rapport au modèle Standard_D2_v2 précédemment utilisé pour utiliser Standard_DS2_v2.

À partir de la version v2204, incluez un quota pour la série DSv2 Azure dans les abonnements Azure de l'espace.

Les VM et leurs ressources associées peuvent ne pas être supprimées complètement dans l'abonnement Microsoft Azure. (2824239, 2681761, 2750176)
Ce problème est résolu pour les manifestes d'espace 2915.x ou version ultérieure. Dans le cas où ce problème se produirait dans les espaces de manifestes antérieurs, des problèmes tels que l'extension des attributions VDI peuvent se produire. Cela est dû à un problème dans Azure Resource Manager (ARM) de Microsoft et à des retards dans la réplication de l'état des ressources dans plusieurs régions du cloud Microsoft Azure. En raison de ce problème relatif à Microsoft ARM, certaines de ces ressources liées à la VM risquent de ne pas être supprimées et, par conséquent, ne pas être attachées à une VM dans l'abonnement Azure. Les disques et les cartes réseau constituent des exemples de ces éléments non attachés. Solution : ce problème est résolu pour les espaces exécutant les manifestes 2915.x ou version ultérieure. Si vous rencontrez ce problème, adressez une demande de service (SR, Service Request) pour demander de l'aide pour l'effacement des données obsolètes et pour planifier la mise à niveau de votre espace afin d'éviter que le problème ne se reproduise. Reportez-vous à l' article 2006985 de la base de connaissances pour connaître les étapes d'archivage des SR.
Pour les espaces déployés dans les abonnements au cloud de Microsoft Azure Government, l'utilisation de la fonctionnalité de chiffrement de disque dans les batteries de serveurs et les attributions de poste de travail échoue. (2572579)
Lorsque votre espace se trouve dans des clouds Microsoft Azure Government et que vous tentez de créer une batterie de serveurs ou une attribution VDI avec la fonctionnalité de chiffrement de disque sélectionnée, le processus de création échoue avec l'erreur Azure error encrypting the VM. Solution : aucune.
Dans l'onglet Serveurs d'une batterie de serveurs existante, toutes les options du mode de connexion utilisateur affichent un message d'erreur signalant qu'Horizon Agent doit être mis à jour. (2528295)
L'utilisation de la console d'administration pour définir le mode de connexion utilisateur est liée à la détection de la version 20.1.0 de l'agent exécutée dans la machine virtuelle de la batterie de serveurs. Toutefois, cette version de l'agent peut ne pas être encore disponible dans le plan de contrôle du cloud pour que vous l'utilisiez dans la mise à jour des agents dans les VM de la batterie de serveurs existante. Solution : aucune. Lorsque la version 20.1.0 de l'agent est disponible dans le plan de cloud et que vos espaces sont mis à jour vers la version de manifeste qui peut utiliser cette version de l'agent, vous pouvez mettre à jour les VM de la batterie de serveurs vers cet agent pour utiliser les choix du mode de connexion utilisateur.
Parfois, certaines VM de poste de travail d'une attribution de poste de travail VDI flottant volumineuse signalent un état d'agent inconnu. (DPM-3201)
Dans les attributions de poste de travail VDI flottant comprenant un grand nombre de machines virtuelles de poste de travail, un petit nombre de ces machines virtuelles de poste de travail peuvent entrer dans un état d'agent inconnu en raison d'un problème connu, car certains services Windows, comme le service Blast d'Horizon Agent ou le service Microsoft Azure, ne démarrent pas ou sont lents à démarrer. Dans la console d'administration, la colonne État de l'agent pour ces machines virtuelles de poste de travail affiche l'état « Inconnu » avec des erreurs d'agent signalées. Solution : dans la console, utilisez l'action Redémarrer pour redémarrer ces VM.
L'assistant Importer la VM à partir de Marketplace crée des images Windows Server 2012 sans la fonctionnalité Expérience de poste de travail activée. (2101856)
En raison d'un problème connu, lorsque vous utilisez l'assistant automatisé Importer la VM à partir de Marketplace pour créer une image à l'aide d'un système d'exploitation Windows Server 2012, la fonctionnalité Expérience de poste de travail n'est pas activée sur l'image obtenue. Solution : si vous voulez affecter la fonctionnalité Expérience de poste de travail à l'image obtenue, vous devez l'activer manuellement. Notez également que pour le système d'exploitation Windows Server 2012, l'installation d'Horizon Agent avec l'option Redirection de scanner requiert l'activation de la fonctionnalité Expérience de poste de travail dans le système d'exploitation.
Lors de la publication (également appelée scellement) d'une machine virtuelle importée, il est possible que le processus entraîne un délai d'expiration ou d'autres échecs de publication en raison de défaillances Sysprep. (2036082, 2080101, 2120508, 2118047)
Lorsque vous cliquez sur Convertir en poste de travail sur une VM importée et sur Publier pour la convertir en image publiée (scellée), plusieurs opérations sont effectuées sur la VM. Ces opérations comprennent l'exécution du processus Préparation du système Windows (Sysprep), l'arrêt de la machine virtuelle et sa mise hors tension, etc. En raison de problèmes connus standard avec le processus Sysprep de Windows et la personnalisation des machines virtuelles, il arrive que le processus de publication échoue pour différentes raisons. Sur la page Activité, des messages tels que « Timeout Error Waited 20 minutes for virtual machine to power off » s'affichent, ainsi que d'autres messages d'échec Sysprep.

En règle générale, vous pouvez éviter ces problèmes Sysprep lors de la création de la VM en utilisant l'assistant Importer la VM à partir de Marketplace. Pour cela, cliquez sur Oui pour l'option Optimiser l'image Windows de l'assistant. Si cette erreur s'affiche pour une VM importée dans laquelle vous n'avez pas utilisé cette option, ou si vous avez créé manuellement cette VM, reportez-vous à l'article 2769827 de la base de connaissances Microsoft, rubrique 615 de Microsoft MVP pour obtenir des recommandations sur la configuration de votre VM d'image afin de réduire la probabilité d'apparition de problèmes Sysprep lors de la publication de l'image. Si les problèmes Sysprep persistent, reportez-vous aux informations des articles Décision d'optimiser l'image Windows lors de l'utilisation de l'assistant Importer la VM à partir de Marketplace et Utilisation de l'option Supprimer les applications du Windows Store lors de l'utilisation de l'assistant Importer un poste de travail pour obtenir les méthodes utilisées par l'assistant automatisé Importer la VM à partir de Marketplace afin de réduire les modifications des problèmes Sysprep. Si les erreurs de délai d'expiration s'affichent sur la page Activité, vous pouvez essayer cette solution : sur la page Images, utilisez l'action Convertir l'image en poste de travail sur l'image. Lorsque la page Activité indique que la conversion de l'image en poste de travail a réussi, accédez à la page VM importées. Connectez-vous à la VM et appliquez les recommandations décrites dans les bases de connaissances. Une fois que la page VM importées indique la mise sous tension de la VM, sélectionnez celle-ci et cliquez sur Convertir en image pour réexécuter le processus de publication.

Lors de la création d'une batterie de serveurs, les machines virtuelles de serveur peuvent parfois être bloquées à l'étape de personnalisation. (2010914, 2041909)
Parfois, pendant l'exécution du processus Sysprep sur les VM du serveur de la batterie de serveurs, un service Windows nommé tiledatamodelsvc empêche Sysprep d'accéder aux fichiers Windows dont il a besoin pour terminer le processus de personnalisation Sysprep. En conséquence, les VM du serveur de la batterie sont bloquées à l'étape de personnalisation. Le journal des erreurs Sysprep contient la ligne « Error SYSPRP setupdigetclassdevs failed with error 0 ». Solution : si vous rencontrez ce problème et que ce message d'erreur s'affiche dans le fichier journal des erreurs Sysprep, essayez d'arrêter et de désactiver le service tiledatamodelsvc sur l'image. Créez ensuite la batterie de serveurs.
L'état de l'agent affiché sur la page VM importées après la duplication d'une image ou la création manuelle d'une image dans Microsoft Azure peut être Non défini. (2002798)
Lorsque vous utilisez le bouton Dupliquer sur la page Images pour cloner une image publiée ou lorsque vous créez manuellement une VM d'image dans Microsoft Azure, la machine virtuelle obtenue est répertoriée sur la page VM importées. En raison de ce problème, même lorsque la machine virtuelle est sous tension, l'état de l'agent peut être « Non défini ». Toutefois, lorsque vous sélectionnez la machine virtuelle et choisissez Convertir en image pour la publier, l'interface utilisateur indique que l'agent est à l'état « Actif ». Solution : aucune. Si les workflows Réinitialiser le couplage d'agent, Nouvelle image ou Convertir en image indiquent que l'agent est « Actif », vous pouvez ignorer l'état « Non défini » sur la page VM importées.

Problèmes connus liés à App Volumes dans des espaces de Microsoft Azure

les problèmes connus répertoriés ici s'appliquent à des espaces déployés dans Microsoft Azure.

Le chargement de modules d'application (fichiers .vhd) portant le même nom de fichier au même emplacement (partage de fichiers), capturés à des moments différents, peut empêcher le service App Volumes d'attacher des applications aux postes de travail VDI lorsque l'utilisateur se connecte (2783560)
Chaque fois qu'App Volumes capture un module d'application (fichier .vhd), le système génère un GUID unique pour identifier le volume ou la session de capture. Lorsque vous tentez de charger un module d'application vers le partage de fichiers de préparation des espaces Horizon Cloud avec un nom de fichier (.vhd) qui a été chargé précédemment, une incompatibilité se produit entre les GUID déjà présents dans les espaces Horizon Cloud Azure et les services cloud.

Le service App Volumes Manager qui s'exécute sur les espaces Horizon Cloud Azure importe régulièrement les modules d'application à partir du partage de fichiers. Lorsque vous tentez d'importer les applications à partir de la page d'importation Inventaire > Applications d'Horizon Universal Console, les modules d'application récemment importés et leurs GUID correspondants sont incompatibles avec les GUID présents dans le service App Volumes Manager exécutant les espaces Horizon Cloud Azure. En raison de cette incompatibilité, les applications attribuées ne sont pas attachées aux utilisateurs autorisés.

La suppression de certains utilisateurs ou groupes d'une attribution App Volumes dans la console peut entraîner la suppression des droits de certains des utilisateurs ou groupes restants dans l'attribution (2704889)
En raison de ce problème, dans le scénario où vous avez créé une attribution App Volumes qui contient un ensemble d'applications et des utilisateurs ou groupes spécifiés, puis vous modifiez cette attribution et supprimez certains de ces utilisateurs ou groupes spécifiques, certains des utilisateurs et groupes qui restent configurés dans cette attribution constatent qu'ils ne voient pas les applications dans leurs postes de travail octroyés.

Bien que ce problème soit résolu dans le manifeste d'espaces 2747 et les versions ultérieures, vous pouvez rencontrer ce problème avec les espaces des manifestes de versions antérieures. Si vous rencontrez ce problème, vous pouvez le contourner en créant une nouvelle attribution App Volumes avec les applications et les utilisateurs et groupes requis, et en supprimant l'attribution App Volumes précédemment créée.

Lorsque votre environnement dispose de plusieurs espaces dans Microsoft Azure, le processus de capture peut parfois passer à un état inconnu une fois le processus terminé. (2600573)
Lorsque votre environnement dispose de plusieurs espaces avec lesquels vous utilisez App Volumes, il arrive qu'après l'exécution du processus de capture, la console indique que la capture est dans un état inconnu même si le processus de capture sur la machine virtuelle est terminé. Pour résoudre ce problème, réimportez le module d'application via Inventaire > Applications > Nouveau > Importer. Le module d'application est ainsi importé en tant qu'application distincte et le lancement suivant de l'attribution et de l'application fonctionne.
Dans un déploiement multisession de Microsoft Windows 10 Enterprise, une tâche d'impression peut se terminer lorsqu'un autre utilisateur se connecte à la même machine.
Dans cet environnement, lorsqu'un utilisateur avec une attribution de module d'applications contenant un pilote d'imprimante se connecte pour la première fois, une tâche d'impression en cours pour un autre utilisateur sur cette machine multisession peut entrer dans un état d'erreur. Pour contourner ce problème, attendez quelques minutes, ou plus, après la fin de la tâche d'impression et tentez à nouveau d'imprimer. Reportez-vous au guide Administration de votre environnement de locataire Horizon Cloud et de votre flotte d'espaces embarqués pour obtenir des informations sur les meilleures pratiques en la matière.
Dans un déploiement multisession de Microsoft Windows 10 Enterprise, les utilisateurs qui ne sont pas attribués à un module d'application reçoivent des aspects de l'application

Dans cet environnement, lorsque vous ne désactivez pas les mises à jour automatiques d'une application pendant le provisionnement, il arrive parfois que la partie mise à jour de l'application devienne par inadvertance visible pour tous les utilisateurs (et pas seulement pour ceux auxquels l'application a été attribuée) sur le poste de travail multisession, par exemple sous la forme d'un raccourci de poste de travail et de fichiers binaires d'application. Pour contourner ce problème, pour les applications avec des services de mise à jour automatique, ajoutez le nom du service de l'application à la configuration de registre à chaînes multiples svservice DisableAppServicesList pour vous assurer que les services de mise à jour automatique ne sont pas démarrés. Reportez-vous au guide Administration de votre environnement de locataire Horizon Cloud et de votre flotte d'espaces embarqués pour obtenir des informations sur les meilleures pratiques en la matière.

Problèmes connus liés à la mise à jour de l'agent

les problèmes connus répertoriés ici s'appliquent à des espaces déployés dans Microsoft Azure.

Lorsque vous tentez de mettre à jour un agent sur une image ayant une mise à jour Windows en attente, le processus de mise à jour peut échouer. (2234964)
Si l'image a besoin d'une mise à jour sur le système d'exploitation Windows, plutôt que d'une mise à jour mineure hors du système d'exploitation, cela risque de mettre les ressources du système d'exploitation hors ligne et non disponibles pour la mise à jour de l'agent. Solution : attendez la fin de la mise à jour de Windows et réessayez de mettre à jour l'agent. Pour vérifier si toutes les mises à jour de Windows sont terminées, vous pouvez mettre l'image hors ligne, effectuer toutes les mises à jour en attente et publier l'image de nouveau avant de lancer la mise à jour de l'agent.

Problèmes connus liés aux rapports et à la surveillance

les problèmes connus répertoriés ici s'appliquent à des espaces déployés dans Microsoft Azure.

Dans le rapport Activité utilisateur, la moyenne hebdomadaire (h) affichée n'est pas intuitive. (1817065)
En raison de ce problème, les statistiques hebdomadaires varient dans le temps, car la logique de calcul consiste à diviser la durée actuelle de la semaine par sept (7) et à ne pas arrondir à une semaine complète. Par exemple, lorsque vous sélectionnez les 30 derniers jours, les données des semaines passées sont inchangées, mais les données de la semaine en cours sont divisées par sept (7). La logique actuelle est moyenne hebdomadaire (h) = moyenne quotidienne (h) × 7 jours, d'où la moyenne hebdomadaire des 30 derniers jours = (durée totale/30 jours) × 7 jours. Solution : aucune
L'état de santé du poste de travail ne reflète pas un nom de batterie de serveurs récemment mis à jour ou d'attribution de poste de travail VDI avant une heure après la modification du nom. (1756889)
Si vous modifiez le nom d'une batterie de serveurs ou d'une attribution de poste de travail VDI, il faut une heure pour que le menu déroulant Attribution et la colonne Attribution du rapport État de santé du poste de travail reflètent le nouveau nom. Solution : attendez une heure pour que le nouveau nom s'affiche dans le rapport.
La mise en forme de certains fichiers CSV que vous pouvez exporter depuis les écrans Rapports de l'interface utilisateur ne correspond pas aux tableaux qui s'affichent. (2015500)
Certains des sous-écrans de la page Rapports fournissent une fonctionnalité d'exportation pour exporter les données affichées au format CSV. En raison de ce problème, la mise en forme dans les fichiers CSV exportés à partir des rapports État de santé du poste de travail, Simultanéité, et Historique de session ne correspond pas exactement à ceux qui s'affichent à l'écran. Par exemple, les en-têtes de colonne peuvent être différents et les fichiers CSV peuvent avoir plus de colonnes de données que dans les tableaux affichés à l'écran. Solution : aucune.

Problèmes connus liés à la gestion des identités, à Workspace ONE Access et à True SSO

les problèmes connus répertoriés ici s'appliquent à des espaces déployés dans Microsoft Azure.

Lorsqu'un espace de versions de manifeste antérieures à 1763 est mis à jour vers le manifeste 1763 ou une version ultérieure, et que cet espace dispose de l'authentification RADIUS à deux facteurs configurée sur ses instances d'Unified Access Gateway et qu'il est également intégré à Workspace ONE Access, vous observez que le lancement d'un poste de travail depuis Workspace ONE Access à l'aide du navigateur affiche le formulaire de connexion RADIUS avec le champ Nom d'utilisateur prérempli avec l'UPN de l'utilisateur. (2248160)
Ce symptôme se produit en raison d'une modification qui a été publiée dans VMware Horizon HTML Access 4.10. Lorsque votre espace dans Microsoft Azure est configuré à partir d'une version précédente d'Horizon Cloud avec des instances d'Unified Access Gateway et une authentification RADIUS à deux facteurs et que vous configurez cet espace pour utiliser Workspace ONE Access, auparavant lors du lancement d'un poste de travail depuis Workspace ONE Access à l'aide du navigateur, le formulaire de connexion RADIUS demandait le nom d'utilisateur et le code secret. L'utilisateur final devait saisir le nom d'utilisateur et le code secret dans le formulaire. Toutefois, en raison de ce problème, après la mise à niveau de cet espace vers cette version, en suivant la même procédure de démarrage du poste de travail, le formulaire de connexion RADIUS comporte le champ Nom d'utilisateur prérempli avec l'UPN de l'utilisateur de domaine. Ce comportement se produit uniquement lorsque vous utilisez le navigateur pour lancer le poste de travail. Il ne se produit pas lorsque vous utilisez Horizon Client. Solution : si cette situation se produit, l'utilisateur final peut effacer le champ Nom d'utilisateur prérempli et entrer les informations requises. En règle générale, pour la plupart des environnements intégrés à Workspace ONE Access, l'authentification à deux facteurs est configurée dans Workspace ONE Access et non sur les instances d'Unified Access Gateway sous-jacentes, auquel cas ce problème ne se produit pas.
Le lancement d'un deuxième poste de travail depuis Workspace ONE Access en utilisant Horizon Client peut échouer avec l'erreur « Vous n'êtes pas autorisé à accéder à ce poste de travail ou à cette application ». (1813881, 2201599)
Ce symptôme se produit dans la situation suivante. L'utilisateur dispose de droits d'accès aux deux attributions VDI dédiées par le biais d'une autorisation de groupe. Les deux attributions de poste de travail VDI dédié sont répertoriées dans Workspace ONE Access lorsque l'utilisateur se connecte. L'utilisateur lance le premier poste de travail à l'aide d'Horizon Client. Ce poste de travail se connecte. L'utilisateur tente ensuite de lancer l'autre poste de travail depuis l'autre attribution, en utilisant là encore Horizon Client. Le lancement de ce poste de travail échoue avec une erreur indiquant que l'utilisateur n'est pas autorisé. Cependant, ce problème se produit uniquement lors de la première tentative sur le deuxième poste de travail. Si l'utilisateur lance le deuxième poste de travail à l'aide du navigateur, les tentatives ultérieures de lancement du deuxième poste de travail à l'aide d'Horizon Client réussissent. Solution : si vous rencontrez cette situation, essayez de lancer le deuxième poste de travail à l'aide du navigateur.
Workspace ONE Access n'affiche pas les noms d'affichage des applications distantes que vous avez définis dans la console d'administration d'Horizon Cloud. (2131583)
Ce problème est résolu à l'aide de Workspace ONE Access Connector version 19.03. En raison d'un problème connu des versions de Workspace ONE Access Connector antérieures à 19.03, lorsque Workspace ONE Access affiche les applications distantes que vous synchronisez depuis Horizon Cloud, Workspace ONE Access n'affiche pas les noms d'affichage que vous avez définis pour ces applications distantes dans Horizon Cloud. Même si Horizon Cloud envoie les noms d'affichage à Workspace ONE Access, Workspace ONE Access utilise plutôt les ID de lancement des applications distantes. Par conséquent, Workspace ONE Access affiche les noms de base pour les applications distantes.

Problèmes connus liés à l'interface utilisateur

sauf indication contraire dans la section portant sur les problèmes connus, les problèmes connus répertoriés ici s'appliquent à des espaces déployés dans Microsoft Azure.

Le graphique Segments d'ouverture de session affiché dans le tableau de bord de session ne comporte pas de données.
Ce problème s'applique à tous les types d'espaces. Le service VMware Logon Monitor fournit des données pour le graphique Segments d'ouverture de session qui s'affiche dans le tableau de bord de session. Cependant, cette version ne prend pas en charge l'utilisation du service VMware Logon Monitor et, par défaut, Horizon Agents Installer désactive ce service dans toutes les installations qu'il effectue. Par conséquent, même si aucune donnée ne figure dans le graphique Segments d'ouverture de session, vous pouvez voir que ce graphique est toujours visible dans le tableau de bord de la session. Solution : aucune.
Lorsque vous utilisez la console d'administration dans un onglet du navigateur, si vous essayez de lancer un poste de travail déconnecté qui se trouve dans un autre onglet du même navigateur, le portail HTML Access est également déconnecté et vous devez vous reconnecter au portail HTML Access. (2118293)
En général, lorsque vous lancez un poste de travail et que vous déconnectez sans fermer le poste de travail, vous restez connecté au portail HTML Access lui-même et vous pouvez vous reconnecter au poste de travail déconnecté sans devoir entrer les informations d'identification pour accéder au portail HTML Access. En raison de ce problème, si vous êtes dans une fenêtre du navigateur où vous êtes connecté à la console d'administration dans un onglet du navigateur et que vous utilisez un autre onglet du navigateur pour vous connecter au portail HTML Access et lancer un poste de travail, le portail HTML Access ferme lorsque vous vous déconnectez de ce poste de travail et essayez de rétablir la connexion. Ensuite, vous devez entrer à nouveau les informations d'identification pour accéder au portail HTML Access avant de pouvoir vous reconnecter à ce poste de travail. Solution : pour éviter ce problème, connectez-vous à la console d'administration à l'aide d'une fenêtre distincte du navigateur à partir de laquelle vous avez accès au portail HTML Access. Ce comportement se produit uniquement si vous êtes également connecté à la console dans un onglet du navigateur de la même fenêtre du navigateur dans laquelle vous utilisez également le portail HTML Access.
Sur l'écran de la fiche utilisateur d'un utilisateur spécifique, les attributions de poste de travail VDI dédié sont supprimées de l'onglet Attributions une fois que l'utilisateur lance pour la première fois le poste de travail dédié à partir de cette attribution. (1958046)
Lorsqu'un utilisateur est spécifié dans une attribution de poste de travail VDI dédié en tant qu'utilisateur individuel et non via un groupe Active Directory, cette attribution de poste de travail VDI dédié s'affiche dans l'onglet Attributions sur l'écran de la fiche utilisateur de cet utilisateur uniquement jusqu'à ce que l'utilisateur lance pour la première fois un poste de travail dédié à partir de cette attribution. Une fois que l'utilisateur lance pour la première fois un poste de travail VDI dédié à partir de cette attribution, l'onglet Attributions de la fiche utilisateur n'affiche plus l'attribution de poste de travail VDI dédié de cet utilisateur. Lors du premier lancement, l'utilisateur demande un poste de travail dédié spécifique à partir du pool sous-jacent défini par cette attribution et le système mappe ce poste de travail dédié spécifique à cet utilisateur particulier. À la fin du mappage, ce poste de travail dédié spécifique obtient l'état Affecté et il est répertorié sur l'onglet Postes de travail de la fiche utilisateur de cet utilisateur.

Solution : au lieu de recourir à l'onglet Attributions de la fiche utilisateur, vous pouvez utiliser l'onglet Postes de travail pour voir les postes de travail VDI dédiés déjà lancés et attribués à un utilisateur spécifique. Si vous avez besoin de localiser l'attribution d'un poste de travail VDI dédié spécifique dans laquelle ce mappage entre le poste de travail et l'utilisateur est effectué, obtenez le nom du poste de travail à partir de l'onglet Poste de travail de la fiche utilisateur et utilisez la fonctionnalité de recherche de bannière supérieure par machines virtuelles pour répertorier cette machine virtuelle de poste de travail spécifique. Cliquez sur le nom des résultats de la recherche par machines virtuelles pour ouvrir la page d'attribution spécifique qui dispose de ce poste de travail dédié particulier. Vous pouvez ensuite localiser l'utilisateur dans les détails de l'attribution.

L'écran Nouveautés s'affiche, même si vous avez précédemment sélectionné l'option inverse. (2075825)
Ce problème s'applique aux environnements présentant n'importe quel type d'espace. En raison de ce problème, si vous effacez le cache du navigateur ou que vous utilisez un autre navigateur que celui dans lequel vous avez précédemment sélectionné l'option de ne pas afficher l'écran Nouveautés, l'écran peut s'afficher lorsque vous vous connectez à la console d'administration. L'indicateur qui permet d'afficher l'écran Nouveautés est stocké dans le cache local du navigateur plutôt que par utilisateur. Solution : aucune.
Même si le processus de création d'image n'est pas entièrement terminé, l'écran Démarrage affiche la valeur Terminé pour l'étape Créer une Image. (2100467)
En raison de ce problème, l'étape Créer une Image est marquée comme étant terminée prématurément. Solution : utilisez la page Activité pour vérifier que le processus de création d'images est terminé.
Lorsque vous utilisez la console d'administration, des espaces réservés peuvent s'afficher au lieu des chaînes de texte ou vous cliquez sur un bouton sur une page et rien ne se passe. (2045967)
Ce problème s'applique aux environnements présentant n'importe quel type d'espace. VMware met régulièrement à jour l'environnement de gestion dans le cloud qui héberge la console Web. Ce problème peut se produire lorsque du contenu statique a été mis en cache dans le navigateur avant la dernière mise à jour dans le cloud. Il s'agit d'un problème temporaire qui disparaît lorsque le cache du navigateur est désactivé. Solution : essayez de vous déconnecter de la console, d'effacer le cache du navigateur, de redémarrer le navigateur, puis de vous reconnecter à la console.
Les noms d'applications s'affichent avec des caractères minuscules lorsque des utilisateurs finaux y accèdent à l'aide de Workspace ONE Access. (1967245)
Lorsque votre environnement Horizon Cloud est intégré à Workspace ONE Access, vos utilisateurs finaux accèdent à leurs applications et postes de travail attribués à l'aide de Workspace ONE Access. En raison de ce problème connu, les utilisateurs voient les noms des applications affichés avec des caractères minuscules, quelle que soit la casse effectivement utilisée dans les noms d'applications. Cette limitation est due à la manière dont Workspace ONE Access crée des ID de lancement à partir d'Horizon Cloud en utilisant d'anciennes instances d'Horizon Cloud REST API. Solution : aucune.
Les pourcentages d'utilisation de la mémoire signalés dans les rapports de santé du poste de travail et utilisés pour les alertes de santé du poste de travail sont basés sur le pourcentage de mémoire allouée, c'est-à-dire la somme de la mémoire physique et de la taille du fichier d'échange, et pas uniquement le pourcentage de mémoire physique. (2015772)
La mémoire allouée pour une machine virtuelle de poste de travail est calculée en additionnant la mémoire physique et la taille du fichier d'échange. Lorsque vous calculez le pourcentage d'utilisation de la mémoire dans un poste de travail, le système prend en compte le pourcentage total utilisé (mémoire physique et taille du fichier d'échange). Les alertes de santé du poste de travail et le rapport d'utilisation de mémoire dans les rapports de santé du poste de travail utilisent ce calcul de pourcentage. Toutefois, lorsque vous vous connectez à une machine virtuelle de poste de travail et ouvrez le Gestionnaire des tâches Windows pour afficher l'utilisation de la mémoire dans le système d'exploitation du poste de travail Windows, il affiche le pourcentage basé sur la mémoire physique uniquement. En conséquence, le pourcentage d'utilisation de la mémoire qu'affiche le Gestionnaire des tâches Windows du poste de travail ne correspond pas au pourcentage d'utilisation de la mémoire affiché dans les rapports de santé du poste de travail ou dans l'alerte de santé du poste de travail. Solution : tenez compte de cette différence si vous décidez d'effectuer une comparaison entre le pourcentage d'utilisation de la mémoire indiquée par le Gestionnaire des tâches d'un poste de travail Windows et le pourcentage d'utilisation de la mémoire indiquée dans le rapport Santé du poste de travail et les alertes de santé du poste de travail de la console pour ce poste de travail.
Lorsque l'utilisation du CPU d'une VM de poste de travail est proche de ou égale à 100 %, l'alerte de poste de travail n'est pas déclenchée. (1446496)
Si une application ou un élément dans la machine virtuelle de poste de travail entraîne l'utilisation du CPU de la machine virtuelle à 100 %, Desktop Agent ne parvient pas à envoyer autant d'échantillons de données qu'il envoie généralement à Horizon Cloud, en raison du niveau d'utilisation du CPU. Étant donné le faible nombre d'échantillons renvoyés, le calcul que le système utilise pour déclencher l'alerte de poste de travail est affecté. Solution : aucune.

Utilisateur final, Horizon Agent, problèmes connus liés à Horizon Client

les problèmes connus répertoriés ici s'appliquent à des espaces déployés dans Microsoft Azure.

Le lancement d'un poste de travail dédié à partir d'une instance d'Horizon Client à l'aide d'une option récente ouverte (ou d'une option équivalente selon le type de client) peut ne pas lancer correctement le poste de travail dédié (SR23422432704, HCS-39121)
Plusieurs instances d'Horizon Client fournissent des mécanismes par lesquels le client mémorise un poste de travail ou une application distante précédemment lancés. L'utilisateur final peut alors lancer ces applications publiées ou ces postes de travail précédemment ouverts sans accéder à la liste complète des postes de travail et des applications auxquels il a accès.

Par exemple, dans Horizon Client pour iOS et Horizon Client pour Android, les écrans nommés Récent fournissent un accès aux applications distantes et aux postes de travail précédemment lancés. Comme décrit dans la documentation d'Horizon Client pour Mac, l'instance d'Horizon Client pour Mac propose deux façons d'ouvrir les applications distantes et les postes de travail récents : à l'aide de l'option Fichier > Ouvrir les éléments récents du client et, si le client est ajouté au Dock, à l'aide de l'icône sur le Dock. Comme décrit dans la documentation d'Horizon Client pour Windows, l'instance d'Horizon Client pour Windows dispose d'un paramètre GPO pour l'intégration de liste de raccourcis. Ce paramètre est généralement activé par défaut, ce qui permet aux utilisateurs de se connecter aux applications publiées et aux postes de travail récents à l'aide de l'icône Horizon Client située dans la barre des tâches Windows.

Dans le cas d'un poste de travail dédié provisionné par Horizon Cloud on Microsoft Azure, après le lancement initial du poste de travail, l'instance d'Horizon Client peut ne pas stocker l'identité correcte du poste de travail en tant que lancement récent.

En raison de ce problème, lorsque l'utilisateur final utilise par la suite l'un des mécanismes récents des clients décrits ci-dessus pour rouvrir ce poste de travail, le poste de travail peut ne pas se lancer.

Ce problème peut également se produire si Workspace ONE Access est utilisé avec le déploiement d'Horizon Cloud on Microsoft Azure et que l'instance d'Horizon Client redirige l'utilisateur vers Workspace ONE pour orchestrer le lancement du poste de travail dédié. Si l'utilisateur final a précédemment lancé le poste de travail directement à partir du portail Workspace ONE, puis tente d'utiliser l'un des mécanismes récents du client pour lancer le poste de travail, lorsque le client redirige l'utilisateur vers Workspace ONE pour orchestrer le lancement, le poste de travail peut ne pas se lancer en raison de ce problème.

Solution : pour éviter ce problème, lancez toujours le poste de travail en le sélectionnant directement dans la liste complète des postes de travail du client ou, lorsque l'environnement est configuré pour exiger que tous les lancements soient effectués depuis le portail Workspace ONE, en sélectionnant le poste de travail dans le portail Workspace ONE. Évitez d'utiliser le mécanisme récent d'un client (évitez d'utiliser Fichier > Ouvrir les éléments récents, la liste Récent ou l'un des mécanismes récents proposés par les clients).
Note : Lorsque la redirection Workspace ONE est activée pour le déploiement d' Horizon Cloud on Microsoft Azure, qu'un utilisateur final utilise un mécanisme récent et que le lancement du poste de travail échoue, un événement d'audit Workspace ONE est écrit pour indiquer l'échec du lancement.
Pour une machine virtuelle exécutant Microsoft Windows 10 Enterprise multisession 2004 ou version ultérieure, les fonctionnalités de synchronisation DPI et de mise à l'échelle de l'affichage présentent des problèmes (2587685, DPM-6352)
En raison de l'impossibilité d'interroger le DPI actuel sur les machines virtuelles exécutant Microsoft Windows 10 Enterprise multisession 2004 ou version ultérieure, ces fonctionnalités avec ces machines virtuelles ne fonctionnent pas comme indiqué dans la documentation d'Horizon Client. Les fonctionnalités de synchronisation DPI et de mise à l'échelle de l'affichage ne fonctionnent pas pour les reconnexions de la session PCoIP. La fonctionnalité de mise à l'échelle DPI ne fonctionne pas pour les reconnexions de la session Blast. Solution : fermez la session, puis reconnectez-vous.
Pour une machine virtuelle exécutant le système d'exploitation Microsoft Windows 10 Enterprise 1903 ou version ultérieure, les fonctionnalités de synchronisation DPI et de mise à l'échelle de l'affichage présentent des problèmes (2589129)
En raison de l'impossibilité d'interroger le DPI actuel sur les machines virtuelles exécutant le système d'exploitation du client Microsoft Windows 10 Enterprise 1903 ou version ultérieure, les fonctionnalités ne fonctionnent pas comme indiqué dans la documentation d'Horizon Client lors de la reconnexion d'une session PCoIP ou Blast. Solution : fermez la session, puis reconnectez-vous.
Parfois, lorsque vous lancez un poste de travail VDI à l'aide de VMware HTML Access, un message d'erreur concernant la déconnexion s'affiche, puis le lancement est réussi. (2243471)
Les machines virtuelles de poste de travail VDI ont un délai de connexion de session par défaut et, lorsque ce délai d'expiration est atteint, la session est déconnectée. Parfois, lorsque vous lancez un poste de travail, si la session HTML Access de l'utilisateur final a expiré au moment où le délai de connexion de session du poste de travail par défaut est atteint, le poste de travail lèvera cette erreur et continuera à lancer le poste de travail. Solution : aucune.
Lorsque le chiffrement de disque est sélectionné sur une attribution de poste de travail VDI et que celle-ci dispose d'un modèle de machine virtuelle à un ou deux cœurs, si la machine virtuelle sous-jacente d'un poste de travail est mise hors tension, l'option de nouvelle tentative automatique de connexion d'Horizon Client peut échouer. (2167432)
Lorsqu'une machine virtuelle de poste de travail VDI est mise hors tension en raison des paramètres de gestion d'alimentation de l'attribution de poste de travail VDI, elle doit être mise sous tension et prête à être utilisée avant qu'un utilisateur final ne se connecte à ce poste de travail. Lorsqu'un client de l'utilisateur final tente de se connecter à la machine virtuelle d'une attribution de poste de travail VDI et que la machine virtuelle est hors tension, le système démarre la mise sous tension de cette machine virtuelle. Pour les machines virtuelles non chiffrées, la machine virtuelle est généralement prête à accepter une connexion client en moins de 10 minutes. Cependant, une machine virtuelle chiffrée à un ou deux cœurs met généralement plus de 10 minutes pour se préparer à accepter une connexion. L'option Nouvelle tentative client d'Horizon Client permet de configurer une limite maximale de 12 minutes. En raison de cette limite supérieure de l'option Nouvelle tentative client, lorsque l'utilisateur final demande au client de retenter automatiquement la connexion alors que la VM sous-jacente du poste de travail est mise sous tension et prête, mais que la connexion n'est pas établie dans les 12 minutes qui suivent, la nouvelle tentative automatique du client est abandonnée. Comme une machine virtuelle chiffrée met généralement plus de 12 minutes à se préparer à établir la connexion client, l'utilisateur final peut observer que la nouvelle tentative automatique d'Horizon Client ne parvient pas à établir la connexion à sa VM de poste de travail chiffrée. Solution : si vous souhaitez disposer du chiffrement de disque d'une attribution de poste de travail VDI, sélectionnez un modèle de VM comportant plus de deux cœurs. Sinon, si votre attribution de poste de travail VDI a un chiffrement de disque et un modèle de machine virtuelle à un ou deux cœurs, informez vos utilisateurs finaux qu'ils peuvent rencontrer ce problème lors de l'utilisation de l'option Nouvelle tentative client avec ces machines virtuelles de poste de travail chiffrées.
Pour un poste de travail virtuel d'une attribution de poste de travail VDI dédié, il est possible que le lien de raccourci sur la page Récent d'Horizon Client ne lance pas le poste de travail. (1813881, HD-3686, DPM-1140)
Les versions d'iOS et d'Android des clients Horizon Client disposent d'une page Récent qui affiche des liens vers les postes de travail lancés récemment. Lorsque l'utilisateur lance pour la première fois un poste de travail virtuel de pool dédié, le poste de travail se lance normalement et le client crée une icône de lancement sur la page Récent. Toutefois, lorsque l'utilisateur se déconnecte du poste de travail et qu'il réessaie ultérieurement de le lancer à partir de la page Récent, le poste de travail ne parvient pas à se lancer, car l'icône de lancement utilise une version raccourcie du nom du poste de travail. Solution : lancez le poste de travail depuis la page principale du client, pas depuis la page Récent.
Espaces à la version de manifeste 1976.0 et VM de batterie de serveurs exécutant le niveau agent 19.4 : les utilisateurs sont déconnectés après une heure depuis leurs sessions de postes de travail ou d'application distante lors de l'utilisation de protocoles HTML Access (Blast) et PCoIP. (2519400)
Cet incident est dû à un problème des services de terminaux Microsoft dans les systèmes Microsoft Windows 10 Enterprise multisession. Pour les postes de travail basés sur une session et les applications distantes provisionnées à partir de batteries de serveurs RDSH basées sur le système d'exploitation Microsoft Windows 10 Enterprise multisession : lorsqu'un utilisateur final se reconnecte à un poste de travail existant ou à une session d'application distante via le protocole HTML Access (Blast) ou PCoIP, la session de l'utilisateur est déconnectée de force après une heure. Il n'y a aucune perte de données. Même si l'utilisateur peut se reconnecter et que la session est dans le même état qu'au moment de la déconnexion, ce comportement se répète et la session reconnectée est de nouveau interrompue de force après une heure.

Ce problème est résolu à l'aide d'Horizon Agents Installer (HAI) 20.1 ou version ultérieure. Lorsque votre espace 1976.0 est mis à jour vers le manifeste 1976.1 ou version ultérieure, l'assistant Importer la VM à partir de Marketplace installe automatiquement le logiciel agent qui comporte ce correctif. Si votre espace est toujours au niveau de manifeste 1976.0, l'exécution de l'assistant installera quand même le logiciel agent avec le problème. Toutefois, lorsque vous scellez la machine virtuelle, la page Images affiche un point bleu, indiquant que vous pouvez utiliser la fonctionnalité Mettre à jour l'agent pour mettre à jour l'agent au niveau de correctif.

Espaces à des versions de manifeste antérieures à 2298. Lors du basculement des protocoles dans le client, si vous choisissez l'option Connecter à la place de Déconnecter et Reconnecter, le client peut cesser de répondre. (2528014)
Ce problème est résolu dans les espaces mis à jour vers la version de manifeste 2298 ou vers une version ultérieure. Ce problème se produit lors de la commutation de protocoles dans le client après l'établissement d'une session sur une batterie de serveurs RDSH à l'aide d'un protocole. Lorsque vous lancez le poste de travail ou l'application à l'aide d'un protocole, déconnectez cette session, utilisez le menu du client pour basculer vers un autre protocole et lancez le même poste de travail ou la même application, le client affiche une boîte de dialogue indiquant « Ce poste de travail est ouvert sur le serveur, mais il exécute un autre protocole ». En outre, il présente un choix de connexion ou de déconnexion et de reconnexion. Si vous sélectionnez le bouton Connecter, la boîte de dialogue s'affiche une deuxième fois et si vous sélectionnez Connecter de nouveau, le client ne répond plus.
Lorsque vous utilisez la fonctionnalité Mettre à jour l'agent pour mettre à jour des images disposant d'une version d'agent antérieure à 18.2.2, le processus de mise à jour peut échouer (2200962)
Les images que vous avez créées sur des nœuds à un niveau de manifeste antérieur à 965 peuvent rencontrer ce problème. Parfois, l'image a des valeurs de Registre RunOnce qui interdisent l'aboutissement du processus de mise à jour de l'agent. Solution : relancez la mise à jour de l'agent, en ajoutant l'argument de ligne de commande suivant dans l'onglet Ligne de commande de l'assistant de mise à jour de l'agent : VDM_SUPPRESS_RUNONCE_CHECK=1