このチェックリストは、ポッドを Horizon Cloud から Microsoft Azure にデプロイするために Microsoft Azure サブスクリプションとネットワークを準備するのに役立ちます。以下に説明する要件を確実に満たすことで、新しいポッドのデプロイを正常に完了し、ポッドのデプロイ後に完了する必要がある主要なタスクを正常に完了することができます。

このチェックリストは、2021 年 5 月のサービス リリース日より前に、ポッドがテナント環境にデプロイまたはクラウド接続されていない Horizon Cloud ユーザー アカウントを対象としています。このような環境は、クリーンスレート環境またはグリーンフィールド環境と呼ばれる場合があります。サービス リリース日にクラウド プレーン バイナリと新しいポッド マニフェスト バージョンがクラウド プレーンにプッシュされた後に発生する新しいポッドのデプロイは、新しいポッド マニフェスト バージョンを使用してデプロイされます。ポッドを正常にデプロイするための要件は、主にポッドのマニフェスト バージョンによって決まります。本番環境のクラウド プレーンにあるクラウド プレーンのバイナリは、正常にデプロイするための要件を決定する場合もあります。

以下にリストした一部の要件は、ポッドのデプロイ自体に必要なものです。これらの要件は、ポッドからプロビジョニングされたデスクトップとアプリケーションをエンド ユーザーに提供する本番のテナント環境を取得するために、ポッドのデプロイ後に実行される主要なタスクに必要な要件です。

ポッドのデプロイ自体の要件
ポッドのデプロイ後の本番環境の要件
重要: ポッド デプロイ ウィザードを起動してポッドのデプロイを開始する前に、以下の要件に加えて、次の重要な点に注意する必要があります。
  • 2020 年 7 月以降のサービス リリースでは、新しい環境で、少なくとも 1 つのゲートウェイ構成を使用して新しいポッドをデプロイする必要があります。カスタマ アカウントが 2020 年 7 月リリースより前に作成されていて、最初のポッドをデプロイしていない場合、最初のポッドのデプロイでは、ポッドのデプロイ時に少なくとも 1 つのゲートウェイ構成を指定する必要があります。
  • ポッドのデプロイを成功させるには、ユーザーまたは IT チームが Microsoft Azure 環境で設定したどの Microsoft Azure ポリシーも、ポッドのコンポーネントの作成をブロック、拒否、または制限しないようにすることが必要です。また、Microsoft Azure ポリシーの組み込みポリシー定義がポッドのコンポーネントの作成をブロック、拒否、または制限しないことを確認する必要があります。たとえば、ユーザーおよび IT チームは、Microsoft Azure ポリシーが Azure ストレージ アカウントでのコンポーネントの作成をブロック、拒否、または制限しないことを確認する必要があります。Azure ポリシーの詳細については、Azure ポリシーのドキュメントを参照してください。
  • ポッド デプロイヤでは、デプロイヤによる Azure StorageV1 および StorageV2 アカウント タイプの使用を Azure ストレージ アカウントで許可されていることが必要です。Microsoft Azure ポリシーが、Azure StorageV1 および StorageV2 アカウント タイプを必要とするコンテンツの作成を制限したり拒否したりしないようにします。
  • デプロイ ウィザードでカスタム リソース タグを指定しない場合、ポッドおよびゲートウェイのデプロイ プロセスの一部として、Horizon Cloud はタグが付いていないリソース グループ (RG) を Microsoft Azure サブスクリプションに作成します。これには、これらのデプロイ プロセスをオーケストレーションする一時ジャンプ ボックス用に作成される初期リソース グループが含まれます。2020 年 10 月 8 日の時点で、デプロイ ウィザードには、デプロイヤで作成されたリソース グループに適用するカスタム リソース タグを指定する機能があります。カスタム リソース タグが指定されておらず、Microsoft Azure サブスクリプションに何らかの種類のリソース タグ要件がある場合、そのサブスクリプションにポッドをデプロイしようとすると、ポッドのデプロイが失敗します。または、ポッドの更新時やポッドにゲートウェイ構成を追加する際に、ポッドのデプロイが失敗します。デプロイ ウィザードの [カスタム リソース タグ] 機能を使用する予定がない場合は、Microsoft Azure ポリシーによって、ポッドのタグなしリソース グループをターゲット サブスクリプションで作成できることを確認する必要があります。デプロイヤが作成する RG のリストについては、『管理ガイド』のMicrosoft Azure にデプロイされたポッド用に作成されたリソース グループトピックを参照してください。
  • すべてのクラウド接続されたポッドは、それらのポッドをデプロイするときに、Active Directory ドメインの同じセットに接続されている必要があります。

Horizon Cloud 制御プレーンの要件

Horizon Cloud 制御プレーンにログインするためのアクティブな My VMware アカウント。

Microsoft Azure サブスクリプションの要件

