ブランチ サイトの復元要件

 

トピックの最終更新日: 2012-01-24

このトピックでは、ブランチ サイトの復元に対するユーザーの準備、ボイス メールの存続性に対するユーザーの準備、および関連するハードウェアとソフトウェアの要件について説明します。

ブランチ サイトの復元に対するブランチ サイトのユーザーの準備

レジストラー プールを存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーとして設定することにより、ブランチ サイトの復元に対してユーザーを準備します。

ブランチ ユーザーのレジストラーへの割り当て

いずれのブランチ サイトの復元ソリューションを選択した場合でも、Microsoft Lync Server 2010 のプライマリ レジストラーを各ユーザーに割り当てる必要があります。ブランチ サイトのユーザーは、常にブランチ サイトのレジストラーに登録する必要があります。これは、そのレジストラーが存続可能ブランチ アプライアンス、存続可能ブランチ サーバー、またはスタンドアロンの Lync Server 2010 Standard もしくは Enterprise Edition サーバーのいずれかに存在するかどうかに関係ありません。クライアントが各自のレジストラー プールを検出できるようにするためには、DNS SRV レコードの設定が必要です。存続可能ブランチ アプライアンスが利用できなくなった場合は、次の方法により、ブランチ サイトのクライアントは自動的にバックアップ レジストラーを検出します。

ブランチ サイトに DNS サーバーがない場合は、2 つの代替策によって、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーの検出を構成できます。

• ブランチ サイトの DHCP サーバーに DHCP オプション 120 を構成して、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーの完全修飾ドメイン名 (FQDN) を参照するように設定します。

• DHCP 120 のクエリに応答するように、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーを構成します。

ブランチ ユーザーの音声ルーティング

ブランチ サイトのユーザーに対して、個別のユーザーレベルの VoIP ポリシーを作成することをお勧めします。このポリシーには、存続可能ブランチ アプライアンスまたはブランチ サーバーのゲートウェイを使用するプライマリ ルートと、中央サイトの PSTN ゲートウェイを使用する 1 つ以上のバックアップ ルートが含まれている必要があります。プライマリ ルートが利用できなくなった場合は、1 つ以上の中央サイトのゲートウェイを使用するバックアップ ルートが代わりに使用されます。この方法により、ユーザーが登録されているのはブランチ サイトのレジストラーなのか、または中央サイトのバックアップ レジストラー プールなのかに関係なく、ユーザーの VoIP ポリシーが常に有効になります。これはフェールオーバー シナリオにおいて特に重要な事項です。たとえば、存続可能ブランチ アプライアンスの名前を変更するか、存続可能ブランチ アプライアンスを再構成して中央サイトのバックアップ レジストラー プールに接続する必要がある場合は、ブランチ サイトのユーザーをしばらくの間、中央サイトに移動する必要があります (存続可能ブランチ アプライアンスの名前の変更または再構成の詳細については、「展開」のドキュメントの「付録 B: 存続可能ブランチ アプライアンスの管理」を参照してください)。ブランチ サイトのユーザーにユーザーレベルの VoIP ポリシーまたはユーザーレベルのダイヤル プランが作成されていない場合に、ユーザーを別のサイトに移動すると、ブランチ サイトのサイトレベルの VoIP ポリシーおよびダイヤル プランではなく、中央サイトのサイトレベルの VoIP ポリシーとサイトレベルのダイヤル プランがユーザーに既定で適用されます。このシナリオでは、バックアップ レジストラー プールで使用されるサイトレベルの VoIP ポリシーとサイトレベルのダイヤル プランをブランチ サイトのユーザーに適用できない場合も通話は失敗します。たとえば、日本のブランチ サイトのユーザーをレドモンドの中央サイトに移動した場合、7 桁の番号の先頭にすべて +1425 を付加する正規化ルールを持つダイヤル プランによって、これらのユーザーの番号が適切に変換される可能性は低いでしょう。

重要:
ブランチ オフィスのバックアップ ルートを作成するときは、ブランチ オフィスのユーザー ポリシーに 2 つの PSTN 電話使用法レコードを追加し、各電話使用法レコードに個別のルートを割り当てることをお勧めします。最初のルート、すなわちプライマリ ルートは、SBA またはブランチ サーバーに関連付けられたゲートウェイに通話を振り分け、2 番目のルート、すなわちバックアップ ルートは、中央サイトのゲートウェイに通話を振り分けます。SBA またはブランチ サーバーは通話を振り分けるときに、最初の PSTN 使用法レコードに割り当てられたすべてのルートを試みてから、2 番目の使用法レコードのルートを試みます。

