ゾーン
展開がWANで接続された広範な場所に分散している場合、ネットワークの遅延と信頼性に関する問題が発生することがあります。このような問題の影響を軽減するには、次の2つの方法があります：
- それぞれに独自のSQL Serverサイトデータベースを持つ複数のサイトの展開
このオプションは、大規模な環境で推奨されます。複数サイトは個別に管理され、各サイトに独自のSQL Serverサイトデータベースが必要です。各サイトが個別のXenApp展開です。
- 単一サイト内に複数のゾーンを構成します。
ゾーンを構成することにより、リモートのユーザーが、WANの大規模セグメントを経由する接続を必ずしも必要とせず、リソースに接続できるようにサポートできます。ゾーンを使用することにより、単一のCitrix Studioコンソール、Citrix Director、およびサイトデータベースからの効果的なサイト管理が実現します。これにより、リモートの場所への追加サイト（個別のデータベースを含む）の展開、それに要する人員の配置、ライセンス取得、および運用のコストが削減されます。
ゾーンは、あらゆる規模の展開で有用です。ゾーンを使用して、アプリケーションおよびデスクトップとエンドユーザーの距離を縮めることにより、パフォーマンスを改善することができます。1つのゾーンにおいて、1つまたは複数のControllerをローカルでインストールして冗長性と回復性を確保することができますが、これは必須ではありません。
サイトで多数のControllerを構成すると、サイト自体へのControllerの新規追加など一部の操作のパフォーマンスが低下する可能性があります。こうした事態を回避するため、XenAppまたはXenDesktopサイトのゾーンの数は50以下に制限することをお勧めします。
注：
ゾーンのネットワーク待機時間が250ミリ秒（RTT）を超える場合は、ゾーンではなくサイトを複数展開することをお勧めします。
このアーティクルを通じ、「ローカル」という用語は、対象となるゾーンを指しています。たとえば、「VDAはローカルControllerに登録されます」という場合、VDAが存在するゾーンのControllerに登録されることを意味します。
このリリースでのゾーンは、XenApp Version 6.5以前と大きな違いはありませんが、同一ではありません。たとえば、このゾーン実装では、データコレクターが存在しません。サイトのすべてのControllerが、プライマリゾーンの1つのサイトデータベースと通信します。また、このリリースではフェールオーバーおよび優先ゾーンの機能が異なります。
ゾーンの種類
1つのサイトには、必ず1つのプライマリゾーンがあります。また、サイトにはオプションで1つまたは複数のサテライトゾーンを含めることもできます。サテライトゾーンは、障害回復、地理的に離れたデータセンター、ブランチオフィス、クラウド、またはクラウドのアベイラビリティゾーンに使用できます。
プライマリゾーン
プライマリゾーンのデフォルト名は「プライマリ」です。これには、SQL Serverサイトデータベース（および使用している場合は高可用性SQL Server）、Studio、Director、Citrix StoreFront、Citrixライセンスサーバー、およびNetScaler Gatewayが含まれます。サイトデータベースは、必ずプライマリゾーンに含まれている必要があります。
また、プライマリゾーンには、冗長性確保のために少なくとも2つのControllerが含まれている必要があります。また、データベースおよびインフラストラクチャと密結合されたアプリケーションを含む1つまたは複数のVDAが含まれる場合があります。
サテライトゾーン
サテライトゾーンには、1つまたは複数のVDAと、Controller、StoreFrontサーバー、およびNetScaler Gatewayサーバーが含まれます。通常時には、サテライトゾーンのControllerはプライマリゾーンのデータベースと直接通信します。
特に大きなサテライトゾーンには、そのゾーンのマシンのプロビジョニングまたは保存（もしくはその両方）に使用されるハイパーバイザーも含まれる場合があります。サテライトゾーンの構成時には、ハイパーバイザーまたはクラウドサービス接続をサテライトゾーンに関連付けることができます（この接続を使用するマシンカタログが同じゾーンに含まれていることを確認してください）。
ニーズと環境に応じて、1つのサイトに異なる構成のサテライトゾーンを含めることができます。次の図は、1つのプライマリゾーンと、複数のサテライトゾーンの例を示しています。
-
プライマリゾーンには、2つのController、Studio、Director、StoreFront、ライセンスサーバー、サイトデータベース（および高可用性SQL Server展開）が含まれています。また、プライマリゾーンには複数のVDAおよびNetScaler Gatewayも含まれています。
-
サテライトゾーン1 - VDA（Controllerあり）
サテライトゾーン1には、Controller、VDA、およびStoreFrontサーバーが含まれています。 このサテライトゾーンのVDAは、ローカルControllerに登録されます。ローカルControllerは、プライマリゾーンのサイトデータベースおよびライセンスサーバーと通信します。
WANで障害が発生した場合、接続リース機能を使用して、サテライトゾーンのControllerがそのゾーンのVDAへの接続を引き続き仲介することができます。このような展開は、オフィスを社内ネットワークに接続するWANリンクで障害が発生しても、作業者がローカルStoreFrontサイトおよびローカルControllerを使用してローカルリソースにアクセスするオフィスで効果的です。
- サテライトゾーン2 - VDA（冗長Controllerあり）
サテライトゾーン2には2つのController、VDA、およびStoreFrontサーバーが含まれています。この種類のゾーンは回復性が最も高く、WANとローカルControllerの1つで同時に障害が発生しても、それに耐えることができます。
VDAの登録とControllerのフェールオーバー
プライマリゾーンとサテライトゾーンを含み、VDAのバージョンが7.7以降のサイトでは、以下のルールが適用されます。
- プライマリゾーンのVDAは、プライマリゾーンのControllerに登録されます。プライマリゾーンのVDAでは、サテライトゾーンのControllerへの登録が試行されることはありません。
- サテライトゾーンのVDAは、可能な場合はローカルControllerに登録されます（これが優先Controllerになります）。 ローカルControllerを利用できない場合（ローカルControllerで追加のVDA登録を受け入れられない場合や、ローカルControllerで障害が発生している場合など）、VDAではプライマリゾーンのControllerへの登録が試行されます。この場合、サテライトゾーンのControllerが再び利用可能になっても、VDAはプライマリゾーンで登録されたままになります。サテライトゾーンのVDAでは、別のサテライトゾーンのControllerへの登録が試行されることはありません。
- ControllerのVDA検出で自動更新が有効になっており、VDAのインストール時にControllerアドレスの一覧を指定した場合、初回登録では、（Controllerが含まれるゾーンに関係なく）その一覧からランダムにControllerが選択されます。そのVDAが含まれるマシンが再起動された後、そのローカルゾーン内のControllerがVDA登録の優先Controllerになります。
- サテライトゾーンのControllerで障害が発生した場合、可能であれば別のローカルControllerへのフェールオーバーが実行されます。ローカルControllerを利用できない場合は、プライマリゾーンのControllerへのフェールオーバーが実行されます。
- Controllerをゾーン内またはゾーン外に移動し、自動更新が有効である場合、両方のゾーンのVDAに対し、ローカルのControllerとプライマリゾーンのControllerを示す更新された一覧が送信されます。これにより、登録および接続の受け入れが可能なControllerがVDAで認識されます。
- マシンカタログを別のゾーンに移動すると、そのカタログのVDAが、カタログを移動したゾーンのControllerに再登録されます（現在のゾーンに適切に接続されていないゾーンにカタログを移動する場合（遅延が大きいネットワークやまたは低帯域幅ネットワークなど）は、関連付けられているすべてのホスト接続も同じゾーンに移動してください）。
- プライマリゾーンのControllerには、すべてのゾーンの接続リース機能データが保持されます。サテライトゾーンのControllerには、そのゾーンおよびプライマリゾーンの接続リース機能データが保持されますが、ほかのサテライトゾーンのデータは保持されません。
プライマリゾーンですべてのControllerが失敗すると、以下の状態になります。
- Studioがサイトに接続できない。
- プライマリゾーンでVDAに接続できない。
- プライマリゾーンのControllerが使用できるようになるまで、サイトのパフォーマンスが低下し続ける。
Version 7.7よりも前のVDAバージョンが含まれるサイトでは、以下のルールが適用されます。
- サテライトゾーンのVDAでは、そのローカルゾーンおよびプライマリゾーンのControllerからの要求が受け入れられます（Version 7.7以降のVDAでは、ほかのセカンダリゾーンからのController要求を受け入れることができます）。
- サテライトゾーンのVDAは、プライマリゾーンまたはローカルゾーンのControllerにランダムに登録されます（Version 7.7以降のVDAでは、ローカルゾーンが優先されます）。
ゾーン優先度
重要：
ゾーンの優先度機能を使用するには、StoreFront 3.7以上およびNetScaler Gateway 11.0-65.x以上を使用している必要があります。
複数のゾーンがあるサイトでは、管理者は、アプリケーションやデスクトップの起動にどのVDAが使用されるかを、ゾーンの優先度機能によってより柔軟に制御できます。
ゾーンの優先度のしくみ
ゾーンの優先度には以下の3つの形式があります。以下によっては、特定のゾーンにVDAを使用するのが好ましい場合があります。
- アプリケーションのデータの保存先。これを「アプリケーションホーム」と呼びます。
- プロファイルやホームシェアなどの、ユーザーのホームデータの場所。これを「ユーザーホーム」と呼びます。
- （Citrix Receiverが実行されている）ユーザーの現在位置。これを「ユーザーの場所」と呼びます。
次の図は、マルチゾーン構成の例を示しています。
この例では、VDAは3つのサテライトゾーンにまたがっていますが、同じデリバリーグループに属しています。そのため、ブローカーはユーザーの起動依頼にどのVDAを使用するかを選択できる場合があります。この例では、ユーザーがCitrix Receiverエンドポイントを実行できる場所が多数存在しています。ユーザーAはサテライトゾーン1で、Citrix Receiverでデバイスを使用しています。ユーザーBはサテライトゾーン2でデバイスを使用しています。1人のユーザーのドキュメントをさまざまな場所に格納できます。 ユーザーAとBは、サテライトゾーン1をベースに共有を使用します。ユーザーCはサテライトゾーンCからの共有を使用します。また、公開アプリケーションのいずれかによって、サテライトゾーン1にあるデータベースが使用されます。
ユーザーまたはアプリケーションにホームゾーンを構成して、ユーザーまたはアプリケーションをゾーンと関連付けることができます。すると、Delivery Controllerのブローカーがこれらの関連付けを使用して、セッションが開始されるゾーンを選択します（リソースが利用可能な場合）。 以下を実行します：
- ユーザーをゾーンに追加して、ユーザーのホームゾーンを構成します。
- アプリケーションプロパティを編集して、アプリケーションのホームゾーンを構成します。
ユーザーまたはアプリケーションに構成できるホームゾーンは1回あたり1つのみです（ユーザーについては、複数のゾーンメンバーシップがある場合は例外となることがあります。「そのほかの考慮事項」セクションを参照してください。ただし、その場合においても、ブローカーが使うホームゾーンは1つのみです）。
ユーザーおよびアプリケーションのゾーン優先度を構成できますが、ブローカーは起動する優先ゾーンを1つだけ選択します。 優先ゾーンの選択におけるデフォルトの優先順位は、アプリケーションホーム、ユーザーホーム、ユーザーの場所の順になります。（この順序は制限できます（次のセクション参照））。ユーザーがアプリケーションを起動したとき：
- アプリケーションに構成済みのゾーンの関連付け（アプリケーションホーム）がある場合、優先ゾーンはそのアプリケーションのホームゾーンとなります。
- アプリケーションには構成済みのゾーンの関連付けがなく、ユーザーには構成されたゾーンの関連付け（ユーザーホーム）がある場合、優先ゾーンはそのユーザーのホームゾーンとなります。
- アプリケーションにもユーザーにもゾーンの関連付けが構成されていない場合、優先ゾーンはユーザーがCitrix Receiverインスタンスを実行しているゾーン（ユーザーの場所）となります。このゾーンが定義されていない場合は、VDAおよびゾーンのランダム選択が使用されます。負荷分散は、優先ゾーン内のすべてのVDAに適用されます。優先ゾーンがない場合、負荷分散はデリバリーグループ内のすべてのVDAに適用されます。
ゾーン優先度の調整
ユーザーまたはアプリケーションのホームゾーンを構成（または削除）すると、ゾーン優先度がどのように使われるか（または使われないか）をさらに制限できます。
- ユーザーのホームゾーンの使用必須： デリバリーグループで、セッションをユーザーのホームゾーンで開始し（ユーザーのホームゾーンがある場合）、ホームゾーンでリソースが利用可能でない場合には別のゾーンにフェールオーバーしないように指定できます。この制限は、大きなプロファイルやデータファイルがゾーン間でコピーされないようにする必要がある場合に有用です。つまり、他のゾーンでセッションを開始するのではなく、他のゾーンではセッションが開始されないようにします。
- アプリケーションのホームゾーンの使用必須： 同様に、アプリケーションのホームゾーンを構成する際に、アプリケーションをそのゾーンでのみ起動し、アプリケーションのホームゾーンでリソースが利用可能でない場合には他のゾーンにフェールオーバーしないように指定できます。
- アプリケーションのホームゾーンなし、構成済みのユーザーホームゾーンは無視： アプリケーションのホームゾーンを指定しない場合は、アプリケーションを起動するときに構成済みのユーザーゾーンを考慮しないように指定することもできます。たとえば、ユーザーの場所ゾーン優先度を使用して、ユーザーに他のホームゾーンがある場合でも、ユーザーが使用している（Citrix Receiver実行中の）マシンの近くにあるVDAで特定のアプリケーションが実行されるようにできます。
優先ゾーンによるセッション使用への影響
ユーザーがアプリケーションやデスクトップを起動すると、ブローカーは既存のセッションよりも優先ゾーンを使用しようとします。
アプリケーションまたはデスクトップを起動しているユーザーに、起動中のリソースに最適なセッション（アプリケーションのセッション共有を使用できるセッション、または起動中のリソースをすでに実行しているセッションなど）があるにもかかわらず、セッションがユーザーまたはアプリケーションの優先ゾーン以外のゾーンのVDAで実行されている場合、新しいセッションが作成されることがあります。これにより、セッションは、ユーザーのセッション要件に対して優先度の低いゾーンに再接続される前に、正しいゾーンで開始されます（そのゾーンに使用可能な容量がある場合）。
操作できなくなる孤立セッションが発生しないようにするため、優先ではないゾーンにあっても、再接続は既存の切断されたセッションにのみ許可されます。
セッション開始の望ましさの順は、以下のとおりです。
- 優先ゾーンにある既存セッションに再接続する。
- 優先ゾーン以外のゾーンにある既存の切断されたセッションに再接続する。
- 優先ゾーンで新しいセッションを開始する。
- 優先ゾーン以外のゾーンにある接続中の既存セッションに再接続する。
- 優先ゾーン以外のゾーンで新しいセッションを開始する。
ゾーン優先度に関するそのほかの考慮事項
- ユーザーグループ（セキュリティグループなど）のホームゾーンを構成する場合、（直接または間接メンバーシップによる）そのグループのユーザーは、指定されたゾーンに関連付けられます。ただし、ユーザーは複数のセキュリティグループのメンバーになることができるため、他のグループのメンバーシップで他のホームゾーンが構成されている可能性があります。そのような場合は、そのユーザーのホームゾーンの特定があいまいになる可能性があります。
ユーザーに、グループメンバーシップで取得されなかった構成済みのホームゾーンがある場合、そのゾーンがゾーン優先度に使用されます。グループメンバーシップで取得されたゾーンの関連付けはすべて無視されます。
ユーザーに、グループメンバーシップのみで取得された複数の異なるゾーンの関連付けがある場合、ブローカーはそれらのゾーンの中からランダムに選択します。ブローカーがゾーンを選択すると、そのゾーンはユーザーのグループメンバーシップが変更されるまで、後続のセッションの開始に使用されます。
- ユーザーの場所ゾーン優先度には、デバイスの接続を経由しているCitrix NetScaler Gatewayによるエンドポイントデバイス上のCitrix Receiverの検出が必要になります。NetScalerは、IPアドレスの範囲を特定のゾーンに関連付けるように構成する必要があり、検出されたゾーンのIDは、StoreFrontからControllerに渡される必要があります。
ゾーン優先度について詳しくは、「Zone Preference Internals」を参照してください。
考慮事項、要件、およびベストプラクティス
- ゾーンには、Controller、マシンカタログ、ホスト接続、ユーザー、およびアプリケーションを配置することができます。マシンカタログでホスト接続を使用する場合は、カタログと接続の両方が同じゾーンに含まれており、遅延が少なく、高帯域幅の接続である必要があります。
- サテライトゾーンにアイテムを配置すると、これらのアイテムおよびこれらに関連する他のオブジェクトとサイトとの通信方法に影響します。
- Controllerマシンがサテライトゾーンに配置されている場合、これらのマシンは同一のサテライトゾーンにあるハイパーバイザーおよびVDAマシンと良好に（ローカルに）接続できるものとみなされます。そのため、サテライトゾーンにあるハイパーバイザーやVDAマシンを処理する場合、プライマリゾーンのControllerではなく同じサテライトゾーンにあるControllerが使用されます。
- ハイパーバイザー接続がサテライトゾーンに配置されている場合、このハイパーバイザー接続で管理されているすべてのハイパーバイザーも同じサテライトゾーン内に存在するものとみなされます。そのため、サテライトゾーンにあるハイパーバイザー接続を使用して通信する場合、プライマリゾーンのControllerではなく同じサテライトゾーンにあるControllerが使用されます。
- マシンカタログがサテライトゾーンに配置されている場合、このカタログ内のすべてのVDAマシンも同じサテライトゾーンにあるとみなされます。このため、各VDAの初回登録後にControllerリストの自動更新メカニズムが有効になると、サイトへの登録時にはプライマリゾーンのControllerではなくローカルのControllerが使用されます。
- NetScaler Gatewayインスタンスもゾーンに関連付けることができます。この関連付けはこの記事で説明する他の要素と同様に、XenAppまたはXenDesktopのサイト構成ではなくStoreFrontの最適なHDXルーティング構成の一環として行います。ゾーンに関連付けられたNetScaler Gatewayは、そのゾーンにあるVDAマシンへのHDX接続で優先して使用されます。
- 実稼働サイトを作成してから、最初のマシンカタログおよびデリバリーグループを作成した場合、すべてのアイテムがプライマリゾーンに含まれます。初期セットアップを完了するまで、サテライトゾーンは作成できません（空のサイトを作成した場合、プライマリゾーンには初期状態ではControllerのみが含まれています。サテライトゾーンは、マシンカタログおよびデリバリーグループの作成前または作成後に作成できます）。
- 1つまたは複数のアイテムが含まれる最初のサテライトゾーンを作成する場合、サイトのそのほかすべてのアイテムはプライマリゾーンに残ります。
- プライマリゾーンのデフォルト名は「プライマリ」です。この名前は変更できます。Studio表示ではどのゾーンがプライマリゾーンかが示されますが、プライマリゾーンには容易に特定できる名前を使用するのがベストプラクティスです。プライマリゾーンは再割り当てする（すなわち、別のゾーンをプライマリゾーンにする）ことができます。ただし、プライマリゾーンには必ずサイトデータベースと高可用性サーバーが含まれている必要があります。
- サイトデータベースは、必ずプライマリゾーンに含まれている必要があります。
- ゾーンを作成した後、アイテムをゾーン間で移動できます。この柔軟性により、近くに配置することによって最適に機能する複数のアイテムを別々のゾーンに配置してしまう可能性があります。たとえば、マシンカタログを、カタログ内のマシンを作成する接続（ホスト）とは別のゾーンに移動すると、パフォーマンスが低下する場合があります。そのため、アイテムをゾーン間で移動する前に、意図しない影響が出る可能性を考慮してください。カタログとホスト接続（同じゾーンまたは適切に接続されているゾーン（遅延が少なく高帯域幅のネットワーク経由など）でカタログが使用するもの）を維持します。
- パフォーマンスを最適化するため、StudioとDirectorはプライマリゾーンのみにインストールします。サテライトゾーンに追加のStudioインスタンスが必要な場合（Controllerが含まれるサテライトゾーンが、プライマリゾーンにアクセスできなくなった場合のフェールオーバーとして使用されている場合など）、Studioをローカル公開アプリケーションとして実行します。DirectorはWebアプリケーションであるため、サテライトゾーンからもアクセスできます。
- サテライトゾーンのNetScaler Gatewayはゾーン内の接続に使用できますが、ほかのゾーンまたは外部からそのゾーンへのユーザー接続に使用するのが理想的です。
- 注意： ゾーンの優先度機能を使用するには、StoreFront 3.7以上およびNetScaler Gateway 11.0-65.x以上を使用している必要があります。
接続の質の制限
サテライトゾーンのControllerは、サイトデータベースに対してSQL操作を直接実行します。このため、サテライトゾーンと、サイトデータベースが含まれるプライマリゾーンとのリンクの質はある程度制限されます。一部の制限は、サテライトゾーンに展開されているVDAの数とこれらのVDA上のユーザーセッションの数に関係します。このため、VDAとセッションの数が少ないサテライトゾーンでは、VDAとセッションの数が多いサテライトゾーンよりもデータベースへの接続の質が低下します。
詳しくは、「遅延およびSQLブロッキングクエリの向上」を参照してください。
仲介のパフォーマンスに対する遅延時間の影響
ゾーンではリンクの遅延時間が大きくなりますが、ローカルブローカーが存在する場合、エンドユーザーのエクスペリエンスではさらに遅延が生じることになります。こうしたユーザーが行う作業のほとんどで、サテライトゾーンのControllerとサイトデータベース間での往復時間による遅れが生じます。
アプリケーションを起動する場合、セッションの仲介プロセスでセッション開始の要求を送信するのに適したVDAが見つかるまで、さらに遅れが生じます。
ゾーンの作成と管理
すべての管理権限を実行できる管理者は、ゾーンの作成および管理に関するすべてのタスクを実行できます。ただし、ゾーンを作成、編集、または削除できるカスタムの役割を作成することもできます。アイテムをゾーン間で移動するために、ゾーン関連の権限（ゾーン読み取り権限を除く）は必要ありません。ただし、移動するアイテムの編集権限は必要になります。たとえば、マシンカタログをゾーン間で移動するには、そのマシンカタログの編集権限が必要です。詳しくは、「委任管理」を参照してください。
Provisioning Servicesを使用する場合： このリリースに付属するProvisioning Servicesコンソールではゾーンが認識されないため、サテライトゾーンに配置するマシンカタログを作成する場合は、Studioを使用することをお勧めします。Studioウィザードを使用してカタログを作成し、適切なサテライトゾーンを指定します。その後、Provisioning Servicesコンソールを使用して、そのカタログのマシンをプロビジョニングします（Provisioning Servicesウィザードを使用してカタログを作成した場合、カタログはプライマリゾーンに配置されます。後でサテライトゾーンに移動するにはStudioを使用する必要があります）。
ゾーンの作成
- Studioのナビゲーションペインで、［構成］>［ゾーン］ の順に選択します。
- ［操作］ペインで ［ゾーンの作成］ を選択します。
- ゾーンの名前と説明（オプション）を入力します。名前はサイト内で一意にする必要があります。
- 新しいゾーンに配置するアイテムを選択します。選択できるアイテムの一覧では、フィルターまたは検索を実行できます。また、アイテムを選択せずに空のゾーンを作成することもできます。
- ［保存］ をクリックします。
この方法とは別に、Studioでアイテムを1つ以上選択してから、［操作］ペインで ［ゾーンの作成］ を選択することもできます。
ゾーンの名前または説明の変更
- Studioのナビゲーションペインで、［構成］>［ゾーン］ の順に選択します。
- 中央ペインでゾーンを選択し、［操作］ペインで ［ゾーンの編集］ を選択します。
- ゾーンの名前または説明（もしくはその両方）を変更します。プライマリゾーンの名前を変更する場合、そのゾーンをプライマリゾーンとして容易に特定できるようにしてください。
- ［OK］ または ［適用］ をクリックします。
アイテムのゾーン間移動
- Studioのナビゲーションペインで、［構成］>［ゾーン］ の順に選択します。
- 中央ペインでゾーンを選択し、1つまたは複数のアイテムを選択します。
- アイテムを移動先ゾーンにドラッグするか、または［操作］ペインで ［アイテムを移動］ を選択してから移動先ゾーンを指定します。
選択したアイテムが確認メッセージで一覧にされ、それらすべてのアイテムを移動するかどうかが確認されます。
注意： マシンカタログでハイパーバイザーまたはクラウドサービスへのホスト接続を使用している場合、そのカタログと接続はともに同じゾーンに含める必要があります。 同じゾーンに含まれていない場合、パフォーマンスが低下する可能性があります。どちらかのアイテムを移動したら、もう1つのアイテムも移動してください。
ゾーンの削除
ゾーンは、削除する前に空にする必要があります。プライマリゾーンは削除できません。
- Studioのナビゲーションペインで、［構成］>［ゾーン］ の順に選択します。
- 中央ペインでゾーンを選択します。
- ［操作］ペインで ［ゾーンの削除］ を選択します。ゾーンが空ではない（アイテムが含まれている）場合、それらのアイテムの移動先ゾーンを選択するよう指示するメッセージが表示されます。
- 削除を確認します。
ユーザーのホームゾーンの追加
ユーザーにホームゾーンを構成することは、ゾーンへのユーザーの追加とも言います。
- Studioのナビゲーションペインで ［構成］>［ゾーン］ の順に選択し、中央ペインでゾーンを選択します。
- ［操作］ペインで ［ゾーンにユーザーを追加します］ を選択します。
- ［ゾーンへのユーザーの追加］ ダイアログボックスで、［追加］をクリックしてからゾーンに追加するユーザーおよびユーザーグループを選択します。すでにホームゾーンがあるユーザーを指定すると、2つの選択肢を提供するメッセージが表示されます。 ［はい］ を選択すると、指定したユーザーのうち、ホームゾーンのないユーザーのみが追加されます。［いいえ］ を選択すると、ユーザー選択ダイアログに戻ります。
- ［OK］ をクリックします。
構成済みのホームゾーンがあるユーザーについては、ユーザーのホームゾーンからのセッション開始のみ要求できます。
- デリバリーグループを作成または編集します。
- ［ユーザー］ページで、［セッションはユーザーのホームゾーンで開始（構成済みの場合）］チェックボックスを選択します。
そのデリバリーグループ内のユーザーによって開始されたすべてのセッションは、そのユーザーのホームゾーンから開始される必要があります。 そのデリバリーグループ内のユーザーに構成済みのホームゾーンがない場合、この設定は有効になりません。
ユーザーのホームゾーンの削除
この手順は、ゾーンからのユーザーの削除とも言います。
- Studioのナビゲーションペインで ［構成］>［ゾーン］ の順に選択し、中央ペインでゾーンを選択します。
- ［操作］ペインで ［ゾーンからユーザーを削除します］ を選択します。
- ［ゾーンへのユーザーの追加］ ダイアログボックスで、［削除］をクリックして、ゾーンから削除するユーザーおよびグループを選択します。このアクションにより、ユーザーがゾーンからのみ削除されます。これらのユーザーは、属しているデリバリーグループおよびアプリケーショングループには残ったままとなります。
- 確認のメッセージが表示されたら、削除を確定します。
アプリケーションのホームゾーンの管理
アプリケーションにホームゾーンを構成することは、ゾーンへのアプリケーションの追加とも言います。デフォルトで、マルチゾーン環境では、アプリケーションにはホームゾーンがありません。
アプリケーションのホームゾーンは、アプリケーションのプロパティで指定されます。アプリケーションのプロパティは、アプリケーションをグループに追加するとき、またはその後に、Studioでアプリケーションを選択して、そのプロパティを編集することによって構成できます。
- デリバリーグループを作成するとき、アプリケーショングループを作成するとき、またはアプリケーションを既存のグループに追加するときに、ウィザードの［アプリケーション］ページで［プロパティ］を選択します。
- アプリケーションの追加後にアプリケーションのプロパティを変更するには、Studioのナビゲーションペインで ［アプリケーション］ を選択します。アプリケーションを選択し、［操作］ペインで ［アプリケーションプロパティの編集］ を選択します。
アプリケーションのプロパティまたは設定の ［ゾーン］ ページで以下の操作を行います：
- アプリケーションにホームゾーンを追加する場合は、
- ［選択したゾーンを決定に使用］ ラジオボタンを選択し、ドロップダウンからゾーンを選択します。
- アプリケーションを選択したゾーンからのみ起動する（他のゾーンからは起動しないようにする）には、ゾーン選択の下にあるチェックボックスを選択します。
- アプリケーションにホームゾーンを設定しない場合は、
- ［ホームゾーンを構成しない］ ラジオボタンを選択します。
- このアプリケーションを起動するときに、ブローカーによって構成済みのユーザーのゾーンが考慮されないようにするには、ラジオボタンの下にあるチェックボックスを選択します。この場合、アプリケーションのホームゾーンまたはユーザーのホームゾーンがこのアプリケーションを起動する場所の決定に使用されることはありません。
ゾーンの指定が含まれるそのほかの操作
サテライトゾーンを少なくとも1つ既に作成している場合、ホストの接続時またはマシンカタログの作成時（サイト作成時を除く）に、アイテムの割り当て先ゾーンを指定できます。
ほとんどの場合、プライマリゾーンがデフォルトで指定されます。Machine Creation Servicesを使用してマシンカタログを作成する場合、ホスト接続に対して構成されたゾーンが自動的に選択されます。
サイトにサテライトゾーンが含まれていない場合は、プライマリゾーンとして処理され、ゾーン選択ボックスは表示されません。