サポートされている Microsoft Azure 環境(Azure Commercial、Azure China、Azure Government)で有効な Microsoft Azure サブスクリプション。外部 Unified Access Gateway を専用のサブスクリプションを使用して個別の VNet にデプロイする場合、同じ Microsoft Azure 環境に追加の有効な Microsoft Azure サブスクリプションが必要です。
注: Horizon Cloud は、大部分の Microsoft Azure リージョンをサポートしています。現在サポートされていない Microsoft Azure リージョンのリストについては、 VMware ナレッジベースの記事「Microsoft Azure Regions with Horizon Cloud Service on Microsoft Azure (77121)」を参照してください。
Microsoft Azure サブスクリプションで有効な Microsoft Azure 管理者権限。詳細については、Microsoft ドキュメントのAzure ポータルでのロールベースのアクセス制御の開始を参照してください。
予想されるデスクトップおよびアプリのワークロードに加えて、Horizon Cloud インフラストラクチャの Microsoft Azure の最小キャパシティが利用可能であること。キャパシティが利用可能になっている限りは、Horizon Cloud によって以下の仮想マシンが自動的にデプロイされるため、手動でのインストールは必要ありません。
  • ポッド デプロイ エンジン、(一時的な)ジャンプ ボックスとも呼ばれます — Standard_F2 x 1
  • 高可用性が有効なポッド/ポッド マネージャ - Standard_D4_v3 x 2(リージョン内に Standard_D4_v3 がない場合は Standard_D3_v2 x 2)
  • 高可用性が有効でないポッド/ポッド マネージャ - Standard_D4_v3 x 1(リージョン内に Standard_D4_v3 がない場合は Standard_D3_v2 x 1)
  • Microsoft Azure Database for PostgreSQL サービス - 第 5 世代、メモリ最適化、2 つの vCore、10 GB ストレージ
  • 外部 Unified Access Gateway(内部ゲートウェイが指定されていない場合は任意) — 2 x Standard_A4_v2 または 2 x Standard_F8s_v2
  • 内部 Unified Access Gateway(外部ゲートウェイが指定されていない場合は任意) — 2 x Standard_A4_v2 または 2 x Standard_F8s_v2
注:
  • 2020 年 7 月のサービス リリース以降、クリーンスレート環境では、少なくとも 1 つのゲートウェイ構成でデプロイするために新しいポッドが必要です。カスタマ アカウントが 2020 年 7 月リリースより前に作成されていて、最初のポッドをデプロイしていない場合、最初のポッドのデプロイでは、ポッドのデプロイ時に少なくとも 1 つのゲートウェイ構成を指定する必要があります。そのため、上記のリストに記載されているように、使用可能な Microsoft Azure の最小キャパシティは、ゲートウェイ構成のいずれかの仮想マシンに対応できる必要があります。
  • サブスクリプションのリージョンが Standard_F8s_v2 の仮想マシン サイズに対応していない場合、ポッドのデプロイヤ ウィザードでは、[ゲートウェイの指定] ウィザードの手順のセレクタに選択肢が表示されません。
  • ポッドのデプロイが完了したら、Microsoft Azure クラウドのキャパシティは、そのポッドで作成するインポートされた仮想マシン、ゴールド イメージ、仮想デスクトップ、および RDSH ファームにも対応する必要があります。アカウントが App Volumes 機能を使用できるようになっていて、コンソールのアプリケーション キャプチャ ワークフローを使用している場合、キャパシティはそのキャプチャ プロセスで使用されるシステム生成のデスクトップ割り当ての仮想マシンにも対応する必要があります。以下のHorizon Cloud 基本イメージ、デスクトップ、およびファームのセクションを参照してください。
  • テナント アカウントが Horizon インフラストラクチャの監視 機能を使用できるようになっていて、ポッドのデプロイ後にポッドでその機能を有効にする予定の場合は、キャパシティは Horizon Edge 仮想アプライアンス のデプロイの時点でも対応する必要があります。以下のHorizon インフラストラクチャの監視要件セクションを参照してください。

外部 Unified Access Gateway は、ポッドと同じサブスクリプションを使用するか、別のサブスクリプションを使用して、専用の Microsoft Azure 仮想ネットワーク (VNet) にオプションでデプロイできます。外部 Unified Access Gateway を専用の VNet にデプロイする場合、外部 Unified Access Gateway がデプロイされるサブスクリプションには次のキャパシティが必要です。

  • 外部 Unified Access Gateway デプロイ エンジン、(一時的な)ゲートウェイ ジャンプ ボックスとも呼ばれます — Standard_F2 x 1
  • 外部ゲートウェイ コネクタ — Standard_A1_v2 x 1
  • 外部Unified Access Gateway — 2 x Standard_A4_v2 または 2 x Standard_F8s_v2。
サブスクリプションごとに作成されたサービス プリンシパルと認証キー。詳細については、方法:リソースにアクセスできる Azure AD アプリケーションとサービス プリンシパルをポータルで作成するを参照。アプリケーション登録を作成して Horizon Cloud ポッド デプロイヤに必要なサービス プリンシパルを作成するも参照してください。
各サービス プリンシパルには、サブスクリプションで Horizon Cloud が実行する必要があるアクションを許可する適切なロールを割り当てる必要があります。このロールには、サブスクリプション レベルで必要な許可されたアクションを持つ共同作成者ロールまたはカスタム ロールがあります。別のサブスクリプションの既存のリソース グループに外部ゲートウェイ構成をデプロイする場合、そのサブスクリプションのサービス プリンシパルに対してよりきめ細かい権限を設定できます。必要なロール アクションの詳細については、Microsoft Azure サブスクリプションでの Horizon Cloud によって要求される操作を参照。
重要: ロールは、 Horizon Cloud に使用されるサービス プリンシパルに直接割り当てる必要があります。サービス プリンシパルへのロールのグループベースの割り当ての使用(ロールがグループに割り当てられ、サービス プリンシパルがそのグループのメンバーとなる)はサポートされていません。
必要なリソース プロバイダが各 Microsoft Azure サブスクリプションで登録されていること。アプリケーション登録を作成して Horizon Cloud ポッド デプロイヤに必要なサービス プリンシパルを作成するの手順 8.b を参照してください。
Microsoft Azure サブスクリプション ID、ディレクトリ ID、アプリケーション ID、およびキーが特定されていること。
外部 Unified Access Gateway を独自のサブスクリプションを使用して別の VNet にデプロイし、ポッド デプロイヤによって作成されたリソース グループではなく、ユーザーによって管理されるリソース グループを組織で使用する必要がある場合は、外部 Unified Access Gateway を独自の名前付きリソース グループにデプロイする機能を使用します。その機能を使用するには、ポッド デプロイヤを実行する前に、サブスクリプションにそのリソース グループを作成する必要があります。また、ポッド デプロイヤが Unified Access Gateway 構成をそのリソース グループにデプロイし、構成を管理し、標準のポッド更新プロセスで Unified Access Gateway ソフトウェアを更新するために必要な権限が設定されていることを確認する必要があります。必要な権限の詳細については、Microsoft Azure サブスクリプションでの Horizon Cloud によって要求される操作を参照。

