Citrix Virtual Apps and Desktops

ローカルホストキャッシュ

November 25, 2025

寄稿者:

Citrix Virtual Apps and Desktopsサイトデータベースを常に使用可能状態にするために、Microsoft社の高可用性ベストプラクティスに従って、耐障害性の高いSQL Server展開から開始することをお勧めします（サポートされているSQL Serverの高可用性機能については、「データベース」を参照してください。）ただし、ネットワークの問題および中断によってユーザーがアプリケーションやデスクトップに接続できなくなる場合があります。

ローカルホストキャッシュ機能を使用すると、停止状態が発生しても、サイトの接続仲介操作を続行できます。オンプレミスのCitrix®環境でDelivery Controller™とサイトデータベースとの間の接続が失敗すると、停止状態が発生します。ローカルホストキャッシュは、サイトデータベースに90秒間アクセスできない場合に使用されます。

XenAppおよびXenDesktop 7.16より、接続リース機能（以前のリリースでの高可用性機能）は削除され、使用できなくなりました。

データコンテンツ

ローカルホストキャッシュには、メインデータベースの情報の一部として次の情報が格納されます：

サイトから公開されたリソースに対する権限が割り当てられているユーザーおよびグループのID。
サイトの公開リソースを現在使用しているか、最近使用したユーザーのID。
サイトで構成されているVDAマシン（リモートPCアクセスマシンを含む）のID。
公開リソースへの接続で頻繁に使用されているCitrix Receiver™クライアントマシンのID（名前とIPアドレス）。

また、メインデータベースが利用できなくなったときに確立され、現在アクティブな接続に関する情報も格納されています：

Citrix Receiverで実行されたクライアントマシンのエンドポイント分析の結果
サイトに関連するインフラストラクチャマシン（NetScaler GatewayやStoreFront™サーバーなど）のID。
ユーザーによる最近のアクティビティの日時とタイプ

機能

次の図は、通常の操作中のローカルホストキャッシュコンポーネントと通信経路を示しています。

通常の操作時におけるローカルホストキャッシュの通信経路図

通常の操作中

Controller上のプリンシパルブローカー（Citrix Broker Service）は、StoreFrontからの接続要求を受け取ります。このブローカーはサイトデータベースと通信して、Controllerに登録されているVDAにユーザーを接続します。
Citrix Config Synchronizer Service（CSS）は、ブローカーを5分ごとにチェックして、構成に変更がないか確認します。こうした変更には、管理者によるもの（デリバリーグループのプロパティの変更など）とシステム操作（マシン割り当てなど）があります。
前回のチェック以降に構成が変更された場合、CSSは、Controllerのセカンダリブローカーに情報を同期（コピー）します。（セカンダリブローカーは、High Availability Serviceとも呼ばれます）。

前回のチェック以降に変更された項目だけでなく、すべての構成データがコピーされます。 CSSは、Controller上のMicrosoft SQL Server Express LocalDBデータベースに構成データをインポートします。このデータベースはローカルホストキャッシュデータベースとして参照されます。 CSSは、ローカルホストキャッシュデータベースの情報がサイトデータベースの情報と一致することを確認します。ローカルホストキャッシュデータベースは、同期が発生するたびに再作成されます。

Controllerをインストールする場合、（ローカルホストキャッシュデータベースで使用するために）Microsoft SQL Server Express LocalDBが自動的にインストールされます（コマンドラインからControllerをインストールするときに、このインストールを禁止できます。）ローカルホストキャッシュデータベースをController間で共有することはできません。ローカルホストキャッシュデータベースのバックアップを作成する必要はありません。構成の変更が検出されるたびに再作成されます。
最後のチェック以降に変更が発生しなかった場合、データはコピーされません。

次の図に、プリンシパルブローカーがサイトデータベースとの接続を失った（停止状態が開始された）場合の通信径路の変化を示します。

停止状態におけるローカルホストキャッシュの通信経路図

停止状態中

停止が開始された場合：

