Documentation produit
Citrix DaaS™
Voir PDF

Cache d’hôte local

April 6, 2026
Contributeur: 
C C

Cet article fournit une vue d’ensemble complète de la fonctionnalité de cache d’hôte local (LHC), en se concentrant sur sa capacité à maintenir la continuité des activités. Il explique le fonctionnement du LHC à la fois pendant les opérations normales et lorsque le mode LHC est activé. De plus, l’article propose des conseils sur les vérifications de configuration, le dépannage, les commandes PowerShell pour la gestion du LHC et la surveillance des journaux d’événements pour la santé du LHC.

Vue d’ensemble

Le LHC maintient l’accès des utilisateurs finaux aux applications et aux bureaux lorsque les Cloud Connectors perdent la connectivité avec Citrix Cloud™ en raison d’une interruption réseau ou d’un problème avec Citrix Cloud. Les sessions actives ne sont pas impactées lorsque le mode LHC est activé et les nouvelles sessions sont gérées par le broker LHC exécuté sur les Cloud Connectors.

Le LHC est activé par défaut, mais il est important de s’assurer que votre environnement est correctement configuré pour le LHC. Bien que des erreurs de configuration puissent ne pas perturber le brokering normal, elles peuvent nuire aux performances du LHC, entraînant des perturbations pour les utilisateurs finaux lorsque le mode LHC est actif. Pour garantir une fonctionnalité LHC optimale, vérifiez votre nœud Zones dans Studio pour détecter les erreurs et avertissements liés aux zones que Citrix a détectés. De plus, consultez le guide Vérifier les configurations de résilience et l’article Éviter les erreurs de configuration courantes qui peuvent avoir un impact négatif sur la résilience de DaaS pour une liste de contrôle complète de la configuration du LHC.

Important :

  • Le LHC ne s’active que si les Cloud Connectors reçoivent du trafic de StoreFront ou si la continuité du service est activée. Pour plus d’informations sur la façon dont la continuité du service peut utiliser le cache d’hôte local pour maintenir l’accès des utilisateurs aux applications et aux bureaux pendant les interruptions de service, consultez Continuité du service.

Fonctionnement

Pendant les opérations normales, le service Remote Broker Provider sur un Cloud Connector communique avec Citrix Cloud pour toutes les opérations de brokering. Le service Citrix Config Synchronizer (CSS) vérifie régulièrement les modifications de configuration dans Citrix Cloud et synchronise ces données avec le broker LHC sur le Cloud Connector. Si les Cloud Connectors perdent la connectivité avec Citrix Cloud ou si Citrix Cloud rencontre un problème, le mode LHC s’active et assure un accès continu aux applications et aux bureaux.

Pendant le fonctionnement normal du brokering

  • Pendant le fonctionnement normal du brokering

  • Le service Citrix Remote Broker Provider sur un Cloud Connector accepte les demandes de connexion de StoreFront. Le service Remote Broker Provider communique avec Citrix Cloud pour connecter les utilisateurs aux VDA enregistrés auprès de Citrix Cloud.
  • Le CSS vérifie auprès du broker Cloud dans Citrix Cloud environ toutes les 5 minutes si des modifications de configuration ont été apportées. Ces modifications peuvent être initiées par l’administrateur (telles que la modification d’une propriété de groupe de mise à disposition) ou des actions système (telles que les attributions de machines).

  • Si une modification de configuration est survenue depuis la vérification précédente, le CSS synchronise les informations avec le broker LHC sur le Cloud Connector. (Le broker LHC est également appelé service de haute disponibilité, ou broker HA).

    Toutes les données de configuration sont copiées, pas seulement les éléments qui ont changé depuis la vérification précédente. Le CSS importe les données de configuration dans une base de données Microsoft SQL Server Express LocalDB sur le Cloud Connector. Cette base de données est appelée base de données du cache d’hôte local. Le CSS garantit que les informations de la base de données du cache d’hôte local correspondent aux informations de la base de données du site dans Citrix Cloud.

    Microsoft SQL Server Express LocalDB (utilisé par la base de données LHC) est installé automatiquement lorsque vous installez un Cloud Connector. La base de données LHC ne peut pas être partagée entre les Cloud Connectors. Vous n’avez pas besoin de sauvegarder la base de données LHC. Elle est recréée chaque fois qu’une modification de configuration est détectée.

  • Si aucune modification n’est survenue depuis la dernière vérification, les données de configuration ne sont pas copiées.

