VDA登録

はじめに

注:

オンプレミス環境では、VDAはDelivery Controllerに登録します。Citrix Cloudサービス環境では、VDAはCloud Connectorに登録します。ハイブリッド環境では、一部のVDAはDelivery Controllerに登録し、他のVDAはCloud Connectorに登録します。

VDAを使用する前に、サイト上の1つ以上のControllerまたはCloud Connectorに登録（通信を確立）する必要があります。VDAは、ListofDDCsと呼ばれるリストをチェックしてControllerまたはConnectorを見つけます。VDA上のListOfDDCsには、そのVDAをサイト上のControllerまたはCloud ConnectorにポイントするDNSエントリが含まれています。負荷分散のため、VDAはリスト内のすべてのControllerまたはCloud Connectorに接続を自動的に分散します。

VDA登録がこれほど重要なのはなぜでしょうか？

• セキュリティの観点から見ると、登録は機密性の高い操作です。ControllerまたはCloud ConnectorとVDA間の接続を確立しています。このような機密性の高い操作では、すべてが完璧な状態でない場合、接続を拒否するのが期待される動作です。VDAからControllerまたはCloud Connectorへ、そしてControllerまたはCloud ConnectorからVDAへという、2つの別々の通信チャネルを効果的に確立しています。接続にはKerberosが使用されるため、時刻同期やドメインメンバーシップの問題は許されません。Kerberosはサービスプリンシパル名（SPN）を使用するため、負荷分散されたIP\ホスト名を使用することはできません。
• Controller（またはCloud Connector）を追加および削除する際に、VDAが正確で最新のControllerまたはCloud Connector情報を持っていない場合、VDAはリストにないControllerまたはCloud Connectorによって仲介されたセッション起動を拒否する可能性があります。無効なエントリは、仮想デスクトップシステムソフトウェアの起動を遅らせる可能性があります。VDAは、不明で信頼できないControllerまたはCloud Connectorからの接続を受け入れません。

ListofDDCsに加えて、ListOfSIDs（セキュリティID）は、ListofDDCs内のどのマシンが信頼されているかを示します。ListofSIDsは、Active Directoryへの負荷を軽減したり、侵害されたDNSサーバーからの潜在的なセキュリティ脅威を回避したりするために使用できます。詳細については、ListOfSIDsを参照してください。

ListofDDCsが複数のControllerまたはCloud Connectorを指定している場合、VDAはランダムな順序でそれらに接続を試みます。オンプレミス展開では、ListofDDCsにはControllerグループを含めることもできます。VDAは、ListofDDCs内の他のエントリに移動する前に、グループ内の各Controllerに接続を試みます。

Citrix Virtual Apps and Desktops™は、VDAインストール中に構成されたControllerまたはCloud Connectorへの接続を自動的にテストします。ControllerまたはCloud Connectorに到達できない場合、エラーが表示されます。ControllerまたはCloud Connectorに接続できないという警告を無視した場合（またはVDAインストール中にControllerまたはCloud Connectorアドレスを指定しなかった場合）、メッセージが表示されて通知されます。

コントローラーまたはクラウドコネクタのアドレスを構成する方法

管理者は、VDAが初めて登録する際（初回登録時）に使用する構成方法を選択します。初回登録時に、VDA上に永続的なキャッシュが作成されます。その後の登録では、構成の変更が検出されない限り、VDAはこのローカルキャッシュからControllerまたはCloud Connectorのリストを取得します。

その後の登録でそのリストを取得する最も簡単な方法は、自動更新機能を使用することです。自動更新はデフォルトで有効になっています。詳細については、「自動更新」を参照してください。

VDA上でControllerまたはCloud Connectorアドレスを構成する方法はいくつかあります。

• ポリシーベース (LGPO または GPO)
• レジストリベース (手動、グループポリシー基本設定 (GPP)、VDA インストール時に指定)
• アクティブディレクトリ OU ベース (従来の OU 検出)
• エムシーエスを基盤とする (personality.ini)

VDA をインストールするときに、初期登録方法を指定します。(自動更新を無効にすると、VDA インストール時に選択した方法が以降の登録に使用されます。)

次の図は、VDA インストールウィザードの Delivery Controller ページを示しています。