セカンダリブローカーは、接続要求のリッスンと処理を開始します。
停止状態の開始時には、セカンダリブローカーに最新のVDA登録データはありませんが、VDAとの通信が始まると登録処理がトリガーされます。その処理中、セカンダリブローカーは、そのVDAに関する現在のセッション情報も取得します。
セカンダリブローカーが接続を処理する間も、プリンシパルブローカーは引き続き接続を監視します。接続が回復すると、プリンシパルブローカーはセカンダリブローカーに接続情報のリスニングを停止するように指示して、仲介操作を再開します。 VDAがプリンシパルブローカーと次に通信するときに、登録処理がトリガーされます。セカンダリブローカーは、前回の停止状態以降に残っているVDA登録をすべて削除します。 CSSは、展開内で構成が変更されたことを検出すると、情報の同期を再開します。

同期中に停止状態が開始されるという可能性の低い事象では、その時点のインポートは破棄され、最新の既知の構成が使用されます。

イベントログには、同期および停止に関する情報が含まれます。

停止モードでの操作に時間制限は適用されませんが、

通常モードと停止モードとの間の移行は、既存のセッションには影響しません。新しいセッションの起動にのみ影響します。

意図的に停止を引き起こすこともできます。これを行う理由と方法について詳しくは、「停止状態の強制」を参照してください。

複数のControllerがあるサイト

CSSは、他のタスク同様、ゾーン内のすべてのControllerに関する情報を日常作業としてセカンダリブローカーに提供します（展開に複数のゾーンが含まれていない場合、このアクションはサイト内のすべてのControllerに影響します。）ゾーンの他のCloud Connectorで実行している各セカンダリブローカーは、この情報からすべてのピアセカンダリブローカーを把握します。

セカンダリブローカーは独立したチャネルで相互に通信します。これらのセカンダリブローカーは、実行しているマシンの完全修飾ドメイン名のアルファベット順の一覧を使用して、停止状態が発生したときにどのセカンダリブローカーがゾーン内の仲介操作を担当するかを決定（選出）します。停止状態中、すべてのVDAが、選出されたセカンダリブローカーに登録されます。選出されていないゾーン内のセカンダリブローカーは、受信接続とVDA登録要求を能動的に拒否します。

停止状態中に、選出されたセカンダリブローカーに障害が発生した場合、別のセカンダリブローカーが選出されて処理を引き継ぎ、VDAは新しく選出されたセカンダリブローカーに登録されます。

停止状態中にControllerを再起動した場合：

このControllerが選出されたブローカーでない場合は、再起動しても影響はありません。
このControllerが選出されたブローカーである場合、別のControllerが選出され、VDAはそちらに登録されます。再起動したControllerの電源がオンになると、このControllerが自動的にブローカーを引き継ぐため、VDAは再度登録されます。このシナリオでは、登録中にパフォーマンスに影響が生じることがあります。

ブローカーに選出したControllerを、通常の操作中に電源を切ってから停止状態中に電源を入れると、ローカルホストキャッシュをこのController上で使用することはできません。

イベントログには、選出に関する情報が含まれます。

停止状態中にできなくなること、およびその他の相違点

停止モードでの操作に時間制限は適用されませんが、ただし、接続をできるだけ早く復元することをお勧めします。

停止状態中：

Studioは使用できません。
PowerShell SDKへのアクセスが制限されます。
- 次のことを最初に行う必要があります：
  - レジストリキーEnableCssTestModeを値1で追加します：New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTestMode -PropertyType DWORD -Value 1
  - ポート89を使用します：Get-BrokerMachine -AdminAddress localhost:89 | Select MachineName, ControllerDNSName, DesktopGroupName, RegistrationState
- これらのコマンドを実行すると、次のものを使用できるようになります：
  - すべてのGet-Broker*コマンドレット。
ハイパーバイザー資格情報をホストサービスから取得できません。すべてのマシンの電力状態が不明で、電源操作を発行できません。ただし、電源が入っているホスト上のVMを接続要求のために使用することができます。
割り当てられたマシンは、通常の操作中に割り当てが発生した場合のみ使用できます。停止状態中は新しい割り当てはできません。
リモートPCアクセスマシンの自動登録と構成はできません。ただし、通常の操作中に登録、構成されたマシンは使用できます。
サーバーでホストされるアプリケーションとデスクトップのユーザーは、リソースが異なるゾーンにある場合、構成されている最大セッション数よりも多くのセッションを使用できる場合があります。
ユーザーは、現在アクティブな、または選出されているセカンダリブローカーを含むゾーン内の登録済みVDAからのみ、アプリケーションとデスクトップを起動できます。停止中は、ゾーン間での起動（あるゾーンのセカンダリブローカーから別のゾーンのVDAへ）はサポートされません。
デリバリーグループ内のVDAに対してスケジュールされた再起動が開始される前にサイトデータベースの停止が発生した場合、停止が終了すると再起動が開始されます。これは意図しない結果につながる可能性があります。詳しくは、「データベースの停止によるスケジュールされた再起動の遅延」を参照してください。
［ゾーン優先度］を構成できません。構成されていても、環境設定はセッション起動では考慮されません。
タグを使用してゾーンを指定するタグ制限機能は、セッション起動ではサポートされていません。このタグ制限が構成されていて、StoreFrontストアの［詳細なヘルスチェック］オプションが有効になっている場合、セッションが断続的に起動に失敗することがあります。

