VDA登録

最終公開日 : Nov 13, 2026
Related information
管理

はじめに

注:
オンプレミス環境では、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アドレスを指定しなかった場合）、メッセージが表示されて通知されます。

ControllerまたはCloud Connectorアドレスを構成する方法

管理者は、VDAが初めて登録するとき（初回登録時）に使用する構成方法を選択します。初回登録時に、VDA上に永続キャッシュが作成されます。その後の登録では、構成の変更が検出されない限り、VDAはこのローカルキャッシュからControllerまたはCloud Connectorのリストを取得します。
その後の登録でそのリストを取得する最も簡単な方法は、自動更新機能を使用することです。自動更新はデフォルトで有効になっています。詳細については、「自動更新」を参照してください。
VDA上でControllerまたはCloud Connectorアドレスを構成する方法はいくつかあります。
  • ポリシーベース (LGPOまたはGPO)
  • レジストリベース (手動、グループポリシー設定 (GPP)、VDAインストール時に指定)
  • Active Directory OUベース (レガシーOU検出)
  • MCSベース (personality.ini)
VDAをインストールする際に、初期登録方法を指定します。(自動更新を無効にした場合、VDAインストール時に選択した方法がその後の登録に使用されます。)
次の図は、VDAインストールウィザードのDelivery Controllerページを示しています。
VDAインストールウィザードのDelivery Controllerページ(/en-us/citrix-virtual-apps-desktops/2407/media/vda-install-controllers-all.png)

ポリシーベース (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インストールウィザードのDelivery Controllerページで、手動で実行 を選択します。次に、インストールされているControllerのFQDNを入力し、追加 をクリックします。複数のControllerをインストールしている場合は、それらのアドレスを追加します。
  • コマンドラインVDAインストールの場合、/controllersオプションを使用し、インストールされているControllerまたはCloud ConnectorのFQDNを指定します。
この情報は、レジストリキーHKLM\Software\Citrix\VirtualDesktopAgentまたはHKLM\Software\Wow6432Node\Citrix\VirtualDesktopAgentの下のレジストリ値ListOfDDCsに保存されます。
このレジストリキーは手動で構成することも、Group Policy Preferences（GPP）を使用することもできます。この方法は、ポリシーベースの方法よりも推奨される場合があります（たとえば、異なるControllerまたはCloud Connectorの条件付き処理が必要な場合。例：XDW-001-で始まるコンピューター名にはXDC-001を使用する）。
ListOfDDCs レジストリキーを更新します。このキーには、サイト内のすべてのControllerまたはCloud ConnectorのFQDNが一覧表示されます。(このキーは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)
注意：Citrixポリシーを介してポリシーベースのVDA登録も有効にすると、VDAインストール中に指定した設定が上書きされます。これは優先度の高い方法であるためです。

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

この方法は主に下位互換性のためにサポートされており、推奨されません。まだこの方法を使用している場合は、別の方法に変更することをお勧めします。
この方法を指定するには、以下の両方の手順を完了します。
  • 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 のリストを最新の状態に保ちます。
  • マルチゾーン展開では、初期構成にはグループポリシーを使用します（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)
  • 起動時の登録遅延を防ぐため、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は登録済み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の登録キャッシュファイルの例(/en-us/citrix-virtual-apps-desktops/2407/media/vda-registration-cache-file.png)
キャッシュファイルはWMI呼び出しで取得できます。ただし、SYSTEMアカウントのみが読み取り可能な場所に保存されています。
重要:
この情報は情報提供のみを目的としています。このファイルを変更しないでください。このファイルまたはフォルダーへの変更は、サポートされていない構成になります。
Get-WmiObject -Namespace "Root\Citrix\DesktopInformation" -Class "Citrix_VirtualDesktopInfo" -Property "PersistentDataLocation"
セキュリティ上の理由から (Active Directoryの負荷軽減とは別に) ListofSIDsを手動で構成する必要がある場合、自動更新機能を使用することはできません。詳細については、「ListOfSIDs」を参照してください。

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

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

構成に関する考慮事項

一般的なVDA登録構成を表示します。
<iframe src="https://www.youtube.com/embed/MgGMZp4SnZgEq9ieibQc9j" width="720px" height="480px" frameborder="0" title="YouTube video player" allowfullscreen=""> </iframe>
VDA登録手順を表示します。
<iframe src="https://www.youtube.com/embed/iwsbajSVY5QvoUTh6m7AjG" width="720px" height="480px" frameborder="0" title="YouTube video player" allowfullscreen=""> </iframe>
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つは、サービスプリンシパル名（SPN）と呼ばれ、Active Directoryコンピューターオブジェクトのプロパティとして保存されます。VDAがControllerまたはCloud Connectorに接続するとき、通信したい相手を指定する必要があります。このアドレスがSPNです。負荷分散されたIPを使用すると、Kerberos相互認証は、そのIPが予期されるControllerまたはCloud Connectorに属していないことを正しく認識します。
詳細については、以下を参照してください。
  • Kerberosの概要(https://blogs.technet.microsoft.com/askds/2008/03/06/kerberos-for-the-busy-admin/)
  • Kerberosを使用した相互認証(https://docs.microsoft.com/ja-jp/windows-server/security/kerberos/kerberos-authentication-overview)

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

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

Controller/Cloud Connectorグループ

特定のシナリオでは、ControllerまたはCloud Connectorをグループで処理し、一方のグループを優先し、すべての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)
この例では、最初のグループのController（001と002）が最初に処理されます。両方が失敗した場合、2番目のグループのController（003と004）が処理されます。
XenDesktop 7.0以降では、登録グループ機能を使用するために追加の手順を実行する必要があります。StudioからControllerの自動更新を有効にするポリシーを禁止する必要があります。

ListOfSIDs

VDAが登録のために連絡できるControllerのリストはListofDDCsです。VDAは、ListofDDCs内のControllerを自動的に信頼しないため、どの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 のリストで、複数ある場合はスペースで区切ります。
次の例では、VDA登録には1つのController (ListofDDCs) が使用されていますが、ブローカー処理には2つのController (List OfSIDs) が使用されています。
登録とブローカー処理に使用される異なるControllerの例

VDA 登録中の Controller 検索

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 に適切なレジストリキーが必要です。
レジストリキーが提供されていない場合、またはレジストリキーフィールドが空の場合、元の LDAP バインディングシーケンスを通過する必要があるため、RODC を使用した VDA 登録には時間がかかります。
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」を参照してください。
  • VDA登録とセッション起動のトラブルシューティングには、Citrix Scoutのヘルスチェックも使用できます。詳細については、「ヘルスチェックについて」を参照してください。