Plan for Enterprise Voice resiliency in Skype for Business Server
中央サイトとブランチ サイトの両方で、Skype for Business Server エンタープライズ VoIPで音声回復性をサポートする方法について説明します。 ブランチ サイトのオプションには、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーの展開が含まれます。
音声回復性とは、ワイド エリア ネットワーク (WAN) の障害やその他の原因によって、Skype for Business Serverをホストする中央サイトが使用できなくなった場合に、ユーザーが通話を継続して受信する機能を指します。 中央サイトで障害が発生した場合、エンタープライズ VoIP サービスでは、バックアップ サイトへの円滑なフェールオーバーにより中断せずにサービスを提供し続ける必要があります。 WAN 障害の場合は、ブランチ サイトの通話をローカルの PSTN ゲートウェイにリダイレクトする必要があります。 ここでは、中央サイトまたは WAN で障害が発生した場合の音声の復元の計画について説明します。
中央サイトの復元
世界中に多数のサイトを持つ企業がますます増えています。 緊急サービスの維持、ヘルプ デスクへのアクセス、および中央サイトのサービスが不足している場合に重要なビジネス タスクを実行する機能は、エンタープライズ VoIP回復性ソリューションに不可欠です。 中央サイトを利用できなくなった場合、以下の条件を満たすことが求められます。
ボイス フェールオーバーを備える必要があります。
通常、中央サイトのフロント エンド プールに登録するユーザーは、別のフロント エンド プールに登録できる必要があります。 これを行うには、複数の DNS SRV レコードを作成します。各 DNS SRV レコードは、各中央サイトのディレクター プールまたはフロント エンド プールに解決されます。 SRV レコードの優先順位と重みを調整して、その中央サイトでサービスを提供するユーザーが、他の SRV レコードよりも先に対応する Director プールとフロントエンド プールを取得できるようにします。
他のサイトに存在するユーザーとの通話を、PSTN に再ルーティングする必要があります。
このトピックでは、中央サイトの音声復元をセキュリティ保護するための推奨ソリューションについて説明します。
アーキテクチャおよびトポロジ
中央サイトで音声回復性を計画するには、音声フェールオーバーを有効にする際にSkype for Business Serverレジストラーが果たす中心的な役割の基本的な理解が必要です。 Skype for Business Server レジストラーは、クライアントの登録と認証を有効にし、ルーティング サービスを提供するサービスです。 すべての Standard Edition サーバー、フロントエンド サーバー、ディレクター、または存続可能ブランチ アプライアンスで実行されます。 レジストラー プールは、フロントエンド プールで実行され、同じサイトに存在するレジストラー サービスで構成されます。 Skype for Business クライアントは、次の検出メカニズムを使用してフロントエンド プールを検出します。
DNS SRV レコード
自動検出 Web サービス
DHCP オプション 120
Skype for Business クライアントがフロントエンド プールに接続すると、ロード バランサーによってプール内のいずれかのフロント エンド サーバーに転送されます。 そのフロントエンド サーバーは、クライアントをプール内の優先レジストラーにリダイレクトします。
エンタープライズ VoIPに対して有効になっている各ユーザーは、特定のレジストラー プールに割り当てられます。これにより、そのユーザーのプライマリ レジストラー プールになります。 サイトでは、数百人または数千人のユーザーが 1 つのプライマリ レジストラー プールを共有するのが一般的です。 プレゼンス、会議、またはフェールオーバーのために中央サイトに依存するブランチ サイトのユーザーによる中央サイトのリソース消費に対応するには、各ブランチ サイトのユーザーを、中央サイトに登録されたユーザーと同様に扱うことをお勧めします。 現時点では、存続可能ブランチ アプライアンスに登録されているユーザーを含め、ブランチ サイト ユーザーの数に制限はありません。
中央サイトの障害時に音声を確実に復元するには、プライマリ レジストラー プールで、別のサイトに配置された単一のバックアップ レジストラー プールを指定しておく必要があります。 バックアップは、トポロジ ビルダーの回復性設定を使用して構成できます。 2 つのサイト間の WAN リンクが復元できている場合、プライマリ レジストラー プールを使用できなくなったユーザーは自動的にバックアップ レジストラー プールにダイレクトされます。
以下のステップでは、クライアントの検出と登録のプロセスについて説明します。
クライアントは、DNS SRV レコードを介してSkype for Business Serverを検出します。 Skype for Business Serverでは、DNS SRV レコードを構成して、DNS SRV クエリに複数の FQDN を返すことができます。 たとえば、企業 Contoso に 3 つの中央サイト (北米、欧州、およびアジア太平洋) があり、各中央サイトにディレクター プールがある場合、DNS SRV レコードで 3 つの各場所のディレクター プールの FQDN を指すことができます。 いずれかの場所のディレクター プールが使用可能である限り、クライアントは最初のホップ Skype for Business Serverに接続できます。
注意
ディレクター プールの使用は省略可能です。 代わりにフロント エンド プールを使用できます。
ディレクター プールは、ユーザーのプライマリ レジストラー プールとバックアップ レジストラー プールについてSkype for Business クライアントに通知します。
Skype for Business クライアントは、最初にユーザーのプライマリ レジストラー プールへの接続を試みます。 プライマリ レジストラー プールが使用可能な場合、レジストラーは登録を受け入れます。 プライマリ レジストラー プールが使用できない場合、Skype for Business クライアントはバックアップ レジストラー プールへの接続を試みます。 バックアップ レジストラー プールが使用可能であり、ユーザーのプライマリ レジストラー プールが使用できないと判断した場合 (指定したフェールオーバー間隔のハートビート不足を検出することによって)、バックアップ レジストラー プールはユーザーの登録を受け入れます。 プライマリ レジストラーが再び使用可能になったことをバックアップ レジストラーが検出すると、バックアップ レジストラー プールはフェールオーバー クライアントをプライマリ プールにリダイレクトします。
要件と推奨事項
中央サイトで音声復元を実装するための以下に示す要件と推奨事項は、ほとんどの組織に適しています。
プライマリおよびバックアップ レジストラー プールのあるサイトは、復元 WAN リンクで接続する必要があります。
各中央サイトには、1 つ以上のレジストラーで構成されるレジストラー プールが存在する必要があります。
各レジストラー プールは、DNS 負荷分散かハードウェア負荷分散またはその両方を使用して負荷分散する必要があります。 負荷分散構成の計画の詳細については、「Skype for Businessの負荷分散要件」を参照してください。
各ユーザーは、Skype for Business Server Management Shell set-CsUser コマンドレットまたはSkype for Business Server コントロール パネルを使用して、プライマリ レジストラー プールに割り当てる必要があります。
プライマリ レジストラー プールは、別の中央サイトに配置されたバックアップ レジストラー プールを 1 つ持つ必要があります。
プライマリ レジストラー プールは、バックアップ レジストラー プールにフェールオーバーするように構成する必要があります。 既定では、プライマリ レジストラーは 300 秒の間隔が経過した後でバックアップ レジストラー プールにフェールオーバーするように設定されています。 この間隔は、Skype for Business Server トポロジ ビルダーを使用して変更できます。
フェールオーバー ルートを構成します。 ルートを構成する際、プライマリ ルートで指定されたゲートウェイとは別のサイトにあるゲートウェイを指定します。
中央サイトにプライマリ管理サーバーが含まれており、サイトが長期間停止する可能性がある場合は、バックアップ サイトで管理ツールを再インストールする必要があります。それ以外の場合は、管理設定を変更できません。
依存関係
Skype for Business Serverは、音声の回復性を確保するために、次のインフラストラクチャとソフトウェア コンポーネントに依存します。
| コンポーネント |
機能 |
|---|---|
| DNS |
SRV レコードおよび A レコードを解決して、サーバー間の接続およびサーバーとクライアント間の接続を確立 |
| Exchange および Exchange Web サービス (EWS) |
コンタクト ストレージ、予定表データ |
| Exchange ユニファイド メッセージングおよび Exchange Web サービス |
通話ログ、ボイス メール一覧、ボイス メール |
| DHCP オプション 120 |
DNS SRV を使用できない場合、クライアントは DHCP オプション 120 を使用してレジストラーの検出を試みます。 これを機能させるには、DHCP サーバーを構成するか、DHCP を有効Skype for Business Server必要があります。 |
存続可能な音声機能
前述の要件と推奨事項が実装されている場合は、以下の音声機能がバックアップ レジストラー プールによって提供されます。
PSTN 通話の発信
テレフォニー サービス プロバイダーがバックアップ サイトへのフェールオーバー機能をサポートしている場合は、PSTN 通話の着信
同じサイトおよび 2 つの異なるサイト間でのユーザー同士のエンタープライズ通話
通話の保留、取得、転送などの基本的な通話処理
2 者間のインスタント メッセージングおよび同じサイトでのユーザー間のオーディオとビデオの共有
着信の転送、エンドポイントの同時呼び出し、通話委任、およびチーム通話サービス。ただし、通話委任の両者または全チーム メンバーが同じサイトで構成されている場合のみ。
既存の電話およびクライアントは動作し続ける
通話詳細記録 (CDR)
認証と承認
プライマリ中央サイトがサービス停止になったときに以下の音声機能が動作するかどうかは、その構成方法によって決まります。
ボイス メールの預かりと取得
プライマリ中央サイトがサービス停止になっているときに Exchange UM を使用可能にするには、以下のいずれかを実行する必要があります。
中央サイトの Exchange UM サーバーが別のサイトのバックアップ Exchange UM サーバーをポイントするように、DNS SRV レコードを変更します。
各ユーザーの Exchange UM ダイヤル プランを構成して、中央サイトとバックアップ サイトの両方に Exchange UM サーバーを含めますが、バックアップ Exchange UM サーバーは無効として指定します。 プライマリ サイトが使用できなくなった場合、Exchange 管理者はバックアップ サイトの Exchange UM サーバーを有効としてマークする必要があります。
上記のどちらのソリューションも使用できない場合、中央サイトが使用できなくなった場合、Exchange UM は使用できなくなります。
すべての種類の会議
バックアップ サイトにフェールオーバーしたユーザーは、プールを使用できる開催者によって作成またはホストされる会議に出席できますが、使用不可になった自身のプライマリ プールで会議を作成またはホストすることはできません。 同様に、他のユーザーは、影響を受けるユーザーのプライマリ プールでホストされている会議に参加できません。
以下の音声機能は、プライマリ中央サイトが停止しているときには動作しません。
会議自動アテンダント
プレゼンスおよび DND ベースのルーティング
着信の転送設定の更新
応答グループ サービスとコール パーク
新しい電話とクライアントのプロビジョニング
アドレス帳 Web 検索
ブランチ サイトの復元
ブランチ サイトの回復性 (高可用性エンタープライズ VoIPサービス) を提供する場合は、次の 3 つのオプションを使用できます。
存続可能ブランチ アプライアンス
存続可能ブランチ サーバー
ブランチ サイトでの完全なSkype for Business Server展開
このガイドは、組織に最適な復元ソリューションを評価し、その復元ソリューションに基づいて、どの PSTN 接続ソリューションを使用すべきかを判断するのに役立ちます。 また、前提条件や計画時のその他の考慮事項も記載されているため、選択したソリューションの展開を準備するときにも役立ちします。
ブランチ サイトの復元機能
ブランチ サイトの回復性を提供する場合、中央サイトへのブランチ サイトの WAN 接続が失敗した場合、または中央サイトに到達できない場合は、次の音声機能を引き続き使用できます。
着信と発信の公衆交換電話網 (PSTN) 通話
同じサイトおよび 2 つの異なるサイト間でのユーザー同士のエンタープライズ通話
通話の保留、取得、転送などの基本的な通話処理
2 者間のインスタント メッセージング
通話転送、エンドポイントの同時呼び出し、呼び出し委任、およびチーム呼び出しサービスが同時に呼び出されますが、委任者と代理人 (マネージャーとマネージャーの管理者など) またはすべてのチーム メンバーが同じサイトで構成されている場合のみ
詳細な通話の記録 (CDR)
自動応答アテンダントを使用した PSTN ダイヤルイン会議
ボイス メール機能 (ボイス メール ルーティング設定を構成している場合)
ユーザーの認証と権限の付与
次の機能は、回復性ソリューションがブランチ サイトでの本格的なSkype for Business Server展開である場合にのみ使用できます。
IM、Web、音声ビデオ会議
プレゼンスおよび応答不可 (DND) ベースのルーティング (通話は DND がアクティブになっている内線番号で呼び出し音が鳴らない)
着信の転送設定の更新
応答グループ アプリケーションとコール パーク アプリケーション
新しい電話とクライアントをプロビジョニングしますが、Active Directory Domain Servicesがブランチ サイトに存在する場合に限ります。
拡張 9-1-1 (E9-1-1)
E9-1-1 が展開され、WAN リンクがダウンしているために中央サイトの SIP トランクを使用できない場合、存続可能ブランチ アプライアンスは E9-1-1 呼び出しをローカル ブランチ ゲートウェイにルーティングします。 この機能を有効にするには、ブランチ サイト ユーザーの音声ポリシーで、WAN エラーが発生した場合にローカル ゲートウェイへの呼び出しをルーティングする必要があります。
注意
SBA (存続可能ブランチ オフィス) は、XMPP ではサポートされません。 SBA 構成に所属するユーザーは、VM を送信したり、XMPP 連絡先を使用してプレゼンスを表示したりすることはできません。
ブランチ サイトの復元ソリューション
ブランチ サイトの復元を提供することには明白な利点があります。 具体的には、中央サイトへの接続が失われると、ブランチ サイトのユーザーは引き続きエンタープライズ VoIPサービスとボイス メールを使用できます (ボイス メールのルーティング設定を構成した場合)。 ただし、ユーザー数が 25 に満たないサイトでは、復元ソリューションによる十分な投資利益が得られない場合があります。
ブランチ サイトの復元を実現するには、3 つの方法があります。 次の表は、組織に最適な方法を判断するのに役立ちます。
| 場合... | を使用することをお勧めします。 |
|---|---|
| ブランチ サイトに 25 から 1,000 ユーザーが所属しており、投資収益率が全面的な展開をサポートしない、またはローカル管理者がいない場合 |
存続可能ブランチ アプライアンス 存続可能ブランチ アプライアンスは、Windows Server 2008 R2 で実行されているSkype for Business Server レジストラーと仲介サーバーを備えた業界標準のブレード サーバーです。 存続可能ブランチ アプライアンスには、公衆交換電話網 (PSTN) ゲートウェイも含まれています。 認定されたサード パーティ製デバイス (存続可能ブランチ アプライアンス (SBA) 認定プログラムの Microsoft パートナーによって開発された) は、WAN 障害が発生した場合に PSTN 接続を継続的に提供しますが、これらの機能は中央サイトのフロント エンド サーバーに依存するため、回復性のあるプレゼンスと会議は提供されません。 存続可能ブランチ アプライアンスの詳細については、このトピックの「存続可能ブランチ アプライアンスの詳細」を参照してください。 メモ：存続可能ブランチ アプライアンスで SIP トランクも使用する場合は、存続可能ブランチ アプライアンス ベンダーに問い合わせて、organizationに最適なサービス プロバイダーを確認してください。 |
| ブランチ サイトで 1000 から 2000 人のユーザーをホストし、回復性のある WAN 接続がなく、Skype for Business Server管理者をトレーニングしました |
存続可能ブランチ サーバーまたは 2 つの存続可能ブランチ アプライアンス。 存続可能ブランチ サーバーは、指定されたハードウェア要件を満たす Windows Server であり、Skype for Business Serverレジストラーと仲介サーバー ソフトウェアがインストールされています。 これを、PSTN ゲートウェイ、または電話サービス プロバイダーへの SIP トランクに接続する必要があります。 存続可能ブランチ サーバーの詳細については、このトピックの「存続可能ブランチ サーバーの詳細」を参照してください。 |
| 最大 5,000 人のユーザーの音声機能に加えてプレゼンス機能と会議機能が必要で、管理者Skype for Business Serverトレーニング済みの場合 |
ブランチ サイトとしてではなく、Standard Edition サーバーが含まれるセントラル サイトとして展開します。 フル スケールのSkype for Business Server展開では、WAN 障害が発生した場合に PSTN 接続を継続的に行い、回復性のあるプレゼンスと会議を実現します。 |
復元のトポロジ
次の図は、ブランチ サイトの復元性を確保するうえで推奨されるトポロジを示しています。
ブランチ サイトの復元オプション
存続可能ブランチ アプライアンスの詳細
Skype for Business Server存続可能ブランチ アプライアンスには、次のコンポーネントが含まれています。
ユーザー認証、登録、通話ルーティングのためのレジストラー
レジストラーと PSTN ゲートウェイ間の信号を処理する仲介サーバー
WAN の停止時に代替トランスポートとして PSTN に通話をルーティングする PSTN ゲートウェイ
ローカル ユーザーのデータ記憶域用 SQL Server Express
存続可能ブランチ アプライアンスには、PSTN トランク、アナログ ポート、イーサネット アダプターも含まれています。
中央サイトへのブランチ サイトの WAN 接続が使用できなくなった場合、内部ブランチ ユーザーは引き続き存続可能ブランチ アプライアンス レジストラーに登録され、PSTN への存続可能ブランチ アプライアンス接続を使用して中断されない音声サービスを取得します。 自宅またはその他のリモートの場所から接続しているブランチ サイトのユーザーは、ブランチ サイトへの WAN リンクが使用できない場合にセントラル サイトのレジストラー サーバーに登録されることができます。 これらのユーザーはすべての統合コミュニケーション機能を使用できますが、唯一の例外は、ブランチ サイトへの着信通話がボイス メールに転送されることです。 WAN 接続が使用可能になると、ブランチ サイトのユーザーはすべての機能を再び使用できるようになります。 存続可能ブランチ アプライアンスへのフェールオーバーもサービスの復元にも、IT 管理者が存在する必要はありません。
Skype for Business Serverは、ブランチ サイトで最大 2 つの存続可能ブランチ アプライアンスをサポートします。
存続可能ブランチ アプライアンスの展開の概要
存続可能ブランチ アプライアンスは、Microsoft と提携してオリジナルの機器メーカーによって製造され、付加価値のある小売業者に代わって展開されます。 この展開は、Skype for Business Serverが中央サイトに展開され、ブランチ サイトへの WAN 接続が確立され、ブランチ サイト ユーザーがエンタープライズ VoIPに対して有効になった後にのみ行う必要があります。
これらのフェーズの詳細については、「展開」のドキュメントの「Deploying a Survivable Branch Appliance or Server」を参照してください。
| 段階 | 手順 | ユーザー権限 |
|---|---|---|
| 存続可能ブランチ アプライアンスのActive Directory Domain Servicesを設定する |
セントラル サイトにおいて: ブランチ サイトで存続可能ブランチ アプライアンスをインストールしてアクティブ化する技術者のドメイン ユーザー アカウント (またはエンタープライズ ID) を作成します。 Active Directory Domain Servicesで、存続可能ブランチ アプライアンスのコンピューター アカウント (該当する完全修飾ドメイン名 (FQDN) を使用) を作成します。 トポロジ ビルダーで、存続可能ブランチ アプライアンスを作成して発行します。 |
技術者のユーザー アカウントは、RTCUniversalSBATechnicians のメンバーである必要があります。 存続可能ブランチ アプライアンスは RTCSBAUniversalServices グループに属している必要があります。これは、トポロジ ビルダーを使用すると自動的に発生します。 |
| 存続可能ブランチ アプライアンスをインストールしてアクティブ化します。 |
ブランチ サイトにおいて: 存続可能ブランチ アプライアンスをイーサネット ポートと PSTN ポートに接続します。 存続可能ブランチ アプライアンスを起動します。 中央サイトの存続可能ブランチ アプライアンス用に作成されたドメイン ユーザー アカウントを使用して、存続可能ブランチ アプライアンスをドメインに参加させます。 コンピューター アカウントで作成された FQDN に一致する FQDN と IP アドレスを設定します。 OEM ユーザー インターフェイスを使用して、存続可能ブランチ アプライアンスを構成します。 PSTN 接続をテストします。 |
技術者のユーザー アカウントは、RTCUniversalSBATechnicians のメンバーである必要があります。 |
存続可能ブランチ サーバーの詳細
トポロジ ビルダーでブランチ サイトを作成し、そのサイトに存続可能なブランチ サーバーを追加し、役割をインストールするコンピューターでSkype for Business Server展開ウィザードを実行します。
ブランチ サイトの復元要件
このトピックでは、ブランチ サイトの復元およびボイス メールの存続性に対するユーザーの準備と、関連するハードウェアとソフトウェアの要件について説明します。
ブランチ サイトの復元に対するブランチ サイトのユーザーの準備
レジストラー プールを存続可能ブランチ アプライアンス (SBA) または存続可能ブランチ サーバーとして設定することで、ブランチ サイトの回復性をユーザーに準備します。
ブランチ ユーザーのレジストラーへの割り当て
選択したブランチ サイトの回復性ソリューションに関係なく、各ユーザーにプライマリ レジストラーを割り当てる必要があります。 ブランチ サイトのユーザーは、レジストラーが存続可能ブランチ アプライアンス、存続可能ブランチ サーバー、スタンドアロン Skype for Business Server Standard サーバーまたはEnterprise Edition サーバーのいずれに存在するかに関係なく、常にブランチ サイトのレジストラーに登録する必要があります。 クライアントがレジストラー プールを検出できるように、ドメイン ネーム システム (DNS) サービス (SRV) リソース レコードが必要です。 存続可能ブランチ アプライアンスが使用できなくなった場合、これはブランチ サイト クライアントがバックアップ レジストラーを自動的に検出する方法です。
ブランチ サイトに DNS サーバーがない場合は、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーの検出を構成する 2 つの代替方法があります。
ブランチ サイトの動的ホスト構成プロトコル (DHCP) サーバーで DHCP オプション 120 を構成し、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーの完全修飾ドメイン名 (FQDN) をポイントします。
DHCP 120 クエリに応答するように、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーを構成します。
ブランチ ユーザーの音声ルーティング
ブランチ サイト内のユーザーに対して、別のユーザー レベルの Voice over Internet Protocol (VoIP) ポリシーを作成することをお勧めします。 このポリシーには、存続可能ブランチ アプライアンスまたはブランチ サーバー ゲートウェイを使用するプライマリ ルートと、中央サイトで公衆交換電話網 (PSTN) ゲートウェイを備えたトランクを使用する 1 つ以上のバックアップ ルートが含まれている必要があります。 プライマリ ルートが使用できない場合は、1 つ以上の中央サイト ゲートウェイを使用するバックアップ ルートが代わりに使用されます。 これにより、ブランチ サイトレジストラーまたは中央サイトのバックアップ レジストラー プールにユーザーが登録されている場所に関係なく、ユーザーの VoIP ポリシーは常に有効になります。 これは、フェールオーバー シナリオの重要な考慮事項です。 たとえば、存続可能ブランチ アプライアンスの名前を変更する必要がある場合、または存続可能ブランチ アプライアンスを再構成して中央サイトのバックアップ レジストラー プールに接続する必要がある場合は、その間、ブランチ サイト のユーザーを中央サイトに移動する必要があります。 (存続可能ブランチ アプライアンスの名前変更または再構成の詳細については、展開ドキュメントの 「付録 B: 存続可能ブランチ アプライアンスの管理 」を参照してください)。これらのユーザーにユーザー レベルの VoIP ポリシーまたはユーザー レベルのダイヤル プランがない場合、ユーザーが別のサイトに移動されると、中央サイトのサイト レベルの VoIP ポリシーとサイト レベルのダイヤル プランが、ブランチ サイト レベルの VoIP ポリシーとダイヤル プランではなく、既定でユーザーに適用されます。 このシナリオでは、バックアップ レジストラー プールで使用されるサイト レベルの VoIP ポリシーとサイト レベルのダイヤル プランをブランチ サイト ユーザーにも適用できない限り、その呼び出しは失敗します。 たとえば、日本にあるブランチ サイトのユーザーが Redmond の中央サイトに移動された場合、正規化ルールを使用したダイヤル プランでは、+1425 をすべての 7 桁の呼び出しの先頭に付けて、それらのユーザーの呼び出しを適切に翻訳する可能性は低いです。
重要
ブランチ オフィスのバックアップ ルートを作成するときは、ブランチ オフィスのユーザー ポリシーに 2 つの PSTN 電話使用法レコードを追加し、各電話使用法レコードに個別のルートを割り当てることをお勧めします。 最初の (プライマリ) ルートは、存続可能ブランチ アプライアンス (SBA) またはブランチ サーバーに関連付けられているゲートウェイへの呼び出しを転送します。2 つ目のバックアップルートは、中央サイトのゲートウェイへの呼び出しを転送します。 SBA またはブランチ サーバーは通話を振り分けるときに、最初の PSTN 使用法レコードに割り当てられたすべてのルートを試みてから、2 番目の使用法レコードのルートを試みます。
ブランチ ゲートウェイまたは存続可能ブランチ アプライアンス サイトの Windows コンポーネントが使用できない場合 (たとえば、存続可能ブランチ アプライアンスまたはブランチ ゲートウェイがメンテナンスのためにダウンした場合など) に、ブランチ サイト ユーザーへの受信呼び出しがそれらのユーザーに確実に到達できるようにするには、ゲートウェイにフェールオーバー ルートを作成します (または、Direct Inward Dialing (DID) プロバイダーと連携して、中央のバックアップ レジストラー プールに着信呼び出しをリダイレクトしますサイト。 通話は、そこから WAN リンク経由でブランチ ユーザーにルーティングされます。 ルートが PSTN ゲートウェイまたは他のトランク ピアの受け入れられた電話番号形式に準拠するように番号を変換することを確認します。 フェールオーバー ルートの作成の詳細については、「Configuring a Failover Route」を参照してください。 また、ブランチ サイトのゲートウェイに関連付けられたトランクにサービスレベルのダイヤル プランを作成して着信通話を正規化します。 ブランチ サイトに存続可能なブランチ アプライアンスが 2 つある場合は、それぞれに個別のサービス レベル プランが必要な場合を除き、両方のサイト レベルのダイヤル プランを作成できます。
注意
プレゼンス、会議、またはフェールオーバーの実行を中央サイトに頼っているすべてのブランチ サイトのユーザーによる中央サイトのリソース消費に対応するには、各ブランチ サイトのユーザーを、中央サイトに登録されたユーザーとしてみなすことをお勧めします。 現時点では、存続可能ブランチ アプライアンスに登録されているユーザーを含め、ブランチ サイト ユーザーの数に制限はありません。
なお、ユーザー レベルのダイヤル プランと音声ポリシーを作成してから、ブランチ サイトのユーザーに割り当てることもお勧めします。 詳細については、「展開」ドキュメントの「Skype for Business Serverでのダイヤル プランの作成または変更」および「ブランチ ユーザー向けの VoIP ルーティング ポリシーの作成」を参照してください。
内線番号のルーティング
ブランチ サイト ユーザー向けのダイヤル プランと音声ポリシーを準備する場合は、msRTCSIP-line (または Line URI) 属性で使用される文字列と番号形式に一致する正規化ルールと翻訳ルールを必ず含めて、ブランチ サイト ユーザーと中央サイト ユーザー間で有効なSkype for Business呼び出しが正しくルーティングされるようにします。特に、WAN リンクが利用できないために PSTN 経由で呼び出しを再ルーティングする必要がある場合は特にです。 さらに、電話番号だけでなく、内線番号を含むダイヤル番号には特別な考慮事項があります。
内線番号を単独で含むか、E.164 準拠の電話番号に追加して含むかにかかわらず、内線番号を含む回線 URI を照合する正規化ルールと変換ルールには要件が追加されます。 このセクションでは、いくつかのシナリオ例を挙げて、内線番号を含む回線 URI の通話をルーティングする方法について説明します。
組織で個々のユーザーに Direct Inward Dial (DID) 電話番号を構成しないで、各ユーザーの回線 URI を内線番号のみで構成している場合、内部ユーザーは、内線番号のみをダイヤルして通話できます。 ただし、ブランチ サイトのユーザーから、内線番号が一致する中央サイトのユーザーへの通話に適用できる正規化ルールを構成する必要があります。
ブランチ サイトのユーザーと中央サイトのユーザーの間で WAN リンクを使用できる場合、ブランチ サイトのユーザーから中央サイトのユーザーへの通話は PSTN 経由でルーティングされないため、マッチング正規化ルールで番号を変換する必要はありません。 次に例を示します。
| ルール名 | 説明 | 番号パターン | 変換 | 例 |
|---|---|---|---|---|
| 5digitExtensions |
5 桁の番号を変換しません。 |
^(\d{5})$ |
$1 |
10001 は変換されません。 |
また、ブランチ サイトと中央サイトの間で WAN リンクを使用できない場合や、ブランチ サイトからの通話を PSTN 経由でルーティングする必要がある場合などのシナリオの内線番号に対応する必要もあります。 WAN の停止中に、ブランチ サイト ユーザーが中央サイト ユーザーの拡張機能をダイヤルするだけで中央サイト ユーザーを呼び出す場合は、中央サイト ユーザーの完全な電話番号を追加する送信翻訳ルールが必要です。 ユーザーの Line URI に、ユーザーに固有の完全な電話番号ではなく、organizationの完全な電話番号とユーザーの一意の内線番号が含まれている場合は、代わりにorganizationの完全な電話番号を追加する送信翻訳ルールが必要です。 次に例を示します。
| 説明 | 一致パターン | 変換 | 例 |
|---|---|---|---|
| 5 桁の番号をユーザーの電話番号と拡張機能に変換します |
^(\d{5})$ |
+14255550123;ext=$1 |
10001 は +14255550123;ext=10001 に変換されます。 |
| 5 桁の番号をorganizationの電話番号とユーザーの拡張機能に変換します |
^(\d{5})$ |
+14255550100;ext=$1 |
10001 は +14255550100;ext=10001 に変換されます。 |
このシナリオで、PSTN への再ルーティングを処理するトランク ピアが、内線番号をサポートしていない場合は、発信変換ルールによって内線番号を削除する必要もあります。 次に例を示します。
| 説明 | 一致パターン | 変換 | 例 |
|---|---|---|---|
| 内線番号付きの電話番号から内線番号を削除します。 |
^+(\d*);ext=(\d*)$ |
+$1 |
+14255550123;ext=10001 は +14255550123 に変換されます。 |
WAN リンクを使用できるかどうかに関係なく、organizationに個々のユーザー用に DID 番号が構成されておらず、ユーザーの回線 URI にorganizationの電話番号とユーザーの一意の内線番号が含まれている場合は、organizationを構成する必要があります。の電話番号 ブランチ サイトのトランク ピアまたは PSTN ゲートウェイによって到達可能な番号を持つ行 URI。 また、呼び出しをその番号にルーティングするための独自の一意の拡張機能を含むように、organizationの電話番号 Line URI を構成する必要もあります。
ボイス メールの存続性の準備
Exchange ユニファイド メッセージング (UM) は通常、ブランチ サイトではなく中央サイトにのみインストールされます。 ブランチ サイトと中央サイトの間で WAN リンクを使用できない場合でも、発信者がボイス メール メッセージを残すことをできるようにする必要があります。 その結果、ブランチ サイト ユーザーにボイス メールを提供する Exchange UM 自動応答電話番号の回線 URI を構成するには、そのボイス メール番号に適用される音声ポリシー、ダイヤル プラン、正規化ルールに加えて、特別な考慮事項が必要です。
存続可能ブランチ アプライアンス (SBA) と存続可能ブランチ サーバーは、WAN の停止中にブランチ ユーザーにボイス メールの存続性を提供します。 具体的には、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーを使用していて、WAN が使用できなくなった場合、SBA または存続可能ブランチ サーバーは PSTN 経由で未応答の呼び出しを中央サイトの Exchange UM に再ルーティングします。 SBA または存続可能ブランチ サーバーを使用すると、ユーザーは WAN の停止中に PSTN を介してボイス メール メッセージを取得することもできます。 最後に、WAN の停止中に、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーは不在着信通知をキューに入れ、WAN の復元時に Exchange UM サーバーにアップロードします。 ボイス メールの再ルーティングの回復性を確保するには、中央サイト プールの FQDN のエントリとエッジ サーバー FQDN のエントリを、存続可能ブランチ サーバーの hosts ファイルに追加してください。 そうしないと、ブランチ サイトに DNS サーバーがない場合、DNS 解決がタイムアウトする可能性があります。
ブランチ サイトのユーザーに対してボイス メールの存続性を構成するには、次のような構成が推奨されます。
Microsoft Exchange 管理者は、メッセージのみを受け入れるように Exchange UM 自動応答 (AA) を構成する必要があります。 この構成により、ユーザーへの転送やオペレーターへの転送など、その他の一般的な機能がすべて無効になり、自動応答 (AA) をメッセージの受け取りのみに制限します。 または、Exchange の管理者は、汎用の自動応答 (AA) を使ったり、自動応答 (AA) をカスタマイズしたりして、通話をオペレーターへルーティングすることができます。
Skype for Business Server管理者は、AA 電話番号を取得し、その電話番号を、存続可能ブランチ アプライアンスまたはブランチ サーバーのボイス メールの再ルーティング設定の exchange um 自動応答番号として使用する必要があります。
Skype for Business Server管理者は、Exchange UM サブスクライバー アクセス電話番号を取得し、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバーのボイス メールのルーティング設定でその番号をサブスクライバー アクセス番号として使用する必要があります。
Skype for Business Server管理者は、WAN の停止中にボイス メールにアクセスする必要があるすべてのブランチ ユーザーに 1 つのダイヤル プランのみが関連付けられているように Exchange UM を構成する必要があります。
WAN リンクが使用できない場合、ブランチ サイト ユーザーへの呼び出しは、ユーザーの Exchange ユニファイド メッセージング (UM) 音声メールボックスにルーティングできますが、通話に適用される音声ポリシーで一意のボイス メール電話番号が指定され、内線番号が含まれていない場合に限られます。
ブランチ サイトの復元のハードウェアおよびソフトウェア要件
ハードウェアおよびソフトウェア要件は、復元ソリューションによって異なります。
存続可能ブランチ アプライアンスの要件
必要なハードウェアとソフトウェアは、存続可能ブランチ アプライアンスに組み込まれています。 ただし、各ブランチ サイトでは、クライアント IP アドレスを取得するために DHCP サーバーを展開することもお勧めします。それ以外の場合、DHCP リースの有効期限が切れると、クライアントは IP 接続を持たなくなります。
エンタープライズ DNS サーバーが中央サイトにのみ配置されている場合、ブランチ サイト ユーザーは WAN の停止中にそれらに接続できないため、DNS SRV (サービス (SRV) リソース レコードを使用するSkype for Business Server検出は失敗します。 WAN の停止時に迅速に再ルーティングされるように、ブランチ サイトで DNS レコードをキャッシュする必要があります。 ブランチのルーターが DNS キャッシュをサポートする場合は、DNS キャッシュを有効にします。 または、ブランチに DNS サーバーを展開することもできます。 これは、スタンドアロン サーバー、または DNS 機能をサポートする存続可能ブランチ アプライアンスのバージョンです。 詳細については、存続可能ブランチ アプライアンス プロバイダーにお問い合わせください。
注意
ブランチ サイトにドメイン コントローラーを使用する必要はありません。 存続可能ブランチ アプライアンスは、サインイン時にクライアントの証明書要求に応答してクライアントを送信する特別な証明書を使用してクライアントを認証します。
クライアントSkype for Business DHCP オプション 120 (SIP レジストラー オプション) を使用してSkype for Business Serverを検出できます。 これは、次の 2 つのいずれかの方法で構成できます。
ブランチ サイトで DHCP サーバーを構成して DHCP 120 クエリに応答します。DHCP 120 クエリは、存続可能ブランチ アプライアンスまたは存続可能ブランチ サーバー上のレジストラーの FQDN を返します。
DHCP Skype for Business Serverオンにします。 これをオンにすると、Skype for Business Server レジストラーは DHCP オプション 120 クエリに応答します。 レジストラーは、DHCP オプション 120 以外の DHCP クエリには応答しません。
また、より大きなブランチ サイトで複数のサブネットがある場合は、DHCP オプション 120 のクエリが DHCP サーバー (構成 1) またはレジストラー (構成 2) に転送されるように、DHCP リレー エージェントを有効にする必要があります。
最後に、ブランチ サイト ユーザーをエンタープライズ VoIP用に構成し、適切なユニファイド コミュニケーション エンドポイントを使用してプロビジョニングする必要があります。
存続可能ブランチ サーバーの要件
存続可能ブランチ サーバーの要件は、フロントエンド サーバーの要件と同じです。 詳細については、「Server requirements for Skype for Business Server 2015」を参照してください。
Full-Scale Skype for Business Server Branch-Site デプロイの要件
詳細については、計画に関するドキュメントの「Skype for Business Server 2015 のサーバー要件」を参照してください。
例: フェールオーバー ルートの構成
次の例では、Dallas-GW1 がメンテナンスで停止したり、利用できなくなったりしたときに使用するフェールオーバー ルートの定義方法を示します。 必要な構成の変更を次の表に示します。
表 1. ユーザー ポリシー
| ユーザー ポリシー | 電話使用法 |
|---|---|
| Default Calling Policy |
Local GlobalPSTNHopoff |
| Redmond Local Policy |
RedmondLocal |
| Dallas Calling Policy |
DallasUsers GlobalPSTNHopoff |
表 2. ルート
| ルート名 | 番号パターン | 電話使用法 | トランク | ゲートウェイ |
|---|---|---|---|---|
| Redmond Local Route |
^+1(425 | 206 | 253)(\d{7})$ |
Local RedmondLocal |
| Dallas Local Route |
^+1(972 | 214 | 469)(\d{7})$ |
Local |
| Universal Route |
^+?(\d*)$ |
GlobalPSTNHopoff |
Trunk1 Trunk2 Trunk3 |
Red-GW1 Red-GW2 Dallas-GW1 |
| Dallas Users Route |
^+?(\d*)$ |
DallasUsers |
Trunk3 |
Dallas-GW1 |
表 1 では、Dallas Calling Policy の電話使用法 DallasUsers の後に、電話使用法 GlobalPSTNHopoff が追加されます。 この結果、電話使用法 DallasUsers に対応したルートが使用できない場合に、Dallas Calling Policy の通話で電話使用法 GlobalPSTNHopoff 用に構成されたルートが使用できるようになります。