アプリケーションとデスクトップのサポート

LHCは次の種類のVDAと配信モデルをサポートしています：

VDAの種類	配信モデル	LHCイベント中のVDAの可用性
マルチセッションOS	アプリケーションとデスクトップ	常に利用できます。
シングルセッションOS静的（割り当て済み）	デスクトップ	常に利用できます。
電源管理されたシングルセッションOSランダム（プール）	デスクトップ	デフォルトでは利用できません。プールされたデリバリーグループ内の電源管理されたVDAに対する、すべてのセッション起動の試みは、デフォルトで失敗します。 LHCイベント中の新しい接続で利用可能にできます。詳しくは、「Web Studioを使用した有効化」および「PowerShellを使用した有効化」を参照してください。重要：電源管理された、シングルセッションのプールされたマシンへのアクセスを有効にすると、以前のユーザーセッションからのデータと変更が後続のセッションに残る可能性があります。

注：

プールされたデリバリーグループ内の電源管理されたデスクトップVDAへのアクセスを有効にしても、通常の操作中に構成されたShutdownDesktopsAfterUseプロパティの機能結果には影響しません。 LHC中にこれらのデスクトップへのアクセスが有効になっている場合、LHCイベントの完了後、VDAは自動的に再起動しません。プールされたデリバリーグループ内の電源管理されたデスクトップVDAは、再起動するまで以前のセッションのデータを保持できます。 VDAの再起動は、ユーザーがLHC以外の操作中にVDAからログオフしたとき、または管理者がVDAを再起動したときに発生することがあります。

Web Studioを使用し、電源管理されたシングルセッションOSのプールされたVDAに対してLHCを有効にする

Web Studioを使用すると、デリバリーグループごとに、LHCイベント中にこれらのマシンを新しい接続で利用できるようになります：

デリバリーグループの作成中にこの機能を有効にするには、「デリバリーグループの作成」を参照してください。
既存のデリバリーグループでこの機能を有効にするには、「デリバリーグループの管理」を参照してください。

注：

この設定は、電源管理されたVDAを配信するプールされたデスクトップデリバリーグループに対する、Web Studioでのみ使用できます。

PowerShellを使用し、電源管理されたシングルセッションOSのプールされたVDAに対してLHCを有効にします

特定のデリバリーグループ内のVDAに対してLHCを有効にするには、次の手順を実行します：

次のコマンドを実行して、サイトレベルでこの機能を有効にします：

Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true
デリバリーグループ名を指定してこのコマンドを実行し、デリバリーグループのLHCを有効にします：

Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $true

電源管理されたVDAを含む新しく作成されたプールされたデリバリーグループで、デフォルトのLHCの可用性を変更するには、次のコマンドを実行します：

Set-BrokerSite -DefaultReuseMachinesWithoutShutdownInOutage $true

RAMサイズの考慮事項

LocalDBサービスは、約1.2GBのRAM（データベースキャッシュ用に最大1GB、SQL Server Express LocalDBの実行用にさらに200MB）を使用できます。セカンダリブローカーは、停止状態が長時間続き、多数のログオンが発生した場合（たとえば12時間でユーザー数1万人）、最大1GBのRAMを使用できます。これらのメモリ要件はControllerの通常のRAM要件とは別なので、RAMの総容量を増やす必要がある場合があります。

サイトデータベースにSQL Server Expressインストールを使用する場合、サーバーに2つのsqlserver.exeプロセスを持つ点に注意してください。

CPUコアとソケットの構成に関する考慮事項