存続可能ブランチ アプライアンスのサイトの Windows コンポーネントが使用できないときでも (たとえば、存続可能ブランチ アプライアンスまたはブランチ ゲートウェイがメンテナンスで停止している場合)、ブランチ サイトのユーザーへの着信通話がユーザーにつながるようにするために、ゲートウェイ上でフェールオーバー ルートを作成し (または Direct Inward Dialing プロバイダーと連携して)、着信通話が中央サイトのバックアップ レジストラー プールにリダイレクトされるようにします。通話は、そこから WAN リンク経由でブランチ ユーザーにルーティングされます。ルートによって番号が PSTN ゲートウェイまたは他のトランク ピアの受け付け済み電話番号方式に準拠するように変換されることを確認します。フェールオーバー ルートの作成の詳細については、「フェールオーバー ルートの構成」を参照してください。また、ブランチ サイトのゲートウェイにサービスレベルのダイヤル プランを作成して着信通話を正規化します。ブランチ サイトに 2 つの存続可能ブランチ アプライアンスがある場合に、それぞれに対して個別のサービスレベルのプランが必要でなければ、その両方に対してサイトレベルのダイヤル プランを作成できます。

注:
プレゼンス、会議、またはフェールオーバーの実行を中央サイトに頼っているすべてのブランチ サイトのユーザーによる中央サイトのリソース消費に対応するには、各ブランチ サイトのユーザーを、中央サイトに登録されたユーザーとしてみなすことをお勧めします。現在のところ、存続可能ブランチ アプライアンスに登録されたユーザーを含めた、ブランチ サイトのユーザー数には制限はありません。

なお、ユーザー レベルのダイヤル プランと音声ポリシーを作成してから、ブランチ サイトのユーザーに割り当てることもお勧めします。詳細については、「展開」のドキュメントの「ダイヤル プランの作成」と「ブランチ ユーザー用の VoIP ルーティング ポリシーの作成」を参照してください。

内線番号のルーティング

ブランチ サイトのユーザーに対してダイヤル プランと音声ポリシーを準備するときは、msRTCSIP-line (または回線 URI) 属性で使用する文字列および数字形式と一致する正規化ルールと変換ルールを含めて、ブランチ サイトのユーザーと中央サイトのユーザーの間での Lync 2010 通話を適切にルーティングできるようにします。特に、WAN リンクを使用できないため、通話を PSTN 経由で再ルーティングする必要がある場合は、その必要があります。電話番号のみが含まれるのではなく、内線番号が含まれるダイヤル番号については、これ以外にも特別な検討事項があります。

内線番号を単独で含むか、E.164 準拠の電話番号に追加して含むかにかかわらず、内線番号を含む回線 URI を照合する正規化ルールと変換ルールには要件が追加されます。このセクションでは、いくつかのシナリオ例を挙げて、内線番号を含む回線 URI の通話をルーティングする方法について説明します。

組織で個々のユーザーに Direct Inward Dial (DID) 電話番号を構成しないで、各ユーザーの回線 URI を内線番号のみで構成している場合、内部ユーザーは、内線番号のみをダイヤルして通話できます。ただし、ブランチ サイトのユーザーから、内線番号が一致する中央サイトのユーザーへの通話に適用できる正規化ルールを構成する必要があります。

ブランチ サイトのユーザーと中央サイトのユーザーの間で WAN リンクを使用できる場合、ブランチ サイトのユーザーから中央サイトのユーザーへの通話は PSTN 経由でルーティングされないため、マッチング正規化ルールで番号を変換する必要はありません。次に例を示します。

ルール名	説明	番号のパターン	変換	例
5digitExtensions	5 桁の番号を変換しません。	^(\d{5})$	$1	10001 は変換されません。