VDA インストールウィザードの Delivery Controller ページを示す図(/ja-jp/citrix-virtual-apps-desktops/2411/media/vda-install-controllers-all.png)

ポリシーベース (LGPO\GPO)

Citrix® は、初期 VDA 登録に GPO を使用することを推奨しています。これは最も高い優先順位を持ちます。(自動更新が最も高い優先順位としてリストされていますが、自動更新は初期登録後にのみ使用されます。) ポリシーベースの登録は、構成にグループポリシーを使用することによる一元化の利点を提供します。

この方法を指定するには、次の両方の手順を完了します。

• VDA インストールウィザードの Delivery Controller ページで、後で実行 (詳細) を選択します。ウィザードは、VDA インストール中にコントローラーアドレスを指定しない場合でも、コントローラーアドレスを指定するように何度か通知します。(VDA 登録はそれほど重要です。)
• Virtual Delivery Agent Settings > Controllers 設定を使用して、Citrix ポリシーを介してポリシーベースの VDA 登録を有効または無効にします。(セキュリティが最優先事項である場合は、Virtual Delivery Agent Settings > Controller SIDs 設定を使用します。)

この設定は HKLM\Software\Policies\Citrix\VirtualDesktopAgent (ListOfDDCs) の下に保存されます。

レジストリベース

この方法を指定するには、次のいずれかの手順を完了します。

• VDAインストールウィザードのDelivery Controllerページで、手動で実行を選択します。次に、インストールされているControllerのFQDNを入力し、追加をクリックします。複数のControllerをインストールしている場合は、それらのアドレスを追加します。
• コマンドラインVDAインストールの場合、/controllersオプションを使用して、インストールされているControllerまたはCloud ConnectorのFQDNを指定します。

この情報は、レジストリキーHKLM\Software\Citrix\VirtualDesktopAgentまたはHKLM\Software\Wow6432Node\Citrix\VirtualDesktopAgentの下にあるレジストリ値ListOfDDCsに保存されます。

このレジストリキーは手動で構成することも、グループポリシー設定（GPP）を使用することもできます。この方法は、ポリシーベースの方法よりも推奨される場合があります（たとえば、異なるControllerまたはCloud Connectorの条件付き処理が必要な場合、XDW-001-で始まるコンピューター名にXDC-001を使用するなど）。

サイト内のすべてのControllerまたはCloud ConnectorのFQDNをリストするListOfDDCsレジストリキーを更新します。（このキーは、Active DirectoryサイトOUに相当します。）

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

HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgentレジストリの場所にListOfDDCsキーとFarmGUIDキーの両方が含まれている場合、ControllerまたはCloud Connectorの検出にはListOfDDCsが使用されます。FarmGUIDは、VDAインストール中にサイトOUが指定された場合に存在します。（これはレガシー展開で使用される場合があります。）

必要に応じて、ListOfSIDsレジストリキーを更新します（詳細については、ListOfSIDsを参照してください）。

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

注意：Citrixポリシーを通じてポリシーベースのVDA登録も有効にすると、VDAインストール中に指定した設定が上書きされます。これは、ポリシーベースの方法がより優先されるためです。

アクティブ ディレクトリ OUベース（レガシー）

この方法は、主に下位互換性のためにサポートされており、推奨されません。まだ使用している場合は、Citrixは別の方法への変更を推奨します。

この方法を指定するには、以下の両方の手順を完了します。

• VDAインストールウィザードのDelivery Controllerページで、Active Directoryから場所を選択を選択します。
• Set-ADControllerDiscovery.ps1スクリプト（すべてのControllerで利用可能）を使用します。また、各VDAでFarmGuidレジストリエントリを構成して、適切なOUを指すようにします。この設定はグループポリシーを使用して構成できます。

MCSベース

MCSを使用してVMをプロビジョニングする場合、MCSがControllerまたはCloud Connectorのリストを設定します。この機能は自動更新と連携します。カタログ作成時、MCSは初期プロビジョニング中にControllerまたはCloud ConnectorのリストをPersonality.iniファイルに挿入します。自動更新によりリストは最新の状態に保たれます。

この方法を指定するには、VDAインストールウィザードのDelivery Controllerページで、Machine Creation Services™に任せるを選択します。

レビューと推奨事項

ベストプラクティスとして：