Lorsque le mode LHC devient actif

  • Lorsque le mode LHC devient actif

  • Le broker LHC commence à écouter les informations de connexion et à traiter les demandes de connexion.
  • Lorsque les Cloud Connectors perdent pour la première fois la connectivité avec Citrix Cloud, le broker LHC ne dispose pas des données d’enregistrement VDA actuelles, mais lorsqu’un VDA communique avec lui, un processus d’enregistrement est déclenché. Pendant ce processus, le broker LHC obtient également les informations de session actuelles pour ce VDA.

  • Pendant que le broker LHC gère les connexions, le service Remote Broker Provider continue de surveiller la connexion à Citrix Cloud. Lorsque la connexion est restaurée, le service Remote Broker Provider demande au broker LHC d’arrêter d’écouter les informations de connexion, et Citrix Cloud reprend les opérations de brokering. La prochaine fois qu’un VDA communique avec Citrix Cloud via le service Remote Broker Provider, un processus d’enregistrement est déclenché. Le broker LHC supprime tous les enregistrements VDA restants de la période où le mode LHC était actif. Le CSS reprend la synchronisation des informations lorsqu’il apprend que des modifications de configuration sont survenues dans Citrix Cloud.

  • Dans le cas improbable où le LHC démarrerait pendant une synchronisation, l’importation en cours est ignorée et la dernière configuration connue est utilisée.

  • Le journal des événements indique quand les synchronisations se produisent et quand le mode LHC s’active.

  • Il n’y a pas de limite de temps imposée pour fonctionner en mode LHC.

  • Vous pouvez également déclencher manuellement le mode LHC. Consultez Forcer le mode LHC pour plus de détails sur les raisons et la manière de procéder.

Zones avec plusieurs Cloud Connectors

  • Entre autres tâches, le CSS fournit régulièrement au broker LHC des informations sur tous les Cloud Connectors de la zone. Ayant ces informations, chaque broker LHC connaît tous les brokers LHC pairs exécutés sur d’autres Cloud Connectors de la zone.

  • Les brokers LHC communiquent entre eux sur un canal distinct. Ces brokers utilisent une liste alphabétique des noms de domaine complets (FQDN) des machines sur lesquelles ils s’exécutent pour déterminer (élire) quel broker LHC gérera les opérations dans la zone si la zone entre en mode LHC. Pendant le mode LHC, tous les VDA se réenregistrent auprès du broker LHC élu. Les brokers LHC non élus de la zone rejettent activement les demandes de connexion entrantes et d’enregistrement VDA.

  • Important :

  • Les connecteurs au sein d’une zone doivent pouvoir se joindre mutuellement à l’adresse http://<FQDN_OF_PEER_CONNECTOR>:80/Citrix/CdsController/ISecondaryBrokerElection. Si les connecteurs ne peuvent pas communiquer à cette adresse, plusieurs brokers peuvent être élus et des échecs de lancement se produisent en mode LHC.

En mode LHC, si un Cloud Connector est redémarré ou si le broker LHC échoue :

  • Si ce Cloud Connector n’est pas le broker LHC élu, le redémarrage n’a aucun impact.
  • Si ce Cloud Connector est le broker LHC élu, le broker LHC du Cloud Connector suivant est élu, ce qui entraîne l’enregistrement des VDA. L’ordre d’élection est basé sur l’ordre alphabétique du FQDN des Cloud Connectors. Une fois que le broker LHC redevient actif, les opérations LHC se poursuivent sur le premier connecteur par ordre alphabétique, ce qui peut entraîner un nouvel enregistrement des VDA. Dans ce scénario, les performances peuvent être affectées pendant les enregistrements.

