サイトの構築を開始する前に、以下の点について計画を立て、必要な情報を収集してください。

• ネットワークに、Unity Connection サイトの接続の前提条件を満たさない音声メッセージサーバーが含まれるが、Voice Profile for Internet Mail (VPIM) プロトコル (例: Cisco Business Edition、Unity Connection サーバー、その他の VPIM 対応システム) をサポートしている場合、VPIM ネットワークを使用して接続します。

  以下の方法に従います。

  • サーバーがすでにVPIM 用に構成されていない限り、最初に、サイトをセットアップしてから、VPIM ネットワークをセットアップします。

  • サイト内で 1 つの Unity Connection ロケーションを選択し、VPIM ロケーションと連絡先の構成を処理します。 このロケーションは、「ブリッジヘッド」と呼ばれます。VPIM ロケーションと連絡先オブジェクトは、ブリッジヘッドからデジタルでネットワークせつぞくされたすべての Unity Connection ロケーションにレプリケートされます。これにより、これらのロケーションは、VPIM メッセージをアドレス指定できます。ネットワーク接続されたロケーションはその後、メッセージを配信用のブリッジヘッドからリモート音声メッセージサーバーに転送します。 これらのオブジェクトを単一の場所から管理することで、メンテナンスタスクが簡素化され、ユーザがメッセージの宛先を指定しようとするときに混乱を招く可能性がある連絡先情報の潜在的な重複を回避できます。

  • サイトに接続する複数のシステムで VPIM ロケーションがすでに構成されている場合は、サイトをセットアップする前に、重複する VPIM ロケーションを 1 台のサーバーを除くすべてのサーバーから削除します。 手順については、「VPIM ロケーションを削除する」項を参照してください。

  • VPIM ロケーションを Unity Connection サイトに移行する場合 (たとえば、VPIM ネットワークを使用して 2 つ以上の Unity Connection サーバーを接続し、サーバーを Unity Connection 14 にアップグレードした場合など)、まず Unity Connection サイトをセットアップします。 ディレクトリのレプリケートが完了し、Unity Connection ロケーション間でのメッセージ交換のテストが完了したら、移行されたサーバーとそのユーザを表す VPIM ロケーションと VPIM 連絡先を削除します。 タスクリストは、そのタスクを実行するタイミングをリマインドします。

• デフォルトでは、すべての Unity Connection のロケーション (サーバまたはクラスター) に、事前定義されたシステム分散リストがいくつか含まれています。これらのリストは変更できますが、削除できません。 これらのリストの名前を、各ロケーションで一意になるように変更していない場合、または名前がロケーション間で同じその他のリストを追加した場合は、初期レプリケーション中に、各ロケーションは、ローカルリストの名前と重複しているリモートリストの表示名にリモートサーバーの名前を追加します。 (デフォルトのリストは、All Voicemail Users、Undeliverable Messages、All Voicemail-Enabled Contacts です)。 これは、ローカルユーザーがこれらのリモートリストを宛先指定しようとした際に混乱を招く可能性があります。

  この問題を解決するには、以下のいずれかの方法を使用します。

  • 各ロケーションで個別にリストを維持する場合は、ホームロケーションの各リストの名前を変更できます。これにより、名前が固有になり (例:「<Location Name> の All Voicemail Users」)、ユーザーに各サーバーの新しいリスト名を周知できます。 この方法を選択する場合は、各リストの記録名を変更して、その情報源を示すようにしてください。

  • あるいは、サイトの設定後、ネットワーク上のすべての拠点にいるすべてのユーザを含むマスターリストを作成することもできます。 タスクリストには、このタスクをいつ、どのように実行するかについての指示が含まれています。

• Unity Connection ユーザーデータを LDAP ディレクトリのユーザーデータと同期する場合は、サイトをセットアップする前に、Unity Connection と LDAP ディレクトリを統合し、テストやトラブルシューティングを簡易化する必要があります。