また、ブランチ サイトと中央サイトの間で WAN リンクを使用できない場合や、ブランチ サイトからの通話を PSTN 経由でルーティングする必要がある場合などのシナリオに対応する必要もあります。WAN の停止時に、ブランチ サイトのユーザーが、中央サイトのユーザーの内線番号のみをダイヤルして中央サイトのユーザーと通話する場合は、中央サイトのユーザーの完全な電話番号を追加する発信変換ルールが必要です。ユーザーの回線 URI に、組織の完全な電話番号とユーザーの一意の内線番号 (ユーザーの一意の完全な電話番号ではなく) が含まれている場合は、組織の完全な電話番号を追加する発信変換ツールが必要です。次に例を示します。

説明	一致パターン	変換	例
5 桁の番号をユーザーの電話番号と内線番号に変換します。	^(\d{5})$	+14255550123;ext=$1	10001 は +14255550123;ext=10001 に変換されます。
5 桁の番号を組織の電話番号とユーザーの内線番号に変換します。	^(\d{5})$	+14255550100;ext=$1	10001 は +14255550100;ext=10001 に変換されます。

このシナリオで、PSTN への再ルーティングを処理するトランク ピアが、内線番号をサポートしていない場合は、発信変換ルールによって内線番号を削除する必要もあります。次に例を示します。

説明	一致パターン	変換	例
内線番号付きの電話番号から内線番号を削除します。	^\+(\d*);ext=(\d*)$	+$1	+14255550123;ext=10001 は +14255550123 に変換されます。

WAN リンクが使用できるかどうかにかかわらず、組織で個々のユーザーに DID 番号を構成しないで、ユーザーの回線 URI に組織の電話番号とユーザーの一意の内線番号を含める場合は、組織の電話番号の回線 URI を、ブランチ サイトのトランク ピアまたは PSTN ゲートウェイから到達可能な番号で構成する必要があります。また、組織の電話番号の回線 URI に独自の一意の内線番号を含めて、その番号に通話をルーティングする必要もあります。

中央サイトとブランチ サイトの間で WAN リンクが使用できない場合に、中央サイトのユーザーからブランチ サイトのユーザーに対して行う通話については、このトピックの後で説明する「ボイス メールの存続性の準備」を参照してください。ダイヤル プランと正規化ルールやその他のサンプル ルールの詳細については、「計画」のドキュメントの「ダイヤル プランと正規化ルール」と、「展開」のドキュメントの「ダイヤル プランと正規化ルールの構成」を参照してください。発信変換ルールの詳細については、「計画」のドキュメントの「変換ルール」と、「展開」のドキュメントの「変換ルールの定義」を参照してください。

ボイス メールの存続性の準備

Exchange ユニファイド メッセージング (UM) は、通常、中央サイトのみにインストールされ、ブランチ サイトにはインストールされません。ブランチ サイトと中央サイトの間で WAN リンクを使用できない場合でも、発信者がボイス メール メッセージを残すことをできるようにする必要があります。したがって、ブランチ サイトのユーザーにボイス メールを提供する Exchange UM 自動応答電話番号を回線 URI に構成するには、特別な検討事項があり、音声ポリシー、ダイヤル プラン、およびボイス メール番号に適用する正規化ルールも必要となります。

存続可能ブランチ アプライアンスと存続可能ブランチ サーバーは、WAN の停止時も、ブランチ ユーザーがボイス メールを継続して使用できるようにします。特に、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーを使用している場合に、WAN が使用できなくなると、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーは、応答のない通話を PSTN 経由で中央サイトの Exchange UM に再ルーティングします。存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーがあれば、ユーザーは WAN が停止しても、ボイス メール メッセージを PSTN 経由で取得できます。最後に、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーは、WAN が停止すると不在着信通知をキューに入れ、WAN が復旧すると、それを Exchange UM サーバーにアップロードします。ボイス メールの再ルーティングを障害許容力のあるものにするには、中央サイトのプールの FQDN の項目とエッジ サーバーの FQDN の項目を存続可能ブランチ サーバーの Hosts ファイルに追加します。

ブランチ サイトのユーザーに対してボイス メールの存続性を構成するには、次のような構成が推奨されます。

• Microsoft Exchange の管理者は、Exchange UM 自動応答 (AA) に対して、メッセージの受け取りのみを有効にするように構成します。この構成により、ユーザーへの転送やオペレーターへの転送など、その他の一般的な機能がすべて無効になり、自動応答 (AA) をメッセージの受け取りのみに制限します。または、Exchange の管理者は、汎用の自動応答 (AA) を使ったり、自動応答 (AA) をカスタマイズしたりして、通話をオペレーターへルーティングすることができます。

