Citrix Virtual Apps and Desktops

VDA登録

はじめに

注:

オンプレミス環境では、VDAはデリバリーコントローラーに登録します。Citrix Cloudサービス環境では、VDAはCloud Connectorに登録します。ハイブリッド環境では、一部のVDAはデリバリーコントローラーに登録し、他の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インストールウィザードのデリバリーコントローラーページを示しています。

VDAインストールウィザードのデリバリーコントローラーページ

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

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

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

  • VDAインストールウィザードのデリバリーコントローラーページで、後で実行(詳細設定)を選択します。ウィザードは、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オプションを使用して、インストールされているコントローラーまたはCloud ConnectorのFQDNを指定します。

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

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

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

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

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

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

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

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

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

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

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

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

MCSベース

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

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

レビューと推奨事項

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

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

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

  • この方法を指定するには:

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

動作原理:

  • 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の負荷を軽減します。

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

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

重要:

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

```
DDC7x.xd.local DDC7xHA.xd.local
  • 32-bit: HKEY_LOCAL_MACHINE \Software\Citrix\VirtualDesktopAgent\ListOfDDCs

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

    ```

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

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

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

構成に関する考慮事項

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

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

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

Controllerまたは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 つの通信チャネルがあります。

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

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

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

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

Controller/Cloud Connector グループ

特定のシナリオでは、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 の自動更新を有効にするポリシーを禁止する必要があります。

ListOfSIDs

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

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

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

  • Controller の役割の分離: XenApp および XenDesktop 7.7 でゾーンが導入される前は、Controller のサブセットのみが登録に使用される場合、ListofSIDs は手動で構成されていました。たとえば、XDC-001 と XDC-002 を XML ブローカーとして使用し、XDC-003 と XDC-004 を VDA 登録に使用する場合、ListofSIDs にすべての Controller を指定し、ListofDDCs に XDC-003 と XDC-004 を指定していました。これは一般的な構成でも推奨される構成でもありません。新しい環境では使用しないでください。代わりにゾーンを使用してください。
  • 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 がある場合はスペースで区切られた信頼された SID のリストです。

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

登録とブローカー処理に使用される異なる Controller の例

VDA 登録中の Controller 検索

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

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

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

HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent

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

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

VDA登録時のLDAPバインディングシーケンス(読み取り専用ドメインコントローラーを使用する場合)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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