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.

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, les problèmes connus du logiciel s'exécutant dans ces espaces Horizon sont fournis ailleurs. Les problèmes connus des versions logicielles des espaces Horizon se trouvent dans les notes de mise à jour du logiciel Horizon lui-même. Les documents du logiciel Horizon version 7.x sont liés depuis la page de documentation de VMware Horizon 7. Les documents de la version 2006 du logiciel Horizon sont liés depuis cette page de documentation de VMware Horizon (parfois appelée Horizon 8 en plus d'Horizon 2006).

Pour plus d'informations sur les problèmes connus du service de gestion des images (IMS, Image Management Service), 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 à Cloud Connector

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 une version 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 à 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 une version 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.

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.

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 KB 2079196 de la base de connaissances de VMware, à l'article KB 2769827 de la base de connaissances de Microsoft, à l'article 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 de désactiver le service tiledatamodelsvc sur l'image, puis de créer 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.

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.

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 à l'authentification unique réelle

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 contenu de la fenêtre Aide > À propos de de la console d'administration n'est pas précis.
Lorsque vous cliquez sur Aide > À propos de dans la console, les informations de la fenêtre ne sont pas précises. En raison de ce problème, le texte est codé de manière irréversible pour toujours afficher la version 2.2 plutôt que d'indiquer des éléments précis et pertinents sur l'environnement du locataire ou sur l'environnement du plan de contrôle du cloud dans lequel vous travaillez. Solution : aucune.
Même si un espace au niveau du manifeste 2298.0 ou une version ultérieure doit disposer d'au moins une configuration de passerelle pour les opérations prises en charge, la console d'administration ne vous empêche pas de supprimer la seule configuration de passerelle de l'espace et de la laisser dans cet état non pris en charge.
La console d'administration fournit un workflow dans lequel vous pouvez supprimer la configuration de la passerelle existante d'un espace afin de redéployer la passerelle avec une nouvelle configuration de déploiement. Ce workflow est fourni, car à ce stade, la console ne permet pas d'utiliser le workflow Modifier l'espace pour mettre à jour la configuration de déploiement de la passerelle, même si ce workflow peut être utilisé pour mettre à jour la configuration logicielle de la passerelle à tout moment.

Désormais, un espace au niveau du manifeste 2298 ou une version ultérieure doit disposer d'au moins une configuration de passerelle pour obtenir une prise en charge des opérations. Lorsque vous supprimez la seule configuration de passerelle d'un espace afin de mettre à jour la configuration de déploiement de la passerelle, comme indiqué dans le paragraphe précédent, la console affiche un message d'avertissement. Toutefois, la console n'empêche pas la suppression de la seule passerelle déployée de l'espace, car elle fournit le cas d'utilisation, comme décrit dans le paragraphe précédent. Il est prévu que vous redéployiez ultérieurement la configuration de la passerelle peu après avec de nouveaux choix de déploiement de la passerelle dont la configuration supprimée ne disposait pas. Le problème est que la console autorise actuellement la suppression de la seule configuration de passerelle d'un espace sur lequel au moins une passerelle est requise pour les opérations prises en charge, alors qu'en même temps la console ne nécessite pas de redéploiement d'une nouvelle passerelle sur l'espace peu après. Si vous laissez l'espace sans configuration de passerelle, la configuration de cet espace n'est pas prise en charge.

Solution : pour obtenir une prise en charge de la configuration, vous devez vous assurer que chaque espace de manifeste 2298.0 ou une version ultérieure dispose d'au moins une configuration de passerelle. L'une des configurations suivantes doit être déployée sur l'espace :

  • une passerelle externe ;
  • une passerelle interne ;
  • des passerelles externe et interne.

Si vous supprimez la seule configuration de passerelle d'un espace de manifeste 2298.0 ou version ultérieure pour modifier un paramètre de passerelle qui ne peut être modifié que par la suppression et le redéploiement de la passerelle, vous devez redéployer une nouvelle passerelle sur l'espace pour conserver une configuration prise en charge. L'équipe du service VMware Horizon travaille sur des améliorations qui ne nécessitent plus la console pour fournir un workflow permettant de supprimer une passerelle déployée pour le cas d'utilisation de la modification de la configuration du déploiement de la passerelle. À ce stade, la possibilité de suppression de la seule configuration de passerelle de l'espace à l'aide de la console est exclue.

Dans la fiche utilisateur, lorsque vous cliquez sur Réinitialiser sur une session de poste de travail VDI à partir d'un espace dans Microsoft Azure, un message d'erreur s'affiche même si la VM a été réinitialisée. (2567272)
En raison de ce problème, même si l'opération de réinitialisation est lancée et si la machine virtuelle finit par être réinitialisée, la console d'administration affiche une boîte de message d'erreur. Le message implique que le système n'a pas pu traiter votre demande, en dépit de la réinitialisation effective de la VM. Ce problème peut être observé pour une session de poste de travail à partir d'une attribution de poste de travail VDI flottant. Solution : aucune. L'opération de réinitialisation a été lancée et la machine virtuelle finit par être réinitialisée. Fermez la boîte de message d'erreur qui s'affiche.
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.

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