ネットワーク要件

必要なサブネットをカバーする適切なアドレス空間を使用して、目的の Microsoft Azure リージョンに Microsoft Azure 仮想ネットワーク (VNet) が作成済みであること。詳細については、Azure 仮想ネットワークを参照。

外部 Unified Access Gateway をポッドの VNet とは別の独自の VNet にデプロイする場合、ポッドの VNet と同じ Microsoft Azure リージョンに必要なサブネットをカバーする適切なアドレス空間を持つ Unified Access Gateway VNet を作成し、2 つの VNet をピアリングします。

ポッド の VNet の重複していない 3 つのアドレス範囲(CIDR 形式)がサブネット用に予約済みであること。
  • 管理サブネット - /27 以上
  • 仮想マシン サブネット - プライマリ(テナント)- /27 以上。/24 ~ /22 を推奨(デスクトップおよび RDS サーバの数に基づく)
  • DMZ サブネット — ポッドの VNet に Unified Access Gateway がデプロイされている場合は /28 以上(オプション)
サブネットは、VNet 上で手動で作成することも、デプロイ中に Horizon Cloud によって作成することもできます。手動で作成されたサブネットを使用する場合、他のリソースは接続できません。
注: マニフェスト 2298.0 以降で新たにデプロイされたポッドの場合、ポッドがデプロイされた後に、ポッドを編集して、ファームおよびデスクトップ割り当ての仮想マシンで使用するための追加のテナント サブネットを追加できます。追加のテナント サブネットは、ポッドがデプロイされているのと同じ VNet、またはピアリングされた VNet に配置できます。詳細については、『管理ガイド 』を参照してください。
外部 Unified Access Gateway をポッドの VNet とは別の独自の VNet にデプロイする場合、Unified Access Gateway の VNet で 3 つの重複しないアドレス範囲(CIDR 形式)がサブネット用に予約されていること。
  • 管理サブネット - /27 以上
  • バックエンド サブネット - /27 以上。/24 ~ /22 を推奨(デスクトップおよび RDS サーバの数に基づく)
  • DMZ(フロント エンド)サブネット — /28 以上
サブネットは、VNet 上で手動で作成することも、デプロイ中に Horizon Cloud によって作成することもできます。手動で作成されたサブネットを使用する場合、他のリソースは接続できません。この使用事例では通常、サブネットは手動で作成されます。この使用事例では、バックエンド サブネットの目的は、前述の表の行に記載されている [仮想マシンのサブネット(プライマリ)] の目的と同様です。
Horizon Cloud ポッドおよび Unified Access Gateway インスタンスからアクセス可能な 1 つまたは複数の NTP サーバ。
内部マシン名と外部名の両方を解決できる有効な DNS サーバを参照するように VNet (仮想ネットワーク) DNS サーバを構成していること。
ポッドおよびゲートウェイのデプロイに使用している VNet 上のアウトバウンド インターネット アクセスは、特定のポートおよびプロトコルを使用して特定の DNS 名を解決し、アクセスする必要があります。これは、デプロイおよび継続的な運用に必要です。DNS 名とポートのリストについては、Microsoft の Horizon Cloud ポッドおよび関連サービス機能の DNS 要件2019 年 9 月のリリースのマニフェスト以降の Horizon Cloud ポッドのポートとプロトコルの要件 を参照してください。
プロキシ サーバ情報(VNet での外部へのインターネット アクセスに必要な場合)。Horizon Cloud 環境のデプロイおよび継続的な運用で使用されます(オプション)。
Microsoft Azure VPN/ExpressRoute が構成済みであること(オプション)。
外部および内部ユーザー アクセス用の FQDN(Unified Access Gateway を使用してポッドをデプロイする場合に必要)。
注: 2020 年 12 月 15 日時点のクラウド プレーンの更新では、ポッドの外部ゲートウェイと内部ゲートウェイの構成で異なる FQDN を使用することがサポートされます。2020 年 12 月 15 日以前は、システムにより強制的にマニフェスト 2298 以降のポッドに同じ FQDN を使用するようになっていました。ユーザーは現在、ポッドのゲートウェイで異なる FQDN を使用するか、同じ FQDN を使用するかを任意に選択できるようになりました。両方のゲートウェイで同じ FQDN を使用する場合は、ポッドのデプロイ後、スプリット DNS(スプリット Domain Name System)を構成して、エンド ユーザー クライアントの DNS クエリのオリジン ネットワークに応じて、外部ゲートウェイまたは内部ゲートウェイのいずれかにゲートウェイ アドレスを解決します。次に、エンド ユーザー クライアントで使用されているのと同じ FQDN で、クライアントがインターネット上にある場合は外部ゲートウェイにルーティングし、クライアントが内部ネットワーク上にある場合は内部ゲートウェイにルーティングできます。
FQDN に一致する PEM 形式の Unified Access Gateway の証明書(Unified Access Gateway を使用してポッドをデプロイする場合に必要)。
注: この目的で提供する 1 つまたは複数の証明書が、特定の DNS 名を参照する CRL(証明書失効リスト)または OCSP(オンライン証明書ステータス プロトコル)の設定を使用する場合、次に、それらの DNS 名への VNet 上のアウトバウンド インターネット アクセスが解決可能で到達可能であることを確認する必要があります。 Unified Access Gateway ゲートウェイ構成で提供された証明書を構成するときに、 Unified Access Gateway ソフトウェアはこれらの DNS 名にアクセスして、証明書の失効ステータスを確認します。これらの DNS 名にアクセスできない場合、ポッドのデプロイは 接続中フェーズにおいて失敗します。これらの名前は、証明書の取得に使用した CA に大きく依存しているため、VMware のコントロールには含まれません。
オンプレミス RADIUS 認証サーバへの 2 要素認証(オプション)
  • 認証サーバの名前を解決するための Unified Access Gateway の DNS アドレス
  • 認証サーバへのネットワーク ルーティングを解決する Unified Access Gateway のルート