Consultez les journaux d’événements pour plus d’informations sur les événements liés aux élections de broker LHC.

Contenu des données du cache d’hôte local

La base de données LHC inclut les données suivantes, qui constituent un sous-ensemble des données de la base de données principale :

  • Identités des utilisateurs et des groupes auxquels des droits sont attribués pour les ressources publiées à partir du site.
  • Identités des utilisateurs qui utilisent actuellement ou qui ont récemment utilisé des ressources publiées à partir du site.
  • Identités des machines VDA (y compris les machines d’accès PC distant) configurées sur le site.
  • Identités (noms et adresses IP) des machines clientes de l’application Citrix Workspace™ utilisées activement pour se connecter aux ressources publiées.

Il contient également les informations suivantes pour les connexions actuellement actives qui ont été établies en mode LHC :

  • Résultats de toute analyse de point de terminaison de machine cliente effectuée par l’application Citrix Workspace.
  • Identités des machines d’infrastructure (telles que les serveurs Citrix Gateway et StoreFront) impliquées sur le site.
  • Dates, heures et types d’activités récentes des utilisateurs.

États du cache d’hôte local

Il existe plusieurs états pendant tout le cycle d’entrée et de sortie du mode LHC. Le diagramme suivant décrit les états d’entrée et de sortie du mode LHC.

États LHC

  • Pendant l’état Fonctionnement normal, tous les composants sont sains et toutes les transactions de brokering sont gérées par le broker Cloud. Le CSS réplique activement les configurations du broker Cloud vers les Cloud Connectors. Si des vérifications d’intégrité échouent, les Cloud Connectors passent à l’état HA en attente. Dans cet état, une vérification d’intégrité complète est lancée pour déterminer la marche à suivre. Les connecteurs interagissent avec d’autres connecteurs de la zone pour déterminer leur état de santé.
    • La décision de passer de HA en attente à HA initiale est basée sur l’état de santé de tous les connecteurs d’une zone donnée. Si les vérifications d’intégrité réussissent, les connecteurs/contrôleurs reviennent à l’état Fonctionnement normal. Sinon, si les vérifications d’intégrité continuent d’échouer, les connecteurs/contrôleurs passent à l’état HA initiale.
    • Pendant l’état HA initiale, le broker LHC du connecteur élu prend en charge les responsabilités de brokering. Tous les VDA de la zone actuelle qui étaient enregistrés auparavant s’enregistreront désormais auprès du broker LHC sur le Cloud Connector. Il peut s’écouler jusqu’à 5 minutes pour que tous les VDA se réenregistrent auprès du service HA. À la fin de la HA initiale, des vérifications d’intégrité sont lancées. Si toutes les vérifications d’intégrité réussissent, l’état passe à Récupération en attente, sinon l’état passe à HA étendue.
  • Les vérifications d’intégrité continuent de se produire pendant la période de HA étendue. Lorsque les vérifications d’intégrité réussissent pendant la HA étendue, l’état passe à Récupération en attente. Il n’y a pas de durée maximale pour qu’un connecteur reste dans l’état HA étendue.
  • Récupération en attente sert de période tampon pour s’assurer que les services sont entièrement sains avant de sortir du mode LHC. Si l’une des vérifications d’intégrité échoue pendant la Récupération en attente, l’état revient à HA étendue.
  • Si toutes les vérifications d’intégrité réussissent pendant toute la période de 10 minutes de Récupération en attente, l’état passe à Fonctionnement normal. Avec cette transition, le mode LHC se termine, et tous les VDA de la zone qui étaient enregistrés auprès du broker LHC se réenregistrent désormais auprès du broker Cloud. Ce réenregistrement peut à nouveau prendre jusqu’à 5 minutes.

