Product Documentation

Delivery Controller

Jun 20, 2017

Le Delivery Controller est le composant côté serveur qui est responsable de la gestion de l'accès utilisateur, ainsi que de la négociation et de l'optimisation des connexions. Les Controller fournissent également les services Machine Creation qui créent des images de bureau et de serveur.

Un site doit avoir au moins un Controller. Après avoir installé le Controller initial, vous pouvez ajouter des Controller supplémentaires lorsque vous créez un site, ou plus tard. Avoir plus d'un Controller dans un site présente deux avantages.

  • Redondance : Il est recommandé qu'un site de production doive toujours disposer d'au moins deux Controller sur des serveurs physiques différents. Si un Controller échoue, les autres peuvent gérer les connexions et administrer le site.
  • Évolutivité : au fur et à mesure que l'activité du site augmente, il en va de même pour l'utilisation de l'UC sur le Controller et l'activité de la base de données. Les Controller supplémentaires permettent de gérer plus d'utilisateurs et plus de demandes d'applications et de bureaux, et peuvent améliorer la réactivité générale.

Chaque Controller communique directement avec la base de données du site. Dans un site avec plusieurs zones, les Controller de chaque zone communiquent avec la base de données du site dans la zone principale.

Conseil : ne modifiez pas le nom de l'ordinateur ou l'appartenance à un domaine d'un Controller une fois que le site est configuré.

Comment les VDA découvrent les Controller

Avant qu'un VDA puisse être utilisé, il doit s'enregistrer (établir la communication) auprès d'un Controller sur le site. Le VDA trouve un Controller en vérifiant une liste de Controller appelée ListofDDCs. La liste ListOfDDCs se compose d'une ou plusieurs entrées DNS ou adresses IP qui pointent le VDA vers des Controller sur le site. Pour assurer l'équilibrage de charge, le VDA répartit automatiquement les connexions de manière équitable entre les Controller dans la liste.

En plus de la liste ListOfDDCs, ListOfSIDs indique les ID de sécurité (SID) de machine qui sont autorisés à contacter le VDA en tant que Controller. 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.

Il est important de s'assurer que les listes ListOfSIDs et ListOfDDCs sur tous les VDA contiennent des informations à jour à mesure que des Controller sont ajoutés et supprimés dans le site. Si les listes ne sont pas mises à jour, un VDA risque de rejeter les sessions qui ont été négociées par un Controller non répertorié. La présence d'entrées non valides peut retarder le démarrage du logiciel système du bureau virtuel. Pour conserver les listes à jour, vous pouvez :

  • Utiliser la fonctionnalité de mise à jour automatique, qui met automatiquement à jour les listes ListOfDDCs et ListOfSIDs à mesure que des Controller sont ajoutés ou supprimés. Par défaut, la mise à jour automatique est activée.
  • Auto gérer : c'est-à-dire mettre à jour manuellement les paramètres de stratégie ou de registre qui identifient les Controller.

Les informations contenues dans les listes ListOfDDCs et ListOfSIDs peuvent provenir de plusieurs endroits dans un déploiement. Le VDA vérifie les emplacements suivants, dans l'ordre, et stoppe au premier dans lequel il trouve les listes :

  1. Un emplacement de stockage persistant dont la maintenance est assurée pour la fonctionnalité de mise à jour automatique. Cet emplacement contient des informations sur le Controller lorsque la fonctionnalité de mise à jour automatique est activée et après que le VDA s'enregistre avec succès pour la première fois après l'installation. (Ce stockage contient également des informations sur la stratégie de machine, ce qui garantit que les paramètres de stratégie sont conservés après les redémarrages). Pour son enregistrement initial après l'installation, ou lorsque la mise à jour automatique est désactivée, le VDA vérifie les emplacements suivants.
  2. Les paramètres de stratégie (Controller, SID de Controller).
  3. Les informations sur le Controller sous la clé Virtual Desktop Agent dans le Registre. Le programme d'installation de VDA renseigne initialement ces valeurs, en fonction des informations sur le Controller que vous spécifiez lors de l'installation du VDA.
  4. Découverte de Controller basée sur l'unité d'organisation. Ceci est une méthode héritée conservée pour des raisons de rétrocompatibilité.
  5. Le fichier Personality.ini créé par Machine Creation Services.

