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

このドキュメント トピックのセクションは次のとおりです。

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

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

ポッドのデプロイ自体の要件
ポッドのデプロイ後の本番環境の要件
重要: ポッド デプロイ ウィザードを起動してポッドのデプロイを開始する前に、以下の要件に加えて、次の重要な点に注意する必要があります。
  • 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 サブスクリプションに作成します。これには、これらのデプロイ プロセスをオーケストレーションする一時ジャンプ ボックス用に作成される初期リソース グループが含まれます。デプロイ時、またはポッドの更新時やポッドへのゲートウェイ構成の追加時に、何らかのタイプのリソース タグ要件がある 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 基本イメージ、デスクトップ、およびファームのセクションを参照してください。

外部 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 によって要求される操作を参照。
必要なリソース プロバイダが各 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 によって作成することもできます。手動で作成されたサブネットを使用する場合、他のリソースは接続できません。
注: このリリースのマニフェスト レベルで新たにデプロイされたポッドの場合、四半期 2020 年 7 月リリース以降、ポッドがデプロイされた後に、ポッドを編集して、ファームおよびデスクトップ割り当ての仮想マシンで使用するための追加のテナント サブネットを追加できます。追加のテナント サブネットは、ポッドがデプロイされているのと同じ 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 Azure での Horizon Cloud ポッドの DNS の要件2019 年 9 月のリリースのマニフェスト以降の Horizon Cloud ポッドのポートとプロトコルの要件 を参照してください。
プロキシ サーバ情報(VNet での外部へのインターネット アクセスに必要な場合)。Horizon Cloud 環境のデプロイおよび継続的な運用で使用されます(オプション)。
Microsoft Azure VPN/ExpressRoute が構成済みであること(オプション)。
外部および内部ユーザー アクセス用の FQDN(Unified Access Gateway を使用してポッドをデプロイする場合に必要)。
注: 2020 年 7 月リリース以降に新たにデプロイされたポッドについては、ポッドに両方のタイプのゲートウェイがある場合、ポッドの外部ゲートウェイと内部ゲートウェイの構成は同じ FQDN を指定する必要があります。両方のゲートウェイで同じ FQDN を使用するため、ポッドのデプロイ後、スプリット DNS(スプリット Domain Name System)を構成して、エンド ユーザー クライアントの DNS クエリのオリジン ネットワークに応じて、外部ゲートウェイまたは内部ゲートウェイのいずれかにゲートウェイ アドレスを解決します。
FQDN に一致する PEM 形式の Unified Access Gateway の証明書(Unified Access Gateway を使用してポッドをデプロイする場合に必要)。
注:
  • 2020 年 7 月リリース以降に新たにデプロイされたポッドの場合、ポッドの外部ゲートウェイと内部ゲートウェイの構成では同じ FQDN を指定する必要があります。証明書は FQDN と一致する必要があるため、ポッドに両方のタイプのゲートウェイがある場合、両方のゲートウェイ構成で同じ証明書が使用されます。
  • この目的で提供する 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 のルート

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

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

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

上記の項目は、ポッドのデプロイ ウィザードを開始する前に必要です。上記の項目が整っていることを確認したら、最初の Horizon Cloud クラウドに接続されたポッドがポッド デプロイヤを使用してポッドを Microsoft Azure にデプロイする場合の高度なワークフロー のポッド デプロイの手順 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 を使用して同じ顧客アカウントにクラウド接続されるすべてのオンプレミスまたは AWS 内の Horizon ポッドにも適用されます。Horizon Cloud での VMware Horizon ポッド - 要件チェックリスト - 2020 年 7 月のサービスリリース以降、ポッドの接続に適した更新では、このような Horizon ポッドのチェックリストを確認できます。
ドメイン バインド アカウント
  • 次の権限を持つ Active Directory ドメイン バインド アカウント(読み取りアクセス権限を持つ標準ユーザー)。
    • コンテンツの一覧表示
    • すべてのプロパティの読み取り
    • アクセス許可の読み取り
    • tokenGroupsGlobalAndUniversal の読み取りすべてのプロパティの読み取り により暗黙に含まれる)
    注:
    • VMware Horizon オンプレミス製品に精通しているのであれば、上記の権限は、この Horizon オンプレミスのドキュメント トピックに記載されている、Horizon オンプレミス製品のセカンダリ認証情報アカウントに必要なセットと同じであることがわかります。
    • 一般的に、ドメイン バインド アカウントには、Microsoft Active Directory デプロイで認証されたユーザーに通常付与される、デフォルトの特別な設定は不要の読み取りアクセス関連の権限が付与されている必要があります。ただし、組織の Active Directory 管理者が通常ユーザーの読み取りアクセス権に関連する権限をロックダウンすることを選択した場合は、それらの Active Directory 管理者に、Horizon Cloud に使用するドメイン バインド アカウントの認証済みユーザーの標準デフォルト設定を保持するように要求する必要があります。

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

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

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

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

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

ドメイン参加アカウント
  • システムが Sysprep 操作を実行し、コンピュータをドメインに参加させるために使用できる Active Directory ドメイン参加アカウント。通常は新規アカウントです(「ドメイン参加ユーザー アカウント」)。
  • Horizon Cloud 管理者グループのメンバーである。
  • アカウント パスワードを「無期限」に設定。
  • このアカウントには、次の Active Directory 権限が必要です:コンテンツの一覧表示、すべてのプロパティの読み取り、アクセス権の読み取り、パスワードのリセット、コンピュータ オブジェクトの作成、およびコンピュータ オブジェクトの削除。
  • また、このアカウントには、ファームおよび 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 権限を確認して手動でクリアする必要がある場合があります。
補助ドメイン参加アカウント(オプション。上記と同じアカウントは使用できません)。
  • システムが Sysprep 操作を実行し、コンピュータをドメインに参加させるために使用できる Active Directory ドメイン参加アカウント。通常は新規アカウントです(「ドメイン参加ユーザー アカウント」)。
  • Horizon Cloud 管理者グループのメンバーである。
  • アカウント パスワードを「無期限」に設定。
  • このアカウントには、次の Active Directory 権限が必要です:コンテンツの一覧表示、すべてのプロパティの読み取り、アクセス権の読み取り、パスワードのリセット、コンピュータ オブジェクトの作成、およびコンピュータ オブジェクトの削除。
  • また、このアカウントには、ファームおよび 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 権限を確認して手動でクリアする必要がある場合があります。
Active Directory グループ
  • Horizon Cloud 管理者 — Horizon Cloud 管理者の Active Directory セキュリティ グループ。Horizon Cloud 管理ユーザーとドメイン参加アカウントが含まれています。このグループは、Horizon Cloud の「スーパー管理者」ロールに追加されます。
  • Horizon Cloud ユーザー — Horizon Cloud の仮想デスクトップおよび RDS セッションベースのデスクトップと公開済みアプリケーションにアクセスするユーザーの 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 Azure での 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 サーバに設定することが重要です。

注: 2020 年 7 月リリース以降に新たにデプロイされたポッドについては、ポッドに両方のタイプのゲートウェイがある場合、ポッドの外部ゲートウェイと内部ゲートウェイの構成は同じ FQDN を指定する必要があります。両方のゲートウェイで同じ 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 内部ロード バランサを参照していること(デプロイされたポッドにこの構成がある場合に必要)。
VMware Workspace ONE Access がポッドに接続するための内部 DNS レコードが作成されていること。これがポッド自身にアップロードする証明書と一致し、ポッド マネージャの 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(またはその両方)

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

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

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

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

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

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

リソース

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