注: ポッドがデプロイされた後、 Universal Broker を使用するように環境を設定してデスクトップをエンド ユーザーにブローカする場合は、内部ネットワーク上のエンド ユーザーの 2 要素認証をスキップするときに、追加の構成が必要になります。ポッドの内部 Unified Access Gateway インスタンスは、そのような内部エンド ユーザーの接続要求を仮想デスクトップとアプリケーションにルーティングします。ポッドに内部ゲートウェイ構成がある場合に、環境で Universal Broker が使用されるよう設定することを計画し、外部エンド ユーザーに対して 2 要素認証を要求しますが内部エンド ユーザーに対しては 2 要素認証をスキップするとします。ポッドがデプロイされたら、内部エンド ユーザーを外部エンド ユーザーから識別して 2 要素認証をスキップするようにするために使用する、 Universal Broker の IP アドレス範囲を入力します。詳細については、ドキュメントのトピック Horizon Cloud テナント環境での仲介方法とエンドユーザーの割り当ての設定、およびそのサブトピックを参照してください。

ポートとプロトコルの要件

ポッドのオンボーディングと Horizon Cloud 環境の継続的な運用には特定のポートとプロトコルが必要です。2019 年 9 月のリリースのマニフェスト以降の Horizon Cloud ポッドのポートとプロトコルの要件を参照してください。

ポッドのデプロイ ワークフロー

上記の項目は、ポッドのデプロイ ウィザードを開始する前に必要です。上記の項目が整っていることを確認したら、Horizon Cloud テナント環境への最初のポッドとして、Microsoft Azure 上の Horizon ポッドを追加する場合のワークフローの概要 のポッド デプロイの手順 4 までを実行してポッドをデプロイします。

ポッドが正常にデプロイされたら、次のセクションで説明する項目を確認し、概要レベル ワークフローの残りの主要な手順を完了します。

Active Directory の要件

Active Directory の登録ワークフローには、次の項目が必要です。このワークフローを理解するには、Horizon Cloud 環境での最初の Active Directory ドメイン登録の実行を参照してください。

サポートされている次の Active Directory 構成のいずれか:
  • VPN/ExpressRoute を介して接続されたオンプレミス Active Directory サーバ
  • Microsoft Azure にある Active Directory サーバ
  • Microsoft Azure の Active Directory ドメイン サービス
サポートされる Microsoft Windows Active Directory Domain Services (AD DS) ドメイン機能レベル:
  • Microsoft Windows Server 2008 R2
  • Microsoft Windows Server 2012 R2
  • Microsoft Windows Server 2016
同じ Horizon Cloud 顧客アカウントのすべてのクラウド接続されたポッドは、それらのポッドをデプロイするときに、Active Directory ドメインの同じセットを認識できる必要があります。この要件は、最初のポッドの後に Microsoft Azure にデプロイする追加のポッドだけでなく、Horizon Cloud Connector を使用して同じ顧客アカウントにクラウド接続されるすべての Horizon ポッドにも適用されます。Horizon Cloud での VMware Horizon ポッド:要件チェックリスト - 2021 年 5 月のサービス リリース以降のポッドを接続するために適切に更新されましたでは、このような Horizon ポッドのチェックリストを確認できます。
重要: このアカウントに求められる主な特性については、 Horizon Cloud の運用に必要なサービス アカウントをご覧ください。

ドメイン バインド アカウント

  • sAMAccountName 属性を持つ Active Directory ドメイン バインド アカウント(読み取りアクセス権限を持つ標準ユーザー)。sAMAccountName 属性は 20 文字以下にする必要があります。また、"/ \ [ ] : ; | = , + * ? < > の文字を含めることはできません。
  • アカウントは、以下の権限を持つ必要があります。
    • コンテンツの一覧表示
    • すべてのプロパティの読み取り
    • アクセス許可の読み取り
    • tokenGroupsGlobalAndUniversal の読み取りすべてのプロパティの読み取り により暗黙に含まれる)
  • VMware Horizon オンプレミス製品に精通しているのであれば、上記の権限は、この Horizon オンプレミスのドキュメント トピックに記載されている、Horizon オンプレミス製品のセカンダリ認証情報アカウントに必要なセットと同じであることがわかります。
  • 一般的に、ドメイン バインド アカウントには、Microsoft Active Directory デプロイで認証されたユーザーに通常付与される、デフォルトの特別な設定は不要の読み取りアクセス関連の権限が付与されている必要があります。ただし、組織の Active Directory 管理者が通常ユーザーの読み取りアクセス権に関連する権限をロックダウンすることを選択した場合は、それらの Active Directory 管理者に、Horizon Cloud に使用するドメイン バインド アカウントの認証済みユーザーの標準デフォルト設定を保持するように要求する必要があります。

また、アカウントのパスワードを 無期限 に設定して、Horizon Cloud 環境にログインするために引き続きアクセスできるようにする必要があります。

詳細および要件については、Horizon Cloud の運用に必要なサービス アカウントを参照。

