Citrix Virtual Apps and Desktops

VDA登録

はじめに

注:

オンプレミス環境では、VDAはデリバリーコントローラーに登録します。Citrix Cloudサービス環境では、VDAはCloud Connectorに登録します。ハイブリッド環境では、一部のVDAはデリバリーコントローラーに登録し、その他はCloud Connectorに登録します。

VDAを使用する前に、サイト上の1つ以上のコントローラーまたはCloud Connectorに登録(通信を確立)する必要があります。VDAは、ListofDDCsと呼ばれるリストを確認することで、コントローラーまたはCloud Connectorを検出します。VDA上のListOfDDCsには、そのVDAをサイト上のコントローラーまたはCloud ConnectorにポイントするDNSエントリが含まれています。ロードバランシングのため、VDAはリスト内のすべてのコントローラーまたはCloud Connectorに接続を自動的に分散します。

VDA登録が非常に重要なのはなぜでしょうか。

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

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

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

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

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

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

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

VDAでコントローラーまたはCloud Connectorアドレスを構成する方法はいくつかあります。

  • ポリシーベース (LGPOまたはGPO)
  • レジストリベース (手動、グループポリシー設定 (GPP)、VDAインストール時に指定)
  • Active Directory OUベース (レガシーOU検出)
  • MCSベース (personality.ini)

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

次のグラフィックは、VDAインストールウィザードの [Delivery Controller] ページを示しています。

VDAインストールウィザードのDelivery Controllerページ

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

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

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

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

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

レジストリベース

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

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

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

このレジストリキーは、手動で構成することも、グループポリシープリファレンス (GPP) を使用して構成することもできます。この方法は、ポリシーベースの方法よりも推奨される場合があります (たとえば、異なるコントローラーまたはクラウドコネクタの条件付き処理が必要な場合など: XDW-001-で始まるコンピューター名にはXDC-001を使用するなど)。

サイト内のすべてのコントローラーまたはクラウドコネクタのFQDNをリストするListOfDDCsレジストリキーを更新します。(このキーはActive DirectoryサイトOUに相当します。)

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

HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgentレジストリの場所にListOfDDCsFarmGUIDの両方のキーが含まれている場合、コントローラーまたはクラウドコネクタの検出にはListOfDDCsが使用されます。FarmGUIDは、VDAインストール中にサイトOUが指定された場合に存在します。(これはレガシー展開で使用される場合があります。)

オプションで、ListOfSIDsレジストリキーを更新します (詳細については、ListOfSIDsを参照してください)。

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

注意: VDAインストール中に指定した設定を上書きするCitrixポリシーによるポリシーベースのVDA登録も有効にすると、Citrixポリシーが優先度の高い方法であるため、そちらが適用されます。

Active Directory OUベース (レガシー)

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

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

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

MCSベース

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

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

レビューと推奨事項

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

  • 初期登録にはグループポリシー登録方法を使用します。
  • コントローラーのリストを最新の状態に保つには、自動更新 (デフォルトで有効) を使用します。
  • マルチゾーン展開では、初期構成にグループポリシーを使用します (少なくとも2つのコントローラーまたはクラウドコネクタを使用)。VDAをそのゾーン内のローカルなコントローラーまたはクラウドコネクタにポイントします。自動更新を使用してそれらを最新の状態に保ちます。自動更新は、サテライトゾーンの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およびXenDesktop 7.6で導入) はデフォルトで有効です。これは、VDA登録を最新の状態に保つための最も効率的な方法です。初期登録には使用されませんが、初期登録が行われると、自動更新ソフトウェアはListofDDCsをダウンロードし、VDA上の永続的なキャッシュに保存します。このプロセスは各VDAに対して実行されます。キャッシュにはマシンポリシー情報も保持され、ポリシー設定が再起動後も保持されることを保証します。

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

この方法の指定

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

動作原理

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

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

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

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

VDAの登録キャッシュファイルの例

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のアドレス

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

ロードバランシング

VDAは、ListofDDCs内のすべてのコントローラーまたはクラウドコネクターに接続を自動的に分散します。フェイルオーバーと負荷分散機能は、Citrix Brokering Protocol (CBP) に組み込まれています。構成で複数のコントローラーまたはクラウドコネクターを指定した場合、必要に応じて登録はそれらの間で自動的にフェイルオーバーします。オートアップデートにより、すべてのVDAで自動フェイルオーバーが自動的に発生します。

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

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

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

オートアップデートによるCNAMEの置き換え

オートアップデート機能は、XenAppおよびXenDesktop 7.xより前のバージョンにおけるCNAME (DNSエイリアス) 機能を置き換えます。CNAME機能は、XenAppおよびXenDesktop 7以降では無効になっています。CNAMEの代わりにオートアップデートを使用してください。(CNAMEを使用する必要がある場合は、CTX137960を参照してください。DNSエイリアシングを一貫して機能させるには、オートアップデートとCNAMEを同時に使用しないでください。)

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

特定のシナリオでは、コントローラーまたはクラウドコネクターをグループで処理したい場合があります。その際、一方のグループを優先し、すべてのコントローラー/クラウドコネクターが失敗した場合に備えてもう一方のグループをフェイルオーバーに使用します。コントローラーまたはクラウドコネクターはリストからランダムに選択されるため、グループ化することで優先的な使用を強制するのに役立ちます。

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

コントローラー/クラウドコネクターのグループを指定するには、括弧を使用します。たとえば、4つのコントローラー (プライマリ2つ、バックアップ2つ) の場合、グループ化は次のようになります。

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

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

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

ListOfSIDs

VDAが登録のために連絡できるコントローラーのリストはListofDDCsです。VDAはListofDDCs内のコントローラーを自動的に信頼しないため、どのコントローラーを信頼すべきかも知っている必要があります。ListofSIDs (セキュリティID) は、信頼されたコントローラーを識別します。VDAは信頼されたコントローラーとのみ登録を試みます。

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

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

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

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

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

次の例では、1つのコントローラーがVDA登録 (ListofDDCs) に使用されますが、2つのコントローラーがブローカリング (ListOfSIDs) に使用されます。

登録とブローカリングに使用される異なるコントローラーの例

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バインディングシーケンスを変更するために、レジストリキーListofIgnoredBindingsHKEY_LOCAL_MACHINE\Software\Policies\Citrix\VirtualDesktopAgentに追加されました。ListofIgnoredBindingsを使用すると、必要に応じてLDAPバインディングシーケンスを変更でき、それによってRODCへのVDA登録を高速化できます。

  • 名前: ListofIgnoredBindings
  • 種類: REG_SZ
  • 値: DefaultPathDomainPathPDCPath

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

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

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

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

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

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

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

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

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

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

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

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