このワークフローでは、ポッド マネージャ ベースのポッドのデプロイから仮想デスクトップおよびアプリケーションの構成までの、第 1 世代 Horizon Universal Console の概要レベルの手順について説明します。エンド ユーザーが資格のある仮想デスクトップとアプリケーションを起動すると、手順は終了します。
使用したい機能が管理コンソール内に見つからない場合は、VMware アカウントの担当者に問い合わせて、お持ちのライセンスおよびテナント アカウント構成にその機能を使用する資格が付与されているか確認してください。
- 前提条件に従って準備します。新しいポッド デプロイの VMware Horizon Cloud Service on Microsoft Azure 要件チェックリストを参照してください。
- Horizon Cloud 以外の準備タスクを実行します。Horizon Cloud ポッドを Microsoft Azure にデプロイする前の準備を参照してください。
- ポッドをデプロイするための DNS、ポート、およびプロトコルの要件に従います。Microsoft Azure での Horizon Cloud ポッドの DNS の要件および2019 年 9 月のリリースのマニフェスト以降での Horizon Cloud ポッドのポートとプロトコルの要件を参照してください。
- Horizon Universal Console にログインし、ウィザードを実行してポッドをデプロイします。
- Horizon 制御プレーンで Active Directory ドメインを登録します。ここでは、サービス アカウントの名前を提供することも含まれます。これらのサービス アカウントが、Horizon Cloud の運用に必要なサービス アカウントで説明されている要件を満たしていることを確認します。
- 管理コンソールに対する認証と管理コンソールでの操作の実行について、組織内のメンバーに適切なロールを割り当てます。Horizon Cloud で使用されるロールには 2 つのタイプがあります。クラウドベースのコンソールを使用して Horizon Cloud 環境で作業するためにユーザーに付与する 2 種類のロールに関するベスト プラクティスを参照してください。
- テナントの Universal Broker 構成を完了します。Universal Broker 設定の構成を参照してください。
- DNS サーバに必要な CNAME レコードを作成します。Universal Broker に対するこれらの CNAME および CNAME レコード要件の目的については、DNS サーバでマッピングする Horizon Cloud ポッドのゲートウェイのロード バランサ情報の取得方法およびUniversal Broker 設定の構成を参照してください。
注: 構成の Azure ロード バランサにプライベート IP アドレスを使用する外部ゲートウェイ構成がある場合は、そのプライベート IP アドレスへのインターネット トラフィックを管理するファイアウォールまたは NAT があることが必須です。そのファイアウォールまたは NAT は、パブリック IP アドレスを提供し、外部ゲートウェイ構成のデプロイ時に指定された FQDN がパブリックに解決可能になるように構成される必要があります。制御プレーンは、外部ゲートウェイに対して指定された FQDN と通信できる必要があります。
- オプション:Horizon Cloud テナント アカウントが VMware Cloud Services エンゲージメント プラットフォームにまだオンボーディングされていない場合は、ここでオンボーディングすることを推奨します。クラウドベースのコンソールを使用して Horizon Cloud テナントを VMware Cloud Services エンゲージメント プラットフォームにオンボーディングするを参照してください。
- ゴールド イメージを作成します。ゴールド イメージの作成は、マルチステップ プロセスで行います。Horizon Cloud テナントで使用できるゴールド イメージを作成するさまざまな方法の概要については、Microsoft Azure に Horizon Cloud ポッドのデスクトップ イメージを作成を参照してください。ゴールド イメージの作成は、ベース仮想マシンのインポートから開始します。このベース仮想マシンは、ビジネスおよびエンド ユーザーのニーズに合わせてカスタマイズします。
- イメージが最終的に意図するエンドユーザー割り当てのタイプに応じて、必要に応じて次の手順の 1 つ以上を実行します。
- 単一セッション VDI デスクトップまたはネイティブ アプリケーションのプロビジョニングに使用される単一セッション イメージで、エンド ユーザーが VDI デスクトップで使用するサードパーティ アプリケーションをインストールし、デスクトップ壁紙の設定、(GPU 対応のイメージのための)GPU ドライバのインストールなどのその他の適用可能なカスタマイズを構成します。イメージのインポート プロセスの一部として実行されていない場合、Microsoft Sysprep のベスト プラクティスに従ってイメージを最適化することもできます。イメージ仮想マシンの Microsoft Windows クライアント オペレーティング システムのカスタマイズ、適切な GPU ドライバのインストール、および最適なリモート エクスペリエンス パフォーマンスを得るためにゴールド イメージで実行すべき 5 つの重要なステップを参照してください。
ヒント: イメージ仮想マシンをさらに調整して、VDI の使用事例で VMware Blast Extreme を使用するための構成を改善するには、 VMware Blast Extreme 最適化ガイドを読み、そのガイドのコーデック オプションに関する推奨事項に従って、イメージ内のコーデック オプションの追加のチューニングを実行することがベスト プラクティスです。
- マルチセッション デスクトップとリモート アプリケーションのプロビジョニングに使用されるマルチセッション イメージで、そのマルチセッション イメージからエンド ユーザーに提供するサードパーティ アプリケーションをインストールし、デスクトップ壁紙の設定、(GPU 対応のイメージのための)GPU ドライバのインストールなどの適用可能なその他のカスタマイズを構成します。イメージのインポート プロセスの一部として実行されていない場合、Microsoft Sysprep のベスト プラクティスに従ってイメージを最適化することもできます。インポートされた仮想マシンが、デフォルトで Office 365 ProPlus を含む Microsoft Windows 10 または Windows 11 Enterprise マルチセッション システムの 1 つを実行している場合、Microsoft のドキュメント トピックOffice 365 ProPlus に対する共有コンピュータのライセンス認証の概要で説明されているように、仮想マシンが Office 365 ProPlus の共有コンピュータのアクティベーション用に構成されていることを確認する必要があります。インポートされた仮想マシンで Office 365 ProPlus が共有コンピュータのアクティベーション用に構成されていない場合は、状況に適した Microsoft ドキュメントに記載されている方法を使用してください。イメージ仮想マシンの Microsoft Windows Server オペレーティング システムのカスタマイズ、イメージ仮想マシンの Microsoft Windows 10 Enterprise マルチセッション オペレーティング システムのカスタマイズ、適切な GPU ドライバのインストール、および最適なリモート エクスペリエンス パフォーマンスを得るためにゴールド イメージで実行すべき 5 つの重要なステップを参照してください。
ヒント: イメージ仮想マシンをさらに調整して、VDI の使用事例で VMware Blast Extreme を使用するための構成を改善するには、 VMware Blast Extreme 最適化ガイドを読み、そのガイドのコーデック オプションに関する推奨事項に従って、イメージ内のコーデック オプションの追加のチューニングを実行することがベスト プラクティスです。
- 単一セッション VDI デスクトップまたはネイティブ アプリケーションのプロビジョニングに使用される単一セッション イメージで、エンド ユーザーが VDI デスクトップで使用するサードパーティ アプリケーションをインストールし、デスクトップ壁紙の設定、(GPU 対応のイメージのための)GPU ドライバのインストールなどのその他の適用可能なカスタマイズを構成します。イメージのインポート プロセスの一部として実行されていない場合、Microsoft Sysprep のベスト プラクティスに従ってイメージを最適化することもできます。イメージ仮想マシンの Microsoft Windows クライアント オペレーティング システムのカスタマイズ、適切な GPU ドライバのインストール、および最適なリモート エクスペリエンス パフォーマンスを得るためにゴールド イメージで実行すべき 5 つの重要なステップを参照してください。
- そのイメージを、割り当て可能なイメージ(イメージのシーリングまたは公開とも呼ばれる)に変換します。構成済み仮想マシンを割り当て可能なイメージに変換するを参照してください。
- 公開済みのマルチセッション イメージからセッション デスクトップとリモート アプリケーションをプロビジョニングするには、次の手順を実行します。
- セッション デスクトップを提供するデスクトップ ファームを作成し、エンド ユーザーにこれらのデスクトップを使用する資格を付与するための割り当てを作成します。ファームの作成およびRDSH セッション デスクトップ割り当ての作成を参照してください。
- リモート アプリケーションを提供するアプリケーション ファームを作成し、アプリケーション インベントリにアプリケーションを追加してから、エンド ユーザーにこれらのリモート アプリケーションを使用する資格を付与するための割り当てを作成します。ファームの作成、RDSH ファームからの新しいリモート アプリケーションのインポート、およびリモート アプリケーション割り当ての作成を参照してください。
- 公開済みの単一セッション VDI デスクトップ イメージから単一セッション VDI デスクトップをプロビジョニングするには、専用またはフローティング VDI デスクトップ割り当てを作成します。これらのデスクトップ割り当ての作成については、Microsoft Azure での Horizon Cloud 環境のポッドのデスクトップ割り当てについてとそのセクションを参照してください。
- App Volumes アプリケーションをエンドユーザーにプロビジョニングするには、App Volumes アプリケーションをアプリケーション インベントリに追加し、エンドユーザーにそれらのアプリケーションを使用する資格を与えるアプリケーション割り当てを作成します。次に、デスクトップ割り当てを作成し、エンド ユーザーにそれらのアプリケーションをベース デスクトップで使用できる資格を付与します。アプリケーション割り当てにより、ユーザーは資格が付与されたデスクトップの Windows オペレーティング システム内で、ユーザーに資格が割り当てられた App Volumes アプリケーションを使用できるようになります。App Volumes アプリケーション - 概要と前提条件を参照してください。
- デプロイに 2 要素認証構成がある場合は、次のタスクを実行する必要があります。
- ポッドの外部ゲートウェイに 2 要素認証が構成され、ゲートウェイの Unified Access Gateway インスタンスがデプロイされているのと同じ VNet トポロジ内で 2 要素認証サーバにアクセスできない場合は、外部ゲートウェイのロード バランサの IP アドレスからの通信を許可するようにその 2 要素認証サーバを構成します。
このシナリオでは、ゲートウェイ展開と同じ VNet トポロジ内で 2 要素認証サーバにアクセスできないため、Unified Access Gateway インスタンスは、そのロード バランサ アドレスを使用してそのサーバとの接続を試みます。その通信トラフィックを許可するには、その外部ゲートウェイのリソース グループにあるロード バランサ リソースの IP アドレスが、確実に 2 要素認証サーバの構成でクライアントまたは登録されたエージェントとして指定されているようにします。この通信を許可する方法の詳細については、お使いの 2 要素認証サーバのドキュメントを参照してください。
- 同じ VNet トポロジ内で 2 要素認証サーバにアクセスできる場合は、Microsoft Azure でのデプロイの Unified Access Gateway インスタンス用に作成された適切な NIC からの通信を許可するように 2 要素認証サーバを構成します。
ネットワーク管理者が、展開に使用される Azure VNet トポロジとそのサブネットに対する 2 要素認証サーバのネットワーク可視性を決定します。2 要素認証サーバは、ネットワーク管理者が 2 要素認証サーバにネットワークの可視性を与えたサブネットに対応する Unified Access Gateway インスタンスの NIC の IP アドレスからの通信を許可する必要があります。
Microsoft Azure のゲートウェイのリソース グループには、そのサブネットに対応する 4 つの NIC があり、そのうち 2 つが 2 個の Unified Access Gateway インスタンスに対して現在アクティブです。もう 2 つはアイドル状態で、ポッドとそのゲートウェイが更新を完了した後にアクティブになります。
実行中のポッド操作のため、および各ポッドの更新後のために、ゲートウェイと 2 要素認証サーバ間の通信トラフィックをサポートするには、これらの 4 つの NIC の IP アドレスがそのサーバ構成でクライアントまたは登録されたエージェントとして指定されていることを確認します。この通信を許可する方法の詳細については、お使いの 2 要素認証サーバのドキュメントを参照してください。
これらの IP アドレスを取得する方法については、必要な Horizon Cloud ポッド ゲートウェイ情報での 2 要素認証システムの更新を参照してください。
- ポッドの外部ゲートウェイに 2 要素認証が構成され、ゲートウェイの Unified Access Gateway インスタンスがデプロイされているのと同じ VNet トポロジ内で 2 要素認証サーバにアクセスできない場合は、外部ゲートウェイのロード バランサの IP アドレスからの通信を許可するようにその 2 要素認証サーバを構成します。
上記のワークフローの手順が完了したら、Universal Broker の仲介 FQDN をエンド ユーザーに提供します。エンド ユーザーは Horizon Client または Horizon HTML Access(Web クライアント)でその仲介 FQDN を使用して、使用資格が付与されたデスクトップとリモート アプリケーションを起動します。
各ワークフロー手順を実行する方法の詳細については、上記の各手順にリンクされたトピックを参照してください。