ControllerのCPU構成、特にSQL Server Express LocalDBが利用できるコア数は、メモリ割り当て以上に、ローカルホストキャッシュのパフォーマンスに直接影響を及ぼします。このCPUオーバーヘッドが発生するのは、データベースとの接続が失われ、セカンダリブローカーがアクティブである停止状態の間だけです。

LocalDBは複数のコア（最大4つ）を使用できますが、単一のソケットだけに制限されます。ソケットを追加しても（たとえば、4つのソケットにそれぞれ1つのコア）、パフォーマンスは向上しません。それよりも複数のコアを持つ複数のソケットの使用をCitrixではお勧めします。 Citrixのテストでは、2x3（2つのソケット、3つのコア）の構成が、4x1および6x1の構成より良好なパフォーマンスを示しました。

ストレージの考慮事項

ユーザーが停止状態の間にリソースにアクセスすると、LocalDBは増大します。たとえば、1秒に10回ログオンするログオン/ログオフテスト実行では、データベースは2～3分に1MB増大しました。通常の操作が再開すると、ローカルデータベースが再作成され、容量は元に戻ります。ただし、停止状態の間のデータベース増大を考慮に入れ、LocalDBがインストールされるドライブ上に、十分な空き領域がある必要があります。ローカルホストキャッシュを使用すると、停止状態中に追加のI/Oが生じます（数十万の読み取りで、1秒あたり約3MBの書き込み）。

パフォーマンスについての考慮事項

停止状態中は1つのセカンダリブローカーがすべての接続を処理するため、通常の操作時に複数のControllerに負荷を分散するサイト（あるいは、ゾーン）では、停止状態中に、選出されたセカンダリブローカーが普通よりはるかに多くの要求を処理する必要があることがあります。このため、CPUへの要求が高くなります。停止状態中に選出されたセカンダリブローカーが変更される可能性があるため、サイト（ゾーン）内のすべてのセカンダリブローカーが、ローカルホストキャッシュデータベースと影響を受けるすべてのVDAによって課される追加の負荷を処理できる必要があります。

VDIの制限事項：

単一ゾーンにVDIを展開する場合、停止状態時には最大10,000のVDAを効果的に処理できます。
複数ゾーンにVDIを展開する場合、停止状態時には各ゾーンで最大10,000のVDA、サイト全体では最大40,000のVDAを効果的に処理できます。たとえば次のそれぞれのサイトが、停止状態時に効果的に処理されます。
- 4つのゾーンそれぞれに10,000のVDAが含まれるサイト。
- 1つのゾーンには10,000のVDAが含まれ、残り6つのゾーンにはそれぞれ5,000のVDAが含まれる、合計7つのゾーンからなるサイト。

停止状態中に、サイト内の負荷管理が影響を受ける可能性があります。負荷評価基準（特にセッション数規則）を超過する可能性があります。

すべてのVDAがセカンダリブローカーに登録する間、そのサービスは現在のセッションの一部を把握できなくなる場合があります。このため、その間の接続要求により、既存のセッションへの再接続が可能であっても、新しいセッションが起動される可能性があります。こうした時間（「新しい」セカンダリブローカーが再登録時にすべてのVDAからセッション情報を取得する時間）が発生するのは避けられません。停止状態の開始時に接続していたセッションは移行期間に影響を受けることはありませんが、新しいセッションおよびセッション再接続は影響を受ける可能性があります。

この期間は、VDAの登録が必要なときには必ず発生します：

停止状態の開始：プリンシパルブローカーからセカンダリブローカーに移行するとき。
停止状態中にセカンダリブローカーに障害が発生した場合：障害が発生したセカンダリブローカーから新しく選出されたセカンダリブローカーに移行するとき
停止からの回復：通常の操作が再開し、プリンシパルブローカーが制御を再開したとき。

Citrix Broker ProtocolのHeartbeatPeriodMsレジストリ値（デフォルト = 600000ms（10分））を小さくすることによって期間を短縮できます。このハートビート値は、VDAがpingに使用する間隔の2倍であるため、デフォルト値では5分ごとにpingが発生します。

たとえば、ハートビートを5分（300000ms）に変更するには、次のコマンドを実行します。このようにすると、pingは2.5分ごとに発生します：

New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer -Name HeartbeatPeriodMs -PropertyType DWORD –Value 300000