Si une liste ListOfDDCs spécifie plusieurs Controller, le VDA tente de s'y connecter aléatoirement. La liste ListOfDDCs peut également contenir des groupes de Controller, qui sont désignés par des crochets entourant deux ou plusieurs entrées de Controller. Le VDA tente de se connecter à chaque Controller dans un groupe avant de passer à d'autres entrées dans la liste ListOfDDCs.

Pour les utilisateurs XenDesktop qui ont été mis à niveau à partir de versions antérieures à la version 7.0, la fonctionnalité de mise à jour automatique remplace la fonction CNAME à partir de la version antérieure. Vous pouvez réactiver manuellement la fonction CNAME, si désiré ; cependant, pour que l'alias DNS fonctionne de manière cohérente, vous ne pouvez pas utiliser la fonctionnalité de mise à jour automatique et la fonction CNAME en même temps. Consultez l'article CTX137960 pour plus d'informations sur la réactivation de la fonctionnalité CNAME.

Consultez l'article Zones pour de plus amples informations sur l'emplacement où le VDA tente de s'enregistrer dans un site qui dispose de plusieurs zones.

Considérations à prendre en compte lors du choix de la mise à jour automatique ou de l'auto-gestion

Le paramètre de stratégie qui active/désactive la mise à jour automatique est activé par défaut.

Les types de déploiements suivants ne peuvent pas utiliser la mise à jour automatique et doivent être gérés de façon autonome.

  • Déploiements qui utilisent des groupes de Controller.
  • Déploiements qui utilisent des listes ListOfSIDs pour des raisons de sécurité. (Les déploiements qui utilisent ListOfSIDs pour réduire la charge Active Directory peuvent utiliser la mise à jour automatique).
  • Déploiements qui utilisent Provisioning Services sans disque d'écriture conditionnelle.
  • Déploiements qui utilisent le paramètre de stratégie des Controller ou SID de Controller.

Mise à jour automatique

Le paramètre de stratégie Activer la mise à jour automatique des Delivery Controller est situé dans la catégorie Virtual Delivery Agent. Pour activer la mise à jour automatique, activez le paramètre de stratégie ; il s'agit de la valeur par défaut. Pour désactiver la mise à jour automatique, désactivez le paramètre de stratégie.

Lorsque la mise à jour automatique est activée et que vous installez un VDA, le VDA tente de s'enregistrer avec les valeurs d'un Controller que vous avez spécifié lorsque vous avez installé le VDA. Le programme d'installation enregistre les informations Delivery Controller que vous spécifiez pendant l'installation de VDA à la valeur de Registre ListOfDDCs.

Après l'enregistrement du VDA, le Controller auprès duquel il est enregistré envoie une liste des noms de domaine complets des Controller et des ID de sécurité (SID) au VDA. Le VDA écrit cette liste sur le stockage persistant de mise à jour automatique. Chaque Controller vérifie également la base de données de configuration de site toutes les 90 minutes pour des informations Controller : si un Controller a été ajouté ou supprimé depuis la dernière vérification ou si une modification de stratégie s'est produite, le Controller envoie les listes mises à jour au VDA auprès duquel il est enregistré. Le VDA acceptera les connexions provenant de tous les Controller figurant dans la dernière liste reçue.

Si un VDA reçoit une liste qui ne comprend pas le Controller auprès duquel il est enregistré (en d'autres termes, ce Controller a été supprimé du site), le VDA s'enregistre de nouveau, en choisissant parmi les Controller dans la liste. Après qu'un VDA s'enregistre ou se réenregistre, il reçoit une liste à jour.

Par exemple :

  1. Un déploiement dispose de trois Controller : A B et C. Un VDA est installé et s'enregistre auprès du Controller B (qui a été spécifié lors de l'installation du VDA).
  2. Deux Controller (D et E) sont ajoutés au site. Dans les 90 minutes qui suivent, le VDA recevra les listes mises à jour et acceptera 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.)
  3. Le Controller B est supprimé du site. Dans les 90 minutes qui suivent, le VDA recevra les listes mises à jour car un Controller a été modifié depuis la dernière vérification. Le VDA installé dans l'étape 1 est enregistré auprès du Controller B, qui ne figure plus sur la liste, si bien que ce VDA se réenregistre en choisissant parmi les Controller disponibles dans la liste actuelle (A, C, D et E).