• ネットワークに参加する各サーバについて、以下の情報をメモしておいてください。

  • サーバの IP アドレスまたは完全修飾ドメイン名（FQDN）。

  • システム管理者ロールに割り当てられているユーザアカウントのユーザ名とパスワード。

  • このサーバーに通話を転送するためにサーバー間サインインまたは転送がほかのサーバーで構成されている場合、ほかのサーバーがこのサーバーを呼び出すためのダイヤル文字列。

Unity Connection サイトを作成するには、まずサイト内リンク経由で 2 つのサーバーをリンクすることから始めます。 各サーバーは、新しいサイト内のロケーションとなります。 （Unity Connection クラスターがサイトにリンクされると、そのクラスターはサイト内の 1 つのロケーションとしてカウントされます。）

Unity Connection サーバーを、2 つ以上のロケーションの既存の Unity Connection サイトに追加する際は、サーバーをそのサイトの 1 つのロケーションにリンクします。追加するサーバーは、そのサイトのその他のすべてのロケーションの一覧を受信し、各ロケーションと情報を交換し、各ロケーションとの間でディレクトリ情報をレプリケートします。

このセクションには 2 つの手順が含まれています。 まず最初の手順を実行してください。Cisco Unity Connection Administration で最初の手順でサーバが正常にリンクされたことが示されない場合は、2 番目の手順を実行してください。 その後、サイトを追加するその他の各サーバーに対してこのプロセスを繰り返します。

SMTP は、サイト内の Unity Connection サイト間でディレクトリ情報とメッセージの両方を送信するために使用されます。

サイト内の任意のロケーションのペアが直接 SMTP メッセージを送受信できない場合 (ファイアウォールがサーバーを分離している場合など)、これらのロケーションが、SMTP スマートホスト経由でこれらのメッセージをルーティングするように構成する必要があります。

さらに、サイトに追加した各 Unity Connection クラスタの場合、その他すべてのネットワークロケーションがスマートホスト経由でクラスタにルーティングするように構成し、パブリッシャサーバーがダウンしている際に、メッセージトラフィックがクラスタサブスクライバサーバーに到達できるようにします。また、スマートホストが、クラスタの SMTP ドメインがパブリッシャサーバーとサブスクライバサーバーの両方に解決できるように構成する必要があります。 例えば、ネットワークには 1 台のスマートホストと、以下の 3 つの拠点があるとします。

• クラスタメンバーではない ServerA

• クラスター 1 は、パブリッシャーである ServerB とサブスクライバーである ServerC で構成されています。

• クラスター 2 は、パブリッシャーである ServerD とサブスクライバーである ServerE で構成されています。

Unity Connection サイトを作成するには、ServerA、ServerB、ServerD を接続して、サイトを構成します。 次の点に注意してください。　

• ServerA 上で、ServerB（クラスター 1 を表す）と ServerD（クラスター 2 を表す）の Unity Connection の場所を設定し、スマートホストを経由してルーティングするようにします。

• ServerB (クラスタ 1 パブリッシャー) 上で、ServerD (クラスタ 2 を表す) の Unity Connection ロケーションをスマートホスト経由でルーティングするように構成します。

• ServerD（クラスタ 2 のパブリッシャー）上で、ServerB（クラスタ 1 を表す）の Unity Connection の場所を設定し、スマートホストを経由してルーティングするようにします。

• スマートホスト上で、クラスタ 1 の SMTP ドメイン名が ServerB と ServerC の両方の IP アドレスに解決するように構成します (たとえば、DNS MX レコードの使用など)。 また、クラスタ 2 の SMTP ドメイン名が ServerD と ServerE の両方に解決するように構成します。

スマートホスト経由で他の場所にルーティングする必要がある各サーバに対して、以下のタスクを実行してください。

1. Unity Connection サーバーからのメッセージを受け入れるように SMTP スマートホストを設定します。 サイトに Unity Connection クラスタが含まれている場合は、スマートホストが、クラスタの SMTP ドメイン名がパブリッシャサーバーとサブスクライバサーバーの両方の IP アドレスに解決するよう構成します。 使用している SMTP サーバアプリケーションのドキュメントを参照してください。

