Enregistrement VDA
Introduction
Remarque :
Dans un environnement sur site, les VDA s’enregistrent auprès d’un Delivery Controller. Dans un environnement de service Citrix Cloud, les VDA s’enregistrent auprès d’un Cloud Connector. Dans un environnement hybride, certains VDA s’enregistrent auprès d’un Delivery Controller tandis que d’autres s’enregistrent 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 plusieurs Controllers ou Cloud Connectors sur le site. Le VDA trouve un Controller ou un Connector en vérifiant une liste appelée ListofDDCs. Le ListOfDDCs sur un VDA contient des entrées DNS qui dirigent ce VDA vers les Controllers ou Cloud Connectors sur le site. Pour l’équilibrage de charge, le VDA distribue automatiquement les connexions entre tous les Controllers ou Cloud Connectors de la liste.
Pourquoi l’enregistrement 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 le Cloud Connector et le VDA. Pour une opération aussi sensible, le comportement attendu est de rejeter la connexion si tout n’est pas en parfait état. 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, de sorte que les problèmes de synchronisation horaire et d’appartenance au domaine sont impardonnables. Kerberos utilise des noms de principal de service (SPN), vous ne pouvez donc pas utiliser d’IP\nom d’hôte équilibré en charge.
- Si un VDA ne dispose pas d’informations précises et à jour sur les Controllers ou Cloud Connectors lorsque vous ajoutez et supprimez des Controllers (ou Cloud Connectors), le VDA peut rejeter les lancements de session qui sont gérés par un Controller ou Cloud Connector non répertorié. Des entrées non valides peuvent retarder le démarrage du logiciel système du bureau virtuel. Un VDA n’acceptera pas une connexion d’un Controller ou Cloud Connector inconnu et non fiable.
En plus du ListofDDCs, le ListOfSIDs (ID de sécurité) indique quelles machines du ListofDDCs sont fiables. Le ListofSIDs peut être utilisé pour réduire la charge sur Active Directory ou pour éviter d’éventuelles menaces de sécurité provenant d’un serveur DNS compromis. Pour plus d’informations, consultez ListOfSIDs.
Si un ListofDDCs spécifie plusieurs Controllers ou Cloud Connectors, le VDA tente de s’y connecter dans un ordre aléatoire. Dans un déploiement sur site, le ListofDDCs peut également contenir des groupes de Controllers. Le VDA tente de se connecter à chaque Controller d’un groupe avant de passer aux autres entrées du ListofDDCs.
Citrix Virtual Apps and Desktops™ teste automatiquement la connectivité aux Controllers ou Cloud Connectors configurés lors de l’installation du VDA. Des erreurs s’affichent si un Controller ou un Cloud Connector est inaccessible. Si vous ignorez un avertissement indiquant qu’un Controller ou un Cloud Connector ne peut pas être contacté (ou si vous ne spécifiez pas d’adresses de Controller ou de Cloud Connector lors de l’installation du VDA), des messages vous le rappellent.
Méthodes de configuration des adresses de Controller ou de Cloud Connector
L’administrateur choisit la méthode de configuration à utiliser lorsque le VDA s’enregistre pour la première fois (l’enregistrement initial). Lors de l’enregistrement initial, un cache persistant est créé sur le VDA. Lors des enregistrements ultérieurs, le VDA récupère la liste des Controllers ou Cloud Connectors à partir de ce cache local, sauf si un changement de configuration est détecté.
Le moyen le plus simple de récupérer cette liste lors des enregistrements ultérieurs est d’utiliser la fonction de mise à jour automatique. La mise à jour automatique est activée par défaut. Pour plus d’informations, consultez Mise à jour automatique.
Il existe plusieurs méthodes pour configurer les adresses de Controller ou de Cloud Connector sur un VDA.
- Basé sur une stratégie (LGPO ou GPO)
- Basé sur le registre (manuel, Group Policy Preferences (GPP), spécifié lors de l’installation du VDA)
- Basé sur l’unité d’organisation (OU) d’Active Directory (découverte d’OU héritée)
- Basé sur MCS (personality.ini)
Vous spécifiez la méthode d’enregistrement initiale lors de l’installation d’un VDA. (Si vous désactivez la mise à jour automatique, la méthode que vous sélectionnez lors de l’installation du VDA est utilisée pour les enregistrements ultérieurs.)
Le graphique suivant montre la page Delivery Controller de l’assistant d’installation du VDA.
Page Delivery Controller dans l’assistant d’installation du VDA(/fr-fr/citrix-virtual-apps-desktops/2311/media/vda-install-controllers-all.png)
Basé sur une stratégie (LGPO\GPO)
Citrix® recommande d’utiliser une GPO pour l’enregistrement initial du VDA. Elle a la priorité la plus élevée. (Bien que la mise à jour automatique soit répertoriée comme ayant la priorité la plus élevée, elle n’est utilisée qu’après l’enregistrement initial.) L’enregistrement basé sur une stratégie offre les avantages de centralisation liés à l’utilisation de la stratégie de groupe pour la configuration.
Pour spécifier cette méthode, suivez les deux étapes suivantes :
- Sur la page Delivery Controller de l’assistant d’installation du VDA, sélectionnez Faire plus tard (avancé). L’assistant vous rappelle plusieurs fois de spécifier les adresses des Controller, même si vous ne les spécifiez pas pendant l’installation du VDA. (L’enregistrement du VDA est d’une telle importance.)
- Activez ou désactivez l’enregistrement VDA basé sur une stratégie via la stratégie Citrix avec le paramètre
Virtual Delivery Agent Settings > Controllers. (Si la sécurité est votre priorité absolue, utilisez le paramètreVirtual Delivery Agent Settings > Controller SIDs.)
Ce paramètre est stocké sous HKLM\Software\Policies\Citrix\VirtualDesktopAgent (ListOfDDCs).
Basé sur le registre
Pour spécifier cette méthode, suivez l’une des étapes suivantes :
- Sur la page Delivery Controller de l’assistant d’installation du VDA, sélectionnez Le faire manuellement. Ensuite, entrez le FQDN d’un Controller installé, puis cliquez sur Ajouter. Si vous avez installé d’autres Controllers, ajoutez leurs adresses.
- Pour une installation de VDA en ligne de commande, utilisez l’option /controllers et spécifiez les FQDN des Controllers ou Cloud Connectors 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 une stratégie (par exemple, si vous souhaitez un traitement conditionnel de différents Controllers ou Cloud Connectors, tel que : utiliser XDC-001 pour les noms d’ordinateurs commençant par XDW-001-).
Mettez à jour la clé de registre ListOfDDCs, qui répertorie les FQDN de tous les Controllers ou Cloud Connectors 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 à la fois 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 de site a été spécifiée lors de l’installation du VDA. (Cela peut être utilisé dans les déploiements hérités.)
Vous pouvez éventuellement mettre à jour la clé de registre ListOfSIDs (pour plus d’informations, consultez ListOfSIDs :
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs (REG_SZ)
Rappel : Si vous activez également l’enregistrement VDA basé sur une stratégie via la stratégie Citrix, cela annule les paramètres que vous spécifiez lors de l’installation du VDA, car il s’agit d’une méthode de priorité plus élevée.
Basé sur l’unité d’organisation Active Directory (hérité)
Cette méthode est principalement prise en charge pour la compatibilité ascendante et n’est pas recommandée. Si vous l’utilisez toujours, Citrix suggère de passer à une autre méthode.
Pour spécifier cette méthode, effectuez les deux étapes suivantes :
- Sur la page Delivery Controller de l’assistant d’installation du VDA, sélectionnez Choisir les emplacements depuis Active Directory.
- Utilisez le script
Set-ADControllerDiscovery.ps1(disponible sur chaque Controller). Configurez également l’entrée de registreFarmGuidsur chaque VDA pour qu’elle pointe vers la bonne unité d’organisation. Ce paramètre peut être configuré à l’aide de la stratégie de groupe.
Basé sur MCS
Si vous utilisez MCS pour provisionner des machines virtuelles, MCS configure la liste des contrôleurs ou des Cloud Connectors. Cette fonctionnalité fonctionne avec la mise à jour automatique. Lors de la création du catalogue, MCS injecte la liste des contrôleurs ou des Cloud Connectors dans le fichier Personality.ini lors du provisionnement initial. La mise à jour automatique maintient la liste à jour.
Pour spécifier cette méthode, sur la page Delivery Controller de l’assistant d’installation du VDA, sélectionnez Laisser Machine Creation Services™ le faire.
Examen et recommandations
Bonnes pratiques :
- Utilisez la méthode d’enregistrement par stratégie de groupe pour l’enregistrement initial.
- Utilisez la mise à jour automatique (activée par défaut) pour maintenir votre liste de contrôleurs à jour.
- Dans un déploiement multi-zones, utilisez la stratégie de groupe pour la configuration initiale (avec au moins deux contrôleurs ou Cloud Connectors). Dirigez les VDA vers les contrôleurs ou Cloud Connectors locaux (dans) leur zone. Utilisez la mise à jour automatique pour les maintenir à jour. La mise à jour automatique optimise automatiquement le
ListofDDCspour les VDA dans les zones satellites. -
Répertoriez plus d’un contrôleur sur la clé de registre
ListOfDDCs, séparés par un espace ou une virgule, afin d’éviter les problèmes d’enregistrement si un contrôleur 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. C’est la méthode la plus efficace pour maintenir vos enregistrements VDA à jour. Bien qu’il ne soit pas utilisé pour l’enregistrement initial, le logiciel de mise à jour automatique télécharge et stocke le ListofDDCs dans un cache persistant sur le VDA lors de l’enregistrement initial. Ce processus est effectué pour chaque VDA. Le cache contient également des informations de stratégie de 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 de Citrix Provisioning™ pour provisionner des machines, à l’exception du cache côté serveur de Citrix Provisioning. Le cache côté serveur n’est pas un scénario courant car il n’y a pas de stockage persistant 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.
Comment ça marche :
- Chaque fois qu’un VDA se réenregistre (par exemple, après le redémarrage d’une machine), le cache est mis à jour. Chaque contrôleur ou Cloud Connector vérifie également la base de données du site toutes les 90 minutes. Si un contrôleur ou un Cloud Connector a été ajouté ou supprimé depuis la dernière vérification, ou si un changement de stratégie s’est produit qui affecte l’enregistrement du VDA, le contrôleur ou le Cloud Connector envoie une liste mise à jour à ses VDA enregistrés et le cache est mis à jour. Le VDA accepte les connexions de tous les contrôleurs ou Cloud Connectors figurant dans sa liste la plus récemment mise en cache.
- Si un VDA reçoit une liste qui n’inclut pas le contrôleur ou le Cloud Connector auprès duquel il est enregistré (en d’autres termes, ce contrôleur ou Cloud Connector a été supprimé du site), le VDA se réenregistre, en choisissant parmi les contrôleurs ou Cloud Connectors figurant dans la
ListofDDCs.
Exemple :
- Un déploiement comporte trois contrôleurs : A, B et C. Un VDA s’enregistre auprès du contrôleur B (qui a été spécifié lors de l’installation du VDA).
- Plus tard, deux contrôleurs (D et E) sont ajoutés au site. Dans les 90 minutes, les VDA reçoivent des listes mises à jour et acceptent ensuite les connexions des contrôleurs A, B, C, D et E. (La charge n’est pas répartie équitablement sur tous les contrôleurs tant que les VDA ne sont pas redémarrés.)
- Plus tard encore, le contrôleur B est déplacé vers un autre site. Dans les 90 minutes, les VDA du site d’origine reçoivent des listes mises à jour car il y a eu un changement de contrôleur depuis la dernière vérification. Le VDA qui s’était initialement enregistré auprès du contrôleur B (qui ne figure plus sur la liste) se réenregistre, en choisissant parmi les contrôleurs de la liste actuelle (A, C, D et E).
Dans un déploiement multi-zones, la mise à jour automatique dans une zone satellite met d’abord en cache tous les contrôleurs locaux. Tous les contrôleurs de la zone principale sont mis en cache dans un groupe de sauvegarde. Si aucun contrôleur local n’est disponible dans la zone satellite, l’enregistrement est tenté avec les contrôleurs de la zone principale.
Comme le montre l’exemple suivant, le fichier cache contient des noms d’hôte et une liste d’identificateurs de sécurité (ListofSIDs). Le VDA n’interroge pas les SID, ce qui réduit la charge sur Active Directory.
Vous pouvez récupérer le fichier cache avec un appel WMI. Cependant, il est stocké dans un emplacement qui n’est lisible que par le compte SYSTEM.
Important :
Ces informations sont fournies à titre indicatif uniquement. NE MODIFIEZ PAS CE FICHIER. Toute modification de ce fichier ou de ce dossier entraînera une configuration non prise en charge.
Get-WmiObject -Namespace "Root\Citrix\DesktopInformation" -Class "Citrix_VirtualDesktopInfo" -Property "PersistentDataLocation"
Si vous devez configurer manuellement le ListofSIDs pour des raisons de sécurité (par opposition à la réduction de la charge Active Directory), vous ne pouvez pas utiliser la fonction de mise à jour automatique. Pour plus de détails, consultez ListOfSIDs.
Exception à la priorité de mise à jour automatique
Bien que la mise à jour automatique ait généralement la priorité la plus élevée parmi toutes les méthodes d’enregistrement de VDA et qu’elle 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 du VDA. La mise à jour automatique surveille ces informations. Si la méthode d’enregistrement initiale change, le processus d’enregistrement ignore la mise à jour automatique et utilise la méthode de priorité configurée suivante la plus élevée. Ce processus peut être utile lorsque vous déplacez un VDA vers un autre site (par exemple, lors d’une reprise après sinistre).
Considérations relatives à la configuration
Afficher une configuration d’enregistrement VDA courante.
Afficher les étapes d’enregistrement VDA.
Tenez compte des points suivants lors de la configuration des éléments susceptibles d’affecter l’enregistrement VDA.
Adresses du Controller ou du Cloud Connector
Quelle que soit la méthode que vous utilisez pour spécifier les Controllers ou les Cloud Connectors, Citrix recommande d’utiliser une adresse FQDN. Une adresse IP n’est pas considérée comme une configuration fiable, car il est plus facile de compromettre une IP qu’un enregistrement DNS. Si vous renseignez ListofSIDs manuellement, vous pouvez utiliser une adresse IP dans un ListofDDCs. Cependant, le FQDN est toujours recommandé.
Équilibrage de charge
Comme indiqué précédemment, le VDA distribue automatiquement les connexions entre tous les Controllers ou Cloud Connectors dans le ListofDDCs. La fonctionnalité de basculement et d’équilibrage de charge est intégrée au protocole de courtage Citrix (CBP). Si vous spécifiez plusieurs Controllers ou Cloud Connectors dans votre configuration, l’enregistrement bascule automatiquement entre eux, 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 d’équilibreur de charge réseau, tel que Citrix ADC. L’enregistrement VDA utilise l’authentification mutuelle Kerberos, où le client (VDA) doit prouver son identité au service (Controller). Cependant, le Controller ou le Cloud Connector doit prouver son identité au VDA. Cela signifie que le VDA et le Controller ou le Cloud Connector agissent simultanément comme serveur et client. Comme indiqué au début de cet article, il existe deux canaux de communication : VDA vers Controller/Cloud Connector et Controller/Cloud Connector vers VDA.
Un composant de ce processus est appelé Service Principal Name (SPN), qui est stocké en tant que propriété dans un objet ordinateur Active Directory. Lorsque votre VDA se connecte à un Controller ou à un Cloud Connector, il doit spécifier avec qui il souhaite communiquer. Cette adresse est un SPN. Si vous utilisez une adresse IP équilibrée en charge, l’authentification mutuelle Kerberos reconnaît correctement que l’adresse IP n’appartient pas au Controller ou au 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 de XenApp et XenDesktop antérieures à 7.x. La fonctionnalité CNAME est désactivée à partir de XenApp et XenDesktop 7. Utilisez la mise à jour automatique au lieu de CNAME. (Si vous devez utiliser CNAME, consultez 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 souhaiter traiter les Controllers ou les Cloud Connectors par groupes, un groupe étant préféré et l’autre groupe étant utilisé pour un basculement si tous les Controllers/Cloud Connectors échouent. N’oubliez pas que les Controllers ou les Cloud Connectors sont sélectionnés de manière aléatoire dans la liste, de sorte que le regroupement peut aider à imposer une utilisation préférentielle.
Ces groupes sont destinés à être utilisés au sein d’un seul site (et non de plusieurs sites).
Utilisez des parenthèses pour spécifier des groupes de Controllers/Cloud Connectors. Par exemple, avec quatre Controllers (deux principaux et deux de sauvegarde), un regroupement pourrait être :
(XDC-001.cdz.lan XDC-002.cdz.lan) (XDC-003.cdz.lan XDC-004.cdz.lan)
Dans cet exemple, les Controllers du premier groupe (001 et 002) sont traités en premier. Si les deux échouent, les Controllers du second groupe (003 et 004) sont traités.
Pour XenDesktop 7.0 ou version ultérieure, une étape supplémentaire est nécessaire pour utiliser la fonctionnalité Groupes d’enregistrement. Vous devez interdire la stratégie Activer la mise à jour automatique du Controller depuis Studio.
ListOfSIDs
La liste des Controllers qu’un VDA peut contacter pour l’enregistrement est le ListofDDCs. Un VDA doit également savoir quels Controllers approuver ; les VDA n’approuvent pas automatiquement les Controllers du ListofDDCs. Les ListofSIDs (identifiants de sécurité) identifient les Controllers approuvés. Les VDA tentent de s’enregistrer uniquement auprès des Controllers approuvés.
Dans la plupart des environnements, le ListofSIDs est généré automatiquement à partir du ListofDDCs. Vous pouvez utiliser une trace CDF pour lire le ListofSIDs.
Généralement, il n’est pas nécessaire de modifier manuellement le ListofSIDs. Il existe plusieurs exceptions. Les deux premières exceptions ne sont plus valides car de nouvelles technologies sont disponibles.
-
Rôles distincts pour les contrôleurs : Avant l’introduction des zones dans XenApp et XenDesktop 7.7, le
ListofSIDsétait configuré manuellement lorsqu’un sous-ensemble de contrôleurs seulement était utilisé pour l’enregistrement. Par exemple, si vous utilisiez XDC-001 et XDC-002 comme brokers XML, et XDC-003 et XDC-004 pour l’enregistrement VDA, vous spécifiiez tous les contrôleurs dans leListofSIDs, et XDC-003 et XDC-004 dans leListofDDCs. Ce n’est pas une configuration typique ou recommandée. Ne l’utilisez pas dans les environnements plus récents. Utilisez plutôt des zones. -
Réduction de la charge Active Directory : Avant l’introduction de la fonction de mise à jour automatique dans XenApp et XenDesktop 7.6, le
ListofSIDsétait utilisé pour réduire la charge sur les contrôleurs de domaine. En pré-remplissant leListofSIDs, la résolution des noms DNS en SID peut être ignorée. Cependant, la fonction de mise à jour automatique supprime la nécessité de ce travail, car ce cache persistant contient des SID. Citrix recommande de laisser la fonction de mise à jour automatique activée. - Sécurité : Dans certains environnements hautement sécurisés, les SID des contrôleurs approuvés étaient configurés manuellement pour éviter d’éventuelles menaces de sécurité provenant d’un serveur DNS compromis. Cependant, si vous faites cela, vous devez également désactiver la fonction de mise à jour automatique. Sinon, la configuration du cache persistant est utilisée.
Ainsi, sauf si vous avez une raison spécifique, ne modifiez pas le ListofSIDs.
Si vous devez modifier le ListofSIDs, créez une clé de registre nommée ListOfSIDs (REG_SZ) sous HKLM\Software\Citrix\VirtualDesktopAgent. La valeur est une liste de SID approuvés, séparés par des espaces si vous en avez plusieurs.
Dans l’exemple suivant, un contrôleur est utilisé pour l’enregistrement VDA (ListofDDCs), mais deux contrôleurs sont utilisés pour le brokering (ListOfSIDs).
Recherche de contrôleur lors de l’enregistrement VDA
Lorsqu’un VDA tente de s’enregistrer, l’agent de 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 de 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 est invalide (par exemple, l’administrateur a saisi un FQDN incorrect lors de l’installation du VDA), l’activité de cette requête peut potentiellement entraîner 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 de broker utilise la requête de secours descendante lorsqu’il ne peut pas localiser un contrôleur lors de la recherche initiale.
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent
- Nom :
DisableDdcWildcardNameLookup - Type :
DWORD - Valeur :
0(par défaut) ou toute valeur non nulle
Lorsque défini 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. C’est le comportement par défaut. Cependant, si défini sur une valeur non nulle, la recherche de secours est désactivée. Si la recherche initiale du contrôleur échoue, l’agent de courtier cesse de chercher.
Séquencement de la liaison LDAP lors de l’enregistrement du VDA à l’aide d’un contrôleur de domaine en lecture seule
Lorsqu’un VDA s’enregistre auprès d’un contrôleur de domaine en lecture seule (RODC), l’agent de courtier doit sélectionner la ou les liaisons LDAP (Light Directory Access Protocol) à ignorer. Pour effectuer cette sélection, l’agent de courtier nécessite une clé de registre appropriée.
Si aucune clé de registre n’est fournie, ou si le champ de la clé de registre est vide, l’enregistrement du VDA auprès du RODC prend plus de temps car il doit passer par la séquence de liaison LDAP d’origine.
Pour modifier la séquence de liaison LDAP, la clé de registre ListofIgnoredBindings a été ajoutée à HKEY_LOCAL_MACHINE\Software\Policies\Citrix\VirtualDesktopAgent. L’utilisation de ListofIgnoredBindings vous permet de modifier la séquence de liaison LDAP si nécessaire, et ainsi d’accélérer l’enregistrement du VDA auprès d’un RODC.
- Nom :
ListofIgnoredBindings - Type :
REG_SZ - Valeurs :
DefaultPath,DomainPath,PDCPath
La valeur est une liste d’options de chemin de liaison, chacune séparée par une virgule. La clé de registre ignorera toute valeur qu’elle ne reconnaît pas comme valide.
Dépanner les problèmes d’enregistrement du 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 intermédiées. Les VDA non enregistrés peuvent entraîner une sous-utilisation des ressources autrement disponibles. Il existe diverses raisons pour lesquelles un VDA pourrait ne pas être enregistré, dont beaucoup peuvent être dépannées par un administrateur. Studio fournit des informations de dépannage dans l’assistant de création de catalogue et après la création d’un groupe de mise à disposition.
-
Identification des problèmes lors de la création du catalogue de machines : Dans l’assistant de création de catalogue, après avoir ajouté des machines existantes, la liste des noms de comptes d’ordinateur indique si chaque machine est appropriée pour être ajoutée au catalogue. Passez la souris sur l’icône à côté de chaque machine pour afficher un message informatif sur cette machine.
Si le message identifie une machine problématique, vous pouvez soit supprimer cette machine (à l’aide du bouton Supprimer), soit l’ajouter. Par exemple, si un message indique que des informations n’ont pas été obtenues sur une machine (peut-être parce qu’elle ne s’était jamais enregistrée), vous pouvez choisir d’ajouter la machine quand même.
Le niveau fonctionnel d’un catalogue contrôle les fonctionnalités du produit disponibles pour les machines du catalogue. L’utilisation de fonctionnalités introduites dans de nouvelles versions du produit peut nécessiter un nouveau VDA. La définition d’un niveau fonctionnel rend toutes les fonctionnalités introduites dans cette version (et ultérieures, si le niveau fonctionnel ne change pas) disponibles pour les machines du catalogue. Cependant, les machines de ce catalogue avec une version de VDA antérieure ne pourront pas s’enregistrer.
-
Identification des problèmes après la création de groupes de mise à disposition : Après avoir créé un groupe de mise à disposition, Studio affiche les détails des machines associées à ce groupe.
Le volet de détails d’un groupe de mise à disposition indique le nombre de machines qui devraient être enregistrées mais ne le sont pas. En d’autres termes, il peut y avoir une ou plusieurs machines qui sont sous tension et non en mode maintenance, mais qui ne sont pas actuellement enregistrées auprès d’un contrôleur. Lorsque vous consultez une machine « non enregistrée, mais qui devrait l’être », examinez l’onglet Dépannage dans le volet de détails pour connaître les causes possibles et les actions correctives recommandées.
Plus d’informations sur le dépannage de l’enregistrement VDA
-
Pour plus d’informations sur les niveaux fonctionnels, consultez Versions VDA et niveaux fonctionnels.
-
Pour plus d’informations sur le dépannage de l’enregistrement VDA, consultez CTX136668.
-
Vous pouvez également utiliser les vérifications d’intégrité de Citrix Scout pour dépanner l’enregistrement VDA et le lancement de session. Pour plus de détails, consultez À propos des vérifications d’intégrité.
Dans cet article
- Introduction
- Méthodes de configuration des adresses de Controller ou de Cloud Connector
- Mise à jour automatique
- Considérations relatives à la configuration
- ListOfSIDs
- Recherche de contrôleur lors de l’enregistrement VDA
- Séquencement de la liaison LDAP lors de l’enregistrement du VDA à l’aide d’un contrôleur de domaine en lecture seule
- Dépanner les problèmes d’enregistrement du VDA