Autogestion

Si vous n'utilisez pas la mise à jour automatique, vous devez mettre à jour le paramètre de stratégie Citrix ou les valeurs de registre de chaque VDA du site après avoir ajouté, déplacé ou supprimé les Delivery Controller dans le site. Les modifications apportées au registre peuvent également être mises à jour à l'aide d'un objet de stratégie de groupe.

Pour pratiquer l'autogestion à l'aide de paramètres de stratégie Citrix

  1. Mettez à jour les valeurs des noms de domaine complets spécifiées dans le paramètre de stratégie Controller. Ce paramètre de stratégie est situé dans la catégorie Virtual Delivery Agent.
  2. Si vous utilisez également une liste ListOfSIDs dans votre déploiement, vous devez mettre à jour les valeurs de SID spécifiées dans le paramètre SIDspolicy du Controller.

Pour pratiquer l'autogestion à l'aide du registre :

Avertissement : la modification incorrecte du Registre peut entraîner des problèmes graves pouvant nécessiter la réinstallation de votre système d'exploitation. Citrix ne peut garantir la possibilité de résoudre les problèmes provenant d'une mauvaise utilisation de l'Éditeur du Registre. Vous assumez l’ensemble des risques liés à l’utilisation de cet outil. Veillez à faire une copie de sauvegarde de votre registre avant de le modifier.

  1. Mettez à jour la clé de registre ListOfDDCs, qui répertorie les noms de domaine complets de tous les Controller du site. (Cette clé est l’équivalent de l'unité d'organisation du site Active Directory.) Séparez les valeurs multiples par des espaces. Entourez les groupes Controller avec crochets.

    HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs (REG_SZ)

    Si l'emplacement de registre HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent contient les clés ListOfDDCs et FarmGUID, ListOfDDCs est utilisée pour la découverte de Controller ; la clé FarmGUID est présente si une unité d'organisation de site a été spécifiée lors de l'installation du VDA.

  2. Si vous le souhaitez, vous pouvez mettre à jour la clé de registre ListOfSIDs :

    HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs (REG_SZ)

Ajouter, supprimer ou déplacer des Delivery Controller

Pour ajouter, supprimer ou déplacer un Controller, vous devez disposer des autorisations de rôle de serveur et de rôle de base de données répertoriées dans l'article Bases de données.

Remarque : l'installation d'un Controller sur un nœud dans une installation de mise en cluster SQL ou mise en miroir SQL n'est pas prise en charge.

Si votre déploiement utilise la mise en miroir de base de données :

  • Avant l'ajout, la suppression ou le déplacement d'un Controller, assurez-vous que les bases de données principale et en miroir sont en cours d'exécution. En outre, si vous utilisez les scripts avec SQL Server Management Studio, activez le mode SQLCMD avant d'exécuter les scripts.
  • Pour vérifier la mise en miroir après ajout, suppression ou déplacement d'un Delivery Controller, exécutez l'applet de commande PowerShell get-configdbconnection pour vous assurer que le partenaire de basculement a été défini dans la chaîne de connexion sur le miroir.

Après avoir ajouté, supprimé ou déplacé un Delivery Controller :

  • Si la mise à jour automatique est activée, les VDA recevront une liste actualisée des Delivery Controller dans les 90 minutes qui suivent.
  • Si la mise à jour automatique n'est pas activée, vérifiez que le paramètre de stratégie du Delivery Controller ou la clé de registre ListOfDDCs sont mis à jour pour tous les VDA. Après déplacement d'un Delivery Controller vers un autre site, mettez à jour le paramètre de stratégie ou la clé de registre sur les deux sites.

Ajouter un Controller

