Enregistrement de VDA
Introduction
Remarque :
Dans un environnement local, les VDA sont enregistrés auprès d’un Delivery Controller. Dans un environnement de service Citrix Cloud, les VDA sont enregistrés auprès d’un Cloud Connector. Dans un environnement hybride, certains VDA sont enregistrés auprès d’un Delivery Controller tandis que d’autres sont enregistrés auprès d’un Cloud Connector.
Avant qu’un VDA puisse être utilisé, il doit s’enregistrer (établir la communication) auprès d’un ou de plusieurs Controller ou Cloud Connector sur le site. Le VDA trouve un Controller ou un Connector en vérifiant une liste appelée ListofDDCs. La liste ListOfDDCs sur un VDA se compose d’une ou plusieurs entrées DNS qui pointent le VDA vers des Controller ou Cloud Connector sur le site. Pour assurer l’équilibrage de charge, le VDA répartit automatiquement les connexions de manière équitable entre les Controller ou Cloud Connector dans la liste.
Pourquoi l’enregistrement de VDA est-il si important ?
- Du point de vue de la sécurité, l’enregistrement est une opération sensible. Vous établissez une connexion entre le Controller ou Cloud Connector et le VDA. Pour une telle opération délicate, le comportement attendu est le rejet de la connexion si toutes les conditions requises ne sont pas remplies. Vous établissez en fait deux canaux de communication distincts : VDA vers Controller ou Cloud Connector et Controller ou Cloud Connector vers VDA. La connexion utilise Kerberos, donc les problèmes de synchronisation de l’heure et d’appartenance de domaine bloqueront le processus. Kerberos utilise les noms principaux de service (SPN), donc vous ne pouvez pas utiliser d’adresse IP ou de nom d’hôte avec équilibrage de charge.
- Si un VDA ne dispose pas d’informations précises et à jour sur le Controller ou Cloud Connector lorsque vous ajoutez et supprimez des Controller ou Cloud Connector, le VDA peut rejeter les lancements de session qui sont négociés par un Controller ou Cloud Connector non répertorié. La présence d’entrées non valides peut retarder le démarrage du logiciel système du bureau virtuel. Un VDA n’accepte pas de connexion à partir d’un Controller ou Cloud Connector inconnu et non fiable.
En plus de la ListofDDCs, la ListOfSIDs (ID de sécurité) indique les machines de ListofDDCs qui sont fiables. La liste ListofSIDs peut être utilisée pour réduire la charge sur Active Directory ou pour éviter des menaces de sécurité provenant d’un serveur DNS non fiable. Pour plus d’informations, consultez la section ListOfSIDs ci-dessous.
Si une liste ListofDDCs spécifie plusieurs Controller ou Cloud Connector, le VDA tente de s’y connecter aléatoirement. Dans un déploiement sur site, la liste ListofDDCs peut également contenir des groupes de Controller. Le VDA tente de se connecter à chaque Controller dans un groupe avant de passer à d’autres entrées dans la liste ListofDDCs.
Citrix Virtual Apps and Desktops teste automatiquement la connectivité avec les Controller ou Cloud Connector configurés lors de l’installation de VDA. Les erreurs sont affichées si un Controller ou Cloud Connector n’est pas accessible. Si vous ignorez un message d’avertissement indiquant qu’un Controller ou Cloud Connector ne peut pas être contacté (ou lorsque vous ne spécifiez pas d’adresses de Controller ou Cloud Connector au cours de l’installation de VDA), des messages de rappel sont envoyés.
Méthodes de configuration des adresses de Controller ou Cloud Connector
L’administrateur décide de la méthode de configuration à utiliser lorsque le VDA s’enregistre pour la première fois (enregistrement initial). Lors de l’enregistrement initial, un cache permanent est créé sur le VDA. Lors des enregistrements ultérieurs, le VDA récupère la liste de Controller ou Cloud Connector à partir de ce cache local, sauf si une modification de configuration est détectée.
La meilleure façon de récupérer cette liste lors des enregistrements ultérieurs consiste à utiliser la fonction de mise à jour automatique. Par défaut, la mise à jour automatique est activée. Pour plus d’informations, consultez Mise à jour automatique.
Il existe plusieurs méthodes de configuration des adresses de Controller ou Cloud Connector sur un VDA.
- Basée une stratégie (LGPO ou GPO)
- Basée sur le Registre (manuelle, préférences de stratégie de groupe ou GPP, spécifiée lors de l’installation de VDA)
- Basée sur l’unité d’organisation Active Directory (découverte d’unité d’organisation ancienne génération)
- Basée sur MCS (personality.ini)
Vous spécifiez la méthode d’enregistrement initial lorsque vous installez un VDA. (Si vous désactivez la mise à jour automatique, la méthode que vous sélectionnez lors de l’installation d’un VDA est également utilisée pour les enregistrements ultérieurs.)
Le graphique suivant montre la page Delivery Controller de l’Assistant d’installation de VDA.
Basée sur une stratégie (LGPO/GPO)
Citrix vous recommande d’utiliser un objet de stratégie de groupe (GPO) pour l’enregistrement initial de VDA. Cette méthode a la priorité la plus élevée. (Bien que la mise à jour automatique soit répertoriée comme priorité la plus élevée, la mise à jour automatique est utilisée uniquement après l’enregistrement initial). L’enregistrement basé sur une stratégie offre les avantages que représente l’utilisation de la stratégie de groupe pour la configuration en termes de centralisation.
Pour spécifier cette méthode, effectuez les deux étapes suivantes :
- Sur la page Delivery Controller dans l’assistant d’installation VDA, sélectionnez Le faire plus tard (avancé). L’assistant vous rappelle plusieurs fois de spécifier les adresses de Controller, même si vous ne les spécifiez pas lors de l’installation de VDA. (L’enregistrement VDA est particulièrement important.)
- Activez ou désactivez l’enregistrement de VDA basé sur une stratégie par le biais de la stratégie Citrix avec le paramètre
Virtual Delivery Agent Settings > Controllers. (Si la sécurité est votre priorité principale, utilisez le paramètreVirtual Delivery Agent Settings > Controller SIDs.)
Ce paramètre est stocké sous HKLM\Software\Policies\Citrix\VirtualDesktopAgent (ListOfDDCs).
Basé sur registre
Pour spécifier cette méthode, effectuez une des étapes suivantes :
- Sur la page Delivery Controller dans l’assistant d’installation VDA, sélectionnez Effectuer manuellement. Ensuite, entrez le nom de domaine complet d’un Controller installé, puis cliquez sur Ajouter. Si vous avez installé des Controller supplémentaires, ajoutez leurs adresses.
- Pour une installation de VDA par ligne de commande, utilisez l’option /controllers et spécifiez les noms de domaine complets des Controller ou Cloud Connector installés.
Ces informations sont stockées dans la valeur de Registre ListOfDDCs sous la clé de Registre HKLM\Software\Citrix\VirtualDesktopAgent ou HKLM\Software\Wow6432Node\Citrix\VirtualDesktopAgent.
Vous pouvez également configurer cette clé de Registre manuellement ou utiliser les préférences de stratégie de groupe (GPP). Cette méthode peut être préférable à la méthode basée sur la stratégie (par exemple, si vous souhaitez un traitement conditionnel de différents Controller ou Cloud Connector, tel que : utiliser XDC-001 pour les noms d’ordinateur qui commencent par XDW-001-).
Mettez à jour la clé de registre ListOfDDCs, qui répertorie les noms de domaine complets de tous les Controller ou Cloud Connector du site. (Cette clé est l’équivalent de l’unité d’organisation du site Active Directory.)
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfDDCs (REG_SZ)
Si l’emplacement de Registre HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent contient les clés ListOfDDCs et FarmGUID, ListOfDDCs est utilisé pour la découverte du Controller ou du Cloud Connector. FarmGUID est présent si une unité d’organisation du site a été spécifiée lors de l’installation du VDA. (Elle peut être utilisée dans les déploiements d’ancienne génération.)
Si vous le souhaitez, mettez à jour la clé de Registre ListOfSIDs (pour plus d’informations, consultez la section ListOfSIDs) :
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs (REG_SZ)
Rappel : si vous activez également l’enregistrement de VDA via une stratégie Citrix, cette configuration remplace les paramètres que vous spécifiez lors de l’installation de VDA, car il s’agit d’une méthode à priorité plus élevée.
Basée sur l’unité d’organisation Active Directory (ancienne génération)
Cette méthode est prise en charge principalement pour la rétrocompatibilité et n’est pas recommandée. Si vous l’utilisez toujours, Citrix suggère de changer de méthode.
Pour spécifier cette méthode, effectuez les deux étapes suivantes :
- Sur la page Delivery Controller dans l’assistant d’installation VDA, sélectionnez Choisir les emplacements d’Active Directory.
- Utilisez le script
Set-ADControllerDiscovery.ps1(disponible sur chaque Controller). Configurez également l’entrée de RegistreFarmGuidsur chaque VDA de manière à pointer vers l’unité d’organisation correcte. Ce paramètre peut être configuré à l’aide de la stratégie de groupe.
Pour plus amples informations, consultez la section Découverte basée sur unité d’organisation Active Directory.
Basée sur MCS
Si vous utilisez MCS pour provisionner des machines virtuelles, MCS configure la liste des Controller ou Cloud Connector. Cette fonctionnalité fonctionne avec la mise à jour automatique. Lors de la création du catalogue, MCS injecte la liste des Controller ou Cloud Connector dans le fichier Personality.ini lors du provisioning initial. La mise à jour automatique permet de conserver la liste à jour.
Pour spécifier cette méthode, sur la page Delivery Controller dans l’assistant d’installation VDA, sélectionnez Laisser Machine Creation Services effectuer ceci automatiquement.
Recommandations
Recommandations :
- Utilisez la méthode de stratégie de groupe pour l’enregistrement initial.
- Utilisez la mise à jour automatique (activée par défaut) pour garder votre liste de Controller à jour.
- Dans un déploiement multi-zone, utilisez la stratégie de groupe pour la configuration initiale (avec au moins deux Controller ou Cloud Connector). Pointez les VDA vers des Controller ou Cloud Connector locaux, dans leur zone. Utilisez la mise à jour automatique pour assurer leur mise à jour. La mise à jour automatique optimise automatiquement la liste
ListofDDCspour les VDA dans des zones satellite. -
Répertoriez plusieurs Delivery Controller sur la clé de registre
ListOfDDCs, séparés par un espace ou une virgule, pour éviter les problèmes d’enregistrement si un Controller n’est pas disponible. Par exemple :DDC7x.xd.local DDC7xHA.xd.local 32-bit: HKEY_LOCAL_MACHINE \Software\Citrix\VirtualDesktopAgent\ListOfDDCs HKEY_LOCAL_MACHINE \Software\Citrix\VirtualDesktopAgent\ListOfDDCs (REG_SZ) <!--NeedCopy--> - Assurez-vous que toutes les valeurs répertoriées sous
ListofDDCscorrespondent à un nom de domaine complet valide afin d’éviter les retards d’enregistrement au démarrage.
Mise à jour automatique
La mise à jour automatique (introduite dans XenApp et XenDesktop 7.6) est activée par défaut. Il s’agit de la méthode la plus efficace pour assurer la mise à jour de vos enregistrements de VDA. Bien que la mise à jour automatique ne soit pas utilisée pour l’enregistrement initial, le logiciel de mise à jour automatique télécharge et stocke la liste ListofDDCs dans un cache permanent sur le VDA lors de l’enregistrement initial. Ce processus est effectué pour chaque VDA. Le cache contient également des informations sur la stratégie de la machine, ce qui garantit que les paramètres de stratégie sont conservés après les redémarrages.
La mise à jour automatique est prise en charge lors de l’utilisation de MCS ou Citrix Provisioning pour provisionner des machines, sauf pour le cache côté serveur Citrix Provisioning. Le cache côté serveur n’est pas un scénario courant car il n’existe pas de stockage permanent pour le cache de mise à jour automatique.
Pour spécifier cette méthode :
- Activez ou désactivez la mise à jour automatique via une stratégie Citrix contenant le paramètre
Virtual Delivery Agent Settings > Enable auto update of Controllers. Ce paramètre est activé par défaut.
Fonctionnement
- Chaque fois qu’un VDA se réenregistre (par exemple, après un redémarrage de machine), le cache est mis à jour. Chaque Controller ou Cloud Connector vérifie également la base de données du site toutes les 90 minutes. Si un Controller ou Cloud Connector a été ajouté ou supprimé depuis la dernière vérification, ou si une modification de stratégie s’est produite qui affecte l’enregistrement du VDA, le Controller ou Cloud Connector envoie une liste actualisée vers les VDA enregistrés et le cache est mis à jour. Le VDA accepte les connexions provenant de tous les Controller ou Cloud Connector figurant dans la liste mise en cache le plus récemment.
- Si un VDA reçoit une liste qui ne comprend pas le Controller ou Cloud Connector auprès duquel il est enregistré (en d’autres termes, ce Controller ou Cloud Connector a été supprimé du site), le VDA s’enregistre de nouveau, en choisissant parmi les Controller ou Cloud Connector dans la liste
ListofDDCs.
Exemple :
- Un déploiement dispose de trois Controller : A B et C. Un VDA s’enregistre auprès du Controller B (qui a été spécifié lors de l’installation du VDA).
- Deux Controller (D et E) sont ajoutés au site plus tard. Dans les 90 minutes qui suivent, le VDA reçoit les listes mises à jour et accepte les connexions provenant des Controller A, B, C, D et E. (La charge ne sera pas répartie de manière égale sur tous les Controller tant que les VDA ne sont pas redémarrés.)
- Plus tard, le Controller B est déplacé vers un autre site. Dans les 90 minutes qui suivent, le VDA sur le site d’origine reçoit les listes mises à jour car un Controller a été modifié depuis la dernière vérification. Le VDA qui s’est enregistré initialement auprès du Controller B (qui ne figure plus sur la liste) se réenregistre en choisissant parmi les Controller disponibles dans la liste actuelle (A, C, D et E).
Dans un déploiement multi-zone, la mise à jour automatique dans une zone satellite commence par mettre automatiquement en cache tous les Controller locaux. Tous les Controller de la zone principale sont mis en cache dans un groupe de secours. Si aucun Controller local de la zone satellite n’est disponible, une tentative d’enregistrement avec les Controller de la zone principale est effectuée.
Comme illustré dans l’exemple suivant, le fichier de cache contient des noms d’hôte et une liste d’ID de sécurité (ListofSIDs). Le VDA n’interroge pas les SID, ce qui réduit la charge d’Active Directory.
Vous pouvez récupérer le fichier cache avec un appel WMI. Toutefois, il est stocké dans un emplacement lisible uniquement par le compte système.
Important :
Cette information est fournie uniquement à titre indicatif. NE MODIFIEZ PAS CE FICHIER. Toute modification de ce fichier ou dossier entraîne une configuration non prise en charge.
Get-WmiObject -Namespace “Root\Citrix\DesktopInformation” -Class “Citrix_VirtualDesktopInfo” -Property “PersistentDataLocation”
Si vous avez besoin de configurer manuellement la ListofSIDs pour des raisons de sécurité (et non à des fins de réduction de la charge d’Active Directory), vous ne pouvez pas utiliser la fonctionnalité de mise à jour automatique. Pour plus amples informations, consultez la section ListOfSIDs.
Exception à la priorité de mise à jour automatique
Bien que la mise à jour automatique ait généralement la priorité la plus élevée de toutes les méthodes d’enregistrement de VDA et remplace les paramètres des autres méthodes, il existe une exception. Les éléments NonAutoListOfDDCs dans le cache spécifient la méthode de configuration initiale de VDA. La mise à jour automatique contrôle ces informations. Si la méthode d’enregistrement initial est modifiée, le processus d’enregistrement ignore la mise à jour automatique et utilise parmi les méthodes configurées celle dont la priorité est la plus proche. Ce processus peut s’avérer utile lorsque vous déplacez un VDA vers un autre site (par exemple, lors d’une récupération d’urgence).
Considérations liées à la configuration
Regardez une configuration d’enregistrement VDA courante.
Regardez les étapes d’un enregistrement VDA.
Tenez compte des éléments suivants lors de la configuration d’éléments pouvant affecter l’enregistrement de VDA.
Adresses de Controller ou Cloud Connector
Quelle que soit la méthode que vous utilisez pour spécifier des Controller ou Cloud Connector, Citrix recommande d’utiliser une adresse de nom de domaine complet. Une adresse IP n’est pas considérée comme une configuration de confiance, car il est plus facile de compromettre une adresse IP qu’un enregistrement DNS. Si vous remplissez la liste ListofSIDs manuellement, vous pouvez utiliser une adresse IP dans une liste ListofDDCs. Cependant, un nom de domaine complet est toujours recommandé.
Équilibrage de charge
Comme indiqué précédemment, le VDA répartit automatiquement les connexions de manière équitable entre les Controller ou Cloud Connector dans la liste ListofDDCs. La fonctionnalité d’équilibrage de charge et de basculement est intégrée au protocole CBP (Citrix Brokering Protocol). Si vous spécifiez plusieurs Controller ou Cloud Connector dans votre configuration, l’enregistrement bascule automatiquement de l’un à l’autre, si nécessaire. Avec la mise à jour automatique, le basculement automatique se produit automatiquement pour tous les VDA.
Pour des raisons de sécurité, vous ne pouvez pas utiliser un équilibreur de charge réseau, tel que Citrix ADC. L’enregistrement de VDA utilise l’authentification mutuelle Kerberos, où le client (VDA) doit prouver son identité au service (Controller). Toutefois, le Controller ou Cloud Connector doit prouver son identité au VDA. Cela signifie que le VDA et le Controller ou Cloud Connector agissent en tant que serveur et client en même temps. Comme indiqué au début de cet article, il existe deux canaux de communications : VDA vers Controller/Cloud Connector et Controller/Cloud Connector vers VDA.
Un composant de ce processus est appelé Nom de service principal (SPN) ; il est stocké en tant que propriété dans un objet ordinateur Active Directory. Lorsque votre VDA se connecte à un Controller ou Cloud Connector, il doit spécifier avec « qui » il souhaite communiquer. Cette adresse est un SPN. Si vous utilisez une adresse IP d’équilibrage de charge, l’authentification Kerberos mutuelle reconnaît correctement que l’adresse IP n’appartient pas au Controller ou Cloud Connector attendu.
Pour plus d’informations, consultez :
La mise à jour automatique remplace CNAME
La fonctionnalité de mise à jour automatique remplace la fonction CNAME (alias DNS) des versions XenApp et XenDesktop antérieures à 7.x. La fonctionnalité CNAME est désactivée, à compter de XenApp et XenDesktop 7. Utilisez la mise à jour automatique au lieu de CNAME. (Si vous devez utiliser CNAME, consultez la section CTX137960. Pour que l’alias DNS fonctionne de manière cohérente, n’utilisez pas la mise à jour automatique et CNAME en même temps.)
Groupes de Controller/Cloud Connector
Dans certains scénarios, vous pouvez gérer les Controller ou Cloud Connector sous forme de groupes, avec un groupe préféré et l’autre groupe utilisé pour le basculement si tous les Controller/Cloud Connector échouent. N’oubliez pas que les Controller ou Cloud Connector sont sélectionnés de manière aléatoire dans la liste, par conséquent le regroupement peut vous aider à imposer l’utilisation de certains Controller.
Ces groupes sont destinés à être utilisés dans un seul site (et non dans plusieurs sites).
Pour spécifier des groupes de Controller/Cloud Connector, utilisez des parenthèses. Par exemple, avec quatre Controller (deux principaux et deux de sauvegarde), un regroupement peut être :
(XDC-001.cdz.lan XDC-002.cdz.lan) (XDC-003.cdz.lan XDC-004.cdz.lan)
Dans cet exemple, les Controller du premier groupe (001 et 002) sont traités en premier. S’ils échouent, les Controller du deuxième groupe (003 et 004) sont traités.
Pour XenDesktop 7.0 ou version ultérieure, vous devez effectuer une étape supplémentaire pour utiliser la fonctionnalité Groupes d’inscription (Registration Groups). Vous devez interdire la stratégie Activer la mise à jour automatique des Controller dans Citrix Studio.
ListOfSIDs
La liste de Controller qu’un VDA peut contacter pour l’enregistrement est la liste ListofDDCs. Un VDA doit également connaître les Controller à approuver ; les VDA ne font pas automatiquement confiance aux Controller de la liste ListofDDCs. La liste ListofSIDs (ID de sécurité) identifie les Controller de confiance. Les VDA tentent de s’enregistrer uniquement avec les Controller de confiance.
Dans la plupart des environnements, la liste ListofSIDs est générée automatiquement à partir de la liste ListofDDCs. Vous pouvez utiliser une trace CDF pour lire la ListofSIDs.
En général, il n’est pas nécessaire de modifier manuellement la ListofSIDs. Il existe toutefois des exceptions. Les deux premières exceptions ne sont plus valides, car des technologies plus récentes sont disponibles.
-
Séparer les rôles pour les Controller : avant que les zones soient introduites dans XenApp et XenDesktop 7.7, la
ListofSIDsétait configurée manuellement lorsqu’un sous-ensemble de Controller était utilisé pour l’enregistrement. Par exemple, si vous utilisiez XDC-001 et XDC-002 en tant que brokers XML, et XDC-003 et XDC-004 pour l’enregistrement de VDA, vous deviez spécifier tous les Controller dans la listeListofSIDset XDC-003 et XDC-004 dans la listeListofDDCs. Il ne s’agit pas d’une configuration typique ou recommandée. Ne l’utilisez pas dans des environnements plus récents. Utilisez plutôt les zones. -
Réduction de la charge d’Active Directory : avant que la fonctionnalité de mise à jour automatique ait été introduite dans XenApp et XenDesktop 7.6, la
ListofSIDsétait utilisée pour réduire la charge sur les contrôleurs de domaine. La résolution de noms DNS vers des SID pouvait être ignorée en prédéfinissant la listeListofSIDs. Toutefois, la fonctionnalité de mise à jour automatique supprime le besoin d’effectuer cette opération, car ce cache permanent contient les SID. Citrix recommande de toujours activer la fonctionnalité de mise à jour automatique. - Sécurité : dans certains environnements hautement sécurisés, les SID de Controller de confiance étaient configurés manuellement pour éviter les menaces de sécurité depuis un serveur DNS non fiable. Toutefois, si vous procédez ainsi, vous devez également désactiver la fonctionnalité de mise à jour automatique. Sinon, la configuration du cache permanent est utilisée.
Donc, à moins que vous ayez une bonne raison, ne modifiez pas la ListofSIDs.
Si vous devez modifier la liste ListofSIDs, créez une clé de Registre nommée ListOfSIDs (REG_SZ) sous HKLM\Software\Citrix\VirtualDesktopAgent. La valeur est une liste de SID de confiance, séparée par des espaces, s’il y en a plusieurs.
Dans l’exemple suivant, un Controller est utilisé pour l’enregistrement de VDA (ListofDDCs), mais deux Controller sont utilisés pour la négociation des connexions (liste OfSIDs).
Recherche de contrôleur lors de l’enregistrement du VDA
Lorsqu’un VDA tente de s’enregistrer, l’agent Broker effectue d’abord une recherche DNS dans le domaine local pour s’assurer que le contrôleur spécifié peut être atteint.
Si cette recherche initiale ne trouve pas le contrôleur, l’agent Broker peut lancer une requête de secours descendante dans AD. Cette requête recherche tous les domaines et se répète fréquemment. Si l’adresse du contrôleur n’est pas valide (par exemple, l’administrateur a entré un nom de domaine complet incorrect lors de l’installation du VDA), l’activité de cette requête peut potentiellement conduire à une condition de déni de service distribué (DDoS) sur le contrôleur de domaine.
La clé de registre suivante contrôle si l’agent Broker utilise la requête de secours descendante lorsqu’il ne peut pas localiser un contrôleur pendant la recherche initiale.
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent
- Nom :
DisableDdcWildcardNameLookup - Type :
DWORD - Valeur :
0(par défaut) ou toute valeur différente de zéro
Lorsque la valeur est définie sur 0, la recherche de secours est activée. Si la recherche initiale du contrôleur échoue, la recherche de secours descendante est lancée. Il s’agit du comportement par défaut. Toutefois, si elle est définie sur une valeur différente de zéro, la recherche de secours est désactivée. Si la recherche initiale du contrôleur échoue, la recherche de l’agent Broker cesse.
Résoudre les problèmes d’enregistrement de VDA
Comme indiqué précédemment, un VDA doit être enregistré auprès d’un Delivery Controller ou d’un Cloud Connector pour être pris en compte lors du lancement de sessions négociées. Des VDA non enregistrés peuvent entraîner une sous-utilisation des ressources disponibles. Il existe un certain nombre de raisons pour lesquelles un VDA peut ne pas être enregistré, un grand nombre d’entre elles pouvant être résolues par un administrateur. Studio offre des informations de dépannage dans l’Assistant de création de catalogue de machines, et après la création d’un groupe de mise à disposition.
-
Identification de problèmes lors de la création de catalogue de machines : dans l’assistant Créer un catalogue de machines, lorsque vous ajoutez des machines existantes, la liste des noms de compte d’ordinateur indique si chaque machine peut être ajoutée au catalogue. Placez le pointeur de la souris sur l’icône située en regard de chaque machine pour afficher un message informatif sur cette machine.
Si le message identifie une machine problématique, vous pouvez supprimer cette machine (à l’aide du bouton Supprimer) ou ajouter la machine. Par exemple, si un message indique qu’il est impossible d’obtenir des informations sur une machine (peut-être parce qu’elle n’a jamais été enregistrée), vous pouvez quand même choisir d’ajouter la machine.
Le niveau fonctionnel d’un catalogue détermine les fonctionnalités du produit qui sont disponibles pour les machines du catalogue. L’utilisation de fonctionnalités introduites dans les nouvelles versions de produit peut nécessiter un nouveau VDA. Définir un niveau fonctionnel met toutes les fonctionnalités introduites dans cette version (et les versions ultérieures, si le niveau fonctionnel ne change pas) à disposition des machines du catalogue. Toutefois, les machines de ce catalogue avec une version antérieure de VDA ne pourront pas s’enregistrer.
-
Identification de problèmes après la création de groupes de mise à disposition : une fois que vous avez créé un groupe de mise à disposition, Studio affiche davantage de détails sur les machines associées à ce groupe.
Le panneau de détails pour un groupe de mise à disposition indique le nombre de machines qui devraient être enregistrées, mais ne le sont pas. En d’autres termes, une ou plusieurs machines peuvent être sous tension et pas en mode de maintenance, mais pas enregistrées auprès d’un composant Controller. Lors de l’affichage d’une machine « non enregistrée », mais qui devrait l’être, l’onglet Dépannage dans le panneau Détails fournit des causes possibles et les actions correctives recommandées.
Plus d’informations sur le dépannage de l’enregistrement de VDA
-
Pour de plus amples informations sur les niveaux fonctionnels, consultez la section Versions VDA et niveaux fonctionnels.
-
Pour plus d’informations sur le dépannage de l’enregistrement de VDA, voir l’article CTX136668.
-
Vous pouvez également utiliser les analyses de l’état de santé Citrix pour résoudre les problèmes d’enregistrement de VDA et de lancement de session. Pour de plus amples informations, consultez la section À propos des contrôles d’intégrité.