2. スマートホストにメッセージをリレーするように Unity Connection サーバーを設定する 2-9 ページの「スマートホストにメッセージを中継するための Unity Connection の設定」の手順を参照してください 。

3. Unity Connection サーバーが、スマートホスト経由でメッセージをその他の Unity Connection ロケーションにルーティングするように構成します。 2-9 ページの「スマートホスト経由でロケーション間のメッセージをルーティングするように Unity Connection を構成する」を参照してください。

Unity Connection クラスタサーバペアを含むサイトを作成する場合、そのペアのうちパブリッシャーサーバのみをサイトに参加させます。 クラスタ サブスクライバ サーバーが、[プライマリ] 状態になった場合に、ネットワーク上のすべてのロケーションがそのサーバーと直接通信できるようにするため、サブスクライバサーバーからの SMTP 接続を許可するようすべてのネットワークロケーション (サブスクライバサーバーとクラスタ化されているパブリッシャサーバーを除く) を構成する必要があります。

クラスタからほかのロケーションへのルーティングがスマートホスト経由で行われない場合、パブリッシャサーバーが [プライマリ] 状態でない場合でも、ロケーションがクラスタからユーザーメッセージトラフィックを受信し続けるためには、直接 SMTP 接続が必要です。 サブスクライバサーバーとの直接的な SMTP 接続は、ディレクトリの更新には影響しません。これは、ディレクトリの更新はパブリッシャサーバーからのみ複製されるためです。

例えば、ネットワークには次の 3 つの場所があります。

• クラスタメンバーではない ServerA

• クラスター 1 は、パブリッシャーである ServerB とサブスクライバーである ServerC で構成されています。

• クラスター 2 は、パブリッシャーである ServerD とサブスクライバーである ServerE で構成されています。

サイトを作成するには、ServerA、ServerB、ServerD を一緒に接続する必要があります。 SMTP に直接アクセスするには、以下の手順が必要です。

• ServerA では、ServerC と ServerE (2 つのサブスクライバサーバー) の両方の IP アドレスを、IP アドレスアクセスリストに追加する必要があります。そうすることで、ServerA が [プライマリ] 状態である場合、どちらのサブスクライバサーバーとも通信できるようになります。

• ServerB（クラスタ 1 のパブリッシャー）では、ServerE（クラスタ 2 のサブスクライバー）の IP アドレスを IP アドレスアクセスリストに追加します。また、ServerD（クラスタ 2 のパブリッシャー）では、ServerC（クラスタ 1 のサブスクライバー）の IP アドレスを IP アドレスアクセスリストに追加します。

あるいは、各クラスタロケーションをスマートホスト経由でほかのすべてのロケーションにメッセージをルーティングするように構成することもできます。この方法を用いると、クラスタサブスクライバが [プライマリ] 状態になっている場合でも、ほかの Unity Connection ロケーションはクラスタサブスクライバからの SMTP 接続を直接許可する必要がなくなります。これは、クラスタサブスクライバがほかのすべてのロケーションと直接ではなく、スマートホスト経由で SMTP 接続を確立するためです。 上記の例において、代替構成は以下のようになります。

• ServerB (クラスタ 1 のパブリッシャ) で、スマートホストを設定し、ServerA と ServerD (クラスタ 2 のパブリッシャ) の Unity Connection ロケーションを構成して、スマートホスト経由でルーティングするようにします。

• ServerD (クラスタ 2 のパブリッシャ) で、スマートホストを設定し、ServerA と ServerB (クラスタ 1 のパブリッシャ) の Unity Connection ロケーションを構成して、スマートホスト経由でルーティングするようにします。

スマートホスト経由のルーティングの構成方法については、2-8 ページの「スマートホストを構成する」項を参照してください。 複数のクラスタが単一のサイトに接続している場合、各クラスタは既にスマートホスト経由でほかのクラスターにメッセージをルーティングするように構成されている必要があります。この場合、追加で必要なのは、クラスターとして構成されていないサーバーに対してスマートホスト経由でルーティングするようにクラスターを構成することだけです。

