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インストール時に指定)
• アクティブディレクトリのオーユーベース (レガシーオーユー検出)
• MCS-based (personality.ini)

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

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

VDAインストールウィザードのデリバリーコントローラーページ(/ja-jp/citrix-virtual-apps-desktops/2507-ltsr/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が使用されます。VDAインストール中にサイトOUが指定された場合、FarmGUIDが存在します。（これはレガシー展開で使用される場合があります。）

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

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

注意：VDAインストール中に指定した設定を上書きするCitrixポリシーを介してポリシーベースのVDA登録も有効にする場合、それは優先度の高い方法であるためです。

アクティブディレクトリ OUベース (レガシー)

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

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

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

MCSベース

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

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

レビューと推奨事項

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

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

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

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

自動更新は、MCSまたはCitrix Provisioning™を使用してマシンをプロビジョニングする場合にサポートされますが、Citrix Provisioningのサーバー側キャッシュは例外です。自動更新キャッシュ用の永続ストレージがないため、サーバー側キャッシュは一般的なシナリオではありません。

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

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

仕組み:

• VDAが再登録されるたび（たとえば、マシンの再起動後）に、キャッシュが更新されます。各ControllerまたはCloud Connectorも90分ごとにサイトデータベースをチェックします。前回のチェック以降にControllerまたはCloud Connectorが追加または削除された場合、またはVDA登録に影響するポリシー変更が発生した場合、そのControllerまたはCloud Connectorは登録済みのVDAsに更新されたリストを送信し、キャッシュが更新されます。VDAは、最新のキャッシュ済みリストにあるすべてのControllerまたはCloud Connectorからの接続を受け入れます。
• If a VDA receives a list that does not include the Controller or Cloud Connector it is registered with (in other words, that Controller or Cloud Connector was removed from the site), the VDA re-registers, choosing among the Controllers or Cloud Connectors in the ListofDDCs.

例:

• 展開には3つのコントローラー（A、B、C）があります。VDAはコントローラーBに登録されます（これはVDAのインストール時に指定されました）。
• その後、2つのコントローラー（DとE）がサイトに追加されます。90分以内に、VDAは更新されたリストを受信し、コントローラーA、B、C、D、Eからの接続を受け入れます。（VDAが再起動されるまで、負荷はすべてのコントローラーに均等に分散されません）。
• Later still, Controller B is moved to another site. Within 90 minutes, VDAs in the original site receive updated lists because there has been a Controller change since the last check. The VDA that originally registered with Controller B (which is no longer on the list) re-registers, choosing among the Controllers in the current list (A, C, D, and E).

In a multi-zone deployment, auto-update in a satellite zone automatically caches all local Controllers first. All Controllers in the primary zone are cached in a backup group. If no local Controllers in the satellite zone are available, registration is attempted with Controllers in the primary zone.

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

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

重要:

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

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

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

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

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

構成に関する考慮事項

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

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

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

コントローラーまたはクラウドコネクタのアドレス

ControllerまたはCloud Connectorを指定するためにどの方法を使用するかにかかわらず、CitrixはFQDNアドレスを使用することを推奨します。IPアドレスは、DNSレコードよりもIPを侵害する方が容易であるため、信頼できる構成とは見なされません。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つの通信チャネルがあります。

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

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

• ケルベロス の概要
• Kerberos を使用した相互認証

自動更新による 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つの例外は、新しいテクノロジーが利用可能になったため、もはや有効ではありません。

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

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

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

次の例では、1つのコントローラーがVDA登録に使用され（ListofDDCs）、2つのコントローラーがブローカー処理に使用されています（List OfSIDs）。

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

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

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

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

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

HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent

• 名前: DisableDdcWildcardNameLookup
• 種類: DWORD
• 値: 0（デフォルト）または任意の非ゼロ値

0に設定すると、フォールバック検索が有効になります。コントローラーの初期検索が失敗した場合、フォールバックのトップダウン検索が開始されます。これはデフォルトの動作です。ただし、ゼロ以外の値に設定すると、フォールバック検索は無効になります。コントローラーの初期検索が失敗した場合、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登録とセッション起動のトラブルシューティングを行うこともできます。詳細については、「ヘルスチェックについて」を参照してください。