重要: このアカウントに求められる主な特性については、 Horizon Cloud の運用に必要なサービス アカウントをご覧ください。

補助ドメイン バインド アカウント — 上記と同じアカウントは使用できません。

  • sAMAccountName 属性を持つ Active Directory ドメイン バインド アカウント(読み取りアクセス権限を持つ標準ユーザー)。sAMAccountName 属性は 20 文字以下にする必要があります。また、"/ \ [ ] : ; | = , + * ? < > の文字を含めることはできません。
  • アカウントは、以下の権限を持つ必要があります。
    • コンテンツの一覧表示
    • すべてのプロパティの読み取り
    • アクセス許可の読み取り
    • tokenGroupsGlobalAndUniversal の読み取りすべてのプロパティの読み取り により暗黙に含まれる)
  • VMware Horizon オンプレミス製品に精通しているのであれば、上記の権限は、この Horizon オンプレミスのドキュメント トピックに記載されている、Horizon オンプレミス製品のセカンダリ認証情報アカウントに必要なセットと同じであることがわかります。
  • 一般的に、ドメイン バインド アカウントには、Microsoft Active Directory デプロイで認証されたユーザーに通常付与される、デフォルトの特別な設定は不要の読み取りアクセス関連の権限が付与されている必要があります。ただし、組織の Active Directory 管理者が通常ユーザーの読み取りアクセス権に関連する権限をロックダウンすることを選択した場合は、それらの Active Directory 管理者に、Horizon Cloud に使用するドメイン バインド アカウントの認証済みユーザーの標準デフォルト設定を保持するように要求する必要があります。

また、アカウントのパスワードを 無期限 に設定して、Horizon Cloud 環境にログインするために引き続きアクセスできるようにする必要があります。

重要: このアカウントに求められる主な特性については、 Horizon Cloud の運用に必要なサービス アカウントをご覧ください。

ドメイン参加アカウント

  • システムが Sysprep 操作を実行し、コンピュータをドメインに参加させるために使用できる Active Directory ドメイン参加アカウント。通常は新規アカウントです(「ドメイン参加ユーザー アカウント」)。
  • このアカウントには、sAMAccountName 属性が必須です。sAMAccountName 属性は 20 文字以下にする必要があります。また、"/ \ [ ] : ; | = , + * ? < > の文字を含めることはできません。
  • アカウント パスワードを「無期限」に設定。
  • このアカウントには、次の Active Directory 権限が必要です:すべてのプロパティの読み取り、パスワードのリセット、コンピュータ オブジェクトの作成、コンピュータ オブジェクトの削除、およびすべてのプロパティの書き込み。
    注: ポッド マニフェスト 2474.0 の時点で、ドメイン参加アカウントに必要な権限は、2474 より前のマニフェストで使用されていた以前の権限セットから削減され、子孫のコンピュータ オブジェクトに対するすべてのプロパティの書き込みが含まれるようになりました。以前のマニフェストを実行しているポッドは、引き続き以前の権限セットが必要になります。詳細については、 Horizon Cloud の運用に必要なサービス アカウントを参照してください。
  • また、このアカウントには、ファームおよび VDI デスクトップ割り当てに使用するターゲット組織単位 (OU) のすべての子孫オブジェクトに対する「すべてのプロパティの書き込み」という Active Directory 権限が必要です。
  • 詳細および要件については、Horizon Cloud の運用に必要なサービス アカウントを参照。
注:
  • アカウントのユーザー名に空白を使用することは、現在サポートされていません。名前に空白が含まれている場合、そのアカウントに依存するシステム操作で予期しない結果が発生します。
  • Microsoft Active Directory では、新しい組織単位 (OU) を作成するときに、システムは、新しく作成された OU およびすべての子孫オブジェクトの [すべての子オブジェクトの削除] 権限に Deny を適用する Prevent Accidental Deletion 属性を自動的に設定する場合があります。その結果、ドメイン参加アカウントに [コンピュータ オブジェクトの削除] 権限を明示的に割り当てた場合、新しく作成された OU の場合、Active Directory は、明示的に割り当てられた [コンピュータ オブジェクトの削除] 権限に上書きを適用した可能性があります。[誤削除の防止] フラグをオフにしても、Active Directory が [すべての子オブジェクトの削除] 権限に適用した Deny が自動的にオフにならない場合があるため、新しく追加された OU の場合、Horizon Cloud コンソールでドメイン参加アカウントを使用する前に、OU およびすべての 子 OU の [すべての子オブジェクトの削除] に対して設定した Deny 権限を確認して手動でクリアする必要がある場合があります。
  • マニフェスト 1600.0 以前は、このアカウントにはシステムのスーパー管理者ロールの権限が必要でした。テナント環境の Microsoft Azure に、1600.0 より古いマニフェストを実行している Horizon Cloud ポッドがある場合、ドメイン参加アカウントは説明されている Horizon Cloud 管理者グループに属している必要があります。システムは、このドメイン参加アカウントを、テナントの Microsoft Azure 内のすべての Horizon Cloud ポッドで使用します。テナントに 1600.0 より古いマニフェストの既存のポッドがある場合、ドメイン参加アカウントはこの要件を満たす必要があります。詳細については、Horizon Cloud の運用に必要なサービス アカウントを参照してください。
重要: このアカウントに求められる主な特性については、 Horizon Cloud の運用に必要なサービス アカウントをご覧ください。