拠点間で初期レプリケーションが開始されると、ディレクトリのサイズによっては、すべての拠点間でデータが完全にレプリケートされるまでに数分から数時間かかる場合があります。

Cisco Unity Connection Administration の [Unity Connectionサイト内リンク] ページには、ロケーション間のレプリケーションの状況に関する情報が表示されます。 Unity Connection Administration でレプリケーションの状態を確認するには、以下の手順を実行してください。

ヒント

Unity Connection 14 ロケーションでは、Cisco Unity Connection Serviceability の音声ネットワークマップツールを使用しも、レプリケーションの状態を確認できます。 このツールを使用すると、サイト内のレプリケーションの問題を迅速に特定し、サイト内の任意の 2 つの場所間のレプリケーションの状態に関する情報を取得できます。 詳細については、ツール内で、[ヘルプ] > [このページ] の順に選択するか、『Cisco Unity Connection Serviceability リリース 14 向けアドミニストレーション ガイド』の「音声ネットワークマッピングツールを使用する」章「音声ネットワークマッピングツールについて」項を参照してください (入手先: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/14/serv_administration/guide/b_14cucservag.html)。

拠点間でサイトを最初に設定する場合、一方の拠点にホームされているユーザは、他方の拠点のユーザにメッセージを送信することができません。これは、各拠点のユーザが別々のパーティションに属しており、他方の拠点のユーザのパーティションを含まない検索スペースを使用しているためです。 ロケーション間の最初のレプリケーションが完了した後、他のサーバーをホームとするパーティションを含むようにサーチスペースを再設定できます。そして、ユーザー、ルーティングルール、コールハンドラ、ディレクトリハンドラ、および VPIM ロケーションの検索範囲を変更して、離れた場所をホームとするサーチスペースを使用できます。 (パーティションとサーチ スペースの両方がロケーション間で複製される一方で、別のロケーションをホームとするパーティションに、ユーザや他のオブジェクトを指定することはできないことに注意してください。)

最低限、いずれのサーバーでもデフォルトのパーティションと検索スペースに変更を加えていない場合は、各ロケーションで、各リモート Unity Connection ロケーションのデフォルトパーティションを、ローカルユーザーが使用する検索スペースに追加できます。 たとえば、ServerA、ServerB、ServerC という名前の 3 台のサーバーがあるネットワークで、システムのデフォルト設定を変更しない場合、ServerA の Cisco Unity Connection Administration では、「ServerB Partition」と「ServerC Partition」というデフォルトパーティションを「ServerA Search Space」というデフォルト検索スペースのメンバーとして追加します。ServerB の Unity Connection Administration では、「ServerA Partition」と「ServerC Partition」を「ServerB Search Space」に追加するなど、同様に設定します。

パーティションを検索スペースに追加する際の詳細については、『Cisco Unity Connection リリース 14 向けシステム アドミニストレーション ガイド』の「ダイヤルプラン」項を参照してください (入手先: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/14/administration/guide/b_14cucsag.html)。

サイト内通信では、ユーザーの資格情報は送信されません。 ただし、メッセージに含まれる SMTP アドレスのセキュリティを保護するため、Unity Connection ロケーション間で SMTP メッセージの送信に関与するスマートホストが、メッセージを適切にルーティングするように設定されていることを必ず確認します。これは、メッセージから SMTP アドレスを抽出できる可能性があるためです。 使用している SMTP サーバアプリケーションのドキュメントを参照して、手順を確認してください。

サイト構成をテストするには、各 Unity Connection ロケーションでテスト用ユーザーアカウントを作成するか、既存のユーザーアカウントを使用します。 テストで使用する Cisco Unity Connection Administration でユーザーアカウントを設定する場合は、各アカウントごとに必ず以下の手順を実行します。

• 音声名を録音してください。

• 内部用挨拶を録音し、有効にします。

• [ユーザ基本設定] ページで、[検索範囲] に対して、リモートユーザのパーティションを含む検索スペースを選択します。

• ユーザ基本設定ページで、「ディレクトリにリストする」チェックボックスをオンにします。