• 初期登録にはグループポリシー登録方法を使用します。
• Controllerのリストを最新の状態に保つには、自動更新（デフォルトで有効）を使用します。
• マルチゾーン展開では、初期構成にグループポリシーを使用します（少なくとも2つのControllerまたはCloud Connectorを使用）。VDAを、そのゾーン内のローカルなControllerまたはCloud Connectorにポイントします。自動更新を使用して、それらを最新の状態に保ちます。自動更新は、サテライトゾーンのVDAに対してListofDDCsを自動的に最適化します。

• ListOfDDCsレジストリキーに複数のコントローラーをスペースで区切ってリストし、コントローラーが利用できない場合の登録の問題を防ぎます。例：

   DDC7x.xd.local DDC7xHA.xd.local
  
   32-bit: HKEY_LOCAL_MACHINE \Software\Citrix\VirtualDesktopAgent\ListOfDDCs
  
   HKEY_LOCAL_MACHINE \Software\Citrix\VirtualDesktopAgent\ListOfDDCs (REG_SZ)
   <!--NeedCopy-->
  

• 起動時の登録遅延を防ぐため、ListofDDCsの下にリストされているすべての値が有効な完全修飾ドメイン名にマッピングされていることを確認してください。

自動更新

自動更新（XenApp and XenDesktop 7.6で導入）はデフォルトで有効です。これはVDA登録を最新の状態に保つための最も効率的な方法です。初期登録には使用されませんが、初期登録時に自動更新ソフトウェアがListofDDCsをダウンロードし、VDA上の永続キャッシュに保存します。このプロセスは各VDAに対して実行されます。キャッシュにはマシンポリシー情報も保持され、これによりポリシー設定が再起動後も保持されます。

Auto-update is supported when using MCS or Citrix Provisioning™ to provision machines, except for Citrix Provisioning server-side cache. Server-side cache is not a common scenario because there is no persistent storage for auto-update cache.

この方法を指定するには：

• 設定Virtual Delivery Agent Settings > Enable auto update of Controllersを含むCitrixポリシーを通じて、自動更新を有効または無効にします。この設定はデフォルトで有効です。

仕組み:

• VDAが再登録されるたびに（たとえば、マシンの再起動後）、キャッシュが更新されます。各ControllerまたはCloud Connectorも90分ごとにサイトデータベースをチェックします。前回のチェック以降にControllerまたはCloud Connectorが追加または削除された場合、またはVDA登録に影響するポリシー変更が発生した場合、ControllerまたはCloud Connectorは更新されたリストを登録済みのVDAに送信し、キャッシュが更新されます。VDAは、最新のキャッシュ済みリストにあるすべてのControllerまたはCloud Connectorからの接続を受け入れます。
• VDAが、登録されているControllerまたはCloud Connectorが含まれていないリストを受信した場合（つまり、そのControllerまたはCloud Connectorがサイトから削除された場合）、VDAはListofDDCsにあるControllerまたはCloud Connectorの中から選択して再登録します。

例:

• 展開には3つのController（A、B、C）があります。VDAはController Bに登録されます（これはVDAのインストール時に指定されました）。
• その後、2つのController（DとE）がサイトに追加されます。90分以内に、VDAは更新されたリストを受信し、Controller A、B、C、D、Eからの接続を受け入れます。（VDAが再起動されるまで、負荷はすべてのControllerに均等に分散されません。）
• さらにその後、Controller Bが別のサイトに移動されます。90分以内に、元のサイトのVDAは、前回のチェック以降にControllerの変更があったため、更新されたリストを受信します。Controller Bに最初に登録されたVDA（リストにない）は、現在のリスト（A、C、D、E）にあるControllerの中から選択して再登録します。

マルチゾーン展開では、サテライトゾーンの自動更新は、まずすべてのローカルControllerを自動的にキャッシュします。プライマリゾーンのすべてのControllerはバックアップグループにキャッシュされます。サテライトゾーンにローカルControllerが利用できない場合、プライマリゾーンのControllerへの登録が試行されます。

次の例に示すように、キャッシュファイルにはホスト名とセキュリティID（ListofSIDs）のリストが含まれています。VDAはSIDを照会しないため、Active Directoryの負荷が軽減されます。

WMI呼び出しでキャッシュファイルを取得できます。ただし、SYSTEMアカウントのみが読み取り可能な場所に保存されます。

