Enregistrement du 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 du 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 effectivement 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 provenant 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 plus d’un Controller ou Cloud Connector, 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 lorsque vous installez 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.

Basé sur une stratégie (LGPO\GPO)

Citrix® recommande d’utiliser les GPO pour l’enregistrement initial du VDA. C’est la priorité la plus élevée. (Bien que la mise à jour automatique soit répertoriée comme 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 de 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 lors de l’installation du VDA. (L’enregistrement du VDA est si important.)
• 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ètre Virtual 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 contrôleur installé, puis cliquez sur Ajouter. Si vous avez installé d’autres contrôleurs, ajoutez leurs adresses.
• Pour une installation de VDA en ligne de commande, utilisez l’option /controllers et spécifiez les FQDN des contrôleurs 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 contrôleurs 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 contrôleurs 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 contrôleur ou du Cloud Connector. La clé FarmGUID est présente 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)

N’oubliez pas : si vous activez également l’enregistrement VDA basé sur une stratégie via une stratégie Citrix, celle-ci remplace 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é descendante 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, suivez les deux étapes suivantes :

• Sur la page Delivery Controller de l’assistant d’installation du VDA, sélectionnez Choisir les emplacements dans Active Directory.
• Utilisez le script Set-ADControllerDiscovery.ps1 (disponible sur chaque contrôleur). Configurez également l’entrée de registre FarmGuid sur 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). Pointez les VDA vers les contrôleurs ou les Cloud Connectors locaux à (dans) leur zone. Utilisez la mise à jour automatique pour les maintenir à jour. La mise à jour automatique optimise automatiquement le ListofDDCs pour les VDA des zones satellites.

• Répertoriez plus d’un contrôleur sur la clé de registre ListOfDDCs, séparés par un espace, 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 ListofDDCs correspondent à 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 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 Controller ou Cloud Connector vérifie également la base de données du site toutes les 90 minutes. Si un Controller ou un Cloud Connector a été ajouté ou supprimé depuis la dernière vérification, ou si un changement de stratégie affectant l’enregistrement du VDA s’est produit, le Controller 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 Controllers ou Cloud Connectors figurant dans sa liste mise en cache la plus récente.
• Si un VDA reçoit une liste qui n’inclut pas le Controller ou le Cloud Connector auprès duquel il est enregistré (en d’autres termes, si ce Controller ou Cloud Connector a été supprimé du site), le VDA se réenregistre, en choisissant parmi les Controllers ou Cloud Connectors de la ListofDDCs.

Exemple :

• Un déploiement comporte trois Controllers : A, B et C. Un VDA s’enregistre auprès du Controller B (qui a été spécifié lors de l’installation du VDA).
• Plus tard, deux Controllers (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 Controllers A, B, C, D et E. (La charge n’est pas répartie équitablement sur tous les Controllers tant que les VDA ne sont pas redémarrés.)
• Plus tard encore, le Controller 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 Controller depuis la dernière vérification. Le VDA qui s’était initialement enregistré auprès du Controller B (qui ne figure plus sur la liste) se réenregistre, en choisissant parmi les Controllers 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 Controllers locaux. Tous les Controllers de la zone principale sont mis en cache dans un groupe de sauvegarde. Si aucun Controller local n’est disponible dans la zone satellite, l’enregistrement est tenté avec les Controllers de la zone principale.

Comme le montre l’exemple suivant, le fichier cache contient des noms d’hôte et une liste d’ID de sécurité (ListofSIDs). Le VDA n’interroge pas les SID et réduit ainsi la charge d’Active Directory.

Vous pouvez récupérer le fichier cache avec un appel WMI. Cependant, il est stocké dans un emplacement lisible uniquement 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îne 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 d’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 éléments suivants lors de la configuration des éléments pouvant 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 manuellement le ListofSIDs, 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 du 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 :

• Introduction à Kerberos
• Authentification mutuelle à l’aide de Kerberos

La mise à jour automatique remplace le 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 du CNAME. (Si vous devez utiliser CNAME, consultez CTX137960. Pour que l’aliasing DNS fonctionne de manière cohérente, n’utilisez pas la mise à jour automatique et le 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 (pas 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 faire confiance, car les VDA ne font pas automatiquement confiance aux Controllers dans le ListofDDCs. Les ListofSIDs (identifiants de sécurité) identifient les Controllers de confiance. Les VDA tentent de s’enregistrer uniquement auprès des Controllers de confiance.

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 était utilisé pour l’enregistrement. Par exemple, si vous utilisiez XDC-001 et XDC-002 comme courtiers XML, et XDC-003 et XDC-004 pour l’enregistrement VDA, vous spécifiiez tous les contrôleurs dans le ListofSIDs, et XDC-003 et XDC-004 dans le ListofDDCs. 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 d’Active Directory : Avant l’introduction de la fonctionnalité 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 le ListofSIDs, la résolution des noms DNS en SID peut être ignorée. Cependant, la fonctionnalité de mise à jour automatique élimine la nécessité de ce travail, car ce cache persistant contient des SID. Citrix recommande de maintenir la fonctionnalité 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 fonctionnalité de mise à jour automatique. Sinon, la configuration d’un cache persistant est utilisée.

Ainsi, à moins d’avoir 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 courtage (List OfSIDs).

Recherche de contrôleur lors de l’enregistrement VDA

Lorsqu’un VDA tente de s’enregistrer, l’agent de courtage effectue d’abord une recherche DNS dans le domaine local pour s’assurer que le contrôleur spécifié est accessible.

Si cette recherche initiale ne trouve pas le contrôleur, l’agent de courtage 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 entré 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 courtage 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 une clé de registre n’est pas 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 ignore les valeurs qu’elle ne reconnaît pas comme valides.

Dépanner 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 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 la supprimer (à 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 les 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 doivent ê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.

Informations supplémentaires 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é.