VDA登録
はじめに
VDAを使用する前に、サイト上の1つ以上のControllerまたはCloud Connectorに登録（通信を確立）する必要があります。(オンプレミスのXenAppおよびXenDesktop®展開では、VDAはControllerに登録します。XenAppおよびXenDesktop Service展開では、VDAは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に接続しようとします。
XenApp®およびXenDesktopは、VDAインストール中に構成されたControllerまたはCloud Connectorへの接続を自動的にテストします。ControllerまたはCloud Connectorに到達できない場合、エラーが表示されます。ControllerまたはCloud Connectorに接続できないという警告を無視した場合（またはVDAインストール中にアドレスを指定しなかった場合）、メッセージが表示されて通知されます。
コントローラーまたはクラウドコネクタのアドレスを構成する方法
管理者は、VDAが初めて登録するときに使用する構成方法を選択します。(これは初回登録と呼ばれます。) 初回登録中に、VDA上に永続的なキャッシュが作成されます。その後の登録では、構成の変更が検出されない限り、VDAはこのローカルキャッシュからControllerまたはCloud Connectorのリストを取得します。
その後の登録でそのリストを取得する最も簡単な方法は、自動更新機能を使用することです。自動更新はデフォルトで有効になっています。詳細については、「自動更新」を参照してください。
VDA上でControllerまたはCloud Connectorアドレスを構成するには、いくつかの方法があります。
- ポリシーベース（LGPOまたはGPO）
- レジストリベース（手動、GPP、VDAインストール時に指定）
- アクティブディレクトリ オーユーベース (レガシー オーユー検出)
- エムシーエスベース (パーソナリティ.ini)
VDAをインストールする際に、初期登録方法を指定します。(自動更新を無効にすると、VDAインストール時に選択した方法が、その後の登録にも使用されます。)
次の図は、VDAインストールウィザードのDelivery Controller™ページを示しています。
VDAインストールコントローラー(/ja-jp/xenapp-and-xendesktop/7-15-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ページで、手動で実行を選択します。次に、インストールされているコントローラーのFQDNを入力し、追加をクリックします。複数のコントローラーをインストールしている場合は、それらのアドレスを追加します。
- コマンドラインVDAインストールの場合は、/controllersオプションを使用して、インストールされているコントローラーまたはCloud ConnectorのFQDNを指定します。
この情報は通常、レジストリキー HKLM\Software\Citrix\VirtualDesktopAgent または HKLM\Software\Wow6432Node\Citrix\VirtualDesktopAgent の下のレジストリ値 ListOfDDCs に保存されます。
このレジストリキーは手動で構成することも、グループポリシー設定 (GPP) を使用することもできます。この方法は、ポリシーベースの方法よりも推奨される場合があります (たとえば、XDW-001- で始まるコンピューター名に XDC-001 を使用するなど、異なるコントローラーまたはクラウドコネクタの条件付き処理が必要な場合)。
ListOfDDCs レジストリキーを更新します。このキーには、サイト内のすべてのコントローラーまたはクラウドコネクタの FQDN がリストされます。(このキーは Active Directory サイト OU に相当します。)
HKEY_LOCAL_MACHINE\Software\Citrix\\VirtualDesktopAgent\ListOfDDCs (REG_SZ)
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent レジストリの場所に ListOfDDCs キーと FarmGUID キーの両方が含まれている場合、ListOfDDCs がコントローラーまたはクラウドコネクタの検出に使用されます。FarmGUID は、VDA のインストール中にサイト OU が指定された場合に存在します。(これはレガシー展開で使用される場合があります。)
必要に応じて、ListOfSIDs レジストリキーを更新します (詳細については、ListOfSIDs を参照してください)。
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs (REG_SZ)
注意:
Citrix ポリシーを介してポリシーベースの VDA 登録も有効にした場合、その構成は VDA インストール中に指定した設定を上書きします。これは、ポリシーベースの方法がより優先度の高い方法であるためです。
Active Directory 組織単位に基づく (従来の)
この方法は主に下位互換性のためにサポートされており、推奨されません。まだ使用している場合は、Citrix は別の方法への変更を推奨します。
この方法を指定するには、次の両方の手順を完了します。
- VDA インストールウィザードの Delivery Controller ページで、Active Directory から場所を選択 を選択します。
-
Set-ADControllerDiscovery.ps1スクリプト (すべてのコントローラーで利用可能) を使用します。また、各 VDA の FarmGuid レジストリエントリを適切な OU を指すように構成します。この設定はグループポリシーを使用して構成できます。
詳細については、Active Directory OUベースの検出 を参照してください。
MCSベース
VMのプロビジョニングにMCSのみを使用する予定の場合、MCSにControllerまたはCloud Connectorのリストを設定するよう指示できます。この機能は自動更新と互換性があります。MCSは、初期プロビジョニング時（マシンカタログ作成時）に、ControllerまたはCloud ConnectorのリストをPersonality.iniファイルに挿入します。自動更新により、リストは常に最新の状態に保たれます。
この方法は、大規模な環境での使用は推奨されません。次の場合にこの方法を使用できます。
- 小規模な環境である
- サイト間でVDAを移動しない
- VMのプロビジョニングにMCSのみを使用する
- グループポリシーを使用したくない
この方法を指定するには：
- VDAインストールウィザードのデリバリーコントローラーページで、マシン作成サービス™に任せるを選択します。
推奨事項
ベストプラクティスとして：
- 初期登録にはグループポリシー登録方法を使用します。
- Controllerのリストを最新の状態に保つには、自動更新（デフォルトで有効）を使用します。
- マルチゾーン展開では、初期構成にグループポリシーを使用します（ControllerまたはCloud Connectorが2つ以上ある場合）。VDAを、そのゾーン内のローカルなControllerまたはCloud Connectorにポイントします。自動更新を使用して、それらを最新の状態に保ちます。自動更新は、サテライトゾーンのVDAのListOfDDCsを自動的に最適化します。
自動更新
自動更新（XenAppおよびXenDesktop 7.6で導入）は、デフォルトで有効になっています。これは、VDA登録を最新の状態に保つための最も効率的な方法です。自動更新は最初の登録には使用されませんが、最初の登録時に自動更新ソフトウェアがListOfDDCsをダウンロードし、VDA上の永続キャッシュに保存します。これは各VDAに対して行われます。（キャッシュにはマシンポリシー情報も保持され、ポリシー設定が再起動後も維持されるようになっています。）
自動更新は、MCSまたはPVSを使用してマシンをプロビジョニングする場合にサポートされます。ただし、PVSサーバー側キャッシュは例外です（自動更新キャッシュ用の永続ストレージがないため、一般的なシナリオではありません）。
この方法を指定するには：
- 設定を含むCitrixポリシーを通じて自動更新を有効または無効にします:
Virtual Delivery Agent Settings > Enable auto update of Controllers。この設定はデフォルトで有効になっています。
仕組み：
- Each time a VDA re-registers (for example, after a machine restart), the cache is updated. Each Controller or Cloud Connector also checks the site database every 90 minutes. If a Controller or Cloud Connector has been added or removed since the last check, or if a policy change occurred that affects VDA registration, the Controller or Cloud Connector sends an updated list to its registered VDAs and the cache is updated. The VDA accepts connections from all the Controllers or Cloud Connectors in its most recently cached list.
- 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が再起動されるまで、負荷はすべてのコントローラーに均等に分散されません）。
- さらにその後、Controller Bは別のSiteに移動されます。90分以内に、元のSiteのVDAは、前回のチェック以降にControllerの変更があったため、更新されたリストを受け取ります。Controller Bに元々登録されていたVDA（リストにはもうありません）は、現在のリスト（A、C、D、E）のControllerの中から選択して再登録します。
マルチゾーン展開では、サテライトゾーンの自動更新は、まずすべてのローカルControllerを自動的にキャッシュします。プライマリゾーンのすべてのControllerはバックアップグループにキャッシュされます。サテライトゾーンにローカルControllerが利用できない場合、プライマリゾーンのControllerで登録が試行されます。
次の例に示すように、キャッシュファイルにはホスト名とセキュリティIDのリスト（ListOfSIDs）が含まれています。VDAはSIDを照会しないため、Active Directoryの負荷が軽減されます。
VDA登録キャッシュファイル(/ja-jp/xenapp-and-xendesktop/7-15-ltsr/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 を別のサイトに移動する場合 (たとえば、ディザスターリカバリ中) に役立ちます。
構成に関する考慮事項
コントローラーまたは Cloud Connector のアドレス
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 つは、サービスプリンシパル名 (SPN) と呼ばれ、Active Directory コンピューターオブジェクトのプロパティとして保存されます。VDA が Controller または Cloud Connector に接続するときは、通信したい「相手」を指定する必要があります。このアドレスは SPN です。負荷分散された IP を使用すると、Kerberos 相互認証は、その IP が予期される Controller または Cloud Connector に属していないことを正しく認識します。
詳細については、以下を参照してください。
- ケルベロス の概要: https://blogs.technet.microsoft.com/askds/2008/03/06/kerberos-for-the-busy-admin/
- Kerberos を使用した相互認証: https://docs.microsoft.com/ja-jp/windows/win32/ad/mutual-authentication-using-kerberos?redirectedfrom=MSDN
自動更新が 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のグループを指定するには、かっこを使用します。たとえば、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が処理されます。
SIDのリスト
VDAが登録のために連絡できるControllerのリストはListOfDDCsです。VDAはどのControllerを信頼すべきかも知っている必要があります。VDAはListOfDDCs内の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登録に使用していた場合、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がある場合はスペースで区切られたリストです。
以下の例では、VDA登録には1つのController（ListOfDDCs）が使用されますが、ブローカー処理には2つのController（ListOfSIDs）が使用されます。
VDAの登録(/ja-jp/xenapp-and-xendesktop/7-15-ltsr/media/vda-registration-listofsids.png)
VDA登録中のコントローラー検索
VDAが登録を試みるとき、Broker AgentはまずローカルドメインでDNSルックアップを実行し、指定されたControllerに到達できることを確認します。
その最初のルックアップでControllerが見つからない場合、Broker AgentはADでフォールバックのトップダウンクエリを開始できます。このクエリはすべてのドメインを検索し、頻繁に繰り返されます。Controllerアドレスが無効な場合（たとえば、管理者がVDAのインストール時に誤ったFQDNを入力した場合）、そのクエリのアクティビティがドメインコントローラー上で分散型サービス拒否（DDoS）状態を引き起こす可能性があります。
以下のレジストリキーは、Broker Agentが最初の検索中にControllerを見つけられない場合に、フォールバックのトップダウンクエリを使用するかどうかを制御します。
HKEY_LOCAL_MACHINE\Software\Policies\Citrix\VirtualDesktopAgent
- 名前:
DisableDdcWildcardNameLookup - 種類:
DWORD - 値:
1(デフォルト) または0
1に設定すると、フォールバック検索は無効になります。Controllerの最初の検索が失敗した場合、Broker Agentは検索を停止します。これがデフォルト設定です。
0に設定すると、フォールバック検索が有効になります。Controllerの最初の検索が失敗した場合、フォールバックのトップダウン検索が開始されます。
VDA登録の問題のトラブルシューティング
前述のとおり、ブローカーセッションを起動する際に考慮されるためには、VDAがDelivery Controllerに登録されている必要があります。未登録のVDAは、利用可能なリソースの活用不足につながる可能性があります。VDAが登録されない理由はさまざまあり、その多くは管理者がトラブルシューティングできます。Studioは、カタログ作成ウィザードおよびDelivery Group作成後にトラブルシューティング情報を提供します。
マシンカタログ作成中の問題の特定:
カタログ作成ウィザードで、既存のマシンを追加した後、コンピューターアカウント名のリストは、各マシンがカタログに追加するのに適しているかどうかを示します。各マシンの横にあるアイコンにカーソルを合わせると、そのマシンに関する情報メッセージが表示されます。
メッセージで問題のあるマシンが特定された場合、そのマシンを削除する（Removeボタンを使用）か、追加することができます。たとえば、あるマシンに関する情報が取得されなかった（おそらくDelivery Controllerに登録されたことがなかったため）というメッセージが表示された場合でも、そのマシンを追加することを選択できます。
カタログの機能レベルは、カタログ内のマシンで利用できる製品機能を制御します。新しい製品バージョンで導入された機能を使用するには、新しいVDAが必要になる場合があります。機能レベルを設定すると、そのバージョンで導入されたすべての機能（および、機能レベルが変更されない場合はそれ以降のバージョンで導入された機能）がカタログ内のマシンで利用可能になります。ただし、そのカタログ内の以前のVDAバージョンのマシンは登録できません。
デリバリーグループ作成後の問題の特定:
デリバリーグループを作成すると、Studioはそのグループに関連付けられているマシンの詳細を表示します。デリバリーグループの詳細ペインには、登録が期待されているが登録されていないマシンの数が表示されます。つまり、電源がオンになっていてメンテナンスモードではないが、現在Controllerに登録されていないマシンが1台以上存在する可能性があります。「登録されていないが、登録が期待されている」マシンを表示する場合は、詳細ペインのトラブルシューティングタブで、考えられる原因と推奨される是正措置を確認してください。
機能レベルの詳細については、「マシンカタログの作成」の「VDAバージョンと機能レベル」セクションを参照してください。
VDA登録のトラブルシューティングの詳細については、「CTX136668」を参照してください。
VDA登録とセッション起動のトラブルシューティングには、Citrix Health Assistantも使用できます。詳細については、「CTX207624」を参照してください。