重要:

この情報は情報提供のみを目的としています。このファイルを変更しないでください。このファイルまたはフォルダーを変更すると、サポートされていない構成になります。

Get-WmiObject -Namespace "Root\Citrix\DesktopInformation" -Class "Citrix_VirtualDesktopInfo" -Property "PersistentDataLocation"

セキュリティ上の理由から（Active Directoryの負荷軽減とは別に）ListofSIDsを手動で構成する必要がある場合、自動更新機能は使用できません。詳細については、「ListOfSIDs」を参照してください。

自動更新の優先順位の例外

自動更新は通常、すべてのVDA登録方法の中で最も高い優先順位を持ち、他の方法の設定を上書きしますが、例外があります。キャッシュ内のNonAutoListOfDDCs要素は、初期VDA構成方法を指定します。自動更新はこの情報を監視します。初期登録方法が変更された場合、登録プロセスは自動更新をスキップし、次に高い優先順位で構成された方法を使用します。このプロセスは、VDAを別のサイトに移動する場合（たとえば、災害復旧中）に役立ちます。

構成に関する考慮事項

一般的なVDA登録構成を表示します。

VDA登録手順を表示します。

VDA登録に影響を与える可能性のある項目を構成する際は、以下を考慮してください。

コントローラーまたはCloud Connectorのアドレス

ControllerまたはCloud Connectorを指定するためにどの方法を使用するかにかかわらず、CitrixはFQDNアドレスを使用することを推奨します。IPアドレスは、DNSレコードよりも侵害されやすいため、信頼できる構成とは見なされません。ListofSIDsを手動で入力する場合、ListofDDCsでIPを使用できます。ただし、FQDNが引き続き推奨されます。

負荷分散

前述のとおり、VDAはListofDDCs内のすべてのControllerまたはCloud Connectorに接続を自動的に分散します。フェールオーバーと負荷分散機能は、Citrix Brokering Protocol (CBP) に組み込まれています。構成で複数のControllerまたはCloud Connectorを指定した場合、必要に応じて登録はそれらの間で自動的にフェールオーバーします。自動更新では、すべてのVDAで自動フェールオーバーが自動的に発生します。

セキュリティ上の理由から、Citrix ADCなどのネットワークロードバランサーを使用することはできません。VDA登録ではKerberos相互認証が使用され、クライアント（VDA）はサービス（Controller）に対して自身のIDを証明する必要があります。ただし、ControllerまたはCloud ConnectorもVDAに対して自身のIDを証明する必要があります。これは、VDAとControllerまたはCloud Connectorが同時にサーバーとクライアントとして機能することを意味します。この記事の冒頭で述べたように、VDAからController/Cloud Connectorへ、およびController/Cloud ConnectorからVDAへの2つの通信チャネルがあります。

このプロセスにおけるコンポーネントは、サービスプリンシパル名（SPN）と呼ばれ、Active Directoryコンピューターオブジェクトのプロパティとして保存されます。VDAがControllerまたはCloud Connectorに接続するとき、通信したい相手を指定する必要があります。このアドレスがSPNです。負荷分散されたIPを使用する場合、Kerberos相互認証は、そのIPが予期されるControllerまたはCloud Connectorに属していないことを正しく認識します。

詳細については、以下を参照してください。