• 再生メッセージ設定ページで、「各メッセージを再生する前に、送信者の情報を再生する」チェックボックスをオンにします。

• 必要に応じて、サーバー間ライブ返信を有効にしてテストする場合は、[サービスのクラスを編集] を選択して表示される [メッセージオプション] ページで、[ほかのユーザーからのメッセージに電話で返信する] チェックボックスがオンになっているサービスのクラスにアカウントが属していることを確認します。 (チェックボックスは、デフォルトでオフになっています)。

サイトが正しく機能していることを確認するために、以下のテストを実施してください。

サイト内のすべてのサーバ上のすべてのユーザを含むマスター配布リストを作成する場合は、以下の手順を実行してください。

1. サイト内の各ロケーションで、All Voicemail Users リストの名前を固有の名前 (たとえば、<Location Name> の All Voicemail Users など) に変更します。 手順については、『Cisco Unity Connection リリース 14 向けシステム アドミニストレーション ガイド』の「システム分散リスト」章を参照してください (入手先: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/14/administration/guide/b_14cucsag.html)。

2. マスターリストとして使用する All Voicemail Users システム配布リストを 1 つのロケーションで新規作成します。

3. すべての場所のリストをマスターリストのメンバーとして追加します。

4. マスターリスト以外のすべてのリストを、ユーザーが使用する検索スペースに属さないパーティションに配置することで、ユーザーがマスターリスト以外のリストを宛先指定できないようにします。 たとえば、各ロケーションでの <Location Name> で Hidden DLs という名前の新しいパーティションを作成して、パーティションのそのロケーションをホームにするリストを配置します。 （デフォルトでは、新しいパーティションはどの検索スペースにも属しません。）

ヒント	ユーザーが、マスターリスト宛に操作品されたメッセージに対して [全員に返信] 機能を使用して大量の音声メッセージ トラフィックが生成されるのを防ぐために、検索スペースを使用して、マスターリストへのアクセスをを少数のユーザーに制限する必要があります。 これらのユーザは、マスターリストを含むパーティションが追加されている点を除けば、他のユーザが使用する検索スペースとほぼ同じ検索スペースを使用できます。

Unity Connection サーバを VPIM ネットワークからサイトのメンバーに移行した後、以前 VPIM ネットワークを使用してそのサーバとメッセージを交換していたサイト内の他のサーバから、そのサーバの VPIM ロケーションを削除する必要があります。 同様に、サーバ上の VPIM ロケーションのうち、サイト内の他の Unity Connection ロケーションを表すものはすべて削除する必要があります。 VPIM の場所を正常に削除するには、まずその場所に関連付けられているすべての連絡先を削除する必要があります。

Unity Connection ユーザーを表す VPIM 連絡歳を削除すると、分散リストから連絡先が削除されます。各サーバーで分散リストを見直して、更新し、必要に応じて、リモートユーザーを含めることを検討します。 また、移行対象サーバ上の連絡先を含むプライベートリストのメンバーシップを更新する必要があることをユーザに通知することも検討してください。

VPIM ロケーションおよび関連する VPIM 連絡先を削除する手順については、「VPIM ロケーションを削除する」を参照してください。

各サーバまたはクラスターは、それぞれ異なるユーザグループを処理する。 大規模な組織では、同じ場所に複数のサーバまたはクラスターが使用されている可能性がある。 この場合、各サーバーにどのユーザーアカウントを作成するか (各ユーザーの「ホーム」サーバーまたはロケーション) を決定し、そのマッピングを記録しておく必要があります。 この記録が必要な理由は以下のとおりです。

• ユーザーの電話機は、ユーザーがホームとしているシステムへの転送コールである必要があります。

• ユーザーの電話機に、[メッセージ] ボタンや、ボイスメールにアクセスするための番号にダイヤルする短縮ダイヤルボタンがある場合、それらのボタンは、ユーザーがホームとして属しているシステムに発信するように構成する必要があります。

• サーバー間サインインを構成していない場合、ユーザーはメッセージを確認するために、自身が所属するサーバーまたはクラスタのパイロット番号に発信する必要があります。この場合、ホームサーバーにアクセスする際にダイヤルする正しい番号をユーザーに周知する必要があります。