ハートビート値を変更するときは注意が必要です。頻度を増やすと、通常モードと停止モードのどちらの間でも、Controllerの負荷が増加します。

VDAの登録をどんなに早くしても、間隔を完全になくすことはできません。

セカンダリブローカー間の同期にかかる時間は、オブジェクト（VDA、アプリケーション、グループなど）の数により増加します。たとえば、5,000個のVDAを同期する場合には、10分以上かかる可能性があります。

XenApp 6.xリリースとの相違点

このローカルホストキャッシュ実装は、XenApp 6.x以前のXenAppリリースのローカルホストキャッシュ機能の名前を共有しますが、大幅に改善されています。この実装は、破損に対してより頑強で耐性もあります。定期的にdsmaintコマンドを実行する必要がないなど、メンテナンス要件が最小になります。このローカルホストキャッシュは技術的にはまったく異なる実装です。

ローカルホストキャッシュの管理

ローカルホストキャッシュを正常に動作させるには、各Controller上のPowerShell実行ポリシーを、RemoteSigned、Unrestricted、またはBypassに設定する必要があります。

SQL Server Express LocalDB

ローカルホストキャッシュが使用するMicrosoft SQL Server Express LocalDBソフトウェアは、Controllerをインストールするか、Controllerを7.9以前のバージョンからアップグレードするときに、自動的にインストールされます。セカンダリブローカーだけがこのデータベースと通信します。 PowerShellコマンドレットを使用して、このデータベースに関する変更を行うことはできません。 LocalDBは、Controller間で共有できません。

SQL Server Express LocalDBデータベースソフトウェアは、ローカルホストキャッシュが有効かどうかに関係なくインストールされます。

このインストールを防止するには、Controllerのインストールまたはアップグレード時に、XenDesktopServerSetup.exeコマンドで「/exclude "Local Host Cache Storage (LocalDB)"」オプションを使用します。ただし、ローカルホストキャッシュ機能はデータベースがないと機能しないことと、セカンダリブローカーでは異なるデータベースを使用できないことに注意してください。

このLocalDBデータベースのインストールは、サイトデータベースとして使うためにSQL Server Expressをインストールするかどうかには影響しません。

以前のバージョンのSQL Server Express LocalDBを新しいバージョンに置き換える方法について詳しくは、「SQL Server Express LocalDBの置き換え」を参照してください。

製品のインストールとアップグレード後のデフォルト設定

Citrix Virtual Apps and Desktops（バージョン7.16以降）の新規インストール時に、ローカルホストキャッシュが有効になります。

アップグレード（バージョン7.16以降へ）後は、展開全体に10,000個未満のVDAが存在する場合に、ローカルホストキャッシュが有効になります。

ローカルホストキャッシュの有効化と無効化

ローカルホストキャッシュを有効化するには、次のように入力します：

Set-BrokerSite -LocalHostCacheEnabled $true

ローカルホストキャッシュが有効かどうかを判断するには、Get-BrokerSiteを入力します。 LocalHostCacheEnabledプロパティがTrueであることを確認します。
ローカルホストキャッシュを無効にするには、次のように入力します。

Set-BrokerSite -LocalHostCacheEnabled $false

注意：XenAppおよびXenDesktop 7.16より、接続リース機能（バージョン7.6以降に提供されていた、ローカルホストキャッシュに先行する機能）は削除され、使用できなくなりました。

ローカルホストキャッシュが動作していることを確認する

ローカルホストキャッシュが適切に設定され動作していることを確認するには：

同期のインポートが正常に完了していることを確認します。イベントログをチェックします。
SQL Server Express LocalDBデータベースがDelivery Controllerごとに作成されたことを確認します。これにより、必要に応じてセカンダリブローカーが処理を引き継げるようになります。
- Delivery Controllerサーバーで、C:\Windows\ServiceProfiles\NetworkServiceに移動します。
- HaDatabaseName.mdfおよびHaDatabaseName_log.ldfが作成されていることを確認します。
Delivery Controllerに停止状態を強制します。ローカルホストキャッシュが動作することを確認したら、すべてのControllerを通常モードに戻します。これには約15分かかります。

イベントログ

イベントログに、同期および停止状態が発生した時刻が示されます。イベントビューアーのログでは、停止状態モードはHAモードと見なされます。

Config Synchronizer Service：