補助ドメイン参加アカウント(オプション。上記と同じアカウントは使用できません)。

  • システムが Sysprep 操作を実行し、コンピュータをドメインに参加させるために使用できる Active Directory ドメイン参加アカウント。通常は新規アカウントです(「ドメイン参加ユーザー アカウント」)。
  • このアカウントには、sAMAccountName 属性が必須です。sAMAccountName 属性は 20 文字以下にする必要があります。また、"/ \ [ ] : ; | = , + * ? < > の文字を含めることはできません。
  • アカウント パスワードを「無期限」に設定。
  • このアカウントには、次の Active Directory 権限が必要です:すべてのプロパティの読み取り、パスワードのリセット、コンピュータ オブジェクトの作成、コンピュータ オブジェクトの削除、およびすべてのプロパティの書き込み。
    注: ポッド マニフェスト 2474.0 の時点で、ドメイン参加アカウントに必要な権限は、2474 より前のマニフェストで使用されていた以前の権限セットから削減され、子孫のコンピュータ オブジェクトに対するすべてのプロパティの書き込みが含まれるようになりました。以前のマニフェストを実行しているポッドは、引き続き以前の権限セットが必要になります。詳細については、 Horizon Cloud の運用に必要なサービス アカウントを参照してください。
  • また、このアカウントには、ファームおよび VDI 仮想デスクトップに使用するターゲット組織単位 (OU) のすべての子孫オブジェクトに対する「すべてのプロパティの書き込み」という Active Directory 権限が必要です。
  • 詳細および要件については、Horizon Cloud の運用に必要なサービス アカウントを参照。
注:
  • アカウントのユーザー名に空白を使用することは、現在サポートされていません。名前に空白が含まれている場合、そのアカウントに依存するシステム操作で予期しない結果が発生します。
  • Microsoft Active Directory では、新しい組織単位 (OU) を作成するときに、システムは、新しく作成された OU およびすべての子孫オブジェクトの [すべての子オブジェクトの削除] 権限に Deny を適用する Prevent Accidental Deletion 属性を自動的に設定する場合があります。その結果、ドメイン参加アカウントに [コンピュータ オブジェクトの削除] 権限を明示的に割り当てた場合、新しく作成された OU の場合、Active Directory は、明示的に割り当てられた [コンピュータ オブジェクトの削除] 権限に上書きを適用した可能性があります。[誤削除の防止] フラグをオフにしても、Active Directory が [すべての子オブジェクトの削除] 権限に適用した Deny が自動的にオフにならない場合があるため、新しく追加された OU の場合、Horizon Cloud コンソールでドメイン参加アカウントを使用する前に、OU およびすべての 子 OU の [すべての子オブジェクトの削除] に対して設定した Deny 権限を確認して手動でクリアする必要がある場合があります。
  • マニフェスト 1600.0 以前は、このアカウントにはシステムのスーパー管理者ロールの権限が必要でした。テナント環境の Microsoft Azure に、1600.0 より古いマニフェストを実行している Horizon Cloud ポッドがある場合、ドメイン参加アカウントは説明されている Horizon Cloud 管理者グループに属している必要があります。システムは、このドメイン参加アカウントを、テナントの Microsoft Azure 内のすべての Horizon Cloud ポッドで使用します。テナントに 1600.0 より古いマニフェストの既存のポッドがある場合、ドメイン参加アカウントはこの要件を満たす必要があります。詳細については、Horizon Cloud の運用に必要なサービス アカウントを参照してください。
Active Directory グループ
  • Horizon Cloud 管理者 — Horizon Cloud 管理者の Active Directory セキュリティ グループ。Horizon Cloud 管理者ユーザーが含まれます。このグループには、Horizon Cloudスーパー管理者ロールが付与されます。
  • Horizon Cloud ユーザー — Horizon Cloud の仮想デスクトップおよび RDS セッションベースのデスクトップと公開済みアプリケーションにアクセスするユーザーの Active Directory セキュリティ グループ。
注: テナント環境の Microsoft Azure に 1600.0 より古いマニフェストを実行している Horizon Cloud ポッドがある場合、ドメイン参加アカウントと補助ドメイン参加アカウントも Horizon Cloud 管理者グループ、または Horizon Cloudスーパー管理者ロールが付与された Active Directory グループに含まれている必要があります。
仮想デスクトップおよび RDS セッションベースのデスクトップまたは公開アプリケーション、またはその両方の Active Directory 組織単位 (OU)。
注: Microsoft Active Directory では、新しい組織単位 (OU) を作成するときに、システムは、新しく作成された OU およびすべての子孫オブジェクトの [すべての子オブジェクトの削除] 権限に Deny を適用する Prevent Accidental Deletion 属性を自動的に設定する場合があります。その結果、ドメイン参加アカウントに [コンピュータ オブジェクトの削除] 権限を明示的に割り当てた場合、新しく作成された OU の場合、Active Directory は、明示的に割り当てられた [コンピュータ オブジェクトの削除] 権限に上書きを適用した可能性があります。 [誤削除の防止] フラグをオフにしても、Active Directory が [すべての子オブジェクトの削除] 権限に適用した Deny が自動的にオフにならない場合があるため、新しく追加された OU の場合、 Horizon Cloud コンソールでドメイン参加アカウントを使用する前に、OU およびすべての 子 OU の [すべての子オブジェクトの削除] に対して設定した Deny 権限を確認して手動でクリアする必要がある場合があります。

Universal Broker の要件

2020 年 7 月リリース以降、Horizon Cloud テナント環境がその日付から開始された新しいアカウントであり、最初のポッドを Microsoft Azure にデプロイした場合は、環境の仲介方法として Universal Broker を使用することを選択できます。ご使用の環境に Universal Broker を構成することを選択した場合は、次の項目が必要になります。Universal Broker の構成 を参照してください。