Vous pouvez ajouter des Controller lorsque vous créez un site et ultérieurement. Vous ne pouvez pas ajouter des Controller installés avec une version antérieure de ce logiciel à un site qui a été créé avec cette version.

  1. Exécutez le programme d'installation sur un serveur contenant un système d'exploitation pris en charge. Installez le composant Delivery Controller et les autres composants principaux requis. Suivez les instructions de l'assistant d'installation.
  2. Si vous n'avez pas encore créé de site, démarrez Studio ; vous êtes invité à créer un site.Sur la page Bases de données de l'Assistant de création de site, cliquez sur le bouton Sélectionner et ajoutez l'adresse du serveur sur lequel vous avez installé le Controller supplémentaire.Important : si vous souhaitez générer des scripts qui initialiseront les bases de données, ajoutez les Controller avant de générer les scripts.
  3. Si vous avez déjà créé un site, pointez Studio vers le serveur sur lequel vous avez installé le Controller supplémentaire. Cliquez sur Adapter votre déploiement et entrez l'adresse du site.

Supprimer un Controller

La suppression d'un Delivery Controller d'un site n'entraîne pas la désinstallation du logiciel Citrix ou de tout autre composant ; elle supprime le Delivery Controller de la base de données afin qu'il ne puisse plus être utilisé pour les connexions du broker et pour effectuer d'autres tâches. Si vous supprimez un Delivery Controller, vous pouvez le rajouter par la suite au même site ou à un autre site. Un site a besoin d'au moins un Delivery Controller ; vous ne pouvez donc pas supprimer le dernier Delivery Controller répertorié dans Studio.

Lorsque vous supprimez un Controller d'un site, l'ouverture de session Controller sur le serveur de base de données n'est pas supprimée. Cela évite potentiellement la suppression d'une ouverture de session utilisée par des services d'autres produits sur la même machine. L'ouverture de session doit être supprimée manuellement si elle n'est plus requise ; l'autorisation de rôle de serveur securityadmin est nécessaire pour la supprimer.

Important : ne supprimez pas le Controller depuis Active Directory tant que vous ne l'avez pas supprimé du site.

  1. Assurez-vous que le Controller est sous tension afin que Studio puisse se charger en moins d'une heure. Une fois que Studio charge le Controller que vous souhaitez supprimer, placez le Controller hors tension lorsque vous y êtes invité.
  2. Sélectionnez Configuration > Delivery Controller dans le panneau de navigation Studio, puis sélectionnez le Controller que vous voulez supprimer.
  3. Cliquez sur Supprimer le Controller dans le volet Actions. Si vous ne possédez pas les droits et les rôles de base de données appropriés, vous pouvez générer un script qui permet à votre administrateur de base de données de supprimer le Delivery Controller à votre place.
  4. Vous devrez peut-être supprimer le compte machine du Delivery Controller du serveur de base de données. Avant de procéder de la sorte, vérifiez qu'aucun autre service n'utilise le compte.

Après utilisation de Studio pour supprimer un Controller, le trafic vers ce Controller peut rester affiché pour un laps de temps pour assurer le bon d’achèvement des tâches courantes. Si vous souhaitez forcer la suppression d'un Controller dans un bref délai, Citrix vous recommande de fermer le serveur sur lequel il a été installé, ou de supprimer ce serveur à partir d’Active Directory. Ensuite, redémarrez les autres Controller du site pour vous assurer qu'aucune autre communication avec le Controller supprimé n'est réalisée.

Déplacer un Controller vers une autre zone

Si votre site contient plusieurs zones, vous pouvez déplacer un Controller vers une autre zone. Consultez l'article Zones pour savoir comment cela peut affecter l'enregistrement du VDA et d'autres opérations.

  1. Sélectionnez Configuration > Delivery Controller dans le panneau de navigation Studio, puis sélectionnez le Controller que vous voulez déplacer.
  2. Sélectionnez Déplacer dans le volet Actions.
  3. Spécifiez la zone vers laquelle vous souhaitez déplacer le Controller.

Pour déplacer un Controller vers un autre site