Considérations importantes en mode LHC

En mode LHC, tenez compte des impacts suivants :

Aspect Impact en mode LHC
Accès à Studio Peut être inaccessible, selon la nature de la perturbation. Les VDA des zones fonctionnant en mode LHC s’affichent comme Non enregistrés dans Studio car ils sont enregistrés auprès du broker LHC.
Accès au SDK PowerShell distant


Accès limité.
Définir l’authentification SDK : Exécutez Get-XDAuthentication -ProfileName WindowsCurrentUser pour empêcher le proxy SDK de rediriger les appels de cmdlet. Après avoir effectué ces modifications, vous pouvez utiliser toutes les cmdlets Get-Broker.
Remarque : Incluez le paramètre -AdminAddress localhost:89 dans l’appel initial de la cmdlet.
Exemple : Get-BrokerMachine -AdminAddress localhost:89
Données de surveillance Les fonctions de surveillance n’affichent pas d’activité lorsque le mode LHC est actif. Un sous-ensemble de données de surveillance est disponible dans le tableau de bord du cache d’hôte local de la page Tendances dans Monitor.
Informations d’identification de l’hyperviseur Impossible d’obtenir du service d’hôte. Machines dans un état d’alimentation inconnu, aucune opération d’alimentation possible. Les machines virtuelles sous tension sont utilisables pour les connexions.
Machines attribuées Utilisables uniquement si attribuées pendant les opérations normales. Les nouvelles attributions sont impossibles en mode LHC.
Machines d’accès PC distant L’inscription et la configuration automatiques ne sont pas prises en charge. Les machines inscrites et configurées pendant le fonctionnement normal sont utilisables.
Limites de session des applications et bureaux hébergés sur serveur Les utilisateurs peuvent utiliser plus de sessions que leurs limites de session configurées, si les ressources se trouvent dans des zones différentes.
Comportement de la zone Chaque zone agit indépendamment. Si la fonctionnalité de vérification d’intégrité avancée de StoreFront est activée, StoreFront est en mesure de router les demandes de lancement vers la zone appropriée en mode LHC et d’éviter les échecs de lancement de session.
Redémarrages VDA planifiés Si le mode LHC est activé avant le début d’un redémarrage planifié pour les VDA d’un groupe de mise à disposition, les redémarrages commencent lorsque le mode LHC se termine et que les opérations de brokering normales reprennent, ce qui peut entraîner des redémarrages inattendus lorsque la zone quitte le mode LHC. Pour plus d’informations et les configurations pouvant modifier ce comportement, consultez Redémarrages planifiés retardés en raison d’une panne de base de données.
Préférence de zone Les configurations de préférence de zone ne sont pas prises en compte pour le lancement de session.
Restrictions de balises Pour les groupes de mise à disposition avec des VDA dans plusieurs zones, les restrictions de balises peuvent entraîner des échecs de lancement si les VDA balisés ne sont pas présents dans toutes les zones.

Remarque :

    • L’utilisation de $XDSDKAuth pour l’authentification SDK est dépréciée à partir de juin 2025. Pour plus de détails, consultez Dépréciation.

Prise en charge des applications et des bureaux

LHC prend en charge les types de VDA et les modèles de mise à disposition suivants :

|Type de VDA|Modèle de mise à disposition|Disponibilité du VDA en mode LHC| |—|—|—|

  • OS multi-session Applications et bureaux Toujours disponible.
    • OS mono-session statique (attribué) Bureaux Toujours disponible.
    • OS mono-session aléatoire (en pool) géré par l’alimentation Bureaux Disponible pour une seule session par défaut.
    • ^^ ^^ ^^ Vous pouvez les configurer pour qu’ils soient toujours disponibles pour de nouvelles sessions pendant le LHC. Pour plus d’informations, consultez Activer l’utilisation de Studio et Activer l’utilisation de PowerShell.
    • ^^ ^^ ^^ Important : L’activation de l’accès aux machines en pool à session unique gérées par l’alimentation peut entraîner la présence de données et de modifications des sessions utilisateur précédentes dans les sessions ultérieures.

