This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
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のアドレスを指定しなかった場合)、メッセージが表示されて通知されます。
コントローラーまたはクラウドコネクタのアドレスの構成方法
管理者は、VDAが初めて登録する際(初回登録時)に使用する構成方法を選択します。初回登録時に、VDA上に永続的なキャッシュが作成されます。その後の登録では、構成の変更が検出されない限り、VDAはこのローカルキャッシュからControllerまたはCloud Connectorのリストを取得します。
その後の登録でそのリストを取得する最も簡単な方法は、自動更新機能を使用することです。自動更新はデフォルトで有効になっています。詳細については、「自動更新」を参照してください。
VDA上でControllerまたはCloud Connectorアドレスを構成する方法はいくつかあります。
- ポリシーベース (LGPOまたはGPO)
- レジストリベース (手動、グループポリシー設定 (GPP)、VDAインストール時に指定)
- アクティブディレクトリOUベース (従来のOU検出)
- エムシーエスに基づいた (personality.ini)
VDAをインストールする際に、初期登録方法を指定します。(自動更新を無効にした場合、VDAインストール時に選択した方法が以降の登録に使用されます。)
次の図は、VDAインストールウィザードのDelivery Controllerページを示しています。
VDAインストールウィザードのデリバリーコントローラーページ(/ja-jp/citrix-virtual-apps-desktops/2511/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に保存されます。
このレジストリキーは手動で構成することも、グループポリシー設定 (GPP) を使用することもできます。この方法は、ポリシーベースの方法よりも推奨される場合があります(たとえば、異なるControllerまたはCloud Connectorの条件付き処理が必要な場合、XDW-001-で始まるコンピューター名にはXDC-001を使用するなど)。
サイト内のすべてのControllerまたはCloud ConnectorのFQDNを一覧表示するListOfDDCsレジストリキーを更新します。(このキーは、Active DirectoryサイトOUに相当します。)
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfDDCs (REG_SZ)
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgentレジストリの場所にListOfDDCsとFarmGUIDの両方のキーが含まれている場合、ControllerまたはCloud Connectorの検出にはListOfDDCsが使用されます。FarmGUIDは、VDAインストール中にサイトOUが指定された場合に存在します。(これはレガシー展開で使用される場合があります。)
必要に応じて、ListOfSIDsレジストリキーを更新します(詳細については、ListOfSIDsを参照してください)。
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs (REG_SZ)
注意:VDAインストール中に指定した設定を上書きするCitrixポリシーを通じてポリシーベースのVDA登録も有効にする場合、それは優先度の高い方法であるためです。
アクティブディレクトリ 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) <!--NeedCopy--> - 起動時の登録遅延を防ぐため、
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の登録キャッシュファイルの例(/ja-jp/citrix-virtual-apps-desktops/2511/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登録構成を表示します。
VDA登録手順を表示します。
VDA登録に影響を与える可能性のある項目を構成する際は、以下を考慮してください。
コントローラーまたは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 が失敗した場合に他方のグループをフェールオーバーに使用したい場合があります。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 の自動更新を有効にするポリシーを禁止する必要があります。
SIDのリスト
VDA が登録のために連絡できる Controller のリストは ListofDDCs です。VDA は、ListofDDCs の Controller を自動的に信頼しないため、どの Controller を信頼すべきかも知る必要があります。ListofSIDs (セキュリティ ID) は、信頼された Controller を識別します。VDA は、信頼された Controller のみに登録を試みます。
ほとんどの環境では、ListofSIDs は ListofDDCs から自動的に生成されます。ListofSIDs を読み取るには、CDF トレースを使用できます。
通常、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) が使用されます。

VDA登録中のコントローラー検索
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」に設定すると、フォールバック検索が有効になります。コントローラーの初期検索が失敗した場合、フォールバックのトップダウン検索が開始されます。これはデフォルトの動作です。ただし、ゼロ以外の値に設定すると、フォールバック検索は無効になります。コントローラーの初期検索が失敗した場合、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」を参照してください。
-
Citrix Scoutのヘルスチェックを使用して、VDA登録とセッション起動のトラブルシューティングを行うこともできます。詳細については、「ヘルスチェックについて」を参照してください。
共有
共有
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.