ポッドに対して使用している VNet 上のアウトバウンド インターネット アクセスでは、特定のポートとプロトコルを使用して特定の DNS 名を解決し、その名前にアクセスする必要があります。これは Universal Broker の構成および継続的な運用のために必要です。DNS 名とポートのリストについては、Microsoft の Horizon Cloud ポッドおよび関連サービス機能の DNS 要件2019 年 9 月のリリースのマニフェスト以降の Horizon Cloud ポッドのポートとプロトコルの要件 を参照してください。
オプション : Universal Broker でポッドに 2 要素認証を使用する場合は、RADIUS 認証サーバへの 2 要素認証用にポッドのゲートウェイを構成します。
  • 認証サーバの名前を解決するための Unified Access Gateway の DNS アドレス
  • 認証サーバへのネットワーク ルーティングを解決する Unified Access Gateway のルート
オプション : エンドユーザーが Universal Broker サービスおよびその FQDN に基づく証明書にアクセスするために使用するカスタムの FQDN(オプション)

DNS レコードの要件

ポッドが Microsoft Azure クラウドにデプロイされた後、ビジネス状況および使用する機能に応じて、完全修飾ドメイン名 (FQDN) をポッド関連の IP アドレスにマッピングするレコードを DNS サーバに設定することが重要です。

注: 外部と内部のゲートウェイ構成で同じ FQDN を使用しているポッドをデプロイした場合は、ポッドのデプロイ後、スプリット DNS(スプリット Domain Name System)を構成して、エンド ユーザー クライアントの DNS クエリのオリジン ネットワークに応じて、外部ゲートウェイまたは内部ゲートウェイのいずれかにゲートウェイ アドレスを解決します。
カスタムの FQDN を使用して Universal Broker を構成した場合は、Universal Broker 構成の VMware 提供の仲介 FQDN にカスタムの FQDN をマッピングするパブリック DNS レコードを作成します。Universal Broker の構成 を参照してください。
外部ゲートウェイ構成の FQDN と一致する、外部エンドユーザー アクセス用にパブリック DNS レコードが作成されていること。これが、ポッドの外部 Unified Access Gateway 構成の Microsoft Azure 外部ロード バランサを参照していること(デプロイされたポッドにこの構成がある場合に必要)。詳細については、Azure クラウド サービスのカスタム ドメイン名の構成を参照。
内部ゲートウェイ構成の FQDN と一致する、内部エンドユーザー アクセス用に内部 DNS レコードが作成されていること。これが、ポッドの内部 Unified Access Gateway 構成の Microsoft Azure 内部ロード バランサを参照していること(デプロイされたポッドにこの構成がある場合に必要)。
展開にシングルポッド仲介を選択する際に内部 DNS レコードが作成されると、展開を VMware Workspace ONE Access に統合することになります。このシナリオでは、この内部 DNS レコードがポッドへの VMware Workspace ONE Access 接続をサポートしています。これにより、VMware Workspace ONE Access Connector はポッドからのユーザー割り当てに関する情報を同期します。この内部 DNS レコードは、ポッド自体にアップロードする証明書の FQDN と一致し、ポッド マネージャの Microsoft Azure 内部ロード バランサを参照します。シングルポッド仲介用に構成された環境内のポッドで VMware Workspace ONE Access を使用する場合に必要です。
注: この内部 DNS レコードと、レコードに一致し、ポッド自体にアップロードされる証明書は、内部エンドユーザーにポッドの内部 Unified Access Gateway 構成に接続するのではなく、ポッドに直接接続するように指示する、一般的ではない、まれなユースケースでも使用されます。このような直接接続は珍しいユースケースです。通常は、内部 Unified Access Gateway が代わりに使用されます。
ポッドへの VMware Workspace ONE Access 接続用に作成されている上記の内部 DNS レコードに一致する証明書チェーン(CA 証明書、SSL 証明書、SSL キー ファイル)。詳細については、直接接続のために SSL 証明書を Horizon Cloud ポッドにアップロードするを参照。(内部エンドユーザーがポッドに直接接続するという一般的ではないユースケースを使用している場合にも必要です。直接接続はまれに使用されますが、通常は使用されません。通常は、内部 Unified Access Gateway が代わりに使用されます。)

Horizon Cloud ゴールド イメージ、デスクトップ、およびファーム

Microsoft Azure サブスクリプションは、デプロイされたポッドからプロビジョニングするゴールド イメージ、VDI デスクトップ、および RDS ファームの種類に応じて、次の要件を満たす必要があります。

注: アカウントで App Volumes の機能を使用できるようになっていて、コンソールの [ キャプチャ ] アクションを使用して App Volumes アプリケーションをインベントリに追加すると、システムは、2 台のデスクトップ仮想マシンのデスクトップ割り当てを生成して、キャプチャ ワークフローをサポートします。キャパシティは、キャプチャ ワークフローの実行中に、これらのデスクトップの作成にも対応する必要があります。環境のアプリケーションのキャプチャが完了したら、そのデスクトップ割り当てを削除できます。
ゴールド イメージの基本 — サポートされている Microsoft Azure 仮想マシン構成のいずれか。
  • Standard_D3_v2、Standard_D4_v3
  • Standard_D2_v2、Standard_D2_v3
  • Standard_NV6
注: 自動化された [Marketplace からの仮想マシンのインポート] ウィザードを使用してベース仮想マシンを作成する場合、システムはデフォルトで上記の仮想マシン サイズの 1 つを自動的に使用します。システムのデフォルト選択は、ポッドの Microsoft Azure リージョンで使用可能なサイズの確認などの内部アルゴリズムに基づきます。ウィザードを使用して GPU 対応の仮想マシンを作成する場合、デフォルトで Standard_NV6 サイズの仮想マシンが作成されます。ウィザードを使用してサーバ OS ベースの仮想マシンを作成する場合、Standard_D2_v2 または Standard_D2_v3 のいずれかの仮想マシンが作成されます。クライアント OS ベースの仮想マシンまたは Windows 10 のマルチセッション仮想マシンを作成する場合、Standard_D3_v2 または Standard_D4_v3 のいずれかの仮想マシンが作成されます。
VDI デスクトップ割り当てのデスクトップ仮想マシンのモデル選択 — Microsoft Azure リージョンで使用可能な Microsoft Azure 仮想マシン構成のいずれか(Horizon Cloud デスクトップ操作と互換性のないものを除く)。