Remarque :

L’activation de l’accès aux VDA de bureau gérés par l’alimentation dans les groupes de mise à disposition en pool n’affecte pas le fonctionnement de la propriété ShutdownDesktopsAfterUse configurée pendant les opérations normales. Lorsque l’accès à ces bureaux est activé pendant le LHC, les VDA ne redémarrent pas automatiquement après le retour aux opérations de courtage normales. Les VDA de bureau gérés par l’alimentation dans les groupes de mise à disposition en pool peuvent conserver les données des sessions précédentes jusqu’au redémarrage des VDA. Un redémarrage de VDA peut se produire lorsqu’un utilisateur se déconnecte du VDA pendant des opérations non-LHC ou lorsque les administrateurs redémarrent le VDA.

Activer le LHC pour les VDA en pool de système d’exploitation à session unique gérés par l’alimentation à l’aide de Studio

À l’aide de Studio, vous pouvez rendre ces machines disponibles pour de nouvelles connexions en mode LHC, groupe de mise à disposition par groupe de mise à disposition :

Remarque :

Ce paramètre est disponible dans Studio uniquement pour les groupes de mise à disposition de bureaux en pool qui fournissent des VDA gérés par l’alimentation.

Activer le LHC pour les VDA en pool de système d’exploitation à session unique gérés par l’alimentation à l’aide de PowerShell

Pour activer le LHC pour les VDA dans un groupe de mise à disposition spécifique, procédez comme suit :

  1. Activez cette fonctionnalité au niveau du site en exécutant cette commande :

    Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true
<!--NeedCopy-->

  2. Activez le LHC pour un groupe de mise à disposition en exécutant cette commande avec le nom du groupe de mise à disposition spécifié :

    Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $true
<!--NeedCopy-->

Pour modifier la disponibilité par défaut du LHC pour les groupes de mise à disposition en pool nouvellement créés avec des VDA gérés par l’alimentation, exécutez la commande suivante :

Set-BrokerSite -DefaultReuseMachinesWithoutShutdownInOutage $true
<!--NeedCopy-->

Remarque :

La modification de la valeur par défaut ne modifie pas le paramètre des groupes de mise à disposition existants et n’affecte que les groupes de mise à disposition créés à l’aide de PowerShell.

Configuration de StoreFront

  • Si vous utilisez un déploiement StoreFront sur site, examinez les points suivants :

  • Si vous utilisez un serveur virtuel d’équilibrage de charge, configurez le serveur virtuel pour surveiller les connecteurs en fonction des capacités de courtage (par exemple, utilisez le moniteur CITRIX-XD-DDC intégré sur un NetScaler® pour l’équilibrage de charge des connecteurs).
  • Incluez tous les Cloud Connectors au sein d’un même locataire Cloud en tant que flux de ressources unique dans StoreFront.
  • Affichez les configurations de NetScaler Gateway dans StoreFront et assurez-vous que tous les connecteurs sont répertoriés en tant que serveurs STA. Vérifiez les appliances NetScaler et assurez-vous que tous les STA répertoriés dans StoreFront sont au même format dans le serveur virtuel NetScaler Gateway. L’état du service STA peut également être surveillé dans le serveur virtuel Gateway.
  • Ajoutez tous les connecteurs au flux de ressources dans StoreFront et assurez-vous que StoreFront peut communiquer avec tous les Cloud Connectors via le port désigné dans le flux de ressources.

Remarque :