• Lync Server の管理者は、自動応答 (AA) の電話番号を、存続可能ブランチ アプライアンスまたはブランチ サーバーのボイス メール再ルーティング設定の [Exchange UM 自動応答] 番号として使用します。

• Lync Server の管理者は、Exchange UM のサブスクライバー アクセス電話番号を、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーのボイス メール再ルーティング設定の [サブスクライバー アクセス] 番号として使用します。

• Microsoft Exchange 管理者は Exchange UM を構成して、WAN の停止時にボイス メールにアクセスする必要のあるすべてのブランチ ユーザーに関連付けられるダイヤル プランが 1 つだけになるようにする必要があります。

• WAN リンクを使用できない場合、ブランチ サイトのユーザーとの通話をユーザーの Exchange UM ボイス メールボックスにルーティングできます。ただし、これは、その通話に適用される音声ポリシーに、内線番号を含まない一意のボイス メール電話番号が指定されている場合に限られます。

ブランチ サイトの復元のハードウェアおよびソフトウェア要件

ハードウェアおよびソフトウェア要件は、復元ソリューションによって異なります。

存続可能ブランチ アプライアンスの要件

必要なハードウェアとソフトウェアは、存続可能ブランチ アプライアンスに組み込まれています。ただし、この他にも、クライアント IP アドレスの取得のために、各ブランチ サイトに DHCP サーバーを展開することをお勧めします。これを行わない場合、DHCP リースの期限が切れたクライアントは、IP 接続ができなくなります。

エンタープライズ DNS サーバーが中央サイトにのみ配置されている場合、ブランチ サイトのユーザーは WAN の停止中はそれらのサーバーにアクセスできないため、DNS SRV を使用する Lync Server の検出は失敗します。WAN の停止時に迅速に再ルーティングされるように、ブランチ サイトで DNS レコードをキャッシュする必要があります。ブランチのルーターが DNS キャッシュをサポートする場合は、DNS キャッシュを有効にします。または、ブランチに DNS サーバーを展開することもできます。その場合は、スタンドアロン サーバーまたは DNS 機能をサポートするバージョンの 存続可能ブランチ アプライアンスを使用することができます。詳細については、お使いの存続可能ブランチ アプライアンス プロバイダーにお問い合わせください。

注:
ドメイン コントローラーをブランチ サイトに置く必要はありません。存続可能ブランチ アプライアンスは、特別な証明書を使用してクライアントを認証します。この証明書は、クライアントのサインイン時の証明書要求に対する応答として、クライアントに送信されます。

Lync Server 2010 のクライアントは、DHCP オプション 120 (SIP レジストラーのオプション) を使用することにより、Lync Server を検出できます。これは、次の 2 つのいずれかの方法で構成できます。

• ブランチ サイトの DHCP サーバーを DHCP 120 のクエリに応答するように構成します。このクエリは、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーのレジストラーの FQDN を返します。

• Lync Server の DHCP を有効にします。有効にすると、Lync Server のレジストラーは、DHCP オプション 120 のクエリに応答します。Lync Server のレジストラーは、DHCP オプション 120 以外の DHCP クエリには応答しません。

また、より大きなブランチ サイトで複数のサブネットがある場合は、DHCP オプション 120 のクエリが DHCP サーバー (構成 1) または Lync Server のレジストラー (構成 2) に転送されるように、DHCP リレー エージェントを有効にする必要があります。

最後に、エンタープライズ VoIP に対してブランチ サイトのユーザーを構成し、ブランチ サイトのユーザーに対して適切な統合コミュニケーションのエンドポイントをプロビジョニングする必要があります。

存続可能ブランチ サーバーの要件

存続可能ブランチ サーバーの要件は、Lync Server の任意のサーバーの役割の要件と同じです。詳細については、「計画」のドキュメントの「インフラストラクチャ要件の決定」を参照してください。

ブランチ サイトへ Lync Server を全面展開する場合の要件

詳細については、「計画」のドキュメントの「インフラストラクチャ要件の決定」を参照してください。