ローカルホストキャッシュ
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）は、ブローカーを毎分チェックして、構成に変更がないか確認します。こうした変更には、管理者によるもの（デリバリーグループのプロパティの変更など）とシステム操作（マシン割り当てなど）があります。
-
前回のチェック以降に構成が変更された場合、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に影響します）。その情報により、各セカンダリブローカーは、ゾーン内のその他のControllerで実行される同じ立場にあるすべてのセカンダリブローカーを認識します。
セカンダリブローカーは独立したチャネルで相互に通信します。これらのセカンダリブローカーは、実行しているマシンの完全修飾ドメイン名のアルファベット順の一覧を使用して、停止状態が発生したときにどのセカンダリブローカーがゾーン内の仲介操作を担当するかを決定（選出）します。停止状態中、すべての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*コマンドレット。 - 電源管理コマンドレット
New-BrokerHostingPowerAction、Set-BrokerHostingPowerAction、およびRemove-BrokerHostingPowerAction。
- すべての
- 次のことを最初に行う必要があります：
- ハイパーバイザー資格情報をホストサービスから取得できません。すべてのマシンの電力状態が不明で、電源操作を発行できません。ただし、電源が入っているホスト上のVMを接続要求のために使用することができます。
- 割り当てられたマシンは、通常の操作中に割り当てが発生した場合のみ使用できます。停止状態中は新しい割り当てはできません。
- リモートPCアクセスマシンの自動登録と構成はできません。ただし、通常の操作中に登録、構成されたマシンは使用できます。
- サーバーでホストされるアプリケーションとデスクトップのユーザーは、リソースが異なるゾーンにある場合、構成されている最大セッション数よりも多くのセッションを使用できる場合があります。
- ユーザーは、現在アクティブな、または選出されているセカンダリブローカーを含むゾーン内の登録済みVDAからのみ、アプリケーションとデスクトップを起動できます。停止中は、ゾーン間での起動（あるゾーンのセカンダリブローカーから別のゾーンのVDAへ）はサポートされません。
- デリバリーグループ内のVDAに対してスケジュールされた再起動が開始される前にサイトデータベースの停止が発生した場合、停止が終了すると再起動が開始されます。これは意図しない結果につながる可能性があります。詳しくは、「データベースの停止によるスケジュールされた再起動の遅延」を参照してください。
- ［ゾーン優先度］を構成できません。構成されていても、環境設定はセッション起動では考慮されません。
- タグを使用してゾーンを指定するタグ制限機能は、セッション起動ではサポートされていません。このタグ制限が構成されていて、StoreFrontストアの ［詳細なヘルスチェック］ オプションが有効になっている場合、セッションが断続的に起動に失敗することがあります。
アプリケーションとデスクトップのサポート
ローカルホストキャッシュは、サーバーでホストされるアプリケーションおよびデスクトップ、および静的な（割り当て済み）デスクトップをサポートします。
ローカルホストキャッシュは、以下のようにプールされたデリバリーグループでデスクトップVDAをサポートします：
-
デフォルトでは、停止状態が発生した場合、「
ShutdownDesktopsAfterUse」プロパティが有効なプールされたデリバリーグループ内で電源管理されているデスクトップVDA（MCSまたはCitrix Provisioningによって作成）は、メンテナンスモードになります。このデフォルトの設定を変更して、停止状態中にこれらのデスクトップを使用できるようにすることができます。ただし、停止状態中は電源管理が機能しないことがあります。（通常の操作を開始すると電源管理が始まります）。また、これらのデスクトップは再起動していないため、前のユーザーのデータが含まれている可能性があります。
-
デフォルトの動作を上書きするには、サイト全体で、影響を受けるデリバリーグループごとに、これを有効にする必要があります。次のPowerShellコマンドレットを実行します。
サイト全体：
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true影響を受ける各デリバリーグループに対して、次のPowerShellコマンドを実行します：
Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $trueこの機能をサイトでデリバリーグループごとに有効にしても、構成済みの
ShutdownDesktopsAfterUseプロパティの、通常操作時の動作には影響がありません。この機能を有効にすると、LHCイベントの完了後にVDAは自動的に再起動しません。プールされたデリバリーグループ内の電源管理されたデスクトップVDAは、再起動されるまで以前のセッションのデータを保持できます。これは、ユーザーがLHC以外の操作中にVDAからログオフした場合、または再起動が手動でトリガーされた場合に発生する可能性があります。
重要：
サイトレベルでReuseMachinesWithoutShutdownInOutageAllowedを有効にし、デリバリーグループレベルでReuseMachinesWithoutShutdownInOutageを有効にしないと、プールされたデリバリーグループ内の電源管理されたデスクトップVDAに対するすべてのセッション起動の試みが、ローカルホストキャッシュイベント中に失敗します。
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サーバーで、
- 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。