Pour les clients disposant de nombreux connecteurs, il peut être avantageux de configurer un serveur virtuel d’équilibrage de charge pour chaque zone afin de réduire la charge de gestion et de simplifier le dépannage. Consultez Conseils Citrix : Intégration du service Citrix Virtual Apps and Desktops et de StoreFront pour plus d’informations.

Valider le fonctionnement du cache d’hôte local

-  Pour vérifier que le LHC est configuré et fonctionne correctement :

-  Assurez-vous que les importations de synchronisation se terminent avec succès. Consultez les [journaux d'événements](#event-logs) pour plus d'informations sur la surveillance des synchronisations LHC.
-  Assurez-vous que la base de données du cache d'hôte local a été créée sur chaque Cloud Connector. Cela confirme que le service de haute disponibilité peut prendre le relais, si nécessaire.
-  Sur le serveur Cloud Connector, accédez à `c:\Windows\ServiceProfiles\NetworkService`.
-  Vérifiez que `HaDatabaseName.mdf` et `HaDatabaseName_log.ldf` sont créés.
  • Forcez le mode LHC sur tous les Cloud Connectors de la zone : Après avoir vérifié que le cache d’hôte local fonctionne, n’oubliez pas de remettre tous les Cloud Connectors en mode normal. Consultez États du cache d’hôte local pour plus d’informations sur le temps nécessaire pour quitter le mode LHC.

Surveiller le cache d’hôte local

Journaux d’événements

Les journaux d’événements fournissent des informations critiques concernant la santé et les performances du LHC.

Service de synchronisation de la configuration

Pendant les opérations normales, les événements suivants peuvent se produire lorsque le CSS importe les données de configuration dans la base de données LHC à l’aide du broker LHC.

ID d’événement Description
503 Indique que le CSS a reçu une configuration mise à jour. Cet événement se produit chaque fois qu’une configuration mise à jour est reçue de Citrix Cloud. Cela indique le début du processus de synchronisation.
504 Indique que le CSS a importé une configuration mise à jour. L’importation de la configuration s’est terminée avec succès.
505 Indique que le CSS a échoué à une importation. L’importation de la configuration ne s’est pas terminée avec succès. Si une configuration réussie précédente est disponible, elle est utilisée si le mode LHC est activé. Cependant, elle sera obsolète par rapport à la configuration actuelle. S’il n’y a pas de configuration précédente disponible, le service ne peut pas participer au courtage de session pendant le mode LHC. Dans ce cas, consultez la section Dépannage et contactez le support Citrix.
507 Indique que le CSS a abandonné une importation car le système est en mode LHC et le broker LHC est utilisé pour le courtage. Le service a reçu une nouvelle configuration, mais l’importation a été abandonnée car le mode LHC a été activé. C’est un comportement attendu.
510 Indique qu’aucune donnée de configuration CSS n’a été reçue du service de configuration principal.
517 Indique qu’il y a eu un problème de communication avec le service de broker principal.
518 Indique que le script CSS a été interrompu car le broker LHC (service de haute disponibilité) n’est pas en cours d’exécution.

Service de haute disponibilité

Ce service est également connu sous le nom de broker LHC.

ID d’événement Description
3502 Indique qu’une panne s’est produite et que le broker LHC effectue des opérations de broker.
3503 Indique qu’une panne a été résolue et que les opérations normales ont repris.
3504 Indique le broker LHC élu et les autres brokers LHC impliqués dans l’élection.
3507 Indique que le mode LHC est actif sur le broker LHC élu. Contient un résumé de la panne, y compris la durée de la panne, l’enregistrement des VDA et les informations de session.
3508 Indique que le LHC n’est plus actif sur le broker LHC élu et que les opérations normales ont été restaurées. Contient un résumé de la panne, y compris la durée de la panne, le nombre de machines enregistrées pendant l’événement LHC et le nombre de lancements réussis en mode LHC.
3509 Indique que le LHC est actif sur le broker LHC non élu. Contient une durée de panne toutes les 2 minutes et indique le broker LHC élu.
3510 Indique que le LHC n’est plus actif sur le broker LHC non élu. Contient la durée de la panne et indique le broker LHC élu.

Fournisseur de broker distant

Ce service agit comme un proxy entre Citrix Cloud et vos VDA et Cloud Connectors.

|ID d’événement|Description| |–|–|

-  |3001|Vérifie si les Cloud Connectors doivent entrer en mode LHC. Se produit après un seul échec de contrôle de santé du Cloud Connector. Si un autre contrôle échoue après 90 secondes, le Cloud Connector passe en mode LHC.|
-  |3002|Indique que le Cloud Connector ne peut pas entrer en mode LHC. La raison est incluse dans les informations de l'événement.|
-  |3003|Indique que le Cloud Connector est en transition entre les états du mode LHC. L'événement fournit des détails sur les éléments suivants&nbsp;:|
-  |^^|^^ -  l'état à partir duquel le Cloud Connector est en transition|
-  |^^|^^ -  l'état vers lequel il est en transition|
  • ^^ ^^ - la durée de l’état précédent

Remarque :

Les événements 3001 sur vos Cloud Connectors, qui se produisent périodiquement tout au long de la journée, ne sont généralement pas une source de préoccupation. Cependant, s’ils se produisent plusieurs fois par heure, cela indique un problème réseau et peut justifier une enquête plus approfondie.

Citrix Monitor

Citrix Monitor contient des informations centralisées concernant les entrées en mode LHC et les performances des différentes zones de votre environnement.

Moniteur DaaS LHC

Consultez Surveiller les tendances historiques sur un site pour plus d’informations.

Forcer le mode Local Host Cache

Vous pouvez délibérément forcer le mode Local Host Cache dans les scénarios suivants :

  • Si votre réseau est instable : Forcer le LHC jusqu’à ce que les problèmes réseau soient résolus empêche la transition continue entre les modes normal et LHC (et les tempêtes d’enregistrement VDA fréquentes qui en résultent).
  • Pour tester un plan de reprise après sinistre.
  • Pour vous assurer que le Local Host Cache fonctionne correctement.

Pour forcer le mode LHC :

  1. Modifiez le registre de chaque serveur Cloud Connector dans HKLM\Software\Citrix\DesktopServer\LHC : Créez et définissez OutageModeForced comme REG_DWORD sur 1.

    • Définir la valeur sur 1 indique au broker LHC d’entrer en mode LHC, quel que soit l’état de la connexion à Citrix Cloud.
    • Définir la valeur sur 0 indique au broker LHC de quitter le mode LHC et de reprendre les opérations normales.

Pour vérifier les événements :

  1. Surveillez le fichier journal Current_HighAvailabilityService dans C:\ProgramData\Citrix\workspaceCloud\Logs\Plugins\HighAvailabilityService.

Résoudre les échecs d’importation de synchronisation

Lorsqu’une importation de synchronisation vers la base de données LHC échoue et qu’un événement 505 est enregistré, vous pouvez utiliser les outils de dépannage suivants :

  • Traçage CDF :
    • Activez le traçage pour les modules ConfigSyncServer et BrokerLHC.
    • Utilisez-le avec d’autres modules de broker pour identifier le problème.
  • Rapport de trace CSS :

    • Génère un rapport détaillé qui identifie l’objet à l’origine de l’échec de la synchronisation.

      Remarque :

      L’activation de ce rapport peut avoir un impact sur la vitesse de synchronisation. Désactivez-le lorsque vous n’êtes pas en train de dépanner activement.

    Pour activer et générer un rapport de trace CSS :

    1. Activer la création de rapports : Exécutez la commande suivante :

      New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -PropertyType DWORD -Value 1
<!--NeedCopy-->

    2. Localiser le rapport : Le rapport HTML est généré à l’emplacement C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\CitrixBrokerConfigSyncReport.html.

    3. Désactiver la création de rapports : Une fois le rapport généré, exécutez la commande suivante pour désactiver la fonctionnalité de création de rapports :

      Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -Value 0
<!--NeedCopy-->

Commandes PowerShell du cache d’hôte local

Vous pouvez gérer le cache d’hôte local sur vos Cloud Connectors à l’aide de commandes PowerShell.

Le module PowerShell se trouve à l’emplacement suivant sur les Cloud Connectors :

C:\Program Files\Citrix\Broker\Service\ControlScripts

Important :

Exécutez ce module uniquement sur les Cloud Connectors.

Importer le module PowerShell

Pour importer le module, exécutez la commande suivante sur votre Cloud Connector :

Import-Module "C:\Program Files\Citrix\Broker\Service\ControlScripts\HighAvailabilityServiceControl.psm1
<!--NeedCopy-->

Commandes PowerShell pour gérer le LHC

Les cmdlets suivantes vous aident à activer et à gérer le mode LHC sur les Cloud Connectors.

Cmdlets Fonction
Enable-LhcForcedOutageMode Place le Broker en mode LHC. Les fichiers de base de données du cache d’hôte local doivent avoir été créés avec succès par le CSS pour que Enable-LhcForcedOutageMode fonctionne correctement. Cette cmdlet force le LHC uniquement sur le Cloud Connector sur lequel elle a été exécutée. Pour que le LHC devienne actif, cette cmdlet doit être exécutée sur tous les Cloud Connectors de la zone.
Disable-LhcForcedOutageMode Désactive le mode LHC du Broker. Cette cmdlet désactive le mode LHC uniquement sur le Cloud Connector sur lequel elle a été exécutée. Disable-LhcForcedOutageMode doit être exécutée sur tous les Cloud Connectors de la zone.
Set-LhcConfigSyncIntervalOverride Définit l’intervalle auquel le CSS vérifie les modifications de configuration au sein du site Citrix DaaS™. L’intervalle de temps peut varier de 60 secondes (une minute) à 3600 secondes (une heure). Ce paramètre s’applique uniquement au Cloud Connector sur lequel il a été exécuté. Pour assurer la cohérence entre les Cloud Connectors, envisagez d’exécuter cette cmdlet sur chaque Cloud Connector. Par exemple : Set-LhcConfigSyncIntervalOverride -Seconds 1200
Clear-LhcConfigSyncIntervalOverride Définit l’intervalle auquel le CSS vérifie les modifications de configuration au sein du site Citrix DaaS à la valeur par défaut de 300 secondes (cinq minutes). Ce paramètre s’applique uniquement au Cloud Connector sur lequel il a été exécuté. Pour assurer la cohérence entre les Cloud Connectors, envisagez d’exécuter cette cmdlet sur chaque Cloud Connector.
Enable-LhcHighAvailabilitySDK Active l’accès à toutes les cmdlets Get-Broker* au sein du Cloud Connector sur lequel elle a été exécutée.
Disable-LhcHighAvailabilitySDK Désactive l’accès aux commandes PowerShell du Broker au sein du Cloud Connector sur lequel elle a été exécutée.

Remarque :

  • Utilisez le port 89 lors de l’exécution des cmdlets Get-Broker* sur le Cloud Connector. Par exemple :
    • Get-BrokerMachine -AdminAddress localhost:89
  • Lorsqu’il n’est pas en mode LHC, le Broker LHC sur le Cloud Connector ne contient que des informations de configuration.
  • En mode LHC, le Broker LHC contient les informations suivantes :
    • États des ressources
    • Détails de session
    • Enregistrements VDA
    • Informations de configuration

Plus d’informations

Cache d’hôte local
April 6, 2026
Contributeur: 
C C
April 6, 2026
Contributeur: 
C C

Dans cet article

Commentaires sur le site | Your privacy choices footer linkVos préférences de confidentialité | Confidentialité et conditions légales | Préférences de cookies | Paramètres de consentement | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.