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

Citrix Virtual Apps and Desktopsサイトデータベースが常に利用可能であることを保証するため、CitrixはMicrosoftの可用性の高いベストプラクティスに従い、フォールトトレラントなSQL Server展開から始めることを推奨します。（サポートされているSQL Serverの高可用性機能については、データベースを参照してください。）しかし、ネットワークの問題や中断により、ユーザーがアプリケーションやデスクトップに接続できなくなる可能性があります。

ローカルホストキャッシュ機能により、障害発生時でもサイト内の接続仲介操作を続行できます。障害は、オンプレミスのCitrix®環境でDelivery Controller™とサイトデータベース間の接続が失敗したときに発生します。サイトデータベースに90秒間アクセスできない場合、ローカルホストキャッシュが有効になります。

XenAppおよびXenDesktop 7.16以降、接続リース機能（以前のリリースにおける先行の高可用性機能）は製品から削除され、利用できなくなりました。

データコンテンツ

ローカルホストキャッシュには、メインデータベースの情報の一部である以下の情報が含まれます。

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

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

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

仕組み

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

通常の操作中のローカルホストキャッシュの通信パスの図(/ja-jp/citrix-virtual-apps-desktops/2507-ltsr/media/lhc-normal1.png)

通常の操作中

• Controller上のプライマリブローカー (Citrix Broker Service) は、StoreFrontからの接続要求を受け入れます。ブローカーはサイトデータベースと通信し、Controllerに登録されているVDAとユーザーを接続します。
• Citrix Config Synchronizer Service (CSS) は、約5分ごとにブローカーに問い合わせて、変更があったかどうかを確認します。これらの変更は、管理者によって開始されたもの（デリバリーグループのプロパティの変更など）またはシステムアクション（マシン割り当てなど）である可能性があります。

• 前回の確認以降に構成変更があった場合、CSSは情報をController上のセカンダリブローカーに同期（コピー）します。（セカンダリブローカーは高可用性サービスとも呼ばれます。）

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

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

• 前回の確認以降に変更がない場合、データはコピーされません。

以下の図は、プライマリブローカーがサイトデータベースとの接続を失った場合（停止が開始された場合）の通信パスの変更を示しています。

停止中のローカルホストキャッシュの通信パスの図(/ja-jp/citrix-virtual-apps-desktops/2507-ltsr/media/lhc-outage1.png)

障害発生時

停止が開始されると：

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

同期中に障害が発生するという万が一の事態が発生した場合、現在のインポートは破棄され、最後に認識された構成が使用されます。

