Lync Server 2013 のブランチ サイトの復元要件
トピック最終更新日時: 2014-02-25
このトピックでは、ブランチ サイトの復元およびボイス メールの存続性に対するユーザーの準備と、関連するハードウェアとソフトウェアの要件について説明します。
ブランチ サイトの復元に対するブランチ サイトのユーザーの準備
レジストラー プールを存続可能ブランチ アプライアンス (SBA) または存続可能ブランチ サーバーとして設定することで、ブランチ サイトの回復性をユーザーに準備します。
ブランチ ユーザーのレジストラーへの割り当て
選択したブランチ サイトの回復性ソリューションに関係なく、各ユーザーにプライマリ レジストラーを割り当てる必要があります。 ブランチ サイトユーザーは、そのレジストラーが存続可能ブランチ アプライアンス、存続可能ブランチ サーバー、またはスタンドアロンの Lync Server 2013 Standard サーバーまたはEnterprise Edition サーバーに存在するかどうかに関係なく、ブランチ サイトのレジストラーに常に登録する必要があります。 クライアントがレジストラー プールを検出できるように、ドメイン ネーム システム (DNS) サービス (SRV) リソース レコードが必要です。 存続可能ブランチ アプライアンスが使用できなくなった場合、ブランチ サイト クライアントはバックアップ レジストラーを自動的に検出します。
ブランチ サイトに DNS サーバーがない場合は、次の 2 つの方法で存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーの検出を構成できます。
ブランチ サイトの動的ホスト構成プロトコル (DHCP) サーバーで DHCP オプション 120 を構成し、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーの完全修飾ドメイン名 (FQDN) を指すようにします。
DHCP 120 クエリに応答するように、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーを構成します。
ブランチ ユーザーの音声ルーティング
ブランチ サイトのユーザーには、別のユーザー レベルの Voice over Internet Protocol (VoIP) ポリシーを作成することをお勧めします。 このポリシーには、存続可能ブランチ アプライアンスまたはブランチ サーバー ゲートウェイを使用するプライマリ ルートと、中央サイトの公衆交換電話ネットワーク (PSTN) ゲートウェイでトランクを使用する 1 つ以上のバックアップ ルートを含める必要があります。 プライマリ ルートが使用できない場合は、代わりに 1 つ以上の中央サイト ゲートウェイを使用するバックアップ ルートが使用されます。 この方法では、ユーザーが登録されている場所に関係なく、ブランチ サイトのレジストラーまたは中央サイトのバックアップ レジストラー プールで、ユーザーの VoIP ポリシーが常に有効になります。 これは、フェールオーバー シナリオの重要な考慮事項です。 たとえば、存続可能ブランチ アプライアンスの名前を変更する必要がある場合や、存続可能ブランチ アプライアンスを再構成して中央サイトのバックアップ レジストラー プールに接続する必要がある場合は、ブランチ サイト のユーザーを中央サイトに移動する必要があります。 (存続可能ブランチ アプライアンスの名前変更または再構成の詳細については、「展開」のドキュメントの「 付録 B: Lync Server 2013 での存続可能ブランチ アプライアンスの管理 」を参照してください)。これらのユーザーにユーザー レベルの VoIP ポリシーまたはユーザー レベルのダイヤル プランがない場合、ユーザーが別のサイトに移動すると、ブランチ サイト サイト レベルの VoIP ポリシーとダイヤル プランではなく、中央サイトのサイト レベルの VoIP ポリシーとサイト レベルのダイヤル プランが既定でユーザーに適用されます。 このシナリオでは、バックアップ レジストラー プールで使用されるサイト レベルの VoIP ポリシーとサイト レベルのダイヤル プランをブランチ サイト ユーザーにも適用できない限り、呼び出しは失敗します。 たとえば、日本にあるブランチ サイトのユーザーがレドモンドの中央サイトに移動された場合、正規化ルールが +1425 を 7 桁のすべての呼び出しに付加するダイヤル プランでは、それらのユーザーの呼び出しを適切に変換する可能性は低いです。
大事な
ブランチ オフィスのバックアップ ルートを作成するときは、ブランチ オフィスのユーザー ポリシーに 2 つの PSTN 電話使用法レコードを追加し、各電話使用法レコードに個別のルートを割り当てることをお勧めします。 最初の (プライマリ) ルートは、存続可能ブランチ アプライアンス (SBA) またはブランチ サーバーに関連付けられているゲートウェイに呼び出しを送信します。2 つ目のルート (バックアップ) は、中央サイトのゲートウェイに呼び出しを送信します。 SBA またはブランチ サーバーは通話を振り分けるときに、最初の PSTN 使用法レコードに割り当てられたすべてのルートを試みてから、2 番目の使用法レコードのルートを試みます。
ブランチ サイト ユーザーへの受信呼び出しが、存続可能ブランチ アプライアンス サイトのブランチ ゲートウェイまたは Windows コンポーネントが利用できない場合 (たとえば、存続可能ブランチ アプライアンスまたはブランチ ゲートウェイがメンテナンスのためにダウンした場合) にそれらのユーザーに確実に到達できるように、ゲートウェイにフェールオーバー ルートを作成します (または、Direct Inward Dialing (DID) プロバイダーと連携して、中央のバックアップ レジストラー プールに着信呼び出しをリダイレクトします。サイト。 通話は、そこから WAN リンク経由でブランチ ユーザーにルーティングされます。 ルートによって番号が PSTN ゲートウェイまたは他のトランク ピアの受け付け済み電話番号方式に準拠するように変換されることを確認します。 フェールオーバー ルートの作成の詳細については、「 Lync Server 2013 でのフェールオーバー ルートの構成」を参照してください。 また、ブランチ サイトのゲートウェイに関連付けられたトランクにサービスレベルのダイヤル プランを作成して着信通話を正規化します。 ブランチ サイトに 2 つの存続可能ブランチ アプライアンスがある場合は、それぞれに個別のサービス レベル プランが必要でない限り、両方のサイト レベルのダイヤル プランを作成できます。
注意
プレゼンス、会議、またはフェールオーバーの実行を中央サイトに頼っているすべてのブランチ サイトのユーザーによる中央サイトのリソース消費に対応するには、各ブランチ サイトのユーザーを、中央サイトに登録されたユーザーとしてみなすことをお勧めします。 現時点では、存続可能ブランチ アプライアンスに登録されているユーザーを含め、ブランチ サイト ユーザーの数に制限はありません。
なお、ユーザー レベルのダイヤル プランと音声ポリシーを作成してから、ブランチ サイトのユーザーに割り当てることもお勧めします。 詳細については、「展開」のドキュメントの「Lync Server 2013 でのダイヤル プランの作成」と「ブランチ ユーザー向けの VoIP ルーティング ポリシーの作成」を参照してください。
内線番号のルーティング
ブランチ サイト ユーザーのダイヤル プランと音声ポリシーを準備する場合は、msRTCSIP-line (または Line URI) 属性で使用される文字列と番号形式に一致する正規化ルールと変換ルールを必ず含めて、ブランチ サイト ユーザーと中央サイト ユーザーの間で有効な Lync 2013 通話が正しくルーティングされるようにしてください。特に、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 リンクが利用できない場合のセントラル サイト ユーザーからブランチ サイト ユーザーへの呼び出しの詳細については、このトピックの後半の「ボイス メールの存続可能性の準備」を参照してください。 ダイヤル プランと正規化ルール (その他のサンプル ルールを含む) の詳細については、展開に関するドキュメント の「計画」および「Lync Server 2013 でのダイヤル プランの構成」の「 Lync Server 2013 のダイヤル プラン と正規化ルール」を参照してください。 送信翻訳ルールの詳細については、「展開」の 「計画」ドキュメントの「Lync Server 2013 の 翻訳ルール」と「Lync Server 2013 での翻訳ルールの定義 」を参照してください。
ボイス メールの存続性の準備
Exchange Unified Messaging (UM) は通常、ブランチ サイトではなく、中央サイトにのみインストールされます。 ブランチ サイトと中央サイトの間で WAN リンクを使用できない場合でも、発信者がボイス メール メッセージを残すことをできるようにする必要があります。 その結果、ブランチ サイト ユーザーにボイス メールを提供する Exchange UM 自動応答電話番号の回線 URI を構成するには、音声ポリシー、ダイヤル プラン、そのボイス メール番号に適用される正規化ルールに加えて、特別な考慮事項が必要です。
存続可能ブランチ アプライアンス (SBA) と存続可能ブランチ サーバーは、WAN 停止中にブランチ ユーザーにボイス メールを存続可能にします。 具体的には、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーを使用していて、WAN が使用できなくなった場合、SBA または存続可能ブランチ サーバーは、PSTN 経由で応答のない呼び出しを中央サイトの Exchange UM に再ルーティングします。 SBA または存続可能ブランチ サーバーを使用すると、WAN 停止中に PSTN 経由でボイス メール メッセージを取得することもできます。 最後に、WAN の停止中に、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーは不在着信通知をキューに登録し、WAN の復元時に Exchange UM サーバーにアップロードします。 ボイス メールの再送信が回復性を確保できるように、中央サイト プールの FQDN のエントリと Edge Server FQDN のエントリを、存続可能ブランチ サーバーのホスト ファイルに追加してください。 そうしないと、ブランチ サイトに DNS サーバーがない場合、DNS 解決がタイムアウトになる可能性があります。
ブランチ サイトのユーザーに対してボイス メールの存続性を構成するには、次のような構成が推奨されます。
Microsoft Exchange 管理者は、メッセージのみを受け入れるように Exchange UM 自動応答 (AA) を構成する必要があります。 この構成により、ユーザーへの転送やオペレーターへの転送など、その他の一般的な機能がすべて無効になり、自動応答 (AA) をメッセージの受け取りのみに制限します。 または、Exchange の管理者は、汎用の自動応答 (AA) を使ったり、自動応答 (AA) をカスタマイズしたりして、通話をオペレーターへルーティングすることができます。
Lync Server 管理者は、AA 電話番号を受け取り、その電話番号を、生存可能ブランチ アプライアンスまたはブランチ サーバーのボイス メールの再転送設定の exchange um 自動応答 番号として使用する必要があります。
Lync Server 管理者は、Exchange UM サブスクライバーアクセス電話番号を取得し、その番号を、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーのボイス メールの再送信設定の サブスクライバー アクセス 番号として使用する必要があります。
Lync Server 管理者は、WAN 停止中にボイス メールにアクセスする必要があるすべてのブランチ ユーザーに 1 つのダイヤル プランのみが関連付けられるように、Exchange UM を構成する必要があります。
WAN リンクを使用できない場合、ブランチ サイトのユーザーとの通話をユーザーの Exchange ユニファイド メッセージング (UM) ボイス メールボックスにルーティングできます。ただし、これは、その通話に適用される音声ポリシーに、内線番号を含まない一意のボイス メール電話番号が指定されている場合に限られます。
ブランチ サイトの復元のハードウェアおよびソフトウェア要件
ハードウェアおよびソフトウェア要件は、復元ソリューションによって異なります。
存続可能ブランチ アプライアンスの要件
必要なハードウェアとソフトウェアは、存続可能ブランチ アプライアンスに組み込まれています。 ただし、各ブランチ サイトで DHCP サーバーを展開してクライアント IP アドレスを取得することもお勧めします。それ以外の場合、DHCP リースの有効期限が切れると、クライアントは IP 接続を持たなくなります。
エンタープライズ DNS サーバーが中央サイトにのみ配置されている場合、ブランチ サイトユーザーは WAN 停止中に接続できないため、DNS SRV (サービス (SRV) リソース レコードを使用する Lync Server 検出は失敗します。 WAN の停止時に迅速に再ルーティングされるように、ブランチ サイトで DNS レコードをキャッシュする必要があります。 ブランチのルーターが DNS キャッシュをサポートする場合は、DNS キャッシュを有効にします。 または、ブランチに DNS サーバーを展開することもできます。 これは、スタンドアロン サーバーでも、DNS 機能をサポートする存続可能ブランチ アプライアンスのバージョンでもかまいません。 詳細については、存続可能ブランチ アプライアンス プロバイダーにお問い合わせください。
注意
ブランチ サイトにドメイン コントローラーを用意する必要はありません。 存続可能ブランチ アプライアンスは、サインイン時にクライアントの証明書要求に応答してクライアントを送信する特別な証明書を使用してクライアントを認証します。
Lync クライアントは、DHCP オプション 120 (SIP レジストラー オプション) を使用して Lync Server を検出できます。 これは、次の 2 つのいずれかの方法で構成できます。
DHCP 120 クエリに応答するようにブランチ サイトの DHCP サーバーを構成します。これは、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバー上のレジストラーの FQDN を返します。
Lync Server DHCP を有効にします。 これをオンにすると、Lync Server レジストラーは DHCP オプション 120 クエリに応答します。 レジストラーは、DHCP オプション 120 以外の DHCP クエリには応答しません。
また、より大きなブランチ サイトで複数のサブネットがある場合は、DHCP オプション 120 のクエリが DHCP サーバー (構成 1) またはレジストラー (構成 2) に転送されるように、DHCP リレー エージェントを有効にする必要があります。
最後に、ブランチ サイトユーザーをエンタープライズ VoIP用に構成し、適切なユニファイド コミュニケーション エンドポイントを使用してプロビジョニングする必要があります。
存続可能ブランチ サーバーの要件
存続可能ブランチ サーバーの要件は、フロントエンド サーバーの要件と同じです。 詳細については、「計画」のドキュメント の「Lync Server 2013 のサーバー ハードウェア プラットフォーム 」を参照してください。
Lync Server Branch-Site 展開Full-Scale要件
詳細については、計画のドキュメント の「Lync Server 2013 のインフラストラクチャ要件の決定 」を参照してください。