マッピングの記録を作成するには、各 Unity Connection ロケーションでユーザーレポートを実行します。 このレポートには、ユーザ名と主な所在地が含まれています。 詳細については、『Cisco Unity Connection リリース 14 向けシステム アドミニストレーション ガイド』の「高度なシステム設定」章の「レポート」項を参照してください (入手先: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/14/administration/guide/b_14cucsag.html)。

サイト間リンクを作成するには、各サイトで 1 つのロケーションを選択して、ほかのサイトへのゲートウェイとして機能させます。 すべてのサイト内通信 (ディレクトリ同期およびメッセージ交換の両方) は、め、接続要件および帯域幅の使用は、それら 2 つのロケーション間のリンクに限定されます。 2 つのサイト間でディレクトリの同期とメッセージの交換を行うには、選択するゲートウェイ同士が以下の接続性を備えている必要があります。

• ディレクトリ同期の場合、HTTPS 接続 (接続を暗号化する場合) または HTTPS 接続。

• メッセージ交換のための SMTP 接続。

ゲートウェイの場所を選択したら、それらの間で SMTP メッセージをルーティングする方法を決定します。 どちらの方向においても、メッセージを直接ルーティングすることも、SMTP スマートホストを使用することもできます。 SMTP スマートホストは、次のような状況で使用します。

• ゲートウェイは、SMTP 通信を遮断するファイアウォールによって隔てられている。

• ゲートウェイのどちらか一方、または両方が Unity Connection クラスタである。

ゲートウェイがクラスタである場合、パブリッシャサーバーがダウンした場合にメッセージトラフィックがクラスタ サブスクライバ サーバーに到達できるように、反対側のゲートウェイを構成して、スマートホスト経由のクラスタにルーティングするように構成し、クラスタの SMTP ドメインをパブリッシャサーバーとサブスクライバサーバーの両方に解決するようにスマートホストを構成する必要があります。 この場合は、双方向のトラフィックをスマートホスト経由でルーティングする必要があります。

このセクションには 2 つの手順が含まれています。

• Unity Connection サイトゲートウェイが SMTP メッセージを相互に直接ルーティングする場合は、「2 つの Unity Connection サイトゲートウェイを自動的にリンクする」を実行します。

  （注）	2 つのゲートウェイを自動的にリンクすると、選択した設定が両方のゲートウェイに適用されます。 リンクを作成した後、どちらのゲートウェイでもほとんどの設定を変更できます。 または、手動の手順を使用して、各ゲートウェイで異なる設定を行うこともできます。

• Unity Connection サイトゲートウェイで、SMTP メッセージのルーティングにスマートホストが必要な場合 (たとえば、ファイアウォールで分離されている場合、またはどちらか一方または両方のゲートウェイがクラスタの場合)、2-18 ページの「2 つの Unity Connection サイトゲートウェイを手動でリンクする」手順 を実行します。

サイト間のリンクを最初に設定した場合、一方のサイトの場所にホームされているユーザは、もう一方のサイトの場所にいるユーザにメッセージを送信することができません。これは、ユーザが別々のパーティションに存在し、もう一方のサイトの場所にあるユーザのパーティションを含まない検索スペースを使用しているためです。 サイト間の最初のレプリケーションが完了した後、リモートサイトをホームとするパーティションを含むようにサーチスペースを再設定できます。そして、ユーザー、ルーティングルール、コールハンドラ、ディレクトリハンドラ、および VPIM ロケーションの検索範囲を変更して、リモートサイトにあるロケーションをホームとするサーチスペースを使用できます。 (パーティションとサーチ スペースの両方がロケーション間で複製される一方で、別のロケーションをホームとするパーティションに、ユーザや他のオブジェクトを指定することはできないことに注意してください。)