本番環境の場合、VMware スケール テストでは、最低 2 つの CPU を持つモデルを使用することをお勧めします。

ファームの RDSH 仮想マシンのモデル選択 — Microsoft Azure リージョンで使用可能な Microsoft Azure 仮想マシン構成のいずれか(Horizon Cloud RDS ファーム操作と互換性のないものを除く)。

この要件は、Microsoft Windows 10 エンタープライズ マルチセッションを実行している仮想マシンが Horizon Cloud で使用されている場合にも適用されます。Microsoft Azure Windows Virtual Desktop ドキュメントの「Microsoft Windows 10 Enterprise マルチセッション FAQ」で説明されているように、Microsoft Windows 10 Enterprise マルチセッションは、以前は Microsoft Windows Server オペレーティング システムのみが提供できた複数の同時対話型セッションを許可する Remote Desktop Session Host (RDSH) タイプです。RDS サーバに適用される Horizon Cloud ワークフローは、Microsoft Windows 10 Enterprise マルチセッションに適用できます。

本番環境の場合、VMware スケール テストでは、最低 2 つの CPU を持つモデルを使用することをお勧めします。

Microsoft Windows オペレーティング システムのライセンス

項目は、インポートされた仮想マシン、ゴールド イメージ、RDSH 対応のファーム仮想マシン、および仮想デスクトップ仮想マシンの Microsoft Windows オペレーティング システムに関連します。Horizon Cloud がサポートする Microsoft Windows オペレーティング システムのリストについては、VMware ナレッジベースの記事 KB78170 および VMware ナレッジベースの記事 KB70965 を参照してください。

Horizon Cloud は、Horizon Cloud ワークフローを使用する過程で使用する Microsoft Windows オペレーティング システムの使用に必要なゲスト OS ライセンスを提供しません。ユーザーは、Horizon Cloud テナント環境で使用するために選択した Windows ベースのデスクトップ仮想マシンおよび RDSH 仮想マシンの作成、ワークフローの実行、および操作を行う資格が付与される有効で適格な Microsoft ライセンスを所有している責任があります。必要なライセンスは、使用目的によって異なります。

ヒント: Windows 10 Enterprise マルチセッションおよび Windows 7 Enterprise の Microsoft Windows Virtual Desktop ライセンスの詳細については、Microsoft Azure のドキュメント トピック「 Windows Virtual Desktop の価格設定」を参照してください。
次のいずれかのタイプのライセンス:Microsoft Windows 7 Enterprise、Microsoft Windows 10(クライアント タイプ)
Microsoft Windows 10 Enterprise マルチセッションのライセンス
次のいずれかのタイプのライセンス:Microsoft Windows Server 2012 R2、Microsoft Windows 2016、Microsoft Server 2019
Microsoft Windows RDS ライセンス サーバ — 高可用性のために冗長ライセンス サーバを推奨
Microsoft RDS ユーザーまたはデバイス CAL(またはその両方)

Horizon インフラストラクチャの監視要件

Horizon Cloud テナントが Horizon インフラストラクチャの監視 機能を使用できるようになっている場合、Horizon Universal Console を使用して、選択したポッドでその機能を有効にできます。ポッドでこの機能を有効にすることを選択すると、システムはそのポッドが配置されているのと同じ Microsoft Azure サブスクリプションに仮想アプライアンスを自動的に構築し、そのアプライアンスを構成してインフラストラクチャ データを収集します。この監視機能を有効にするには、テナントを VMware Cloud Services にオンボーディングする必要があります。Horizon Cloud テナントを VMware Cloud Services にオンボーディングするおよび Horizon インフラストラクチャの監視と Horizon Cloud 環境のポッドを参照してください。

テナントを VMware Cloud Services にオンボーディングします。
Horizon インフラストラクチャの監視 機能を有効にするポッドごとに、ポッドの Microsoft Azure サブスクリプションは次の追加要件を満たす必要があります。
  • Horizon Edge 仮想アプライアンス - 1 x Standard_D4_v3

リファレンス アーキテクチャ

以下のアーキテクチャ ダイアグラムを参照してください。

図 1. 高可用性が有効にされ、外部および内部ゲートウェイ構成の両方で構成されたポッドの Horizon Cloud ポッド アーキテクチャの図、ポッドと同じ VNet にデプロイされた外部ゲートウェイ、外部ゲートウェイ仮想マシンに 3 つの NIC、内部ゲートウェイ仮想マシンに 2 つの NIC、および外部ゲートウェイのロード バランサに対して有効なパブリック IP アドレス

高可用性が有効で、両方のタイプの Unified Access Gateway 構成が設定され、外部ゲートウェイがポッドと同じ VNet にあるポッドのリソース グループ、仮想マシン、およびサブネットのアーキテクチャ図。

図 2. 外部ゲートウェイが独自の VNet にデプロイされ、3 つの NIC を備えたポッドの VNet から切り離され、ポッド デプロイヤによって作成されたリソース グループにデプロイされたときの、外部ゲートウェイのアーキテクチャ要素の図

外部ゲートウェイが、ポッドの VNet とは別の独自の VNet、およびポッド デプロイヤによって作成されたリソース グループにデプロイされる場合の外部ゲートウェイのアーキテクチャ要素の図

リソース

詳細については、以下のリソースを参照してください。