(#event-logs)には、同期と障害に関する情報が記載されています。

障害モードでの運用に時間制限はありません。

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

意図的に障害をトリガーすることもできます。その理由と方法の詳細については、障害の強制を参照してください。

複数のControllerがあるサイト

CSSは、他のタスクの中でも、ゾーン内のすべてのControllerに関する情報をセカンダリブローカーに定期的に提供します。（展開に複数のゾーンが含まれていない場合、このアクションはサイト内のすべてのControllerに影響します。）その情報を持つことで、各セカンダリブローカーは、ゾーン内の他のControllerで実行されているすべてのピアセカンダリブローカーについて認識しています。

セカンダリブローカーは、別のチャネルで相互に通信します。これらのブローカーは、実行されているマシンのFQDN名のアルファベット順リストを使用して、障害が発生した場合にゾーンでブローカー操作を行うセカンダリブローカーを決定（選出）します。障害中、すべてのVDAは選出されたセカンダリブローカーに登録します。ゾーン内の選出されていないセカンダリブローカーは、受信接続およびVDA登録要求を積極的に拒否します。

障害中に選出されたセカンダリブローカーが失敗した場合、別のセカンダリブローカーが選出されて引き継ぎ、VDAは新しく選出されたセカンダリブローカーに登録します。

障害中にControllerが再起動された場合：

• そのControllerが選出されたブローカーでない場合、再起動による影響はありません。
• そのControllerが選出されたブローカーである場合、別のControllerが選出され、VDAが登録されます。再起動されたControllerが起動すると、自動的にブローカリングを引き継ぎ、VDAが再度登録されます。このシナリオでは、登録中にパフォーマンスが影響を受ける可能性があります。

通常操作中にControllerの電源をオフにし、障害中に電源をオンにした場合、そのControllerがブローカーとして選出されても、そのControllerではローカルホストキャッシュを使用できません。

(#event-logs)には、選出に関する情報が記載されています。

停止中に利用できないもの、およびその他の相違点

停止モードでの運用に時間制限はありません。ただし、Citrixは可能な限り迅速に接続を復元することを推奨します。

障害発生時：

• 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は、接続要求に使用できます。
• 割り当てられたマシンは、通常の操作中に割り当てが行われた場合にのみ使用できます。停止中に新しい割り当てを行うことはできません。
• Remote PC Accessマシンの自動登録と構成はできません。ただし、通常の操作中に登録および構成されたマシンは使用可能です。
• リソースが異なるゾーンにある場合、サーバーでホストされているアプリケーションおよびデスクトップのユーザーは、構成されたセッション制限よりも多くのセッションを使用する可能性があります。
• ユーザーは、現在アクティブ/選出されているセカンダリブローカーを含むゾーン内の登録済みVDAからのみアプリケーションとデスクトップを起動できます。停止中は、ゾーンをまたいだ起動（あるゾーンのセカンダリブローカーから別のゾーンのVDAへの起動）はサポートされません。
• デリバリーグループ内のVDAのスケジュールされた再起動が開始される前にサイトデータベースの停止が発生した場合、停止が終了したときに再起動が開始されます。これにより、意図しない結果が生じる可能性があります。詳しくは、「データベース停止により遅延するスケジュールされた再起動」を参照してください。
• ゾーン設定は構成できません。構成されている場合、セッション起動時に設定は考慮されません。
• タグがゾーンの指定に使用されるタグ制限は、セッション起動ではサポートされていません。このようなタグ制限が構成され、StoreFrontストアの高度なヘルスチェックオプションが有効になっている場合、セッションの起動が断続的に失敗することがあります。

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

LHCは、次の種類のVDAとデリバリーモデルをサポートしています。

注：

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

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

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

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

注：

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

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

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

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

   Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true

2. デリバリーグループ名を指定してこのコマンドを実行し、デリバリーグループに対してLHCを有効にします。

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

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

Set-BrokerSite -DefaultReuseMachinesWithoutShutdownInOutage $true

RAMサイズの考慮事項

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

サイトデータベースにSQL Server Expressインストールを使用する場合、サーバーには2つのsqlserver.exeプロセスがあります。

CPUコアとソケット構成の考慮事項

コントローラーのCPU構成、特にSQL Server Express LocalDBに利用可能なコアの数は、メモリ割り当てよりもさらに、ローカルホストキャッシュのパフォーマンスに直接影響します。このCPUオーバーヘッドは、データベースに到達できず、セカンダリブローカーがアクティブな停止期間中にのみ観測されます。

LocalDBは複数のコア（最大4つ）を使用できますが、単一のソケットに制限されています。ソケットを追加してもパフォーマンスは向上しません（たとえば、1コアずつ4つのソケットがある場合）。代わりに、Citrixは複数のコアを持つ複数のソケットを使用することを推奨しています。Citrixのテストでは、2x3（2ソケット、3コア）構成は4x1および6x1構成よりも優れたパフォーマンスを提供しました。

ストレージの考慮事項

停止中にユーザーがリソースにアクセスすると、LocalDBは増大します。たとえば、毎秒10ログオンで実行されるログオン/ログオフテスト中、データベースは2〜3分ごとに1 MB増加しました。通常の操作が再開されると、ローカルデータベースは再作成され、スペースは返却されます。ただし、停止中のデータベースの増大を許容するために、LocalDBがインストールされているドライブには十分なスペースが必要です。ローカルホストキャッシュは、停止中にさらに多くのI/Oを発生させます。これは、毎秒約3 MBの書き込みと数十万回の読み取りです。

パフォーマンスに関する考慮事項

障害発生時には、1つのセカンダリブローカーがすべての接続を処理するため、通常の運用中に複数のコントローラー間で負荷分散を行うサイト（またはゾーン）では、障害発生時に選出されたセカンダリブローカーが、通常よりもはるかに多くの要求を処理する必要がある場合があります。したがって、CPUの要求は高くなります。障害発生時に選出されるセカンダリブローカーは変更される可能性があるため、サイト（ゾーン）内のすべてのセカンダリブローカーは、ローカルホストキャッシュデータベースと影響を受けるすべてのVDAによって課される追加の負荷を処理できる必要があります。

VDIの制限：

• シングルゾーンVDI展開では、障害発生時に最大10,000台のVDAを効果的に処理できます。
• マルチゾーンVDI展開では、障害発生時に各ゾーンで最大10,000台のVDAを効果的に処理でき、サイト全体では最大40,000台のVDAまでです。たとえば、以下の各サイトは障害発生時に効果的に処理できます。
  • 4つのゾーンがあり、それぞれに10,000台のVDAが含まれるサイト。
  • 7つのゾーンがあり、1つに10,000台のVDA、残りの6つにそれぞれ5,000台のVDAが含まれるサイト。

障害発生時には、サイト内の負荷管理が影響を受ける可能性があります。負荷評価器（特にセッション数ルール）が超過する可能性があります。

すべてのVDAがセカンダリブローカーに登録するのにかかる時間の間、そのサービスは現在のセッションに関する完全な情報を持っていない可能性があります。そのため、その期間中のユーザー接続要求は、既存のセッションへの再接続が可能であったとしても、新しいセッションが起動される結果となる可能性があります。この期間（「新しい」セカンダリブローカーが再登録中にすべてのVDAからセッション情報を取得する間）は避けられません。障害発生時に接続されているセッションは、移行期間中に影響を受けませんが、新しいセッションやセッションの再接続は影響を受ける可能性があります。

この期間は、VDAが登録する必要がある場合に常に発生します。

• 障害の開始：プライマリブローカーからセカンダリブローカーに移行する場合。
• 障害発生中のセカンダリブローカーの障害：障害が発生したセカンダリブローカーから、新たに選出されたセカンダリブローカーに移行する場合。
• 障害からの復旧：通常の運用が再開され、プライマリブローカーが制御を再開する場合。

Citrix Broker ProtocolのHeartbeatPeriodMsレジストリ値を下げることで、この間隔を短縮できます（デフォルト = 600000ミリ秒、つまり10分）。このハートビート値は、VDAがpingに使用する間隔の2倍であるため、デフォルト値では5分ごとにpingが実行されます。

たとえば、次のコマンドはハートビートを5分（300000ミリ秒）に変更し、2.5分ごとにpingが実行されるようにします。

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

ハートビート値の変更には注意してください。頻度を上げると、通常モードと停止モードの両方でコントローラーへの負荷が増大します。

VDAがどれだけ迅速に登録されても、間隔を完全に排除することはできません。

セカンダリブローカー間の同期にかかる時間は、オブジェクト（VDA、アプリケーション、グループなど）の数が増えるにつれて長くなります。たとえば、5000個のVDAを同期するには、完了までに10分以上かかる場合があります。

XenApp 6.xリリースとの違い

このローカルホストキャッシュの実装は、XenApp 6.xおよびそれ以前のXenAppリリースにおけるローカルホストキャッシュ機能と同じ名前を共有していますが、大幅な改善が加えられています。この実装はより堅牢で、破損の影響を受けません。定期的なdsmaintコマンドの必要性を排除するなど、メンテナンス要件が最小限に抑えられています。このローカルホストキャッシュは、技術的には全く異なる実装です。

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

ローカルホストキャッシュが正しく機能するには、各コントローラーのPowerShell実行ポリシーをRemoteSigned、Unrestricted、またはBypassに設定する必要があります。

エスキューエルサーバー エクスプレス ローカルDB

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

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

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

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

以前のSQL Server Express LocalDBバージョンを新しいバージョンに置き換える方法については、Replace 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 and XenDesktop 7.16 以降、接続リース (バージョン 7.6 以降のローカルホストキャッシュに先行する機能) は製品から削除され、利用できなくなりました。

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

ローカルホストキャッシュが正しくセットアップされ、機能していることを確認するには：

• 同期インポートが正常に完了していることを確認します。イベントログ を確認します。
• 各 Delivery Controller に SQL Server Express LocalDB データベースが作成されていることを確認します。これにより、必要に応じてセカンダリブローカーが引き継ぐことができることが確認されます。
  • デリバリーコントローラーサーバーで、C:\Windows\ServiceProfiles\NetworkService に移動します。
  • HaDatabaseName.mdf と HaDatabaseName_log.ldf が作成されていることを確認します。
• 停止を強制するをDelivery Controllerで実行します。ローカルホストキャッシュが機能することを確認したら、すべてのControllerを通常モードに戻すことを忘れないでください。これには約15分かかる場合があります。

イベントログ

イベントログは、同期と停止が発生した時期を示します。イベントビューアーログでは、停止モードはHAモードと呼ばれます。*

構成同期サービス:

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

• 503: Citrix Config Sync Serviceが更新された構成を受信しました。このイベントは、同期プロセスの開始を示します。
• 504: Citrix Config Sync Serviceが更新された構成をインポートしました。構成のインポートが正常に完了しました。
• 505: Citrix Config Sync Serviceがインポートに失敗しました。構成のインポートが正常に完了しませんでした。以前に正常な構成が利用可能な場合、停止が発生するとそれが使用されます。ただし、現在の構成とは異なる古いものになります。以前の構成が利用できない場合、サービスは停止中にセッションブローカーに参加できません。この場合、トラブルシューティングセクションを参照し、Citrixサポートに連絡してください。
• 507: システムが停止モードであり、ローカルホストキャッシュブローカーがブローカー処理に使用されているため、Citrix Config Sync Serviceはインポートを中止しました。サービスは新しい構成を受信しましたが、停止が発生したためインポートは中止されました。これは予期される動作です。
• 510: プライマリ コンフィギュレーションサービスからコンフィギュレーションサービスの構成データが受信されませんでした。
• 517: プライマリBrokerとの通信に問題がありました。
• 518: セカンダリBroker (High Availability Service) が実行されていないため、Config Syncスクリプトが中止されました。

高可用性サービス:

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

• 3502: 停止が発生し、ローカルホストキャッシュブローカーがブローカー処理を実行しています。
• 3503: 停止が解決され、通常の操作が再開されました。
• 3504: どのローカルホストキャッシュブローカーが選出されたか、および選出に関与した他のローカルホストキャッシュブローカーを示します。
• 3507: 2分ごとにローカルホストキャッシュのステータス更新を提供し、選出されたブローカーでローカルホストキャッシュモードがアクティブであることを示します。停止期間、VDA登録、セッション情報を含む停止の概要が含まれます。
• 3508: 選出されたブローカーでローカルホストキャッシュがアクティブでなくなり、通常の操作が復元されたことを通知します。停止期間、ローカルホストキャッシュイベント中に登録されたマシンの数、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モジュールは、デリバリーコントローラーの次の場所にあります。

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

重要:

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

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

モジュールをインポートするには、Delivery Controllerで以下を実行します。

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

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

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

注:

• Delivery Controller で Get-Broker* cmdlet を実行するときは、ポート 89 を使用します。例:
  • Get-BrokerMachine -AdminAddress localhost:89
• LHC モードでない場合、Delivery Controller 上の LHC Broker は構成情報のみを保持します。
• LHC モード中、選出された Delivery Controller 上の LHC Broker は以下の情報を保持します。
  • リソースの状態
  • セッションの詳細
  • VDA 登録
  • 構成に関する情報