最低限、いずれのサーバーでもデフォルトのパーティションと検索スペースに変更を加えていない場合は、各ロケーションで、各リモートサイトロケーションのデフォルトパーティションを、ローカルユーザーが使用する検索スペースに追加できます。 たとえば、サイト 1 に ServerA、ServerB、ServerC があり、サイト 2 に Server D がある組織では、システムのデフォルト設定を変更せずに、ServerA、ServerB、ServerC の Cisco Unity Connection Administration で、「ServerD Partition」というデフォルトパーティションをそれぞれ「ServerA Search Space」、「ServerB Search Space」、「ServerC Search Space」のデフォルト検索スペースのメンバーとして追加します。また、ServerD の Unity Connection Administration では、「ServerA Partition」、「ServerB Partition」、「ServerC Partition」を「ServerD Search Space」に追加するなどします。

パーティションを検索スペースに追加する際の詳細については、『Cisco Unity Connection リリース 14 向けシステム アドミニストレーション ガイド』の「ダイヤルプラン」項を参照してください (入手先: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/14/administration/guide/b_14cucsag.html)。

手順 9 の「2 つの Unity Connection サイトゲートウェイを自動でリンクする」または手順 12 の「2 つの Unity Connection サイトゲートウェイを手動でリンクする」の [ディレクトリデータ] チェックボックスを同期する際に、[分散リストを含める] をオンにした場合、リモートサイトで作成されたシステム分散リストに関する情報がローカルサイトにプルされます。 ただし、個々のリストに関する情報を別のサイトに提供するには、リストの「配布リストの基本設定の編集」ページで、「サイト間リンクを介してリモートサイトに複製する」チェックボックスをオンにする必要があります。 デフォルトでは、「サイト間リンクを介してリモートサイトに複製する」がチェックされているため、個々の Unity Connection システム配布リストはデフォルトで同期対象としてマークされます。 ただし、連絡先をシステム配布リストのメンバーとして許可するには、「サイト間リンクを介してリモートサイトに複製する」のチェックを外す必要があります。そのため、連絡先をメンバーとして許可するように構成されているリストがある場合、それらのリストはリモートサイトへの複製対象として提供されません。

個々のリストの同期を無効にするには、「サイト間リンクを介してリモートサイトに複製する」チェックボックスのチェックを外してください。 個々のリストの同期を有効にするには、メンバーとして追加されている連絡先をすべて削除し、[サイト間リンクを介してリモートサイトに複製する] チェックボックスをオンにします。 複数のリストの同期を一度に有効または無効にするには、[一括編集] または一括管理ツールを使用できます。

両サイトのすべてのサーバ上のすべてのユーザを含むマスター配布リストを作成する場合は、以下の手順を実行してください。

1. 各サイトのロケーションで、まだ行っていない場合は、All Voicemail Users リストの名前を固有の名前に変更します (<Server Name> の All Voicemail Users など)。 手順については、『Cisco Unity Connection リリース 14 向けシステム アドミニストレーション ガイド』の「システム分散リスト」章を参照してください (入手先: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/14/administration/guide/b_14cucsag.html)。

2. マスターリストをホストする組織内のロケーションを 1 つ選択します。 マスターリストとして使用する All Voicemail Users システム配布リストを 1 つのロケーションで新規作成します。

3. 両方のサイトのすべてのロケーションからリストをマスターリストのメンバーとして追加します。

   （注）	リモートサイトからリストを追加するには、マスターリストがホームになっているサイトのゲートウェイでは、[サイト間リンクの編集] ページで [ディレクトリデータを同期する際に分散リストを含める] チェックボックスをオンにする必要があります。また、リモートサイトの各ロケーションからのリストでは、[分散リストの基本を編集する] ページで [サイト間リンク経由でリモートサイトをレプリケートする] チェックボックスをオンにする必要があります。

4. マスターリスト以外のすべてのリストを、ユーザーが使用する検索スペースに属さないパーティションに配置することで、ユーザーがマスターリスト以外のリストを宛先指定できないようにします。 たとえば、各ロケーションでの <Server Name> で Hidden DLs という名前の新しいパーティションを作成して、パーティションのそのロケーションをホームにするリストを配置します。 (デフォルトでは、新しいパーティションは、検索スペースのメンバーではありません)。