通常の操作中、ローカルホストキャッシュブローカーを使用してCSSが構成データをローカルホストキャッシュデータベースにインポートすると次のイベントが発生することがあります。

503：Citrix Config Sync Serviceが更新された構成を受信しました。このイベントは、同期プロセスが開始されたことを表します。
504：Citrix Config Sync Serviceが更新された構成をインポートしました。構成のインポートが正常に完了しました。
505：Citrix Config Sync Serviceがインポートに失敗しました。構成のインポートが正常に完了しませんでした。過去に正常にインポートされた構成がある場合、停止状態の発生時にはその構成が使用されます。ただし、この構成は現在の構成よりも古いものです。使用可能な過去の構成がない場合、停止状態中、サービスはセッション仲介に参加できません。この場合は、「トラブルシューティング」セクションを確認の上、Citrixサポートにお問い合わせください。
507：システムが停止状態であり、ローカルホストキャッシュブローカーが使用中であるため、Citrix Config Sync Serviceによりインポートが中止されました。サービスは新しい構成を受け取りましたが、停止状態が発生したためインポートは中止されました。これは正常な動作です。
510：プライマリ構成サービスから構成サービス構成データを受信していません。
517：プライマリブローカーとの通信に問題がありました。
518：セカンダリブローカー（High Availability Service）が実行されていないため、Config Syncスクリプトが中止されました。

High Availability Service：

このサービスは、ローカルホストキャッシュブローカーとも呼ばれます。

3502：停止状態が発生しローカルホストキャッシュブローカーが仲介操作を実行しています。
3503：停止状態が解消され、通常の操作が再開しました。
3504：どのローカルホストキャッシュブローカーが選出されたかと、選出に関わった他のローカルホストキャッシュブローカーを示します。
3507：ローカルホストキャッシュの更新された状態情報を2分ごとに提供します。この情報は、選択されたブローカーでローカルホストキャッシュモードがアクティブであることを示すものです。停止時間、VDA登録、セッション情報など、停止の概要も含まれます。
3508：選択されたブローカー上でローカルホストキャッシュがアクティブではなくなり、通常の操作が復元されたことを通知します。停止時間、ローカルホストキャッシュ（LHC）イベント中に登録されたマシンの数、LHCイベント中に成功した起動の数など、停止の概要も含まれます。
3509：選択されていないブローカー上でローカルホストキャッシュがアクティブであることを通知します。 2分ごとの停止時間と選択されているブローカーも通知します。
3510：選択されていないブローカー上でローカルホストキャッシュがアクティブでなくなったことを通知します。停止時間と選択されているブローカーも通知します。

停止状態の強制

停止状態は意図的に発生させることもできます。

ネットワークが稼動と停止を繰り返している場合。ネットワークの問題が解決するまで強制的に停止状態にすることにより、通常モードと停止状態モードの移行が繰り返され、VDA登録ストームが頻繁に発生するのを防げます。
障害回復プランをテストするには：
ローカルホストキャッシュが正常に動作することを確認する場合。
サイトデータベースサーバーの交換または修理中。

停止状態を強制するには、Delivery Controllerを含む各サーバーのレジストリを編集します。 HKLM\Software\Citrix\DesktopServer\LHCでOutageModeForcedを作成し、REG_DWORDを1に設定します。この設定により、ローカルホストキャッシュブローカーはデータベースの状態に関係なく停止状態モードに入るよう指示されます。値を0に設定すると、ローカルホストキャッシュブローカーの停止状態モードは終了します。

イベントを確認するには、C:\ProgramData\Citrix\WorkspaceCloud\Logs\Plugins\HighAvailabilityServiceのCurrent_HighAvailabilityServiceログファイルを監視します。

トラブルシューティング

ローカルホストキャッシュデータベースへの同期インポートが失敗し505イベントがポストされた場合には、次のトラブルシューティングツールが役立ちます。

CDFトレース：ConfigSyncServerモジュールおよびBrokerLHCモジュール向けのオプションが用意されています。それらのオプションと他のブローカーモジュールの組み合わせで問題を識別できるはずです。

レポート： 同期インポートが失敗した場合は、レポートを生成できます。このレポートの最後に、エラーの原因となったオブジェクトが記載されています。このレポート機能は同期速度に影響するため、Citrixでは使用しないときは無効にしておくことをお勧めします。