• ケルベロス の概要
• Kerberos を使用した相互認証(https://docs.microsoft.com/ja-jp/windows-server/security/kerberos/kerberos-authentication-overview)

自動更新による CNAME の置き換え

自動更新機能は、XenApp および XenDesktop 7.x より前のバージョンにおける CNAME (DNS エイリアス) 機能に代わるものです。XenApp および XenDesktop 7 以降、CNAME 機能は無効になっています。CNAME の代わりに自動更新を使用してください。(CNAME を使用する必要がある場合は、CTX137960 を参照してください。DNS エイリアスを常に機能させるには、自動更新と CNAME を同時に使用しないでください。)

コントローラー/クラウドコネクタ グループ

特定のシナリオでは、Controller または Cloud Connector をグループで処理したい場合があります。その際、1つのグループを優先し、すべての Controller/Cloud Connector が失敗した場合に別のグループをフェールオーバーに使用します。Controller または Cloud Connector はリストからランダムに選択されることに注意してください。そのため、グループ化は優先的な使用を強制するのに役立ちます。

これらのグループは、単一サイト内での使用を目的としています (複数サイトではありません)。

Controller/Cloud Connector のグループを指定するには、かっこを使用します。たとえば、4つの Controller (プライマリ 2つとバックアップ 2つ) の場合、グループ化は次のようになります。

(XDC-001.cdz.lan XDC-002.cdz.lan) (XDC-003.cdz.lan XDC-004.cdz.lan)

この例では、最初のグループ (001 と 002) の Controller が最初に処理されます。両方が失敗した場合、2番目のグループ (003 と 004) の Controller が処理されます。

XenDesktop 7.0 以降の場合、登録グループ機能を使用するには、追加の手順を実行する必要があります。Studio から Controller の自動更新を有効にするポリシーを禁止する必要があります。

SIDのリスト

VDA が登録のために接続できる Controller のリストは ListofDDCs です。VDA は、どの Controller を信頼すべきかも知る必要があります。VDA は ListofDDCs の Controller を自動的に信頼しないためです。ListofSIDs (セキュリティ ID) は、信頼できる Controller を識別します。VDA は、信頼できる Controller にのみ登録を試みます。

ほとんどの環境では、ListofSIDs は ListofDDCs から自動的に生成されます。CDF トレースを使用して ListofSIDs を読み取ることができます。

通常、ListofSIDs を手動で変更する必要はありません。いくつかの例外があります。最初の2つの例外は、新しいテクノロジーが利用可能になったため、もはや有効ではありません。

• Controller の役割の分離: XenApp および XenDesktop 7.7 でゾーンが導入される前は、登録に Controller のサブセットのみが使用される場合、ListofSIDs は手動で構成されていました。たとえば、XDC-001 と XDC-002 を XML ブローカーとして使用し、XDC-003 と XDC-004 を VDA 登録に使用していた場合、すべての Controller を ListofSIDs に、XDC-003 と XDC-004 を ListofDDCs に指定していました。これは一般的または推奨される構成ではありません。新しい環境では使用しないでください。代わりにゾーンを使用してください。
• Active Directory の負荷軽減: XenApp および XenDesktop 7.6 で自動更新機能が導入される前は、ドメインコントローラーの負荷を軽減するために ListofSIDs が使用されていました。ListofSIDs を事前入力することで、DNS 名から SID への解決をスキップできます。ただし、この永続キャッシュには SID が含まれているため、自動更新機能によりこの作業は不要になります。Citrix は自動更新機能を有効にしておくことを推奨します。
• セキュリティ: 一部の高度に保護された環境では、侵害された DNS サーバーからの潜在的なセキュリティ脅威を回避するために、信頼された Controller の SID が手動で構成されていました。ただし、これを行う場合は、自動更新機能も無効にする必要があります。そうしないと、永続キャッシュからの構成が使用されます。

したがって、特別な理由がない限り、ListofSIDs を変更しないでください。

ListofSIDs を変更する必要がある場合は、HKLM\Software\Citrix\VirtualDesktopAgent の下に ListOfSIDs (REG_SZ) という名前のレジストリキーを作成します。値は信頼された SID のリストであり、複数ある場合はスペースで区切ります。

次の例では、1 つの Controller が VDA 登録 (ListofDDCs) に使用され、2 つの Controller がブローカー処理 (List OfSIDs) に使用されています。

登録とブローカー処理に使用される異なる Controller の例(/ja-jp/citrix-virtual-apps-desktops/2411/media/vda-registration-listofsids.png)

VDA 登録中のコントローラー検索

VDA が登録を試行すると、Broker Agent はまずローカルドメインで DNS ルックアップを実行し、指定された Controller に到達できることを確認します。

最初のルックアップで Controller が見つからない場合、Broker Agent は AD でフォールバックのトップダウンクエリを開始できます。このクエリはすべてのドメインを検索し、頻繁に繰り返されます。Controller アドレスが無効な場合（たとえば、管理者が VDA のインストール時に誤った FQDN を入力した場合）、そのクエリのアクティビティがドメインコントローラー上で分散型サービス拒否（DDoS）状態を引き起こす可能性があります。

以下のレジストリキーは、Broker Agent が最初の検索中に Controller を見つけられない場合に、フォールバックのトップダウンクエリを使用するかどうかを制御します。

HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent

• 名前: DisableDdcWildcardNameLookup
• 種類: DWORD
• 値: 0 (デフォルト) または任意のゼロ以外の値

0 に設定すると、フォールバック検索が有効になります。Controller の初期検索が失敗した場合、フォールバックのトップダウン検索が開始されます。これはデフォルトの動作です。ただし、ゼロ以外の値に設定すると、フォールバック検索は無効になります。Controller の初期検索が失敗した場合、Broker Agent は検索を停止します。

読み取り専用ドメインコントローラーを使用した VDA 登録中の LDAP バインディングシーケンス

VDA が読み取り専用ドメインコントローラー (RODC) に登録する場合、Broker Agent は無視する Light Directory Access Protocol (LDAP) バインディングを選択する必要があります。この選択を行うには、Broker Agent に適切なレジストリキーが必要です。

レジストリキーが提供されていない場合、またはレジストリキーフィールドが空の場合、RODC を使用した VDA 登録は、元の LDAP バインディングシーケンスを経由する必要があるため、時間がかかります。

LDAP バインディングシーケンスを変更するために、レジストリキー ListofIgnoredBindings が HKEY_LOCAL_MACHINE\Software\Policies\Citrix\VirtualDesktopAgent に追加されました。ListofIgnoredBindings を使用すると、必要に応じて LDAP バインディングシーケンスを変更でき、RODC を使用した VDA 登録を高速化できます。

• 名前: ListofIgnoredBindings
• 種類: REG_SZ
• 指定できる値: DefaultPath, DomainPath, PDCPath

値は、コンマで区切られたバインディングパスオプションのリストです。レジストリキーは、有効と認識しない値を無視します。

VDA 登録の問題のトラブルシューティング

前述のとおり、VDA は、仲介されたセッションを起動する際に考慮されるために、Delivery Controller または Cloud Connector に登録されている必要があります。未登録の VDA は、利用可能なリソースの活用不足につながる可能性があります。VDA が登録されない理由はさまざまあり、その多くは管理者がトラブルシューティングできます。Studio は、カタログ作成ウィザードおよびデリバリーグループ作成後にトラブルシューティング情報を提供します。

• マシンカタログ作成中の問題の特定: カタログ作成ウィザードで、既存のマシンを追加した後、コンピューターアカウント名のリストは、各マシンがカタログに追加するのに適しているかどうかを示します。各マシンの横にあるアイコンにカーソルを合わせると、そのマシンに関する情報メッセージが表示されます。

  メッセージが問題のあるマシンを特定した場合、そのマシンを削除する（削除ボタンを使用）か、マシンを追加することができます。たとえば、マシンに関する情報が取得されなかった（おそらく登録されたことがないため）ことを示すメッセージが表示された場合でも、そのマシンを追加することを選択できます。

  カタログの機能レベルは、カタログ内のマシンで利用できる製品機能を制御します。新しい製品バージョンで導入された機能を使用するには、新しい VDA が必要になる場合があります。機能レベルを設定すると、そのバージョンで導入されたすべての機能（および機能レベルが変更されない場合はそれ以降の機能）がカタログ内のマシンで利用可能になります。ただし、そのカタログ内の以前の VDA バージョンのマシンは登録できません。

• デリバリーグループ作成後の問題の特定: デリバリーグループを作成した後、Studio はそのグループに関連付けられたマシンの詳細を表示します。

  デリバリーグループの詳細ペインには、登録が必要だが登録されていないマシンの数が表示されます。つまり、電源が入っていてメンテナンスモードではないが、現在コントローラーに登録されていないマシンが1台以上存在する可能性があります。「登録されていないが、登録が必要な」マシンを表示している場合は、詳細ペインのトラブルシューティングタブで、考えられる原因と推奨される是正措置を確認してください。

VDA登録のトラブルシューティングに関する詳細情報

• 機能レベルの詳細については、「VDAのバージョンと機能レベル」を参照してください。

• VDA登録のトラブルシューティングの詳細については、「CTX136668」を参照してください。

• Citrix Scoutのヘルスチェックを使用して、VDA登録とセッション起動のトラブルシューティングを行うこともできます。詳細については、「ヘルスチェックについて」を参照してください。