Vous ne pouvez pas déplacer un Delivery Controller vers un site qui a été créé avec une version antérieure de ce logiciel.

  1. Sur le site dans lequel figure le Controller (l'ancien site), sélectionnez Configuration > Delivery Controller dans le panneau de navigation de Studio, puis sélectionnez le Controller que vous souhaitez déplacer.
  2. Cliquez sur Supprimer le Controller dans le volet Actions. Si vous ne possédez pas les droits et les rôles de base de données appropriés, vous pouvez générer un script qui permet à un utilisateur disposant de ces autorisations (tel qu'un administrateur de base de données) de supprimer le Delivery Controller à votre place. Un site a besoin d'au moins un Delivery Controller ; vous ne pouvez donc pas supprimer le dernier Delivery Controller répertorié dans Studio.
  3. Sur le Controller que vous déplacez, ouvrez Studio, réinitialisez les services lorsque vous y êtes invité, cliquez sur Joindre un site existant et saisissez l'adresse du nouveau site.

Déplacer un VDA vers un autre site

Si un VDA a été provisionné à l'aide de Provisioning Services ou qu'il est une image existante, vous pouvez déplacer un VDA vers un autre site (d'un site 1 au site 2) lors de la mise à niveau, ou lors du déplacement d'une image de VDA qui a été créée dans un site test vers un site de production. Les VDA provisionnés à l'aide de Machine Creation Services (MCS) ne peuvent pas être déplacés d'un site à un autre car MCS ne prend pas en charge la modification des listes ListOfDDC que VDA vérifie pour s'enregistrer auprès d'un Controller ; les VDA provisionnés à l'aide de MCS vérifient toujours les listes ListOfDDC associées au site dans lequel ils ont été créés.

Il existe deux façons de déplacer un VDA vers un autre site : à l'aide du programme d'installation ou de stratégies Citrix.

Programme d'installation : exécutez le programme d'installation et ajoutez un Controller, en spécifiant le nom complet (entrée DNS) d'un Controller du site 2. Important : ne spécifiez les Controller dans le programme d'installation que lorsque le paramètre de stratégie des Controller n'est pas utilisé.

Éditeur de stratégie de groupe : l'exemple suivant déplace plusieurs VDA entre sites.

  1. Créez une stratégie dans le site 1 qui contient les paramètres suivants, puis filtrez la stratégie au niveau du groupe de mise à disposition pour initier une migration VDA échelonnée entre les sites.
    Controller : contenant les noms complets (entrées DNS) d'un ou de plusieurs Controller dans le site 2.
    Activer la mise à jour automatique des Controller : défini sur désactivé.
  2. Chaque VDA dans le groupe de mise à disposition reçoit une alerte dans les 90 minutes qui suivent la création de la nouvelle stratégie. Le VDA ignore la liste de Controller qu'il reçoit (car la mise à jour automatique est désactivée) : il sélectionne l'un des Controller spécifiés dans la stratégie, qui répertorie les Controller du site 2.
  3. Lorsque le VDA s'enregistre avec succès auprès d'un Controller du site 2, il reçoit la liste ListOfDDCs du site 2 et les informations de stratégie, dans laquelle la mise à jour automatique est activée par défaut. Étant donné que le Controller auquel duquel le VDA s'est enregistré dans le site 1 ne figure pas sur la liste envoyée par le Controller du site 2, le VDA se réenregistre, en choisissant parmi les Controller de la liste du site 2. Dès lors, le VDA est automatiquement mis à jour avec les informations du site 2.

Découverte de Controller basée sur unité d'organisation Active Directory

Cette méthode de découverte Delivery Controller est prise en charge principalement pour la rétrocompatibilité, et est uniquement valide pour les Virtual Delivery Agent (VDA) pour OS Windows Desktop, et non pour les VDA pour OS Windows Desktop. La découverte basée sur Active Directory exige que tous les ordinateurs d'un site soient membres d'un domaine ; par ailleurs, le domaine utilisé par le Controller doit entretenir des relations de confiance avec le ou les domaines utilisés par les bureaux. Si vous utilisez cette méthode, vous devez configurer le GUID de l'unité d'organisation dans chaque registre de bureau.

Pour effectuer une découverte de Controller basée sur l'unité d'organisation, exécutez le script PowerShell Set-ADControllerDiscovery.ps1 sur le Controller (chaque Controller contient ce script dans le dossier $Env:ProgramFiles\Citrix\Broker\Service\Setup Scripts). Pour exécuter le script, vous devez disposer des autorisations CreateChild sur une unité d'organisation parente, ainsi que des droits d'administration complets.

Lorsque vous créez un site, une unité d'organisation correspondante doit être créée dans Active Directory si vous souhaitez que les bureaux reconnaissent les Controller d'un site à l'aide d'Active Directory. L'unité d'organisation peut être créée dans un domaine quelconque de la forêt contenant vos ordinateurs. Il est recommandé que l'unité d'organisation contienne également les Controller du site. Cependant, cette condition n'est pas obligatoire. Un administrateur de domaine avec des privilèges adéquats peut créer l'unité d'organisation en tant que conteneur vide, puis déléguer les droits d'administration de l'unité d'organisation à un administrateur Citrix.

Le script crée plusieurs objets essentiels. Seuls les objets Active Directory standard sont créés et utilisés. Il n'est pas nécessaire de développer le schéma.

  • Un groupe de sécurité pour les Controller. Le compte d'ordinateur de tous les Controller du site doit appartenir à ce groupe de sécurité. Les bureaux d'un site acceptent les données provenant de Controller uniquement s'ils appartiennent à ce groupe de sécurité.

    Vérifiez que tous les Controller disposent du privilège « Accéder à cet ordinateur à partir du réseau » sur l'ensemble des bureaux virtuels exécutant le VDA. Pour ce faire, vous pouvez affecter ce privilège au groupe de sécurité des Controller. Si les Controller ne disposent pas de ce privilège, les VDA ne pourront pas s'enregistrer.

  • Un objet SCP (Service Connection Point) qui contient des informations sur le site, tel que son nom. Si vous utilisez l'outil d'administration Utilisateurs et ordinateurs Active Directory pour inspecter l'unité d'organisation d'un site, vous devrez sans doute activer Fonctionnalités avancées dans le menu Affichage pour afficher les objets SCP.
  • Un conteneur appelé RegistrationServices, qui est créé dans l'unité d'organisation du site. Celui-ci contient un objet SCP pour chaque Controller du site. À chaque démarrage du Controller, il valide le contenu de son objet SCP et le met à jour si nécessaire.

Si différents administrateurs sont susceptibles d'ajouter et de supprimer des Controller une fois l'installation initiale effectuée, ils doivent disposer des autorisations requises pour créer et supprimer les enfants dans le conteneur RegistrationServices et les propriétés d'écriture sur le groupe de sécurité des Controller ; ces autorisations sont accordées automatiquement à l'administrateur qui exécute le script Set-ADControllerDiscovery.ps1. L'administrateur de domaine ou l'administrateur à l'origine de l'installation peuvent accorder ces autorisations. Citrix recommande la configuration d'un groupe de sécurité à cette fin.

Lorsque vous utilisez une unité d'organisation de site :

  • Les informations sont écrites dans Active Directory uniquement lorsque vous installez ou désinstallez ce logiciel, ou lorsqu'un Controller démarre et doit mettre à jour les informations dans son objet SCP (par exemple, lorsque le nom du Controller ou le port de communication a été modifié). Par défaut, le script Set-ADControllerDiscovery.ps1 définit les autorisations appropriées relatives aux objets de l'unité d'organisation d'un site, en accordant à chaque Controller un accès en écriture sur leurs objets SCP. Le contenu des objets de l'unité d'organisation du site permet d'établir une relation de confiance entre les bureaux et les Controller. Assurez-vous que :
    • seuls les administrateurs autorisés peuvent ajouter ou supprimer des ordinateurs dans le groupe de sécurité des Controller à l'aide de la liste de contrôle d'accès (ACL) s'y référant ;
    • seuls les administrateurs autorisés et leur Controller respectif peuvent modifier les informations de l'objet SCP du Controller.
  • Si votre déploiement utilise la réplication, tenez compte des éventuels retards ; consultez la documentation Microsoft pour plus d'informations. Ce point est particulièrement important si vous créez l'unité d'organisation du site dans un domaine contenant des contrôleurs de domaine situés dans différents sites Active Directory. En fonction de l'emplacement des bureaux, des Controller et des contrôleurs de domaine, les modifications apportées à Active Directory lors de la création initiale de l'unité d'organisation du site, de l'installation ou de la désinstallation de Controller, de la modification d'un nom de Controller ou de ports de communication, peuvent ne pas être visibles sur les bureaux tant que les informations n'ont pas été répliquées dans le contrôleur de domaine approprié. Le retard de la réplication peut entraîner, entre autres, les conséquences suivantes : les bureaux ne peuvent pas établir de contact avec les Controller, et de ce fait, ne sont pas disponibles pour les connexions utilisateur.
  • Ce logiciel utilise plusieurs attributs d'objet ordinateur standard dans Active Directory pour gérer les bureaux. En fonction de votre déploiement, le nom de domaine complet de l'objet machine, tel qu'indiqué dans l'enregistrement Active Directory du bureau, peut être intégré aux paramètres de connexion renvoyés à l'utilisateur en vue de la connexion. Assurez-vous que les informations sont cohérentes avec les informations dans votre environnement DNS.

Pour déplacer un Controller vers un autre site à l'aide de la découverte de Controller basée sur l'unité d'organisation, suivez les instructions ci-dessus pour le déplacement d'un Delivery Controller. Lorsque vous supprimez le Controller de l'ancien site (étape 2), exécutez le script PowerShell : Set-ADControllerDiscover –sync. Le script assure la synchronisation entre l'unité d'organisation et l'ensemble actuel des Controller. Après avoir rejoint le site existant (étape 3), exécutez le même script sur un Controller dans le nouveau site.

Autorisations requises pour la découverte basée sur l'unité d'organisation

Pour créer un site, l'administrateur Citrix qui exécute le script doit posséder les droits appropriés sur l'unité d'organisation du site afin de créer des objets (SCP, conteneur et groupe de sécurité). 

(Si l’unité d'organisation du site n’est pas présente, l’administrateur doit également disposer de droits lui permettant de la créer. Citrix recommande à l’administrateur de domaine AD de pré-créer cette unité d'organisation et d’en déléguer les droits à l’identité de l’administrateur du site Citrix. Le script peut également créer l'unité d'organisation du site. Pour ce faire, l’administrateur doit être autorisé à créer une unité d'organisation sur l’unité d'organisation parente de la nouvelle unité d'organisation. Toutefois, comme indiqué, Citrix ne recommande pas cette façon de procéder.

Plus tard, pour ajouter ou supprimer un Delivery Controller dans le site, l'administrateur Citrix doit disposer des droits d'ajouter/supprimer une machine dans le groupe de sécurité, et de créer/supprimer un objet SCP.

En mode de fonctionnement normal, les Controller et les VDA doivent disposer des droits d'accès en lecture à tous les objets de l'unité d'organisation et des niveaux inférieurs. Les VDA accèdent à l'unité d'organisation sous leur propre identité de machine ; cette identité de machine doit disposer au minimum de droits en lecture dans l'unité d'organisation pour être en mesure de détecter les Controller. Un Controller a également besoin des droits lui permettant de définir des propriétés sur son propre objet SCP dans le conteneur. 

Accorder à l'administrateur Citrix des droits complets sur les unités d'organisation enfants lui permettra d'effectuer toutes ces actions. Toutefois, si votre déploiement est lié à des exigences de sécurité strictes (par exemple, limitant les personnes qui peuvent utiliser le script d'une action), vous pouvez utiliser l'Assistant Délégation de contrôle pour définir des droits spécifiques. L'exemple suivant accorde les droits nécessaires pour créer le site.

  1. Créez une unité d'organisation qui contient les objets enfants (SCP (Service Connection Point), conteneur et groupe de sécurité).
  2. Sélectionnez l'unité d'organisation, puis cliquez avec le bouton droit et sélectionnez Délégation de contrôle.
  3. Dans l'Assistant Délégation de contrôle, spécifiez l'utilisateur de domaine auquel déléguer le contrôle pour l'unité d'organisation.
  4. Sur la page Tâches à déléguer, sélectionnez Créer une tâche personnalisée à déléguer.
  5. Sur la page Type d’objet Active Directory, acceptez le paramètre par défaut De ce dossier et des objets qui s’y trouvent. Déléguer aussi la création de nouveaux objets dans ce dossier.
  6. Sur la page Autorisations, sélectionnez les cases Écriture et Créer tous les objets enfants.
  7. Terminez l'assistant pour confirmer les privilèges.