CSSトレースレポートを有効化および作成するには、次のコマンドを入力します：

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

HTMLレポートは、C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\CitrixBrokerConfigSyncReport.htmlに格納されます。

レポートが生成されたら、次のコマンドを入力してレポート機能を無効にします：

Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -Value 0

ブローカー構成のエクスポート： デバッグのために正確な構成を提供します。

Export-BrokerConfiguration | Out-File <file-pathname>

たとえば、Export-BrokerConfiguration | Out-File C:\\BrokerConfig.xmlなどです。

ローカルホストキャッシュ用のPowerShellコマンド

PowerShellコマンドを使用して、 Delivery Controller上のローカルホストキャッシュ (LHC) を管理できます。

PowerShellモジュールは、Delivery Controller上の次の場所にあります。

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

重要:

このモジュールはDelivery Controller上でのみ実行してください。

PowerShellモジュールのインポート

PowerShellモジュールをインポートするには、Delivery Controllerで次のコマンドを実行します。

cd C:\Program Files\Citrix\Broker\Service\ControlScripts Import-Module .\HighAvailabilityServiceControl.psm1

LHCを管理するためのPowerShellコマンド

以下のコマンドは、Delivery ControllerでLHCモードをアクティブ化して管理するのに役立ちます。

コマンドレット	機能
`Enable-LhcForcedOutageMode`	ブローカーをLHCモードにします。 `Enable-LhcForcedOutageMode`が正しく機能するには、LHCデータベースファイルがConfigSync Serviceによって正常に作成されている必要があります。このコマンドレットは、LHCが実行されていたDelivery Controllerでのみ、LHCを強制的にアクティブ化します。 LHCをアクティブ化するには、ゾーン内のすべてのDelivery Controllerでこのコマンドを実行する必要があります。
`Disable-LhcForcedOutageMode`	ブローカーのLHCモードを解除します。このコマンドレットは、LHCが実行されていたDelivery Controllerでのみ、LHCモードを無効にします。 `Disable-LhcForcedOutageMode`は、ゾーン内のすべてのDelivery Controllerで実行する必要があります。
`Set-LhcConfigSyncIntervalOverride`	Citrix Config Synchronizer Service（CSS）がサイト内に構成変更がないかをチェックする間隔を設定します。時間間隔の範囲は60秒（1分）～3600秒（1時間）です。この設定は、LHCが実行されていたDelivery Controllerにのみ適用されます。 Delivery Controller間の一貫性を確保するには、すべてのDelivery Controllerでこのコマンドレットを実行してください。例：`Set-LhcConfigSyncIntervalOverride -Seconds 1200`
`Clear-LhcConfigSyncIntervalOverride`	Citrix Config Synchronizer Service（CSS）がサイト内に構成変更がないかをチェックする間隔をデフォルト値の300秒（5分）に設定します。この設定は、LHCが実行されていたDelivery Controllerにのみ適用されます。 Delivery Controller間の一貫性を確保するには、すべてのDelivery Controllerでこのコマンドレットを実行してください。
`Enable-LhcHighAvailabilitySDK`	LHCが実行されていたDelivery Controller内で、すべての`Get-Broker*`コマンドレットへのアクセスを有効にします。
`Disable-LhcHighAvailabilitySDK`	LHCが実行されていたDelivery Controller内で、ブローカーコマンドレットへのアクセスを無効にします。

注：

Delivery ControllerでGet-Broker*コマンドレットを実行する場合は、ポート89を使用します。次に例を示します：

Get-BrokerMachine -AdminAddress localhost:89

LHCモードではないDelivery ControllerのLHCブローカーは、構成情報のみを保持しています。

LHCモード中、選択されたDelivery ControllerのLHCブローカーは次の情報を保持しています。

リソースの状態

セッションの詳細

VDA登録

構成情報

この製品ドキュメントの正式なバージョンは英語版です。英語以外のすべてのバージョンは、お客様の利便性のためにのみ提供され、機械翻訳された内容が含まれている場合があります。詳しくは、Cloud Software Group home で機械翻訳に関する免責事項（Machine Translation Disclaimer）をご覧ください。

この情報は役に立ちましたか?

ローカルホストキャッシュ

November 25, 2025

寄稿者:

November 25, 2025

寄稿者:

この情報は役に立ちましたか?