デスクトップサブネットに、プロビジョニングされたデスクトップおよび RDSH サーバの数と、重複のための追加 バッファをカバーするのに十分な IP アドレスが含まれていることを確認します。
たとえば、サブネットの CIDR 形式で /24 を指定すると、ちょうど 252 個のアドレスを取得します。事前に追加の サブネットを追加すると、必要に応じたシームレスなキャパシティ拡張が可能になります。
Horizon Cloud Service ユーザー ポータルおよび管理コンソール ポータル URL の選択
ユーザーと管理者は、セキュリティで保護された Web ベースのポータルを介して、デスクトップ、RDSH サーバ、
および管理機能にアクセスできます。どちらのポータルも、同じ URL を使用し、次の例に示すように、その後に / horizonadmin が続きます。
ポータル 説明 サンプル URL
Horizon Cloud Service ユーザーポ ータル
エンドユーザーに Horizon Cloud Service デ スクトップやアプリケーションへのクライアント レスの HTML5 アクセスを提供する Web ベー スのポータル
https://desktop.virtualdesktopaccess.com
Horizon Cloud Service 管理コンソー ル
Horizon Cloud Service デスクトップおよび アプリケーション、リソース資格、イメージのプ ロビジョニングと管理のために IT 管理者が使用 する Web ベースのポータル
https://desktop.virtualdesktopaccess.com/horizonadmin
これらのポータルに使用する命名規則を定義できます。
ポータル URL オプション 1
このオプションは、簡単で使いやすいため、パイロットでは最も一般的です。DNS ドメインは、VMware によって 所有および提供されます。また、内部アクセス用にスプリット DNS をセットアップすることもできます。
n https://companyname.horizon.vmware.com
n VMware の *.horizon.vmwware.com 証明書を使用
ポータル URL オプション 2
オプション 2 には 2 つの選択肢があります。virtualdesktopaccess.com の所有者は、Apache2 形式で SSL 証 明書を提供し、スプリット DNS を使用して内部およびパブリック（必要な場合）DNS レコードをセットアップす る必要があります。
n https://desktop.virtualdesktopaccess.com
n https://www.virtualdesktopaccess.com
選択肢 1：サイトツーサイト VPN または Direct Connect がある場合は、Horizon Cloud Service 管理コンソー ルをパブリックインターネットからアクセス可能にするかどうかを選択できます。
選択肢 2：サイトツーサイト VPN または Direct Connect がないアイランドテナントがある場合、Horizon Cloud Service ユーザーポータルと管理コンソールは、Unified Access Gateway を介してパブリックインタ ーネットからアクセス可能である必要があります。
4
Horizon Cloud Service を展開する前に、Active Directory をセットアップすることが重要です。
デプロイプロセス全体を通して、早い段階から頻繁に Active Directory チームに問い合わせます。意思決定およ びデプロイプロセスにおいて、適切なドメイン管理者の権限を持つ、自分の Active Directory チームの代表者を 最初から関与させます。これにより、デプロイの早い段階において、すべてのユーザーが質問したり、懸念事項を表 明したり、問題に対処したりすることが可能になります。以下のリンク先に、考慮する必要があるトピックが記載さ れています。
この章には、次のトピックが含まれています。
n 既存または隔離された Active Directory の選択
n Active Directory のサービスアカウントの作成
n Active Directory のグループの作成
n Active Directory 用の一意の Horizon Cloud Service OU の作成
n DHCP スコープとオプションコード 74 のセットアップまたは手動による DaaS エージェントの構成
既存または隔離された Active Directory の選択
Horizon Cloud Service プラットフォームは Active Directory に依存しますが、Horizon Cloud Service を既 存の Active Directory 環境に統合する必要はありません。Horizon Cloud Service デスクトップとアプリケー ションサービスに対してローカルである、別の隔離された Active Directory ドメインを使用できます。Horizon Cloud Service チームに、隔離されたドメインを要求できます。
次の使用事例では、パイロットドメインを選択することが有利になります。
使用事例 説明
アウトソーシング先のユーザーを抱える企業 自分の会社が他の国に開発業務を移行しようという場合に、それらの従業員にはデスクトッ プを提供する必要がありますが、独自のインフラストラクチャに直接接続しないようにする 必要がある可能性が考えられます。パイロットドメインでは、隔離された環境において、そ れらの従業員が必要とするすべての設定を行うことができます。
季節雇用のユーザーを抱える会社 年に 2、3 回、2、3 か月の期間の季節労働が増える会社においては、会社の Active Directory 構造に多数のデスクトップを追加することを望まないことが考えられます。必
Active Directory のサービス アカウントの作成
Horizon Cloud Service 環境を既存の Active Directory と統合する選択をした場合、ドメインバインドとドメ イン参加の 2 つのタイプのサービスアカウントが必要になります。
n ドメインバインドアカウントは、Active Directory 構造を解析し、Horizon Cloud Service に指定された すべてのユーザーを引き込みます。
n ドメイン参加アカウントは、仮想デスクトップおよび RDSH サーバを Active Directory ドメインに参加させ ます。詳細については、管理ガイドを参照してください。
例については、Horizon Cloud セットアップ Web フォームを参照してください。
Active Directory のグループの作成
ユーザーを効率的に Horizon Cloud Service プラットフォーム内のデスクトップ、アプリケーション、およびテナ ントの管理機能にマッピングするには、各タイプのロール、機能、およびアクセスに対して、Active Directory で グループを作成することが賢明です。
Horizon Cloud Service プラットフォームとの互換性を維持するためには、次の点に注意してください。
n ネストの回避 – Active Directory オブジェクトの検索の効率性を確保するために、ネストされたグループを作 成しないでください。グループのメンバーは、ユーザーオブジェクトのみになります。
n 混合の回避 – 複数のドメイン（子または信頼済み）からのメンバーを同じグループに混在させないでください。
n グループの作成 – テナント管理、ヘルプデスクサポート、テストおよび検証ユーザー、および本番ユーザーの ためのグループを別個に作成します。Horizon Cloud Service テナント用に複数のドメインが構成されてい る場合、IT 管理者は、個々のドメインのテナント管理、ヘルプデスクサポート、テストおよび検証ユーザー、
および本番ユーザーについて、同様のグループを作成する必要があります。テナント管理者は、Horizon Cloud Service 管理コンソールにアクセスできます。テスト、検証、および本番ユーザーのグループは、Horizon
Cloud Service デスクトップおよびアプリケーションへのアクセスをプロビジョニングするために使用されま
す。
Active Directory 用の一意の Horizon Cloud Service OU の作成
Horizon Cloud Service プラットフォームによって作成されたコンピュータアカウントに対して一意の OU を実 装できます。
数千の OU およびグループがある大企業では、その Active Directory に数十万個のオブジェクトが含まれかねな い場合があります。企業は、Horizon Cloud Service プラットフォームによって作成されたコンピュータアカウン トに対して一意の OU を実装することで、デプロイの時間を短縮できます。一意の OU により、Horizon Cloud Service が仮想デスクトップおよび RDSH サーバのコンピュータオブジェクトを検索するために Active Directory 全体を解析する必要がなくなります。
ユーザー、アカウント、および必要な権限のリストについては、Horizon Cloud セットアップ Web フォームを参 照してください。
DHCP スコープとオプション コード 74 のセットアップまたは手動 による DaaS エージェントの構成
VMware Horizon Cloud Service チームに、インフラストラクチャ内で使用されていないサービスサブネットと デスクトップサブネットを指定する必要があります。また、これらのサブネットは、プロビジョニングされているデ スクトップまたは RDSH サーバの数をカバーするのに十分な IP アドレスを含んでいる必要があります。
デスクトップサブネットの DHCP スコープでオプションコード 74 を設定すると、デスクトップおよび RDSH サ ーバをテナントアプライアンスに向けることができます。VMware Horizon Cloud Service チームは、デプロイ プロセス中にテナントアプライアンスの 2 つの IP アドレスを提供します。
次の問題を認識しておく必要があります。
n オプションコード 74 を適切に設定できない – 設定が正しく完了しないと、デスクトップおよび RDSH サーバ はテナントアプライアンスを見つけて登録することができません。エンドユーザーは公開済みデスクトップお よびアプリケーションリソースにアクセスできません。
n 固有のサービスとデスクトップサブネットを指定できない - サービスとデスクトップサブネットを、クラウド にある場合でも、ローカルインフラストラクチャの拡張機能として考えます。すでに使用されているサブネット を指定すると、競合が発生し、ネットワークトラフィックが Horizon Cloud Service とネットワークとの間 で正しくフローしないことがあります。
n サイズの見積もりができない – ターゲットとなるデスクトップおよび RDSH サーバの数をカバーするのに十分 な IP アドレスを持つデスクトップサブネットを指定しない場合、キャパシティの増加をサポートするために別 のサブネットを設定する必要があります。たとえば、サブネットの CIDR 形式で /24 を指定すると、ちょうど 252 個のアドレスを取得します。事前に追加のサブネットを追加すると、必要に応じたシームレスなキャパシテ ィ拡張が可能になります。
ネットワーク制約などの理由で DHCP オプション 74 を構成できない場合は、DaaS エージェントを手動で構成し てテナントアプライアンスと通信することができます。VMware Horizon Cloud Service チームは、テナントア プライアンスの 2 つの IP アドレスを提供し、monitor.ini ファイルを使用して DaaS エージェントを手動で構成し ます。