horizon cloud デプロイガイ - docs.vmware.com · 最初のポッドのデプロイが...

Horizon Cloud デプロイガイド

2019 年 12 月 12 日以降のサービスレベル向け

VMware Horizon Cloud Service

最新の技術ドキュメントは、 VMware の Web サイト（https://docs.vmware.com/jp/）でご確認いただけます。このドキュメ

ントに関するご意見およびご感想は、[email protected] までお送りください。

VMware, Inc.3401 Hillview Ave.Palo Alto, CA 94304www.vmware.com

ヴイエムウェア株式会社

105-0013　東京都港区浜松町 1-30-5浜松町スクエア 13Fwww.vmware.com/jp

Copyright ©

2017-2019 VMware, Inc. All rights reserved. 著作権および商標情報。


VMware, Inc. 2

https://docs.vmware.com/jp/

mailto:[email protected]

http://pubs.vmware.com/copyright-trademark.html

目次

Horizon Cloud for Microsoft Azure、Horizon 7 オンプレミス、および Horizon 7 on VMware Cloud on AWS へのオンボーディング 4

1 Horizon Cloud の紹介およびポッドをクラウド接続するためのオンボーディングの概要 13VMware Horizon Cloud Service on Microsoft Azure 要件チェックリスト - 2019 年 12 月のサービスリリース

で使用 15

VMware Horizon 7 with Horizon Cloud の要件チェックリスト - 2019 年 12 月のサービスリリースで使用

22

2 Horizon Cloud テナント環境への最初のクラウド接続されたポッドのオンボーディング 26最初のポッドデプロイでオンプレミスのキャパシティを選択した場合 28

Horizon Cloud テナント環境への最初のポッドとして、手動でデプロイされた既存の Horizon 7 ポッドをオン

ボーディングする場合のワークフローの概要 30

Horizon Cloud Service を既存の Horizon 7 ポッドと接続して、Horizon サブスクリプションライセンスまた

はクラウドホスト型サービス、あるいはその両方を使用する 35

Horizon 7 Cloud Connector の既知の考慮事項 47

最初のポッドデプロイに対して Microsoft Azure クラウドキャパシティを選択する場合 57

クラウド接続された最初のポッドが Microsoft Azure へのデプロイから作成された場合の概要レベルのワーク

フロー 63

3 最初のポッドのデプロイが完了し、Horizon Cloud に接続されました 182

4 Tech Preview - Microsoft Windows 仮想デスクトップを拡張する VMware Horizon Cloud Service on Microsoft Azure 183

VMware, Inc. 3

Horizon Cloud for Microsoft Azure、Horizon 7 オンプレミス、および Horizon 7 on VMware Cloud on AWS へのオンボーディング

これらのドキュメントトピックは、[VMware Horizon Service へようこそ] E メールを受信し、最初のポッドをオン

ボーディングする準備ができたときに適用されます。このオンボーディングの一連のトピックでは、クラウドホスト

型サービスの使用資格を付与する Horizon ユニバーサルライセンスとサブスクリプションライセンスの関係、およ

びポッドを Horizon Cloud に初めてオンボーディングするプロセスの概要について説明します。この初めてのオン

ボーディングは、Horizon サブスクリプションライセンスを利用し、既存の Horizon 7 ポッドを関連するクラウド

ホスト型サービスにオンボーディングし、Microsoft Azure で新しいポッドを作成し、現在 VMware Horizon® Cloud Service™ がクラウド接続されたポッドに対して提供しているクラウドホスト型サービスのすべてを活用する

ための鍵となります。

既存の Horizon 7 ポッドをクラウドにオンボーディングする場合、2 つの主要な使用事例を想定します。すなわち、

そのポッドのサブスクリプションライセンスをアクティブ化すること、そして Horizon Cloud がそのタイプのポッ

ドに提供するクラウドホスト型サービスを使用できるようにすることです。ポッドを Microsoft Azure にオンボー

ディングするには、Horizon Cloud 管理コンソールを使用してそのポッドを Microsoft Azure クラウドサブスクリ

プションにデプロイします。

ヒント: すでに少なくとも 1 つのクラウド接続されたポッドがある場合は、最初のオンボーディングを実行した後の

後続のポッドのオンボーディングに関する情報について、このオンボーディングのトピックセットの代わりに、コン

パニオンの管理のトピックセットを使用してください。

n Horizon ユニバーサルライセンスを使用した最初のポッドのオンボーディング、そのライセンスに関連付けられ

た My VMware アカウント、Horizon Cloud テナント、「ようこそ」E メールの関係

n オンボーディング要件のチェックリスト

n これらのオンボーディングトピックのリビジョン履歴

n 対象読者

n スクリーンショットについて

n Horizon Cloud コミュニティ

n VMware サポートへのお問い合わせ

VMware, Inc. 4

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-571F4415-515C-4BED-B02E-8ED2BBD8EF1C.html

Horizon ユニバーサルライセンスを使用した最初のポッドのオンボ

ーディング、そのライセンスに関連付けられた My VMware アカウン

ト、Horizon Cloud テナント、「ようこそ」E メールの関係

概要レベルでは、これらの要素をつなぐ点は次のようになります。

1 サブスクリプションライセンスを取得します。現在、取得する公式のサブスクリプションライセンスは

Horizon ユニバーサルライセンスです。ライセンスは、ライセンス要求で使用される特定の My VMware アカ

ウントに関連付けられます。

2 クラウド制御プレーンで、VMware は新しい Horizon Cloud テナントアカウントと環境をセットアップし、そ

れを手順 1 で Horizon ユニバーサルライセンスが関連付けられた My VMware アカウントに関連付けます。

Horizon Cloud は、マルチテナントクラウド環境です。

3 VMware は、手順 1 で My VMware アカウントに構成され、ライセンスが関連付けられているメールアドレス

に、[VMware Horizon Service へようこそ] E メールを送信します。この「ようこそ」E メールの例については、

次のスクリーンショットを参照してください。


VMware, Inc. 5

https://www.vmware.com/products/horizon-universal-license.html

4 E メールを受信したら、記載されている情報を読み、「はじめに」セクションのハイパーテキストリンクを使用

して URL を開き、テナント環境ポータル（Horizon Cloud 管理コンソール）、Horizon 7 Cloud Connector ソフトウェアのダウンロード場所、およびオンラインドキュメントなど、主要な目的の場所に移動します。

重要： E メールを最初に受信した後、最初の My VMware アカウントを使用してテナント環境ポータルにログイン

し、ポッドのオンボーディングおよびオンボーディングされたポッドの管理を別のユーザーに許可するための My VMware アカウントを追加することをお勧めします。最初のポッドをオンボーディングする前にそれらのユーザー

を追加すると、元のユーザーが社内で対応できなくなったり、チームにログイン認証情報を知っているユーザーがい

なくなったりする状況でテナントアカウントへのアクセスの遅延を回避することができます。ポッドをオンボーデ

ィングしたり、Horizon 7 Cloud Connector の再構成などの関連ワークフローを実行するには、テナントアカウン

トへのアクセスが必要です。メインのユーザーが組織を離れたためにテナントアカウントへのアクセスが中断され

た場合、VMware へのサポートリクエストを開いて、テナントアカウントの関連付けられた My VMware アカウン

トを更新する必要があります。これにより、オンボーディングおよび管理ポータルへのログインで遅延が発生する場

合があります。

テナントアカウントにログインする別の My VMware アカウントを追加する手順については、Horizon Cloud テナ

ント環境にログインする管理者の追加を参照してください。

ライセンスの取得まずライセンスを取得する必要があります。ライセンスは、VMware が Horizon Cloud テナントアカウントと環境を生成するポイントです。

クラウド制御プレーンの新

しい Horizon Cloud テナン

トアカウント

Horizon Cloud テナントアカウントは、既存の Horizon 7 ポッドでサブスクリプ

ションライセンスを使用することが唯一のユースケースで、クラウドホスト型サー

ビスをポッドで使用することを想定していない場合でも重要です。このテナント

アカウントが重要である理由は、同じテナントアカウントが以下の両方で使用され

るためです。

n Horizon 7 Cloud Connector のオンボードおよび管理ポータルへのログイ

ン。Horizon 7 Cloud Connector ポータルは、Horizon 7 ポッドをクラウド

にオンボーディングして、サブスクリプションライセンスを使用するため、お

よびクラウドホスト型サービスを有効にするために使用されます。Horizon 7 ポッドの最初のオンボーディングが完了したら、いつでも Horizon 7 Cloud Connector ポータルにログインして、コネクタ自体の機能を管理できます。

n Horizon Cloud 管理コンソールという名前の Horizon Cloud テナント環境ポ

ータルへのログイン。Horizon Cloud テナント環境ポータルを使用して管理

者を追加し、ライセンスを取得した最初の My VMware アカウントに加えて、

それらの管理者も Horizon 7 Cloud Connector のオンボーディングおよび管

理ポータルを使用できるようにします。このテナント環境ポータルは、クラウ

ド監視サービスの監視ダッシュボードとレポート、および Microsoft Azure にデプロイするためのポッドデプロイウィザードなどのクラウドホスト型サー

ビスへのアクセスにも使用されます。このポータルは、Horizon Cloud 管理コ

ンソールと呼ばれます。


VMware, Inc. 6

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-4D46E8D7-2AE4-4DDB-8389-59DE1AF55D84.html


テナントアカウントと、ラ

イセンスに関連付けられた

My VMware アカウントと

の関係

最初に Horizon ユニバーサルライセンスを取得するには、My VMware アカウン

トを使用する必要があります。その結果、My VMware アカウントは、新しく作成

された Horizon Cloud テナントアカウントと環境に登録された最初のアカウント

となり、Horizon Cloud テナントアカウントへのログイン認証情報に使用されます

（上記の両方のポータルで使用）。テナントアカウントが作成されると、[VMware Horizon Service へようこそ] E メールが、その My VMware アカウントで構成され

ている特定のメールアドレスに送信されます。次のスクリーンショットは、「よう

こそ」E メールの例です。自分または組織内の誰かが、サブスクリプションライセ

ンスの購入で使用した My VMware アカウントに関連付けられているメールアカ

ウントから「ようこそ」E メールを取得できることを確認する必要があります。そ

の E メールに記載されたリンクを使用して Horizon 7 Cloud Connector のダウン

ロードに移動したり、Horizon Cloud のテナントポータルを開いたりすることがで

きます。

次のスクリーンショットは「ようこそ」E メールの例で、My VMware アカウント

が参照されている場所を示しています。


VMware, Inc. 7

https://my.vmware.com


新しい Horizon Cloud テナ

ント環境とそのポータル

VMware から「ようこそ」E メールを受け取ると、クラウド接続されたポッドの数

がゼロの場合でも、関連付けられた My VMware アカウントは、新しく作成された

Horizon Cloud テナント環境にログインできます。ただし、この最初の時点で、テ

ナント環境ポータルは、単一の初期画面とその画面内のクラウドホスト型ワークフ

ローアクションの小さなサブセットへのアクセスを提供します。

次のスクリーンショットは、テナントアカウントが最初に作成された時点のポータ

ルを示しています。次のリストは、最初のポッドをオンボーディングする前にその

画面で実行できる主要なアクションについて説明します。


VMware, Inc. 8

ヒント: そのポータル画面の [全般的なセットアップ] バーをクリックして、次の 2 つの主要なアクションを確認します。

n [オンプレミス] の行でオンプレミスの Horizon 7 ポッドをオンボーディング

する方法を学習する。

n [クラウドのキャパシティを追加] 行の [追加] ボタンから、VMware Cloud on AWS の SDDC キャパシティに Horizon 7 ポッドをオンボーディングする方

法を学習する。

n 同じ [クラウドのキャパシティを追加] 行の [追加] ボタンから、ポッドを

Microsoft Azure にデプロイする。

n Horizon 7 Cloud Connector のオンボーディングおよび管理ポータル、およ

び Horizon Cloud 管理コンソール（テナント環境へのポータル）にログインす

る機能を付与する管理者を追加する。テナントのセットアップに使用された


VMware, Inc. 9

My VMware アカウントは、デフォルトで事前入力されています。その結果、

その行には緑色のチェックマークが付けられていることがわかります。ただ

しこれは、テナント環境の作成時にテナントアカウントに関連付けられた最初

の My VMware アカウントが常に 1 つあるからのみです。

ヒント: ユーザーが会社や組織を離れる場合など、何らかの理由で非アクティ

ブになった最初の My VMware アカウントを使用してアクセスしたためにテ

ナント環境と Horizon 7 Cloud Connector オンボーディングの両方からロッ

クアウトされるのを防ぐため、ポッドを初めてオンボーディングする前でも、

[Horizon Service へようこそ] E メールを受信したらすぐに管理者を追加する

ことを推奨します。

n クラウド監視サービス (CMS) の有効化。CMS はデフォルトで有効になってい

るため、緑色のチェックマークが付いた行が表示されます。この時点で、ポッ

ドをオンボーディングする前でも、その機能をオフに切り替えることができま

す。

ヒント: 上記の 4 つのアクションのほかに、ポータルの他のアクションとワークフローにアクセスするには、オンボ

ーディングされたポッドがあり、そのポッドがオンラインで、クラウド管理プレーンと通信し、テナント環境に Active Directory ドメインが登録されている必要があります。ポータルは、Active Directory ドメイン登録ワークフローが

完了するまで、他の管理アクションへのアクセスをブロックします。このワークフローの詳細については、Horizon Cloud 環境での最初の Active Directory ドメイン登録の実行を参照してください。

オンボーディング要件のチェックリスト

このオンボーディングドキュメントセットで説明されている手順を開始する前に、最初のポッドオンボーディング

が既存の Horizon 7 ポッドで Horizon サブスクリプションライセンスを利用する場合は、最初に VMware Horizon 7 with Horizon Cloud の要件チェックリスト - 2019 年 12 月のサービスリリースで使用をお読みください。この

トピックでは、Horizon 7 ポッドを Horizon Cloud に正常に接続するために必要なさまざまな前提条件について説

明します。Horizon 7 ポッドがクラウド接続された後、Horizon サブスクリプションライセンスがクラウドからポッ

ドにプッシュされ、テナントポータル内でそのポッドのクラウドホスト型サービスの有効化を開始できます。

最初のポッドオンボーディングが Microsoft Azure にある場合、このオンボーディングドキュメントセットで説明

されている手順を開始する前に、まず VMware Horizon Cloud Service on Microsoft Azure 要件チェックリスト - 2019 年 12 月のサービスリリースで使用をお読みください。このトピックでは、Microsoft Azure への最初のポッ

ドのデプロイを成功させるために必要なさまざまな前提条件について説明します。


VMware, Inc. 10

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-CBAA1736-2B10-4875-B19A-64520C63572D.html


これらのオンボーディングトピックのリビジョン履歴

このドキュメントのトピックセットは、製品がリリースされるたびに、あるいは必要に応じて更新されます。

次の表に更新履歴を示します。

リビジョン説明

2019 年 12 月 12 日

説明する機能が本番環境にデプロイされた最初のバージョン。

このドキュメントでは、最新のサービス機能について説明します。

n Microsoft Azure キャパシティを使用するポッドの場合、最新の機能は、ポッドのマニフェストバージョン 1750 以降に

対応します。

クラウド接続された Horizon 7 ポッドの場合、最新の機能はバージョン 1.5 以降の Horizon 7 Cloud Connector を使用

してクラウド制御プレーンに接続された、バージョン 7.11 以降の Horizon 7 コンポーネントに対応します。

対象読者

このドキュメントは、以下の領域の知識がある経験豊富なデータセンター管理者を対象としています。

n VMware Horizon

n VMware Horizon® 7 Cloud Connector™

n VMware Unified Access Gateway™

n VMware Workspace ONE® Access™

n 仮想化テクノロジー

n ネットワーク

n VMware Cloud™ on AWS (VMware Cloud)

n VMware Horizon® 7 on VMware Cloud™ on AWS

n Microsoft Azure

スクリーンショットについて

スクリーンショットは通常次のようになっています。

n 説明に対応するユーザーインターフェイスの部分のみが表示されます。完全なユーザーインターフェイスが表

示されるとは限りません。

n データの匿名性を維持するため、適宜ぼかしを入れています。

n PDF 形式では、幅が 6 インチを超えるスクリーンショットイメージは自動的にサイズ変更されます。その結果、

そのようなイメージは PDF 形式でぼやけて表示されることがあります。パラレルの HTML ページでは、このよ

うな幅の広いスクリーンショット画像をクリックして、画像をフルサイズで表示することができます。

注：一部のスクリーンショットは高解像度で取得しています。このため、PDF を 100% で表示したときに、読みに

くい場合があります。このような画像は、200% に拡大すると明瞭になり、読みやすくなります。


VMware, Inc. 11

Horizon Cloud コミュニティ

以下のコミュニティを使用して質問をしたり、その他のユーザーからの質問への回答を検索したり、役に立つ情報へ

のリンクにアクセスしたりすることができます。

n https://communities.vmware.com/community/vmtn/horizon-cloud-service にある VMware Horizon Cloud Service コミュニティ

n https://communities.vmware.com/community/vmtn/horizon-cloud-service/horizon-cloud-on-azure にある VMware Horizon Cloud on Microsoft Azure サブコミュニティ（VMware Horizon Cloud Service コミュニティのサブコミュニティ）。

VMware サポートへのお問い合わせ

Horizon Cloud 環境でなにかお困りの場合は、VMware サポートにお問い合わせください。

n My VMware® アカウントを使用して、オンラインで VMware サポートにサポートリクエストを送信するか、お

電話でお問い合わせください。

n KB 2144012 カスタマサポートのガイドラインから、発生した問題に応じてサポートを受ける方法が参照でき

ます。

n 管理コンソールにおいて、[ ] - [サポート] をクリックすると、KB 2144012 へのリンクも表示されます。

VMware の技術ドキュメントの用語集

VMware の技術ドキュメントには、専門的な用語などを集約した用語集があります。VMware の技術ドキュメント

で使用されている用語の定義については、http://www.vmware.com/support/pubs をご覧ください。


VMware, Inc. 12

https://communities.vmware.com/community/vmtn/horizon-cloud-service

https://communities.vmware.com/community/vmtn/horizon-cloud-service/horizon-cloud-on-azure

https://kb.vmware.com/s/article/2144012

http://www.vmware.com/support/pubs

Horizon Cloud の紹介およびポッドをクラウド接続するためのオンボーディングの概要

1Horizon Cloud テナント環境全体は、VMware がホストするクラウドサービスと、対応するキャパシティ環境にデ

プロイされ、クラウドサービスに接続されたポッドで構成されます。サポートされているキャパシティ環境にデプロ

イされた VMware ソフトウェアで構成されるポッドが適切にオンボーディングされると、クラウド接続されたポッ

ドになります。少なくとも 1 つのポッドがテナント環境に完全にオンボーディングされたら、追加のポッドをオンボ

ーディングしてクラウド接続されたポッドの集合を作ることができます。テナント環境のクラウド接続されたポッド

とサービスが提供する、サービスとしてのデスクトップ機能を使用するには、Horizon Cloud 管理コンソールとして

知られるテナント環境のポータルにログインして使用します。

Horizon Cloud VMware がクラウドでホストする制御プレーンであり、仮想デスクトップおよびア

プリケーションを一元的に編成および管理します。

クラウド接続されたポッドサポートされているキャパシティ環境にデプロイされ、クラウド制御プレーンにオ

ンボーディングされた VMware ソフトウェア。サポートされているキャパシティ

環境とは、Microsoft Azure クラウドや VMware Cloud™ on AWS、またはオンプ

レミスインフラストラクチャなどです。これらのキャパシティ環境には、それぞれ

特定のポッドタイプが用意されています。

n Microsoft Azure サブスクリプションのポッド

n Horizon 7 オンプレミスポッド

n VMware Cloud on AWS の Horizon 7

使用しているキャパシティ環境のタイプに応じて、Horizon Cloud 管理コンソールを使用して自動化されたポッドの

デプロイおよび Horizon Cloud への接続を行うことができます。一部のポッドタイプでは、ポッドを自動的にデプ

ロイおよび構成することはできませんが、それらのポッドを Horizon Cloud にオンボーディングすることはできま

す。

ポッドのオンボーディングの概念の概要については、「Horizon Cloud for Microsoft Azure、Horizon 7 オンプレミ

ス、および Horizon 7 on VMware Cloud on AWS へのオンボーディング」を参照してください。

VMware, Inc. 13

Horizon Cloud 制御プレーン

VMware は Horizon Cloud 制御プレーンをクラウドでホストします。このクラウドサービスを使用すると、ユーザ

ーの仮想デスクトップ、リモートデスクトップセッション、およびリモートアプリケーションの一元的な編成およ

び管理が可能になります。クラウドサービスはポッドも管理します。ポッドは、提供されたキャパシティ環境に物理

的に配置されます。クラウドサービスにログインすると、物理的な場所に関係なくすべてのポッドを表示し、それら

のポッド間で管理アクティビティを実行できます。

VMware は、責任を持ってサービスをホスティングし、SaaS（サービスとしてのソフトウェア）環境の機能を更新

および強化しています。

クラウドの制御プレーンでは、Horizon Cloud 管理コンソール（管理コンソール）という共通の管理ユーザーイン

ターフェイスもホストします。管理コンソールは、業界標準のブラウザで実行されます。管理コンソールは、ユーザ

ー割り当て、仮想デスクトップ、リモートデスクトップセッション、およびアプリケーションに関与する管理タス

クを IT 管理者のために 1 つにまとめた場所です。管理コンソールは、時間や場所に関係なくアクセスできるので、

非常に柔軟に利用できます。

重要：管理コンソールの表示は動的で、現在のサービスレベルで利用可能な機能が反映されます。ただし、ポッド

のソフトウェアの最新レベルにまだ更新されていないクラウド接続されたポッドがある場合は、管理コンソールには

最新ポッドのソフトウェアレベルに依存する機能は表示されません。また、特定のリリースでは、Horizon Cloud に個別にライセンスされた機能が含まれている場合があります。お持ちのライセンスにそのような機能の使用が含まれ

る場合のみ、管理コンソールにその機能に関連する要素が動的に反映されます。例については、Horizon Cloud 管理

ガイドの「Horizon Cloud 管理コンソールのツアー」を参照してください。

使用したい機能が管理コンソール内に見つからない場合は、VMware アカウントの担当者に問い合わせて、お持ちの

ライセンスにその機能を使用する資格が付与されているか確認してください。

Horizon Cloud に接続できるポッドのタイプ

この Horizon Cloud リリースで、以下のデプロイタイプが可能になります。

注：自動的なデプロイのために、Horizon Cloud にポッドを接続するか、または管理コンソールを使用するには、

ユーザーのアカウントが適切なライセンスを有している必要があります。詳細については、VMware アカウントの担

当者にお問い合わせください。


VMware, Inc. 14

表 1-1. ポッドのデプロイタイプ

デプロイタイプ説明

オンプレミスインフラストラクチャ内にある VMware Horizon 7 ポッド

オンプレミスインフラストラクチャに Horizon 7 Cloud Connector をデプロイし、

そのポッドを Horizon Cloud に接続するように構成します。

VMware Cloud on AWS SDDC に手動でインストールお

よび構成した VMware Horizon 7 ポッド

VMware Cloud on AWS SDDC に Horizon 7 Cloud Connector をデプロイし、そ

のポッドを Horizon Cloud に接続するように構成します。

Horizon Cloud が Microsoft Azure クラウドのキャパシテ

ィにデプロイした Horizon Cloud ポッド

Horizon Cloud 管理コンソールの自動デプロイウィザードを使用してポッドをデプ

ロイします。

重要：本番環境では、ファームとデスクトップ割り当てに使用する仮想マシンモデルに少なくとも 2 個の CPU が確実に搭載されているようにします。VMware のスケールテストでは、2 個以上の CPU を使用することによって、

予期しないエンドユーザー接続の問題を回避していることが示されています。システムによって、単一の CPU を搭

載した仮想マシンモデルの選択が妨げられることはありませんが、このような仮想マシンモデルはテスト用または

概念実証用にのみ使用する必要があります。

この章には、次のトピックが含まれています。

n VMware Horizon Cloud Service on Microsoft Azure 要件チェックリスト - 2019 年 12 月のサービスリリー

スで使用

n VMware Horizon 7 with Horizon Cloud の要件チェックリスト - 2019 年 12 月のサービスリリースで使用

VMware Horizon Cloud Service on Microsoft Azure 要件チェックリ

スト - 2019 年 12 月のサービスリリースで使用

次のタスクを完了して、VMware Horizon® Cloud Service™ をデプロイするための Microsoft Azure サブスクリプ

ションとネットワークを準備します。デプロイを正常に完了するには、以下の内容に従ってすべての手順を完了して

おく必要があります。

n Horizon Cloud 制御プレーンの要件

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

n ネットワーク要件

n Active Directory の要件

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

n Horizon Cloud 基本イメージ、デスクトップ、およびファーム

n ライセンス

n デプロイのワークフロー

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


VMware, Inc. 15

n リソース

重要：ポッドデプロイウィザードを起動してポッドのデプロイを開始する前に、以下の要件に加えて、次の重要な

点に注意する必要があります。

n ポッドのデプロイを成功させるには、ユーザーまたは IT チームが Microsoft Azure 環境で設定したどの

Microsoft Azure ポリシーも、ポッドのコンポーネントの作成をブロック、拒否、または制限しないようにする

ことが必要です。また、Microsoft Azure ポリシーの組み込みポリシー定義がポッドのコンポーネントの作成を

ブロック、拒否、または制限しないことを確認する必要があります。たとえば、ユーザーおよび IT チームは、

Microsoft Azure ポリシーが Azure ストレージアカウントでのコンポーネントの作成をブロック、拒否、また

は制限しないことを確認する必要があります。Azure ポリシーの詳細については、Azure ポリシーのドキュメン

トを参照してください。

n ポッドデプロイヤでは、Azure ストレージアカウントが Azure StorageV1 アカウントタイプを使用する必要

があります。Microsoft Azure ポリシーが、Azure StorageV1 アカウントタイプを必要とするコンテンツの作

成を制限したり拒否したりしないようにします。

n ポッドデプロイヤは、タグを持たないリソースグループ (RG) を作成します。Microsoft Azure ポリシーが、ポ

ッドのタグが付けられていないリソースグループの作成を許可することを確認する必要があります。デプロイ

ヤが作成する RG のリストについては、『管理ガイド』の Microsoft Azure にデプロイされたポッド用に作成さ

れたリソースグループトピックを参照してください。

Horizon Cloud 制御プレーンの要件

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

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

☐ サポートされている Microsoft Azure 環境（パブリック Azure、Azure China、Azure Germany、Azure Government）で有効

な Microsoft Azure サブスクリプション。オプションの外部 Unified Access Gateway を専用のサブスクリプションを使用して個

別の VNet にデプロイする場合、同じ Microsoft Azure 環境に追加の有効な Microsoft Azure サブスクリプションが必要です。

☐ Microsoft Azure サブスクリプションで有効な Microsoft Azure 管理者権限。詳細については、Microsoft ドキュメントの Azure ポータルでのロールベースのアクセス制御の開始を参照してください。


VMware, Inc. 16

https://docs.microsoft.com/en-us/azure/governance/policy/

https://docs.microsoft.com/en-us/azure/governance/policy/

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-9F004F77-5685-400E-8ADC-3ECA96D3CA71.html

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-9F004F77-5685-400E-8ADC-3ECA96D3CA71.html

https://docs.microsoft.com/en-us/azure/role-based-access-control/overview

https://docs.microsoft.com/en-us/azure/role-based-access-control/overview

☐ 予想されるデスクトップおよびアプリのワークロードに加えて、Horizon Cloud インフラストラクチャの Microsoft Azure の最小

キャパシティが利用可能であること。キャパシティが利用可能になっている限りは、Horizon Cloud によって以下の仮想マシンが自

動的にデプロイされるため、手動でのインストールは必要ありません。

n ポッドデプロイエンジン、（一時的な）ジャンプボックスとも呼ばれます — Standard_F2 x 1

n 高可用性が有効なポッド/ポッドマネージャ - Standard_D4_v3 x 2（リージョン内に Standard_D4_v3 がない場合は

Standard_D3_v2 x 2）

n 高可用性が有効でないポッド/ポッドマネージャ - Standard_D4_v3 x 1（リージョン内に Standard_D4_v3 がない場合は

Standard_D3_v2 x 1）

n Microsoft Azure Database for PostgreSQL サービス - 第 5 世代、メモリ最適化、2 つの vCore、10 GB ストレージ

n 外部 Unified Access Gateway（オプション）— Standard_A4_v2 x 2

n 内部 Unified Access Gateway（オプション）— Standard_A4_v2 x 2

n 基本イメージ、仮想デスクトップ、および RDSH ファーム（Horizon Cloud 基本イメージ、デスクトップ、およびファームセ

クションを参照）

外部 Unified Access Gateway は、ポッドと同じサブスクリプションを使用するか、別のサブスクリプションを使用して、専用の

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

n 外部 Unified Access Gateway デプロイエンジン、（一時的な）ゲートウェイジャンプボックスとも呼ばれます — Standard_F2 x 1

n 外部ゲートウェイコネクタ — Standard_A1_v2 x 1

n 外部 Unified Access Gateway — Standard_A4_v2 x 2

☐ サブスクリプションごとに作成されたサービスプリンシパルと認証キー。詳細については、方法：リソースにアクセスできる Azure AD アプリケーションとサービスプリンシパルをポータルで作成するを参照。

☐ サービスプリンシパルに、サブスクリプションレベルで必要な許可されたアクションを持つ共同作成者ロールまたはカスタムロール

が割り当てられていること。必要なロールアクションの詳細については、Microsoft Azure サブスクリプションの Horizon Cloud ポッドデプロイヤに必要なロール操作を参照。

☐ 必要なリソースプロバイダが Microsoft Azure サブスクリプションで登録されていること。

☐ Microsoft Azure サブスクリプション ID、ディレクトリ ID、アプリケーション ID、およびキーが特定されていること。

ネットワーク要件

☐ 必要なサブネットをカバーする適切なアドレス空間を使用して、目的の Microsoft Azure リージョンに Microsoft Azure 仮想ネッ

トワーク (VNet) が作成済みであること。詳細については、Azure 仮想ネットワークを参照。

オプションの外部 Unified Access Gateway をポッドの VNet とは別の独自の VNet にデプロイする場合、ポッドの VNet と同じ

Microsoft Azure リージョンに必要なサブネットをカバーする適切なアドレス空間を持つ Unified Access Gateway VNet を作成

し、2 つの VNet をピアリングします。

☐ ポッドの VNet の重複していない 3 つのアドレス範囲（CIDR 形式）がサブネット用に予約済みであること。

n 管理サブネット — 27 以上

n テナントサブネット — /27 以上。/24 ～ /22 を推奨（デスクトップおよび RDS サーバの数に基づく）

n DMZ サブネット — ポッドの VNet に Unified Access Gateway がデプロイされている場合は /28 以上（オプション）

サブネットは、VNet 上で手動で作成することも、デプロイ中に Horizon Cloud によって作成することもできます。手動で作成され

たサブネットを使用する場合、他のリソースは接続できません。


VMware, Inc. 17

https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-create-service-principal-portal?view=azure-cli-latest

https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-create-service-principal-portal?view=azure-cli-latest

https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview

☐ オプションの外部 Unified Access Gateway をポッドの VNet とは別の独自の VNet にデプロイする場合、Unified Access Gateway の VNet で 3 つの重複しないアドレス範囲（CIDR 形式）がサブネット用に予約されていること。

n 管理サブネット — 27 以上

n バックエンドサブネット — /27 以上。/24 ～ /22 を推奨（デスクトップおよび RDS サーバの数に基づく）

n 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 に必要です）。

☐ FQDN と一致する、外部エンドユーザーアクセス用にパブリック DNS レコードが作成されていること。これが、外部 Unified Access Gateway 構成の Microsoft Azure 外部ロードバランサを参照していること（オプション）。詳細については、Azure クラ

ウドサービスのカスタムドメイン名の構成を参照。

☐ FQDN と一致する、内部エンドユーザーアクセス用に内部 DNS レコードが作成されていること。これが、内部 Unified Access Gateway 構成の Microsoft Azure 内部ロードバランサを参照していること（オプション）。

☐ FQDN に一致する PEM 形式の Unified Access Gateway の証明書（Unified Access Gateway に必要）。

☐ オンプレミス RADIUS 認証サーバへの 2 要素認証（オプション）

n 認証サーバの名前を解決するための Unified Access Gateway の DNS アドレス

n 認証サーバへのネットワークルーティングを解決する Unified Access Gateway のルート

☐ ポッドに直接接続するために内部 DNS レコードが作成されていること。これがポッドにアップロードする証明書と一致し、ポッド

マネージャの Microsoft Azure 内部ロードバランサを参照していること（オプション）。

☐ ポッドへの直接接続用に作成されている内部 DNS レコードに一致する証明書チェーン（CA 証明書、SSL 証明書、SSL キーファイ

ル）。詳細については、直接接続のために SSL 証明書を Horizon Cloud ポッドにアップロードするを参照。

Active Directory の要件

☐ サポートされている次の Active Directory 構成のいずれか：

n VPN/ExpressRoute を介して接続されたオンプレミス Active Directory サーバ

n Microsoft Azure にある Active Directory サーバ

n Microsoft Azure の Active Directory ドメインサービス

☐ サポートされる Microsoft Windows Active Directory Domain Services (AD DS) ドメイン機能レベル：

n Microsoft Windows Server 2003

n Microsoft Windows Server 2008 R2




VMware, Inc. 18

https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-custom-domain-name

https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-custom-domain-name

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-23E74933-1441-42A3-AEE9-A95FD1555E03.html

☐ すべてのクラウド接続されたポッドは、それらのポッドをデプロイするときに、Active Directory ドメインの同じセットに接続され

ている必要があります。

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

n Active Directory でのオブジェクトの読み取り権限を持つ Active Directory ドメインバインドアカウント（読み取りアクセス

権限を持つ標準ユーザー）。

n アカウントパスワードを「無期限」に設定。

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

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





☐ ドメイン参加アカウント

n システムが Sysprep 操作を実行し、コンピュータをドメインに参加させるために使用できる Active Directory ドメイン参加ア

カウント。通常は新規アカウントです（「ドメイン参加ユーザーアカウント」）。

n Horizon Cloud 管理者グループのメンバーである。


n このアカウントには、次の Active Directory 権限が必要です：コンテンツの一覧表示、すべてのプロパティの読み取り、アクセ

ス権の読み取り、パスワードのリセット、コンピュータオブジェクトの作成、コンピュータオブジェクトの削除、およびすべて

のプロパティの書き込み。


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









☐ Active Directory グループ

n Horizon Cloud 管理者 — Horizon Cloud 管理者の Active Directory セキュリティグループ。Horizon Cloud 管理ユーザー

とドメイン参加アカウントが含まれています。このグループは、Horizon Cloud の「スーパー管理者」ロールに追加されます。

n Horizon Cloud ユーザー — Horizon Cloud の仮想デスクトップおよび RDS セッションベースのデスクトップと公開済みアプ

リケーションにアクセスするユーザーの Active Directory セキュリティグループ。

☐ 仮想デスクトップおよび RDS セッションベースのデスクトップまたは公開アプリケーション、またはその両方の Active Directory 組織単位 (OU)。

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

☐ ポッドのオンボーディングと Horizon Cloud 環境の継続的な運用には特定のポートとプロトコルが必要です。2019 年 9 月のリリ

ースのマニフェスト以降の Horizon Cloud ポッドのポートとプロトコルの要件を参照してください。


VMware, Inc. 19

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-5F0B52F6-CD79-447B-B1C6-6ED2AF71BBA7.html




Horizon Cloud 基本イメージ、デスクトップ、およびファーム

☐ マスターイメージの基本 — サポートされている Microsoft Azure 仮想マシン構成のいずれか。

n Standard_D4_v3 または Standard_D2_v2

n Standard_NV6

☐ VDI デスクトップ割り当てのデスクトップモデルの選択 — Microsoft Azure リージョンで使用可能な Microsoft Azure 仮想マシ

ン構成のいずれか（Horizon Cloud デスクトップ操作と互換性のないものを除く）。

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

☐ RDS ファーム用の RDS サーバモデルの選択 — Microsoft Azure リージョンで使用可能な Microsoft Azure 仮想マシン構成のいず

れか（Horizon Cloud RDS ファーム操作と互換性のないものを除く）。

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

ライセンス

☐ Microsoft Windows 10 ライセンス

☐ Microsoft Windows Server 2012 R2、Server 2016 ライセンスまたは Server 2019 ライセンス、あるいはそれら両方

☐ Microsoft Windows RDS ライセンスサーバ — 高可用性のために冗長ライセンスサーバを推奨

☐ Microsoft RDS ユーザーまたはデバイス CAL（またはその両方）

デプロイのワークフロー

上記のチェックリストが完成したら、クラウド接続された最初のポッドが Microsoft Azure へのデプロイから作成さ

れた場合の概要レベルのワークフローに従ってサービスをデプロイし、管理を開始します。

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

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


VMware, Inc. 20

図 1-1. 高可用性が有効で、外部ゲートウェイと内部ゲートウェイの両方の構成が設定され、ポッドと同じ VNet に外

部ゲートウェイがデプロイされ、外部ゲートウェイのロードバランサでパブリック IP アドレスが有効になっている

ポッドの Horizon Cloud Pod アーキテクチャの図

仮想マシン

仮想マシン

仮想マシン

仮想マシン

仮想マシン

仮想マシン

仮想マシン

仮想マシン

管理ネットワーク

管理者Horizon Cloud制御プレーンインターネット

外部ユーザー

内部ユーザー

ゲートウェイ VPN または

ExpressRoute

Microsoft Azure ロードバランサ

PostgresDB

ベース仮想マシン

公開済イメージ

RG: vmw-hcs-<podID>-pool-1001

RG: vmw-hcs-<podID>-pool-100n

RG: vmw-hcs- <podID>-base-vms

RG: vmw-hcs-<podID>-jumpbox

仮想マシン：ジャンプボックス（一時）

NIC/IP アドレス

RG: vmw-hcs-<podID>

仮想マシン：ポッド

マネージャ 1


マネージャ 2

DMZ ネットワーク

パブリック IP アドレス

仮想マシン： Unified Access

Gateway 1


Gateway 2


Gateway 1


Gateway 2


RG: vmw-hcs-<podID>-uag

RG: vmw-hcs-<podID>-uag-internal

テナントネットワーク

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

Microsoft Azure 内部ロードバランサ

IPsec トンネルを備えた 2 VPN ゲートウェイ

外部ネットワークに接続

VPN ゲートウェイ（オプション）



VMware, Inc. 21

図 1-2. 外部ゲートウェイがポッドの VNet とは別の専用の VNet にデプロイされている場合の外部ゲートウェイの

アーキテクチャ要素の図

VNet-2 の管理サブネット

管理者インターネットHorizon Cloud制御プレーン

外部ユーザー


一時ジャンプボックスの RG

NIC/IP アドレス

仮想マシン：コネクタ

外部ゲートウェイコネクタ

仮想マシンの RG

外部ゲートウェイリソースの RG

NIC/IP アドレス

VNet-2 の DMZ （フロントエンド）サブネット

VNet-2

仮想マシン： UAG-1


ロードバランサの IP アドレス

VNet-2 のバックエンドサブネット

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス


NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

リソース

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

n VMware Horizon Cloud Service ドキュメントページ（製品ガイドおよびリリースノートへのリンクを提供）

n VMware Unified Access Gateway ドキュメントページ

n VMware Horizon Cloud on Microsoft Azure のクイックスタートチュートリアル

n Microsoft Azure Resource Manager の概要（5 分）

n ポータルを使用して Microsoft Azure サービスプリンシパルを作成する（6 分）

n Microsoft Azure 仮想ネットワーク (VNet)（5 分）

n Microsoft Azure 仮想ネットワークのピアリング（6 分）

VMware Horizon 7 with Horizon Cloud の要件チェックリスト - 2019 年 12 月のサービスリリースで使用

次のタスクを実行して、Horizon 7 環境をオンプレミスまたは VMware Cloud on AWS で Horizon Cloud と接続

するための準備をします。デプロイを正常に完了するには、以下の内容に従ってすべての手順を完了しておく必要が

あります。

n Horizon Cloud 制御プレーンの要件


VMware, Inc. 22

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/index.html

https://docs.vmware.com/jp/Unified-Access-Gateway/

https://techzone.vmware.com/quick-start-tutorial-vmware-horizon-cloud-service-microsoft-azure

https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview

https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal?view=azure-cli-latest


https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview

n Active Directory の要件

n Horizon 7 ポッドと Horizon 7 Cloud Connector の要件

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

n ライセンス

Horizon Cloud 制御プレーンの要件

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

☐ Horizon 7 で有効な Horizon ユニバーサルまたはサブスクリプションライセンス。これらのライセンスタイプの詳細については、

[Horizon ユニバーサルライセンスおよびサブスクリプション] ページを参照してください。

Active Directory の要件

☐ サポートされる Microsoft Windows Active Directory Domain Services (AD DS) ドメイン機能レベル：






☐ すべてのクラウド接続されたポッドは、それらのポッドを接続またはデプロイするときに、Active Directory ドメインの同じセット

に接続されている必要があります。

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





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





☐ ドメイン参加アカウント










VMware, Inc. 23





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









☐ Active Directory グループ

n Horizon Cloud 管理者 — Horizon Cloud 管理者の Active Directory セキュリティグループ。Horizon Cloud 管理ユーザー

とドメイン参加アカウントが含まれています。このグループは、Horizon Cloud の「スーパー管理者」ロールに追加されます。

n Horizon Cloud ユーザー — Horizon Cloud の仮想デスクトップおよび RDS セッションベースのデスクトップと公開済みアプ

リケーションにアクセスするユーザーの Active Directory セキュリティグループ。

Horizon 7 ポッドと Horizon 7 Cloud Connector の要件

☐ Horizon 7 ポッドが Horizon 7 7.9 以降のバージョンを実行していること。クラウド接続されたポッドで最新のクラウドサービス

および機能を使用するには、最新バージョンである Horizon 7 7.11 を実行している必要があります。

☐ バージョン 1.4 以降の Horizon 7 Cloud Connector 仮想アプライアンス。クラウド接続されたポッドで最新のクラウドサービス

および機能を使用するには、最新バージョンである Horizon 7 Cloud Connector バージョン 1.5 を実行している必要があります。

n 固定 IP アドレス

n DNS 正引きおよび逆引き参照レコード

☐ Horizon 7 Cloud Connector 仮想アプライアンスのリソース要件：

n バージョン 1.4 の場合：vCPU x 8、8 GB メモリ (RAM)、40 GB のハードディスク

n バージョン 1.5（最新）の場合：vCPU x 8、8 GB メモリ (RAM)、40 GB のハードディスク

重要： Connection Server 仮想マシン、Unified Access Gateway 仮想マシン、およびその他のコンポーネントなどの Horizon 7 管理コンポーネントの容量を予約するとともに、Horizon 7 Cloud Connector コンポーネントの容量を予約する必要があります。

Horizon 7 Cloud Connector は、Horizon 7 ポッドを Horizon Cloud に接続するために Horizon 7 ポッド環境にデプロイされる

インフラストラクチャコンポーネントです。これは、そのポッドで Horizon サブスクリプションライセンスとクラウドホスト型サ

ービスを使用するユースケースを想定しています。

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

☐ Horizon 7 Cloud Connector および Horizon Cloud テナント環境の進行中の操作には特定のポートとプロトコルが必要です。

Horizon 7 Cloud Connector と Horizon 7 ポッドを使用するときの DNS、ポート、およびプロトコルの要件を参照してください。

☐ Horizon 7 で有効な Horizon ユニバーサルまたはサブスクリプションライセンス。これらのライセンスタイプの詳細については、

[Horizon ユニバーサルライセンスおよびサブスクリプション] ページを参照してください。

ライセンス

☐ Microsoft Windows 7 および Windows 10 のライセンス

☐ Microsoft Windows Server 2012 R2、Server 2016 ライセンスまたは Server 2019 ライセンス、あるいはそれら両方


VMware, Inc. 24


https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.getstarted15/GUID-2EA5CC20-0452-4BC2-A898-30F493C21DC5.html


☐ Microsoft Windows RDS ライセンスサーバ — 高可用性のために冗長ライセンスサーバを推奨

☐ Microsoft RDS ユーザーまたはデバイス CAL（またはその両方）


VMware, Inc. 25

Horizon Cloud テナント環境への最初のクラウド接続されたポッドのオンボーディング

2最初から VMware Horizon® Cloud Service™ を使用して体験を開始する場合は、このガイドのトピックを参照して

ください。この体験の開始時には、Horizon Cloud テナント環境は完全に新規であり、クラウド接続されたポッドは

ありません。最初の手順は、その新しい環境にポッドをオンボーディングすることです。そのポッドは、クラウド接

続された最初のポッドです。次のトピックでは、現在 Horizon Cloud で使用可能なポッドタイプのいずれかで、ク

ラウド接続された最初のポッドを取得する方法について説明します。

Horizon Cloud テナント環境を取得するプロセス、およびその環境とポッドのオンボーディグとの関係についての概

要については、「Horizon Cloud for Microsoft Azure、Horizon 7 オンプレミス、および Horizon 7 on VMware Cloud on AWS へのオンボーディング」を参照してください。

次のスクリーンショットは、アカウントに初めてログインしたときに、新しい Horizon Cloud 環境がどのようなも

のかを示しています。

VMware, Inc. 26

この最初の画面は、キャパシティを追加するという考えに基づいています。ここでのキャパシティの追加は、さまざ

まなキャパシティ環境でポッドをデプロイし、それらのポッドを Horizon Cloud 環境全体に接続することと同じと

考えて差し支えありません。

画面上のテキストの表示このテキストが最初のクラウド接続ポッドとどのように関連するか

[オンプレミスのキャパシティの追加方法について...] この時点からオンプレミスのキャパシティを追加すると、最初のクラウド接続のポッドが、オ

ンプレミスでの既存の Horizon 7 ポッドまたは VMware Cloud on AWS で手動で構成した

ポッドになります。最初のクラウド接続されたポッドとしてこのタイプに関心がある場合は、

トピック Horizon Cloud テナント環境への最初のポッドとして、手動でデプロイされた既存

の Horizon 7 ポッドをオンボーディングする場合のワークフローの概要から最善の方法を確

認してください。

[クラウドキャパシティの追加...Microsoft Azure クラウド]

この時点から Microsoft Azure のクラウドキャパシティを追加すると、ウィザードによって

ポッドが Microsoft Azure に自動的にデプロイされます。そのプロセスが完了すると、その

ポッドは最初のクラウド接続ポッドになります。最初のクラウドに接続されたポッドでこの

タイプに関心がある場合は、トピック最初のポッドデプロイに対して Microsoft Azure クラ

ウドキャパシティを選択する場合およびそのサブトピックを参照してください。

最初のポッドがテナント環境にオンボーディングされたら、コンパニオン Horizon Cloud 管理ガイドを使用して、

その最初のクラウド接続されたポッドで Active Directory ドメイン登録ワークフローを完了する方法について確認

します。ドメインの登録が完了したら、そのコンパニオンの Horizon Cloud 管理ガイドを引き続き使用して、ポッ

ドの追加など、Horizon Cloud で実行できるすべてのワークフローについて学習します。このガイドは、トピック

「Horizon Cloud について」、「Horizon Cloud 環境の使用を開始する」およびそのサブトピックから始まります。

注： n VMware Cloud on AWS に手動で作成した Horizon 7 ポッドがあり、Horizon Cloud に接続する場合は、[オ

ンプレミスのキャパシティを追加] ワークフローを使用して、既存のポッドを接続することができます。これが

最初に完了したキャパシティの追加ワークフローである場合は、そのポッドが最初のクラウド接続ポッドになり

ます。このドキュメントで説明する手順を開始する前に、「VMware Horizon 7 with Horizon Cloud の要件チ

ェックリスト - 2019 年 12 月のサービスリリースで使用」も参照してください。このチェックリストは、

VMware Cloud on AWS への最初のデプロイを成功させるために必要なさまざまな前提条件の要素について説

明しています。

n 最初のクラウドに接続されたポッドとして Microsoft Azure クラウドのキャパシティを追加している場合は、こ

のドキュメントで説明されている手順を開始する前に、「VMware Horizon Cloud Service on Microsoft Azure 要件チェックリスト - 2019 年 12 月のサービスリリースで使用」も参照してください。このチェックリストは、

Microsoft Azure への最初のデプロイを成功させるために必要なさまざまな前提条件の要素について説明して

います。

この章には、次のトピックが含まれています。

n 最初のポッドデプロイでオンプレミスのキャパシティを選択した場合

n 最初のポッドデプロイに対して Microsoft Azure クラウドキャパシティを選択する場合


VMware, Inc. 27

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-3E17DDDC-807B-4952-A1D3-F37364925AA3.html

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-A4FA2F8E-6AF5-4F4A-9437-01107591337F.html

最初のポッドデプロイでオンプレミスのキャパシティを選択した場

合

ここで、オンプレミスのキャパシティとは、オンプレミスのインフラストラクチャまたは VMware Cloud on AWS SDDC で手動でインストールおよび構成した VMware Horizon 7 のデプロイのことになります。このような

Horizon 7 のデプロイを Horizon Cloud テナント環境にオンボーディングするのは、Horizon 7 ポッドでサブスク

リプションライセンスを適用する場合と、そのライセンスでクラウドホスト型サービスを使用する場合の 2 つの使

用事例になります。そのポッドでサブスクリプションライセンスが有効化されると、そのアクティベーションによっ

て、これらのクラウドホスト型サービスを利用できるようになります。このようなサービスには、クラウド接続され

たポッド向けの機能およびワークフローが含まれます。どちらの使用事例でも、Horizon 7 のデプロイを Horizon Cloud のクラウドベース管理プレーンに接続するコンポーネントである VMware Horizon® 7 Cloud Connector™ を使用する必要があります。この接続は、Horizon 7 デプロイへのサブスクリプションライセンスの適用と、クラウ

ド監視サービス (CMS) などのクラウドホスト型サービスの有効化の両方を提供します。

ポッドをクラウド制御プレーンに初めてオンボーディングするプロセスの概要については、「Horizon Cloud for Microsoft Azure、Horizon 7 オンプレミス、および Horizon 7 on VMware Cloud on AWS へのオンボーディン

グ」を参照してください。

仮想マシン

Connection Server

管理サービスシステムの健全性

Cloud Connector

Horizon 7 ポッド

クラウド監視サービス (CMS)

ライセンスサービス

Active Directory

Horizon Cloud 管理プレーン

Horizon API

重要： Horizon Cloud 環境は、Microsoft Azure のポッドと、オンプレミスおよび VMware Cloud on AWS にあ

るポッドで構成することができます。そのため、クラウド接続されたすべてのポッドは、同じ Active Directory ドメ

インのセットとの通信路を確立している必要があります。環境内にすでに Microsoft Azure のポッドがあり、最初の

Horizon 7 ポッドを接続する場合は、Horizon 7 ポッドを接続したときに Horizon 7 ポッドがすでに Horizon Cloud 環境に登録されている Active Directory ドメインを認識できることを確認する必要があります。Active Directory のドメイン登録ワークフローの詳細については、Horizon Cloud 環境での最初の Active Directory ドメ

イン登録の実行を参照してください。


VMware, Inc. 28

https://docs.vmware.com/enVMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-CBAA1736-2B10-4875-B19A-64520C63572D.html

https://docs.vmware.com/enVMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-CBAA1736-2B10-4875-B19A-64520C63572D.html

Horizon 7 Cloud Connector を使用した、Horizon 7 ポッド向けのサブスクリプションライセンスのアクティブ化と、クラウドホスト型サービスの有効化

Horizon 7 Cloud Connector は、Horizon 7 ポッドと Horizon Cloud の橋渡しをする仮想アプライアンスです。

Horizon 7 Cloud Connector は、Horizon 7 サブスクリプションライセンス、健全性ステータスダッシュボード、

および Horizon ヘルプデスクツールなどを含む、お使いの Horizon 7 ポッドでのクラウドホスト型のサービスを

使用するために必要となります。

Horizon 7 サブスクリプシ

ョンライセンス

Horizon 7 サブスクリプションライセンスは、スタンドアローンの Horizon 7 パッ

ケージとして利用できます。また、Workspace ONE エンタープライズバンドルの

一部としても使用できます。Horizon 7 サブスクリプションライセンスでは、同じ

製品をより「柔軟な展開」オプションがある状態で提供します。Horizon 7 サブス

クリプションライセンスでは、データセンター、プライベートクラウド、および

VMware Cloud on AWS での Horizon 7 のデプロイが可能になります。Horizon 7 Cloud Connector を使用してポッドを Horizon Cloud にオンボーディングする

手順を完了すると、VMware はサブスクリプションライセンスを有効化します。

48 時間以内に、ライセンスサービスはそのクラウド接続されたポッドにライセン

スを適用し、Horizon 7 管理のライセンス画面にメッセージが表示されます。

https://my.vmware.com から Horizon 7 ライセンスを購入するには、アクティブ

な My VMware アカウントが必要です。Horizon 7 Cloud Connector を OVA ファイルとしてダウンロードできるリンクがようこそ E メールで届きます。

vSphere Web Client から Horizon 7 Cloud Connector 仮想アプライアンスをデ

プロイする場合、Cloud Connector を、サブスクリプションライセンスまたはク

ラウドホスト型サービスを使用するために Horizon Cloud に接続するポッドの

Connection Server とペアリングします。ペアリングプロセスにおいて、Horizon 7 Cloud Connector 仮想アプライアンスが Connection Server を Horizon Cloud に接続し、Horizon 7 サブスクリプションライセンスおよびその他のサービ

スを管理します。Horizon 7 サブスクリプションライセンスがある場合、VMware Horizon 7 製品のアクティベーションのための Horizon 7 ライセンスキーを手動

で入力する必要はありません。ただし、vSphere、App Volumes などのサポート

コンポーネントを有効にするには、ライセンスキーを使用する必要があります。

Horizon 7 ポッド用のクラ

ウドホスト型サービス

Horizon 7 Cloud Connector を使用してポッドを Horizon Cloud に接続する手

順を完了したら、サブスクリプションライセンスを適用することに加えて、Horizon Cloud が提供する、ご利用のサブスクリプションライセンスに応じて利用可能とな


VMware, Inc. 29


る、クラウドホスト型サービス、機能、およびワークフローを利用できます。たと

えばクラウド監視サービス (CMS) などです。「Horizon Cloud で提供されるクラウ

ド監視サービスの統合された可視性、健全性監視、およびヘルプデスク機能の紹

介」を参照してください。

Horizon Cloud テナント環境への最初のポッドとして、手動でデプロイされた既存の Horizon 7 ポッドをオンボーディングする場合のワークフローの概要

このリストは、最初のポッドを Horizon Cloud テナント環境にオンボーディングし、そのポッドが手動でデプロイ

された既存の Horizon ポッドである場合の手順の概要です。手動でデプロイされたポッドは、オンプレミスのキャパ

シティまたは VMware Cloud on AWS キャパシティを使用して手動でインストールして構成したポッドです。最初

のクラウド接続されたポッドでこれらのオンボーディング手順が完了すると、サブスクリプションライセンスがその

オンボーディングされた Horizon 7 ポッドに適用され、Horizon Cloud がそのポッドに提供するクラウドホスト型

サービスの使用を開始できます。これには、クラウド監視サービス (CMS) が含まれます。その時点で、追加のポッド

をオンボーディングすることもできます。

次の図は、全体的なフローを示しています。

仮想マシン

vApp

Horizon ユニバーサル/サブスクリプションライセンスの取得

固定 IP アドレスを使用して Horizon 7 Cloud Connector OVA をダウンロードして Horizon 7 ポッドにデプロイ

ポッドの Active Directory ドメインを Horizon Cloud に登録

デプロイされた Horizon 7 Cloud Connector およびポッドを Horizon Cloud とペアリング

このワークフローを開始する前に、Horizon 7 ポッドをインストールおよび構成しておく必要があります。この

Horizon Cloud リリースで使用できる Horizon 7 ポッドの手動インストールの詳細については、以下を参照してく

ださい。

n オンプレミスのキャパシティを使用してポッドを手動でインストールする方法については、Horizon 7 のドキュ

メントページから Horizon 7 の最新バージョンのインストールの関連情報を参照してください。

n VMware Cloud on AWS キャパシティを使用してポッドを手動でインストールする方法については、『Horizon 7 on VMware Cloud on AWS』製品ページから利用できる Horizon 7 on VMware Cloud on AWS のデプロイ

のベストプラクティスガイドを参照してください。


VMware, Inc. 30

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-9815E322-A13F-4E0A-B4F7-98B34A054D8F.html



https://docs.vmware.com/jp/VMware-Horizon-7/index.html

https://docs.vmware.com/jp/VMware-Horizon-7/index.html

https://www.vmware.com/products/horizon/horizon-on-vmc-aws.html

https://www.vmware.com/products/horizon/horizon-on-vmc-aws.html

既存の Horizon 7 ポッドをクラウドにオンボーディングする場合、2 つの主要なユースケースを想定します。すなわ

ち、そのポッドのサブスクリプションライセンスをアクティブ化すること、そして Horizon Cloud がそのタイプの

ポッドに提供するクラウド監視サービス (CMS) などのクラウドホスト型サービスを使用できるようにすることで

す。CMS は、Horizon Cloud で提供される中心的なサービスの 1 つです。CMS は、クラウドに接続されたポッド

に可視性、健全性監視、ヘルプデスクサービスを提供します。ポッドをクラウド制御プレーンにオンボーディング

するプロセスの概要については、「Horizon Cloud for Microsoft Azure、Horizon 7 オンプレミス、および Horizon 7 on VMware Cloud on AWS へのオンボーディング」を参照してください。

注意：以下の手順をすべて完了して最初のポッドを Horizon Cloud に完全に接続してから、その後手動でインスト

ールして接続したいポッドに Horizon 7 Cloud Connector をデプロイします。このリリースの既知の問題により、

Active Directory ドメイン登録およびスーパー管理者ロール割り当ての手順を一度も完了することなく Horizon 7 Cloud Connector を使用して複数のポッドをクラウドに接続すると、Active Directory ドメイン登録の手順が失敗

します。その時点で、必要な Active Directory ドメイン登録とスーパー管理者ロールの割り当ての手順を正常に完了

する前に、クラウド接続された Horizon 7 ポッドの 1 つ以外のすべてを接続解除する必要があります。

1 Horizon ユニバーサルライセンスなどの Horizon サブスクリプションライセンスの取得を含む前提条件を満

たします。「VMware Horizon 7 with Horizon Cloud の要件チェックリスト - 2019 年 12 月のサービスリリ

ースで使用」および「Horizon Cloud Service を既存の Horizon 7 ポッドと接続して、Horizon サブスクリプ

ションライセンスまたはクラウドホスト型サービス、あるいはその両方を使用する」の前提条件のセクション

を参照してください。

2 Horizon 7 ポッドを Horizon Cloud と接続するための DNS、ポート、およびプロトコルの要件が満たされてい

ることを確認します。 Horizon 7 Cloud Connector と Horizon 7 ポッドを使用するときの DNS、ポート、お

よびプロトコルの要件を参照してください。

3 必要に応じて Horizon Cloud テナントポータルにログインし、テナント環境に追加の管理者を構成します。

ヒント: 次の手順を実行してテナント環境に最初に関連付けられている My VMware アカウントのみを使用し

てポッドをオンボーディングすることができますが、このプロセスの開始時に追加の管理者を構成することをお

勧めします。テナントアカウントに関連付けられている My VMware アカウントが 1 つだけの場合に認証情報

にアクセスできなくなると、新しい My VMware アカウントをテナントアカウントに関連付けるために

VMware へのサービスリクエストを開く必要があるため、遅延が発生する可能性があります。このような遅延

を防ぐには、最初に関連付けられた My VMware アカウントで cloud.horizon.vmware.com のテナントポー

タルにログインし、画面の [全般設定] セクションの行を使用して「Horizon Cloud テナント環境にログインす

る管理者を追加する」に説明されている手順を実行します。

4 Horizon 7 Cloud Connector 仮想アプライアンスをポッドの環境にデプロイします。「Horizon Cloud Service を既存の Horizon 7 ポッドと接続して、Horizon サブスクリプションライセンスまたはクラウドホスト型サー

ビス、あるいはその両方を使用する」で説明されている OVA のデプロイ手順に従います。


VMware, Inc. 31


https://cloud.horizon.vmware.com



5 Horizon 7 Cloud Connector のオンボーディングポータルにログインし、コネクタとポッドの Connection Server をペアリングするオンボーディング手順を実行します。

ヒント: コネクタと Connection Server が正常にペアリングされると、Horizon 7 Cloud Connector のオン

ボーディングポータルに完了メッセージが表示されます。この時点で、VMware はサブスクリプションライセ

ンスをアクティベーションします。アクティベーションには、最大 48 時間かかります。ライセンスが有効にな

ると、標準の Horizon 7 [製品ライセンスと使用] 画面に「ライセンスサービスに接続されました」というメッセージが

表示されます。

6 必要に応じて、Horizon 7 Cloud Connector 仮想アプライアンス用の CA 署名付き証明書を構成します。

Horizon 7 Cloud Connector 仮想アプライアンスの CA 署名付き証明書の構成を参照してください。

7 管理コンソールと呼ばれる Horizon Cloud テナントポータル内で Active Directory ドメイン登録ワークフロ

ーを実行します。Horizon Cloud 管理ガイドを参照してください。

ヒント: Active Directory ドメイン登録ワークフローを完了すると、クラウド監視サービス (CMS) など、すべ

てのクラウドホスト型サービスを利用できます。ポッドの Active Directory ドメインがテナント環境に登録さ

れるまで、ポータルは、CMS の監視データが表示される管理コンソールの画面へのアクセスをブロックします。

8 ドメイン参加アカウントをメンバーとして含む Active Directory グループに Horizon Cloud スーパー管理者

の役割を付与します。Horizon Cloud 管理ガイドを参照してください。

各ワークフローステップを実行する方法の詳細については、上記の各手順にリンクされたトピックまたはコンパニオ

ンガイドを参照してください。Horizon Cloud 管理ガイドを参照してください。

Horizon 7 Cloud Connector と Horizon 7 ポッドを使用するときの DNS、ポート、およびプ

ロトコルの要件

Horizon 7 Cloud Connector コンポーネントを Horizon 7 ポッドとともに使用しているときに、Cloud Connector が必要なドメインネームサービス (DNS) のアドレスにアクセスできるように、ファイアウォールを構成する必要が

あります。さらに、このトピックで説明するように、プロキシ設定には構成済みのポートとプロトコルが必要で、

DNS は特定の名前を解決する必要があります。次に、Cloud Connector コンポーネントがデプロイされ、ポッドを

Horizon Cloud に正常に接続するための手順が完了したら、Horizon Cloud と Cloud Connector 間の継続的な運

用のために、特定のポートとプロトコルが必要となります。

最初のポッドデプロイでオンプレミスのキャパシティを選択した場合で説明されているように、Cloud Connector コンポーネントは、Horizon 7 でサブスクリプションライセンスをアクティブ化し、クラウドホスト型サービスを

現在の Horizon 7 デプロイで使用できるようにするために、Horizon 7 デプロイで使用されます。


VMware, Inc. 32

http://www.vmware.com/info?id=1439



接続と DNS の要件

Horizon Cloud Service を既存の Horizon 7 ポッドと接続して、Horizon サブスクリプションライセンスまたはク

ラウドホスト型サービス、あるいはその両方を使用するには、ブラウザを使用して Cloud Connector アプライアン

スの IP アドレスに移動し、ログイン画面が表示される手順が含まれています。そのログイン画面を表示するために

は、Cloud Connector アプライアンスと Horizon Cloud クラウド制御プレーン間のインターネット接続が必要で

す。アプライアンスは最初に HTTPS を使用して Horizon Cloud クラウド制御プレーンへの接続を確立してから、ア

ウトバウンドインターネットポート 443 を使用して Web ソケットを開きます。継続的な運用のために、Cloud Connector アプライアンスと Horizon Cloud 間の接続では、ポート 443 を使用するアウトバウンドインターネッ

ト接続が常に開いている必要があります。次の DNS 名が解決可能であり、次の表に記載されている特定のポートお

よびプロトコルを使用してアクセス可能であるようにする必要があります。

ソースターゲット (DNS 名) ポートプロトコル目的

Horizon 7 Cloud Connector

Horizon Cloud アカウントで指定されている

Horizon Cloud 制御プレーンに応じて、次のいずれ

か:

n cloud.horizon.vmware.com

n cloud-eu-central-1.horizon.vmware.com

n cloud-ap-southeast-2.horizon.vmware.com

443 TCP Horizon Cloud 制御プ

レーン

制御プレーンと接続する

ために Horizon 7 Cloud Connector で使

用されます。

n 米国では、

cloud.horizon.vmware.com です。

n ヨーロッパでは、

cloud-eu-central-1.horizon.vmware.com です。

n オーストラリアで

は、cloud-ap-southeast-2.horizon.vmware.com です。


Horizon Cloud アカウントにどのリージョンの

Horizon Cloud 制御プレーンが指定されているかに

応じて異なります。

北米：

n kinesis.us-east-1.amazonaws.com

n query-prod-us-east-1.cms.vmware.com

ヨーロッパ：

n kinesis.eu-central-1.amazonaws.com

n query-prod-eu-central-1.cms.vmware.com

オーストラリア：

n kinesis.ap-southeast-2.amazonaws.com

n query-prod-ap-southeast-2.cms.vmware.com

443 TCP クラウド監視サービス

(CMS)


VMware, Inc. 33

Horizon 7 Cloud Connector アプライアンスで必要となるポートとプロトコル

Horizon 7 Cloud Connector と Horizon Cloud の間の継続的な運用のためには、次の表のポートとプロトコルが必

要です。

表 2-1. Horizon 7 Cloud Connector のポート

ソースターゲットポートプロトコル説明


Horizon Cloud 443 HTTPS Horizon 7 Cloud Connector を Horizon Cloud とペアリン

グし、データを転送するために使

用されます。


Connection Server 443 HTTPS Connection Server への API 呼び出し。


Connection Server 4002 TCP Cloud Connector と

Connection Server との間の

Java Message Service (JMS) 通信

Horizon 7 Cloud Connector アプライアン

スの新しいバージョン

Horizon 7 Cloud Connector アプライア

ンスの既存のバージョン

22 SSH アップグレードプロセスの開始

要求を待機します。

Web ブラウザ Horizon 7 Cloud Connector

443 HTTPS ペアリングプロセスの開始を待

機します。


認証局 * HTTP、HTTPS CRL または OCSP のクエリ

ネットワーク上のクラウド

接続された Horizon 7 からのデスクトップまたはサ

ーバ仮想マシンのクラウド

監視サービスエージェン

ト

Horizon 7 Cloud Connector アプライア

ンス

11002 TCP サーバまたはデスクトップ仮想

マシン上のクラウド監視サービ

スエージェントが Cloud Connector にデータを送信する

ために使用されます。

Horizon 7 Cloud Connector を使用して Horizon 7 ポッドと Horizon Cloud をペアリングす

るためのオンボーディングウィザードの実行準備

既存の Horizon 7 ポッドで Horizon サブスクリプションライセンスまたはクラウドホスト型サービスを使用する

目的でそのポッドを現在のサービスリリースレベルに接続するには、Horizon 7 Cloud Connector をデプロイする

前に、以下の項目を確認します。

n Horizon 7 Cloud Connector 仮想アプライアンスとペアリングするポッドの Connection Server インスタン

スを決定し、その Connection Server インスタンスの FQDN を確認する。一度に、Horizon 7 Cloud Connector 仮想アプライアンスを 1 つのみポッドのインストール済みの Connection Server インスタンスと

ペアリングできます。

n https://my.vmware.com に有効な My VMware アカウントを持っている。このアカウントは、Horizon 7 サブ

スクリプションライセンスを購入し、Horizon 7 Cloud Connector オンボーディングワークフローを実行して

ポッドをクラウドサービスとペアリングするため、また Horizon Cloud 管理コンソールにログインしてそのポ

ッドでクラウドホスト型サービスを使用するために必要です。

n Horizon 7 のサブスクリプションライセンスが My VMware アカウントに関連付けられている。


VMware, Inc. 34


n Horizon 7 Cloud Connector OVA をダウンロードするためのリンクなどの情報が My VMware アカウントに

関連付けられたメールアドレスに送信された「ようこそ」メールに記載されている。E メール情報がない場合

は、その My VMware アカウントを使用して my.vmware.com にログインし、アカウントについてリストされ

ている製品のダウンロードに移動して OVA をダウンロードできます。

n Microsoft Internet Explorer Web ブラウザを使用している場合は、互換モードが無効であることを確認します。

この設定により、その Web ブラウザで Horizon 7 Cloud Connector アプライアンスのオンボーディングユー

ザーインターフェイスが表示されます。

n Horizon 7 Cloud Connector と Horizon 7 ポッドを使用するときの DNS、ポート、およびプロトコルの要件を

満たしていることを確認する。

n Horizon 7 Cloud Connector 仮想アプライアンスに使用する固定 IP アドレスを決定する。この IP アドレス

は、Horizon 7 Cloud Connector OVA を vSphere にデプロイするときに必要になります。

注： Horizon 7 Cloud Connector 仮想アプライアンスで IPv6 を使用しないでください。IPv6 はサポートされ

ていません。

n DNS 検索ドメイン、DNS サーバの IP アドレス、デフォルトのゲートウェイアドレス、サブネットマスクなど、

vSphere 環境に Horizon 7 Cloud Connector OVA をデプロイするときに使用する、環境に適した一般的なネ

ットワーク情報があることを確認する。

重要： Horizon 7 Cloud Connector 仮想アプライアンスの自己署名証明書では、プロキシの SSL 設定を使用

できません。

n Horizon 7 ポッドで Horizon サブスクリプションライセンスを使用する最小のユースケースについて、上記の

記載に加えて、以下の前提条件を満たしていることを確認する。

n Horizon 7 Cloud Connector とペアリングする Connection Server インスタンスは、Horizon 7 バージョ

ン 7.6 以降を実行している必要がある。バージョン 7.6 は、クラウドサービスとペアリングできる最小バー

ジョンです。

ヒント: 技術的には、最新の Horizon 7 バージョンよりも古いバージョンを実行している Horizon 7 ポッ

ドをペアリングすることもできますが、クラウドでホストされる最新の機能をそのポッドで取得するために

は、Horizon 7 ポッドの Connection Server に最新バージョンの Horizon 7 を使用することを推奨します。

Horizon 7 と Horizon 7 Cloud Connector の最新バージョンの組み合わせを使用することによってのみ、

そのポッドでサブスクリプションライセンスを使用するだけでなく、クラウドでホストされる最新の機能に

もアクセスできます。

Horizon Cloud Service を既存の Horizon 7 ポッドと接続して、Horizon サブスクリプションライセンスまたはクラウドホスト型サービス、あるいはその両方を使用する

既存の Horizon 7 ポッドを Horizon Cloud Service に接続する場合は、複数の手順を実行します。VMware Horizon のサブスクリプションライセンスを購入すると、VMware からサブスクリプションライセンスのメールが

届きます。この E メールに、Horizon 7 Cloud Connector 仮想アプライアンスのダウンロードリンクが含まれてい

ます。次に、仮想アプライアンスをインストールしてパワーオンします。仮想アプライアンスがパワーオンされたら、

コネクタのオンボーディングワークフローを使用して、そのサブスクリプションライセンスを使用するポッド内の


VMware, Inc. 35

Connection Server とペアリングします。成功したペアリングプロセスの一部として、Horizon 7 Cloud Connector 仮想アプライアンスは Connection Server を Horizon Cloud Service にブリッジし、クラウド管理プ

レーンが Horizon サブスクリプションライセンス、および現在クラウド接続されているポッドの他のクラウドホス

ト型サービスを管理できるようにします。

仮想マシン

Connection Server

管理サービスシステムの健全性

Cloud Connector

Horizon 7 ポッド

クラウド監視サービス (CMS)

ライセンスサービス

Active Directory

Horizon Cloud 管理プレーン

Horizon API

ヒント: Horizon Cloud のオンボーディングプロセス全体の概要については、「Horizon Cloud for Microsoft Azure、Horizon 7 オンプレミス、および Horizon 7 on VMware Cloud on AWS へのオンボーディング」を参照し

てください。

これらの手順を使用して、オンプレミスでインストールされている、または VMware Cloud™ on AWS にインスト

ールされている既存の Horizon 7 環境をクラウド管理プレーンに接続します。ポッドを Horizon Cloud Service に接続すると、そのポッドでクラウドホスト型サービスを利用していない場合でも、そのポッドで Horizon サブスク

リプションライセンスを使用できます。Horizon サブスクリプションライセンスがある場合、Horizon 7 製品のア

クティベーションのための Horizon 7 ライセンスキーを手動で入力する必要はありません。ペアリングが完了する

と、通常ポッドをクラウド制御プレーンとペアリングしてから 48 時間以内に、VMware はサブスクリプションライ

センスをアクティブ化します。VMware がサブスクリプションライセンスをアクティブ化すると、Horizon 7 コン

ソールに Horizon 7 環境がサブスクリプションライセンスを使用しているというメッセージが表示されます。


VMware, Inc. 36

「Horizon Cloud for Microsoft Azure、Horizon 7 オンプレミス、および Horizon 7 on VMware Cloud on AWS へのオンボーディング」で説明するように、Horizon 7 ポッドを Horizon Cloud にオンボーディングするプロセス

には、次の基本概念が含まれます。

n Horizon サブスクリプションライセンスは、クラウド管理プレーン、すなわち Horizon Cloud から管理されま

す。

n そのため、Horizon 7 ポッドで Horizon サブスクリプションライセンスを使用する場合は、ポッドをそのクラ

ウド管理プレーンに接続する必要があります。Horizon 7 ポッドをクラウド管理プレーンに接続しないように

する場合、そのポッドで Horizon サブスクリプションライセンスを使用することはできません。

n 既存の Horizon 7 ポッドをクラウド管理プレーンに接続するには、Horizon 7 Cloud Connector という名前の

コネクタが必要です。クラウド管理プレーンはコネクタと通信し、コネクタはポッドの Connection Server インスタンスの 1 つと通信します。コネクタは、一度にポッドのインストール済みの Connection Server インス

タンスの 1 つのみとペアリングできます。

n Horizon 7 Cloud Connector は、クラウド管理プレーンと、それをペアリングするポッドの接続サーバインス

タンスの両方に到達する必要があるため、Horizon 7 Cloud Connector とポッドのペアリング、および継続的

な操作を成功させるために特定の Horizon 7 Cloud Connector と Horizon 7 ポッドを使用するときの DNS、

ポート、およびプロトコルの要件を満たす必要があります。ポッドでサブスクリプションライセンスを使用する

最小の使用事例でも、それらの DNS、ポート、およびプロトコルの要件を満たす必要があります。

n Horizon サブスクリプションライセンスを取得し、クラウド管理プレーンで認証してコネクタをセットアップ

し、ポッドでそのサブスクリプションライセンスを使用するための接続を確立するには、My VMware アカウン

トが必要です。

n Horizon 7 ポッドで Horizon サブスクリプションライセンスのみを使用することも、そのポッドでクラウドホスト型サービスを追加で使用することもできます。どの使用事例でも、Horizon サブスクリプションライセンス

が必要です。

n 最新の機能およびセキュリティとバグ修正を取得するには、Horizon 7 の最新バージョンと Horizon 7 Cloud Connector の最新バージョンの組み合わせを使用するのが最適です。バージョン 7.6 は Horizon 7 Cloud Connector を使用してクラウド管理プレーンから管理される Horizon サブスクリプションライセンスを使用

する機能を提供する最初の Horizon 7 バージョンでしたが、そのバージョンは 1 年以上経過しており、Horizon 7 バージョン 7.6 では、サブスクリプションライセンスの単純な使用を超える現在のクラウド管理サービスを利

用できません。Horizon 7 バージョンと Horizon 7 Cloud Connector バージョンの推奨される組み合わせに

ついては、Horizon Cloud Service のドキュメントページからリンクされている Horizon Cloud リリースノー

トを参照してください。

このプロセスの手順の概要は次のとおりです。

1 My VMware アカウントを取得します。

2 その My VMware アカウントを使用して、Horizon サブスクリプションライセンスにサインアップします。

3 ライセンスにサインアップすると、その My VMware アカウントに関連付けられているメールアドレスによう

こそ E メールが送信されます。ようこそ E メールには、適切な my.vmware.com ダウンロードエリアから

Horizon 7 Cloud Connector OVA をダウンロードするためのリンクが含まれています。

4 ようこそ E メールのリンクを使用して、Horizon 7 Cloud Connector OVA をダウンロードします。


VMware, Inc. 37

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/index.html

http://www.vmware.com/go/download-horizon-subscription

5 固定 IP アドレスを使用して、その OVA を Horizon 7 ポッドの vSphere 環境にデプロイします。仮想アプライ

アンスのデプロイプロセスが完了したら、仮想アプライアンスをパワーオンします。

6 パワーオンすると、アプライアンスの青いコンソール画面には、Horizon 7 Cloud Connector とポッド内の

Connection Server インスタンスをペアリングし、Connection Server インスタンス、Horizon 7 Cloud Connector、およびクラウド管理プレーン間の接続を完了するためのペアリングワークフローを開始するために

使用する URL アドレスが表示されます。

7 ブラウザでアプライアンスの青いコンソール画面に表示された URL アドレスを使用して、ペアリングワークフ

ローを開始します。Horizon Cloud からログイン画面が表示されるので、My VMware アカウントの認証情報を

使用してログインします。その時点でワークフローのユーザーインターフェイスがブラウザに表示されるので、

このトピックで説明する以下の手順を完了します。

重要：この Horizon 7 ポッドを接続している Horizon Cloud 環境にすでにクラウド接続ポッドがある場合は、そ

れらのクラウド接続ポッドすべてが同じ Active Directory ドメインのセットを認識できる必要があります。

Horizon 7 ポッドを接続する手順を実行するときは、Horizon 7 ポッドが、すでに Horizon Cloud 環境に登録され

ている Active Directory ドメインを認識できるようにする必要があります。

たとえば、環境にすでに Microsoft Azure のポッドがあり、Horizon 7 ポッドを接続している場合は、次のことを確

認する必要があります。

n 次の手順を使用して接続している Horizon 7 ポッドが、Microsoft Azure の既存のポッドで使用される Active Directory ドメインを認識できること（これらのドメインはすでに環境のクラウドプレーンに登録されているた

め）。

n Microsoft Azure の既存のクラウド接続ポッドが、Horizon 7 ポッドの Active Directory ドメイン（次の手順で

Horizon 7 Cloud Connector 仮想アプライアンスと Horizon 7 ポッドの Connection Server をペアリングす

るために使用しているドメイン）を認識できること。

前提条件

「Horizon 7 Cloud Connector を使用して Horizon 7 ポッドと Horizon Cloud をペアリングするためのオンボー

ディングウィザードの実行準備」に記載されているすべての項目を満たしていることを確認します。

Horizon 7 ポッドと Horizon Cloud をペアリングするために Horizon 7 Cloud Connector を使用する場合、

Horizon 7 Cloud Connector と Horizon 7 ポッドを使用するときの DNS、ポート、およびプロトコルの要件を満た

していることを確認します。

ネットワークトポロジ内の DNS 構成が、ポッドの Connection Server の FQDN を解決するために、デプロイされ

た Horizon 7 Cloud Connector を提供することを確認します。デプロイされた Horizon 7 Cloud Connector が

DNS を使用して Connection Server を解決できない場合、Horizon 7 ドメイン認証情報を入力するステップでオン

ボーディングウィザードに予期しないエラーが発生します。


VMware, Inc. 38

手順

1 前提条件リストに記載されているように、サブスクリプション E メールに記載されているリンクを使用して

Horizon 7 Cloud Connector アプライアンスをダウンロードします。

Horizon 7 Cloud Connector アプライアンスは OVA ファイルとして利用でき、My VMware アカウントの資

格情報を使用して my.vmware.com にログインすると、my.vmware.com にホームロケーションが表示されま

す。

重要：最新の機能を有効にするには、ダウンロードしたバージョンが最新のバージョン（バージョン 1.5 以降）

であることを確認します。以前に 1.5 より前のバージョンで Horizon 7 Cloud Connector OVA をダウンロー

ドした場合は、my.vmware.com にログインし、ポッドのペアリングに使用する最新バージョンを取得する必要

があります。

2 vSphere Web Client を使用して、OVF テンプレートとして Horizon 7 Cloud Connector アプライアンスを

Horizon ポッドにデプロイします。

OVF テンプレートのダウンロード方法の全般的な情報については、『vSphere 仮想マシン管理』を参照してくだ

さい。

重要：アプライアンスをデプロイする場合は、次の項目に注意してください。

n Flex ベースのユーザーインターフェイスである VMware vSphere® Web Client を使用する場合は、アプ

ライアンスをポッドにデプロイすると最適の結果を得られます。最新の HTML5 ベースのユーザーインタ

ーフェイスである VMware vSphere® Client™ を使用してデプロイすると、無効な値に関するエラーメッセ

ージが表示されることがあります。この問題は vSphere Client の既知の問題によって発生するものであっ

て、Horizon 7 Cloud Connector アプライアンスパッケージの問題ではありません。このエラーが発生し

た場合は、代わりに Flex ベースのユーザーインターフェイスを使用してアプライアンスをデプロイします。

n OVF テンプレートの root パスワードを入力するときに、大文字、数字、特殊文字をそれぞれ 1 個以上含む

8 文字以上のパスワードを使用する必要があります。

n 仮想アプライアンスに固定 IP アドレスを指定します。Horizon 7 Cloud Connector 仮想アプライアンス

で IPv6 を使用しないでください。IPv6 はサポートされていません。

n Horizon 7 Cloud Connector 仮想アプライアンスの自己署名証明書では、プロキシの SSL 設定を使用でき

ません。

3 「Horizon 7 Cloud Connector 1.4 以降のプロキシの設定」または「Horizon 7 Cloud Connector 1.3 以前のプ

ロキシの設定」の説明に従って、Horizon 7 Cloud Connector 仮想アプライアンスのプロキシ設定と非プロキ

シホストを構成します。

4 Horizon 7 Cloud Connector アプライアンスをパワーオンします。

5 アプライアンスが完全にパワーオンされたら、vSphere Web Client のオプションを使用して Horizon 7 Cloud Connector アプライアンスのコンソールを起動します。

Horizon 7 Cloud Connector アプライアンスの青いコンソール画面が表示されます。その青いコンソール画面

には、オンボーディングワークフローのためにブラウザに読み込む URL アドレスが表示されます。次のスクリ

ーンショットは、アドレス https://10.92.245.255/ を持つデプロイ済みアプライアンスの例です。


VMware, Inc. 39

http://my.vmware.com

http://www.vmware.com/go/download-horizon-subscription

6 OVA を vSphere にデプロイしたときに設定した root アカウントとパスワードを使用して、アプライアンスに

ログインします。

7 アプライアンスのオペレーティングシステムを終了して、表示された URL アドレスを確認します。

8 ブラウザを使用して、アプライアンスの青いコンソール画面に表示されるアドレスに移動します。

重要：このステップでは、Horizon 7 Cloud Connector が Horizon Cloud に接続してログイン画面を表示し

ます。これはクラウド制御プレーンで My VMware アカウントの認証情報を認証するために使用されます。こ

の接続は、ポート 443 を使用する送信 HTTPS です。ログイン画面が表示されない場合は、 Horizon 7 Cloud Connector と Horizon 7 ポッドを使用するときの DNS、ポート、およびプロトコルの要件を満たしていること

を確認します。

ログイン画面が表示されます。

9 ログイン画面で、My VMware アカウントの認証情報を入力し、[ログイン] をクリックします。

次のスクリーンショットは、[ログイン] をクリックする前に入力された認証情報を使用したログイン画面の例で

す。

サービス条件のメッセージが表示された場合は、[承認]をクリックして続行します。


VMware, Inc. 40

ポッドのオンボーディングウィザードの最初の手順が表示されます。次のスクリーンショットは、フィールドの

入力を完了する前のこの手順の例を示します。

10 [Horizon 7 Connection Server に接続] フィールドに、Horizon 7 Cloud Connector とペアリングするポッド

の Connection Server インスタンスの FQDN を入力します。

フィールドに入力すると、[接続] ボタンが表示されます。

11 FQDN を入力したら、[接続] をクリックします。

Horizon 7 Cloud Connector は、指定された Connection Server と通信し、その証明書情報を取得しようとし

ます。このプロセスには数分かかることがあります。通信が確立されると、ページには取得した証明書情報が表

示されます。

Connection Server に有効なルート CA 証明書がない場合、証明書を自動的に検証できないことを示す警告メッ

セージが表示されます。チェックボックスをクリックして、有効であることを確認する必要があります。次のス

クリーンショットは、この状況の例です。


VMware, Inc. 41

このメッセージが表示された場合は、表示された証明書情報が正確であることを確認し、チェックボックスをク

リックして次の手順に進みます。

注： Connection Server に有効なルート CA 証明書がある場合、ウィザードが自動的に情報を検証し、次の手

順に進むことができます。

次のスクリーンショットは、チェックボックスをクリックした後の画面を示します。

12 [Horizon 7 認証情報] セクションで、Connection Server が使用するドメイン名と管理者認証情報を入力し、

[接続] をクリックします。

次のスクリーンショットは、画面のこの領域を示しています。


VMware, Inc. 42

注：この時点で、システムは、指定した Connection Server インスタンスがすでに Horizon 7 Cloud Connector の別のインスタンスとペアリングされているかどうかを検出します。この場合、既存のペアリングを

削除し、この Connection Server と手順 4 で指定した Horizon 7 Cloud Connector インスタンスとのペアリ

ングを実行するメッセージと [同意する] ボタンがページに表示されます。

ウィザードの手順 2 が表示されます。

13 このウィザードの手順では、ポッドの詳細を指定します。

次のスクリーンショットは、この手順が完了した例です。

これらの詳細は、ペアリングされた Connection Server インスタンスと Horizon 7 Cloud Connector を

Horizon Cloud テナント環境に関連付けるためにクラウド管理プレーンで使用されます。たとえば、指定した名

前、場所、および説明が Horizon Cloud 管理コンソールに表示されるため、制御プレーンに接続されている他

のポッドからこのポッドを識別できます。

オプション説明

名前 Horizon Cloud テナント環境でこのポッドを識別するためのわかりやすい名前を入力します。

データセンターの場所このポッドを使用する既存の場所を選択するか、[新規] をクリックして新しい場所を指定しま

す。Horizon Cloud 管理コンソールでは、ポッドは指定した場所に従ってグループ化されて表

示されます。

[市区町村名] テキストボックスに、市区町村の名前を入力します。システムは自動的にバック

エンドの地理参照テーブルにある、入力した文字に一致する世界の市区町村名表示するので、

そのリストから市区町村を選択できます。

注：システムのオートコンプリートリストから市区町村を選択する必要があります。


VMware, Inc. 43


説明オプション：このポッドの説明を入力します。

VMware Cloud on AWS にデプロイされた

ポッド

ポッドが VMware Cloud on AWS の Software-Defined Data Center (SDDC) にデプロイ

されている場合は、このチェックボックスをオンにします。

14 [保存] をクリックして、次のウィザード手順に進みます。

ウィザードの構成手順が表示されます。システムは、指定した Connection Server インスタンスへの接続をチ

ェックし、最後の構成手順を完了します。次のスクリーンショットは、この手順の例です。

ポッドが Horizon Cloud 制御プレーンに正常に接続されたことをシステムが判断すると、正常な完了を示す画

面に、いくつかのガイダンステキストとアクションボタンが表示されます。次のスクリーンショットは、この

画面の例です。

注： Horizon 7 Cloud Connector の自動更新用に Horizon Cloud テナントアカウントが構成されている場合

は、[Cloud Connector の自動更新の構成] ボタンがここに表示されます。


VMware, Inc. 44

この時点で、ペアリングのワークフローが完了します。ポッドをクラウド制御プレーンとペアリングしてから通

常 48 時間以内に、VMware はサブスクリプションライセンスをアクティブ化します。VMware がサブスクリ

プションライセンスをアクティブ化すると、Horizon 7 Administrator コンソールに Horizon 7 環境がサブス

クリプションライセンスを使用しているというメッセージが表示されます。次のスクリーンショットは、図のサ

ンプルです。


VMware, Inc. 45

注： 48 時間経過しても、Horizon Console のライセンス領域に「ライセンスサービスに接続されました」と

いうメッセージが表示されない場合は、VMware の担当者にお問い合わせください。

注：ペアリングプロセスの後、Horizon 7 Cloud Connector が LDAP サーバに IP やサムプリントなどのエン

ドポイントの詳細を入力するまで最大 10 分かかります。

15 クラウドテナントアカウントで自動アップグレード機能が有効になっている場合は、[Cloud Connector の自

動更新の構成] をクリックし、機能に必要な設定を指定します。

この構成により、サービスを正常に実行するために必要な場合に Horizon Cloud が仮想アプライアンスでメン

テナンスアクションを実行できるようになります。

a vCenter Server の FQDN を入力して、[証明書の取得] をクリックします。証明書情報が表示されたら、[上の証明書を確認したので続行します] を選択します。

b [Horizon Cloud Connector vCenter Server 証明書] に、vCenter Server のユーザー名とパスワードを入

力します。

c [Cloud Connector アップグレードの追加の固定 IP アドレスの詳細] で、以前に収集した Horizon 7 Cloud Connector 仮想アプライアンスの固定 IP アドレス、ゲートウェイ、サブネットマスク、DNS 情報を入力

します。

d [保存] をクリックします。


VMware, Inc. 46

[Cloud Connector の自動更新の構成] に加え、Horizon 7 Cloud Connector のセットアップウィザードの最後の

ページにいくつかのアクションが表示されます。今後、これらのアクションを実行する場合は、説明した手順と同様

にお使いのブラウザを Horizon 7 Cloud Connector アプライアンスの IP アドレスにポイントし、ウィザードペー

ジからこれらのオプションにアクセスできます。DNS サーバで FQDN を IP アドレスにマッピングする正引きおよ

び逆引き参照レコードを作成した場合は、その FQDN を使用してウィザードページにアクセスできます。

n 同じポッドに Connection Server の詳細を再設定する場合は、[再構成] をクリックし、手順に従ってウィザー

ドを完了します。

n この Connection Server インスタンスと制御プレーン間の接続を削除する場合は、[接続解除] をクリックしま

す。

次のステップ

n Horizon 7 Cloud Connector 仮想アプライアンスの完全修飾ドメイン名 (FQDN) でホスト名を解決する場合

は、その FQDN を Horizon 7 Cloud Connector 仮想アプライアンスの固定 IP アドレスにマッピングする正引

き参照と逆引き参照のレコードを DNS サーバに作成します。

現在のクラウド接続ポッドで Horizon サブスクリプションライセンスを使用することが唯一の目標である場合、追

加の手順はありません。ただし、Horizon 7 Cloud Connector と Cloud 制御プレーン間の接続を維持するために、

DNS、ポート、およびプロトコルの要件が引き続き満たされていることを確認する必要があります。サブスクリプシ

ョンライセンスは Cloud 制御プレーンによって管理されるため、Horizon 7 Cloud Connector はサブスクリプショ

ンライセンス情報を受け取るためにポッドの Cloud 制御プレーンに引き続き到達できる必要があります。

重要： Horizon 7 Cloud Connector をインストールすると、インターネットの送信ポート 443 でクラウド制御プ

レーンへの接続が確立されます。これは常時接続されています。Cloud Connector とクラウド制御プレーン間でこ

の接続がオフラインになった場合は、このポッドと Horizon Cloud とのペアリングの確実な期限切れまで、デフォ

ルトで 10 日の猶予期間があります。この場合は、VMware サポートに問い合わせてください。

クラウドに接続されたポッドでクラウドホスト型サービスを利用するには、Horizon Cloud 管理コンソールにログ

インし、ポッドの Active Directory ドメインを Horizon Cloud に登録する Active Directory 登録ワークフローを完

了する必要があります。このワークフローの詳細については、『Horizon Cloud 管理ガイド』の「Horizon Cloud 環境での最初の Active Directory ドメイン登録の実行」を参照してください。

Horizon 7 Cloud Connector の既知の考慮事項

Horizon 7 Cloud Connector を使用している場合は、これらの考慮事項に留意してください。

n Horizon 7 Cloud Connector 仮想アプライアンスでの IPv6 の使用はサポートされていません。

n Horizon 7 Cloud Connector 仮想アプライアンスのデプロイ中は、プロキシの SSL 設定を使用できません。

n デプロイされた Horizon 7 Cloud Connector 仮想アプライアンスの固定 IP アドレスとプロキシの設定に関す

る情報は、特定のコンテナファイルに保存されます。仮想アプライアンスでこれらの設定を変更する場合は、仮

想アプライアンスに接続し、それらのコンテナファイルを編集する必要があります。vSphere 環境にデプロイ

された仮想アプライアンスの固定 IP アドレスを変更する場合、仮想アプライアンスのオペレーティングシステ

ムで適切なコンテナファイルを編集し、コマンドを実行して、仮想アプライアンスに依存するポッドのすべての

コンポーネントで新しい IP アドレスが共有されるようにする必要があります。Horizon 7 Cloud Connector 仮想アプライアンスの固定 IP アドレスの更新を参照してください。


VMware, Inc. 47



n vCenter Server 環境から Horizon 7 Cloud Connector 仮想アプライアンスを削除する前に、Horizon 7 Cloud Connector アプライアンスの IP アドレスにブラウザをポイントし、[接続解除] アクションを使用して、ポッド

と Horizon Cloud 間の接続を削除します。

n Horizon 7 ポッドとペアリングされた Horizon 7 Cloud Connector の個別の vdmadmin アカウントを使用す

るのがベストプラクティスです。個別の vdmadmin アカウントを使用すると、クラウド管理とオンプレミス管

理の間で構成が上書きされるのを回避できます。個別のアカウントを使用することで、クラウドベースの操作の

監査も容易になります。

n Horizon 7 Cloud Connector と Horizon Cloud 間の接続には、インターネットの送信ポート 443 を使用しま

す。コネクタに必要なすべての DNS、ポート、およびプロトコルについては、 Horizon 7 Cloud Connector と

Horizon 7 ポッドを使用するときの DNS、ポート、およびプロトコルの要件を参照してください。

n デプロイの際に、Horizon 7 Cloud Connector 仮想アプライアンスの root ユーザーのパスワードを設定しま

す。デフォルトでは、このパスワードに有効期限はありません。ただし、組織のセキュリティポリシーによって

は、root ユーザーに有効期限ポリシーを設定して root パスワードを定期的に更新することをお勧めします。手

順については、Horizon 7 Cloud Connector root ユーザーのパスワード有効期限ポリシーの設定を参照してく

ださい。

n 接続サーバが自己署名証明書を使用していて、ポッドを Horizon Cloud にペアリングした後に自己署名証明書

を置き換える場合は、Horizon 7 Cloud Connector インターフェイスにログインし、[再構成] ワークフローを

使用して新しい自己署名証明書で証明書の検証手順を再度実行する必要があります。Horizon 7 Cloud Connector インターフェイスにログインしたら、[再構成] をクリックしてウィザードの手順を完了し、接続サー

バからの新しい自己署名証明書を使用して通信を確認することができます。

n 接続サーバの IP アドレスを解決するために、/etc/hosts ファイルにエントリを追加した場合は、hze-core

サービスを再起動する必要があります。次のコマンドを使用します。

systemctl restart hze-core

Horizon 7 Cloud Connector 仮想アプライアンスの CA 署名付き証明書の構成

セキュリティを強化するために、Horizon 7 Cloud Connector 仮想アプライアンスのカスタム CA 署名付き証明書

を構成できます。

前提条件

n 完全な証明書チェーンが PEM 形式で使用できることを確認します。

n プライベートキーが PEM 形式で使用できることを確認します。

n 発行された証明書に FQDN と Subject Alt Name が含まれていることを確認します。

手順

1 デプロイされた Horizon 7 Cloud Connector 仮想アプライアンスへの SSH セッションを開きます。

2 ディレクトリ /root/server.crt に CA 署名付き証明書をコピーします。

3 ディレクトリ /root/server.key に CA 署名キーをコピーします。


VMware, Inc. 48

4 既存の証明書をバックアップします。

n バージョン 1.4 以降の Horizon 7 Cloud Connector では、次のコマンドを使用します。

cp /opt/container-data/certs/hze-nginx/server.crt /opt/container-data/certs/hze-nginx/

server.crt.orig

n バージョン 1.3 以前の Horizon 7 Cloud Connector では、次のコマンドを使用します。

cp /etc/nginx/ssl/server.crt /etc/nginx/ssl/server.crt.orig

5 既存のキーをバックアップします。


cp /opt/container-data/certs/hze-nginx/server.key /opt/container-data/certs/hze-nginx/

server.key.orig


cp /etc/nginx/ssl/server.key /etc/nginx/ssl/server.key.orig

6 既存の nginx conf ファイルをコピーします。


cp /opt/container-data/conf/hze-nginx/nginx.conf /opt/container-data/conf/hze-nginx/

nginx.conf.orig


cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.orig

7 お使いの仮想アプライアンスのバージョンに適したディレクトリに CA 証明書をコピーします。


cp /root/server.crt /opt/container-data/certs/hze-nginx/server.crt


cp /root/server.crt /etc/nginx/ssl/server.crt

8 お使いの仮想アプライアンスのバージョンに適したディレクトリに CA 証明書のキーファイルをコピーします。


cp /root/server.key /opt/container-data/certs/hze-nginx/server.key


cp /root/server.key /etc/nginx/ssl/server.key


VMware, Inc. 49

9 証明書とキーファイルの所有者と権限を確認します。


chown -R hze-nginx:hze-nginx /opt/container-data/certs/hze-nginx

chmod 644 /opt/container-data/certs/hze-nginx/server.crt

chmod 600 /opt/container-data/certs/hze-nginx/server.key


chown -R root:root /etc/nginx/ssl

chmod -R 600 /etc/nginx/ssl

10 証明書内の発行された FQDN が、nginx の構成ファイルにあるサーバリスン 443 ブロックのサーバ名ディレク

ティブと一致することを確認します。

n バージョン 1.4 以降の Horizon 7 Cloud Connector では、nginx の構成ファイルは /opt/container-

data/conf/hze-nginx/nginx.conf にあります。

n バージョン 1.3 以前の Horizon 7 Cloud Connector では、nginx の構成ファイルは /etc/nginx/

nginx.conf にあります。

11 nginx を確認して再起動します。


docker exec -i hze-nginx sudo nginx -t

systemctl restart hze-nginx


nginx -t

systemctl restart nginx

12 バージョン 1.4 以降の Horizon 7 Cloud Connector では、[ようこそ] 画面で SSL サムプリントを更新します。

次のコマンドを使用します。

docker exec -i hze-core sudo /opt/vmware/bin/configure-welcome-screen.py

/usr/bin/killall --quiet vami_login

13 新しい証明書をテストするには、Web ブラウザで Horizon 7 Cloud Connector ユーザーインターフェイスの

URL を再ロードします。

14 （オプション）証明書が正常に動作する場合は、バックアップファイルを削除します。


rm /opt/container-data/certs/hze-nginx/server.crt.orig

rm /opt/container-data/certs/hze-nginx/server.key.orig

rm /opt/container-data/conf/hze-nginx/nginx.conf.orig


VMware, Inc. 50


rm /etc/nginx/ssl/server.crt.orig

rm /etc/nginx/ssl/server.key.orig

rm /etc/nginx/nginx.conf.orig

15 ルートディレクトリにコピーした CA 証明書とキーファイルを削除します。

次のコマンドを使用します。

rm /root/server.crt

rm /root/server.key

Horizon 7 Cloud Connector 仮想アプライアンスの固定 IP アドレスの更新

Horizon 7 Cloud Connector 仮想アプライアンスの固定 IP アドレスに関する情報は、デプロイされた仮想アプライ

アンスのコンテナファイルに保存されます。Horizon 7 Cloud Connector 仮想アプライアンスの固定 IP アドレス

を更新する場合は、別の操作も必要になります。コンテナ設定ファイルを手動で再設定してから、ペアリングされて

いる Horizon 7 ポッドに関連するすべてのデスクトップに新しい固定 IP アドレスの情報を送信する必要がありま

す。

固定 IP アドレスが格納され

る場所

デプロイされた Horizon 7 Cloud Connector 仮想アプライアンスの固定 IP アド

レスは、-/opt/container-data/cc-settings/ip.conf ファイルに保存さ

れ、アプライアンス内で実行されるコンテナと共有されます。

たとえば、固定 IP アドレスの情報は次のようにファイルに保存されます。

cc.address=10.117.163.20

プロキシ設定が保存される

場所

Horizon 7 Cloud Connector 仮想アプライアンスのプロキシ設定は、-/opt/

container-data/cc-settings/proxy.conf に保存され、アプライアンス内

で実行されるコンテナと共有されます。

たとえば、プロキシ情報は次のようにファイルに保存されます。

proxyHost=null

proxyPort=0

proxySsl=false

proxyUsername=null

proxyPassword=

noProxyFor=null

前提条件

Horizon 7 Cloud Connector 仮想アプライアンスの新しい固定 IP アドレスを設定し、アプライアンスを Active Directory に参加させます。


VMware, Inc. 51

手順

1 次の例のように、-/opt/container-data/cc-settings/ip.conf ファイルの cc.address 行を編集しま

す。

cc.address=[新しい固定 IP アドレス]

2 実行中のすべての Horizon 7 デスクトップに新しい固定 IP アドレスを送信するには、次のコマンドを実行しま

す。

docker exec csms /bin/bash -c "cd /usr/local/csms; ./scripts/address_changed.sh"

Horizon 7 Cloud Connector 1.4 以降のプロキシの設定

このトピックでは、Horizon 7 Cloud Connector 1.4 以降のプロキシ設定および非プロキシホストを構成する方法

について説明します。

このトピックで説明する手順を使用して、プロキシ設定および非プロキシホストを次のタイミングで構成する必要が

あります。

n Horizon 7 Cloud Connector 仮想アプライアンスをデプロイするとき

n Horizon 7 Cloud Connector のデプロイ後にプロキシ設定または非プロキシホストを変更するとき

n （非プロキシホストの場合）Horizon 7 Cloud Connector を以降のバージョンにアップグレードした後

手順

1 デプロイされた Horizon 7 Cloud Connector 仮想アプライアンスへの Secure Shell (SSH) セッションを開き

ます。

2 プロキシ設定を指定します。

a /opt/container-data/cc-settings/proxy.conf を開き、該当する行でプロキシ情報を指定しま

す。次のサンプル構成を参考にしてください。

proxyHost=<host_IP>

proxyPort=<port_number>

proxySsl=false

proxyUsername=<user_name>

proxyPassword=<pwd>

noProxyFor=null

b /opt/container-data/data/hze-core/properties/hydra.properties を開き、該当する行で

プロキシ情報を指定します。次のサンプル構成を参考にしてください。

hydra.adapter.proxy.host=<host_IP>

hydra.adapter.proxy.port=<port_number>

hydra.adapter.proxy.username=<user_name>

hydra.adapter.proxy.password=<pwd>


VMware, Inc. 52

c /opt/container-data/data/hze-ccc/config/ccc-core/sn.config を開き、プロキシデータを

JSON 形式でファイルに追加します。次のサンプル構成を参考にしてください。

“proxyPort” : <port_number>,

“proxyPassword” : "<pwd>",

“proxyHost” : “<host_IP>",

“proxySSLConfig” : {

“enabled” : “false”,

“supportedCiphers” : [ “TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",

“TLS_RSA_WITH_AES_128_CBC_SHA256” ],

“supportedProtocols” : [ “TLSv1.2” ]

},

“proxyUsername” : "<user_name> "

注：プロキシデータを新しいエントリとしてファイルに追加します。既存の <name> : <value> のペア

は置き換えないでください。

d hze-ccc サービスを再起動します。

systemctl restart hze-ccc


VMware, Inc. 53

3 非プロキシホストを構成します。

a /etc/systemd/system/hze-core.service ファイルのバックアップコピーを保存します。

b オリジナルの hze-core.service ファイルを開いて編集します。

vi /etc/systemd/system/hze-core.service

c プロパティ Environment="CATALINA_OPTS= を検索します。プロパティの末尾に -

Dhttp.nonProxyHosts="localhost|<HostNoProxy>" の行を追加します。ここで、<HostNoProxy> は、

Horizon 7 Cloud Connector 仮想アプライアンスに対して構成する非プロキシホストの完全修飾ドメイン

名 (FQDN) です。

たとえば、host-a.noproxy.example.com が非プロキシホストの FQDN である場合は、プロパティを次の

ように変更します。

Environment="CATALINA_OPTS= ...

...

-Dhttp.nonProxyHosts="localhost|host-a.noproxy.example.com"

注：複数の非プロキシホストがある場合は、* を使用してワイルドカードエントリを指定できます。次の

例は、noproxy.example.com ドメイン内のホストのワイルドカードエントリを示しています。

Environment="CATALINA_OPTS= ...

...

-Dhttp.nonProxyHosts="localhost|*.noproxy.example.com"

a デーモンを再ロードします。

systemctl daemon-reload

b hze.core サービスを再起動します。

systemctl restart hze-core

c hze.core サービスが起動シーケンスを完了するまで 1 分間待機します。

d 実行中のコンテナのリストを表示して、hze.core サービスが起動していることを確認します。

docker ps

出力に hze.core が含まれていることを確認します。

Horizon 7 Cloud Connector 仮想アプライアンスのプロキシ設定は、-/opt/container-data/cc-settings/

proxy.conf に保存され、アプライアンス内で実行されるコンテナと共有されます。

次のステップ


ラウドホスト型サービス、あるいはその両方を使用するに記載されている手順を続行して、Horizon 7 Cloud Connector 仮想アプライアンスと Connection Server インスタンスをペアリングします。


VMware, Inc. 54

Horizon 7 Cloud Connector 1.3 以前のプロキシの設定

このトピックでは、Horizon 7 Cloud Connector 1.3 以前のプロキシ設定および非プロキシホストを構成する方法

について説明します。

このトピックで説明する手順を使用して、プロキシ設定および非プロキシホストを次のタイミングで構成する必要が

あります。

n Horizon 7 Cloud Connector 仮想アプライアンスをデプロイするとき

n Horizon 7 Cloud Connector のデプロイ後にプロキシ設定または非プロキシホストを変更するとき

n （非プロキシホストの場合）Horizon 7 Cloud Connector を以降のバージョンにアップグレードした後

手順

1 デプロイされた Horizon 7 Cloud Connector 仮想アプライアンスへの Secure Shell (SSH) セッションを開き

ます。

2 プロキシ設定を指定します。

a /opt/vmware/var/lib/tomcat8/properties/hydra.properties を開き、該当する行でプロキシ

情報を指定します。次のサンプル構成を参考にしてください。

hydra.adapter.proxy.host=<host_IP>

hydra.adapter.proxy.port=<port_number>

hydra.adapter.proxy.username=<user_name>

hydra.adapter.proxy.password=<pwd>

b /opt/vmware/var/lib/tomcat8/properties/sn.config を開き、プロキシデータを JSON 形式で

ファイルに追加します。次のサンプル構成を参考にしてください。

“proxyPort” : <port_number>,

“proxyPassword” : "<pwd>",

“proxyHost” : “<host_IP>",

“proxySSLConfig” : {

“enabled” : “false”,

“supportedCiphers” : [ “TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",

“TLS_RSA_WITH_AES_128_CBC_SHA256” ],

“supportedProtocols” : [ “TLSv1.2” ]

},

“proxyUsername” : "<user_name> "

注：プロキシデータを新しいエントリとしてファイルに追加します。既存の <name> : <value> のペア

は置き換えないでください。

c tomcat8 サービスを再起動します。

systemctl restart tomcat8


VMware, Inc. 55

3 非プロキシホストを構成します。

a /etc/systemd/system/tomcat8.service ファイルのバックアップコピーを保存します。

b 元の /etc/systemd/system/tomcat8.service ファイルを開いて編集します。

c プロパティ Environment='JAVA_OPTS=-Djava.awt.headless=true' を検索します。プロパティの末尾

に -Dhttp.nonProxyHosts="localhost|<HostNoProxy>" を追加します。ここで、<HostNoProxy> は、

Horizon 7 Cloud Connector 仮想アプライアンスに対して構成する非プロキシホストの完全修飾ドメイン

名 (FQDN) です。

たとえば、host-a.noproxy.example.com が非プロキシホストの FQDN である場合は、プロパティを次の

ように変更します。

Environment='JAVA_OPTS=-Djava.awt.headless=true'

-Dhttp.nonProxyHosts="localhost|host-a.noproxy.example.com"

d デーモンを再ロードします。

systemctl daemon-reload

e tomcat8 サービスを再起動します。

systemctl restart tomcat8

次のステップ


ラウドホスト型サービス、あるいはその両方を使用するに記載されている手順を続行して、Horizon 7 Cloud Connector 仮想アプライアンスと Connection Server インスタンスをペアリングします。

Horizon 7 Cloud Connector root ユーザーのパスワード有効期限ポリシーの設定

Horizon 7 Cloud Connector OVA を vSphere 環境にデプロイする場合、デプロイプロセスで root ユーザーのパ

スワードを設定する必要があります。デフォルトでは、このパスワードに有効期限はありません。ただし、ユーザー

のセキュリティポリシーによっては、root ユーザーに有効期限ポリシーを設定し、root パスワードを定期的に更新

する必要があります。

注： Horizon 7 Cloud Connector 仮想アプライアンスにログインした後に、root ユーザーとしてすべてのコマン

ドを入力する必要があります。パスワード有効期限ポリシーを独自に設定している場合、管理者が定期的にログイン

し、有効期限が切れる前にパスワードを更新する必要があります。Horizon 7 Cloud Connector 仮想アプライアン

スは、パスワードの有効期限を管理者に通知しません。

手順

1 root ユーザーのパスワード有効期限ポリシーを設定をするには、次のコマンドを入力します。

chage -M <Max days before password change> -W <Number of days of warning before password expires>

root


VMware, Inc. 56

たとえば、パスワードを変更してから 365 日後にパスワードを期限切れにし、パスワードの有効期限の 30 日前

から警告を表示するようにするには、次のコマンドを入力します。

chage -M 365 -W 30 root

2 root ユーザーの現在のパスワード有効期限ポリシーを表示するには、次のコマンドを入力します。

chage -l root

最初のポッドデプロイに対して Microsoft Azure クラウドキャパシ

ティを選択する場合

Horizon Cloud を Microsoft Azure サブスクリプションに接続して、Microsoft Windows 10 VDI デスクトップと、

セッションベースのデスクトップおよびリモートアプリケーション用の仮想 RDS 対応の Windows サーバの管理と

配布を行います。必要な VMware ソフトウェアを Microsoft Azure のキャパシティにデプロイし、環境を設定しま

す。デプロイした VMware ソフトウェアがポッドというエンティティを作成し、適切に構成します。このエンティ

ティが制御プレーンとペアリングされます。このポッドがデプロイされたら、制御プレーンを使用して VDI デスクト

ップと RDS 対応のサーバをプロビジョニングして、デスクトップとリモートアプリケーションへのアクセスをエン

ドユーザーに付与します。

Microsoft Azure でのポッドのデプロイ

Microsoft Azure に Horizon Cloud によってデプロイされたポッドには、Microsoft Azure クラウド内に物理的な

配置場所があります。ポッドデプロイウィザードで、Microsoft Azure サブスクリプションで使用可能なリージョ

ンに基づいてポッドの配置場所を選択します。選択したリージョンでポッドが使用する既存の仮想ネットワーク

(VNet) も選択します。ポッドで外部ゲートウェイ構成をデプロイするオプションがあります。このオプションでは、

その外部ゲートウェイのリソースをポッドと同じ VNet にデプロイするか、ポッドの VNet とピアリングされる別の

VNet にデプロイします。

注：ポッドの VNet（およびその構成オプションを使用する場合は外部ゲートウェイ VNet）を使用して、Microsoft Azure 環境を事前に構成します。ポッドと外部ゲートウェイの構成に必要なサブネットを事前に作成するか、デプロ

イ中にポッドデプロイヤによってサブネットを作成することができます。事前にサブネットを作成しない場合は、ポ

ッドデプロイヤが環境内で必要な仮想マシンとリソースをデプロイすると同時にサブネットを作成します。ポッド

デプロイヤによって必要なサブネットを作成するよう選択した場合、デプロイウィザードを開始する前に、ポッドの

サブネットに使用する IP アドレス空間を把握しておく必要があります。サブネットを事前に作成することを選択し

た場合は、デプロイプロセスを開始する前にサブネットが特定の要件を満たしていることを確認する必要がありま

す。事前にサブネットを作成するときの要件の詳細については、ポッドのデプロイの前に、Microsoft Azure の VNet で Horizon Cloud ポッドに必要なサブネットを作成するおよび Microsoft Azure で Horizon Cloud ポッド用の既

存のサブネットを使用する場合を参照してください。


VMware, Inc. 57

2 台以上のポッドを Microsoft Azure にデプロイした場合には、Horizon Cloud 管理コンソールでノードを一元管

理できます。最初のポッドの後にデプロイするポッドは、最初のポッドと同じ VNet を再利用することも、別の VNet を使用することもできます。また、各ポッドは別の Microsoft Azure リージョンに配置することもできます。この場

合は、各リージョンの VNet を使用します。

重要： Microsoft Azure では、このポッドはテナントではありません。このポッドの特性は、テナントを定義する

特性や、ユーザーがテナントに対して期待する特性とまったく同じものにはなり得ません。たとえば、テナントが

Active Directory ドメインに対して 1 対 1 でマッピングされていて、他のテナントから分離されている場合でも、同

じ Horizon Cloud 顧客アカウントレコードを使用して展開されている Microsoft Azure 内のすべての Horizon Cloud ポッドは同じ Active Directory サーバにアクセスできる必要があるとともに、DNS 構成でこれらのすべての

Active Directory ドメインを解決する必要があります。

マルチテナント状態を実行するには、複数の Horizon Cloud 顧客アカウントレコードを設定します。Horizon Cloud サービスを使用するために VMware で登録を行ったときに作成され、My VMware 認証情報に関連付けられ

る Horizon Cloud 顧客アカウントレコードは、よりテナントに近いものになります。Horizon Cloud 顧客アカウン

トレコードは、他の Horizon Cloud 顧客アカウントレコードから分離されます。1 つの顧客アカウントレコードは

複数のポッドにマップされます。また、誰かが管理コンソールにログインするためにその顧客アカウントレコードに

関連付けられたいずれかのアカウント認証情報を使用するときに、その顧客アカウントレコードにマッピングされて

いるすべてのポッドがコンソールで反映されます。

ポッドのデプロイプロセスで、一連のリソースグループが Microsoft Azure キャパシティに自動的に作成されます。

リソースグループは、環境が必要として作成する次のような資産の整理に使用します。

n ポッドのマネージャインスタンスの仮想マシン（高可用性が有効になっているポッドの場合は複数の仮想マシ

ン）

n Unified Access Gateway インスタンスとそのロードバランサの仮想マシン

n ポッドの VNet とは別の VNet に外部ゲートウェイ構成をデプロイする場合の、その構成のコネクタ仮想マシン

の仮想マシン

n マスター RDS が有効なサーバイメージの仮想マシン

n マスター VDI デスクトップイメージの仮想マシン

n マスターイメージから作成された割り当て可能な（公開済み）イメージの仮想マシン

n RDSH デスクトップとリモートアプリケーションを提供する RDSH ファームの仮想マシン

n VDI デスクトップの仮想マシン

n ネットワークインターフェイス、IP アドレス、ディスク、キーコンテナ、Microsoft Azure Database for PostgreSQL サーバリソースなど、サポートされている操作のために仮想マシンおよび環境で必要となる追加の

アセット、およびそれらに関連するさまざまなアイテム。ポッドのデプロイプロセスは、デプロイウィザード

で指定する値を使用して、必要な仮想サブネットを作成することもできます。

次の図は、高可用性が有効で、外部と内部の両方のタイプのゲートウェイ構成があり、外部ゲートウェイがポッド自

身と同じ VNet に存在するデプロイされたポッドを示しています。この図では、RG はリソースグループを意味しま

す。外部ゲートウェイ構成の Unified Access Gateway インスタンスは、非武装地帯 (DMZ) ネットワーク上に NIC があります。外部ゲートウェイ構成を使用すると、インターネットや企業ネットワーク外部のエンドユーザーは、そ

の構成を介してポッドがプロビジョニングされた仮想デスクトップおよびアプリケーションにアクセスできます。内


VMware, Inc. 58

部ゲートウェイ構成を使用すると、イントラネットや企業ネットワーク内部のエンドユーザーは、そのゲートウェイ

を介してポッドがプロビジョニングされた仮想デスクトップおよびアプリケーションとの間で信頼された接続を確立

できます。ポッドデプロイウィザードは、両方の構成を事前に使用してポッドをデプロイするオプションを提供し

ます。または、ポッドを 1 つのゲートウェイ構成のみでデプロイするか、まったく構成せずにデプロイし、デプロイ

されたポッドを後で編集して、選択されていないゲートウェイ構成を追加できます。

また、デプロイウィザードで高可用性オプションを有効にしないことを選択し、デプロイされたポッドを後で編集し

て高可用性を有効にすることもできます。このリリース以降、ウィザードで高可用性オプションを有効にしていない

場合でも、新しいポッドは常に Microsoft Azure Database for PostgreSQL サーバリソースおよびポッドのロード

バランサとともにデプロイされます。これらのリソースを利用できるようにすると、デプロイ済みのポッドで高可用

性を有効にできます。2 番目のポッドマネージャ仮想マシンは、ポッドで高可用性が有効になっている場合にのみデ

プロイされます。詳細については、『管理ガイド』の Microsoft Azure での高可用性と Horizon Cloud ポッドのドキ

ュメントトピックを参照してください。


VMware, Inc. 59

https://docs.microsoft.com/en-us/azure/postgresql/overview

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-1DAA5671-5928-47C0-BDAE-E3353A90115D.html

図 2-1. 高可用性が有効で、外部ゲートウェイと内部ゲートウェイの両方の構成が設定され、ポッドと同じ VNet に外

部ゲートウェイがデプロイされ、外部ゲートウェイのロードバランサでパブリック IP アドレスが有効になっている

ポッドの Horizon Cloud Pod アーキテクチャの図

仮想マシン

仮想マシン

仮想マシン

仮想マシン

仮想マシン

仮想マシン

仮想マシン

仮想マシン

管理ネットワーク

管理者Horizon Cloud制御プレーンインターネット

外部ユーザー

内部ユーザー

ゲートウェイ VPN または

ExpressRoute


PostgresDB

ベース仮想マシン

公開済イメージ

RG: vmw-hcs-<podID>-pool-1001

RG: vmw-hcs-<podID>-pool-100n

RG: vmw-hcs- <podID>-base-vms

RG: vmw-hcs-<podID>-jumpbox


NIC/IP アドレス

RG: vmw-hcs-<podID>


マネージャ 1


マネージャ 2

DMZ ネットワーク

パブリック IP アドレス


Gateway 1


Gateway 2


Gateway 1


Gateway 2


RG: vmw-hcs-<podID>-uag

RG: vmw-hcs-<podID>-uag-internal

テナントネットワーク

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

Microsoft Azure 内部ロードバランサ

IPsec トンネルを備えた 2 VPN ゲートウェイ

外部ネットワークに接続




VMware, Inc. 60

次の図は、外部ゲートウェイをポッドの VNet とは別の専用の VNet に配置するオプションを選択したときにデプロ

イされるリソースを示しています。2 つの VNet をピアリングする必要があります。この図は、ポッドで使用される

ものとは異なる Microsoft Azure サブスクリプションを使用して外部ゲートウェイのリソースをデプロイするオプ

ションを選択した場合にも適用されます。VNet は複数のサブスクリプションにまたがることはできないため、外部

ゲートウェイを専用のサブスクリプションにデプロイすることは、外部ゲートウェイを専用の VNet に配置するよう

に選択することの一部です。

ヒント: 外部ゲートウェイ構成を専用の VNet にデプロイすると、これらの Horizon Cloud ポッドを、Microsoft Azure のハブ - スポークネットワークトポロジを使用する複雑な Microsoft Azure 環境にデプロイできます。

図 2-2. 外部ゲートウェイがポッドの VNet とは別の専用の VNet にデプロイされている場合の外部ゲートウェイの

アーキテクチャ要素の図

VNet-2 の管理サブネット

管理者インターネットHorizon Cloud制御プレーン

外部ユーザー


一時ジャンプボックスの RG

NIC/IP アドレス

仮想マシン：コネクタ

外部ゲートウェイコネクタ

仮想マシンの RG

外部ゲートウェイリソースの RG

NIC/IP アドレス

VNet-2 の DMZ （フロントエンド）サブネット

VNet-2



ロードバランサの IP アドレス

VNet-2 のバックエンドサブネット

NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス


NIC/IP アドレス

NIC/IP アドレス

NIC/IP アドレス

Microsoft Azure の専門用語とリファレンス

VMware Horizon Cloud Service on Microsoft Azure 製品のドキュメントでは、必要に応じて VMware Horizon Cloud Service on Microsoft Azure ワークフローの説明とタスクの手順に Microsoft Azure の専門用語が使用され

ています。Microsoft Azure の専門用語に慣れていない場合は、以下の Microsoft Azure 製品ドキュメントに関連す

るリファレンスを参照してください。

注：以下の表記に含まれる大文字と小文字の区別およびスペルは、すべて Microsoft Azure ドキュメント自身のリ

ンク先の記事に合わせてあります。


VMware, Inc. 61

https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/hub-spoke


有用な Microsoft Azure のリファレンス説明

Microsoft Azure glossary: A dictionary of cloud terminology on the Azure platform

（Microsoft Azure 用語集：Azure プラットフォ

ームに関するクラウド用語の辞書）

この用語集には、たとえばロードバランサ、リージョン、リソースグループ、サブスクリプショ

ン、仮想マシン、仮想ネットワーク (vnet) など、Microsoft Azure クラウドのコンテキストで使

用される用語が含まれています。

注： Microsoft Azure 用語集には「サービスプリンシパル」という用語は含まれていません。サ

ービスプリンシパルは、アプリケーション登録が Microsoft Azure で作成されるときに

Microsoft Azure で自動的に作成されるリソースであるためです。Microsoft Azure サブスクリ

プションでアプリケーション登録を作成する理由は、Microsoft Azure キャパシティを使用するた

めに Horizon Cloud をアプリケーションとして承認することです。アプリケーション登録とその

コンパニオンサービスプリンシパルによって、アプリケーションとして動作する Horizon Cloud クラウドサービスは Microsoft Azure サブスクリプションのリソースにアクセスできるようにな

ります。Microsoft Azure のリソースにアクセスできるアプリケーションとサービスプリンシパ

ルについては、以下のリファレンスを参照してください。

Use portal to create an Azure Active Directory application and service principal that can access resources（ポータルを利用し

てリソースにアクセスできる Azure Active Directory アプリケーションとサービスプリン

シパルを作成する）

この記事では、Microsoft Azure クラウドのアプリケーションとサービスプリンシパルの関係に

ついて説明しています。

Azure Resource Manager overview（Azure Resource Manager の概要）

この記事では、Microsoft Azure のリソース、リソースグループ、およびリソースマネージャの

関係について説明しています。

Azure VNet この記事では、Microsoft Azure の Azure 仮想ネットワーク (VNet) サービスについて説明してい

ます。Azure Virtual Network FAQs（Azure 仮想ネットワークに関する FAQ）も参照してくだ

さい。

Azure VNet Peering（Azure VNet ピアリン

グ）

この記事では、Microsoft Azure での仮想ネットワークピアリングについて説明しています。

Azure のハブ - スポークネットワークトポロ

ジ

この記事では、Microsoft Azure でのハブ - スポークネットワークトポロジについて説明してい

ます。

Microsoft Azure ExpressRoute の概要この記事では、Microsoft Azure ExpressRoute について、およびオンプレミスネットワーク、

Microsoft Azure、および Horizon Cloud ポッド間の接続を確立するために Microsoft Azure ExpressRoute を使用する方法について説明します。

VPN ゲートウェイについて

VPN ゲートウェイの計画および設計

Azure ポータルでのサイト間の接続の作成

これらの記事では、Microsoft Azure で VPN を構成する方法について説明します。

Azure Load Balancer の概要この記事では、ポッド用にデプロイされた Azure ロードバランサについて、すなわちポッドマネ

ージャ仮想マシンのロードバランサとゲートウェイ構成のロードバランサについて説明します。

Azure Database for PostgreSQL の概要この記事では、Microsoft Azure Database for PostgreSQL サービスについて説明します。

その他の VMware リソース

次のリソースは、サービスに関する技術的な詳細情報を提供します。


VMware, Inc. 62

https://docs.microsoft.com/en-us/azure/azure-glossary-cloud-terminology




https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-create-service-principal-portal









https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-faq





https://docs.microsoft.com/en-us/azure/expressroute/expressroute-introduction

https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpngateways

https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-plan-design

https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-site-to-site-resource-manager-portal

https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview

https://docs.microsoft.com/en-us/azure/postgresql/

その他の VMware の技術的なリソース説明

要件チェックリストこのチェックリストを使用して、ポッドのデプロイプロセスを開始する前に取得および構成する

必要があるアセットについて確認します。

VMware Horizon Cloud を使用した

Microsoft Azure でのネットワークおよび

Active Directory についての考慮事項

この記事では、ネットワーク接続および Microsoft Azure 内の Horizon Cloud ポッドと

Microsoft Active Directory を使用するためのさまざまなオプションとベストプラクティスにつ

いて説明します。

Horizon Cloud Service on Microsoft Azure のセキュリティについての考慮事項

この記事では、環境のセキュリティ詳細に関する情報と、保存されたデータのタイプに関する情報

が提供されます。

Horizon Cloud on Microsoft Azure：RDS デスクトップおよびアプリのスケーラビリティ（ホ

ワイトペーパーのダウンロード）

この記事では、ファームのデプロイと電源管理設定に関連するコストの考慮事項とともに、RDS デスクトップとリモートアプリケーションのスケーラビリティおよび最適なユーザー密度につい

ての分析からの洞察を得ることができます。

クラウド接続された最初のポッドが Microsoft Azure へのデプロイから作成された場合の概要レベルのワークフロー

これは、ポッドを Microsoft Azure のキャパシティにデプロイすることによって、最初にクラウド接続されたポッド

を作成するための、Horizon Cloud のウィザードを使用する手順の高レベルリストです。最初のクラウド接続ポッド

が完全にデプロイされ、ポッドの目的である Active Directory ドメインに Horizon Cloud を登録するための手順を

完了すると、Horizon Cloud に提供されるすべての機能、特に VDI デスクトップのプロビジョニング、RDSH セッ

ションベースデスクトップ、または RDSH ベースのリモートアプリケーションを、そのポッドからエンドユーザー

に対して使用できます。

最初のクラウド接続ポッドをデプロイし、ウィザードを使用して Microsoft Azure にデプロイする場合は、次の手順

を実行します。

1 前提条件に従って準備します。VMware Horizon Cloud Service on Microsoft Azure 要件チェックリスト - 2019 年 12 月のサービスリリースで使用を参照してください。を参照してください。

2 Horizon Cloud 以外の準備タスクを実行します。Horizon Cloud ポッドを Microsoft Azure にデプロイする前

の準備を参照してください。

3 ポッドをデプロイするための DNS、ポート、およびプロトコルの要件を満たしていることを確認します。

Microsoft Azure での Horizon Cloud ポッドの DNS の要件および 2019 年 9 月のリリースのマニフェスト以

降の Horizon Cloud ポッドのポートとプロトコルの要件を参照してください。

4 ポッドをデプロイします。Microsoft Azure への Horizon Cloud ポッドのデプロイを参照してください。

5 デプロイ済みのポッドで Active Directory ドメインを登録します。ここでは、ドメイン参加アカウントの名前を

提供することも含まれます。Horizon Cloud 管理ガイドを参照してください。

6 ドメイン参加アカウントをメンバーとして含む Active Directory グループに Horizon Cloud スーパー管理者

の役割を付与します。

重要：ドメインの登録時に入力したドメイン参加アカウントが、Horizon Cloud スーパー管理者の役割を割り

当てる Active Directory グループの 1 つの中に確実に入っている必要があります。システムのドメイン参加の

操作は、Horizon Cloud スーパー管理者の役割を持つドメイン参加アカウントによって異なります。『VMware Horizon Cloud Service on Microsoft Azure 管理ガイド』を参照してください。を参照してください。


VMware, Inc. 63


https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/horizon/vmw-wp-networking-ad-horizon-cloud-azure-uslet-20171201.pdf



https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/horizon/vmw-wp-horizon-cloud-microsoft-azure-uslet-white-paper.pdf

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/horizon/vmw-wp-horizon-cloud-microsoft-azure-uslet-white-paper.pdf

https://secure.vmware.com/44435_REG

https://secure.vmware.com/44435_REG

7 ポッドで Workspace ONE Access を使用する計画の場合、またはポッドに Horizon Clients を直接接続する計

画（ポッドのゲートウェイ構成を使用しない）の場合は、次の手順を実行します。

n DNS サーバで、完全修飾ドメイン名 (FQDN) をポッドのテナントアプライアンス IP アドレスにマッピング

します。

n そのマッピングされた FQDN に基づいて SSL 証明書を取得します。

DNS のポッドのテナントアプライアンス IP アドレスにマッピングした FQDN に基づく SSL 証明書をポッドに

アップロードし、ポッドへの接続が信頼された接続を確立するようにします。このような接続には、マッピング

した FQDN が付与されるユーザー用の Horizon Clients、および Workspace ONE Access とポッドを統合する

ときに使用される Workspace ONE Access Connector が含まれます。Workspace ONE Access Connector は、ポッドのテナントアプライアンス IP アドレスにマッピングされた FQDN を使用してポッドに接続する必要

があります。

注目: Workspace ONE Access をポッドと統合する場合は、ポッドに SSL 証明書をアップロードし、ポッドの

Unified Gateway Access 構成ではなく、ポッドをポイントするように Workspace ONE Access を設定する必

要があります。

ただし、DNS にマッピングされた FQDN に基づいて SSL 証明書をアップロードした場合、適切に構成された

Workspace ONE Access を経由せずに、その FQDN をブラウザに直接入力して接続しようとすると、純粋な

FQDN の使用がブラウザへの信頼されない接続として表示されることに注意してください。これは、単純にこの

FQDN のブラウザへのロードは HTML Access (Blast) を使用した接続であり、HTML Access (Blast) がそのよう

にして動作するためです。その結果、この FQDN をブラウザにロードすると、信頼されていない証明書の一般

的なエラーが表示されます。

Workspace ONE Access がない場合に、HTML Access (Blast) を使用した接続（基本的にブラウザを使用）で、

そのような信頼されていない証明書エラーが表示されるのを回避するには、ポッドにゲートウェイ構成を配置し、

そのゲートウェイ構成のロードバランサと Unified Access Gateway インスタンスを使用する必要がありま

す。インターネット上で FQDN を公開したくない場合は、内部 Unified Access Gateway 構成をデプロイでき

ます。この内部 Unified Access Gateway 構成では、企業のネットワーク内にいるエンドユーザーが接続でき

る Microsoft 内部ロードバランサを使用しています。

8 前の手順で説明したユースケースのいずれかまたは両方を使うことを予定している場合は、管理コンソールのポ

ッドの [サマリ] ページを使用して、SSL 証明書をポッドに直接アップロードします。Horizon Cloud 管理ガイ

ドを参照してください。

ヒント: ポッドの Unified Access Gateway インスタンスに接続されたロードバランサを介してそれらのイン

スタンスに接続するというアクセスのユースケースのみをサポートする場合、ポッドに直接 SSL 証明書をアップ

ロードする必要はありません。それでも、上記の手順 6 とこの手順 7 を実行することが推奨されるのは、その

FQDN をユーザーに配信して、ユーザーが自分の Horizon Clients で入力したときに、それらのクライアントで

信頼された接続が確立されるからです。また、手順 6 とこの手順 7 を実行すると、FQDN がマッピングされ、

SSL 証明書がポッドに配置されているため、ポッドをより早く Workspace ONE Access に統合することができ

ます。

9 マスターイメージをインポートします。[インポートされた仮想マシン] ページで、[エージェントペアリングを

リセット] アクションを使用して、新しいマスターイメージを Horizon Cloud とペアリングします。Horizon Cloud 管理ガイドを参照してください。


VMware, Inc. 64

10 マスターイメージが VDI デスクトップのプロビジョニング用であるか、RDSH ベースのセッションデスクトッ

プおよび RDSH ベースのリモートアプリケーション用であるかに応じて、以下の 1 つまたは複数の手順を実行

します。詳細な手順については、Horizon Cloud 管理ガイドを参照してください。

n VDI デスクトップのマスターイメージで、エンドユーザーに提供するサードパーティアプリケーションを

インストールし、デスクトップ壁紙の設定、（GPU 対応のイメージのための）NVIDIA GPU のドライバのイ

ンストールなどのその他の適用可能なカスタマイズを設定します。イメージのインポートプロセスの一部

として実行されていない場合、Microsoft Sysprep のベストプラクティスに従ってイメージを最適化するこ

ともできます。Horizon Cloud 管理ガイドを参照してください。

n RDSH ベースのセッションデスクトップとリモートアプリケーションのプロビジョニングのための RDS 対応サーバのマスターイメージで、その RDS イメージからエンドユーザーに提供するサードパーティアプ

リケーションをインストールし、デスクトップ壁紙の設定、（GPU 対応のイメージのための）NVIDIA GPU のドライバのインストールなどの適用可能なその他のカスタマイズを設定します。イメージのインポート

プロセスの一部として実行されていない場合、Microsoft Sysprep のベストプラクティスに従ってイメージ

を最適化することもできます。

11 そのマスターイメージを、割り当て可能なイメージ（イメージのシーリングまたは公開とも呼ばれる）に変換し

ます。Horizon Cloud 管理ガイドを参照してください。

12 公開済みのマスターサーバイメージからセッションベースの RDSH デスクトップおよびリモートアプリケー

ションをプロビジョニングするには：

a セッションデスクトップを提供するデスクトップ RDSH ファームを作成し、エンドユーザーにこれらのデ

スクトップを使用する資格を付与するために割り当てを作成します。Horizon Cloud 管理ガイドを参照し

てください。

b リモートアプリケーションを提供するためにアプリケーション RDSH ファームを作成し、アプリケーショ

ンインベントリにアプリケーションを追加してから、エンドユーザーにこれらのリモートアプリケーショ

ンを使用する資格を付与するために割り当てを作成します。Horizon Cloud 管理ガイドを参照してくださ

い。

13 公開済みのマスター VDI デスクトップイメージから VDI デスクトップをプロビジョニングするには、専用また

はフローティング VDI デスクトップ割り当てを作成します。Horizon Cloud 管理ガイドを参照してください。

14 ポッドがゲートウェイ構成でデプロイされている場合、デプロイウィザードで入力した完全修飾ドメイン名

(FQDN) をそのゲートウェイのポッドで構成されている適切な Azure ロードバランサリソースにマッピングす

る CNAME レコードを、DNS サーバに作成する必要があります。

n パブリック IP アドレスが有効な外部ゲートウェイの場合は、デプロイウィザードで入力した FQDN を、ゲ

ートウェイの Azure ロードバランサリソースの自動生成されたパブリック FQDN にマッピングします。

DNS サーバレコードは、ロードバランサの自動生成されたパブリック FQDN とエンドユーザーが使用す

る FQDN をマッピングします。これは、アップロードされた証明書で使用されます。次のコード行は、例

を示します。Active Directory ドメインを登録した後、管理コンソールのポッドの詳細ページから使用する

ID を見つけます。外部ゲートウェイが専用の VNet にデプロイされていた場合は、[デプロイ ID] フィール

ドに表示されている ID を使用します。

ourApps.ourOrg.example.com vwm-hcs-ID-uag.リージョン.cloudapp.azure.com


VMware, Inc. 65

n 内部ゲートウェイまたはパブリック IP アドレスがない外部ゲートウェイの場合は、デプロイウィザードで

入力した FQDN を、ゲートウェイの Azure ロードバランサリソースのプライベート IP アドレスにマッピ

ングします。DNS サーバレコードは、ロードバランサの IP アドレスとエンドユーザーが使用する FQDN をマッピングします。これは、アップロードされた証明書で使用されます。次のコード行は、例を示します。

ourApps.ourOrg.example.com Azure-load-balancer-private-IP

ポッドがオンボーディングされ、管理コンソールの [容量] ページにアクセスできるようになったら、[容量] ペー

ジに移動して、DNS で FQDN をマッピングするために必要な vmw-hcs-ID-uag.region.cloudapp.azure.com

値を確認します。

管理コンソールでロードバランサの FQDN を特定する方法については、Horizon Cloud 管理ガイドを参照して

ください。

15 ポッドがポッドのゲートウェイに対して RADIUS 2 要素認証を使用するようにデプロイされている場合は、次の

タスクを実行する必要があります。

n RADIUS 設定を使用して外部ゲートウェイを構成し、ポッドで使用される VNet と同じ VNet 内で、または

外部ゲートウェイを専用の VNet に展開した場合は、ピアリングされた VNet トポロジ内でその RADIUS サーバにアクセスできない場合、その RADIUS サーバが、外部ゲートウェイのロードバランサの IP アドレス

からのクライアント接続を許可するように構成します。外部ゲートウェイ構成では、Unified Access Gateway インスタンスは、そのロードバランサのアドレスを使用して、RADIUS サーバとの通信を試みま

す。接続を許可するには、その外部ゲートウェイのリソースグループにあるロードバランサリソースの IP アドレスが、確実に RADIUS サーバ構成でクライアントとして指定されているようにします。

n 内部ゲートウェイを構成した場合や、外部ゲートウェイを構成してポッドで使用される VNet と同じ VNet 内で RADIUS サーバにアクセスできる場合は、RADIUS サーバと通信する必要がある、Microsoft Azure でのゲートウェイのリソースグループで作成された適切な NIC からの接続を許可するように RADIUS サーバ

を構成します。ネットワーク管理者が、ポッドの Azure 仮想ネットワークおよびサブネットに対する

RADIUS サーバのネットワーク可視性を決定します。RADIUS サーバは、ネットワーク管理者によって

RADIUS サーバへのネットワーク可視性が付与されたサブネットに対応するゲートウェイ NIC の IP アドレ

スからの、クライアント接続を許可する必要があります。Microsoft Azure のゲートウェイのリソースグル

ープには、そのサブネットに対応する 4 つの NIC があり、そのうち 2 つが 2 個の Unified Access Gateway インスタンスに対して現在アクティブです。もう 2 つはアイドル状態で、ポッドがアップグレードを完了し

た後にアクティブになります。実行中のポッド操作のため、および各ポッドのアップグレード後のために、

ゲートウェイと RADIUS サーバ間の接続をサポートするには、これらの 4 つの NIC の IP アドレスが

RADIUS サーバ構成でクライアントとして指定されていることを確認します。

これらの IP アドレスの取得方法については、『管理ガイド』を参照してください。

上記のワークフローの手順が完了すると、Horizon Client または HTML Access で FQDN を使用して資格のあるデ

スクトップとリモートアプリケーションを起動できます。

各ワークフローステップを実行する方法の詳細については、上記の各手順にリンクされたトピックまたはコンパニオ

ンガイドを参照してください。Horizon Cloud 管理ガイドを参照してください。


VMware, Inc. 66

Horizon Cloud ポッドを Microsoft Azure にデプロイする前の準備

Horizon Cloud 管理コンソールにログインしてポッドデプロイウィザードを初めて実行する前に、次の準備作業を

行う必要があります。

1 VMware Horizon Cloud Service on Microsoft Azure 要件チェックリスト - 2019 年 12 月のサービスリリー

スで使用を参照して、前提条件をすべて満たしていることを確認します。特に、次の点に注意してください。

n Microsoft Azure アカウントとサブスクリプションに、ポッドに必要な仮想マシンの数とサイズが含まれて

いることを確認します。オプションの Unified Access Gateway 構成をデプロイする場合は、それらも対象

になります。Microsoft Azure の Horizon Cloud ポッドに対する Microsoft Azure 仮想マシンの要件を参

照してください。

ポッドのサブスクリプションとは別の専用のサブスクリプションを使用する外部ゲートウェイ構成でポッド

をデプロイする予定がある場合は、他のサブスクリプションに外部ゲートウェイに必要な仮想マシンの数と

サイズが含まれていることを確認します。この使用事例では、VNet は複数のサブスクリプションにまたが

らないため、その個別のサブスクリプションには専用の VNet が必要です。また、サポートされる VNet トポロジは同じ Microsoft Azure リージョン内の VNet を接続しているため、このサブスクリプションはポッ

ドのサブスクリプションと同じリージョンに存在する必要があります。

n ポッドをデプロイするリージョンに仮想ネットワーク (VNet) があり、仮想ネットワークが Horizon Cloud ポッドの要件を満たしていることを確認します。既存の VNet がない場合には、要件を満たす VNet を作成

します。Microsoft Azure で必要な仮想ネットワークを構成を参照してください。

ポッドの VNet とは別の専用の VNet を使用する、またはポッドのサブスクリプションとは別の専用のサブ

スクリプションを使用する外部ゲートウェイ構成でポッドをデプロイする場合は、ポッドの VNet と同じリ

ージョンに VNet が存在すること、および Microsoft Azure で必要な仮想ネットワークを構成を満たしてい

ることを確認します。この使用事例では、これら 2 つの VNet をピアリングする必要があります。

重要：一部の Microsoft Azure リージョンでは、GPU が有効な仮想マシンはサポートされません。GPU 対応のデスクトップまたはリモートアプリケーションでポッドを使用する場合は、使用する NV シリーズの

仮想マシンタイプが、ポッド用に選択した Microsoft Azure のリージョンで提供されていることと、この

Horizon Cloud リリースでサポートされていることを確認します。詳細については、https://azure.microsoft.com/ja-jp/regions/services/ にある Microsoft のドキュメントを参照してください。

n ポッドをデプロイする前に、ポッドのサブネットを VNet 上で手動で作成する場合は、VNet で必要な数の

サブネットが作成されたこと、およびそのアドレス空間が Microsoft Azure で必要な仮想ネットワークを構

成を満たしていること、またリソースがないことを確認します。ポッドのデプロイの前に、Microsoft Azure の VNet で Horizon Cloud ポッドに必要なサブネットを作成する。

注意：ポッドのデプロイのために VNet 上に作成するこれらのサブネットは空である必要があります。ポ

ッドをデプロイする前にサブネットを作成することが可能ですが、これらのサブネットにいかなるリソース

も配置しないでください。またいかなる IP アドレスも使用しないでください。IP アドレスがサブネットで

既に使用されていると、ポッドのデプロイに失敗する可能性があります。

サブネットを事前に作成しない場合、ポッドのデプロイプロセスは画面上のウィザードに入力した CIDR 情報を使用してサブネットを作成します。


VMware, Inc. 67

https://azure.microsoft.com/en-us/regions/services/


n 仮想ネットワークが、外部名を解決している有効なドメインネームサービス (DNS) サーバを指すように設

定されていることを確認します。Microsoft Azure の Horizon Cloud ポッドに使用する VNet トポロジに

必要な DNS サーバの設定を参照してください。

重要：ポッドのデプロイプロセスでは、外部名および内部名の解決が必要です。外部名を解決できない

DNS サーバを VNet がポイントしている場合、デプロイプロセスは失敗します。

n このリリースでの使用がサポートされている Active Directory が設定済みで、お使いの仮想ネットワークが

それに到達することができ、DNS サーバがその名前を解決できることを確認します。Active Directory ドメインの構成を参照してください。

2 サービスプリンシパルを作成し、Microsoft Azure サブスクリプション ID、アプリケーション ID、アプリケー

ション認証キー、Microsoft Azure Active Directory のディレクトリ ID を作成します。これらのリソースは、

Horizon Cloud が Microsoft Azure 環境内で操作を実行するために使用されます。詳細な手順についてはアプ

リケーション登録を作成して Horizon Cloud ポッドデプロイヤに必要なサービスプリンシパルを作成するを

参照してください。

重要：サービスプリンシパルには、サブスクリプションに割り当てられたロールが必要です。割り当てられた

ロールは、ポッドを正常にデプロイして維持するために Horizon Cloud が Microsoft Azure サブスクリプショ

ンで実行する必要のあるアクションを許可する必要があります。次のロールのいずれかを、サービスプリンシパ

ルに割り当てる必要があります。

n 共同作成者ロール。共同作成者ロールは、Microsoft Azure の組み込みロールの 1 つです。共同作成者ロー

ルについては、Microsoft Azure ドキュメントの「Azure リソースの組み込みロール」を参照してくださ

い。

n Horizon Cloud がポッドのデプロイおよびメンテナンス操作に必要とする Microsoft Azure サブスクリプ

ションの Horizon Cloud ポッドデプロイヤに必要なロール操作をサービスプリンシパルに提供するため

に設定したカスタムロール。

3 Unified Access Gateway 構成でポッドをデプロイしている場合、エンドユーザーのクライアントがデスクトッ

プおよびリモートアプリケーションへの接続を信頼できるようにする署名付きの TLS/SSL サーバ証明書を取得

します。この証明書は、エンドユーザーがクライアントで使用する FQDN に一致し、信頼されている認証局

(CA) によって署名される必要があります。また、証明書チェーン内のすべての証明書には、すべての中間証明書

を含め、有効な有効期限が設定されていなければなりません。チェーン内のいずれかの証明書が期限切れの場合、

ポッドのオンボーディングプロセスの後半で予期しない不具合が発生する可能性があります。

エンドユーザーのクライアントが接続を信頼できるように、Unified Access Gateway が CA 署名付きの証明書

を提供します。インターネットからの信頼できるアクセスをサポートするには、ポッドの外部 Unified Access Gateway 構成をデプロイします。企業のネットワーク内の信頼できるアクセスをサポートするには、内部

Unified Access Gateway 構成を使用します。どちらの構成タイプも、ポッドの編集ワークフローを使用して最

初のポッドデプロイプロセスまたはポッド後のデプロイ中にデプロイできます。

重要：この FQDN には、アンダースコアを含めることはできません。このリリースでは、FQDN にアンダー

スコアが含まれていると、Unified Access Gateway インスタンスへの接続が失敗します。


VMware, Inc. 68

https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles

4 Unified Access Gateway 構成で使用する署名付き SSL サーバ証明書が PEM 形式でない、またはプライベート

キー付きの証明書チェーン全体を含む単一の PEM ファイルでない場合は、証明書の情報を必要な PEM 形式に変

換します。証明書ファイルをポッドのデプロイに必要な PEM 形式に変換するの手順を参照してください。

5 まだ登録を行っていない場合には、My VMware アカウントを取得して Horizon Cloud を登録します。

これらの準備作業が完了したら、My VMware アカウントを使用して、cloud.horizon.vmware.com にある Horizon Cloud 管理コンソールにログインします。ログイン後、画面に [クラウドのキャパシティを追加] 領域が表示されま

す。[追加] をクリックして、ポッドデプロイウィザードを起動します。各画面で必要な情報を入力して、ウィザード

を完了します。詳細な手順については Microsoft Azure への Horizon Cloud ポッドのデプロイを参照してくださ

い。

注： Horizon Cloud 管理コンソールへのログイン認証は、My VMware アカウントの認証情報に依存します。My VMware アカウントのシステムで、システムの停止が発生していて、認証要求に対応できない場合、その期間中に管

理コンソールにログインすることはできません。管理コンソールの最初のログイン画面でログインの問題が発生する

場合は、https://status.horizon.vmware.com にある Horizon Cloud システムステータスページで最新のシステ

ムステータスを確認してください。そのページで、アップデートを定期受信するようにすることもできます。

Microsoft Azure の Horizon Cloud ポッドに対する Microsoft Azure 仮想マシンの要件

ポッドをデプロイし、ポッドのゲートウェイ構成をデプロイして標準的な運用を行う場合、Microsoft Azure のクラ

ウドキャパシティで特定の種類とサイズの仮想マシン (VM) が必要になります。サブスクリプションには、これらの

仮想マシンをサポートする適切な割り当てと構成が必要です。個別のサブスクリプションでポッドの外部ゲートウェ

イをデプロイするオプションを使用している場合、そのサブスクリプションには、その外部ゲートウェイ構成をサポ

ートするための割り当てと構成が必要です。

重要：ポッドデプロイウィザードは、Microsoft Azure 環境に、指定したポッドとゲートウェイ構成（ある場合）

を構築するのに十分なコアの割り当てがあることを検証します。ウィザードで指定したサブスクリプション情報に基

づいて十分な割り当てがないとウィザードが判断した場合、画面にメッセージが表示され、ウィザードは次のステッ

プに進みません。

2019 年 9 月のリリース以降、すべての新しいポッドは、Microsoft Azure ロードバランサと Microsoft Azure Database for PostgreSQL サーバとともにデプロイされます。Microsoft Azure Database for PostgreSQL サーバ

は、単一サーバのデプロイを使用してデプロイされます。

注： GPU が有効な仮想マシンは、一部の Microsoft Azure リージョンでのみ使用できます。詳細については、リ

ージョン別の Azure 製品を参照してください。

以下の表では、仮想マシンの仕様の列に次の情報が示されています。

n Microsoft Azure のドキュメントで使用されているシリーズ名

n Microsoft Azure ポータルに表示されるクォータに使用されている vCPU のファミリ名

n そのファミリからの仮想マシンタイプの特定の名前


VMware, Inc. 69


https://status.horizon.vmware.com



Microsoft Azure ポータルでサブスクリプションの現在の割り当てを表示するには、[すべてのサービス] - [サブスク

リプション] に移動して、サブスクリプションをクリックし、[使用量 + クォータ] をクリックします。Microsoft Azure の Microsoft Windows 仮想マシンのサイズの詳細については、Microsoft Azure のドキュメントの次のトピ

ックとそのサブトピックを参照してください。https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/sizes

表 2-2. ポッドのジャンプボックス仮想マシンの要件

仮想マシン Microsoft Azure 仮想マシンの仕様数量説明

ジャンプボ

ックス

Linux Standard F ファミリ：

Standard_F2（2 コア、4 GB のメモリ）

OS ディスク：標準的な HDD 30 GiB

ポッドごと

に 1 つ

Microsoft Azure 環境内で作成され、最初のポッド作成時と以降のソフトウェア更新で使用さ

れる仮想マシン。デプロイするポッドごとに 1 台のジャンプボックス仮想マシンが作成され

ます。ポッドの作成または更新プロセスが完了して仮想マシンが不要になると、このジャンプ

ボックス仮想マシンは自動的に削除されます。

注：ジャンプボックス仮想マシンが、ポッドを作成するため、ポッドソフトウェアの次のバ

ージョンが利用可能であるときにアップグレードの Green コンポーネントを構築するため、ポ

ッドでの Blue/Green アップグレードプロセスを調整するため、およびゲートウェイ構成を既

存のポッドに追加するプロセスのために新たにデプロイされます。

表 2-3. 個別の VNet に外部ゲートウェイがある場合：ジャンプボックス仮想マシンの要件


ジャンプボ

ックス

Linux Standard F ファミリ：

Standard_F2（2 コア、4 GB のメモリ）


ポッドごと

に 1 つ

オプションで外部ゲートウェイを専用の VNet または専用のサブスクリプションにデプロイす

る場合、ポッド自体のコアリソースに使用されるジャンプボックス仮想マシンとは別のジャン

プボックス仮想マシンが必要です。Microsoft Azure 環境では、このジャンプボックス仮想

マシンはポッドのジャンプボックス仮想マシンとは別のリソースグループに作成され、外部ゲ

ートウェイ構成の初期デプロイ中、およびその外部ゲートウェイでの後続のソフトウェア更新

中に使用されます。デプロイする専用の VNet またはサブスクリプションの外部ゲートウェイ

ごとに 1 つのジャンプボックス仮想マシンがあります。外部ゲートウェイのデプロイまたは

更新プロセスが完了して仮想マシンが不要になると、このジャンプボックス仮想マシンは自動

的に削除されます。

注：ジャンプボックス仮想マシンは、（ポッドの作成中、または [ポッドを編集] ワークフロ

ーを使用して外部ゲートウェイを既存のポッドに追加する場合に）専用の VNet またはサブス

クリプションでそれらの外部ゲートウェイの 1 つを作成するために、あるいは外部ゲートウェ

イまたはポッドソフトウェアの次のバージョンが利用可能になったときにその外部ゲートウェ

イのアップグレードの Green コンポーネントを構築するために、またはその外部ゲートウェイ

で Blue/Green アップグレードプロセスを調整するために新たにデプロイされます。


VMware, Inc. 70

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes


表 2-4. ポッド管理仮想マシンの要件 - ポッドのコア仮想マシン向け（ゲートウェイ構成は含まない）


高可用性が

有効になっ

ていないポ

ッド：ポッド

管理インス

タンス

Linux - Standard Dv3 ファミリ：

Standard_D4_v3（4 コア、16 GB のメ

モリ）


注： Standard_D4_v3 タイプが

Microsoft Azure リージョンで使用でき

ない場合、デプロイヤは代わりに

Standard Dv2 ファミリの


モリ）を使用します。

定常状態の動作中はポッドごとに 1 つ

ポッドの Blue/Green アップグレードプロセ

スの End-to-End 時間中は、ポッドごとに 2

つ。

高可用性が有効になっていないポッドの場合、定常状態の動

作中は、1 台の仮想マシンが存在し、パワーオンされた状態

で、ポッドを実行します。新しいポッドのマニフェストが

VMware オペレーションチームによって利用可能になった

ときに、システムがポッドの Blue/Green アップグレード

プロセス用の Green コンポーネントの構築を開始すると、

2 つ目のインスタンスが作成され、パワーオンされます。

End-to-End のアップグレードプロセスの一部として、シ

ステムが Green コンポーネントの使用に切り替える時刻を

スケジューリングします。切り替えが完了した後、ポッドは

定常状態の動作のために新しく作成された仮想マシンを使

用しており、Blue コンポーネントセットにある以前に使用

されていた仮想マシンは停止して削除されます。

環境のサイズは、システムが Blue/Green アップグレード

プロセスのためにポッドの Green コンポーネントの構築を

開始した時点から、ポッドが新しい Green コンポーネント

を使用するように切り替えられる時点までの、End-to-End

のアップグレード期間で並行して実行される 2 つのポッド

マネージャインスタンスに対応できる必要があります。ポ

ッドの Blue/Green アップグレードプロセスの説明につい

ては、『管理ガイド』を参照してください。

高可用性が

有効になっ

ているポッ

ド：ポッド管

理インスタ

ンス

Linux - Standard Dv3 ファミリ：


モリ）


注： Standard_D4_v3 タイプが

Microsoft Azure リージョンで使用でき

ない場合、ポッドデプロイヤは代わりに

Standard Dv2 ファミリの


モリ）を使用します。

定常状態の動作中はポッドごとに 2 つ

ポッドの Blue/Green アップグレードプロセ

スの End-to-End 時間中は、ポッドごとに 4

つ。

高可用性が有効になっているポッドの場合、定常状態の動作

中は、2 台の仮想マシンが存在し、パワーオンされた状態

で、ポッドを実行します。新しいポッドのマニフェストが

VMware オペレーションチームによって利用可能になった

ときに、システムがポッドの Blue/Green アップグレード

プロセス用の Green コンポーネントの構築を開始すると、

ポッドマネージャ仮想マシンにつき 2 つ目のインスタンス

が作成され、パワーオンされます。その時点では、ポッドマ

ネージャ仮想マシンの合計実行数は 4 です。End-to-End

のアップグレードプロセスの一部として、システムが

Green コンポーネントの使用に切り替える時刻をスケジュ

ーリングします。切り替えが完了した後、ポッドは定常状態

の動作のために新しく作成された 2 台の仮想マシンを使用

しており、Blue コンポーネントセットにある以前に使用さ

れていた 2 台の仮想マシンは停止して削除されます。





のアップグレード期間で並行して実行される 4 つのポッド

マネージャインスタンスに対応できる必要があります。ポ

ッドの Blue/Green アップグレードプロセスの説明につい

ては、『管理ガイド』を参照してください。


VMware, Inc. 71

表 2-5. Unified Access Gateway 仮想マシンの要件（ポッドの VNet とサブスクリプションを使用する外部ゲートウェイ）


Unified

Access

Gateway イ

ンスタンス

Linux Standard Av2 ファミリ：

Standard_A4_v2 Standard（4 コア、

8 GB のメモリ）


外部または内部 Unified Access Gateway

構成を使用するか、同じポッドで両方のタイプ

を使用するかによって異なります。

構成が外部または内部のみの場合：

n 定常状態の動作中はポッドごとに 2 つ

n ポッド関連の Blue/Green アップグレ

ードアクティビティの End-to-End 時

間中はポッドごとに 4 つ。

Unified Access Gateway 構成が外部および

内部の両方設定されているポッドの場合：

n 定常状態の動作中はポッドごとに 4 つ

n ポッド関連の Blue/Green アップグレ

ードアクティビティの End-to-End 時

間中はポッドごとに 8 つ。

Unified Access Gateway は、デプロイウィザードでゲー

トウェイ設定を行うときに、ポッドでデプロイされるオプシ

ョンの機能です。ポッドで Unified Access Gateway イ

ンスタンスを使用することを決定した場合、環境がポッドの

End-to-End の Blue/Green アップグレードプロセス中

に実行しているこれらのインスタンスに対応できる必要が

あります。定常状態インスタンスの数は、外部および内部の

両方の Unified Access Gateway 構成を選択するかどう

かによって決まります。

定常状態の動作中に外部のみまたは内部のみの Unified

Access Gateway 構成しかない場合、2 つのインスタンス

が存在し、パワーオンになり、Unified Access Gateway

機能を提供します。アップグレードプロセスで、2 つの追加

インスタンスが作成され、パワーオンされて Unified

Access Gateway のソフトウェア更新が実行されます。ア

ップグレードの完了後、ポッドは新しく作成された仮想マシ

ンの使用に移行し、Blue コンポーネントセットにある以前

に使用されていた仮想マシンは停止して削除されます。

定常状態の動作中に内部と外部の両方の Unified Access

Gateway 構成を使用する場合、4 つのインスタンスが存在

し、パワーオン状態になり、Unified Access Gateway 機

能を提供します。2 つのインスタンスが外部構成の機能を

提供し、2 つのインスタンスが内部構成の機能を提供しま

す。アップグレードプロセス中は、1 つの構成あたり 2 つ

の追加インスタンスが作成され、パワーオンされて Unified

Access Gateway のソフトウェア更新が実行されます。ア

ップグレードの完了後、ポッドは新しく作成された仮想マシ

ンの使用に移行し、Blue コンポーネントセットにある以前

に使用されていた仮想マシンは停止して削除されます。





のアップグレード期間で並行して実行される示された

Unified Access Gateway インスタンスに対応できる必要

があります。ポッドの Blue/Green アップグレードプロセ

スの説明については、『管理ガイド』を参照してください。


VMware, Inc. 72

表 2-6. 個別の VNet に外部ゲートウェイがある場合：ゲートウェイコネクタ仮想マシンの要件


ゲートウェ

イコネクタ

インスタン

ス

Linux Standard Av2 ファミリ：

Standard_A1_v2 Standard（1 コア、

2 GB のメモリ）


定常状態の操作中に、この外部ゲートウェイタ

イプごとに 1 つ

ポッド関連の Blue/Green アップグレードア

クティビティの End-to-End 時間中はこの外

部ゲートウェイタイプごとに 2 つ。

外部ゲートウェイが個別の VNet にデプロイされると、この

仮想マシンが作成され、その外部ゲートウェイ構成でのクラ

ウド管理操作に使用されます。アップグレードプロセス中

に追加のインスタンスが作成され、パワーオン状態になり、

外部ゲートウェイ構成の Unified Access Gateway でソ

フトウェアの更新が実行されます。アップグレードが完了

すると、新しく作成された仮想マシンへの移行が行われ、以

前使用されていた仮想マシンは停止して削除されます。こ

のオプションの構成を使用する場合は、ポッド関連の Blue/

Green アップグレードアクティビティ中に End-to-End

で実行されるこれらのインスタンスに環境が対応できる必

要があります。


VMware, Inc. 73

表 2-7. イメージ仮想マシンの要件


マスターイ

メージ

マスターイ

メージは、そ

れらを作成

したときの

選択に応じ

て、GPU 対

応かそうで

ないかのい

ずれかにな

ります。

GPU が有効なマスターイメージでは、シ

ステムは次を使用します。

n （Standard NV ファミリ vCPU か

らの）NV シリーズ NV6 Standard

n OS ディスク：標準的な HDD 127

GiB

必要に応じ

て変更でき

ます。

マスターイメージとは、Horizon Cloud がそれを公開イメージに変換できるように構成され

ている、Microsoft Windows オペレーティングシステムの仮想マシンです。RDS 対応の

Windows サーバオペレーティングシステム仮想マシンは、セッションベースのデスクトッ

プおよびリモートアプリケーションをエンドユーザーに提供する RDSH ファームを作成する

ために使用される基盤を提供します。Windows クライアントオペレーティングシステム仮

想マシンは、VDI デスクトップを作成するために使用する基盤を提供します。各マスターイメ

ージは、Microsoft Windows オペレーティングシステムと GPU 対応であるか非対応かを組

み合わせたものになります。このため、ポッドで提供するものが次のとおりである場合：

n Microsoft Windows 2016 Datacenter を使用する RDSH デスクトップ、GPU なし

n Microsoft Windows 2016 Datacenter を使用する RDSH デスクトップ、GPU あり

少なくとも 2 つのマスターイメージ仮想マシンが必要になります。

マスターイメージを公開イメージに変換するプロセスは、イメージの公開と呼ばれたり、イメ

ージのシーリングとも呼ばれることがあります。作成される公開イメージは、割り当てで使用

するための最終状態になっているため、シールドされたイメージまたは割り当て可能なイメー

ジと呼ばれることがあります。

システムは、公開時（管理コンソールでマスターイメージに [イメージに変換] アクションを実

行するとき）にマスターイメージを自動的にパワーオフします。公開イメージを更新すると、

システムは仮想マシンを再度パワーオンします。

注：管理コンソールを使用してイメージを複製する場合、システムはその複製のための構成

を取得するためにマスターイメージの仮想マシンを一時的にパワーオンして、再びパワーオフ

します。

マスターイメージを作成する方法については、管理ガイドのトピック「Microsoft Azure に

Horizon Cloud ポッドのデスクトップイメージを作成」を参照してください。

GPU が有効でないマスターイメージと

Microsoft Windows クライアントオ

ペレーティングシステムでは、システム

は次を使用します。

n （Standard Dv3 ファミリ vCPU

からの）Standard_D4_v3


GiB

ポッドがデプロイされた Microsoft

Azure リージョンにおいて Microsoft

が Standard Dv3 ファミリを提供しな

い場合、システムは Standard Dv2 ファ

ミリの Standard_D3_v2 を代わりに使

用します。

GPU が有効でないマスターイメージと

Microsoft Windows Server オペレー

ティングシステムでは、システムは次を

使用します。

n （Standard Dv3 ファミリ vCPU

からの）Standard_D2_v3


GiB

ポッドがデプロイされた Microsoft

Azure リージョンにおいて Microsoft

が Dv3 シリーズを提供しない場合、シス

テムは Standard Dv2 ファミリの

Standard_D2_v2 を代わりに使用しま

す。


VMware, Inc. 74


表 2-8. ファーム仮想マシンの要件


RDSH ファ

ーム

このリリース以降、ポッドでファームを

作成するときに選択できるようにする一

連の Microsoft Azure 仮想マシンタイ

プをカスタマイズできます。標準の

Microsoft Azure リージョンで一般的に

使用可能な一連の Microsoft Azure 仮

想マシンサイズから独自のリストをカス

タマイズできます。ファームで使用でき

る一連の仮想マシンタイプのカスタマイ

ズの詳細については、『Horizon Cloud

管理ガイド』を参照してください。

ファームを作成または編集するときに、

ファームのサーバインスタンスの OS デ

ィスクサイズをカスタマイズして、シス

テムのデフォルト値から変更できます。

標準の Microsoft Azure リージョンで

一般的に利用可能な Windows 仮想マシ

ンサイズの詳細については、https://

docs.microsoft.com/en-us/azure/

virtual-machines/windows/sizes に

ある Microsoft のドキュメントを参照し

てください。

注：本番環境では、ファームに使用する

仮想マシンタイプに少なくとも 2 個の

CPU が確実に搭載されているようにしま

す。この基準を満たすことで、エンドユ

ーザー接続に関する不測の問題を回避で

きます。この基準は、バージョン 7.x 以

降から Horizon Agent をインストール

またはアップグレードするために、2 個以

上の CPU を備えていることが Horizon

Agent の推奨であることによるもので

す。この Horizon Agent の基準は、

Horizon 7 のドキュメントのトピックバ

ージョン 7.7 以降からの仮想マシンへの

Horizon Agent のインストールで説明

されています。

ニーズおよ

び Horizon

Cloud 環境

で仮想マシ

ンのサイズ

をカスタマ

イズした方

法によって

異なります。

RDSH ファームの仮想マシンは、エンドユーザーにセッションベースのデスクトップとリモ

ートアプリケーションを提供するサーバインスタンスです。セッションデスクトップを提供

するには少なくとも 1 つの RDSH ファームが必要で、リモートアプリケーションを提供する

には 1 つの RDSH ファームが必要です。管理者またはエンドユーザーのニーズを満たすため

に、追加のファームをデプロイすることを決定することができます。

これらの仮想マシンの電源状態は、ファームの構成とエンドユーザーの要件によって異なりま

す。

注：このリリースでは、セッションベースのデスクトップとリモートアプリケーションを同

じファームから配布することはできません。


VMware, Inc. 75




https://docs.vmware.com/jp/VMware-Horizon-7/7.8/horizon-virtual-desktops/GUID-1F2D0C6E-6379-4B52-A7EA-C1EF09CE2F9B.html



表 2-9. VDI デスクトップ仮想マシンの要件


VDI デスク

トップ

このリリース以降、ポッドで VDI デスク

トップ割り当てを作成するときに選択で

きるようにする一連の Microsoft Azure

仮想マシンタイプをカスタマイズできま

す。標準の Microsoft Azure リージョ

ンで一般的に使用可能な一連の

Microsoft Azure 仮想マシンサイズか

ら独自のリストをカスタマイズできま

す。VDI デスクトップ割り当てで使用で

きる一連の仮想マシンタイプのカスタマ

イズの詳細については、『Horizon Cloud

管理ガイド』を参照してください。

注： Standard_B2l や Standard_B1

など、Microsoft が VDI のユースケース

には適していないと判断した少数の

Microsoft Azure 仮想マシンサイズは、

使用の対象から自動的に除外されます。

VDI デスクトップ割り当てを作成または

編集するときに、VDI デスクトップイン

スタンスの OS ディスクサイズをカスタ

マイズして、システムのデフォルトから

変更できます。

これらの Windows 仮想マシンのサイズ

に関する詳細情報については、Microsoft

のドキュメント ( https://

docs.microsoft.com/en-us/azure/

virtual-machines/windows/sizes) を


注：本番環境では、VDI デスクトップ割

り当てに使用する仮想マシンタイプに少

なくとも 2 個の CPU が確実に搭載され

ているようにします。この基準を満たす

ことで、エンドユーザー接続に関する不

測の問題を回避できます。この基準は、

バージョン 7.x 以降から Horizon

Agent をインストールまたはアップグレ

ードするために、2 個以上の CPU を備え

ていることが Horizon Agent の推奨で

あることによるものです。この Horizon

Agent の基準は、Horizon 7 のドキュメ

ントのトピックバージョン 7.7 以降から

の仮想マシンへの Horizon Agent のイ

ンストールで説明されています。

ニーズおよ

び Horizon

Cloud 環境

で仮想マシ

ンのサイズ

をカスタマ

イズした方

法によって

異なります。

VDI デスクトップ仮想マシンは、エンドユーザーに VDI デスクトップを提供するインスタン

スです。

これらの仮想マシンの電源状態は、VDI デスクトップ割り当ての設定とエンドユーザーの要件

によって異なります。

VMware Horizon Cloud Service on Microsoft Azure サービスの制限

このトピックでは、サポートされる最大値とも呼ばれる VMware Horizon Cloud Service on Microsoft Azure のい

くつかの一般的な制限について説明します。このトピックは現在、単一のサブスクリプションでデプロイ可能なデス

クトップおよびファームサーバ仮想マシンの数と、ポッドごとの同時実行される接続セッションの合計数の両方につ


VMware, Inc. 76







いて、サポートされる最大値を記載しています。時間の経過とともにこのトピックは更新され、既知の制限が追加さ

れます。

サービスは、単一のサブスクリプションでデプロイされる特定の数の仮想マシンについて、および 1 つのポッドで対

応できる同時接続の数についてテストされます。

サブスクリプションあたり

最大 2,000 のデスクトップ

仮想マシンとファームサー

バ仮想マシン

この制限は、単一のサブスクリプションに対して適用される Microsoft Azure API の制限に基づいています。標準の操作でこれらの API 制限を守るため、Horizon Cloud はサブスクリプションあたり最大 2,000 のデスクトップ仮想マシンとファ

ームサーバ仮想マシンをサポートします。

サブスクリプションあたり 2,000 という制限には、VDI デスクトップ仮想マシンと

ファームサーバ仮想マシンが含まれ、単一のサブスクリプションのすべてのポッド

が対象です。たとえば、サブスクリプションに 1 つのポッドがある場合、そのポッ

ドに最大 2,000 の VDI デスクトップを接続することも、1,950 の VDI デスクトップ

と 50 のファームサーバを接続することもできます。サブスクリプションに複数の

ポッドがある場合でも、すべてのポッドに接続された VDI デスクトップとファーム

サーバの数は合計で 2,000 を超えることはできません。

ポッドあたり最大 2,000 のセッション

Horizon Cloud は、ポッドあたり最大 2,000 の同時接続セッションをサポートしま

す。2,000 という制限には、VDI デスクトップ、RDS デスクトップ、ポッドによっ

て提供される RDS アプリケーションへの接続が含まれます。この最大値は、ポッド

のセッション処理能力によって決まります。

Microsoft Azure で必要な仮想ネットワークを構成

Horizon Cloud ポッドを環境にデプロイするには、Microsoft Azure 環境に既存の仮想ネットワークが必要です。デ

プロイするリージョンに仮想ネットワーク (VNet) がない場合は、仮想ネットワークを作成する必要があります。ポ

ッドの外部ゲートウェイを、ポッドの VNet とは別の専用の VNet にデプロイする場合は、その VNet も作成し、そ

れから 2 つの VNet をピアリングする必要があります。ポッドの外部ゲートウェイが、ポッドとは別の専用のサブス

クリプションを使用するようにする場合、その外部ゲートウェイに使用する別の VNet を作成して、2 つの VNet をピアリングする必要があります。これは、単一の VNet は複数のサブスクリプションにまたがらないため、外部ゲー


VMware, Inc. 77

トウェイを専用のサブスクリプションにデプロイすることを選択する場合、外部ゲートウェイはポッドの VNet にピ

アリングされた別の VNet を使用する必要もあるからです。

注意：ポッドのデプロイのために VNet 上に事前に手動で作成したサブネットは空のままである必要があります。

これらのサブネットに何らかのリソースを投入したり、IP アドレスを使用したりしないでください。IP アドレスがサ

ブネットで既に使用されていると、ポッドのデプロイに失敗する可能性があります。

ポッドの VNet を使用して

外部ゲートウェイでポッド

をデプロイする場合

この構成では、事前に VNet でサブネットを作成してポッドのデプロイウィザード

でそのサブネットを指定するか、必要なサブネットのアドレス空間をウィザードに

直接入力すると、ポッドデプロイヤが VNet にサブネットを作成します。

重要：既存の VNet がピアリングされている場合、デプロイヤは VNet のアドレス

空間を自動的に更新することができません。VNet がピアリングされている場合の

ベストプラクティスは、ポッドのデプロイの前に、Microsoft Azure の VNet で

Horizon Cloud ポッドに必要なサブネットを作成するに記載されているように、事

前にサブネットを作成することです。サブネットを事前に作成せずに、デプロイウィザードで VNet の既存アドレス空間に含まれていないサブネット CIDR を入力し

た場合、ウィザードにはエラーメッセージが表示されます。この場合は、有効なサ

ブネットアドレス空間を指定して続行するか、ピアリングされていない仮想ネット

ワークを使用します。

この構成では、次のサブネットが必要です。

n ポッド自身の管理アクティビティに含まれる仮想マシンで使用される IP アド

レスの場合は管理サブネット

n そのサブネット上の RDSH サーバの仮想マシンおよび VDI デスクトップ仮想

マシンに使用される IP アドレスの場合はデスクトップサブネット。内部

Unified Access Gateway 構成がデプロイウィザードで指定されている場合、

Unified Access Gateway 仮想マシンもこのサブネットからの IP アドレスを

使用します。

重要： VDI デスクトップの仮想マシン、RDS イメージ、ポッドの RDS ファー

ム内の各サーバはこれらの IP アドレスを使用します。このデスクトップサブ

ネットはポッドのデプロイ後に拡張できないため、このポッドで提供するデス

クトップの数を考慮してこの範囲を十分に大きく設定します。たとえば、この

ポッドが将来 1000 台以上のデスクトップを提供すると予想される場合は、こ

の範囲がそれ以上の IP アドレスを提供するようにします。

n オプションの外部 Unified Access Gateway 構成によって使用される IP アド

レス用の DMZ サブネット。


VMware, Inc. 78

デプロイヤにサブネットの自動作成を実施させる場合、デプロイヤは対応する VNet に新しいサブネットを常に作成します。VNet のアドレス空間の観点から、次のよう

にウィザードに入力したサブネットアドレス空間を、デプロイヤが処理します。

n VNet のアドレス空間にまだ存在していないアドレス空間をウィザードで指定

すると、デプロイヤは自動的にそれらのアドレス空間を追加するために VNet の構成を更新します。次に、VNet に新しいサブネットが作成されます。

n ウィザードで指定したアドレス空間がすでに VNet の既存のアドレス空間に含

まれている場合、デプロイヤは単純にその指定したアドレス空間を使用して

VNet に新しいサブネットを作成します。

ポッドの VNet またはサブ

スクリプションとは別に、専

用の VNet またはサブスク

リプションを使用する外部

ゲートウェイを持つように

選択してポッドをデプロイ

する場合

この構成では、2 つの VNet が含まれ、これらの VNet をピアリングする必要があ

るため、ベストプラクティスとして、VNet で事前にサブネットを作成し、ポッド

のデプロイウィザードでそれらを指定します。ポッドのデプロイの前に、

Microsoft Azure の VNet で Horizon Cloud ポッドに必要なサブネットを作成す

るの説明に従って、事前にサブネットを作成します。デプロイウィザードには、デ

プロイヤがサブネットを作成するために必要なサブネットのアドレス空間をウィザ

ードに直接入力するオプションがありますが、VNet のアドレス空間にないアドレス

空間を指定すると、VNet はピアリングされた VNet であるため、デプロイヤはその

アドレス空間を VNet に追加できません。

この場合、1 つの VNet にポッドのサブネットがあり、もう 1 つの VNet に外部ゲ

ートウェイのサブネットがあります。これらの 2 つの VNet をピアリングする必要

があります。ポッドの VNet を VNet-1、外部ゲートウェイの VNet を VNet-2 と呼

ぶことにします。VNet ごとに、ポッドデプロイヤが自動的に作成するサブネット

のアドレス空間を指定するか、事前に作成したサブネットを指定できます。

このタイプのデプロイでは、ポッドの VNet (VNet-1) は管理サブネットとデスクト

ップサブネットを取得し、それらは外部ゲートウェイがポッドの専用 VNet にある

場合の説明と同じ目的で使用されます。ただし、ポッドの VNet はこの構成では

DMZ サブネットを取得しません。これは、DMZ サブネットがこの構成の別の

VNet (VNet-2) にある外部 Unified Access Gateway 構成で使用されるためです。

このデプロイ構成では、外部ゲートウェイの VNet は次のサブネットを取得します。

n 外部ゲートウェイ自体の管理アクティビティに含まれる仮想マシン（一時ジャ

ンプボックス、ゲートウェイのコネクタ仮想マシン、および外部ゲートウェイ

の Unified Access Gateway インスタンス）が使用する IP アドレスのための管

理サブネット

n 外部ゲートウェイの Unified Access Gateway インスタンスによって使用さ

れるバックエンドサブネット

n 外部ゲートウェイの Unified Access Gateway インスタンスによって使用さ

れる DMZ サブネット


VMware, Inc. 79

登録アカウントに応じた Microsoft Azure ポータルを使用して、次の手順を行います。たとえば、これらの

Microsoft Azure クラウドのための特定のポータルエンドポイントがあります。

n Microsoft Azure（標準グローバル）

n Microsoft Azure Germany

n Microsoft Azure China

n Microsoft Azure US Government

自分のアカウントに該当する URL を使用してポータルにログインします。

手順

1 Microsoft Azure ポータルの左側のナビゲーションバーから、（[仮想ネットワーク]）をクリッ

クし、[追加] をクリックします。

[仮想ネットワークを作成] 画面が表示されます。

2 必須のフィールドに情報を入力します。


名前 VNet の名前を指定します。

アドレス空間 VNet のアドレス空間を指定します。

サブスクリプションポッドをデプロイするときに使用する予定がある、同じサブスクリプションを選択します。

リソースグループ既存のリソースグループを選択するか、仮想ネットワークの作成時に新しいリソースグループ

を作成することができます。

場所ポッドをデプロイする予定がある、同じリージョンを選択します。

サブネットとアドレス範囲 Microsoft Azure では、VNet を作成するときに 1 つのサブネットを作成する必要がありま

す。デフォルト値を保持することも、名前や範囲をカスタマイズすることもできます。ポッド

の必要なサブネットのいずれかにこのサブネットを使用する場合は、ポッドデプロイヤの要件

に応じて適切なアドレス範囲を指定してください。たとえば、ポッドのテナントサブネットに

このサブネットを使用する場合は、デプロイウィザードが要求する /27 に最小限適合する IP アドレス範囲を持つことを確認してください。ポッドのデプロイの前に、Microsoft Azure の

VNet で Horizon Cloud ポッドに必要なサブネットを作成するを参照してください。

重要：このサブネットを、ポッドの必要なサブネットの 1 つに使用する場合は、その他のリ

ソースに使用できません。

オプションの設定に対しては、デフォルト値を保持します。


VMware, Inc. 80

3 [作成] をクリックします。

ご利用の Microsoft Azure アカウントで、仮想ネットワーク (VNet) が作成されます。

次のステップ

ポッドのデプロイプロセスによって作成を行う代わりに必要なサブネットを手動で作成する場合、ポッドに使用する

サブネットで新しく作成された VNet を設定します。ポッドのデプロイの前に、Microsoft Azure の VNet で

Horizon Cloud ポッドに必要なサブネットを作成するおよび Microsoft Azure で Horizon Cloud ポッド用の既存

のサブネットを使用する場合の手順を参照してください。

実行中の DNS サービスと、ポッドで使用する Active Directory サービスへの接続により、新しく作成された VNet を構成します。Microsoft Azure の Horizon Cloud ポッドに使用する VNet トポロジに必要な DNS サーバの設定

の手順を参照してください。

ファイアウォールや、その他のネットワーク動作に関連して、現在の VNet 構成が、Microsoft Azure での Horizon Cloud ポッドの DNS の要件および 2019 年 9 月のリリースのマニフェスト以降の Horizon Cloud ポッドのポート

とプロトコルの要件に記載されているとおりに、ポッドデプロイの DNS、ポート、およびプロトコルの要件に準拠

していることを確認します。

重要：ポッドの一時的なジャンプボックス仮想マシンおよびポッドのマネージャ仮想マシンでは、Microsoft Azure VNet でのアウトバウンドインターネットアクセスが必要です。専用の VNet に外部ゲートウェイをデプロイする

場合、その VNet は外部ゲートウェイの一時ジャンプボックスと、外部へのインターネットにアクセスするゲートウ

ェイコネクタ仮想マシンをサポートする必要があります。プロキシベースのアウトバウンドインターネットアクセ

スが必要な場合は、ポッドのデプロイウィザードのフィールドの入力を完了するときにプロキシサーバ情報を指定



VMware, Inc. 81

ポッドのデプロイの前に、Microsoft Azure の VNet で Horizon Cloud ポッドに必要なサブネットを作成する

ピアリングされた VNet を使用している場合、ベストプラクティスは、ポッドをデプロイする前に必要なサブネット

を作成し、デプロイウィザードを実行する前に VNet でサブネットが必要とするアドレス空間が確保されるようにす

ることです。VNet がピアリングされていない場合でも、ポッドのデプロイプロセスに必要なサブネットを作成させ

る代わりに、VNet であらかじめ作成することができます。

重要： 2019 年 9 月のリリース以降、このリリースで新しくデプロイされたポッドとこのリリースにアップグレー

ドされたポッドの両方で、ポッドの管理サブネットがポッドの Microsoft Azure Database for PostgreSQL サービ

スリソースとのネットワーク通信もサポートする必要があります。新しいポッドをデプロイする前、または既存のポ

ッドをアップグレードする前に、作成するポッド管理サブネットで、Microsoft.Sql サービスがサービスエンドポイ

ントとしてリストされている必要があります。デプロイまたはアップグレードプロセスでは、サブネットにエンドポ

イントがあるかどうかがチェックされ、サブネットでエンドポイントが有効になっていない場合は続行されません。

詳細については、Microsoft Azure で Horizon Cloud ポッド用の既存のサブネットを使用する場合を参照してくだ

さい。

サブネットを事前に作成する場合、クラスレスドメイン間ルーティング (CIDR) 表記のアドレス範囲がポッドデプロ

イウィザードの最小要求に準じていることを確認する必要があります。

n 管理サブネットの場合、/27 以上の CIDR が必要です。このサブネットは、ポッド自身の管理アクティビティに

含まれる仮想マシンで使用される IP アドレスのためのものです。

n デスクトップテナントサブネットの場合、少なくとも /27 の CIDR が必要です。本番環境では、/24 ～ /21 の

CIDR（256 ～ 2048 アドレス）を推奨します。このサブネットは、サブネット上の RDSH サーバの仮想マシン

および VDI デスクトップ仮想マシンに使用される IP アドレスのためのものです。ポッドマネージャの仮想マシ

ンは、このサブネットからの IP アドレスを使用します。ポッドに内部 Unified Access Gateway 構成がある場

合、それらの Unified Access Gateway 仮想マシンもこのサブネットからの IP アドレスを使用します。ポッド

に、ポッドの VNet を使用してデプロイされた外部ゲートウェイ構成がある場合、その外部ゲートウェイの

Unified Access Gateway 仮想マシンもこのサブネットの IP アドレスを使用します。

重要： VDI デスクトップの仮想マシン、RDS イメージ、ポッドの RDS ファーム内の各サーバはこれらの IP アドレスを使用します。このデスクトップサブネットはポッドのデプロイ後に拡張できないため、このポッドで提

供するデスクトップの数を考慮してこの範囲を十分に大きく設定します。たとえば、このポッドが将来 1000 台以上のデスクトップを提供すると予想される場合は、この範囲がそれ以上の IP アドレスを提供するようにしま

す。

n 外部の Unified Access Gateway 構成をポッドの VNet にデプロイする場合、CIDR が /28 以上の DMZ サブネ

ットが必要です。このサブネットは、Unified Access Gateway 仮想マシンの NIC がこの外部ゲートウェイ構成

のロードバランサと通信するために使用する IP アドレス用です。管理および DMZ サブネットの範囲を同じ場

所に共存させるには、IP アドレスを指定して DMZ サブネット範囲を管理サブネットと同様のものに指定するこ

とができます。たとえば、管理サブネットが 192.168.8.0/27 の場合、一致する DMZ サブネットは

192.168.8.32/27 になります。


VMware, Inc. 82

n 外部の Unified Access Gateway 構成をポッドとは別の専用の VNet にデプロイする場合、その VNet には次の

3 つのサブネットが必要です。

n 管理サブネット。/27 以上の CIDR が必要です。このサブネットは、ゲートウェイコネクタ仮想マシンな

ど、外部ゲートウェイ全体の管理アクティビティに含まれる仮想マシンによって使用される IP アドレスのた

めのものです。

n バックエンドサブネット。/27 以上の CIDR が必要です。このサブネットは、Unified Access Gateway 仮想マシンの NIC がピアリングされた VNet を介してポッドの VNet と通信するために使用する IP アドレス

のためのものです。

n フロントエンド (DMZ) サブネット。/28 以上の CIDR が必要です。このサブネットは、Unified Access Gateway 仮想マシンの NIC が外部ゲートウェイのロードバランサと通信するために使用する IP アドレス

のためのものです。管理およびフロントエンドサブネットの範囲をこの VNet 内の同じ場所に共存させる

には、IP アドレスを指定して DMZ サブネット範囲を管理サブネットと同様のものに指定することができま

す。たとえば、管理サブネットが 192.168.8.0/27 の場合、マッチしたフロントエンドサブネットは

192.168.8.32/27 になります。

重要：それぞれの CIDR は、プリフィックスとビットマスクの各組み合わせが、プリフィックスを開始 IP アドレス

とする IP アドレス範囲になるように定義する必要があります。Microsoft Azure では、CIDR プリフィックスを範囲

の先頭にする必要があります。たとえば、192.168.182.48/28 という正しい CIDR の場合、IP アドレス範囲は

192.168.182.48 ～ 192.168.182.63 になり、プリフィックスは開始 IP アドレス (192.168.182.48) と同じになりま

す。ただし、192.168.182.60/28 という間違った CIDR の場合、IP アドレス範囲は 192.168.182.48 ～

192.168.182.63 になり、開始 IP アドレスは 192.168.182.60 のプリフィックスと同じになりません。CIDR は、開

始 IP アドレスが CIDR プリフィックスと一致する IP アドレス範囲になるように定義してください。

前提条件

Microsoft リージョンに、ポッドに使用する VNet があることを確認します。Microsoft Azure で必要な仮想ネット

ワークを構成を参照してください。

サブネットに使用するアドレス範囲が重複しないことを確認します。サブネット範囲が重複していると、ポッドデプ

ロイウィザードがエラーを表示します。

手順

1 Microsoft Azure ポータルで、ここで説明したサブネットを作成する必要がある VNet に移動します。

2 [サブネット] をクリックします。

3 [+ サブネット] をクリックします。

[サブネットの追加] 画面が表示されます。

4 必須のフィールドに情報を入力します。


名前サブネットの名前を指定します。

アドレスの範囲（CIDR ブロック）サブネットの CIDR を入力します。


VMware, Inc. 83

5 [OK] をクリックします。

サブネットは、VNet に追加されます。

6 残りの必要なサブネットを追加するため、手順 3 ～ 5 を繰り返します。

7 外部ゲートウェイを専用の VNet にデプロイする場合は、その VNet のサブネットに対して手順を繰り返します。

注意：ポッドのデプロイのために VNet 上に事前に手動で作成したサブネットは空のままである必要があります。

これらのサブネットに何らかのリソースを投入したり、IP アドレスを使用したりしないでください。IP アドレスがサ

ブネットで既に使用されていると、ポッドのデプロイに失敗する可能性があります。

次のステップ

作成した管理サブネットに対して、Microsoft.Sql サービスをサービスエンドポイントとして有効にします。

Microsoft Azure で Horizon Cloud ポッド用の既存のサブネットを使用する場合を参照してください。このサービ

スはポッドの管理サブネットで有効にする必要があり、外部ゲートウェイを専用の VNet にデプロイする場合、サー

ビスはそのゲートウェイの管理サブネットでも有効にする必要があります。

Microsoft Azure で Horizon Cloud ポッド用の既存のサブネットを使用する場合

2019 年 9 月のリリース以降、このリリースで新しくデプロイされたポッドとこのリリースにアップグレードされた

ポッドの両方で、ポッドの管理サブネットが Microsoft Azure Database for PostgreSQL サービスエンドポイント

とのネットワーク通信もサポートする必要があります。新しいポッドをデプロイする前、または既存のポッドをアッ

プグレードする前に、作成するポッド管理サブネットで、Microsoft.Sql サービスをサービスエンドポイントとして

有効にする必要があります。デプロイまたはアップグレードプロセスでは、サブネットにエンドポイントがあるかど

うかがチェックされ、管理サブネットでエンドポイントが有効になっていない場合は続行されません。このサービス

エンドポイントを有効にすることに加えて、ファイアウォールまたはネットワークセキュリティグループ (NSG) ルールが管理サブネット上にある場合は、新しいポッドをデプロイしたり既存のポッドをアップグレードしたりする前

に、Microsoft Azure Database for PostgreSQL サービスに対するトラフィックを許可するように構成する必要が

あります。

重要： 2019 年 12 月のリリースでは、ポッドの外部 Unified Access Gateway 構成をポッドの VNet とは別の専用

の VNet にデプロイする機能が導入されています。この機能を使用する場合、外部ゲートウェイの VNet の管理サブ

ネットもこの要件を満たし、Microsoft.Sql サービスをそのサブネット上のサービスエンドポイントとして有効にす

る必要があります。

2019 年 9 月のリリースでは、Microsoft Azure の Horizon Cloud ポッドの必須要素としての、Microsoft Azure Database for PostgreSQL サービスの使用が導入されています。Microsoft のドキュメントで説明されているよう

に、Microsoft Azure Database for PostgreSQL は、完全に管理されたデータベースとしてのサービスを提供しま

す。ポッドのデプロイまたはアップグレードでは、単一サーバのデプロイタイプを使用して、Microsoft Azure Database for PostgreSQL サーバリソースがポッドのリソースグループにデプロイされます。デプロイおよびア

ップグレードプロセスでは、ポッドの VNet に VNet ルールも自動的に追加されます。この VNet ルールは、ポッド

の管理サブネットへの Microsoft Azure Database for PostgreSQL サーバのトラフィックを制限します。ポッド

と、その Microsoft Azure Database for PostgreSQL サーバとの間の通信では、管理サブネットを使用します。こ

れにより、ポッドの管理サブネットにいくつかの要件が適用されます。

管理サブネットで、Microsoft.Sql サービスをサービスエンドポイントとして有効にする


VMware, Inc. 84



デプロイされた Microsoft Azure Database for PostgreSQL サーバの管理サブネットへのトラフィックを制限する

VNet ルールでは、サブネットで Microsoft.Sql サービスエンドポイントが有効になっている必要があります。ポッ

ドデプロイヤによってサブネットが作成されるシナリオでは、デプロイヤによって、ポッドの管理サブネットが作成

する管理サブネット上で有効になっている Microsoft.Sql サービスエンドポイントが確保されます。ただし、管理サ

ブネットを自分で作成する場合は、新しいポッドをデプロイする前、または既存のポッドをアップグレードする前に、

管理サブネットが確実にこれらの要件を満たしている必要があります。次のスクリーンショットは、Microsoft Azure ポータルを使用して、サブネット上で Microsoft.Sql サービスをサービスエンドポイントとして有効にする例

を示しています。ポータルでサブネットをクリックした後、[サービスエンドポイント] セクションで [サービス] ドロ

ップダウンリストを使用して Microsoft.Sql を選択し、保存します。

Microsoft Azure ポータルを使用して管理サブネットに移動し、[サービス] ドロップダウンで Microsoft.Sql を選択

することができます。

ファイアウォールまたは NSG で、Microsoft Azure Database for PostgreSQL サービスへのポッド通信が許可され

ていることを確認する


VMware, Inc. 85

Microsoft Azure での Horizon Cloud ポッドの DNS の要件にリストされているように、管理サブネットでは、管理

サブネットのネットワークルールを構成して、ポッドから Microsoft Azure Database for PostgreSQL サービスへ

の通信を許可する必要があります。新しいポッドをデプロイする前、または既存のポッドをアップグレードする前に、

管理サブネットがこの要件を満たしていることを確認する必要があります。

ファイアウォールまたは NSG がサービスタグを使用してアクセスを指定することをサポートする場合は、次のいず

れかの方法でポッド通信を許可します。

n グローバル Azure SQL サービスタグ：Sql

n ポッドがデプロイされている Azure リージョンの地域固有の SQL サービスタグ：Sql.region（Sql.WestUS な

ど）

ファイアウォールまたは NSG がサービスタグを使用してアクセスを指定することをサポートしない場合は、ポッド

のリソースグループで作成されたデータベースサーバリソースのホスト名を使用できます。サーバリソースの名

前は、*.postgres.database.azure.com のパターンに従います。

セキュリティグループ内のサービスタグの詳細については、サービスタグにある Microsoft Azure ドキュメントの

トピックを参照してください。

Microsoft Azure の Horizon Cloud ポッドに使用する VNet トポロジに必要な DNS サーバの設定

Horizon Cloud ポッドがデプロイされている VNet は、内部マシン名と外部名の両方を解決できる必要があります。

ポッドのデプロイ中に、デプロイヤは Horizon Cloud 制御プレーンの外部アドレスから Microsoft Azure 環境にポ

ッドソフトウェアを安全にダウンロードします。内部仮想マシン (VM) 名を解決する機能は、Microsoft Azure 環境

に展開される仮想マシンでのポッドの Horizon Cloud Active Directory ドメイン参加の操作に必要です。

重要：最終的には、特定の DNS 名に到達する必要があるポッド関連の仮想マシンでこれを実行できることが重要

です。これを実行する必要があるポッド関連の仮想マシンによって内部マシン名と外部名の両方を解決できるように

VNet トポロジが構成されている必要があります。ポッドをデプロイする Microsoft Azure で使用している VNet トポロジによって、関連する必要なサブネットにデプロイされたポッド仮想マシンがその DNS 名前解決を取得できる

ことを確認する必要があります。DNS の解決要件の詳細については、Microsoft Azure での Horizon Cloud ポッド

の DNS の要件を参照してください。

外部ゲートウェイをポッドの VNet とは別の専用の VNet にデプロイする機能を使用する場合、前のパラグラフで説

明したように、それらの VNet をピアリングする必要があり、ユーザーおよびネットワークチームは、ピアリングさ

れた VNet トポロジがポッドの主要な DNS 要件を満たすためにそのトポロジの DNS 設定を提供していることを確

認する必要があります。Horizon Cloud ドキュメントセットは、ネットワークチームがユーザーの使用に合わせて

カスタマイズした高度な VNet トポロジの詳細については説明しません。

Microsoft Azure サブスクリプションのデフォルトでは、内部ネットワーク接続は設定されていません。本番環境で

は通常、ユーザーおよびネットワークチームは、外部名を解決でき、会社のマシン用の Microsoft Azure で動作可

能な有効な DNS サーバをポイントするように仮想ネットワークの DNS を設定します。たとえば、Microsoft Windows Server 2016 仮想マシンをその仮想ネットワークにデプロイして DNS サーバとして動作させ、仮想ネッ

トワークの DNS 設定をデプロイされた DNS サーバの IP アドレスをポイントするように構成できます。


VMware, Inc. 86

https://docs.microsoft.com/en-us/azure/virtual-network/security-overview#service-tags

概念実証の環境では、組織のプライバシとセキュリティポリシーで許可されている場合、外部の名前解決のために内

部 DNS を外部のパブリック DNS に委譲するように構成できます。その目的で、一部の組織や ISP では

208.67.222.222 の OpenDNS や 8.8.8.8 の Google Public DNS など、再帰的パブリックネームサーバを提供して

います。これらの再帰的パブリックネームサーバのサンプルリストについては、Wikipedia の記事「再帰的パブリ

ックネームサーバ」を参照してください。

前提条件

Microsoft Azure リージョンに、ポッドデプロイヤウィザードで指定することを計画している VNet トポロジがある

ことを確認します。Microsoft Azure で必要な仮想ネットワークを構成を参照してください。

その VNet トポロジに対して、ユーザーまたはネットワークチームが構成する DNS サーバ設定が、ポッドの正常な

デプロイに必要な特定の外部名に到達して解決できることを確認します。詳細については、Microsoft Azure での

Horizon Cloud ポッドの DNS の要件を参照してください。

手順

1 Microsoft Azure ポータルの左側のナビゲーションバーから、（[仮想ネットワーク]）をクリッ

クし、ポッドに使用する仮想ネットワークをクリックします。

2 [DNS サーバ]をクリックして、仮想ネットワークの DNS サーバ設定を表示します。

3 [カスタム] オプションを使用して、名前解決に使用する DNS サーバのアドレスを追加し、[保存] をクリックし

ます。

次のステップ

DNS、ポート、およびプロトコルに対するポッドデプロイヤのアクセス要件を満たしていることを VNet トポロジか

ら確認します。Microsoft Azure での Horizon Cloud ポッドの DNS の要件および 2019 年 9 月のリリースのマニ

フェスト以降の Horizon Cloud ポッドのポートとプロトコルの要件を参照してください。

Active Directory ドメインの構成

Horizon Cloud 環境では、少なくとも 1 つの Active Directory (AD) ドメインを Horizon Cloud ポッドに登録する

必要があります。このトピックでは、Microsoft Azure の Horizon Cloud ポッドでの使用がサポートされている構

成について説明します。


VMware, Inc. 87

https://en.wikipedia.org/wiki/Public_recursive_name_server

https://en.wikipedia.org/wiki/Public_recursive_name_server

サポートされる構成は以下のとおりです。

n オンプレミスの Active Directory サーバと、VPN/MPLS または Microsoft Azure Express Route を使用したそ

のオンプレミス Active Directory と Microsoft Azure 環境との接続。

n Microsoft Azure 環境で実行する Active Directory サーバ。

n Microsoft Azure の Active Directory ドメインサービスの使用。Microsoft Azure が提供するこれらのサービ

スの概要については、Microsoft のドキュメントでこの Azure Active Directory ドメインサービスの記事を参


サポートされている各構成の技術的な詳細説明や、各構成のいくつかのオプション、および各構成のメリットとデメ

リットについては、VMware のホワイトペーパー『VMware Horizon Cloud を使用した Microsoft Azure でのネッ

トワークおよび Active Directory についての考慮事項』を参照してください。

重要： Horizon Cloud 環境は Microsoft Azure および Horizon 7 ポッド（オンプレミスおよび VMware Cloud on AWS）のポッドで構成できます。そのため、クラウド接続されたすべてのポッドは、同じ Active Directory ドメ

インのセットとの通信路を確立している必要があります。環境にすでにクラウド接続された Horizon 7 ポッドがあ

り、最初のポッドを Microsoft Azure にデプロイしている場合は、すでに Horizon Cloud に登録されている Active Directory ドメインに対してポッドが通信路を確立していることを確認する必要があります。詳細については

Horizon Cloud 管理ガイドの Active Directory に関連するトピックを参照してください。

Microsoft Azure での Horizon Cloud ポッドの DNS の要件

ポッドのデプロイプロセスが正常にポッドを Microsoft Azure にデプロイするには、Horizon Cloud が必要なドメ

インネームサービス (DNS) アドレスにアクセスできるよう、ファイアウォールを構成する必要があります。さらに、

このトピックの説明に従い、DNS で特定の名前を解決する必要があります。メインポッドのデプロイに加えて、外


VMware, Inc. 88

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/



部ゲートウェイを専用の VNet にデプロイする場合、このトピックで説明するように、その VNet のサブネットは、

別のポッド VNet の管理サブネットと同じ DNS 要件を満たしている必要があります。

重要：ポッドのデプロイプロセスでは、ジャンプボックス仮想マシンを使用します。このジャンプボックス仮想

マシンには、ポッドのデプロイプロセスのためのポートとプロトコルの要件があります。ポッドのデプロイと更新中

にポッドのジャンプボックスで必要となるポートとプロトコルを参照してください。

外部ゲートウェイを専用の VNet にデプロイする場合も、ポッドとは別の専用のジャンプボックス仮想マシンを使用

します。このジャンプボックス仮想マシンには、ゲートウェイデプロイプロセスのための専用のポートおよびプロ

トコル要件があります。外部ゲートウェイが専用の VNet にデプロイされている場合：ゲートウェイのデプロイおよ

び更新中に外部ゲートウェイ構成のジャンプボックスに必要なポートとプロトコルを参照してください。

ポッドが正常にデプロイされたら、Horizon Cloud の継続的な運用のためには特定のポートおよびプロトコルが必要

です。必要な特定のポートとプロトコルは、ポッドが 2019 年 9 月のリリースのマニフェストバージョンであるか、

または以前のマニフェストバージョンであるかによって異なります。

n 2019 年 9 月のリリース以降に作成されたポッド、またはそのリリースのマニフェストバージョン以降にアップ

グレードされたポッドの場合は、2019 年 9 月のリリースのマニフェスト以降の Horizon Cloud ポッドのポート

とプロトコルの要件を参照してください。そのようなポッドには、1593 以降のマニフェストバージョンがあり

ます。

n 2019 年 9 月のリリース以前に作成されたポッド、またはそのリリースのマニフェストバージョンにまだアップ

グレードされていないポッドの場合は、2019 年 9 月のリリースより前にデプロイされた Horizon Cloud ポッド

のポートとプロトコルの要件を参照してください。そのようなポッドには、1493.1 以前のマニフェストバージ

ョンがあります。

n ポッドの全体的なデプロイプロセス、ポッドのアップグレード、および継続的な運用に関する DNS の要件

n ポッドのデプロイと更新中にポッドのジャンプボックスで必要となるポートとプロトコル

n 外部ゲートウェイが専用の VNet にデプロイされている場合：ゲートウェイのデプロイおよび更新中に外部ゲー

トウェイ構成のジャンプボックスに必要なポートとプロトコル

ポッドの全体的なデプロイプロセス、ポッドのアップグレード、および継続的な運用に関する DNS の要件

次の DNS 名が解決可能であり、次の表に記載されている特定のポートおよびプロトコルを使用して管理およびテナ

ントサブネットからアクセス可能であるようにする必要があります。Horizon Cloud は、特定の送信ポートを使用

して、Microsoft Azure 環境に安全にポッドソフトウェアをダウンロードし、ポッドが Horizon Cloud 制御プレー

ンに戻ることができるようにします。Horizon Cloud が必要なポートで DNS アドレスに連絡できるよう、ネットワ

ークファイアウォールを構成する必要があります。そうしないと、ポッドのデプロイプロセスは失敗します。

重要：この機能を使用して外部ゲートウェイを専用の VNet にデプロイする場合、その VNet の管理サブネットは、

以下の表に記載されているポッドの VNet の管理サブネットの場合と同じ DNS 要件を満たす必要があります。外部

ゲートウェイ VNet のバックエンドサブネットと DMZ サブネットには、特定の DNS 要件はありません。


VMware, Inc. 89

表 2-10. ポッドのデプロイと操作に関する DNS の要件

サブネットソースターゲット (DNS 名) ポートプロトコル目的

管理 Horizon Cloud アカウントで指定されている

Horizon Cloud 制御プレーンに応じて、次のいずれ

か：

cloud.horizon.vmware.com

cloud-eu-central-1.horizon.vmware.com

cloud-ap-southeast-2.horizon.vmware.com

443 TCP Horizon Cloud 制御プ

レーン。

米国では、

cloud.horizon.vmware.com です。

ヨーロッパでは、cloud-eu-central-1.horizon.vmware.com です。

オーストラリアでは、

cloud-ap-southeast-2.horizon.vmware.com です。

管理 softwareupdate.vmware.com 443 TCP VMware ソフトウェア

パッケージサーバ。シ

ステムのイメージに関連

する操作で使用されてい

るエージェントに関連す

るソフトウェアの更新を

ダウンロードするために

使用します。

管理 d1mes20qfad06k.cloudfront.net 443 TCP Horizon Cloud コンテ

ンツ配信サーバ。管理サ

ブネット上で、このサイ

トはポッドのマネージャ

および Unified Access Gateway 仮想マシンの

VHD（仮想ハードディ

スク）をダウンロードす

るために使用されます。

外部ゲートウェイが独自

の VNet にある場合は、

ゲートウェイコネクタ

仮想マシンの VHD にも

使用されます。

管理 packages.microsoft.com 443 および

11371TCP Microsoft ソフトウェ

アパッケージサーバ。

Microsoft Azure コマ

ンドラインインターフ

ェイス (CLI) ソフトウェ

アを安全にダウンロード

するために使用します。


VMware, Inc. 90

表 2-10. ポッドのデプロイと操作に関する DNS の要件（続き）


管理 azure.archive.ubuntu.com 80 TCP Ubuntu ソフトウェア

パッケージサーバ。

Ubuntu オペレーティ

ングシステムの更新用

にポッド関連の Linux ベースの仮想マシンによ

って使用されます。

管理 api.snapcraft.io 443 TCP Ubuntu ソフトウェア




にポッドの Linux ベー

スの仮想マシンによって


管理 archive.ubuntu.com 80 TCP Ubuntu ソフトウェア







管理 changelogs.ubuntu.com 80 TCP Ubuntu ソフトウェア



ングシステムの更新の

追跡用にポッドの

Linux ベースの仮想マ

シンによって使用されま

す。

管理 security.ubuntu.com 80 TCP Ubuntu ソフトウェア

パッケージサーバ。セ

キュリティ関連の







VMware, Inc. 91



管理ポッドをデプロイする Microsoft Azure クラウドに

応じて、以下のいずれかになります。

n Microsoft Azure（グローバル）：

login.microsoftonline.com

n Microsoft Azure Germany：

login.microsoftonline.de

n Microsoft Azure China：

login.chinacloudapi.cn

n Microsoft Azure US Government：login.microsoftonline.us

443 TCP この Web アドレスは通

常、アプリケーションに

よって Microsoft Azure サービスを認証

するために使用されま

す。Microsoft Azure ドキュメントでの関連す

る説明については、

「OAuth 2.0 承認コード

フロー」、「Azure Active Directory v2.0 および

OpenID Connect プロ

トコル」、および

「National Clouds」を


「National Clouds」の

トピックでは、各

Microsoft Azure National Cloud に対応

する Azure AD 認証エ

ンドポイントの相違点に

ついて説明します。




management.azure.com


management.microsoftazure.de


management.chinacloudapi.cn

n Microsoft Azure US Government：management.usgovcloudapi.net

443 TCP Microsoft Azure Resource Manager エンドポイントへのポッド

API リクエストで、

Microsoft Azure Resource Manager サービスを使用するために


Microsoft Azure Resource Manager は、Azure PowerShell、Azure CLI、Azure ポー

タル、REST API、および

クライアント SDK を通

じてタスクを実行するた

めの一貫した管理レイヤ

ーを提供します。




graph.windows.net


graph.cloudapi.de


graph.chinacloudapi.cn

n Microsoft Azure US Government：graph.windows.net

443 TCP Azure Active Directory (Azure AD) Graph API へのアクセ

ス。これは、OData REST API エンドポイン

トを介した Azure Active Directory (Azure AD) へのポッド

によるプログラムアク

セスに使用されます。


VMware, Inc. 92

https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow


https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc




https://docs.microsoft.com/en-us/azure/active-directory/develop/authentication-national-cloud

https://docs.microsoft.com/en-us/azure/active-directory/develop/authentication-national-cloud



管理ポッドをデプロイした Microsoft Azure クラウドに



*.blob.core.windows.net


*.blob.core.cloudapi.de


*.blob.core.chinacloudapi.cn

n Microsoft Azure US Government：*.blob.core.usgovcloudapi.net

443 TCP Azure BLOB ストレー

ジへのポッドによるプロ

グラムアクセスに使用

されます。Azure Blob Storage は、大量の非構

造化オブジェクトデー

タ（テキストやバイナリ

データなど）を格納する

サービスです。

管理ポッドをデプロイした Microsoft Azure クラウドに



*.vault.azure.net


*.vault.microsoftazure.de

n Microsoft Azure China：*.vault.azure.cn

n Microsoft Azure US Government：*.vault.usgovcloudapi.net

443 TCP Azure Key Vault クラ

ウドサービスでポッド

をプログラムを通じて動

作させる機能に使用され

ます。Azure Key Vault は、シークレットの安全

なストアを提供するクラ

ウドサービスです。

管理ファイアウォールまたはネットワークセキュリティ

グループ (NSG) でサービスタグの使用がサポートさ

れている場合は、以下のいずれかになります。


n ポッドがデプロイされている Azure リージョン

の地域固有の SQL サービスタグ：Sql.region

（Sql.WestUS など）

ファイアウォールまたはネットワークセキュリティ


れていない場合は、データベースのホスト名を使用で

きます。この名前は、

*.postgres.database.azure.com のパターンに従い

ます。

5432 TCP Microsoft Azure PostgreSQL データベ

ースサーバへのポッド

の通信に使用されます。

2019 年 9 月のリリース

以降、リリース日以降に

新たにデプロイされたポ

ッドと、そのリリースの

マニフェストバージョ

ンにアップグレードされ

たポッドは、Microsoft Azure PostgreSQL データベースサーバを使

用して構成されます。

セキュリティグループ

内のサービスタグの詳

細については、サービス

タグにある Microsoft Azure ドキュメントの

トピックを参照してくだ

さい。


VMware, Inc. 93





テナント d1mes20qfad06k.cloudfront.net 443 TCP Horizon Cloud コンテ

ンツ配信サーバ。テナン

トサブネット上で、この

サイトは、エージェント

に関連するソフトウェア

のインストーラをダウン

ロードするために、シス

テムの自動化されたイメ

ージのインポートプロ

セスによって使用されま

す。

テナント Horizon Cloud アカウントにどのリージョンの

Horizon Cloud 制御プレーンが指定されているかに

応じて異なります。

北米：



ヨーロッパ：

n kinesis.eu-central-1.amazonaws.com

n query-prod-eu-central-1.cms.vmware.com

オーストラリア：

n kinesis.ap-southeast-2.amazonaws.com

n query-prod-ap-southeast-2.cms.vmware.com


(CMS)

ポッドのデプロイと更新中にポッドのジャンプボックスで必要となるポートとプロトコル

Microsoft Azure の Horizon Cloud ポッドに対する Microsoft Azure 仮想マシンの要件で説明するとおり、ジャン

プボックス仮想マシンは、ポッドの最初の作成時、およびポッドの環境上でその後実行されるソフトウェア更新時に

使用されます。ポッドの作成後、ジャンプボックス仮想マシンは削除されます。その後、ポッドの更新中に、ジャン

プボックス仮想マシンがその更新プロセスを実行するために再作成され、更新が完了すると削除されます。このよう

な更新には、ポッドを編集してゲートウェイを追加するときが含まれます。

注： 2019 年 9 月のリリース以降の Microsoft Azure で新規にデプロイされたポッド、または 2019 年 9 月のリリ

ースのマニフェストレベルにアップグレードされて高可用性が有効になっているポッドには、2 台のマネージャ仮想

マシンがあります。次以降のパラグラフでは、仮想マシンという単語の複数形を使用して、ポッドのマネージャ仮想

マシンが 1 台だけの場合でも 2 台の場合でも、ジャンプボックス仮想マシンはすべてのマネージャ仮想マシンと通

信する必要があることを示します。


VMware, Inc. 94

これらのプロセス中に、ジャンプボックス仮想マシンはポッドのマネージャ仮想マシンのポート 22 に SSH 接続し

て、マネージャ仮想マシンと通信します。その結果、ポッドのデプロイおよび更新プロセス中には、ジャンプボック

ス仮想マシンとマネージャ仮想マシンのポート 22 との間の通信を維持するという要件を満たす必要があります。接

続元であるジャンプボックス仮想マシンと接続先であるマネージャ仮想マシンの間でマネージャ仮想マシンのポー

ト 22 が許可される必要があります。これらの仮想マシンには IP アドレスが動的に割り当てられるため、この通信を

許可するネットワークルールでは、送信先ポートに 22、送信元ポートに任意、プロトコルに TCP を指定し、管理サ

ブネット CIDR を接続元ポートと接続先ポートの両方として使用する必要があります。

注：ポッドの継続的な運用では、ポッドのマネージャ仮想マシン上でポート 22 が使用可能である必要はありませ

ん。ただし、VMware に対してサポートリクエストを送信し、サポートチームがそのリクエストを解決するために

はポッドのマネージャ仮想マシンと SSH 通信するためのジャンプボックス仮想マシンをデプロイする必要があると

判断した場合、VMware サポートチームが問題をデバッグするためにポートを必要としている間は、このポート要

件を満たす必要があります。VMware サポートチームは、サポート状況に応じて必要な情報をユーザーに通知しま

す。

外部ゲートウェイが専用の VNet にデプロイされている場合：ゲートウェイのデプロイおよび更新中に外部ゲートウ

ェイ構成のジャンプボックスに必要なポートとプロトコル

Microsoft Azure の Horizon Cloud ポッドに対する Microsoft Azure 仮想マシンの要件で説明するとおり、ジャン

プボックス仮想マシンは、専用の VNet での外部ゲートウェイの最初の作成時、およびその外部ゲートウェイでその

後実行されるソフトウェアの更新時に使用されます。外部ゲートウェイが専用の VNet に作成されると、ジャンプボックス仮想マシンが削除されます。その後、その外部ゲートウェイの更新中に、ジャンプボックス仮想マシンがその

更新プロセスを実行するために再作成され、更新が完了すると削除されます。このような更新には、ポッドを編集し

て専用の VNet に外部ゲートウェイを追加する場合などがあります。

これらのプロセス中に、ジャンプボックス仮想マシンはゲートウェイコネクタ仮想マシンのポート 22 に SSH 接続

して、そのコネクタ仮想マシンと通信します。その結果、ゲートウェイのデプロイおよび更新中には、ジャンプボッ

クス仮想マシンとコネクタ仮想マシンのポート 22 との間の通信を維持するという要件を満たす必要があります。接

続元であるジャンプボックス仮想マシンと接続先であるコネクタ仮想マシンの間でコネクタ仮想マシンのポート 22 が許可される必要があります。これらの仮想マシンには IP アドレスが動的に割り当てられるため、この通信を許可す

るネットワークルールでは、送信先ポートに 22、送信元ポートに任意、プロトコルに TCP を指定し、管理サブネッ

ト CIDR を接続元ポートと接続先ポートの両方として使用する必要があります。

注：ポッドの継続的な運用では、ゲートウェイコネクタの仮想マシン上でポート 22 が使用可能である必要はあり

ません。ただし、VMware に対してサポートリクエストを送信し、サポートチームがそのリクエストを解決するた

めにはそのゲートウェイのコネクタ仮想マシンと SSH 通信するためのジャンプボックス仮想マシンをデプロイする

必要があると判断した場合、VMware サポートチームが問題をデバッグするためにポートを必要としている間は、

このポート要件を満たす必要があります。VMware サポートチームは、サポート状況に応じて必要な情報をユーザ

ーに通知します。

2019 年 9 月のリリースのマニフェスト以降の Horizon Cloud ポッドのポートとプロトコルの要件

Horizon Cloud の継続的な運用のために、2019 年 9 月のリリース以降に Microsoft Azure で新規にデプロイされた

ポッドまたは 2019 年 9 月のリリースレベルにアップグレードされているポッドには、以前にデプロイされたポッド


VMware, Inc. 95

とは異なる特定のポートおよびプロトコルの要件があります。新規にデプロイされたポッド、または 2019 年 9 月の

リリースにアップグレードされたポッドには、1600 以降のマニフェストバージョンがあります。

重要：ここで説明するポートとプロトコルに加えて、DNS の要件も満たす必要があります。詳細については、

Microsoft Azure での Horizon Cloud ポッドの DNS の要件を参照してください。

継続的な運用のために主要なポッドコンポーネントで必要となるポートとプロトコル

DNS の要件に加えて、デプロイ後に進行中の操作に関してポッドが正常に操作されるためには、次の表に記載された

ポートおよびプロトコルが必要です。

下記の表では、マネージャ仮想マシンという用語はポッドのマネージャ仮想マシンを意味します。Microsoft Azure ポータルでは、この仮想マシンには vmw-hcs-podID（podID はポッドの UUID）や node を含む名前が付けられま

す。

重要：高可用性が有効になっているポッドには、2 台のマネージャ仮想マシンがあります。高可用性が無効になっ

ているポッドには、1 台のみのマネージャ仮想マシンがあります。下記の表では、マネージャ仮想マシンという用語

が示されている場合、特に指定がない限り、それは高可用性が有効なポッド内のすべてのマネージャ仮想マシンに適

用されます。

2019 年 9 月のリリースのマニフェストバージョン以降のすべてのポッドには、ポッドの Microsoft Azure ロード

バランサが 1 台あります。ポッドのロードバランサに関連するテーブル行は、1600 以降のマニフェストレベルのす

べてのポッドに適用されます。

表 2-11. ポッドの操作に関するポートおよびプロトコル

ソースターゲットポー

ト

プロトコル目的

マネージャ仮

想マシン

ポッドのその

他のマネージ

ャ仮想マシン

4101

TCP 高可用性が有効になっているポッドの場合、このトラフィックはマネージャ仮想マシン

間の JMS ルーティングです。

ポッドの

Microsoft Azure ロー

ドバランサ

マネージャ仮

想マシン

8080

HTTP ロードバランサのバックエンドプール内の仮想マシンの健全性チェック。このリリー

スのマニフェストバージョンのポッドで高可用性が有効になっていない場合、ロードバランサには、チェックする 1 台のマネージャ仮想マシンがそのバックエンドプールにあ

ります。

マネージャ仮

想マシン

ドメインコントローラ

389 TCP

UDP

LDAP サービス。Active Directory 構成内のドメインコントローラの役割が含まれて

いるサーバ。Active Directory へのポッドの登録が必要です。

マネージャ仮

想マシン

グローバル

カタログ

3268

TCP LDAP サービス。Active Directory 構成内のグローバルカタログの役割が含まれてい

るサーバ。Active Directory へのポッドの登録が必要です。

マネージャ仮

想マシン


88 TCP

UDP

Kerberos サービス。Active Directory 構成内のドメインコントローラの役割が含まれ

ているサーバ。Active Directory へのポッドの登録が必要です。

マネージャ仮

想マシン

DNS サーバ 53 TCP

UDP

DNS サービス。

マネージャ仮

想マシン

NTP サーバ 123 UDP NTP サービス。NTP の時刻同期を提供するサーバ。

マネージャ仮

想マシン

True SSO 登録サーバ

32111

TCP True SSO 登録サーバ。ポッドで True SSO 登録サーバの機能を使用していない場合は

省略できます。


VMware, Inc. 96

表 2-11. ポッドの操作に関するポートおよびプロトコル（続き）


ト


マネージャ仮

想マシン

Workspace ONE Access サービス

443 HTTPS ポッドで Workspace ONE Access を使用していない場合は省略できます。ポッドと

Workspace ONE Access サービス間の信頼関係を作成するために使用します。使用中

の Workspace ONE Access 環境（オンプレミスまたはクラウドサービス）に対して、

ポッドがポート 443 でアクセスできることを確認します。Workspace ONE Access クラウドサービスを使用している場合、Workspace ONE Access Connector および

ポッドがアクセス権を持つ必要のある、Workspace ONE Access サービスの IP アドレ

スのリスト（VMware のナレッジベースの記事 KB2149884 にある）も参照してくださ

い。

一時的なジャ

ンプボック

ス仮想マシン

マネージャ仮

想マシン

22 TCP ポッドのデプロイと更新中にポッドのジャンプボックスで必要となるポートとプロトコ

ルで説明したように、一時的なジャンプボックスは、ポッドのデプロイおよびポッドの

更新中に使用されます。進行中のプロセスがこれらのポートを必要としない場合でも、

ポッドのデプロイおよびポッドの更新中は、このジャンプボックス仮想マシンはマネー

ジャ仮想マシンのポート 22 への SSH を使用してマネージャ仮想マシンと通信する必要

があります。ジャンプボックス仮想マシンでこの通信が必要になる場合の詳細について

は、ポッドのデプロイと更新中にポッドのジャンプボックスで必要となるポートとプロ

トコルを参照してください。

注：マニフェストバージョンが 1600 以降で、高可用性機能が有効になっているポッ

ドには、2 台のマネージャ仮想マシンがあります。前述のパラグラフでは、仮想マシンと

いう単語の複数形を使用して、ポッドのマネージャ仮想マシンが 1 台だけの場合でも 2 台の場合でも、ジャンプボックス仮想マシンはすべてのマネージャ仮想マシンと通信す

る必要があることを示します。

ゲートウェイコネクタ仮想マシンのポートとプロトコルの要件

この表は、外部ゲートウェイを別の VNet にデプロイしたときに使用されるゲートウェイのコネクタ仮想マシンに適

用されます。DNS の要件に加えて、デプロイ後に継続的な運用に関して外部ゲートウェイが正常に操作されるために

は、次の表に記載されたポートおよびプロトコルが必要です。

次の表では、コネクタ仮想マシンという用語は、クラウド管理プレーンと外部ゲートウェイ間の接続を管理するゲー

トウェイのコネクタ仮想マシンを指します。Microsoft Azure ポータルでは、この仮想マシンには vmw-hcs-ID（ID はゲートウェイのデプロイヤ ID）や node を含む名前が付けられます。



ト


コネクタ仮想

マシン


UDP

DNS サービス。

コネクタ仮想

マシン


一時的なジャ

ンプボック

ス仮想マシン

コネクタ仮想

マシン


ルで説明したように、一時的なジャンプボックスは、外部ゲートウェイのデプロイおよ

び更新中に使用されます。進行中のプロセスがこれらのポートを必要としない場合で

も、デプロイおよび更新中は、このジャンプボックス仮想マシンはコネクタ仮想マシン

のポート 22 への SSH を使用してコネクタ仮想マシンと通信する必要があります。


VMware, Inc. 97

Unified Access Gateway 仮想マシンのポートとプロトコルの要件

DNS および上記のプライマリポートとプロトコルの要件に加え、次の表のポートとプロトコルは、デプロイ後の継

続的な運用のために適切に動作するようにポッドで構成したゲートウェイに関連しています。

Unified Access Gateway インスタンスで構成されている高可用性が有効なポッドを使用した接続では、トラフィッ

クは次の表に記載されているようにポッドの Unified Access Gateway インスタンスからターゲットに対して許可

される必要があります。ポッドのデプロイ中に、ネットワークセキュリティグループ (NSG) は、ポッドの Unified Access Gateway ソフトウェアによる使用に対応するために Microsoft Azure 環境に作成されます。

表 2-13. ポッドの Unified Access Gateway インスタンスからのトラフィックに関するポートの要件

ソースターゲットポートプロトコル目的

Unified Access Gateway

ポッドの


443 TCP ログイン認証トラフィック。Unified Access Gateway インスタンスから

のトラフィックは、ポッドのロードバランサを経由してポッドのマネージャ

仮想マシンに到達します。


デスクトップまた

はファームサーバ

仮想マシン内の

Horizon Agent

4172 TCP

UDP

PCoIP





Horizon Agent

22443 TCP

UDP

Blast Extreme

デフォルトでは、Blast Extreme を使用する場合、クライアントドライブリダイレクト (CDR) トラフィックおよび USB トラフィックはこのポート内で

サイドチャネルされます。好みに応じて、CDR トラフィックは TCP 9427 ポート上で、および USB リダイレクトトラフィックは TCP 32111 ポート

上で分離できます。





Horizon Agent

9427 TCP クライアントドライブリダイレクト (CDR) とマルチメディアリダイレク

ト (MMR) トラフィックでは省略できます。





Horizon Agent

32111 TCP USB リダイレクトトラフィックでは省略できます。


RADIUS インスタ

ンス

1812 UDP その Unified Access Gateway の構成に RADIUS 2 要素認証を使用する場

合。RADIUS のデフォルト値はここに表示されます。

エンドユーザーの接続トラフィックのポートとプロトコルの要件

エンドユーザーが Horizon Cloud ポッドで使用する可能性のあるさまざまな Horizon Client の詳細については、

https://docs.vmware.com/jp/VMware-Horizon-Client/index.html にある Horizon Client のドキュメントペー

ジを参照してください。エンドユーザーの接続によるトラフィックで、ポッドがプロビジョニングされた仮想デスク

トップおよびリモートアプリケーションにアクセスするためにどのポートが開かれていなければならないかは、エン

ドユーザーが接続する方法に関する選択内容によって異なります。

ポッド専用の VNet で外部

ゲートウェイ構成を使用す

デプロイヤは、Microsoft Azure 環境に Unified Access Gateway インスタンスを

デプロイします。このとき、そのロードバランサのバックエンドプールのインスタ

ンスに Microsoft Azure ロードバランサリソースもデプロイされます。このロー


VMware, Inc. 98

https://docs.vmware.com/jp/VMware-Horizon-Client/index.html


るためのデプロイヤオプシ

ョンを選択する場合

ドバランサは、DMZ サブネット上のこれらのインスタンスの NIC と通信し、

Microsoft Azure でのパブリックロードバランサとして構成されます。図 2-1. 高可用性が有効で、外部ゲートウェイと内部ゲートウェイの両方の構成が設定され、

ポッドと同じ VNet に外部ゲートウェイがデプロイされ、外部ゲートウェイのロー

ドバランサでパブリック IP アドレスが有効になっているポッドの Horizon Cloud Pod アーキテクチャの図は、このパブリックロードバランサと Unified Access Gateway インスタンスの場所を示します。ポッドがこの構成を使用している場合、

インターネット上のエンドユーザーからのトラフィックは、Unified Access Gateway インスタンスに要求を配信するロードバランサに向かいます。この構成

に対しては、これらのエンドユーザー接続が、次のリストにあるポートおよびプロ

トコルを使用してロードバランサにアクセス可能であるようにする必要がありま

す。デプロイ後に、外部ゲートウェイのロードバランサは vmw-hcs-podID-uag と

いう名前のリソースグループにあります。ここで podID はポッドの UUID です。

内部 Unified Access Gateway 構成を使用するた

めのデプロイヤオプション

を選択する場合

内部ゲートウェイ構成は、デフォルトでポッド専用の VNet にデプロイされます。


デプロイします。このとき、そのバックエンドプールのインスタンスに Microsoft Azure ロードバランサリソースもデプロイされます。このロードバランサは、テ

ナントサブネット上のこれらのインスタンスの NIC と通信し、Microsoft Azure での内部ロードバランサとして構成されます。図 2-1. 高可用性が有効で、外部ゲート

ウェイと内部ゲートウェイの両方の構成が設定され、ポッドと同じ VNet に外部ゲ

ートウェイがデプロイされ、外部ゲートウェイのロードバランサでパブリック IP アドレスが有効になっているポッドの Horizon Cloud Pod アーキテクチャの図は、

この内部ロードバランサと Unified Access Gateway インスタンスの場所を示し

ます。ポッドがこの構成を使用している場合、企業ネットワーク内のエンドユーザ

ーからのトラフィックは、Unified Access Gateway インスタンスに要求を配信す

るロードバランサに向かいます。この構成に対しては、これらのエンドユーザー接

続が、次のリストにあるポートおよびプロトコルを使用してロードバランサにアク

セス可能であるようにする必要があります。デプロイ後に、内部ゲートウェイのロ

ードバランサは vmw-hcs-podID-uag-internal という名前のリソースグループ

にあります。ここで podID はポッドの UUID です。

ポッドではなく、専用の

VNet で外部ゲートウェイ

構成を使用する、または専用

のサブスクリプションを使

用するオプション（VNet は複数のサブスクリプション

にまたがらないため、これは

専用の VNet を使用する特

別なサブケースです）のいず

れかのデプロイヤオプショ

ンを選択する場合


デプロイします。このとき、そのロードバランサのバックエンドプールのインスタ

ンスに Microsoft Azure ロードバランサリソースもデプロイされます。このロー

ドバランサは、DMZ サブネット上のこれらのインスタンスの NIC と通信し、

Microsoft Azure でのパブリックロードバランサとして構成されます。図 2-2. 外部ゲートウェイがポッドの VNet とは別の専用の VNet にデプロイされている場合

の外部ゲートウェイのアーキテクチャ要素の図は、このパブリックロードバランサ

と、ゲートウェイ専用の VNet 内の Unified Access Gateway インスタンスの場所

を示します。ポッドがこの構成を使用している場合、インターネット上のエンドユーザーからのトラフィックは、Unified Access Gateway インスタンスに要求を配

信するロードバランサに向かいます。この構成に対しては、これらのエンドユーザ

ー接続が、次のリストにあるポートおよびプロトコルを使用してロードバランサに


VMware, Inc. 99

https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview#publicloadbalancer



https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview#internalloadbalancer




アクセス可能であるようにする必要があります。デプロイ後、外部ゲートウェイの

ロードバランサは、vmw-hcs-ID-uag という名前のリソースグループにあります。

ここで ID は、ポッドの詳細ページの [デプロイヤ ID] フィールドに表示される値で

す。『管理ガイド』の説明に従って、管理コンソールの [キャパシティ] ページからポ

ッドの詳細ページにアクセスします。

Workspace ONE Access をポッドと統合している場

合や、内部ユーザーが VPN 経由で直接接続することを

許可している場合など、ポッ

ドで Unified Access Gateway 構成をゼロにする

ことを選択する場合

注目: 本番システムでの内部ユーザーアクセスのベストプラクティスは、ポッド

への直接接続ではなく、ポッドでの内部 Unified Access Gateway ゲートウェイ構

成を使用することです。

Workspace ONE Access がポッドと統合されている場合、通常エンドユーザーは

Workspace ONE Access を介して接続します。Workspace ONE Access が

Microsoft Azure の Horizon Cloud ポッドと統合されている場合、ポッドを直接指

すように構成する必要があります。したがって、エンドユーザーが Workspace ONE Access を使用してポッドがプロビジョニングされたリソースに接続している

場合、ポッドで Unified Access Gateway を構成する必要はありません。この構成

の場合、『VMware Horizon Cloud Service 管理ガイド』の説明に従って、管理コ

ンソールのポッドの [サマリ] ページを使用して、SSL 証明書をポッドのマネージャ

仮想マシンにアップロードします。次に、Workspace ONE Access をポッドと統

合する手順を完了します。

表 2-14. ポッドの構成に外部 Unified Access Gateway インスタンスがある場合の外部エンドユーザー接続のポー

トおよびプロトコル


ト


Horizon Client

これらの Unified Access Gateway インスタンスの


443 TCP ログイン認証トラフィック。クライアントドライブリダイレクト (CDR)、マルチメディアリダイレクト (MMR)、USB リダイレクト、および RDP トラフィックのトン

ネルも実行できます。

SSL（HTTPS アクセス）は、デフォルトでクライアント接続に対して有効化されてい

ます。ポート 80（HTTP アクセス）は、いくつかの場合に使用できます。『VMware Horizon Cloud Service 管理ガイド』で「URL コンテンツリダイレクトについて」

のトピックを参照してください。

Horizon Client



4172 TCP

UDP

Unified Access Gateway 上の PCoIP Secure Gateway を介した PCoIP

Horizon Client



443 TCP データトラフィック用の Unified Access Gateway 上の Blast Secure Gateway を介した Blast Extreme。


VMware, Inc. 100


トおよびプロトコル（続き）


ト


Horizon Client



443 UDP データトラフィック用の Unified Access Gateway を介した Blast Extreme。

Horizon Client



8443 UDP データトラフィック用の Unified Access Gateway 上の Blast Secure Gateway を介した Blast Extreme（アダプティブトランスポート）。

ブラウザこれらの Unified Access Gateway インスタンスの


443 TCP HTML Access

表 2-15. ポッドの構成に内部 Unified Access Gateway インスタンスがある場合の内部エンドユーザー接続のポー



ト


Horizon Client








Horizon Client



4172 TCP

UDP


Horizon Client




Horizon Client





VMware, Inc. 101


トおよびプロトコル（続き）


ト


Horizon Client






443 TCP HTML Access

表 2-16. VPN を介するなどの直接ポッド接続を使用する場合の内部エンドユーザー接続のポートおよびプロトコル

ソースターゲットポートプロトコ

ル

目的

Horizon Client

ポッドの


443 TCP ログイン認証トラフィック。クライアントからのトラフィックは、ポッドのロードバランサを経由してポッドのマネージャ仮想マシンに到達します。

Horizon Client




Horizon Agent

4172 TCP

UDP

PCoIP

Horizon Client




Horizon Agent

22443 TCP

UDP

Blast Extreme

Horizon Client




Horizon Agent

32111 TCP USB リダイレクト

Horizon Client




Horizon Agent

9427 TCP クライアントドライブリダイレクト (CDR) とマルチメディアリダイレクト

(MMR)

ブラウザデスクトップまた



Horizon Agent

443 TCP HTML Access

Horizon Agent と VDI デスクトップおよびファーム間で必要なポートとプロトコル

次のポートは、デスクトップ仮想マシンとファームサーバ仮想マシンにインストールされている Horizon Agent に関連するソフトウェアから高可用性が有効なポッドのマネージャ仮想マシンへのトラフィックを許可する必要があり

ます。


VMware, Inc. 102


デスクトップ

またはファー

ムサーバ仮

想マシン内の

Horizon Agent

マネージャ仮想マ

シン

4002 TCP セキュリティ強化を使用する場合の Java Message Service (JMS) (デフォ

ルト)

デスクトップ

またはファー

ムサーバ仮

想マシン内の

Horizon Agent


シン

4001 TCP Java Message Service (JMS)、レガシー

デスクトップ

またはファー

ムサーバ仮

想マシン内の

Horizon Agent


シン

3099 TCP デスクトップメッセージサーバ

デスクトップ

またはファー

ムサーバ仮

想マシンの

FlexEngine エージェント

（VMware Dynamic Environment Manager のエージェン

ト）



仮想マシンで実行

される

FlexEngine エー

ジェントによる使

用のためにセット

アップしたファイ

ル共有

445 TCP VMware Dynamic Environment Manager 機能を使用している場合、

SMB ファイル共有への FlexEngine エージェントアクセス。

ポッドのデプロイプロセスの一環として、デプロイヤはデプロイされたすべての仮想マシンのネットワークインタ

ーフェイス (NIC) にネットワークセキュリティグループ (NSG) を作成します。これらの NSG で定義されているル

ールの詳細については、『Horizon Cloud 管理ガイド』を参照してください。

注： DNS 名、IP アドレス、ポート、およびプロトコルを Horizon Cloud ナレッジベース (KB) の記事に記載する代

わりに、コアの Horizon Cloud ドキュメントの一部としてここに提供しています。

2019 年 9 月のリリースより前にデプロイされた Horizon Cloud ポッドのポートとプロトコルの要件

Horizon Cloud の継続的な運用のために、Microsoft Azure で 2019 年 9 月のリリースより前にデプロイされたポッ

ドには、特定のポートとプロトコルの要件があります。これは、2019 年 9 月のリリースのマニフェストバージョン

でデプロイされたポッドや、2019 年 9 月のリリースのマニフェストバージョンにアップグレードされたポッドとは

異なる要件です。2019 年 9 月のリリースより前にデプロイされたポッドのマニフェストバージョンは、1493.1 より前になります。

重要：ここで説明するポートとプロトコルに加えて、DNS の要件も満たす必要があります。詳細については、

Microsoft Azure での Horizon Cloud ポッドの DNS の要件を参照してください。


VMware, Inc. 103


マニフェストバージョンのポッドの継続的な運用のために必要なポートとプロトコル

DNS の要件に加えて、デプロイ後に進行中の操作に関してポッドが正常に操作されるためには、次の表に記載された

ポートおよびプロトコルが必要です。

注：このセクションの表では、マネージャ仮想マシンという用語はポッドのマネージャ仮想マシンを意味します。

Microsoft Azure ポータルでは、この仮想マシンには vmw-hcs-podID（podID はポッドの UUID）や node を含む名

前が付けられます。



ト


マネージャ仮

想マシン


389 TCP

UDP

LDAP サービス。Active Directory 構成内のドメインコントローラの役割が含まれて

いるサーバ。Active Directory へのポッドの登録が必要です。

マネージャ仮

想マシン

グローバル

カタログ

3268

TCP LDAP サービス。Active Directory 構成内のグローバルカタログの役割が含まれてい

るサーバ。Active Directory へのポッドの登録が必要です。

マネージャ仮

想マシン


88 TCP

UDP

Kerberos サービス。Active Directory 構成内のドメインコントローラの役割が含まれ

ているサーバ。Active Directory へのポッドの登録が必要です。

マネージャ仮

想マシン


UDP

DNS サービス。

マネージャ仮

想マシン


マネージャ仮

想マシン

True SSO 登録サーバ

32111

TCP True SSO 登録サーバ。ポッドで True SSO 登録サーバの機能を使用していない場合は

省略できます。

マネージャ仮

想マシン

Workspace ONE Access サービス

443 HTTPS ポッドで Workspace ONE Access を使用していない場合は省略できます。ポッドと

Workspace ONE Access サービス間の信頼関係を作成するために使用します。使用中

の Workspace ONE Access 環境（オンプレミスまたはクラウドサービス）に対して、

ポッドがポート 443 でアクセスできることを確認します。Workspace ONE Access クラウドサービスを使用している場合、Workspace ONE Access Connector および

ポッドがアクセス権を持つ必要のある、Workspace ONE Access サービスの IP アドレ

スのリスト（VMware のナレッジベースの記事 KB2149884 にある）も参照してくださ

い。

一時的なジャ

ンプボック

ス仮想マシン

マネージャ仮

想マシン


ルで説明したように、一時的なジャンプボックスは、ポッドのデプロイおよびポッドの

更新中に使用されます。進行中のプロセスがこれらのポートを必要としない場合でも、

ポッドのデプロイおよびポッドの更新中は、このジャンプボックス仮想マシンはマネー

ジャ仮想マシンのポート 22 への SSH を使用してポッドのマネージャ仮想マシンと通信

する必要があります。ジャンプボックス仮想マシンでこの通信が必要になる場合の詳細

については、ポッドのデプロイと更新中にポッドのジャンプボックスで必要となるポー

トとプロトコルを参照してください。

エンドユーザーの接続によるトラフィックで、ポッドがプロビジョニングされた仮想デスクトップおよびリモート

アプリケーションにアクセスするためにどのポートが開かれていなければならないかは、エンドユーザーが接続する

方法に関する選択内容によって異なります。

n 外部ゲートウェイ構成を使用するためのオプションを選択すると、Unified Access Gateway インスタンスが、

そのバックエンドプール内の各インスタンス用の Microsoft Azure ロードバランサリソースとともに、


VMware, Inc. 104


Microsoft Azure の環境内に自動的にデプロイされます。このロードバランサは、DMZ サブネット上のこれら

のインスタンスの NIC と通信し、Microsoft Azure でのパブリックロードバランサとして構成されます。図

2-1. 高可用性が有効で、外部ゲートウェイと内部ゲートウェイの両方の構成が設定され、ポッドと同じ VNet に外部ゲートウェイがデプロイされ、外部ゲートウェイのロードバランサでパブリック IP アドレスが有効になっ

ているポッドの Horizon Cloud Pod アーキテクチャの図は、このパブリックロードバランサと Unified Access Gateway インスタンスの場所を示します。ポッドがこの構成を使用している場合、インターネット上の

エンドユーザーからのトラフィックは、Unified Access Gateway インスタンスに要求を配信するロードバラ

ンサに向かいます。この構成に対しては、これらのエンドユーザー接続が、次のリストにあるポートおよびプロ

トコルを使用してロードバランサにアクセス可能であるようにする必要があります。デプロイされたポッドで

は、外部ゲートウェイのロードバランサは vmw-hcs-podID-uag という名前のリソースグループにあります。

ここで podID はポッドの UUID です。

n 内部 Unified Access Gateway 構成を使用するためのオプションを選択すると、Unified Access Gateway イン

スタンスが、そのバックエンドプール内の各インスタンス用の Microsoft Azure ロードバランサリソースとと

もに、Microsoft Azure の環境内に自動的にデプロイされます。このロードバランサは、テナントサブネット

上のこれらのインスタンスの NIC と通信し、Microsoft Azure での内部ロードバランサとして構成されます。

図 2-1. 高可用性が有効で、外部ゲートウェイと内部ゲートウェイの両方の構成が設定され、ポッドと同じ VNet に外部ゲートウェイがデプロイされ、外部ゲートウェイのロードバランサでパブリック IP アドレスが有効にな

っているポッドの Horizon Cloud Pod アーキテクチャの図は、この内部ロードバランサと Unified Access Gateway インスタンスの場所を示します。ポッドがこの構成を使用している場合、企業ネットワーク内のエン

ドユーザーからのトラフィックは、Unified Access Gateway インスタンスに要求を配信するロードバランサ

に向かいます。この構成に対しては、これらのエンドユーザー接続が、次のリストにあるポートおよびプロトコ

ルを使用してロードバランサにアクセス可能であるようにする必要があります。デプロイされたポッドでは、内

部ゲートウェイのロードバランサは vmw-hcs-podID-uag-internal という名前のリソースグループにありま

す。ここで podID はポッドの UUID です。

n どちらの Unified Access Gateway 構成も選択しない場合は、代わりに VPN を使用するなどしてエンドユーザ

ーの接続をポッドに対して直接行うことができます。この構成の場合、『VMware Horizon Cloud Service 管理

ガイド』の説明に従って、管理コンソールのポッドの [サマリ] ページを使用して、SSL 証明書をポッドのマネー

ジャ仮想マシンにアップロードします。

エンドユーザーが Horizon Cloud ポッドで使用する可能性のあるさまざまな Horizon Client の詳細については、

https://docs.vmware.com/jp/VMware-Horizon-Client/index.html にある Horizon Client のドキュメントペー

ジを参照してください。


VMware, Inc. 105




https://docs.vmware.com/jp/VMware-Horizon-Client/index.html




ト


Horizon Client








Horizon Client



4172 TCP

UDP


Horizon Client




Horizon Client




Horizon Client






443 TCP HTML Access


VMware, Inc. 106




ト


Horizon Client








Horizon Client



4172 TCP

UDP


Horizon Client




Horizon Client




Horizon Client






443 TCP HTML Access



ル

目的

Horizon Client


シン

443 TCP ログイン認証トラフィック

Horizon Client




Horizon Agent

4172 TCP

UDP

PCoIP


VMware, Inc. 107


（続き）


ル

目的

Horizon Client




Horizon Agent

22443 TCP

UDP

Blast Extreme

Horizon Client




Horizon Agent

32111 TCP USB リダイレクト

Horizon Client




Horizon Agent

9427 TCP クライアントドライブリダイレクト (CDR) とマルチメディアリダイレクト

(MMR)

ブラウザデスクトップまた



Horizon Agent

443 TCP HTML Access

Unified Access Gateway インスタンスで構成されているポッドを使用した接続では、トラフィックは次の表に記載

されているようにポッドの Unified Access Gateway インスタンスからターゲットに対して許可される必要があり

ます。ポッドのデプロイ中に、ネットワークセキュリティグループ (NSG) は、ポッドの Unified Access Gateway ソフトウェアによる使用に対応するために Microsoft Azure 環境に作成されます。

表 2-21. ポッドの Unified Access Gateway インスタンスからのトラフィックに関するポートの要件




シン

443 TCP ログイン認証トラフィック





Horizon Agent

4172 TCP

UDP

PCoIP





Horizon Agent

22443 TCP

UDP

Blast Extreme

デフォルトでは、Blast Extreme を使用する場合、クライアントドライブリダイレクト (CDR) トラフィックおよび USB トラフィックはこのポート内で

サイドチャネルされます。好みに応じて、CDR トラフィックは TCP 9427 ポート上で、および USB リダイレクトトラフィックは TCP 32111 ポート

上で分離できます。





Horizon Agent

9427 TCP クライアントドライブリダイレクト (CDR) とマルチメディアリダイレク

ト (MMR) トラフィックでは省略できます。


VMware, Inc. 108

表 2-21. ポッドの Unified Access Gateway インスタンスからのトラフィックに関するポートの要件（続き）






Horizon Agent

32111 TCP USB リダイレクトトラフィックでは省略できます。


RADIUS インスタ

ンス

1812 UDP その Unified Access Gateway の構成に RADIUS 2 要素認証を使用する場

合。RADIUS のデフォルト値はここに表示されます。

次のポートは、デスクトップ仮想マシンとファームサーバ仮想マシンにインストールされている Horizon Agent に関連するソフトウェアからのトラフィックを許可する必要があります。


デスクトップ

またはファー

ムサーバ仮

想マシン内の

Horizon Agent


シン

4002 TCP セキュリティ強化を使用する場合の Java Message Service (JMS) (デフォ

ルト)

デスクトップ

またはファー

ムサーバ仮

想マシン内の

Horizon Agent


シン

4001 TCP Java Message Service (JMS)、レガシー

デスクトップ

またはファー

ムサーバ仮

想マシン内の

Horizon Agent


シン

3099 TCP デスクトップメッセージサーバ

デスクトップ

またはファー

ムサーバ仮

想マシンの

FlexEngine エージェント

（VMware Dynamic Environment Manager のエージェン

ト）



仮想マシンで実行

される

FlexEngine エー

ジェントによる使

用のためにセット

アップしたファイ

ル共有

445 TCP VMware Dynamic Environment Manager 機能を使用している場合、

SMB ファイル共有への FlexEngine エージェントアクセス。


VMware, Inc. 109

ポッドのデプロイプロセスの一環として、デプロイヤはデプロイされたすべての仮想マシンのネットワークインタ

ーフェイス (NIC) にネットワークセキュリティグループ (NSG) を作成します。これらの NSG で定義されているル

ールの詳細については、『Horizon Cloud 管理ガイド』を参照してください。

注： DNS 名、IP アドレス、ポート、およびプロトコルを Horizon Cloud ナレッジベース (KB) の記事に記載する代

わりに、コアの Horizon Cloud ドキュメントの一部としてここに提供しています。

アプリケーション登録を作成して Horizon Cloud ポッドデプロイヤに必要なサービスプリンシパルを作成する

Horizon Cloud ポッドデプロイヤは、Horizon Cloud ポッドのために Microsoft Azure サブスクリプションのキャ

パシティにアクセスして使用するには、サービスプリンシパルが必要です。Microsoft Azure Active Directory アプ

リケーションを登録すると、サービスプリンシパルも作成されます。また、認証キーを生成して、サブスクリプショ

ンレベルでプリンシパルサービスに役割を割り当てる必要があります。この機能を使用して、外部ゲートウェイが

ポッドとは別の専用のサブスクリプションを使用するようにする場合は、そのサブスクリプションに対してもこれら

の手順を実行する必要があります。

サービスプリンシパルを作成するための最新の詳細情報およびスクリーンショットについては、Microsoft Azure ドキュメントの「方法：ポータルを使用してリソースにアクセスできる Azure AD アプリケーションとサービスプリン

シパルを作成する」トピックを参照してください。

重要：サービスプリンシパルには、サブスクリプションに割り当てられたロールが必要です。割り当てられたロー

ルは、ポッドを正常にデプロイして維持するために Horizon Cloud が Microsoft Azure サブスクリプションで実行

する必要のあるアクションを許可する必要があります。次のロールのいずれかを、サービスプリンシパルに割り当て


n 共同作成者ロール。共同作成者ロールは、Microsoft Azure の組み込みロールの 1 つです。共同作成者ロールに

ついては、Microsoft Azure ドキュメントの「Azure リソースの組み込みロール」を参照してください。

n Horizon Cloud がポッドのデプロイおよびメンテナンス操作に必要とする Microsoft Azure サブスクリプショ

ンの Horizon Cloud ポッドデプロイヤに必要なロール操作をサービスプリンシパルに提供するために設定し

たカスタムロール。

登録アカウントに応じた Microsoft Azure ポータルを使用して、次の手順を行います。たとえば、これらの

Microsoft Azure クラウドのための特定のポータルエンドポイントがあります。

n Microsoft Azure（標準グローバル）

n Microsoft Azure Germany

n Microsoft Azure China


VMware, Inc. 110


https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal

https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal

https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles

n Microsoft Azure US Government

注：これらの手順の実行中に、デプロイウィザードで必要になる値を収集できます。詳細については、Horizon Cloud ポッドのデプロイウィザードのためのサブスクリプション関連情報を参照してください。

n アプリケーション ID

n 認証キー

注意：プライベートキーの有効期限を設定することもできますが、設定する場合には、期限切れになる前に必ずキ

ーを更新する必要があります。期限内にキーを更新しないと、関連する Horizon Cloud ポッドが機能しなくなりま

す。Horizon Cloud は、ユーザーが設定した期間を認識することも、確認することもできません。操作を簡単にする

ため、キーの有効期限に [無期限] を設定します。

有効期限に [無期限] を設定する代わりに、期限が切れる前にキーをリフレッシュする場合は、有効期限内に Horizon Cloud 管理コンソールにログインして、関連するポッドのサブスクリプション情報に新しいキーの値を入力する必要

があります。詳細な手順については、『VMware Horizon Cloud Service on Microsoft Azure 管理ガイド』の「デ

プロイされたポッドに関連付けられたサブスクリプション情報の更新」トピックを参照してください。

前提条件

組み込みの共同作成者ロールの代わりにカスタムプリンシパルロールをサービスプリンシパルに割り当てる場合

は、カスタムロールがサブスクリプションに存在することを確認します。Microsoft Azure サブスクリプションの

Horizon Cloud ポッドデプロイヤに必要なロール操作の説明に従って、カスタムロールが必要な管理操作を許可す

ることを確認します。

手順

1 Microsoft Azure ポータルの左側のナビゲーションバーで、 ([Azure Active

Directory]) をクリックし、 ([アプリの登録]) をクリックします。

2 [新しいアプリケーションを登録] をクリックします。

3 わかりやすい名前を入力し、サポートされているアカウントタイプを選択します。


VMware, Inc. 111


4 [リダイレクト URI] セクションで、[Web] を選択し、「http://localhost:8000」と入力して、[登録] をクリッ

クします。


[名前] 任意の名前を設定できます。同じサブスクリプション内で Horizon Cloud が使用するサービ

スプリンシパルと他のサービスプリンシパルが区別できるように設定してください。

[リダイレクト URI] [Web] が選択されていることを確認します。

示されるとおりに http://localhost:8000 を入力します。Microsoft Azure は、これを必

須フィールドとしてマークします。これは、Horizon Cloud ではサービスプリンシパル

http://localhost:8000 が Microsoft Azure 要件を満たすために使用され、シングルサイ

ンオン URL を必要としないためです。

新しく作成されたアプリ登録が画面に表示されます。


VMware, Inc. 112

5 アプリケーション ID とディレクトリ（テナント）ID をコピーし、デプロイウィザードの実行中に参照できる場

所に保存します。

6 サービスプリンシパルの詳細画面で、サービスプリンシパルの認証プライベートキーを作成します。

a （[証明書とシークレット]）をクリックします。

b [新しいクライアントのシークレット] をクリックします。


VMware, Inc. 113

c 説明を入力して有効期限を選択し、[追加] をクリックします。

キーの説明は 16 文字以下にしてください。たとえば、Hzn-Cloud-Key1 と入力します。

注意：有効期限は [無期限] に設定するか、特定の期間を設定します。ただし、特定の期間を設定する場合

は、期限が切れる前にキーをリフレッシュし、Horizon Cloud 管理コンソールのポッドのサブスクリプショ

ン情報に新しいキーを入力する必要があります。そうしないと、関連ポッドは機能しなくなります。

Horizon Cloud は、ユーザーが設定した期間を認識することも、確認することもできません。

重要：シークレット値をコピーし、後で参照可能な場所に貼り付けるまでは、この画面を開いたままにし

ます。シークレット値のコピーが完了するまで、画面を終了しないでください。

d デプロイウィザードの実行中に参照できる場所にシークレット値をコピーします。


VMware, Inc. 114

7 サブスクリプションレベルでプリンシパルサービスにロールを割り当てます。

注意： Microsoft Azure サブスクリプションの Horizon Cloud ポッドデプロイヤに必要なロール操作で説明

するように、ロールは共同作成者ロールまたは必要な管理操作を許可するために定義されたカスタムロールのい

ずれかになります。サービスプリンシパルに割り当てられたロールでポッドデプロイヤが必要とする操作が許

可されていない場合、デプロイウィザードはウィザードを完了できないようにブロックします。

a Microsoft Azure ポータルのメインナビゲーションバーで [すべてのサービス] をクリックし、[サブスクリ

プション] をクリックし、ポッドで使用するサブスクリプションの名前をクリックして、サブスクリプショ

ンの設定画面に移動します。

注：ここで、画面に表示されたサブスクリプション ID をコピーできます。この ID は、デプロイウィザー

ドで必要になります。

b （[アクセス制御 (IAM)]）をクリックして、[追加] - [ロール割り当てを追加] の順にクリ

ックし、[ロール割り当てを追加] 画面を開きます。

c [ロール割り当てを追加] 画面の [ロール] に対して、Contributor またはサービスプリンシパルに割り当て

るために作成したカスタムロールのいずれかを選択します。


VMware, Inc. 115

d 指定した名前でサービスプリンシパルを検索するには、[選択] ボックスを使用します。

次のスクリーンショットは、サービスプリンシパルに対して共同作成者ロールが選択されているこのステッ

プを示します。

注： [アクセス権限の割り当て先] ドロップダウンリストが [Azure AD ユーザー、グループ、またはアプ

リケーション] に設定されていることを確認します。

e サービスプリンシパルをクリックしてメンバーに設定し、[保存] をクリックします。


VMware, Inc. 116

8 ポッドに必要なリソースプロバイダがサブスクリプションに登録されていることを確認します。

a 前の手順で使用した [アクセス制御 (IAM)] 画面で、サブスクリプションのメニューにある ([Resource providers]) をクリックし、サブスクリプションに登録されているリソースプロバイダのリスト

を表示します。

b 次のリソースプロバイダが（[登録済み]）状態になっていることを確認します。この状態でない

場合には、プロバイダを登録します。

n Microsoft.Compute

n microsoft.insights

n Microsoft.Network

n Microsoft.Storage

n Microsoft.KeyVault

n Microsoft.Authorization

n Microsoft.Resources

n Microsoft.ResourceHealth

n Microsoft.DBforPostgreSQL


VMware, Inc. 117

これで、ポッドのサービスプロバイダが作成および構成され、ポッドのデプロイウィザードの最初の手順で必要な

サブスクリプション関連の値があります。4 つのサブスクリプション関連の値は次のとおりです。

n サブスクリプション ID

n Azure Active Directory ID

n アプリケーション ID

n アプリケーションキーの値

次のステップ

デプロイウィザードに入力するすべてのサブスクリプション関連情報が収集されたことを確認します。Horizon Cloud ポッドのデプロイウィザードのためのサブスクリプション関連情報を参照してください。

Microsoft Azure サブスクリプションの Horizon Cloud ポッドデプロイヤに必要なロール操作

このリリース以降では、Microsoft Azure の組み込みの共同作成者ロールを使用する代わりに、カスタムロールをサ

ービスプリンシパルに割り当てることができます。割り当てられたロールは、仮想マシンを作成する機能など、ポッ

ドを正常にデプロイして維持するために Horizon Cloud がサブスクリプションで実行する必要のあるアクションを

許可する必要があります。そのため、Horizon Cloud で使用されるサービスプリンシパルにカスタムロールを使用

する場合は、少なくとも、ここで説明する管理操作のセットを許可するようにそのロールを定義する必要があります。

Microsoft Azure のカスタムロールとカスタムロールを作成するための手順については、Microsoft Azure ドキュ

メントの「Azure リソースのカスタムロール」トピックを参照してください。ロールの仕組み、その構造、および管

理操作の構造の詳細については、Microsoft Azure ドキュメントの「Azure リソースのロール定義の理解」を参照し

てください。このドキュメントのトピックで説明するとおり、ロール定義は権限のコレクションです。このロール定

義は、略してロールと呼ばれます。ロールには、そのロールが割り当てられているサービスプリンシパルによって実

行できる管理操作と、実行できない管理操作がリストされます。管理操作は、リソースとそのリソースに対して実行

されるアクションの組み合わせです。

ポッドデプロイヤは、カスタムロール定義の以下のアクションを必要とします。*（ワイルドカード文字）は、リス

トされているリソースプロバイダ操作内の文字列と一致するすべての操作へのアクセスを許可します。操作の説明

については、下記のリンクにある Microsoft Azure のドキュメントを参照してください。


VMware, Inc. 118

https://docs.microsoft.com/en-us/azure/role-based-access-control/custom-roles

https://docs.microsoft.com/en-us/azure/role-based-access-control/role-definitions

表 2-22. カスタムロールで許可する必要がある Microsoft Azure リソースの操作

操作 Microsoft Azure ドキ

ュメントの説明

Microsoft.Authorization/*/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftauthorization

Microsoft.Compute/*/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute

Microsoft.Compute/availabilitySets/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute

Microsoft.Compute/disks/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute

Microsoft.Compute/images/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute


VMware, Inc. 119

https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftauthorization








https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute
































表 2-22. カスタムロールで許可する必要がある Microsoft Azure リソースの操作（続き）



Microsoft.Compute/locations/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute

Microsoft.Compute/virtualMachines/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute

Microsoft.Compute/virtualMachineScaleSets/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute

Microsoft.Compute/snapshots/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftcompute

Microsoft.DBforPostgreSQL/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftdbforpostgresql


VMware, Inc. 120

































https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftdbforpostgresql











Microsoft.KeyVault/*/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftkeyvault

Microsoft.KeyVault/vaults/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftkeyvault

Microsoft.KeyVault/vaults/secrets/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftkeyvault

Microsoft.Network/loadBalancers/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork

Microsoft.Network/networkInterfaces/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork


VMware, Inc. 121

https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftkeyvault
























https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork



















Microsoft.Network/networkSecurityGroups/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork

Microsoft.Network/publicIPAddresses/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork

Microsoft.Network/virtualNetworks/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork

Microsoft.Network/virtualNetworks/write https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork

Microsoft.Network/virtualNetworks/checkIpAddressAvailability/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork


VMware, Inc. 122












































Microsoft.Network/virtualNetworks/subnets/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftnetwork

Microsoft.ResourceHealth/availabilityStatuses/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftresourcehealth

Microsoft.Resources/subscriptions/resourceGroups/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftresources

Microsoft.Resources/deployments/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftresources


VMware, Inc. 123









https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftresourcehealth








https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftresources



















Microsoft.Storage/*/read https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftstorage

Microsoft.Storage/storageAccounts/* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftstorage

例

次の JSON コードブロックは、Horizon Cloud Pod という名前のカスタムロール定義に、ポッドデプロイヤが必

要とする一連の操作がある場合の例です。プロパティと使用方法の説明については、Microsoft Azure ドキュメント

の「Azure リソースのカスタムロール」トピックで「カスタムロールのプロパティ」セクションを参照してくださ

い。ID は、カスタムロールの一意の ID です。Azure PowerShell または Azure CLI を使用してカスタムロールを

作成すると、この ID は新しいロールを作成したときに自動的に生成されます。「チュートリアル：Azure CLI を使用

して Azure リソースのカスタムロールを作成する」で説明するとおり、mysubscriptionId1 は独自のサブスクリプ

ションの ID です。

{

"Name": "Horizon Cloud Pod",

"Id": "uuid",

"IsCustom": true,

"Description": "Minimum set of Horizon Cloud pod required operations",

"Actions": [

"Microsoft.Authorization/*/read"

"Microsoft.Compute/*/read"

"Microsoft.Compute/availabilitySets/*"

"Microsoft.Compute/disks/*"

"Microsoft.Compute/images/*"

"Microsoft.Compute/locations/*"

"Microsoft.Compute/virtualMachines/*"

"Microsoft.Compute/virtualMachineScaleSets/*"

"Microsoft.Compute/snapshots/*"

"Microsoft.DBforPostgreSQL/*"

"Microsoft.KeyVault/*/read"

"Microsoft.KeyVault/vaults/*"

"Microsoft.KeyVault/vaults/secrets/*"

"Microsoft.Network/loadBalancers/*"


VMware, Inc. 124

https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftstorage
















https://docs.microsoft.com/en-us/azure/role-based-access-control/custom-roles

https://docs.microsoft.com/en-us/azure/role-based-access-control/custom-roles#custom-role-properties

https://docs.microsoft.com/en-us/azure/role-based-access-control/tutorial-custom-role-cli

https://docs.microsoft.com/en-us/azure/role-based-access-control/tutorial-custom-role-cli

"Microsoft.Network/networkInterfaces/*"

"Microsoft.Network/networkSecurityGroups/*"

"Microsoft.Network/publicIPAddresses/*"

"Microsoft.Network/virtualNetworks/read"

"Microsoft.Network/virtualNetworks/write"

"Microsoft.Network/virtualNetworks/checkIpAddressAvailability/read"

"Microsoft.Network/virtualNetworks/subnets/*"

"Microsoft.Resources/subscriptions/resourceGroups/*"

"Microsoft.ResourceHealth/availabilityStatuses/read"

"Microsoft.Resources/deployments/*"

"Microsoft.Storage/*/read"

"Microsoft.Storage/storageAccounts/*"

],

"NotActions": [],

"DataActions": [],

"NotDataActions": [],

"AssignableScopes": [

"/subscriptions/mysubscriptionId1"

]

}

Horizon Cloud ポッドのデプロイウィザードのためのサブスクリプション関連情報

Horizon Cloud ポッドのデプロイウィザードでは、Microsoft Azure サブスクリプションから以下の情報を指定す

る必要があります。外部ゲートウェイをポッドとは別の専用のサブスクリプションにデプロイする場合、デプロイヤ

はどちらのサブスクリプションに対してもこの情報を必要とします。

重要： Microsoft Azure ポータルで生成されたアプリケーションキーは、即座に取得する必要があります。詳細に

ついては、アプリケーション登録を作成して Horizon Cloud ポッドデプロイヤに必要なサービスプリンシパルを作

成するを参照してください。その他の情報についは、Microsoft Azure アカウントの認証情報を使用して Microsoft Azure ポータルにログインするといつでも入手できます。

ID は UUID で、8-4-4-4-12 の形式です。次の表で説明するこれらの ID とキーは、ポッドのデプロイウィザードの

最初の手順で使用されます。

要求値収集方法値

[環境] Microsoft Azure サブスクリプションに登録するときに、

Microsoft Azure クラウド環境を決定します。その時点で、

アカウントとサブスクリプションは特定の Microsoft Azure 環境内で作成されます。

[サブスクリプション ID] Microsoft Azure ポータルで、左のメニューの

をクリックします。

[ディレクトリ ID] Microsoft Azure ポータルで、

[ ] - [ ]（[管理] の下）をクリックします。


VMware, Inc. 125

要求値収集方法値

[アプリケーション ID] Microsoft Azure ポータルで、

[ ] -

[ ] をクリックし、アプリケーション登録

を作成して Horizon Cloud ポッドデプロイヤに必要なサー

ビスプリンシパルを作成するの手順を使用して Horizon Cloud に対して作成した [アプリケーション登録] をクリッ

クします。

[アプリケーションキー] Microsoft Azure ポータルでキーを生成して取得します。

アプリケーション登録を作成して Horizon Cloud ポッドデプロイヤに必要なサービスプリンシパルを作成するを参照

してください。

証明書ファイルをポッドのデプロイに必要な PEM 形式に変換する

ポッドの Unified Access Gateway 機能には、クライアント接続のための SSL が必要です。ポッドに対して Unified Access Gateway 構成を作成する場合、ポッドデプロイウィザードには、SSL サーバ証明書チェーンをそのポッド

の Unified Access Gateway 構成に提供するための PEM フォーマットファイルが必要になります。1 つの PEM ファイルに、SSL サーバ証明書、必要な中間 CA 証明書、ルート CA 証明書、プライベートキーを含む、完全な証明書

チェーンが含まれている必要があります。

Unified Access Gateway で使用される証明書タイプについて詳しくは、Unified Access Gateway 製品ドキュメン

トの「正しい証明書タイプの選択」トピックを参照してください。

ゲートウェイ設定に関するポッドデプロイウィザードの手順で、証明書ファイルをアップロードします。デプロイ

中、このファイルはデプロイされた Unified Access Gateway インスタンスの構成に送信されます。ウィザードインターフェイスでアップロード手順を実行すると、ウィザードはアップロードしたファイルが次の要件を満たしてい

るかを検証します。

n ファイルを PEM 形式として解析できる。

n 有効な証明書チェーンとプライベートキーが含まれている。

n そのプライベートキーはサーバ証明書のパブリックキーと一致する。

証明書情報に対する PEM 形式のファイルがない場合は、証明書情報を上記の要件を満たすファイルに変換する必要

があります。PEM 形式でないファイルを PEM 形式のファイルに変換し、完全な証明書チェーンとプライベートキー

を含む単一の PEM ファイルを作成する必要があります。不要な情報が表示される場合は、ファイルの解析中にウィ

ザードで問題が発生しないように、ファイルを編集してその情報を削除する必要があります。手順の概要は次のとお

りです。

1 証明書情報を PEM 形式に変換し、証明書チェーンとプライベートキーを含む単一の PEM ファイルを作成しま

す。

2 ファイルを編集し、----BEGIN CERTIFICATE---- と -----END CERTIFICATE----- のマーカー間の証明書情

報の外部に余分な証明書情報があれば削除します。

次の手順のコード例では、ルート CA 証明書、中間 CA 証明書情報、およびプライベートキーを含む

mycaservercert.pfx という名前のファイルを使用することを想定します。


VMware, Inc. 126

https://docs.vmware.com/jp/Unified-Access-Gateway/index.html

https://docs.vmware.com/jp/Unified-Access-Gateway/index.html

前提条件

n 証明書ファイルがあることを確認します。このファイルは PKCS#12（.p12 または .pfx）形式や、Java JKS ま

たは JCEKS 形式になることができます。

重要：証明書チェーン内のすべての証明書が有効期限内である必要があります。Unified Access Gateway 仮想マシンでは、任意の中間証明書を含む、チェーン内のすべての証明書が有効期限内である必要があります。チ

ェーン内のいずれかの証明書が期限切れの場合、後で Unified Access Gateway 構成に証明書がアップロードさ

れる際に予期しない障害が発生する可能性があります。

n 証明書を変換するために使用できる openssl コマンドラインツールについて理解しておきます。https://

www.openssl.org/docs/apps/openssl.html を参照してください。

n 証明書が Java JKS または JCEKS 形式の場合、.pem ファイルに変換する前に、最初に証明書を .p12 また

は .pks 形式に変換するための Java keytool コマンドラインツールについて理解しておきます。

手順

1 証明書が Java JKS または JCEKS 形式の場合、keytool を使用して証明書を .p12 または .pks 形式に変換し

ます。

重要：この変換中、変換元と変換先で同じパスワードを使用します。

2 証明書が PKCS#12（.p12 または .pfx）形式の場合、または証明書を PKCS#12 形式に変換した後には、

openssl を使用して証明書を .pem ファイルに変換します。

たとえば、証明書の名前が mycaservercert.pfx の場合、次のコマンドを使用して証明書を変換できます。

openssl pkcs12 -in mycaservercert.pfx -nokeys -out mycaservercertchain.pem

openssl pkcs12 -in mycaservercert.pfx -nodes -nocerts -out mycaservercertkey.pem

上記の最初の行は mycaservercert.pfx の証明書を取得し、mycaservercertchain.pem に PEM 形式で

書き込みます。上記の 2 番目の行は mycaservercert.pfx からプライベートキーを取得し、

mycaservercertkey.pem に PEM 形式で書き込みます。

3 （オプション）プライベートキーが RSA 形式でない場合は、プライベートキーを RSA プライベートキー形式に

変換します。

Unified Access Gateway インスタンスには、RSA プライベートキー形式が必要です。この手順を実行する必要

があるかどうかを確認するには、PEM ファイルのプライベートキー情報が次の行で始まるかどうかを確認しま

す。

-----BEGIN PRIVATE KEY-----

プライベートキーがこの行で始まる場合は、プライベートキーを RSA 形式に変換する必要があります。プライ

ベートキーが -----BEGIN RSA PRIVATE KEY----- で始まる場合は、この手順を実行してプライベートキーを

変換する必要はありません。


VMware, Inc. 127

https://www.openssl.org/docs/apps/openssl.html

https://www.openssl.org/docs/apps/openssl.html

プライベートキーを RSA 形式に変換するには、次のコマンドを実行します。

openssl rsa -in mycaservercertkey.pem -check -out mycaservercertkeyrsa.pem

これで PEM ファイルのプライベートキーは RSA 形式（-----BEGIN RSA PRIVATE KEY----- と -----END

RSA PRIVATE KEY-----）になります。

4 証明書チェーン PEM ファイルとプライベートキー PEM ファイルの情報を組み合わせて、1 つの PEM ファイル

を作成します。

次の例では、mycaservercertkeyrsa.pem の内容（RSA 形式のプライベートキー）が最初にあり、その後にプ

ライマリ SSL 証明書である mycaservercertchain.pem の内容が続きます。さらに 1 つの中間証明書、ルー

ト証明書が続きます。

-----BEGIN CERTIFICATE-----

.... (your primary SSL certificate)

-----END CERTIFICATE-----


.... (the intermediate CA certificate)



.... (the trusted root certificate)


-----BEGIN RSA PRIVATE KEY-----

.... (your server key from mycaservercertkeyrsa.pem)

----- END RSA PRIVATE KEY-----

注：サーバ証明書が最初で、次に中間証明書、その次に信頼されるルート証明書の順番にする必要があります。

5 BEGIN と END マーカーの間に不要な証明書エントリまたは無関係な情報がある場合は、ファイルを編集して削除

します。

これで PEM ファイルは、ポッドデプロイウィザードの要件を満たすようになります。

Microsoft Azure への Horizon Cloud ポッドのデプロイ

ポッドデプロイウィザードを実行して、ポッドとそのゲートウェイ構成の要素となるコンポーネントをデプロイし

ます。ポッドのコネクタコンポーネントを Horizon Cloud とペアリングし、Microsoft Azure のキャパシティを

Horizon Cloud で使用できるようにします。

デプロイヤは、ウィザードの各手順で入力された情報を使用してポッドを構成する方法を決定します。特定の手順で

必要となる情報を提供した後、[次へ] をクリックして次の手順に進みます。

注意：以下の手順で示す IP アドレスはサンプルです。組織の要件を満たすアドレス範囲を使用してください。IP アドレス範囲の記述がある手順では、組織に適切な IP アドレスに置き換えてください。


VMware, Inc. 128

前提条件

ポッドデプロイウィザードを開始する前に必要な項目を用意しておくことを確認します。ウィザードで指定する必

要がある項目は、ポッドの構成オプションによって異なります。前提条件については、ポッドデプロイウィザード

を実行するための前提条件を参照してください。

ポッドの構成オプションには次が含まれます。

n 事前に作成する既存のサブネットを選択するか、ポッドデプロイヤで自動的にサブネットを作成するか

n ポッドの高可用性を有効にするかどうか。高可用性を有効にせずにポッドをデプロイする場合は、後でポッドを

編集して有効にすることができます。

n デプロイプロセスで VMware Workspace ONE® Access™ テナントを作成する。

n 外部または内部の Unified Access Gateway 構成を使用してデプロイするか、またはその両方を使用してデプロ

イするか。ゲートウェイ構成の 1 つのタイプだけでデプロイする場合は、後でポッドを編集してもう一方の未構

成のタイプを追加できます。

Unified Access Gateway を次のように構成してデプロイする場合後でポッドを編集して以下を追加することが可能

外部内部

内部外部

なしいずれか一方、または同時に両方

n ポッドの VNet とは別の、専用の VNet で外部 Unified Access Gateway 構成を使用してデプロイする。

n ポッドのサブスクリプションとは別の、専用のサブスクリプションで外部 Unified Access Gateway 構成を使用

してデプロイする。VNet は複数のサブスクリプションにまたがらないため、このオプションは個別の VNet ケースの特別なシナリオです。外部ゲートウェイが専用のサブスクリプションを使用してデプロイされる場合、そ

れは外部ゲートウェイが専用の VNet にもあることを意味します。

n 外部および内部ゲートウェイ構成の Microsoft Azure ロードバランサにどの SKU を使用するか。選択できる

のは、標準の Azure ロードバランサ SKU または基本の Azure ロードバランサ SKU です。2 つの SKU の比較

については、Microsoft Azure のドキュメントで「Load Balancer の SKU の比較」トピックを参照してくださ

い。

n ポッドのゲートウェイ構成に設定されている RADIUS 2 要素認証のオプションを使用してデプロイする。ポッ

ドのゲートウェイ構成に設定されている RADIUS 設定を使用せずにデプロイする場合は、後でポッドを編集して

もう一方の未構成のタイプを追加できます。

n 外部 Unified Access Gateway 構成の場合は、構成のロードバランサでパブリック IP アドレスを使用しないよ

うにすることをオプションで選択できます。ロードバランサにパブリック IP アドレスを持たないようにウィザ

ードオプションを選択する場合は、DNS サーバで FQDN にマッピングした IP アドレス値をウィザードで指定

する必要があります。この FQDN は、このゲートウェイへの PCoIP 接続のためにエンドユーザーの Horizon Client で使用されるものです。デプロイプロセスでは、デプロイヤは Unified Access Gateway の Horizon 設定でその IP アドレスを構成します。Unified Access Gateway のドキュメントでは、この IP アドレス値は


VMware, Inc. 129

http://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview#skus

PCoIP 外部 URL と呼ばれます。Unified Access Gateway のドキュメントで URL と呼ばれている場合でも、入

力した値は IP アドレスである必要があります。この IP アドレスを DNS の FQDN にマッピングします。これ

は、ポッドの外部 Unified Access Gateway 構成で PCoIP セッションを確立するためにエンドユーザーの

Horizon Client で使用される FQDN です。

注意：デプロイされたポッドを後で編集して、外部ゲートウェイのロードバランサに対するこの IP アドレス

設定を変更することはできません。そのため、デプロイウィザードで DNS マッピングの FQDN と一致するパブ

リック IP アドレスを入力し、その FQDN がデプロイウィザードでアップロードする証明書の FQDN と一致す

ることを確認してください。

手順

1 ポッドデプロイウィザードを実行するための前提条件

ポッドデプロイウィザードを実行する前に、環境がこれらの前提条件を満たしていることを確認してくださ

い。ポッドデプロイウィザードで要求された値を指定し、ウィザードの指示に従って進めるために、次の項目

を用意しておく必要があります。

2 ポッドデプロイウィザードの開始

Microsoft Azure に完全に初めてのポッドをデプロイするときは、Horizon Cloud 管理コンソールの [はじめ

に] ページの [クラウドのキャパシティを追加] 機能を使用して、ポッドデプロイウィザードを開始します。

3 新しいポッドの Microsoft Azure サブスクリプション情報の指定

ポッドデプロイウィザードのこの手順で、このポッドで使用する Microsoft Azure サブスクリプション情報を

指定します。

4 ポッドの構成情報の指定

ポッドデプロイウィザードのポッドセットアップの手順で、ネットワーク情報に加えて、ポッドの名前などの

詳細を指定します。この手順では、オプションとしてデプロイプロセスで Workspace ONE Access テナント

を作成することも選択できます。

5 Horizon Cloud ポッドのゲートウェイ構成の指定

ウィザードのこの手順では、ゲートウェイが構成されているポッドをデプロイするために必要な情報を指定し

ます。Unified Access Gateway は、Microsoft Azure にデプロイされたポッドのゲートウェイ環境を提供し

ます。新しいポッドをデプロイするときには、外部または内部ゲートウェイ構成を使用するか、同じポッドで

両方のタイプを使用するかを選択できます。また、ゲートウェイ構成なしでポッドをデプロイし、ポッドのデ

プロイ後に後で追加することもできます。デフォルトでは、このウィザードの手順が表示されるときに、外部

ゲートウェイ構成が選択されます。

6 検証と続行、およびポッドのデプロイプロセスの開始

[検証と続行] をクリックした後、指定した値がシステムによって検証されます。すべてが検証されると、ウィザ

ードに確認のための情報の概要が表示されます。次にデプロイプロセスを開始します。

ポッドデプロイウィザードを実行するための前提条件

ポッドデプロイウィザードを実行する前に、環境がこれらの前提条件を満たしていることを確認してください。ポ

ッドデプロイウィザードで要求された値を指定し、ウィザードの指示に従って進めるために、次の項目を用意して

おく必要があります。


VMware, Inc. 130

すべてのデプロイの前提条件

n Horizon Cloud ポッドを Microsoft Azure にデプロイする前の準備に記載されている準備作業がすべて完了し

ていることを確認します。

n サブスクリプション情報が Horizon Cloud ポッドのデプロイウィザードのためのサブスクリプション関連情報

に記載のとおりであることを確認します。

n Microsoft Azure で必要な仮想ネットワークを構成で説明したように、Microsoft Azure サブスクリプション

で、ポッドを追加するリージョンに仮想ネットワークがあることを確認します。

重要：一部の Microsoft Azure リージョンでは、GPU が有効な仮想マシンはサポートされません。GPU 対応

のデスクトップまたはリモートアプリケーションでポッドを使用する場合は、使用する NV シリーズの仮想マシ

ンタイプが、ポッド用に選択した Microsoft Azure のリージョンで提供されていることと、この Horizon Cloud リリースでサポートされていることを確認します。詳細については、https://azure.microsoft.com/ja-jp/regions/services/ にある Microsoft のドキュメントを参照してください。

n VNet が、外部アドレスを解決できる DNS を参照するように構成されていることを確認します。ポッドデプロ

イヤは、ポッドソフトウェアを Microsoft Azure 環境に安全にダウンロードするために Horizon Cloud 制御プ

レーンの外部アドレスに到達できる必要があります。

n Microsoft Azure での Horizon Cloud ポッドの DNS の要件および 2019 年 9 月のリリースのマニフェスト以

降の Horizon Cloud ポッドのポートとプロトコルの要件の説明どおりに、ポッドデプロイヤの DNS、ポート、

およびプロトコルの要件が満たされていることを確認します。

n アウトバウンドインターネットアクセスでプロキシを使用する必要がある場合は、プロキシ設定のためのネッ

トワーク情報および必要な認証情報（使用する場合）があることを確認します。ポッドのデプロイプロセスに

は、アウトバウンドインターネットアクセスが必要です。

n ポッドで時刻の同期に使用する少なくとも 1 つの NTP サーバの情報があることを確認します。NTP サーバは、

パブリック NTP サーバ、またはこの目的で設定する独自の NTP サーバです。指定する NTP サーバは、構成し

た仮想ネットワークからアクセス可能である必要があります。IP アドレスではなくドメイン名を使用して NTP サーバを使用する場合は、仮想ネットワークに対して構成された DNS が NTP サーバの名前を解決できることも

確認してください。

n デプロイヤが必要なサブネットを自動的に作成するようにしたくない場合は、必要なサブネットが事前に作成さ

れていて VNet 上に存在していることを確認します。必要なサブネットを事前に作成する手順については、ポッ

ドのデプロイの前に、Microsoft Azure の VNet で Horizon Cloud ポッドに必要なサブネットを作成するおよ

び Microsoft Azure で Horizon Cloud ポッド用の既存のサブネットを使用する場合を参照してください。

注意：ポッドのデプロイのために VNet 上に事前に手動で作成したサブネットは空のままである必要がありま

す。これらのサブネットに何らかのリソースを投入したり、IP アドレスを使用したりしないでください。IP アド

レスがサブネットで既に使用されていると、ポッドのデプロイに失敗する可能性があります。

n デプロイヤで必要なサブネットを作成する場合、ウィザードの管理サブネット、デスクトップサブネット、およ

び DMZ サブネットに入力するアドレス範囲を把握していることを確認します。外部 Unified Access Gateway 構成を使用する場合は、DMZ サブネットが必要です。また、これらの範囲が重複しないことを確認します。ア

ドレス範囲は、CIDR 表記（クラスレスドメイン間ルーティング表記）で入力します。入力したサブネット範囲

が重複していると、ウィザードがエラーを表示します。管理サブネット範囲の場合、少なくとも /27 の CIDR が


VMware, Inc. 131



必要です。DMZ サブネット範囲の場合、少なくとも /28 の CIDR が必要です。管理および DMZ サブネットの

範囲を同じ場所に共存させたいのであれば、IP アドレスを指定して DMZ サブネット範囲を管理サブネットと同

様のものに指定することができます。たとえば、管理サブネットが 192.168.8.0/27 の場合、マッチした DMZ サブネットは 192.168.8.32/27 になります。

重要：ウィザードフィールドに入力する CIDR は、プリフィックスとビットマスクの各組み合わせが、プリフ

ィックスを開始 IP アドレスとする IP アドレス範囲になるように定義する必要があります。Microsoft Azure では、CIDR プリフィックスを範囲の先頭にする必要があります。たとえば、192.168.182.48/28 という正しい

CIDR の場合、IP アドレス範囲は 192.168.182.48 ～ 192.168.182.63 になり、プリフィックスは開始 IP アドレ

ス (192.168.182.48) と同じになります。ただし、192.168.182.60/28 という間違った CIDR の場合、IP アドレ

ス範囲は 192.168.182.48 ～ 192.168.182.63 になり、開始 IP アドレスは 192.168.182.60 のプリフィックスと

同じになりません。CIDR は、開始 IP アドレスが CIDR プリフィックスと一致する IP アドレス範囲になるように

定義してください。

n デプロイヤによって必要なサブネットを作成する場合、このアドレス範囲を持つサブネットが VNet 上に存在し

ないことを確認してください。この場合、デプロイヤ自体がウィザードで指定するアドレス範囲を使用してサブ

ネットを自動的に作成します。ウィザードが既にこれらの範囲が存在するサブネットを検出した場合は、ウィザ

ードにアドレスの重複に関するエラーが表示され、それ以降に進まなくなります。VNet がピアリングされてい

る場合、ウィザードに入力するつもりの CIDR アドレス空間がすでに VNet のアドレス空間に含まれていること

を確認します。

ポッドのデプロイ時に Workspace ONE Access Cloud テナントを作成する場合の前提条件

ポッドデプロイウィザードには、ポッドのデプロイの一部として Workspace ONE Access Cloud サービスに

Workspace ONE Access テナントを作成するオプションがあります。そのオプションを選択すると、ポッドのデプ

ロイプロセスで、Workspace ONE Access Cloud サービス内のテナントが作成および構成されます。テナント作成

後の構成手順の後に、同じ Horizon Cloud アカウントを使用して Microsoft Azure にデプロイするポッドで

Workspace ONE Access テナントを使用することができます。

ウィザードでこのオプションを使用する場合は、次を把握していることを確認してください。

n Workspace ONE Access テナントの作成先である Workspace ONE Access データセンターリージョンの名

前。ポッドデプロイウィザードで、ドロップダウンメニューからこのデータセンターのリージョンを選択しま

す。

n Workspace ONE Access テナントに使用する名前。

n テナントの管理者アカウントに使用するユーザー名。

n メールアドレス。ウィザードで入力したメールアドレスは、テナントの管理者アカウントに関連付けられます。

システムが Workspace ONE Access テナントを作成すると、そのメールアドレスにウェルカムメールが送信

されます。


VMware, Inc. 132

ベストプラクティスは、VMware Horizon Cloud Service on Microsoft Azure 顧客アカウントレコードに関連

付けられている、My VMware アカウントに反映されているメールアドレスを使用することです。新しいテナン

トについてのウェルカムメールの受信アドレスは、Horizon Cloud からのメールが送信されるメールアドレス

と同じものを使用することが、ベストプラクティスとなります。つまり、最初のポッドをデプロイするために管

理コンソールにログインする際に、ポッドデプロイウィザードの開始に記載されているとおりに

[email protected] の形式の My VMware の名前でログインします。Workspace ONE Access テナントのメ

ールアドレスと同じ名前を使用することで、初期の使用が分かりやすくなります。

Unified Access Gateway 構成でデプロイする際の前提条件

ポッドで Unified Access Gateway の構成を使用することを計画している場合、次の情報を入力する必要がありま

す。

n サービスへのアクセスでエンドユーザーが使用する完全修飾ドメイン名 (FQDN)。外部/内部の両方の Unified Access Gateway 構成タイプでポッドをデプロイし、両方に同じ FQDN を使用する場合、適切なロードバラン

サにエンドユーザークライアントの受信トラフィックをルーティングする方法を決定する必要があります。こ

のシナリオでは、インターネットからのクライアントトラフィックが Microsoft パブリックロードバランサに

ルーティングされ、イントラネットからのクライアントトラフィックが Microsoft 内部ロードバランサにルー

ティングされるようにルーティングを設定する必要があります。

重要：この FQDN には、アンダースコアを含めることはできません。このリリースでは、FQDN にアンダー

スコアが含まれていると、Unified Access Gateway インスタンスへの接続が失敗します。

n その FQDN に基づいた署名付きの SSL サーバ証明書（PEM 形式）。Unified Access Gateway 機能には、

Unified Access Gateway 製品マニュアルに記載されているようにクライアント接続のための SSL が必要です。

証明書には、信頼された証明書認証局 (CA) の署名が必要です。単一の PEM ファイルに完全な証明書チェーンお

よびプライベートキーが含まれている必要があります。たとえば、単一の PEM ファイルに SSL サーバ証明書、

必要な中間 CA 証明書、ルート CA 証明書、およびプライベートキーが含まれている必要があります。OpenSSL は、PEM ファイルの作成に使用できるツールです。

重要：証明書チェーン内のすべての証明書が有効期限内である必要があります。Unified Access Gateway 仮想マシンでは、任意の中間証明書を含む、チェーン内のすべての証明書が有効期限内である必要があります。チ

ェーン内のいずれかの証明書が期限切れの場合、後で Unified Access Gateway 構成に証明書がアップロードさ

れる際に予期しない障害が発生する可能性があります。

n 外部の Unified Access Gateway 構成でデプロイする場合、DMZ (非武装地帯) サブネットを指定する必要があ

ります。2 つの方法で、この DMZ サブネットを指定することができます。

n DMZ サブネットを VNet で事前に作成する。この方法を使うと、管理サブネットおよびデスクトップテナ

ントサブネットも事前に作成する必要があります。ポッドのデプロイの前に、Microsoft Azure の VNet で

Horizon Cloud ポッドに必要なサブネットを作成するの手順を参照してください。

n デプロイの際に、デプロイヤに DMZ サブネットを自動的に作成させる。この方法では、ウィザードに入力

する DMZ サブネット用のアドレス範囲を決定し、その範囲が管理サブネットおよびデスクトップテナント

サブネットの範囲と重複しないことを確認する必要があります。アドレス範囲は、CIDR 表記（クラスレス

ドメイン間ルーティング表記）で入力します。入力したサブネット範囲が重複していると、ウィザードがエ

ラーを表示します。DMZ サブネット範囲の場合、少なくとも /28 の CIDR が必要です。管理および DMZ サブネットの範囲を同じ場所に共存させるには、IP アドレスを指定して DMZ サブネット範囲を管理サブネ


VMware, Inc. 133

ットと同一のものに指定することができます。たとえば、管理サブネットが 192.168.8.0/27 の場合、一致

する DMZ サブネットは 192.168.8.32/27 になります。IP アドレスの範囲に、プリフィックスを開始 IP アドレスとするプリフィックスとビットマスクの組み合わせが必要なことに関する、すべてのデプロイの前提

条件の重要な注意事項も参照してください。

n 外部 Unified Access Gateway 構成でデプロイし、構成のロードバランサにパブリック IP アドレスを使用する

ことを禁止する場合、DNS 設定でエンドユーザーが Horizon Client の PCoIP 接続に使用する FQDN にマッピ

ングした IP アドレスを指定する必要があります。

Unified Access Gateway で必要な PEM ファイルに関する考慮事項の詳細については、証明書ファイルをポッドの

デプロイに必要な PEM 形式に変換するを参照してください。

ポッドの VNet またはサブスクリプションとは別の専用の VNet またはサブスクリプションを使用して外部 Unified Access Gateway 構成でデプロイする場合の前提条件

Unified Access Gateway 構成でデプロイする場合の上記の前提条件に加えて、これらの前提条件は、外部ゲートウ

ェイを専用の VNet または専用のサブスクリプションにデプロイする使用事例に固有です。専用のサブスクリプショ

ンの使用は専用の VNet の使用の特殊な事例です。それは、VNet の適用範囲はサブスクリプションであるため、個

別のサブスクリプションには専用の VNet が必要になるからです。

n ゲートウェイの VNet は、ポッドの VNet とピアリングする必要があります。

n 必要なサブネットが事前に作成されて VNet に存在すること、またはウィザードに入力する予定の CIDR アドレ

ス空間が VNet のアドレス空間にすでに含まれていることを確認します。VNet はピアリングされているため、

VNet のアドレス空間にまだ含まれていない CIDR アドレス空間をウィザードに入力すると、デプロイヤは VNet を自動的に拡張できません。その場合、デプロイプロセスは失敗します。

ヒント: ベストプラクティスは、事前にサブネットを作成することです。必要なサブネットを事前に作成する

手順については、ポッドのデプロイの前に、Microsoft Azure の VNet で Horizon Cloud ポッドに必要なサブ

ネットを作成するおよび Microsoft Azure で Horizon Cloud ポッド用の既存のサブネットを使用する場合を参


n 外部ゲートウェイに個別のサブスクリプションを使用している場合は、Horizon Cloud ポッドのデプロイウィ

ザードのためのサブスクリプション関連情報で説明するようにサブスクリプション情報があることを確認しま

す。

2 要素認証構成でデプロイする際の前提条件

2 要素認証機能を使用する予定や、それをオンプレミスの 2 要素認証サーバと使用する予定がある場合は、認証サー

バの構成で次の情報が使用されていることを確認して、ポッドデプロイウィザードの適切なフィールドにその情報

を提供できるようにします。プライマリおよびセカンダリサーバの両方がある場合は、それぞれの情報を取得しま

す。

n 認証サーバの IP アドレスまたは DNS 名

n 認証サーバのプロトコルメッセージで暗号化および復号化のために使用される共有シークレット

n 認証ポートの番号、通常は 1812 UDP ポート。


VMware, Inc. 134

n 認証プロトコルのタイプ。認証タイプには、PAP（パスワード認証プロトコル）、CHAP（チャレンジハンドシ

ェイク認証プロトコル）、MSCHAP1 および MSCHAP2（Microsoft チャレンジハンドシェイク認証プロトコ

ル、バージョン 1 および 2）があります。

注： RADIUS ベンダーの推奨する認証プロトコルについては、RADIUS ベンダーのドキュメントを確認し、指

定したプロトコルタイプに従ってください。RADIUS の 2 要素認証をサポートするポッドの機能は、Unified Access Gateway インスタンスによって提供され、Unified Access Gateway が PAP、CHAP、MSCHAP1、

MSCHAP2 をサポートします。PAP のセキュリティは、通常 MSCHAP2 のものよりも低くなっています。また

PAP は MSCHAP2 よりシンプルなプロトコルです。結果として、RADIUS ベンダーのほとんどはよりシンプル

な PAP プロトコルと互換性がありますが、一部の RADIUS ベンダーはよりセキュリティの高い MSCHAP2 との

互換性を有していません。

ポッドデプロイウィザードの開始

Microsoft Azure に完全に初めてのポッドをデプロイするときは、Horizon Cloud 管理コンソールの [はじめに] ページの [クラウドのキャパシティを追加] 機能を使用して、ポッドデプロイウィザードを開始します。

注： Horizon Cloud 管理コンソールへのログイン認証は、My VMware アカウントの認証情報に依存します。My VMware アカウントのシステムで、システムの停止が発生していて、認証要求に対応できない場合、その期間中に管

理コンソールにログインすることはできません。管理コンソールの最初のログイン画面でログインの問題が発生する

場合は、https://status.horizon.vmware.com にある Horizon Cloud システムステータスページで最新のシステ

ムステータスを確認してください。そのページで、アップデートを定期受信するようにすることもできます。

前提条件

ポッドデプロイウィザードを実行するための前提条件に記載されている前提条件を満たしていることを確認しま

す。

手順

1 My VMware アカウントの認証情報を使用して https://cloud.horizon.vmware.com での Horizon Cloud 管理コンソールにログインします。

アカウントの認証情報は、[email protected] のようなプライマリメールアドレスと、アカウントのプロファ

イルで設定されているパスワードです。


VMware, Inc. 135

https://status.horizon.vmware.com


これまでにこれらの My VMware 認証情報を使用して Horizon Cloud の利用規約に同意していなかった場合、

[ログイン] ボタンをクリックした後に利用規約に関する通知ボックスが表示されます。利用規約に合意して続行

します。

ログイン後、Horizon Cloud 管理コンソールが開きます。既存のポッドがない場合、デフォルトでは、[キャパ

シティ] セクションが展開された状態で、[クラウドのキャパシティを追加] 行で、[はじめに] ウィザードが開きま

す。

2 [クラウドのキャパシティを追加] 行で、[追加] をクリックします。

このポッドをデプロイするクラウドを選択するための選択ウィンドウが表示されます。


VMware, Inc. 136

3 Microsoft Azure クラウドに対して [選択] をクリックします。

[クラウドのキャパシティを追加] ウィザードが開き、最初の手順が表示されます。

4 新しいポッドの Microsoft Azure サブスクリプション情報の指定の手順に従ってこのポッドで使用されるサブ

スクリプションを指定します。

新しいポッドの Microsoft Azure サブスクリプション情報の指定

ポッドデプロイウィザードのこの手順で、このポッドで使用する Microsoft Azure サブスクリプション情報を指定

します。

前提条件

n Microsoft Azure への Horizon Cloud ポッドのデプロイに記載されている前提条件を満たしていることを確認

します。

n このウィザードの手順では、Horizon Cloud ポッドのデプロイウィザードのためのサブスクリプション関連情

報に記載されているように、サブスクリプション関連の情報があることを確認します。

n ポッドデプロイウィザードの開始の手順を完了させます。


VMware, Inc. 137

手順

1 ウィザードの最初の手順で、以前に入力したサブスクリプションの名前を選択するか、新しいサブスクリプショ

ン情報を入力して、このポッドで使用するサブスクリプションを指定します。


VMware, Inc. 138

既存のサブスクリプションを選択すると、以前にシステムに入力されたそのサブスクリプションの情報が、この

手順で自動入力されます。

注：最初の [はじめに] ページからポッドをデプロイしているときに、以前入力したサブスクリプション情報が

表示されている理由が分からない可能性があります。以前入力したサブスクリプション情報は、次のような事例

において表示される可能性があります。

n ウィザードを開始して、最初のウィザード手順でサブスクリプション情報を入力し、[追加] をクリックして

サブスクリプション情報をシステムに送信してから、ウィザードを先に進みます。その後のどこかの手順で、

すべての手順を完了する前にウィザードをキャンセルして終了します。この場合、[追加] をクリックしてか

ら最初のウィザードの手順で入力したサブスクリプション情報がシステムによって保存されます。その後の

手順でウィザードをキャンセルして終了しても、システムはそれ以前に入力されたサブスクリプション情報

を保持します。

n 以前にこの Horizon Cloud 顧客アカウントレコードを使用して、そのアカウントレコードに対して最初と

それ以降のポッドをデプロイし、その後のある時点においてそれらのポッドを削除しました。Horizon Cloud 顧客アカウントレコードに関連付けられている認証情報でログインし直すと、以前に入力したサブス

クリプション情報は引き続きその顧客のレコードと関連付けられていて、以前のサブスクリプションの名前

がドロップダウンリストに表示されます。


[サブスクリプシ

ョンの適用]以前に入力したサブスクリプションの名前を選択するか、[新規追加] を選択して新しいサブスクリプション情報を入力しま

す。


ョン名]新しいサブスクリプション情報を入力する場合には、前に入力したサブスクリプションと区別できるように、わかりやすい

名前を入力します。

名前は、文字から始まり、文字、ダッシュ、および数字のみで構成する必要があります。

[環境] 次のような、サブスクリプションに関連付けられているクラウド環境を選択します。

n [Azure]：標準的なグローバル Microsoft Azure クラウドの場合

n [Azure - 中国]：Microsoft Azure （中国）クラウドの場合

n [Azure - ドイツ]：Microsoft Azure Germany クラウドの場合

n [Azure - US Government]：Microsoft Azure US Government クラウドの場合


ョン ID]クラウドキャパシティのサブスクリプション ID を UUID の形式で入力します。選択した環境で有効なサブスクリプション

ID を入力してください。Microsoft Azure では、Microsoft Azure ポータルの [サブスクリプション] 領域でこの UUID を取得できます。

[ディレクトリ

ID]Microsoft Azure Active Directory のディレクトリ ID を UUID 形式で入力します。Microsoft Azure では、Microsoft Azure ポータルの Microsoft Azure Active Directory プロパティで UUID を取得できます。

[アプリケーショ

ン ID]Microsoft Azure ポータルで作成したサービスプリンシパルのアプリケーション ID を UUID 形式で入力します。

Microsoft Azure Active Directory で、アプリケーション登録とそれに関連付けられたサービスプリンシパルを作成する

ことは必須です。


VMware, Inc. 139


[アプリケーショ

ンキー]Microsoft Azure ポータルで作成したサービスプリンシパル認証キーの値を入力します。このキーの作成は必須です。

[外部ゲートウェ

イに別のサブス

クリプションを

使用]

外部の Unified Access Gateway 構成をポッドのサブスクリプションとは別の専用のサブスクリプションにデプロイする

場合は、このトグルを有効にします。外部ゲートウェイに個別のサブスクリプションを使用すると、組織はチームの専門分

野に応じて、それらのサブスクリプションを制御する個別のチームを柔軟に割り当てることができます。これにより、組織

内のどのユーザーがサブスクリプションのリソースグループ内のポッドのアセットにアクセスでき、どのユーザーがゲート

ウェイのアセットにアクセスできるかについて、よりきめ細かなアクセス制御が可能になります。

このトグルをオンにすると、ゲートウェイのサブスクリプション情報を入力するためのフィールドが表示されます。ポッド

のサブスクリプションの場合と同様に、これらのフィールドに情報を指定します。

重要：この画面では、特定の [サブスクリプション名] に関連付けられている、以前入力したサブスクリプショ

ンの値を削除することはできません。これが発生するのはまれなことではありますが、次のような状況を想定で

きます。

a Microsoft Azure でサブスクリプション関連の要素を設定します。

b [クラウドのキャパシティを追加] ウィザードを開始し、最初の手順でこれらのサブスクリプションの値を入

力し、次のウィザードの手順に進みます。

c ただし、ウィザードの次の手順で要求されたネットワークの値の読み取り時に、このウィザードをキャンセ

ルして終了し、新しいブラウザータブを開いて Microsoft Azure ポータルに移動し、前提条件を満たすよ

うにネットワーク構成を調整します。

d Microsoft Azure ポータルにいる間に、サービスプロバイダを別の名前で利用するために新しいアプリケー

ション登録を行うことも決めます。

e [はじめに] ページがあるブラウザに戻り、[クラウドのキャパシティを追加] ウィザードを再び開始します。

この時点で、以前に入力したサブスクリプション名は引き続き [サブスクリプションの適用] ドロップダウンリストにあります。ただし、その名前を選択すると、古いアプリケーション ID を含む以前の値ですべてのフィー

ルドが自動入力され、画面内のそれらの値を変更することや、そのサブスクリプション名を編集または削除して

やり直すことはできません。このような状況が生じた場合は、ウィザードをキャンセルして終了し、再びウィザ

ードを開始したらその最初の手順で [新規追加] を選択して新しいサブスクリプション名を作成し、使用する現在

の値を入力してから先に進みます。

次のスクリーンショットは、この手順が完了した状態の例です。


VMware, Inc. 140

2 ウィザードの次の手順に進みます。

次の手順に進むためのボタンをクリックすると、システムは指定されたすべての値の有効性、および値が相互に

適切に関連しているかどうかを、以下のように検証します。

n 指定したサブスクリプション ID は選択した環境で有効か。

n 指定したディレクトリ ID、アプリケーション ID、およびアプリケーションキーがそのサブスクリプション

で有効か。

n 指定されたアプリケーション ID に対するアプリケーションのサービスプリンシパルに、ポッドのデプロイ

プロセスで必要なすべての操作を許可するロールがあるか。サービスプリンシパルとそのロールの要件に

ついては、『デプロイガイド』の「アプリケーションの登録と必要なサービスプリンシパルの作成」トピッ

クを参照してください。

値の修正に関するエラーメッセージが表示される場合は、少なくとも 1 つの値が、サブスクリプションに存在し

ないか、別の値との有効な関係を持っていないかのいずれかの理由で無効になっています。次に、そのエラーメッセージが表示される可能性がある状況を、すべてではありませんが、いくつかリストで示します。

n サブスクリプションにある [ディレクトリ ID] を指定して、別のディレクトリにある [アプリケーション ID] の値を指定した場合。

n 指定されたサービスプリンシパルに割り当てられたロールが、ポッドデプロイヤで要求される操作を許可

しない場合。

重要：このエラーメッセージが表示される場合は、複数の要素が無効である可能性があります。この場合は、

収集したサブスクリプション関連情報とサービスプリンシパルの構成を確認します。

3 ポッドの構成情報の指定の手順に従ってポッドの詳細とネットワーク情報を指定します。


VMware, Inc. 141

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.getstarted15/GUID-DC011997-CE9E-4B38-9C4F-57104226218C.html

ポッドの構成情報の指定

ポッドデプロイウィザードのポッドセットアップの手順で、ネットワーク情報に加えて、ポッドの名前などの詳細

を指定します。この手順では、オプションとしてデプロイプロセスで Workspace ONE Access テナントを作成する

ことも選択できます。

注意：以下の手順で示す IP アドレスはサンプルです。組織の要件を満たすアドレス範囲を使用してください。IP アドレス範囲の記述がある手順では、組織に適切な IP アドレスに置き換えてください。

前提条件


す。

デプロイプロセスで必要なサブネットを自動作成する場合、ウィザードフィールドでこれらのサブネット用に指定

する CIDR アドレス範囲が、Microsoft Azure 内の VNet 上の既存のサブネットによって使用されていないことを確

認します。

このポッドで使用するために事前にサブネットを作成済みである場合は、それらのサブネットにリソースが接続され

ていないことを確認し、管理サブネットに使用するために作成したサブネットには、そのサブネット用のサービスエンドポイントとして構成された Microsoft.SQL サービスがあることを確認します。ポッドデプロイウィザード

で、Microsoft.SQL サービスが管理サブネット上のサービスエンドポイントとして構成されていることを検証し

ます。

注意：ポッドのデプロイのために VNet 上に作成するこれらのサブネットは空である必要があります。ポッドをデ

プロイする前にサブネットを作成することが可能ですが、これらのサブネットにいかなるリソースも配置しないでく

ださい。またいかなる IP アドレスも使用しないでください。IP アドレスがサブネットで既に使用されていると、ポ

ッドのデプロイに失敗する可能性があります。

手順

1 ウィザードのこの手順で、ポッドに関する詳細と必要なネットワーク情報を提供します。

次のスクリーンショットは、最初に表示されるときの手順の例です。


VMware, Inc. 142


[ポッド名] このポッドにわかりやすい名前を入力します。管理コンソールでは、他のポッドと区別するために、この名前が使用され

ます。

[場所] 既存の市区町村名を選択するか、[追加] をクリックして新しい市区町村名を指定します。

システムは市区町村名に基づいてポッドをグループ化し、管理コンソールの [ダッシュボード] ページの [Horizon のグ

ローバルな占有量] マップに表示します。

[追加] をクリックして、市区町村の名前を入力します。システムは自動的にバックエンドの地理参照テーブルにある、入

力した文字に一致する世界の市区町村名表示するので、そのリストから市区町村を選択できます。

注：システムのオートコンプリートリストから市区町村を選択する必要があります。


VMware, Inc. 143


[Microsoft Azure リージョン]

ポッドを展開する実際の地理的な Microsoft Azure リージョンを選択します。利用可能なリージョンは、以前に選択し

た Microsoft Azure 環境によって決まります。

リージョンを選択するときは、このポッドからサービスを利用するエンドユーザーとの近接性を考慮します。エンドユーザーがより近接している場合、遅延は少なくなります。

重要：一部の Microsoft Azure リージョンでは、GPU が有効な仮想マシンはサポートされません。GPU 対応のデス

クトップまたはリモートアプリケーションでポッドを使用する場合は、使用する NV シリーズの仮想マシンタイプが、

ポッド用に選択した Microsoft Azure のリージョンで提供されていることと、この Horizon Cloud リリースでサポー

トされていることを確認します。詳細については、https://azure.microsoft.com/ja-jp/regions/services/ にある

Microsoft のドキュメントを参照してください。

[説明] オプション：このポッドの説明を入力します。

[高可用性] 高可用性が構成されているポッドをデプロイするには、このトグルを有効にします。高可用性とポッドの詳細について

は、『管理ガイド』を参照してください。

このトグルを無効にすると、ポッドは高可用性なしでデプロイされます。

[仮想ネットワーク] リストから仮想ネットワークを選択します。

[Microsoft Azure リージョン] フィールドで選択されたリージョンに存在する仮想ネットワーク (VNet) のみがここに

表示されます。Microsoft Azure サブスクリプションで、そのリージョンで使用する VNet をすでに作成している必要

があります。

[既存のサブネット

を使用]ポッドのサブネット要件を満たすよう事前にサブネットを作成済みの場合は、このトグルを有効にします。このトグルを

[はい] に設定すると、サブネットを指定するためのウィザードフィールドは、ドロップダウン選択メニューに変わりま

す。

重要：このウィザードは、必要なサブネットの 1 つとして既存のサブネットを使用すること、またはその他の必要なサ

ブネットに対して CIDR アドレスを入力することをサポートしません。このトグルを [はい] に設定している場合は、ポ

ッドの必要なサブネットをすべて既存のサブネットから選択する必要があります。

[管理サブネット]

[管理サブネット

(CIDR)]

[既存のサブネットを使用] を有効にすると、[管理サブネット] で [仮想ネットワーク] のために選択された VNet 上で使

用可能なサブネットが一覧表示されます。ポッドの管理サブネットに使用する既存のサブネットを選択します。

重要：

n サブネットのサービスエンドポイントとして構成された Microsoft.SQL サービスがあるサブネットを選択しま

す。このサービスエンドポイントは、管理サブネットを介した、ポッドマネージャ仮想マシンとポッドの Azure Postgres データベースとの間で必要となる通信をサポートします。

接続されているその他のリソースがない空のサブネットを選択します。サブネットが空でない場合、デプロイプロ

セス中またはポッドの操作中に予期しない結果が発生する可能性があります。

[既存のサブネットを使用] が無効になっている場合、[管理サブネット (CIDR)] でサブネットのアドレス範囲を CIDR 表記（192.168.8.0/27 など）で入力して、ポッドと Unified Access Gateway インスタンスが接続するサブネットをデ

プロイヤが作成するようにします。管理サブネットの場合、少なくとも /27 の CIDR が必要です。

注意：既存のサブネットを使用するウィザードオプションを選択しない場合、そのサブネットが Microsoft Azure 環境に存在していない必要があります。既に存在している場合は、ウィザードの次の手順に進もうとするとエラーが発生し

ます。


VMware, Inc. 144



[デスクトップサブ

ネット]

[デスクトップサブ

ネット (CIDR)]

[既存のサブネットを使用] を有効にすると、[デスクトップサブネット] で [仮想ネットワーク] のために選択された

VNet 上で使用可能なサブネットが一覧表示されます。ポッドのデスクトップテナントサブネットに使用する既存のサ

ブネットを選択します。

重要：接続されているその他のリソースがない空のサブネットを選択します。サブネットが空でない場合、デプロイプロセス中またはポッドの操作中に予期しない結果が発生する可能性があります。

[既存のサブネットを使用] が無効になっている場合、[デスクトップサブネット (CIDR)] でサブネットのアドレス範囲を

CIDR 表記（192.168.12.0/22 など）で入力して、このポッドのすべての VDI デスクトップおよび RDSH ファームサー

バ（エンドユーザーのリモートデスクトップおよびアプリケーション用）が接続するサブネットをデプロイヤが作成す

るようにします。デスクトップサブネットの場合、少なくとも /27 の CIDR が必要であり、/22 の CIDR を推奨します。

重要：このポッドで提供するデスクトップの数を考慮して、必ず十分に大きな範囲を入力するようにします。このデス

クトップのサブネットは、ポッドをデプロイした後には拡張できません。

注意：既存のサブネットを使用するウィザードオプションを選択しない場合、そのサブネットが Microsoft Azure 環境に存在していない必要があります。既に存在している場合は、ウィザードの次の手順に進もうとするとエラーが発生し

ます。

[NTP サーバ] 時刻を同期するために使用する NTP サーバのリストをカンマで区切って入力します。

ここで入力する NTP サーバは、パブリック NTP サーバ、または時刻同期を指定するために設定する独自の NTP サーバ

です。ここで指定した NTP サーバは、使用するポッドのために [仮想ネットワーク] フィールドで選択した仮想ネットワ

ークからアクセスできる必要があります。このフィールドでは、各 NTP サーバを IP アドレスまたはドメイン名のいずれ

かで指定できます。このフィールドに IP アドレスの代わりにドメイン名を入力する場合、仮想ネットワークに対して構

成された DNS が指定された名前を解決できることを確認する必要があります。

パブリック NTP サーバのドメイン名の例は、time.windows.com、us.pool.ntp.org、time.google.com です。

[プロキシを使用] アウトバウンドインターネット接続用のプロキシが必要な場合は、このトグルを有効にして、表示される関連フィール

ドに入力します。

ポッドデプロイヤは、ソフトウェアを Microsoft Azure クラウド環境に安全にダウンロードし、Horizon Cloud クラ

ウド制御プレーンに接続するために、インターネットへのアウトバウンドアクセスを必要とします。ポッドでプロキシ

設定を使用するには、トグルを有効にした後、次の情報を提供する必要があります。

n [プロキシ]（必須）：プロキシサーバのホスト名または IP アドレスを入力します。

n [ポート]（必須）：プロキシサーバの設定で指定されているポート番号を入力します。

プロキシサーバ設定で認証のためのユーザー名とパスワードが必要な場合は、次の認証情報も入力します。

次のスクリーンショットは、デプロイプロセスでサブネットを自動作成するようにし、[高可用性] を有効にした

場合に、この手順を完了したときの例です。この例では、アウトバウンドインターネット接続の要件を満たすた

めに、プロキシは必要ありません。


VMware, Inc. 145

2 ポッドデプロイプロセスで Workspace ONE Access クラウドテナントを自動作成する場合は、[Workspace ONE Access] セクションで [Workspace ONE Access テナント] トグルを有効にし、表示された関連フィールド

への入力を完了します。

重要：システムは、このポッド作成ワークフローで Workspace ONE Access テナントを作成できます。今回

のリリースでは、システムが Workspace ONE Access テナントを作成するように、既存のポッドを後で編集す

ることはできません。このセクションのトグルを有効にしたポッドを作成し、その後この顧客アカウントの

Horizon Cloud ポッドで Workspace ONE Access テナントを使用する場合、Workspace ONE Access クラウ

ドホスト型環境にサブスクライブしてテナントを取得する必要があります。


[データセンターの地

域]新しいテナントの Workspace ONE Access リージョンを選択します。

[テナント名] テナントの名前を入力します。


VMware, Inc. 146


[ユーザー名] Workspace ONE Access テナントの管理者アカウントに使用する名前を入力します。

[E メール] [ユーザー名] の管理者アカウントで使用するメールアドレスを入力します。システムが Workspace ONE Access テナントを作成すると、そのメールアドレスにウェルカムメールが送信されます。

ベストプラクティスは、この Horizon Cloud テナント環境の所有者として、Horizon Cloud 顧客アカウントレコー

ドの [はじめに] 画面の [My VMware アカウント] 領域に顧客管理者としてリストされている My VMware アカウント

の電子メールアドレスのいずれかを使用することです。新しいテナントについてのウェルカムメールの受信アドレス

は、Horizon Cloud からのメールが送信されるメールアドレスと同じものを使用することが、ベストプラクティスと

なります。つまり、最初のポッドをデプロイするために管理コンソールにログインする際に、ポッドデプロイウィザー

ドの開始に記載されているとおりに [email protected] の形式の My VMware の名前でログインします。

Workspace ONE Access テナントのメールアドレスと同じ名前を使用することで、初期の使用が分かりやすくなりま

す。

次のスクリーンショットは、フィールドが入力済みのセクションを示します。

注：ポッドがデプロイされたら、新規 Workspace ONE Access テナントをポッドに統合するためにさらに手

順が必要になります。その後の手順については、『Horizon Cloud 管理ガイド』および「Horizon Cloud ポッド

と Workspace ONE Access 環境の統合」トピックとサブトピックを参照してください。ポッドデプロイヤは

Workspace ONE Access サービスと統合するポッドに必要な Workspace ONE Access コネクタアプライア

ンスをデプロイしません。

3 [次へ] をクリックして、次の手順に進みます。

4 Horizon Cloud ポッドのゲートウェイ構成の指定の手順に従って、ポッドに Unified Access Gateway 構成を

作成するための詳細を指定します。エンドユーザーがインターネット経由でデスクトップおよびリモートアプ

リケーションにアクセスできるようにするためには、外部 Unified Access Gateway 構成が必要です。

Horizon Cloud ポッドのゲートウェイ構成の指定

ウィザードのこの手順では、ゲートウェイが構成されているポッドをデプロイするために必要な情報を指定します。

Unified Access Gateway は、Microsoft Azure にデプロイされたポッドのゲートウェイ環境を提供します。新しい

ポッドをデプロイするときには、外部または内部ゲートウェイ構成を使用するか、同じポッドで両方のタイプを使用


VMware, Inc. 147

するかを選択できます。また、ゲートウェイ構成なしでポッドをデプロイし、ポッドのデプロイ後に後で追加するこ

ともできます。デフォルトでは、このウィザードの手順が表示されるときに、外部ゲートウェイ構成が選択されます。

外部ゲートウェイ構成外部 Unified Access Gateway 構成では、企業のネットワークの外部にいるユーザ

ーに対してデスクトップおよびアプリケーションへのアクセスを与える機能が提供

されます。ポッドにこの外部ゲートウェイ構成がある場合、ポッドには、このアク

セスを提供するための Azure ロードバランサリソースと Unified Access Gateway インスタンスが含まれています。この場合、各インスタンスには 3 つの

NIC があります：1 つは管理サブネット上の NIC、1 つはデスクトップサブネット

上の NIC、そしてもう 1 つは DMZ サブネット上の NIC です。デプロイウィザード

では、ロードバランサにプライベート IP アドレスを使用するか、パブリック IP アドレスを使用するかに応じて、ロードバランシングタイプをプライベートまたはパ

ブリックのいずれかに指定するためのオプションがあります。パブリック IP のト

グルを無効にする場合、エンドユーザーの Horizon Client がゲートウェイとの

PCoIP 接続に使用する FQDN に DNS サーバでマッピングした IP アドレスを指定


外部ゲートウェイ構成の場合、ポッドの VNet とは別の VNet に構成をデプロイす

るオプションもあります。VNet をピアリングする必要があります。このタイプの

構成では、ポッドをハブ - スポークネットワークトポロジなど Microsoft Azure のより複雑なネットワークトポロジーにデプロイできます。

注：最初のウィザードのステップで、外部ゲートウェイが専用のサブスクリプシ

ョンを使用するトグルを有効にした場合、外部ゲートウェイを専用の VNet（そのサ

ブスクリプションに関連付けられている VNet）にデプロイする必要があります。

内部ゲートウェイ構成内部 Unified Access Gateway 構成は、企業のネットワークの内部にいるエンドユーザーに対して、デスクトップおよびアプリケーションへの信頼される HTML Access (Blast) 接続機能を提供します。内部ゲートウェイ構成を使用してポッドが

構成されていない場合、企業のネットワーク内のエンドユーザーは、ブラウザを使

用してデスクトップやアプリケーションに HTML Access (Blast) 接続をする際に

標準ブラウザの信頼されていない証明書エラーに遭遇します。ポッドにこの内部ゲ

ートウェイ構成がある場合、ポッドには、このアクセスを提供するための Azure ロードバランサのリソースと Unified Access Gateway インスタンスが含まれてい

ます。この場合、各インスタンスには 2 つの NIC があります：1 つは管理サブネッ

ト上の NIC、1 つはデスクトップサブネット上の NIC です。デフォルトでは、この

ゲートウェイのロードバランシングタイプはプライベートです。

次のスクリーンショットは、最初に表示されるときの手順の例です。


VMware, Inc. 148






VMware, Inc. 149

前提条件


す。

重要：この手順を完了するには、エンドユーザーがサービスにアクセスするために必要な完全修飾ドメイン名

(FQDN) と、その FQDN に基づく署名付きの SSL 証明書（PEM 形式）を取得する必要があります。証明書は信頼さ

れている認証局 (CA) によって署名する必要があります。1 つの PEM ファイルに、SSL 証明書の中間証明書、ルート

CA 証明書、プライベートキーを含む、完全な証明書チェーンが含まれている必要があります。詳細については、証

明書ファイルをポッドのデプロイに必要な PEM 形式に変換するを参照してください。

証明書チェーン内のすべての証明書の有効期限が切れていないことを確認します。証明書チェーン内のいずれかの証

明書の有効期限が切れている場合、後からポッドのオンボーディングプロセスで予期しない不具合が発生する可能性

があります。

この FQDN には、アンダースコアを含めることはできません。このリリースでは、FQDN にアンダースコアが含ま

れていると、Unified Access Gateway インスタンスへの接続が失敗します。

手順

1 外部ゲートウェイ構成を使用する場合、[外部 UAG] セクションのフィールドをすべて入力します。


[外部 UAG を有効にします

か?]

ポッドに外部ゲートウェイ構成があるかどうかを制御します。外部構成を使用すると、企業のネットワークの外部にいるユーザ

ーがデスクトップおよびアプリケーションにアクセスできるようになります。ポッドには、このアクセスを提供する Azure ロードバランサリソースと Unified Access Gateway インスタンスが含まれています。

注：デフォルトの有効になっている設定にしておくことをお勧めします。

このトグルをオフにすると、クライアントはポッドと統合された Workspace ONE Access を介して、またはポッドマネージ

ャのロードバランサに直接接続するか、内部ゲートウェイ構成を介して接続する必要があります。クライアントがポッドに統

合された Workspace ONE Access を介して、または直接接続する場合、いくつかのデプロイ後の手順が必要です。この場合、

ポッドをデプロイした後に、Horizon Cloud 管理ガイドにおけるポッドへの SSL 証明書のアップロードに関する情報を参照


[FQDN] サービスへのアクセスでエンドユーザーが使用する完全修飾ドメイン名 (FQDN) を入力します（例：ourOrg.example.com）。

このドメイン名を所有し、その FQDN を検証可能な PEM 形式の証明書を取得する必要があります。

重要：この FQDN には、アンダースコアを含めることはできません。このリリースでは、FQDN にアンダースコアが含ま


[DNS アドレ

ス]オプションで、Unified Access Gateway が名前解決に使用できる追加の DNS サーバのアドレスを、カンマ区切りで入力し

ます。オンプレミスの RADIUS サーバで 2 要素認証を使用するためにこの外部 Unified Access Gateway 構成を設定すると

きは、オンプレミスの RADIUS サーバの名前を解決できる DNS サーバのアドレスを指定します。

すべてのデプロイの前提条件で説明したように、最初に DNS サーバをサブスクリプション内にセットアップし、外部名を解決

できるように構成する必要があります。Unified Access Gateway インスタンスは、デフォルトではその DNS サーバを使用

します。このフィールドにアドレスを指定する場合、デプロイした Unified Access Gateway インスタンスは、サブスクリプ

ションの仮想ネットワークで構成した前提条件の DNS サーバに加えて、アドレスを使用します。


VMware, Inc. 150


[ルート] オプションで、デプロイした Unified Access Gateway インスタンスが、エンドユーザーアクセス用のネットワークのルー

ティングを解決するために使用する、追加のゲートウェイへのカスタムルートを指定します。指定したルートは、Unified Access Gateway が 2 要素認証の RADIUS サーバなどにネットワークルーティングを解決できるようにするために使用され

ます。

このポッドをオンプレミスの RADIUS サーバで 2 要素認証を使用するように構成する場合は、Unified Access Gateway イン

スタンスが RADIUS サーバに接続するための正しいルートを入力する必要があります。たとえば、オンプレミスの RADIUS サーバがその IP アドレスとして 10.10.60.20 を使用している場合、10.10.60.0/24 とデフォルトルートのゲートウェイアドレ

スをカスタムルートとして入力することになります。この環境で使用している Express ルートまたは VPN 構成からデフォル

トルートのゲートウェイアドレスを取得します。

形式 ipv4-network-address/bits ipv4-gateway-address で、カンマ区切りリストとしてカスタムルートを指定します

（例：192.168.1.0/24 192.168.0.1, 192.168.2.0/24 192.168.0.2）。

[証明書] Microsoft Azure で実行中の Unified Access Gateway インスタンスへの接続をクライアントが信頼できるようにするため

に、Unified Access Gateway で使用される PEM 形式の証明書をアップロードします。証明書は、入力した FQDN に基づい

たものにして、信頼されている認証局 (CA) によって署名されている必要があります。PEM ファイルに、SSL 証明書の中間証

明書、ルート CA 証明書、プライベートキーを含む、完全な証明書チェーンが含まれている必要があります。

このゲートウェイの Microsoft ロードバランサの設定を指定します。


[パブリック IP アドレ

スを有効にしますか?]このゲートウェイのロードバランシングタイプがプライベートとして構成されるか、パブリックとして構成されるか

を制御します。オンに切り替えると、デプロイされた Microsoft Azure ロードバランサリソースがパブリック IP アドレスで構成されます。オフに切り替えると、Microsoft Azure ロードバランサリソースがプライベート IP アドレ

スで構成されます。

重要：このリリースでは、外部ゲートウェイのロードバランシングタイプを後でパブリックからプライベートに、

またはプライベートからパブリックに変更することはできません。この変更を行う唯一の方法は、デプロイされたポッ

ドからゲートウェイ構成を完全に削除してから、ポッドを編集して逆の設定で追加することです。

このトグルを無効にすると、[Horizon FQDN のパブリック IP アドレス] フィールドが表示されます。

[Horizon FQDN のパ

ブリック IP アドレス]デプロイされた Microsoft Azure ロードバランサにパブリック IP を構成しないことを選択した場合、エンドユーザ

ーの Horizon Client がゲートウェイとの PCoIP 接続に使用する FQDN に DNS でマッピングする IP アドレスを提

供する必要があります。デプロイヤは、この IP アドレスを Unified Access Gateway 構成の設定で構成します。

[タイプ] デプロイヤによってこの外部ゲートウェイ構成に使用される Microsoft Azure Load Balancer に使用する SKU を選

択します。選択できるのは、[標準] または [基本] です。2 つの SKU の比較については、Microsoft Azure のドキュメ

ントで「Load Balancer の SKU の比較」トピックを参照してください。

外部ゲートウェイのネットワーク設定を指定します。


VMware, Inc. 151



[別の仮想ネット

ワークを使用]このトグルは、外部ゲートウェイをポッドの VNet とは別の専用の VNet にデプロイするかどうかを制御します。

次の行は、さまざまなケースを示しています。

注：ウィザードの最初のステップで外部ゲートウェイに別のサブスクリプションを使用するように指定した場合、このト

グルはデフォルトで有効になっています。その場合は、ゲートウェイの VNet を選択する必要があります。


ワークを使用] — 無効

トグルを無効にすると、外部ゲートウェイがポッドの VNet にデプロイされます。この場合は、DMZ サブネットを指定す


n [DMZ サブネット] - ポッドのセットアップウィザード手順で [既存のサブネットを使用] を有効にすると、[DMZ サブ

ネット] には [仮想ネットワーク] に対して選択された VNet 上で使用可能なサブネットが表示されます。ポッドの

DMZ サブネットに使用する既存のサブネットを選択します。

重要：接続されているその他のリソースがない空のサブネットを選択します。サブネットが空でない場合、デプロイ

プロセス中またはポッドの操作中に予期しない結果が発生する可能性があります。

n [DMZ サブネット (CIDR)] - 前のウィザード手順で [既存のサブネットを使用] が無効になっている場合、DMZ（非武

装地帯）ネットワークのサブネットを CIDR 表記で入力します。このネットワークは、Unified Access Gateway インスタンスをゲートウェイの Microsoft Azure パブリックロードバランサに接続するように構成されます。


ワークを使用] — 有効

トグルを有効にすると、外部ゲートウェイが専用の VNet にデプロイされます。この場合、使用する VNet を選択してか

ら、必要な 3 つのサブネットを指定する必要があります。[既存のサブネットを使用] トグルを有効にして、指定した VNet で事前に作成したサブネットから選択します。そうでない場合は、サブネットを CIDR 表記で指定します。

重要：接続されているその他のリソースがない空のサブネットを選択します。サブネットが空でない場合、デプロイプロセス中またはポッドの操作中に予期しない結果が発生する可能性があります。

この場合、ゲートウェイの VNet とポッドの VNet がピアリングされます。ベストプラクティスは、サブネットを事前に

作成し、ここで CIDR エントリを使用しないことです。ポッドの VNet またはサブスクリプションとは別の専用の VNet またはサブスクリプションを使用して外部 Unified Access Gateway 構成でデプロイする場合の前提条件を参照してくだ

さい。

n 管理サブネット - ゲートウェイの管理サブネットに使用するサブネットを指定します。少なくとも /27 の CIDR が必

要です。このサブネットにはサービスエンドポイントとして Microsoft.SQL サービスが構成されている必要があり

ます。

n バックエンドサブネット - ゲートウェイのバックエンドサブネットに使用するサブネットを指定します。少なくと

も /27 の CIDR が必要です。

n フロントエンドサブネット - Unified Access Gateway インスタンスをゲートウェイの Microsoft Azure パブリッ

クロードバランサに接続するように構成されるフロントエンドサブネットのサブネットを指定します。

2 （オプション） [外部 UAG] セクションで、外部 Unified Access Gateway の 2 要素認証をオプションで構成し

ます。

ポッドのための 2 要素認証機能の指定の手順を完了させます。


VMware, Inc. 152

3 [内部 UAG] セクションで、内部 Unified Access Gateway 構成が必要な場合は、[内部 UAG を有効にしますか? ] トグルをオンにして、表示されるフィールドに入力します。


[内部 UAG を有効にします

か?]

ポッドに内部ゲートウェイ構成があるかどうかを制御します。内部構成は、企業のネットワーク内に存在するユーザーが

HTML Access (Blast) でデスクトップおよびアプリケーションに接続するときに信頼されたアクセスを提供します。ポッド

には、このアクセスを提供する Azure ロードバランサリソースと Unified Access Gateway インスタンスが含まれていま

す。デフォルトでは、このゲートウェイのロードバランシングタイプはプライベートです。ロードバランサは、プライベー

ト IP アドレスで構成されます。

[FQDN] サービスへのアクセスでエンドユーザーが使用する完全修飾ドメイン名 (FQDN) を入力します（例：

ourOrg.example.com）。このドメイン名を所有し、その FQDN を検証可能な PEM 形式の証明書を取得する必要があります。

重要：この FQDN には、アンダースコアを含めることはできません。このリリースでは、FQDN にアンダースコアが含ま


[DNS アドレ

ス]オプションで、Unified Access Gateway が名前解決に使用できる追加の DNS サーバのアドレスを、カンマ区切りで入力し

ます。オンプレミスの RADIUS サーバで 2 要素認証を使用するためにこの内部 Unified Access Gateway 構成を設定すると

きは、オンプレミスの RADIUS サーバの名前を解決できる DNS サーバのアドレスを指定します。

すべてのデプロイの前提条件で説明したように、最初に DNS サーバをサブスクリプション内にセットアップし、名前を解決

できるように構成する必要があります。Unified Access Gateway インスタンスは、デフォルトではその DNS サーバを使用

します。このフィールドにアドレスを指定する場合、デプロイした Unified Access Gateway インスタンスは、サブスクリプ

ションの仮想ネットワークで構成した前提条件の DNS サーバに加えて、アドレスを使用します。

[ルート] オプションで、デプロイした Unified Access Gateway インスタンスが、エンドユーザーアクセス用のネットワークのルー

ティングを解決するために使用する、追加のゲートウェイへのカスタムルートを指定します。指定したルートは、Unified Access Gateway が 2 要素認証の RADIUS サーバなどにネットワークルーティングを解決できるようにするために使用さ

れます。

このポッドをオンプレミスの RADIUS サーバで 2 要素認証を使用するように構成する場合は、Unified Access Gateway インスタンスが RADIUS サーバに接続するための正しいルートを入力する必要があります。たとえば、オンプレミスの RADIUS サーバがその IP アドレスとして 10.10.60.20 を使用している場合、10.10.60.0/24 とデフォルトルートのゲートウェイアド

レスをカスタムルートとして入力することになります。この環境で使用している Express ルートまたは VPN 構成からデフ

ォルトルートのゲートウェイアドレスを取得します。

形式 ipv4-network-address/bits ipv4-gateway-address で、カンマ区切りリストとしてカスタムルートを指定します

（例：192.168.1.0/24 192.168.0.1, 192.168.2.0/24 192.168.0.2）。

[証明書] Microsoft Azure で実行中の Unified Access Gateway インスタンスへの接続をクライアントが信頼できるようにするため

に、Unified Access Gateway で使用される PEM 形式の証明書をアップロードします。証明書は、入力した FQDN に基づ

いたものにして、信頼されている認証局 (CA) によって署名されている必要があります。PEM ファイルに、SSL 証明書の中間

証明書、ルート CA 証明書、プライベートキーを含む、完全な証明書チェーンが含まれている必要があります。

[ロードバラン

サタイプ]デプロイヤによってこの外部ゲートウェイ構成に使用される Microsoft Azure Load Balancer に使用する SKU を選択しま

す。選択できるのは、[標準] または [基本] です。2 つの SKU の比較については、Microsoft Azure のドキュメントで「Load Balancer の SKU の比較」トピックを参照してください。

4 （オプション） [内部 UAG] セクションで、内部 Unified Access Gateway の 2 要素認証をオプションで構成し

ます。

ポッドのための 2 要素認証機能の指定の手順を完了させます。

選択したオプションに関連付けられている必要な情報を提供した場合、[検証と続行] をクリックしてウィザードの最

後の手順まで続行することができます。検証と続行、およびポッドのデプロイプロセスの開始を参照してください。。

ポッドのための 2 要素認証機能の指定

Unified Access Gateway 構成を指定するためのポッドのデプロイウィザードの手順で、エンドユーザーがこれら

のゲートウェイ構成を介してデスクトップおよびアプリケーションにアクセスする際の 2 要素認証の使用を指定す


VMware, Inc. 153



ることもできます。Unified Access Gateway 構成の詳細を指定した後に、これらの 2 要素認証の詳細を指定できま

す。

前提条件


す。

2 要素認証の詳細を入力する外部または内部 Unified Access Gateway 構成で、Horizon Cloud ポッドのゲートウ

ェイ構成の指定に記載されているとおりに、ウィザードにおける Unified Access Gateway 構成用のフィールドの指

定が完了していることを確認します。オンプレミス認証サーバに対して 2 要素認証を構成するときに、Unified Access Gateway インスタンスがそのオンプレミスサーバにルーティングを解決できるようにするために次のフィ

ールドにも情報を提供します。


[DNS アドレス] オンプレミス認証サーバの名前を解決できる DNS サーバの 1 つ以上のアドレスを指定します。

[ルート] ポッドの Unified Access Gateway インスタンスがネットワークのルーティングをオンプレミス認証サーバに解決できるように

する、1 つ以上のカスタムルートを指定します。

たとえば、オンプレミスの RADIUS サーバがその IP アドレスとして 10.10.60.20 を使用している場合、10.10.60.0/24 とデフォ

ルトルートのゲートウェイアドレスをカスタムルートとして使用することになります。この環境で使用している Express ルート

または VPN 構成からデフォルトルートのゲートウェイアドレスを取得します。

形式 ipv4-network-address/bits ipv4-gateway-address で、カンマ区切りリストとしてカスタムルートを指定します（例：

192.168.1.0/24 192.168.0.1, 192.168.2.0/24 192.168.0.2）。

次の情報が、ポッドデプロイウィザードの適切なフィールドに指定できるように、認証サーバの構成で使用されて

いることを確認します。プライマリおよびセカンダリサーバの両方がある場合は、それぞれの情報を取得します。

n 認証サーバの IP アドレスまたは DNS 名

n 認証サーバのプロトコルメッセージで暗号化および復号化のために使用される共有シークレット

n 認証ポートの番号、通常は 1812 UDP ポート。

n 認証プロトコルのタイプ。認証タイプには、PAP（パスワード認証プロトコル）、CHAP（チャレンジハンドシ

ェイク認証プロトコル）、MSCHAP1 および MSCHAP2（Microsoft チャレンジハンドシェイク認証プロトコ

ル、バージョン 1 および 2）があります。

注： RADIUS ベンダーの推奨する認証プロトコルについては、RADIUS ベンダーのドキュメントを確認し、指

定したプロトコルタイプに従ってください。RADIUS の 2 要素認証をサポートするポッドの機能は、Unified Access Gateway インスタンスによって提供され、Unified Access Gateway が PAP、CHAP、MSCHAP1、

MSCHAP2 をサポートします。PAP のセキュリティは、通常 MSCHAP2 のものよりも低くなっています。また

PAP は MSCHAP2 よりシンプルなプロトコルです。結果として、RADIUS ベンダーのほとんどはよりシンプル

な PAP プロトコルと互換性がありますが、一部の RADIUS ベンダーはよりセキュリティの高い MSCHAP2 との

互換性を有していません。


VMware, Inc. 154

手順

1 [2 要素認証を有効にしますか] トグルをオンに切り替えます。

トグルが有効になっていると、ウィザードに追加の構成フィールドが表示されます。すべてのフィールドにアク

セスするには、スクロールバーを使用します。

次のスクリーンショットは、[外部 UAG] セクションのトグルをオンに切り替えた後に表示される内容の例です。

2 ドロップダウンリストで 2 要素認証方法を選択します。

このリリースでは、RADIUS 認証がサポートされています。

3 [名前] フィールドで、この構成の識別名を入力します。

4 [プロパティ] セクションで、アクセスの認証に使用するログイン画面でのエンドユーザーの操作に関連する詳細

を指定します。


[表示名] このフィールドは空白のままにできます。このフィールドはウィザードに表示されますが、Unified Access Gateway の内部名

のみを設定します。この名前は Horizon クライアントによって使用されません。

[表示に関す

るヒント]必要に応じて、ユーザーに RADIUS ユーザー名とパスコードの入力を要求するときにエンドユーザークライアントのログイン

画面に表示されるメッセージに、エンドユーザーに対して表示されるテキスト文字列を入力します。指定されたヒントは、Enter

your DisplayHint user name and passcode としてエンドユーザーに表示されます。ここで、DisplayHint はこのフィール

ドで指定するテキストです。

このヒントを参考にして、ユーザーは正しい RADIUS パスコードを入力することができます。たとえば、

Example Company user name and domain password below のようなフレーズを指定すると、Enter your

Example Company user name and domain password below for user name and passcode というプロンプトがエンド

ユーザーに表示されます。


VMware, Inc. 155


[名前 ID のサフィック

ス]

この設定は、ポッドがシングルサインオンのために TrueSSO を使用するよう構成されている、SAML シナリオで使用されま

す。オプションとして、ブローカに送信される SAML アサーションユーザー名の後にシステムによって追加される文字列を指

定します。たとえば、ユーザー名が user1 としてログイン画面に入力され、@example.com の名前 ID のサフィックスがここで

指定された場合、システムはブローカに [email protected] の SAML アサーションユーザー名を送信します。

[反復回数] この RADIUS システムを使用してログインを試行する場合に、ユーザーに対して許可される認証の失敗試行の最大数を入力しま

す。

[ユーザー名

を維持]Horizon Cloud への認証中にユーザーの RADIUS ユーザー名を維持する場合はこのトグルを有効にします。有効になっている

場合：

n ユーザーは、Horizon Cloud に対する Active Directory 認証の場合と同じユーザー名認証情報を RADIUS でも利用でき


n ユーザーは、ログイン画面でユーザー名を変更することができません。

このトグルが無効になると、ユーザーはログイン画面で別のユーザー名を入力することができます。

注： Horizon Cloud での [ユーザー名の維持] の有効化とドメインセキュリティ設定の関係については、『Horizon Cloud 管理ガイド』の「[全般設定] ページでのドメインセキュリティ設定」トピックを参照してください。

5 [プライマリサーバ] セクションで、認証サーバの詳細を指定します。


[ホスト名/IP アド

レス]認証サーバの DNS 名または IP アドレスを入力します。

[共有シークレッ

ト]認証サーバと通信するため、シークレットを入力します。この値は、サーバで構成されている値と同じである必要がありま

す。

[認証ポート] 認証トラフィックを送受信するために認証サーバで構成されている UDP ポートを指定します。デフォルトは 1812 です。

[アカウントポー

ト]オプションとして、アカウンティングトラフィックを送受信するために認証サーバで構成されている UDP ポートを指定し

ます。デフォルトは 1813 です。

[メカニズム] 指定した認証サーバでサポートされている、デプロイされたポッドが使用する認証プロトコルを選択します。

[サーバタイムア

ウト]ポッドが認証サーバからの応答を待機する秒数を指定します。この秒数が経過した後、サーバが応答しない場合は再試行が

送信されます。

[最大再試行回数] ポッドが認証サーバへの失敗した要求を再試行する最大回数を指定します。

[レルムのプリフ

ィックス]オプションとして、名前が認証サーバに送信されるときに、システムによってユーザー名の先頭に付加される文字列を指定

します。ユーザーアカウントの場所はレルムと呼ばれます。

たとえば、ユーザー名が user1 としてログイン画面に入力され、DOMAIN-A\ のレルムのプリフィックスがここで指定され

た場合、システムは認証サーバに DOMAIN-A\user1 を送信します。レルムのプリフィックスを指定しないと、入力したユ

ーザー名だけが送信されます。

[レルムのサフィ

ックス]オプションとして、名前が認証サーバに送信されるときに、システムによってユーザー名の後に追加される文字列を指定し

ます。たとえば、ユーザー名が user1 としてログイン画面に入力され、@example.com のレルムのサフィックスがここで

指定された場合、システムは認証サーバに [email protected] を送信します。

6 （オプション） [セカンダリサーバ] セクションで、オプションとして、補助認証サーバの詳細を指定します。

高可用性を提供するにはセカンダリ認証サーバを構成することができます。[補助サーバ] トグルを有効にして、

手順 [プライマリサーバ] セクションの記載どおりにフィールドに入力します。


VMware, Inc. 156

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-FE87529D-CF7F-464D-B74F-A21F19A22F54.html

検証と続行、およびポッドのデプロイプロセスの開始

[検証と続行] をクリックした後、指定した値がシステムによって検証されます。すべてが検証されると、ウィザード

に確認のための情報の概要が表示されます。次にデプロイプロセスを開始します。

手順

1 [検証と続行] をクリックします。

次のような指定した値がシステムによって検証されます。

n これから作成されるサブネットのために指定したアドレス範囲が有効で、サブスクリプション内で選択した

リージョンの他のアドレスと重複していないか。

n サブスクリプションのクォータに、ポッドを構築するための十分な仮想マシン (VM) とコアがあるか。

n アップロードされた証明書ファイルは正しい PEM 形式か。

n 既存の管理サブネットを使用することを選択した場合、そのサブネットで Microsoft.SQL サービスエンド

ポイントが有効になっていますか。

重要： 2019 年 9 月のサービスリリース以降、ポッドの Microsoft Azure PostgreSQL データベースの使用を

サポートするために、新しいポッドのデプロイでは管理サブネットで Microsoft.SQL サービスエンドポイント

が有効になっている必要があります。次のスクリーンショットのような選択したサブネットをリストする検証エ

ラーが表示される場合は、ウィザードで選択した既存の管理サブネットに Microsoft.SQL サービスエンドポイ

ントが構成されていないことを意味します。この時点で、Microsoft Azure ポータルにログインし、サブネット

上で Microsoft.SQL サービスエンドポイントを有効にできます。その後、ウィザードを再送信してポッドをデ

プロイできます。エンドポイントを有効にする方法の詳細については、ポッドのデプロイの前に、Microsoft Azure の VNet で Horizon Cloud ポッドに必要なサブネットを作成するを参照してください。

すべてが検証されると、[サマリ] ページが表示されます。

ネットワークアドレスの重複に関するエラーメッセージが表示される場合は、サブスクリプションに同じ値を

使用している既存のサブネットがあるかどうかを確認します。

2 ウィザードの最終手順で、概要情報を確認して、[送信] をクリックします。

Microsoft Azure 環境へのポッドのデプロイを開始します。


VMware, Inc. 157

最初のポッドのデプロイに最大で 1 時間ほどかかる場合があります。ポッドが正常にデプロイされるまで、進捗状況

のアイコンが管理コンソールの [はじめに] 画面に表示されます。進捗状況を確認するときに、ブラウザ画面の更新が

必要になる場合があります。ブラウザベースのユーザーインターフェイスは、約 30 分後にタイムアウトして、ログ

インし直すよう要求することができます。

重要：通常、ポッドの保留中のステージは最大 10 分間続きます。ただし、Microsoft Azure China クラウドにポ

ッドをデプロイする場合、デプロイのプロセス全体が完了するまでに最大で 7 時間かかることがあります。このプロ

セスは地理的なネットワークの問題の影響を受け、バイナリがクラウドの制御プレーンからダウンロードされるとき

にダウンロードの速度が低下することがあります。

20 分後にポッドが保留中からダウンロード中の状態に変化せず、またデプロイ先が Microsoft Azure China では

ない場合、システムはポッドを自動的にエラー状態に設定します。また、ポッドをクラウドサービスに接続できな

いため、Microsoft Azure 環境のネットワーク接続状態を確認するように促すメッセージが表示されます。

デプロイされたジャンプボックス仮想マシンがクラウドサービスから必要なバイナリをダウンロードできず、ポッ

ドがエラー状態と表示される場合、環境のネットワーク構成に問題がある可能性があります。たとえば、VNet の設

定済み DNS が内部名または外部名を解決していない、必要なアウトバウンドポートが開いていない、またはファイ

アウォールによってブロックされている可能性があります。時には、Microsoft Azure コマンドラインインターフ

ェイスのソフトウェアをダウンロードするために使用される packages.microsoft.com サイトへの接続が一時的に

失われている場合があります。いくつかのテストを実行し、ポッドの要件に対して環境ネットワークが適切に構成さ

れているかどうかを検証することができます。ポッドのデプロイまたは初めてのドメインバインドで問題が発生し

た場合のトラブルシューティングを参照してください。

ポッドのデプロイプロセス全体を通して、[はじめに] ページの [キャパシティ] セクションには、プロセスの現在のス

テージ（保留中、ダウンロード中、構築中、接続中など）が示されます。

次の表は、ポッドを構築するステージについての、およその期間の例をいくつか示しています。

重要：デプロイの進行状況で発生する実際の期間は、その時点で存在するネットワーク遅延によって異なります。

ステージ期間の例

保留中 10 分

ダウンロード中 10 分

構成中 15 分

接続中 10 分

ポッドが正常にデプロイされた場合：

n Horizon Cloud が、対応する Horizon Cloud 顧客アカウントレコードで識別されるアカウント所有者に通知 E メールを送信します。この E メールには、ポッドのオンボーディングが完了したことが記載されています。

n [はじめに] 画面にはポッドが追加されたこととドメイン参加プロセスの完了を知らせるメッセージの横に緑色の

チェックマークが表示されます。


VMware, Inc. 158

注：この時点では、Active Directory ドメインがポッドにまだ登録されていないため、[削除] ボタンがページに表

示されます。何らかの理由でデプロイプロセスが失敗する場合、または使用した値が好ましくないため Active Directory ドメインを登録する前に再びやり直したい場合、[削除] ボタンをクリックしてデプロイされたアーティフ

ァクトを削除することができます。ポッドが正常に削除されたことが画面に示されたら、[追加] ボタンを再度クリッ

クしてプロセスを再開することができます。

ネットワーク遅延のため、この時点でポッドを削除することを選ぶと、すべてポッド関連のアーティファクトが完全

に Microsoft Azure 環境から削除される前に、[はじめに] ページでポッドが完全に削除されたことが示される可能性

があります。新しいポッドを削除した後、ポッドのデプロイウィザードを再び実行する前に、次の手順を行います。

1 Horizon Cloud ユーザーインターフェイスからログアウトします。

2 Microsoft Azure ポータルにログインします。

3 作成した VNet に移動します。

4 デプロイヤを使用してポッドのサブネットを自動作成した場合は、ポッドにより作成されたサブネットがないこ

と、およびそのポッドのサブネットに対して指定したアドレス範囲が VNet のアドレス空間から削除されている

ことを確認してください。

次に、Horizon Cloud にログインし直して、ポッドのデプロイウィザードを再び実行します。

次のステップ

Horizon Cloud の [はじめに] ウィザードの [全般的なセットアップ] を展開し、Active Directory ドメインの登録に

必要な作業を完了します。次に必要な作業は Active Directory の登録です。ドメインの登録後、このポッドの管理を

管理コンソールで継続します。『Horizon Cloud 管理ガイド』の「はじめに」を参照してください。Active Directory ドメインを登録したら、[はじめに] ウィザードに従って、次に完了するタスクを確認します。

ポッドでゲートウェイ構成を指定した場合、エンドユーザーが自身のデスクトップやリモートアプリケーションに

アクセスする前に、指定したゲートウェイのタイプに応じて DNS サーバに適切な CNAME レコードを設定する必要

があります。

n パブリック IP アドレスが有効な外部ゲートウェイの場合は、デプロイウィザードで入力した FQDN を、ゲート

ウェイの Azure ロードバランサリソースの自動生成されたパブリック FQDN にマッピングします。DNS サー

バレコードは、ロードバランサの自動生成されたパブリック FQDN とエンドユーザーが使用する FQDN をマ

ッピングします。これは、アップロードされた証明書で使用されます。次のコード行は、例を示します。Active Directory ドメインを登録した後、管理コンソールのポッドの詳細ページから使用する ID を見つけます。外部ゲ

ートウェイが専用の VNet にデプロイされていた場合は、[デプロイ ID] フィールドに表示されている ID を使用

します。

ourApps.ourOrg.example.com vwm-hcs-ID-uag.リージョン.cloudapp.azure.com


VMware, Inc. 159

n 内部ゲートウェイまたはパブリック IP アドレスがない外部ゲートウェイの場合は、デプロイウィザードで入力

した FQDN を、ゲートウェイの Azure ロードバランサリソースのプライベート IP アドレスにマッピングしま

す。DNS サーバレコードは、ロードバランサの IP アドレスとエンドユーザーが使用する FQDN をマッピング

します。これは、アップロードされた証明書で使用されます。次のコード行は、例を示します。

ourApps.ourOrg.example.com Azure-load-balancer-private-IP

外部および内部ゲートウェイ構成の両方を指定し、その両方に同じ FQDN を使用する場合は、受信するエンドユー

ザークライアントのトラフィックを、ゲートウェイのリソースグループ内の適切なロードバランサリソースにルー

ティングするための設定を行う必要があります。このシナリオでは、インターネットからのクライアントトラフィッ

クが外部ゲートウェイの Azure ロードバランサリソースにルーティングされ、イントラネットからのクライアント

トラフィックが内部ゲートウェイの Azure ロードバランサリソースにルーティングされるようにルーティングを設

定する必要があります。

ポッド詳細ページでロードバランサ情報を見つける手順については Horizon Cloud 管理ガイドを参照してくださ

い。

ポッドのゲートウェイ構成に RADIUS 2 要素認証を指定した場合は、次のタスクを実行する必要があります。

n RADIUS 設定を使用して外部ゲートウェイを構成し、ポッドで使用される VNet と同じ VNet 内で、または外部

ゲートウェイを専用の VNet に展開した場合は、ピアリングされた VNet トポロジ内でその RADIUS サーバにア

クセスできない場合、その RADIUS サーバが、外部ゲートウェイのロードバランサの IP アドレスからのクライ

アント接続を許可するように構成します。外部ゲートウェイ構成では、Unified Access Gateway インスタンス

は、そのロードバランサのアドレスを使用して、RADIUS サーバとの通信を試みます。接続を許可するには、そ

の外部ゲートウェイのリソースグループにあるロードバランサリソースの IP アドレスが、確実に RADIUS サーバ構成でクライアントとして指定されているようにします。

n 内部ゲートウェイを構成した場合や、外部ゲートウェイを構成してポッドで使用される VNet と同じ VNet 内で

RADIUS サーバにアクセスできる場合は、RADIUS サーバと通信する必要がある、Microsoft Azure でのゲート

ウェイのリソースグループで作成された適切な NIC からの接続を許可するように RADIUS サーバを構成しま

す。ネットワーク管理者が、ポッドの Azure 仮想ネットワークおよびサブネットに対する RADIUS サーバのネ

ットワーク可視性を決定します。RADIUS サーバは、ネットワーク管理者によって RADIUS サーバへのネットワ

ーク可視性が付与されたサブネットに対応するゲートウェイ NIC の IP アドレスからの、クライアント接続を許

可する必要があります。Microsoft Azure のゲートウェイのリソースグループには、そのサブネットに対応する

4 つの NIC があり、そのうち 2 つが 2 個の Unified Access Gateway インスタンスに対して現在アクティブで

す。もう 2 つはアイドル状態で、ポッドがアップグレードを完了した後にアクティブになります。実行中のポッ

ド操作のため、および各ポッドのアップグレード後のために、ゲートウェイと RADIUS サーバ間の接続をサポー

トするには、これらの 4 つの NIC の IP アドレスが RADIUS サーバ構成でクライアントとして指定されているこ

とを確認します。

これらの IP アドレスの取得方法については、『管理ガイド』を参照してください。

ポッドのデプロイプロセスで Workspace ONE Access テナントが作成されるよう指定した場合、そのテナントとポ

ッドの統合を完了させるための追加手順を行う必要があります。Active Directory ドメインを登録するために必要

なタスクを完了した後に、Horizon Cloud 管理ガイドの Workspace ONE Access 環境トピックで Horizon Cloud ポッド統合についての情報を参照してください。


VMware, Inc. 160

ポッドのデプロイまたは初めてのドメインバインドで問題が発生した場合のトラブルシューテ

ィング

Microsoft Azure の Horizon Cloud ポッドで使用する環境のネットワークが正しく設定されていないと、ポッドを

構築するプロセスが PENDING 状態のままになる場合や、デプロイ後の Active Directory 環境へのドメインバイン

ドのアクションが失敗する可能性があります。必要な送信ポートを開くことができないことと、DNS が内部アドレス

と外部アドレスの両方を解決できないことの 2 つが、最も一般的なネットワーク関連の原因です。ここで説明するト

ラブルシューティングの手順を実行することで、必要な送信ポートが開いていることと、DNS が内部アドレスと外部

アドレスの両方を解決できることを確認するためのテストを実行できます。

ポッドを正常にデプロイするためのネットワーク全体の要件は、この PDF リンクにある前提条件のチェックリスト

ドキュメントに示されていて、Microsoft Azure の Horizon Cloud ポッドに使用する VNet トポロジに必要な DNS サーバの設定および Microsoft Azure での Horizon Cloud ポッドの DNS の要件に記載されています。環境のネ

ットワークがこれらの要件を満たしていない場合は、次のいずれかまたは両方の問題が発生します。

問題一般的な原因

n [はじめに] ページにポッドが保留状態であることが示され、接続状態に

ならない。通常、ポッドは約 10 分間保留状態になります（Microsoft Azure China クラウドにポッドを展開する場合は例外で、さらに時間が

かかります）。

n ポッドが正常にデプロイされた場合でも、Active Directory を登録しよ

うとすると、ドメインバインドの手順がエラー「Unable to register

Active Directory」で失敗する。

n 必要な送信ポートが開いていないか、ファイアウォール環境によ

ってブロックされています。必要な送信ポートが開いていない、

またはファイアウォールによってブロックされている場合、ポッ

ドソフトウェアは Microsoft Azure クラウド環境に安全にダウ

ンロードされず、Horizon Cloud クラウド制御プレーンに接続

できません。その結果、保留状態のままになる問題が発生しま

す。

n VNet DNS サーバが、内部マシン名と外部マシン名の両方を解決

できる有効な DNS サーバを参照するように適切に構成されてい

ません。

n VNet DNS サーバは DNS サーバを正しく参照していますが、

DNS サーバは内部マシン名と外部マシン名の両方を解決できま

せん。

外部マシン名の DNS 解決が VNet に提供されない場合、保留状態が

続く問題とドメインバインドの問題が発生する可能性があります。

たとえば、DNS がドメインコントローラの Active Directory に解

決できない場合、ドメインバインドの手順は失敗します。VNet の

DNS 構成の詳細については、Microsoft Azure の Horizon Cloud ポッドに使用する VNet トポロジに必要な DNS サーバの設定を参照


DNS 構成が内部名と外部名を解決できること、および必要な送信ポートが開いていることを確認するためのいくつか

のテストを実行するには、Microsoft Azure サブスクリプションに小さなテスト用仮想マシン (VM) をデプロイし、

その仮想マシンを使用してこれらのネットワークテストを実行します。トラブルシューティング手順の概要は次の

とおりです。

1 SSH キーペアを作成します。

2 Microsoft Azure サブスクリプションにテスト用仮想マシンを作成します。

3 テスト用仮想マシンに接続します。

4 ネットワークテストを実行します。


VMware, Inc. 161


5 テストが完了したら、テスト用仮想マシンと、このトラブルシューティングを行うために Microsoft Azure 環境

で作成されたすべてのテスト関連のアーティファクトを削除します。

注：テスト関連のアーティファクトを削除せず、後でポッドを削除するために管理コンソールの [削除] アクション

を使用すると、予期しない結果が発生する可能性があります。ポッドを削除するときに、システムはサブネットに接

続されているすべてのものが（ポッドの ID に応じて）ポッド自体に属していることを確認するために、ポッドのサ

ブネットをチェックします。追加の仮想マシン、仮想マシンのディスク、IP、またはその他のアーティファクトがポ

ッドのサブネットに接続されているとシステムによって判断された場合は、システムがポッドをクリーンに削除する

ことはできません。

トラブルシューティングテストの実行の詳細については、次のセクションを参照してください。

重要：すべてのトラフィックをオンプレミスネットワーク経由で通るように向けていて、認証トラフィックの通過

のみを許可している場合に、ポッドデプロイウィザードでプロキシを使用するための値を指定しなかった場合は、

これらの手動のテストがすべて成功しても、非認証ソースであるジャンプボックスによって送信されたトラフィック

は失敗します。この状況では、ポッドデプロイが保留中の状態で停止します。この状況が発生した場合は、[はじめ

に] ページからポッドを削除し、ポッドデプロイウィザードを再実行し、必要なプロキシ情報を指定する必要があり

ます。

手順

1 SSH キーペアを作成する

Microsoft Azure サブスクリプションにデプロイするテスト用 Linux 仮想マシンを認証するには SSH キーペアが必要です。キーペアはテスト用仮想マシンに SSH 接続するために使用するシステムに作成します。その

システム上にすでにキーペアがある場合、この手順はオプションです。

2 Microsoft Azure サブスクリプションにテスト用仮想マシンを作成する

Microsoft Azure 環境でテスト用 Linux 仮想マシン (VM) を使用して、Horizon Cloud ポッドが構成されてい

るネットワーク接続を確認するテストを実行します。

3 SSH を使用してテスト用仮想マシンに接続する

Microsoft Azure 環境でネットワーク接続テストを実行できるように、テスト用仮想マシンに対して SSH (Secure Shell) 接続を実行します。

4 Microsoft Azure 環境でネットワークを確認するためのテストを実行する

ここでのテストを実行することで、DNS が内部アドレスと外部アドレスの両方を解決できる、および必要な送

信ポートが開いている、という 2 つのネットワーク関連の領域が適切に設定されていることを確認します。こ

れらのテストは、テスト用仮想マシンを使用して実行します。

5 テストの完了後にテスト用仮想マシンを削除する

Microsoft Azure のネットワーク構成を確認するためのテストを完了し、テスト用仮想マシンが不要になった

ら、Microsoft Azure 環境からその仮想マシンと関連するすべてのアーティファクトを削除する必要がありま

す。


VMware, Inc. 162

SSH キーペアを作成する

Microsoft Azure サブスクリプションにデプロイするテスト用 Linux 仮想マシンを認証するには SSH キーペアが必

要です。キーペアはテスト用仮想マシンに SSH 接続するために使用するシステムに作成します。そのシステム上に

すでにキーペアがある場合、この手順はオプションです。

Microsoft Windows または Linux システムのいずれかを使用してこの SSH キーペアを作成することができます。

ここでは両方のタイプのシステムでの手順を説明します。実際の状況に適した手順を選択してください。

Microsoft Windows システム上で SSH キーペアを作成する

Microsoft Windows システムを使用して、Microsoft Azure サブスクリプションにデプロイするテスト用 Linux 仮想マシンに SSH 接続する場合は、以下の手順を使用します。

Microsoft Azure でテスト用仮想マシンを作成する場合、生成されたパブリックキーファイルの内容を使用します。

テスト用仮想マシンに接続するために使用する Microsoft Windows システム上に既存の SSH キーペアがある場合

は、この手順をスキップし、Microsoft Azure サブスクリプションにテスト用仮想マシンを作成するでの説明に従っ

てテスト用仮想マシンの作成に進むことができます。

次の手順に従って、SSH キーペアを生成し、パブリックキーファイルの内容をコピーしてテスト用仮想マシンの作

成時に使用できるようにし、プライベートキーを PuTTY Pageant ツールにロードします。Pageant は、プライベ

ートキーをメモリに保持できる SSH 認証エージェントです。プライベートキーをメモリに保持することで、プライ

ベートキーはその Microsoft Windows システムから SSH セッションに対して自動的に適用されるので、簡単に使

用できるようになります。

前提条件

デフォルトでは、Microsoft Windows システムには、SSH キーペアソフトウェアがインストールされていません。

使用する予定があるシステムに SSH キーペア生成ソフトウェアがインストールされていることを確認します。任意

の SSH キーペア生成ソフトウェアを使用できます。以下の手順では、Microsoft Windows 上で PuTTY ソフトウェ

アを使用して SSH キーペアを作成する方法について説明します。PuTTY ソフトウェアは、www.putty.org から取

得できます。インストール後、PuTTY の一連のツールを使用できます。次のスクリーンショットは、[スタート] メニ

ューの PuTTY ツールの例を示します。


VMware, Inc. 163

https://www.putty.org

手順

1 Microsoft Windows システムで、PuTTYgen（PuTTY キージェネレータ）を起動します。

Microsoft Windows 10 では、[スタート] メニューの PuTTYgen 項目は、のようになりま

す。

[PuTTY キージェネレータ] ウィンドウが表示されます。次のスクリーンショットで強調されているように、目

標は SSH-2 RSA タイプで 2048 ビットのパブリック - プライベートキーペアを生成することです。

2 [SSH-2RSA] が選択され、ビット数に 2048 が設定されていることを確認し、[生成] をクリックします。ウィン

ドウは、進行状況バーを示す [キー] ウィンドウに変わります。


VMware, Inc. 164

3 カーソルを進行状況バーの下の空白領域でランダムに動かします。領域内でカーソルを移動すると、必要なラン

ダム性がプロセスに追加されます。

4 キーのパスフレーズを入力してシステムにプライベートキーを保存し、[プライベートキーを保存] をクリックし

ます。

注：キーパスフレーズを使用することは、オプションとしてのベストプラクティスです。ただし、キーのパス

フレーズを入力せずに [プライベートキーを保存] をクリックすると、キーのパスフレーズなしでプライベート

キーを保存するかを確認するポップアップウィンドウが表示されます。

プライベートキーが PPK ファイルとして保存されます。[プライベートキーを保存] をクリックした後、ローカ

ルシステムのディレクトリを参照し、ファイル名を入力して、ファイルを保存することができます。


VMware, Inc. 165

5 [パブリックキーを保存] ボタンを使用して、テスト用仮想マシンの作成時にパブリックキーをコピーできる場

所に保存します。

6 PuTTY の SSH 認証エージェントである Pageant を起動します。

Microsoft Windows 10 では、[スタート] メニューの Pageant 項目は、のようになります。ク

リックすると、帽子が付いたコンピュータで表された Pageant アイコンがシステムトレイにロードされます。

次のスクリーンショットは、Microsoft Windows 10 のシステムトレイにロードされた Pageant アイコンを示

します。

7 プライベートキーを Pageant に追加するには、システムトレイアイコンを右クリックし、[キーを追加] をクリ

ックし、ファイル選択ウィンドウを使用して、保存されたプライベートキー (PPK) ファイルに移動して選択しま

す。

注：以前にプライベートキーファイルを保存したときにキーのパスフレーズを指定した場合は、そのパスフレ

ーズを入力するためのボックスが表示されます。

この時点では、プライベートキーは Pageant にロードされます。アクションメニューの [キーの表示] 項目を使用し

て、ロードされたキーのリストのキーを表示することができます。PuTTY を使用して SSH セッションを開始すると、

PuTTY は Pageant からキーを自動的に取得し、そのキーを使用して認証するので、パスフレーズを入力する必要は

ありません。後で、SSH セッションの実行を終了して Pageant をシャットダウンするときには、Pageant システム

のトレイアイコンの右クリックメニューから [終了] を選択します。


VMware, Inc. 166

次のステップ

Microsoft Azure サブスクリプションにテスト用仮想マシンを作成するの手順に従って、テスト用の仮想マシンを作

成します。

Linux システム上で SSH キーペアを作成する

Linux システムを使用して、Microsoft Azure サブスクリプションにデプロイするテスト用 Linux 仮想マシンに

SSH 接続する場合は、以下の手順を使用します。

Microsoft Azure でテスト用仮想マシンを作成する手順では、生成されたパブリックキーファイルの内容を使用し

ます。テスト用仮想マシンに接続するために使用する Linux システム上に既存の SSH キーペアがある場合は、この

手順をスキップし、「Microsoft Azure サブスクリプションにテスト用仮想マシンを作成する」での説明に従ってテ

スト用仮想マシンの作成に進むことができます。

前提条件

これらの手順を実行する前に、別の目的で保持しておく既存の SSH キーペアが上書きされないことを確認してくだ

さい。Linux システムでは、SSH のパブリックおよびプライベートキーファイルは、デフォルトで Linux の

~/.ssh/id_rsa ディレクトリに作成されます。このディレクトリに SSH キーペアが存在し、次のコマンドを実行す

るときに同じファイル名を使用する場合、またはコマンド内で別の場所を指定し、その場所に SSH キーペアがすで

に存在する場合は、既存の SSH キーペアが上書きされます。

手順

1 Linux システムで、Bash シェルを開きます。

2 Bash シェルで、次のコマンドを入力します。

ssh-keygen -t rsa -b 2048

3 画面の指示に従い、キーを保存するファイルを入力し、パスフレーズを入力し、パスフレーズを確認します。

ここに画面の指示のサンプルを示します。ここでは、キーを保存するファイルとして mykey が入力されました。

-bash-4.1$ ssh-keygen -t rsa -b 2048

Generating public/private rsa key pair.

Enter file in which to save the key (/mts-cm/home/user1/.ssh/id_rsa): mykey

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

注：キーパスフレーズを使用することは、オプションのベストプラクティスです。

プライベートキーは指定したファイルに保存され、パブリックキーは同じ名前で拡張子が .pub のファイルに保

存されます。ファイルとして mykey を入力する上記の例を使用した場合、出力サンプルは次のようになります。

Your identification has been saved in mykey.

Your public key has been saved in mykey.pub.


VMware, Inc. 167

次のステップ

Microsoft Azure サブスクリプションにテスト用仮想マシンを作成するの手順に従って、テスト用の仮想マシンを作

成します。

Microsoft Azure サブスクリプションにテスト用仮想マシンを作成する

Microsoft Azure 環境でテスト用 Linux 仮想マシン (VM) を使用して、Horizon Cloud ポッドが構成されているネッ

トワーク接続を確認するテストを実行します。

前提条件

SSH キーペアを作成するでの説明に従って作成した SSH パブリックキーを持っていることを確認します。仮想マ

シンの作成ウィザードでこのパブリックキーを指定し、対応するプライベートキーを持つシステムからの SSH 接続

を仮想マシンが信頼するようにします。

Microsoft Azure で必要な仮想ネットワークを構成での説明に従って、仮想ネットワーク (VNet) の名前が、ポッド

のデプロイで使用しているものと同じであることを確認します。

ポッドのデプロイを実行して、デプロイプロセスがある時点で失敗する場合は、そのプロセスがすでにポッドの管理

サブネットを VNet 内で作成している可能性があります。

n その場合は、テスト用仮想マシンをそのサブネットにデプロイすることをお勧めします。VNet 上にポッドの管

理サブネットが存在するかどうかを確認するには、Microsoft Azure ポータルにログインし、該当の VNet に移

動してサブネットのリストを調べます。VNet に移動するには左のナビゲーションバーで [仮想ネットワーク]

（）を使用します。ポッドの管理サブネット名のパターンは、vmw-hcs-podID-net-management

になります。podID はポッドの UUID です。

n ポッドのデプロイプロセスで VNet 上にポッドの管理サブネットが作成されなかった場合は、VNet 上で使用可

能なサブネットを選択するか、新しいサブネットを作成して、テスト用仮想マシンで使用することができます。

手順


2 ポータルの左側のナビゲーションバーで、[仮想マシン]（）をクリックし、[+ 追加] をクリックします。


VMware, Inc. 168

3 Ubuntu Server 16.04 LTS を検索して選択します。

4 デプロイモデルとして [リソースマネージャ] を選択し、[作成] をクリックします。

[仮想マシンの作成] ウィザードが開き、基本設定を構成するための手順が表示されます。

5 仮想マシンの基本設定を指定し、[OK] をクリックしてウィザードの次の手順に移動します。


[名前] 仮想マシンの名前を入力します。

[仮想マシンのディスクタイプ] デフォルトの SSD 設定のままにします。

[ユーザー名] ここから入手できる Microsoft のドキュメントに従って、Microsoft Azure のユーザー名要件を

満たすユーザー名を入力します。

重要：この名前は、後で必要になるためメモしておきます。

[認証タイプ] [SSH パブリックキー] を選択します。

[SSH パブリックキー] このフィールドには、SSH キーペアを作成したときに作成した SSH パブリックキーを貼り付け

ます。貼り付けられた内容は、パブリックキーの ---- BEGIN SSH2 PUBLIC KEY ---- 行で始

まり、---- END SSH2 PUBLIC KEY ---- 行で終わる必要があります。

[サブスクリプション] ポッドに使用しているのと同じサブスクリプションを選択します。

[リソースグループ] テスト用仮想マシンおよびそのディスクなどの関連するアーティファクトのための新しいリソー

スグループを作成することをお勧めします。[新規作成] を選択し、新しいリソースグループの名

前を入力します。このテスト用仮想マシンには既存のリソースグループを使用することができま

すが、テストの実行が終了したときにリソースグループ全体を削除した方が、より簡単に仮想マ

シンおよび関連するアーティファクトを削除できるので、テスト用仮想マシンに固有のリソース

グループを使用することをお勧めします。

[場所] ポッドに使用しているのと同じ物理的なリージョンを選択します。


VMware, Inc. 169

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/faq#what-are-the-username-requirements-when-creating-a-vm

6 ウィザードのサイズ設定の手順で、仮想マシンのサイズをクリックし、[選択] をクリックして次のウィザードの

手順に進みます。

ここでは検証テストを完了するために使用される一時的な仮想マシンを想定しているため、任意のサイズを選択

できます。ただし、通常はサイズが小さいほど Microsoft Azure の関連コストが低くなるため、テスト用仮想マ

シンには小さなサイズを選択するのが一般的です。次のスクリーンショットは、D2S_V3 の標準サイズを選択す

る場合の例を示します。


VMware, Inc. 170

7 ウィザードの設定の手順で、テスト用仮想マシンに対する主要なネットワーク項目を指定します。

このウィザードの手順では、3 つの重要な選択項目があります。次のスクリーンショットは、これらの 3 つの主

要な項目を示します。3 つの主要なネットワークオプションを設定した後、その他のすべてのデフォルト値を保

持することができます。


VMware, Inc. 171


[仮想ネットワーク] ポッドのデプロイに使用しているのと同じ VNet を選択する必要があります。この VNet は、前提条件チェックリストお

よび Microsoft Azure で必要な仮想ネットワークを構成に記載された指示に従って設定されている必要があります。

[サブネット] ポッドをデプロイしようとしてプロセスが失敗した場合は、ポッドの管理サブネットが仮想ネットワークで作成されてい

る可能性があります。サブネットがある場合は、このテスト用仮想マシンにそのサブネットを選択することをお勧めしま

す。選択された仮想ネットワークに存在するサブネットに移動するには、[サブネット] をクリックします。サブネット上

にマウスを移動すると、ツールチップにサブネットの完全名が表示されます。このスクリーンショットでは、サブネット

上にマウスを移動し、ポッドの管理サブネットの名前のパターンを表示しています。パターンは vmw-hcs-podID-net-

management です。

ポッドのデプロイプロセスで VNet 上にポッドの管理サブネットが作成されなかった場合は、テスト用仮想マシンに使用

するように識別された VNet 上のサブネットを選択します（上記の前提条件を参照）。

注：ポッドが正常に展開された後、ドメイン参加の問題のトラブルシューティングが発生した場合は、ドメイン参加の

操作はそのデスクトップサブネットに接続されたデスクトップイメージで使用されるため、管理サブネットの代わりにポ

ッドのデスクトップサブネットをテスト用仮想マシンのために選択することができます。

[パブリック IP アドレ

ス]この項目を選択すると、作成されたテスト用仮想マシンにはパブリック IP アドレスが割り当てられます。パブリック IP アドレスが割り当てられたテスト用仮想マシンには Wide Area Network (WAN) 経由で接続できます。

注：パブリック IP アドレスは、ネットワーク構成によっては使用できない場合があります。パブリック IP アドレスを持

つテスト用仮想マシンを作成できない場合は、ローカルシステムから、[サブネット] フィールドで選択したサブネットに

ネットワーク接続する必要があります。あるいは、ネットワーク上の他のマシンに接続してから、テスト用仮想マシンに

インバウンド接続する必要があります。

8 [OK] をクリックして、ウィザードのサマリの手順に進みます。

9 サマリの手順では、重要な情報（サブスクリプション、場所、仮想ネットワーク、サブネット）がポッドに使用

しているものと一致することを確認し、[作成] をクリックします。

テスト用仮想マシンの作成が開始します。次のスクリーンショットに示すように、通常は実行中のプロセスを

Microsoft Azure ダッシュボードに表示できます。


VMware, Inc. 172

仮想マシンのデプロイには通常 5 ～ 10 分かかります。仮想マシンが完全にデプロイされると、実行状態になります。

次のスクリーンショットに、サンプルのテスト用仮想マシンの詳細を示します。

テスト用仮想マシンが実行中であることを確認したら、接続します。SSH を使用してテスト用仮想マシンに接続する

の手順に従います。

SSH を使用してテスト用仮想マシンに接続する

Microsoft Azure 環境でネットワーク接続テストを実行できるように、テスト用仮想マシンに対して SSH (Secure Shell) 接続を実行します。

Microsoft Windows システムからテスト用仮想マシンに SSH 接続する

この接続は、テスト用仮想マシンの作成時に指定したパブリックキーに対応するプライベートキーを持つ Microsoft Windows システムから行います。

前提条件

テスト用仮想マシンの IP アドレスと、仮想マシンの作成時に指定したユーザー名があることを確認します。

Microsoft Windows システムでは、通常 PuTTY が使用されます。SSH セッションを開始するときに PuTTY がプラ

イベートキーを簡単に読み込むことができるように、PuTTY を起動する前に、Microsoft Windows システム上で

SSH キーペアを作成するでの説明に従って Pageant を起動し、SSH プライベートキーを Pageant キーリストに追

加します。SSH プライベートキーは、テスト用仮想マシンの作成時に指定したパブリックキーと一致する必要があ

ります。プライベートキーが Pageant に読み込まれると、PuTTY の SSH セッションはそのプライベートキーを自

動的に使用します。

手順

1 PuTTY を起動します（）。

[PuTTY 構成] ウィンドウが開きます。

2 [PuTTY 構成] ウィンドウでホスト名を指定し、[SSH] を選択し、[開く] をクリックします。

[PuTTY 構成] ウィンドウの [ホスト名] フィールドに、次のパターンで文字列を入力します。

testvm_username@testvmip


VMware, Inc. 173

テスト用仮想マシンのユーザー名と IP アドレスを、それぞれ文字列の testvm_username と testvmip に代入

します。

重要： [開く] をクリックした後、初めてテスト用仮想マシンに接続するときに、サーバのホストキーがキャッ

シュされていないことを示す PuTTY セキュリティメッセージが表示され、サーバの rsa2 キーフィンガープリ

ントが表示されます。接続を続行する場合は、[はい] をクリックしてサーバのホストキーを PuTTY のキャッシ

ュに追加するか、[いいえ] をクリックしてキーを PuTTY のキャッシュに追加せずに接続することができます。

テスト用仮想マシンへの接続がされていない可能性がある場合は、[キャンセル] クリックして接続を破棄し、

[PuTTY 構成] ウィンドウに戻り、ホスト名の入力を確認します。

次のスクリーンショットは、サンプルを使用したウィンドウを示します

[email protected]

。

SSH 接続が確立されると、次のスクリーンショットのようなコマンドラインウィンドウが表示されます。


VMware, Inc. 174

次のステップ

テスト用仮想マシンに接続したら、テストを実行して Microsoft Azure 環境内のネットワーク接続を確認できます。

Microsoft Azure 環境でネットワークを確認するためのテストを実行するで説明する手順を実行します。

Linux システムからテスト用仮想マシンに SSH 接続する

この接続は、テスト用仮想マシンの作成時に指定したパブリックキーに対応するプライベートキーを持つ Linux システムから行います。

前提条件

テスト用仮想マシンの IP アドレスと、仮想マシンの作成時に指定したユーザー名があることを確認します。

手順

1 Bash シェルを開きます。

2 Bash シェルの $ プロンプトで、次のように ssh コマンドを入力し、テスト用仮想マシンの IP アドレスとユーザ

ー名を、それぞれコマンドの testvmip と testvm_username に代入します。

ssh testvm_username@testvmip

たとえば、Microsoft Azure サブスクリプションにテスト用仮想マシンを作成するの例にあるテスト用仮想マシ

ンの詳細を使用すると、サンプルコマンドは次のようになります。

ssh [email protected]

SSH 接続が確立されると、次のスクリーンショットのようなコマンドラインウィンドウが表示されます。


VMware, Inc. 175

次のステップ

テスト用仮想マシンに接続したら、テストを実行して Microsoft Azure 環境内のネットワーク接続を確認できます。

Microsoft Azure 環境でネットワークを確認するためのテストを実行するで説明する手順を実行します。

Microsoft Azure 環境でネットワークを確認するためのテストを実行する

ここでのテストを実行することで、DNS が内部アドレスと外部アドレスの両方を解決できる、および必要な送信ポー

トが開いている、という 2 つのネットワーク関連の領域が適切に設定されていることを確認します。これらのテスト

は、テスト用仮想マシンを使用して実行します。

ポッドは DNS によって内部アドレスと外部アドレスの両方を解決します。ここでの最初の 2 つのテストでは、ネッ

トワーク環境で設定された DNS が、内部アドレスと外部アドレスの既知の FQDN を解決できるかを確認します。

重要：すべてのトラフィックをオンプレミスネットワーク経由で通るように向けていて、認証トラフィックの通過

のみを許可している場合に、ポッドデプロイウィザードでプロキシを使用するための値を指定しなかった場合は、

これらの手動のテストがすべて成功しても、非認証ソースであるジャンプボックスによって送信されたトラフィック

は失敗します。この状況では、ポッドデプロイが保留中の状態で停止します。この状況が発生した場合は、[はじめ

に] ページからポッドを削除し、ポッドデプロイウィザードを再実行し、必要なプロキシ情報を指定する必要があり

ます。

前提条件

これらのテストを実行する前に、Microsoft Azure サブスクリプションにテスト用仮想マシンを作成するおよび SSH を使用してテスト用仮想マシンに接続するでの説明に従って、Microsoft Azure サブスクリプションでテスト用仮想

マシンを作成し、SSH 接続があることを確認します。

Active Directory ドメインコントローラなど、VNet からアクセス可能であると考えられるネットワークの内部にあ

るサーバの IP アドレスと完全修飾ドメイン名 (FQDN) を取得します。この情報は、DNS 検証テストで使用します。


VMware, Inc. 176

手順

1 dlg コマンドを使用して Microsoft Azure の VNet の内部にある既知のドメイン名をクエリすることにより、

DNS が環境内で動作し、内部 FQDN を解決できることを確認します。

SSH 接続ウィンドウで、dig コマンドを実行し、Active Directory ドメインコントローラなどネットワークの

内部にあることがわかっているサーバのドメイン名をクエリします。

dig internal-domain-name

ここで、internal-domain-name は、ネットワークの内部にあることがわかっているサーバの完全修飾ドメイン

名です。

dig (Domain Information Groper) は、ネットワークトラブルシューティングのためのコマンドラインツール

です。内部ホスト名を使用してこのコマンドを実行した結果により、DNS 構成が内部アドレスを適切に解決でき

るかどうかが検証されます。DNS 構成がコマンドで使用される internal-domain-name を解決できる場合、コ

マンド出力はそのドメイン名に関連付けられた正しい IP アドレスを返します。

たとえば VNet が、DNS エントリが skylo.local で IP アドレスが 192.168.0.15 の Active Directory ドメイ

ンコントローラを持つ内部 Active Directory サーバで構成されているとします。dig skylo.local を発行す

ると、VNet の DNS 構成がその内部の skylo.local サーバ名を解決できるかどうかがチェックされます：

testvmadmin@HCS-testingVM:~$ dig skylo.local

; <<>> DiG 9.10.3-P4-Ubuntu <<>> skylo.local

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64899

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4000

;; QUESTION SECTION:

;skylo.local. IN A

;; ANSWER SECTION: skylo.local.600 IN A 192.168.0.15

;; Query time: 1 msec

;; SERVER: 192.168.0.15#53(192.168.0.15)

;; WHEN: Mon Mar 26 20:58:01 UTC 2018

;; MSG SIZE rcvd: 56

testvmadmin@HCS-testingVM:~$

ANSWER SECTION が、指定したホスト名がそのホスト名に対して予測される IP アドレスに解決されたことを

示している場合は、テストは成功です。

注：場合によっては DNS が完全に信頼できるものではなく、一部の要求は正常に解決され、他の要求は失敗

することがあります。コマンドの最初の発行が失敗する場合は、コマンドを 10 ～ 20 回繰り返して実行し、信頼

できる応答が毎回得られるかどうかを確認します。


VMware, Inc. 177

2 dlg コマンドを使用して既知の外部ドメイン名をクエリすることにより、DNS が環境内で動作し、外部 FQDN

を解決できることを確認します。

SSH 接続ウィンドウで、dig コマンドを発行し、vmware.com または microsoft.com などの外部の業界標準

ドメイン名をクエリします。

dig external-domain-name

ここで、external-domain-name は、VNet の外部にある完全修飾ドメイン名です。たとえば、dig vmware.com

を発行すると VNet の DNS 構成がその外部名を解決できたかどうかチェックします。

testvmadmin@HCS-testingVM:~$ dig vmware.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> vmware.com

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38655

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4000

;; QUESTION SECTION:

;vmware.com. IN A

;; ANSWER SECTION: vmware.com.150 IN A 107.154.105.19 vmware.com.150 IN A 107.154.106.19

;; Query time: 28 msec

;; SERVER: 192.168.0.15#53(192.168.0.15)

;; WHEN: Mon Mar 26 21:14:29 UTC 2018

;; MSG SIZE rcvd: 71

testvmadmin@HCS-testingVM:~

上記の例では、ANSWER SECTION は外部ドメイン名 vmware.com が 2 つの IP アドレスに適切に解決されたこ

とを示しています。

注：このテストを azure.com や microsoft.com などのさまざまな外部ドメイン名を使用して繰り返し、DNS

が異なる外部名を解決できることを確認できます。

DNS テストが機能しない場合は、ネットワーク構成および DNS サーバを確認してください。DNS サーバを

VNet に追加したことを確認します。

重要： DNS サーバを VNet に追加する必要がある場合、または VNet の DNS サーバ構成を変更する必要があ

る場合は、VNet に接続されているすべての仮想マシンを再起動して変更を反映する必要があります。VNet の

DNS サーバ設定を変更した後、その VNet に接続されたすべての仮想マシンを再起動しないと、変更は VNet 上で正しく伝達されません。


VMware, Inc. 178

3 netcat コマンドを使用して、必要な送信ポートが使用可能であることを確認します。

Horizon Cloud ではいくつかの送信ポートを開く必要があります。それによって、ポッドソフトウェアを

Microsoft Azure 環境に安全にダウンロードすることができ、またポッドを Horizon Cloud 制御プレーンに戻

すことができます。Microsoft Azure での Horizon Cloud ポッドの DNS の要件で説明するように、以下の送信

TCP ポートをポッドの管理サブネットから開く必要があります：port 80、443、および 11371。以下に示すよ

うに netcat コマンドを実行すると、それらの送信ポートが要求されるとおりに開いていることを確認できます。

SSH 接続ウィンドウで、次のコマンドを発行します（ポートごとに 1 つ）。

注：ポート 11371 をテストする以下のコマンドは packages.microsoft.com を指定してその接続をテスト

し、他の 2 つの行は Horizon Cloud 制御プレーンへの送信接続をテストします。

testvmadmin@HCS-testingVM:~$ netcat -v -w 3 cloud.horizon.vmware.com 80

Connection to cloud.horizon.vmware.com 80 port [tcp/http] succeeded!

testvmadmin@HCS-testingVM:~$ netcat -v -w 3 cloud.horizon.vmware.com 443

Connection to cloud.horizon.vmware.com 443 port [tcp/https] succeeded!

testvmadmin@HCS-testingVM:~$ netcat -v -w 3 packages.microsoft.com 11371

Connection to packages.microsoft.com 11371 port [tcp/hkp] succeeded!

ポートが正常に開くと、netcat コマンドはそのテストに対して succeeded! 行を返します。

netcat コマンドが失敗を返す場合は、Microsoft Azure のネットワーク接続、サブスクリプションのネットワー

クセキュリティグループ、および使用しているファイアウォールを確認します。Microsoft Azure での

Horizon Cloud ポッドの DNS の要件で説明されているように、ポッドがデプロイのために必要とする DNS、ポ

ート、およびプロトコルの要件を、ネットワーク構成が確実に満たすようにします。

上記のテストが成功した場合は、ポッドを正常にデプロイすることができます。

注： Radius の 2 要素認証や True SSO など、ポッドで使用するオプションの機能を設定している場合は、それらの

目的に応じて追加のポートが必要になることがあります。上記の送信ポートのテスト方法を使用して、それらのポー

トが適切に開いていることを確認することができます。

次のステップ

テストを完了したら、Microsoft Azure 環境からテスト用仮想マシンと、その仮想マシンのディスク、IP アドレス、

NIC などの関連するアーティファクトのすべてを削除する必要があります。理想的には、テスト仮想マシンのリソー

スグループを作成してあり、単純にそのリソースグループを削除することで仮想マシンのすべてのアーティファク

トを削除できることが望ましいです。テストの完了後にテスト用仮想マシンを削除するの手順に従います。

重要： Microsoft Azure 環境からすべてのテスト用仮想マシンのアーティファクトを削除しないで、仮想マシンを

ポッドのサブネットの 1 つに接続した場合、後で管理コンソールを使用してポッドを削除しようとしても、システム

はこれらの残りの接続されているアーティファクトのためにポッドを完全に削除できない可能性があります。デフォ

ルトでは、[削除] アクションを使用してポッドを削除する場合に、Horizon Cloud はポッドのために作成したこれら

のリソースグループおよびサブネットを削除します。Microsoft Azure は、継続して使用中であるサブネットの削除

を防止します。テスト用仮想マシンのアーティファクトがポッドのサブネットに接続されている場合は、これらのサ

ブネットは削除できず、ポッドの削除は完了しません。この状況を回避するには、ポッドを正常にデプロイした後に、

テスト用仮想マシンのすべてのアーティファクトが確実に削除されるようにします。


VMware, Inc. 179

テストの完了後にテスト用仮想マシンを削除する

Microsoft Azure のネットワーク構成を確認するためのテストを完了し、テスト用仮想マシンが不要になったら、

Microsoft Azure 環境からその仮想マシンと関連するすべてのアーティファクトを削除する必要があります。

重要： Microsoft Azure 環境からすべてのテスト用仮想マシンのアーティファクトを削除しないで、仮想マシンを

ポッドのサブネットの 1 つに接続した場合、後で管理コンソールを使用してポッドを削除しようとしても、システム

はこれらの残りの接続されているアーティファクトのためにポッドを完全に削除できない可能性があります。デフォ

ルトでは、[削除] アクションを使用してポッドを削除する場合に、Horizon Cloud はポッドのために作成したこれら

のリソースグループおよびサブネットを削除します。Microsoft Azure は、継続して使用中であるサブネットの削除

を防止します。テスト用仮想マシンのアーティファクトがポッドのサブネットに接続されている場合は、これらのサ

ブネットは削除できず、ポッドの削除は完了しません。この状況を回避するには、ポッドを正常にデプロイした後に、

テスト用仮想マシンのすべてのアーティファクトが確実に削除されるようにします。

手順


2 テスト用仮想マシンは、そのデプロイ方法に応じて次のいずれかの方法で削除します。

n テスト用仮想マシンを独自のリソースグループにデプロイし、そのグループを他の目的で使用していない場

合は、リソースグループ全体を削除できます。

注意：誤って他のアイテムを削除するのを回避するため、リソースグループを削除する前に、リソースグループにはテスト用仮想マシンと、ディスクやネットワークアダプタなどの関連オブジェクトのみが含まれ

るようにします。

a ポータルの左側のナビゲーションで、[リソースグループ] をクリックし、テスト用仮想マシンのリソー

スグループを検索します。

b リソースグループの名前をクリックすると、そのリソースグループのアイテムが表示されます。


VMware, Inc. 180

c [リソースグループの削除] をクリックします。確認メッセージで、リソースグループの名前を入力し、

[削除] をクリックします。

n リソースグループ全体を削除せずにテスト用仮想マシンを削除する必要がある場合は、ポータルの検索ボッ

クスを使用してテスト用の仮想マシンの名前を検索できます。検索結果には、仮想マシンとそのすべての関

連オブジェクト（ディスク、ネットワークインターフェイス、パブリック IP アドレスなど）が一覧表示さ

れます。各オブジェクトを個別に削除します。


VMware, Inc. 181

最初のポッドのデプロイが完了し、Horizon Cloud に接続されました 3おめでとうございます。最初の Horizon Cloud ポッドをのデプロイが完了しました。

管理コンソールの [はじめに] ページには、クラウド接続ポッドが正常に作成されたことが表示されます。

次のスクリーンショットは、最初のポッドが Microsoft Azure に展開されている場合のページの外観を示していま

す。

この時点で、このポッドで使用したい Active Directory ドメインに Horizon Cloud を登録するための手順を実行す

る必要があります。Horizon Cloud 管理ガイドに、これらの詳細な手順を示します。Horizon Cloud 環境の使用を

開始するという名称のトピックおよびそのサブトピックを参照してください。

VMware, Inc. 182



Tech Preview - Microsoft Windows 仮想デスクトップを拡張する VMware Horizon Cloud Service on Microsoft Azure

4Microsoft とのパートナーシップが拡張され、Microsoft Windows 仮想デスクトップを拡張する VMware Horizon Cloud Service on Microsoft Azure が Tech Preview の対象になりました。この Tech Preview は、この Tech Preview の一部としてポッドがデプロイされた Microsoft Windows 10 Enterprise マルチセッションおよび

Microsoft Windows 7 を使用するためのサポートを提供します。

n Tech Preview の登録

n この Tech Preview と一般公開されている VMware Horizon Cloud Service on Microsoft Azure リリースの

機能との関係

n この Tech Preview でデプロイされたポッドの DNS、ポート、およびプロトコルの要件

n この Tech Preview での Microsoft Windows 10 Enterprise マルチセッションと Horizon Cloud ポッドでの

サポートについて

n この Tech Preview の Microsoft Windows 7 VDI と Horizon Cloud ポッドでのサポートについて

n 一般的公開されたリリースと比較した場合の、この Tech Preview のサポートにおける特定の制限

Tech Preview の登録

まだ登録を受け付けている場合、https://vmware.com/go/HCTechPreview の登録フォームに記入して、この Tech Preview への参加を申し込むことができます。

VMware, Inc. 183

https://vmware.com/go/HCTechPreview

この Tech Preview と一般公開されている VMware Horizon Cloud Service on Microsoft Azure リリースの機能との関係

この Tech Preview に登録すると、この Tech Preview に固有の項目について以下のセクションで別途の記載がある

場合を除き、Microsoft Azure のポッドの一般公開された Horizon Cloud on Microsoft Azure リリースに適用され

る情報が同様に適用されます。

重要：以下のリンクに表示される一般公開されたリリースのドキュメントは、この Tech Preview のサポート用に

カスタマイズされていないことに注意してください。たとえば、『管理ガイド』にはこの Tech Preview に固有の情

報は含まれていません。この Tech Preview をサポートする一般公開されたリリースの『デプロイガイド』および

『管理ガイド』を補足する情報、またはそれらと異なる情報は、このトピック内に記載されています。

この Tech Preview では、Horizon Cloud の Auto Agent Update (AAU) 機能はサポートされていません。

この Tech Preview では、Microsoft Windows 7 VDI のために RDP プロトコルがサポートされています。これは、

そのオペレーティングシステムのためにこの Tech Preview でサポートされている唯一のプロトコルです。したが

って、この Tech Preview の一部として Microsoft Windows 7 VDI を実行する場合は、テナントサブネット内で

RDP ポート 3389 をブロックしないでください。

一般公開されたリリースからの重要なサポート情報は、次のリンクと、以下にリストされているリンクのリンク先ペ

ージにあります。

n Horizon Cloud for Microsoft Azure、Horizon 7 オンプレミス、および Horizon 7 on VMware Cloud on AWS へのオンボーディング。すべてのポッドタイプの全体的な Horizon Cloud のオンボーディングプロセス

について紹介します。VMware Horizon チームは、Horizon Cloud テナントアカウントと環境を作成し、この

Tech Preview に適したオプションを使用して有効にします。テナント環境の準備が整うと、

cloud.horizon.vmware.com に新しく作成された Horizon Cloud テナントポータルにログインするためのリ

ンクなどの追加情報を含むようこそ E メールが送信されます。

n 1 章 Horizon Cloud の紹介およびポッドをクラウド接続するためのオンボーディングの概要。Horizon Cloud の概念について説明します。

n 最初のポッドデプロイに対して Microsoft Azure クラウドキャパシティを選択する場合。Microsoft Azure でのポッドのデプロイについて概念レベルからの説明を提供します。

n クラウド接続された最初のポッドが Microsoft Azure へのデプロイから作成された場合の概要レベルのワーク

フロー。役に立つ作業用ポッドを取得するために実行する手順の概要を示します。

n VMware Horizon Cloud Service on Microsoft Azure 要件チェックリスト - 2019 年 12 月のサービスリリー

スで使用

n 『管理ガイド』の「Horizon Cloud 環境の使用開始」トピックとそのサブトピック。これらのトピックでは、

Active Directory 登録ワークフローや管理者の追加など、最初のポッドがデプロイされた後に実行するワークフ

ローについて説明します。

n 『管理ガイド』の「Microsoft Azure の Horizon Cloud ポッドの概要」とそのサブトピック。これらのトピック

では、イメージ仮想マシン、ファーム、VDI デスクトッププールの作成、エンドユーザーのデスクトップへの

資格付与など、ポッドで実行するサービスとしてのデスクトップワークフローのすべてについて説明していま

す。


VMware, Inc. 184

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.getstarted15/GUID-6E460805-C323-4200-9A45-45E7BFB31730.html

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-571F4415-515C-4BED-B02E-8ED2BBD8EF1C.html


https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-907A8E3F-72B8-4EB6-AB2E-BAC133EDA43B.html

この Tech Preview でデプロイされたポッドの DNS、ポート、および

プロトコルの要件

以下のトピックを読み、一般公開された Horizon Cloud リリースで使用されるポッドに必要な DNS、ポート、およ

びプロトコルの全体的なコンテキストを学習します：Microsoft Azure での Horizon Cloud ポッドの DNS の要件

および 2019 年 9 月のリリースのマニフェスト以降の Horizon Cloud ポッドのポートとプロトコルの要件。

重要： Tech Preview には、DNS に固有の要件があります。それらについては、引き続きトピックをお読みくださ

い。

Tech Preview のポートとプロトコルの要件は、上記のリンクにある一般公開されたリリースと同じです。ただし、

一般公開されたリリースのドキュメントの「ポートとプロトコルの要件」トピックのポートとプロトコルの表では、

Windows 7 RDP ポート 3389 の要件について記載されていません。これは、一般公開されたリリースには

Windows 7 が含まれていないためです。この Tech Preview の一部として Windows 7 VDI を使用する場合は、テ

ナントサブネット内の RDP ポート 3389 をブロックしないようにしてください。

この Tech Preview には、この Tech Preview のポッドをデプロイして使用するために満たす必要がある、これらと

同様の専用の DNS 要件があります。Tech Preview に固有の要件を次の表に示します。ネットワークファイアウォ

ールがこれらの要件を満たすように構成されていることを確認する必要があります。

表 4-1. ポッドのデプロイと操作に関する DNS の要件


管理 cloud-us-2.horizon.vmware.com 443 TCP Horizon Cloud 制御プ

レーン。Tech Preview では US リージョンのみ

がサポートされていま

す。

管理 softwareupdate.vmware.com 443 TCP VMware ソフトウェア

パッケージサーバ。シ

ステムのイメージに関連

する操作で使用されてい

るエージェントに関連す

るソフトウェアの更新を

ダウンロードするために

使用します。

管理 hydra-softwarelib-cdn.azureedge.net 443 TCP Horizon Cloud コンテ

ンツ配信サーバ。管理サ

ブネット上で、このサイ

トはポッドのマネージャ

および Unified Access Gateway 仮想マシンの

VHD（仮想ハードディ

スク）をダウンロードす

るために使用されます。

外部ゲートウェイが独自

の VNet にある場合は、

ゲートウェイコネクタ

仮想マシンの VHD にも



VMware, Inc. 185



管理 packages.microsoft.com 443 および

11371TCP Microsoft ソフトウェ

アパッケージサーバ。

Microsoft Azure コマ

ンドラインインターフ

ェイス (CLI) ソフトウェ

アを安全にダウンロード

するために使用します。

管理 azure.archive.ubuntu.com 80 TCP Ubuntu ソフトウェア




にポッド関連の Linux ベースの仮想マシンによ

って使用されます。

管理 api.snapcraft.io 443 TCP Ubuntu ソフトウェア







管理 archive.ubuntu.com 80 TCP Ubuntu ソフトウェア







管理 changelogs.ubuntu.com 80 TCP Ubuntu ソフトウェア



ングシステムの更新の

追跡用にポッドの

Linux ベースの仮想マ

シンによって使用されま

す。

管理 security.ubuntu.com 80 TCP Ubuntu ソフトウェア

パッケージサーバ。セ

キュリティ関連の







VMware, Inc. 186



管理 login.microsoftonline.com 443 TCP この Web アドレスは通

常、アプリケーションに

よって Microsoft Azure サービスを認証

するために使用されま

す。Microsoft Azure ドキュメントでの関連す

る説明については、

「OAuth 2.0 承認コード

フロー」および「Azure Active Directory v2.0 および OpenID Connect プロトコル」

を参照してください。

管理 management.azure.com 443 TCP Microsoft Azure Resource Manager エンドポイントへのポッド

API リクエストで、

Microsoft Azure Resource Manager サービスを使用するために


Microsoft Azure Resource Manager は、Azure PowerShell、Azure CLI、Azure ポー

タル、REST API、および

クライアント SDK を通

じてタスクを実行するた

めの一貫した管理レイヤ

ーを提供します。

管理 graph.windows.net 443 TCP Azure Active Directory (Azure AD) Graph API へのアクセ

ス。これは、OData REST API エンドポイン

トを介した Azure Active Directory (Azure AD) へのポッド

によるプログラムアク

セスに使用されます。


VMware, Inc. 187









管理 *.blob.core.windows.net 443 TCP Azure BLOB ストレー

ジへのポッドによるプロ

グラムアクセスに使用

されます。Azure Blob Storage は、大量の非構

造化オブジェクトデー

タ（テキストやバイナリ

データなど）を格納する

サービスです。

管理 *.vault.azure.net 443 TCP Azure Key Vault クラ

ウドサービスでポッド

をプログラムを通じて動

作させる機能に使用され

ます。Azure Key Vault は、シークレットの安全

なストアを提供するクラ

ウドサービスです。

管理ファイアウォールまたはネットワークセキュリティ


れている場合は、以下のいずれかになります。


n ポッドがデプロイされている Azure リージョン

の地域固有の SQL サービスタグ：Sql.region

（Sql.WestUS など）

ファイアウォールまたはネットワークセキュリティ


れていない場合は、データベースのホスト名を使用で

きます。この名前は、

*.postgres.database.azure.com のパターンに従い

ます。

5432 TCP Microsoft Azure PostgreSQL データベ

ースサーバへのポッド

の通信に使用されます。

セキュリティグループ

内のサービスタグの詳

細については、サービス

タグにある Microsoft Azure ドキュメントの

トピックを参照してくだ

さい。


VMware, Inc. 188





テナント hydra-softwarelib-cdn.azureedge.net 443 TCP Horizon Cloud コンテ

ンツ配信サーバ。テナン

トサブネット上で、この

サイトは、エージェント

に関連するソフトウェア

のインストーラをダウン

ロードするために、シス

テムの自動化されたイメ

ージのインポートプロ

セスによって使用されま

す。

テナント北米：




(CMS)、Horizon Cloud 内の主要なサービスの 1 つ。CMS の詳細につい

ては、「https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-9815E322-A13F-4E0A-B4F7-98B34A054D8F.html」を参照してくださ

い。

この Tech Preview での Microsoft Windows 10 Enterprise マルチセ

ッションと Horizon Cloud ポッドでのサポートについて

Microsoft Windows 10 Enterprise マルチセッションの詳細については、Microsoft ドキュメントの「Windows 10 Enterprise マルチセッションに関する FAQ」を参照してください。Microsoft Windows 10 Enterprise マルチセッ

ションは、新しい Remote Desktop Session Host (RDSH) タイプであり、以前は Microsoft Windows Server オペ

レーティングシステムのみが提供できた複数の同時対話セッションを許可します。

Microsoft Windows 10 Enterprise マルチセッションは RDSH タイプのオペレーティングシステムであるため、こ

の Tech Preview でサポートされているということは、Horizon Cloud 管理コンソールでは、Horizon Cloud が現

在のリリースでサポートしている RDSH に対応したオペレーティングシステムに関連する管理ワークフローにそれ

らのセッションが表示されることを意味します。RDSH に適用可能なオペレーティングシステムに適用される標準


VMware, Inc. 189












https://docs.microsoft.com/en-us/azure/virtual-desktop/windows-10-multisession-faq

https://docs.microsoft.com/en-us/azure/virtual-desktop/windows-10-multisession-faq

の管理コンソールのオプションとメニューは、関連するワークフローで Microsoft Windows 10 Enterprise マルチ

セッションを使用する場合に適用されます。RDSH に適用可能なオペレーティングシステムに関連する特定のオプ

ションを持つ Horizon Cloud ワークフローは、Horizon Cloud on Microsoft Azure の一般公開されたリリースの

ワークフローが説明されている『Horizon Cloud 管理ガイド』のポインタとともに次の表にリストされています。

注意: 一般公開された管理ガイドのドキュメントテキストは、この Tech Preview サポート用にカスタマイズされ

ていません。これらの HTML ページで文書化されたワークフローステップ内では、Microsoft Windows 10 Enterprise マルチセッションへの言及はありません。このドキュメントのテキストは、一般公開された Horizon Cloud 機能に適用されます。


VMware, Inc. 190

表 4-2. Microsoft Windows 10 Enterprise マルチセッションを使用する Horizon Cloud ワークフローへのポイン

タ

ワークフロー一般公開された管理ガイドの対応するトピッ

ク

Tech Preview サポートと一般公開 (GA) サー

ビスドキュメントの相違点

Microsoft Azure に Horizon Cloud ポッドの

デスクトップイメージを作成

Microsoft Azure とそのサブトピックに

Horizon Cloud ポッドのデスクトップイメ

ージを作成

次のような、Microsoft Windows Server オペ

レーティングシステムの GA ドキュメントで説

明されている手順とユーザーインターフェイス

オプションを使用します。

n Microsoft Azure Marketplace から自動

的にマスター仮想マシンを作成し、

Horizon Cloud とペアリングするのサー

バ関連のオプション

n マスターサーバイメージ仮想マシンの

Windows サーバゲスト OS をカスタマイ

ズする

n マスター仮想マシンを手動で作成する場

合、特に「エージェントインストール用の

マスターサーバ仮想マシンの準備」で、サ

ーバ仮想マシンに適用される手順を使用し

ます。

Tech Preview の既知の制限：

n NV シリーズの GPU は、Tech Preview ではテストもサポートもされていません。

この Tech Preview でサポートされている

Horizon Agent リモートエクスペリエンス

(RX) オプションのリストについては、次の表表

4-3. Microsoft Windows 10 Enterprise マル

チセッション —この Tech Preview でサポート

されている機能の RX 行を参照してください。

ファーム関連のワークフロー Horizon Cloud のファームとそのサブトピッ

ク

これらのワークフローは、マスターイメージ

からのセッションベースの RDSH デスクトッ

プとリモートアプリケーションを提供するフ

ァームを作成するものです。

Microsoft Windows 10 Enterprise マルチセ

ッションは RDSH タイプのオペレーティング

システムであるため、ファーム関連のワークフ

ローが適用されます。


n GA リリースのファーム電源管理機能は、

Tech Preview ではテストもサポートもさ

れていません。

セッションベースのデスクトップとリモートアプリケーションをエンドユーザーにプロビジョ

ニングする

RDSH セッションデスクトップ割り当ての作

成

Horizon Cloud Inventory のアプリケーシ

ョンとそのサブトピック

セッションベースのデスクトップ割り当てとリ

モートアプリケーション割り当てに関する GA リリースドキュメントのトピックの手順が適用

されます。

次の表では、この Tech Preview の Microsoft Windows 10 Enterprise マルチセッションのサポートの追加の側面

を示します。

重要：この表は、Tech Preview 期間中のサポートのみを示しています。


VMware, Inc. 191

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-D090D2ED-6446-4544-BEEC-D01F60F1F62B.html



https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-0C50B5BF-1673-40C1-B30D-B604450B345E.html



https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-D907EE17-37E9-4222-9BD4-F9225F7F9366.html



https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-F32B697A-BB68-4C7D-9021-C0D2DBA9409F.html

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-F32B697A-BB68-4C7D-9021-C0D2DBA9409F.html

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-B2391FC9-9D85-44E4-9526-6EC4CC64D6D7.html

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-DC9A088D-216F-4A0A-A9DC-D80EA0338151.html

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-DC9A088D-216F-4A0A-A9DC-D80EA0338151.html

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-6AD2B0E1-94D1-431E-A097-29053235EA69.html

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-6AD2B0E1-94D1-431E-A097-29053235EA69.html

サポートされている OS のバージョン Windows 10 Enterprise マルチセッション、バージョン 1909

Windows 10 Enterprise マルチセッション、バージョン 1903

サポートされている Microsoft Azure Marketplace イメージ Office 365 ProPlus、バージョン 1909 での Windows 10 Enterprise マルチセッション


Office 365 ProPlus、バージョン 1903 での Windows 10 Enterprise マルチセッション


エンドユーザーのプロビジョニングタイプセッションベースのデスクトップとリモートアプリケーション（公開ア

プリケーション）のプロビジョニングに使用されるファーム

サポートされている Horizon Client Windows

HTML Access

macOS

Linux

iOS

Android

Chrome

UWP

サポートされているプロトコル Blast Extreme

PCoIP

サポートされているリモートエクスペリエンス (RX) 機能次の機能は、「マーケットプレイスから仮想マシンをインポート」ウィザ

ードを使用する場合、または Horizon Agents Installer を手動で実行す

る場合にオプションでインストールできる Horizon Agent の機能です。

これらは、Microsoft Windows 10 Enterprise マルチセッションの

Tech Preview での使用がサポートされているオプションです。

n USB リダイレクト

n クライアントドライブのリダイレクト (CDR)

n リアルタイムオーディオビデオ (RTAV)

n スキャナリダイレクト

n シリアルポートリダイレクト

n HTML 5 リダイレクト

n URL コンテンツリダイレクト

n ブラウザコンテンツリダイレクト

n ドライバレス印刷

n クラウド監視サービス (CMS) とヘルプデスクをサポートする機能

この Tech Preview の Microsoft Windows 7 VDI と Horizon Cloud ポッドでのサポートについて

Microsoft Windows 7 はクライアントタイプのオペレーティングシステムであるため、この Tech Preview でサポ

ートされているということは、Horizon Cloud 管理コンソールでは、Horizon Cloud が現在のリリースでサポート

しているクライアントオペレーティングシステムに関連する管理ワークフローにそれらのセッションが表示される

ことを意味します。クライアントオペレーティングシステムに適用可能なオペレーティングシステムに適用される


VMware, Inc. 192

標準の管理コンソールのオプションとメニューは、関連するワークフローで Microsoft Windows 7 を使用する場合

に適用されます。クライアントオペレーティングシステムに関連する特定のオプションを持つ Horizon Cloud ワークフローは、Horizon Cloud on Microsoft Azure の一般公開されたリリースのワークフローが説明されている

『Horizon Cloud 管理ガイド』のポインタとともに次の表にリストされています。

注意: 一般公開された管理ガイドのドキュメントテキストは、この Tech Preview サポート用にカスタマイズされ

ていません。これらの HTML ページで文書化されたワークフローステップ内では、Microsoft Windows 7 への言及

はありません。このドキュメントのテキストは、一般公開された Horizon Cloud 機能に適用されます。

表 4-4. Microsoft Windows 7 を使用する Horizon Cloud ワークフローへのポインタ

ワークフロー一般公開された管理ガイドの対応するトピッ

ク

Tech Preview サポートと一般公開 (GA) サー

ビスドキュメントの相違点

Microsoft Azure に Horizon Cloud ポッドの

デスクトップイメージを作成

Microsoft Azure とそのサブトピックに

Horizon Cloud ポッドのデスクトップイメ

ージを作成

次のような、Microsoft Windows クライアン

トタイプのオペレーティングシステムの GA ドキュメントで説明されている手順とユーザー

インターフェイスオプションを使用します。

n Microsoft Azure Marketplace から自動

的にマスター仮想マシンを作成し、

Horizon Cloud とペアリングするのクラ

イアントオペレーティングシステム関連

のオプション

n マスター VDI デスクトップ仮想マシンの

Windows ゲストクライアント OS をカス

タマイズする

n マスター仮想マシンを手動で作成する場

合、特に「エージェントインストール用の

VDI デスクトップマスター仮想マシンの準

備」で、VDI デスクトップ仮想マシンに適

用される手順を使用します。


n NV シリーズの GPU はサポートされてい

ません

n Windows 7 VDI でサポートされている唯

一の Horizon Agent リモートエクスペリ

エンス (RX) オプションは、USB リダイレク

トと、クラウド監視サービス (CMS) および

ヘルプデスクをサポートする機能です。

n Blast Extreme および PCoIP プロトコル

はサポートされていません。RDP プロトコ

ルのみがサポートされます。

VDI デスクトップ関連のワークフローフローティングおよび専用 VDI デスクトップ

割り当てに関する「Horizon Cloud でのデス

クトップ割り当ての作成」とそのサブトピッ

ク。

Microsoft Windows 7 はクライアントタイプ

のオペレーティングシステムであるため、VDI デスクトップ関連のワークフローが適用されま

す。


n GA リリースの VDI デスクトップ割り当て

の電源管理機能は、Tech Preview ではテ

ストもサポートもされていません。


VMware, Inc. 193







https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-766EED3B-FB83-4B25-8474-CAB90963EBD2.html



https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-039DE380-F42F-45B1-9917-56AFB0C38410.html



https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-93033B78-1651-4C1A-9010-3D093C7ABB9D.html

https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-93033B78-1651-4C1A-9010-3D093C7ABB9D.html

次の表では、この Tech Preview の Microsoft Windows 10 Enterprise マルチセッションのサポートの追加の側面

を示します。

重要：この表は、Tech Preview 期間中のサポートのみを示しています。

サポートされている OS のバージョン RDP 8.x を使用した Windows 7 64 ビット (SP1) の簡易ロールアップ

サポートされている Microsoft Azure Marketplace イメージ Windows 7 Enterprise

エンドユーザーのプロビジョニングタイプ VDI — 専用 VDI およびフローティング VDI デスクトップ割り当て。

Horizon Cloud では、VDI デスクトップ割り当ては、エンドユーザーの

資格付与とデスクトップのプロビジョニングの両方に使用されます。

サポートされている Horizon Client Windows

サポートされているプロトコル RDP 8.x

サポートされているリモートエクスペリエンス (RX) 機能次の機能は、「マーケットプレイスから仮想マシンをインポート」ウィザ

ードを使用する場合、または Horizon Agents Installer を手動で実行す

る場合にオプションでインストールできる Horizon Agent の機能に関

連しています。これらは、Microsoft Windows 7 の Tech Preview での使用がサポートされているオプションです。

n USB リダイレクト

n クラウド監視サービス (CMS) とヘルプデスクをサポートする機能

一般的公開されたリリースと比較した場合の、この Tech Preview のサポートにおける特定の制限

以下の項目は、Microsoft Windows 10 Enterprise マルチセッションで標準の Horizon Cloud ワークフローを使用

する Tech Preview 期間中において、公式にテストもサポートもされていません。

n 電源管理機能

n N シリーズ仮想マシンを使用する GPU

n Horizon Cloud の Agent Auto Update (AAU) 機能

n 上記の Microsoft Windows 10 Enterprise マルチセッションの表にリストされているもの以外のリモートエクスペリエンス機能。

以下の項目は、Windows 7 VDI で標準の Horizon Cloud ワークフローを使用する Tech Preview 期間内に、公式に

テストもサポートもされていません。

n 電源管理機能

n GPU サポート

n Blast Extreme および PCoIP プロトコル

n Horizon Cloud の Agent Auto Update (AAU) 機能

n 上記の Microsoft Windows 7 の表にリストされているもの以外のリモートエクスペリエンス機能。


VMware, Inc. 194

horizon cloud デプロイ ガイ - docs.vmware.com · 最初のポッドのデプロイが...

Documents

horizon cloud デプロイガイ - docs.vmware.com · 最初のポッドのデプロイが...