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のアドレスを指定しなかった場合）、メッセージが表示されます。
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 ページ(/en-us/citrix-virtual-apps-desktops/2503/media/vda-install-controllers-all.png)
ポリシーベース (LGPO\\GPO)
Citrix® は、初期 VDA 登録に GPO を使用することを推奨しています。これは最も優先度が高いです。(自動更新が最も優先度が高いとされていますが、自動更新は初期登録後にのみ使用されます。) ポリシーベースの登録は、構成にグループポリシーを使用する集中管理の利点を提供します。
この方法を指定するには、以下の両方の手順を完了します。
-
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に保存されます。
このレジストリキーは、手動で構成することも、グループポリシー設定（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)
注意：VDAインストール中に指定した設定を上書きするCitrixポリシーを通じてポリシーベースのVDA登録も有効にする場合、それは優先度の高い方法であるためです。
Active Directory 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を自動的に最適化します。 -
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の負荷が軽減されます。
キャッシュファイルはWMI呼び出しで取得できます。ただし、SYSTEMアカウントのみが読み取り可能な場所に保存されています。
重要:
この情報は情報提供のみを目的としています。このファイルを変更しないでください。このファイルまたはフォルダーへの変更は、サポートされていない構成になります。
Get-WmiObject -Namespace "Root\Citrix\DesktopInformation" -Class "Citrix_VirtualDesktopInfo" -Property "PersistentDataLocation"
セキュリティ上の理由から (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つは、サービスプリンシパル名（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グループ
特定のシナリオでは、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)
この例では、最初のグループ（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にのみ登録を試みます。
ほとんどの環境では、
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のリストであり、複数ある場合はスペースで区切ります。
次の例では、VDA登録には1つのコントローラー (
ListofDDCs) が使用されますが、ブローカー処理には2つのコントローラー (List OfSIDs) が使用されます。
VDA登録中のコントローラー検索
VDAが登録を試行すると、Broker AgentはまずローカルドメインでDNSルックアップを実行し、指定されたコントローラーに到達できることを確認します。
その最初のルックアップでコントローラーが見つからない場合、Broker AgentはADでフォールバックのトップダウンクエリを開始できます。そのクエリはすべてのドメインを検索し、頻繁に繰り返されます。コントローラーアドレスが無効な場合（たとえば、管理者がVDAのインストール時に誤ったFQDNを入力した場合）、そのクエリのアクティビティは、ドメインコントローラー上で分散型サービス拒否（DDoS）状態を引き起こす可能性があります。
最初の検索中にコントローラーを見つけられない場合に、Broker Agentがフォールバックのトップダウンクエリを使用するかどうかは、次のレジストリキーによって制御されます。
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent
-
名前:
DisableDdcWildcardNameLookup -
種類:
DWORD -
値:
0(デフォルト) または任意のゼロ以外の値
0に設定すると、フォールバック検索が有効になります。コントローラーの初期検索が失敗した場合、フォールバックのトップダウン検索が開始されます。これはデフォルトの動作です。ただし、ゼロ以外の値に設定すると、フォールバック検索は無効になります。コントローラーの初期検索が失敗した場合、ブローカーエージェントは検索を停止します。
読み取り専用ドメインコントローラーを使用した VDA 登録中の LDAP バインディングシーケンス
VDAが読み取り専用ドメインコントローラー (RODC) に登録する場合、ブローカーエージェントは無視するLight Directory Access Protocol (LDAP) バインディングを選択する必要があります。この選択を行うには、ブローカーエージェントに適切なレジストリキーが必要です。
レジストリキーが提供されていない場合、またはレジストリキーフィールドが空の場合、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は、カタログ作成ウィザードおよびデリバリーグループ作成後にトラブルシューティング情報を提供します。
-
マシンカタログ作成中の問題の特定: カタログ作成ウィザードで、既存のマシンを追加した後、コンピューターアカウント名の一覧は、各マシンがカタログに追加するのに適しているかどうかを示します。各マシンの横にあるアイコンにカーソルを合わせると、そのマシンに関する情報メッセージが表示されます。メッセージで問題のあるマシンが特定された場合、そのマシンを削除する（Removeボタンを使用）か、マシンを追加することができます。たとえば、マシンに関する情報が取得されなかった（おそらく一度も登録されなかったため）というメッセージが表示された場合でも、そのマシンを追加することを選択できます。カタログの機能レベルは、カタログ内のマシンで利用できる製品機能を制御します。新しい製品バージョンで導入された機能を使用するには、新しいVDAが必要になる場合があります。機能レベルを設定すると、そのバージョンで導入されたすべての機能（および機能レベルが変更されない場合はそれ以降のバージョン）がカタログ内のマシンで利用可能になります。ただし、以前のVDAバージョンを持つカタログ内のマシンは登録できません。
-
デリバリーグループ作成後の問題の特定: デリバリーグループを作成すると、Studioはそのグループに関連付けられたマシンに関する詳細を表示します。デリバリーグループの詳細ペインには、登録が必要だが登録されていないマシンの数が表示されます。つまり、電源が入っていてメンテナンスモードではないが、現在コントローラーに登録されていないマシンが1台以上存在する可能性があります。「登録されていないが、登録が必要な」マシンを表示している場合は、詳細ペインのトラブルシューティングタブで、考えられる原因と推奨される是正措置を確認してください。
VDA登録のトラブルシューティングに関する詳細情報
-
機能レベルの詳細については、「VDAのバージョンと機能レベル」を参照してください。
-
VDA登録のトラブルシューティングについて詳しくは、「CTX136668」を参照してください。
-
VDA登録とセッション起動のトラブルシューティングには、Citrix Scoutのヘルスチェックも使用できます。詳細については、「ヘルスチェックについて」を参照してください。