VDA登録
はじめに
VDAを使用するには、そのサイトの1つまたは複数のControllerまたはCloud Connectorに登録（接続を確立）する必要があります。（オンプレミスのXenAppおよびXenDesktop展開環境では、VDAはControllerに登録されます。XenAppおよびXenDesktop Service展開環境では、VDAはCloud Connectorに登録されます。）VDAはListofDDCsと呼ばれる一覧をチェックして、Controllerまたはコネクタを見つけます。VDAのListOfDDCsには、そのVDAをサイトのControllerまたはCloud ConnectorにポイントするDNSエントリが含まれています。負荷分散のため、VDAは一覧のすべてのControllerまたはCloud Connectorで接続を自動的に分散させます。
VDA登録が重要な理由
- セキュリティの面で見ると、登録ではControllerまたはCloud ConnectorとVDA間の接続を確立するため、デリケートな操作と言えます。このように注意が必要な操作では、不完全なものが1つでもあればその接続を拒否する必要があります。実際には、2つの個別の通信チャネル（VDAからControllerまたはCloud Connector、ControllerまたはCloud ConnectorからVDA）を確立することになります。接続ではKerberosが使用されるため、時刻の同期およびドメインへの参加に関する問題は見過ごせないものになります。Kerberosではサービスプリンシパル名（SPN）が使用されるため、負荷分散されたIPやホスト名は使用できません。
- ControllerまたはCloud Connectorの追加および削除は、VDAに正確かつ最新のControllerまたはCloud Connectorの情報が設定されていないと、未登録のControllerまたはCloud Connectorにより仲介されたセッションの起動がVDAにより拒否される場合があります。また、無効なエントリにより、仮想デスクトップシステムソフトウェアの起動に遅延が生じることがあります。VDAでは、信頼されていない不明なControllerまたはCloud Connectorからの接続は受け入れられません。
ListOfDDCsに加えて、ListOfSIDs（セキュリティID）により、ListOfDDCsに記載されているどのマシンを信頼するかが指定されます。ListOfSIDsは、Active Directoryでの負荷を軽減したり、改ざんされたDNSサーバーからのセキュリティ上の脅威を防いだりするために使用できます。詳しくは、「ListOfSIDs」を参照してください。
ListOfDDCsに複数のControllerまたはCloud Connectorが指定されている場合、VDAはランダムな順序で接続を試行します。オンプレミスの展開では、ListOfDDCsにはControllerのグループを含めることもできます。VDAは、これらのグループ内の各Controllerへの接続を試行し、その後でListOfDDCsのほかのエントリを試行します。
XenAppとXenDesktopでは、VDAのインストール中に構成済みのControllerまたはCloud Connectorに対する接続が自動でテストされます。ControllerまたはCloud Connectorに接続できない場合は、エラーが表示されます。ControllerまたはCloud Connectorに接続できないことを示す警告を無視した場合（またはVDAのインストール中にアドレスを指定しなかった場合）は、メッセージが表示されます。
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］ ページを示します。
ポリシーベース（LGPOまたはGPO）
VDAの初回登録ではGPOを使用することをCitrixではお勧めします。この方法が最優先です（以前は自動更新が最優先となっていましたが、自動更新は初回登録後にのみ使用します）。ポリシーベースの登録には、構成にグループポリシーを使用できるという集中化のメリットがあります。
この方法を指定するには、次の手順の両方を実行します。
- VDAインストールウィザードの ［Delivery Controller］ ページで、［あとで実行（上級）］を選択します。VDAのインストール中にControllerのアドレスの指定は行いませんが、ウィザードからこれらのアドレスを指定するように複数回促されます（これは、VDAの登録が非常に重要なためです）。
-
Virtual Delivery Agent Settings > Controllers設定で、Citrixポリシーを使用してポリシーベースのVDA登録を有効化または無効化します（セキュリティが最優先の場合、Virtual Delivery Agent Settings > Controller SIDs設定を使用します）。
この設定はHKLM\Software\Policies\Citrix\VirtualDesktopAgent (ListOfDDCs)に格納されています。
レジストリベース
この方法を指定するには、次の手順のいずれかを実行します。
- VDAインストールウィザードの ［Delivery Controller］ ページで、［手動で指定する］を選択します。次に、インストール済みのControllerの完全修飾ドメイン名を入力し、［追加］をクリックします。追加の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を使用する）場合などは、ポリシーベースの方法よりも適しています。
サイトのすべてのControllerまたはCloud Connectorの完全修飾ドメイン名の一覧が設定されているListOfDDCsレジストリキーを更新します。（このキーはActive Directoryサイト組織単位に相当します。）
HKEY_LOCAL_MACHINE\Software\Citrix\\VirtualDesktopAgent\ListOfDDCs (REG_SZ)
レジストリHKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgentにListOfDDCsとFarmGUIDキーの両方がある場合は、ListOfDDCsがControllerまたはCloud Connectorの検出に使用されます。FarmGUIDは、VDAのインストール時にサイト組織単位を指定した場合に作成されます（このキーは古い展開環境で使用する場合があります）。
オプションで、ListOfSIDsレジストリキーを更新します（詳しくは「ListOfSID」を参照してください）：
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs (REG_SZ)
注意事項：
CitrixポリシーによりポリシーベースのVDA登録も有効化している場合は、ポリシーベースの方法の方が優先度が高いため、VDAのインストール時に指定した設定がポリシーベースの設定で上書きされます。
Active DirectoryのOUベース（旧）
この方法は主として後方互換性のためにサポートされているものであり、推奨されていません。現在もこの方法を使用している場合は、別の方法に変えることをCitrixではお勧めします。
この方法を指定するには、次の手順の両方を実行します。
- VDAインストールウィザードの ［Delivery Controller］ ページで、［Active Directoryから場所を選択する］を選択します。
-
Set-ADControllerDiscovery.ps1スクリプトを使用します（各Controller上にあります）。また、各VDA上のFarmGuidレジストリを、適切な組織単位を指すように構成します。この設定はグループポリシーを使用して行うことができます。
詳しくは、「Active Directoryの組織単位ベースの検出」を参照してください。
MCSベース
VMのプロビジョニングにMCSのみを使用する予定の場合は、ControllerまたはCloud Connectorのリストを設定するようにMCSを構成することができます。この機能は自動更新と互換性があります。MCSは、初回プロビジョニング時（マシンカタログの作成時）にControllerまたはCloud ConnectorのリストをPersonality.iniファイルに書き込みます。自動更新により、このリストが最新に保たれます。
大規模な環境では、この方法の使用は推奨されていません。この方法は次の場合に使用することをお勧めします。
- 環境が小規模である
- サイト間でVDAを移動させない
- VMのプロビジョニングにMCSのみを使用する
- グループポリシーを使用しない
この方法を指定するには次の手順を実行します。
- VDAインストールウィザードの ［Delivery Controller］ ページで、［Machine Creation Servicesで指定する］ を選択します。
推奨事項
ベストプラクティス：
- 初回登録にはグループポリシーによる登録方法を使用します。
- 自動更新（デフォルトで有効化されています）を使用してControllerのリストを最新に保ちます。
- マルチゾーン展開（ControllerまたはCloud Connectorが2つ以上）では、初回構成にグループポリシーを使用します。各ゾーンにローカルのControllerまたはCloud Connectorに対してVDAをポイントします。自動更新を使用して、VDAを最新の状態に保ちます。自動更新により、サテライトゾーンにあるVDAのListOfDDCsが自動で最適化されます。
自動更新
自動更新（XenAppおよびXenDesktop 7.6で導入）は、デフォルトで有効化されています。これは、VDA登録を最新の状態に保つ最も効率的な方法です。初回登録では自動更新は使用しませんが、自動更新ソフトウェアにより、初回登録を行うときにListOfDDCsがダウンロードされ、永続キャッシュに格納されます。これはVDAごとに行われます（このキャッシュには、マシンポリシーの情報も格納されます。これにより、再起動後もポリシー設定が保持されます）。
MCSまたはPVSを使用してマシンをプロビジョニングする場合、自動更新がサポートされます。PVSサーバーのキャッシュは除外されます（自動更新キャッシュ用の永続的なストレージがないためです）。
この方法を指定するには次の手順を実行します。
- 次の設定が含まれるCitrixポリシーで自動更新を有効または無効にします：
Virtual Delivery Agent Settings > Enable auto update of Controllers。この設定項目は、デフォルトで有効になっています。
自動更新の仕組みは次のとおりです。
- VDAの再登録の度（マシンの再起動後など）にキャッシュが更新されます。また、各ControllerまたはCloud Connectorも90分ごとにサイトのデータベースをチェックします。最後のチェック以降にControllerまたはCloud Connectorが追加または削除されていた場合、またはVDA登録に影響するポリシー変更が行われていた場合、ControllerまたはCloud ConnectorからControllerまたはCloud Connectorに登録済みのVDAに最新のリストが送信され、キャッシュが更新されます。VDAは、最近キャッシュ化されたリストに含まれているすべてのControllerまたはCloud Connectorからの接続を受け入れます。
- VDAが受信したリストに登録先のControllerまたはCloud Connectorが含まれていない場合（つまり、そのControllerまたはCloud Connectorがサイトから削除された場合）、ListOfDDCsのいずれかのControllerまたはCloud ConnectorにVDAが再登録されます。
例：
- 環境内に3つのController A、B、Cがあります。VDAは（VDAのインストール時に指定した）Controller Bに登録されています。
- その後、サイトに2つのController（DおよびE）を追加します。90分以内に、更新されたリストがVDAに送信されます。これにより、VDAはController A、B、C、D、Eからの接続を受け入れるようになります（VDAを再起動するまでは、すべてのController間で負荷分散は行われません）。
- さらにそのあとで、Controller Bを別のサイトに移動します。前回のチェック以降にサイトのControllerに変更があったため、元のサイトのVDAは90分以内に更新済みのリストを受信します。初めにController B（リストから削除されています）に登録されていたVDAは、現在のリストに含まれるController（A、C、D、E）のいずれかに再登録されます。
マルチゾーン展開のサテライトゾーンでは、まず自動更新によりすべてのローカルControllerがキャッシュ化されます。プライマリゾーンのControllerはすべて、バックアップグループにキャッシュ化されます。サテライトゾーンのローカルControllerを利用できない場合、プライマリゾーンのControllerへの登録が試みられます。
以下の例に示すように、キャッシュファイルにはホスト名およびセキュリティIDのリスト（ListOfSID）が含まれています。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を別のサイトに移動する場合に役立ちます。
構成に関する考慮事項
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を指定する場合、登録では必要に応じてこれらのControllerまたはCloud Connector間で自動的にフェールオーバーが行われます。自動更新を使用すると、すべてのVDAで自動フェールオーバーが自動的に行われます。
セキュリティ上の理由から、Citrix ADCなどのネットワークロードバランサーは使用できません。VDA登録ではKerberos相互認証を使用しており、クライアント（VDA）はその身元をサービス（Controller）に対して証明する必要があります。また、ControllerまたはCloud Connectorはその身元をVDAに対して証明する必要があります。つまり、VDAとControllerまたはCloud Connectorは、サーバーであるのと同時にクライアントとしても動作するということです。本記事の初めに述べたように、通信チャネルには、VDAからController/Cloud ConnectorとController/Cloud ConnectorからVDAの2つが存在します。
このプロセスのコンポーネントはサービスプリンシパル名（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/en-us/windows/win32/ad/mutual-authentication-using-kerberos?redirectedfrom=MSDN
CNAMEから自動更新への移行
自動更新機能は、バージョン7.x以前のXenAppおよびXenDesktopの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のグループを指定するにはかっこを使用します。たとえばControllerが4つ（主に使用するものが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）が処理されます。
ListOfSIDs
登録時に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を変更する必要がある場合は、HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgentの下にListOfSIDsという名前のレジストリキー（REG_SZ）を作成します。値には、信頼できるSIDの一覧を指定します。SIDが複数ある場合はスペースで区切って指定します。
次の例では、1つのControllerをVDAの登録に使用しますが（ListOfDDCs）、2つのControllerは仲介に使用します（ListOfSIDs）。
VDA登録中のControllerの検索
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登録の問題のトラブルシューティング
先に述べたように、仲介セッションを起動する場合、対象のDelivery ControllerにVDAが登録されている必要があります。VDAが登録されていないと、登録されていれば使用されるはずの資源が使用されない場合があります。VDAが登録されない理由はさまざまですが、その多くは管理者がトラブルシューティングできます。Studioでは、カタログ作成ウィザード内で、およびカタログをデリバリーグループに登録した後に、トラブルシューティング情報が提供されます。
マシンカタログの作成時に問題を特定する：
カタログ作成ウィザードで、既存のマシンを追加すると、コンピューターアカウント名の一覧に、各マシンがカタログに追加するのに適しているかどうかが示されます。各マシンの横にあるアイコンにマウスを合わせると、そのマシンに関する情報メッセージが表示されます。
メッセージで問題のあるマシンが示された場合は、該当のマシンを（［削除］ ボタンを使って）削除することも、そのマシンを追加することもできます。たとえば、（Delivery Controllerで登録されたことがないなどの理由により）マシンに関する情報を取得されていないことを示すメッセージが表示された場合は、そのマシンを追加する可能性があります。
カタログの機能レベルにより、どの製品機能がカタログにあるマシンで利用可能かが制御されます。新しい製品バージョンで導入された機能を使用するには、新しいVDAが必要な場合があります。機能レベルを設定すると、そのバージョン（機能レベルが変更されない場合はそのバージョン以降）で導入されたすべての機能がカタログで利用できるようになります。ただし、以前のVDAバージョンのカタログにあるマシンは登録できません。
デリバリーグループの作成後に問題を特定する：
デリバリーグループを作成すると、そのグループと関連付けられているマシンの詳細がStudioに表示されます。デリバリーグループの［詳細］ペインに、登録されている必要があるのに登録されていないマシンの数が表示されます。つまり、電源が入っており保守モードでないはないのに、Controllerに現在登録されていないマシンが1台または複数台存在することが考えられます。「未登録だが登録する必要がある」マシンが表示された場合は、［詳細］ペインの ［トラブルシューティング］ タブで、考えられる原因と推奨される修正アクションを確認します。
機能レベルについて詳しくは、「マシンカタログの作成」の「VDAバージョンと機能レベル」を参照してください。
VDA登録のトラブルシューティングについて詳しくは、CTX136668を参照してください。
Citrix Health Assistantを使用して、VDA登録とセッションの開始に関するトラブルシューティングを行うことも可能です。詳しくは、CTX207624を参照してください。