Skype for Business Serverの Edge Server 環境要件

概要：Skype for Business Serverの Edge Server の環境要件について説明します。

計画と準備の多くは、Skype for Business Server Edge Server 環境自体の外部で行う必要があります。 この記事では、以下の一覧に従って、組織環境でどのような準備を実施する必要があるかを確認します。

• Topology planning

• DNS planning

• Certificate planning

• Port and firewall planning

トポロジの計画

Skype for Business Server Edge Server トポロジでは、次の機能を使用できます。

• ルーティング可能なパブリック IP アドレス

• ルーティング不可のプライベート IP アドレス (対称ネットワーク アドレス変換 (NAT) を使用する場合)

ルーティング不可のプライベート IP アドレスと NAT を使用する場合の注意点は次のとおりです。

• 3 つすべての外部インターフェイスでルーティング可能なプライベート IP アドレスを使用する必要があります。

• 受信と送信のトラフィックについて、対称 NAT を構成する必要があります。 対称 NAT は、Skype for Business Server エッジ サーバーで使用できる唯一のサポートされる NAT です。

• 受信元アドレスを変更しないように NAT を構成してください。 A/V Edge サービスは、最適なメディア パスを見つけるために受信ソース アドレスを受信できる必要があります。

• エッジ サーバーは、パブリック A/V Edge IP アドレスから相互に通信できる必要があります。 ファイアウォールでこのトラフィックを許可する必要があります。

• NAT は、DNS 負荷分散を使用する場合 にのみ 、スケーリングされた統合エッジ サーバーに使用できます。 ハードウェア ロード バランサー機器 (HLB) を使用する場合は、NAT なしでパブリック ルーティング可能な IP アドレスを使用する必要があります。

(ハードウェア負荷分散を使用していない限り) 単一およびスケーリングされた統合エッジ サーバー トポロジの両方に対して対称 NAT を実行するルーターまたはファイアウォールの背後に、Access、Web 会議、および A/V Edge インターフェイスを使用しても問題はありません。

エッジ サーバー トポロジ オプションの概要

Skype for Business Server Edge Server の展開に使用できるトポロジ オプションがいくつかあります。

• プライベート IP アドレスと NAT を使用する単一統合エッジ

• パブリック IP アドレスを使用する単一統合エッジ

• プライベート IP アドレスと NAT を使用する拡張統合エッジ

• パブリック IP アドレスを使用する拡張統合エッジ

• ハードウェア ロード バランサーによる拡張統合エッジ

選択の目安として、各トポロジで使用できるオプションの概要を次の表に示します。

¹ DNS 負荷分散を使用した Exchange ユニファイド メッセージング (UM) リモート ユーザー フェールオーバーには、Exchange 2013 以降が必要です。

IP アドレスの要件

基本的なレベルでは、3 つのサービスに IP アドレスが必要です。Edge サービス、Web 会議エッジ サービス、および A/V Edge サービスにアクセスします。 3 つの IP アドレスを使用してサービスごとに 1 つのアドレスを割り当てるか、1 つの IP アドレスおよびサービスごとに異なる 1 つのポートを選択して割り当てることができます (この点の詳細について、「Port and firewall planning」を参照することもできます)。 単一統合エッジ環境ではかなり明快です。

スケーリングされた統合トポロジでは少し複雑になる可能性があるため、トポロジの選択の主な決定ポイントは高可用性と負荷分散であることを念頭に置いて、IP アドレス要件をレイアウトするテーブルをいくつか見てみましょう。 高可用性のニーズは、負荷分散の選択に影響を与える可能性があります (これについては、テーブルの後で詳しく説明します)。

拡張統合エッジに必要な IP アドレス (役割ごとの IP アドレス)

拡張統合エッジに必要な IP アドレス (すべての役割に対して 1 つの IP アドレス)

計画を立てるときに、いくつかの追加事項も考慮してください。

• 高可用性: デプロイで高可用性が必要な場合は、プールに少なくとも 2 つのエッジ サーバーをデプロイする必要があります。 1 つのエッジ プールで最大 12 台のエッジ サーバーがサポートされることに注目してください (ただし、トポロジ ビルダーでは、テストもサポートもされていない最大 20 台まで追加できるため、サポートしないことをお勧めします)。 12 を超えるエッジ サーバーが必要な場合は、追加のエッジ プールを作成する必要があります。

• ハードウェア負荷分散: ほとんどのシナリオでは、DNS 負荷分散をお勧めします。 もちろん、ハードウェア負荷分散もサポートされていますが、特に DNS 負荷分散に対する単一のシナリオでは必要です。

  • Exchange 2007 または Exchange 2010 (SP なし) ユニファイド メッセージング (UM) への外部アクセス。

• DNS 負荷分散: UM の場合、Exchange 2010 SP1 以降は DNS 負荷分散でサポートできます。 以前のバージョンの Exchange の DNS 負荷分散を使用する必要がある場合は動作しますが、このトラフィックはすべてプール内の最初のサーバーに送信され、使用できない場合は、そのトラフィックは後で失敗します。

  次を使用して企業とフェデレーションする場合は、DNS 負荷分散も推奨されます。

• Skype for Business Server 2015:

  • Lync Server 2010
  • Lync Server 2013
  • Microsoft 365 または Office 365

• Skype for Business Server 2019:

  • Lync Server 2013
  • Skype for Business Server 2015
  • Microsoft 365 または Office 365

DNS の計画

エッジ サーバーのデプロイSkype for Business Serverとなると、DNS を適切に準備することが重要です。 適切なレコードを配置すると、デプロイがはるかに簡単になります。 概要を行い、これらのシナリオの DNS レコードの概要を示すいくつかのテーブルを一覧表示するため、上記のセクションでトポロジを選択できたらと思います。 必要に応じて、より詳細な読み取りのために、Skype for Business Server用の高度なエッジ サーバー DNS 計画も用意します。

単一統合エッジ サーバー シナリオの DNS レコード

これらは、パブリック IP または NAT を使用したプライベート IP を使用して、エッジ サーバーを歌うために必要な DNS レコードになります。 これはサンプル データであるため、独自のエントリをより簡単に解決できるように、IP の例を示します。

• 内部ネットワーク アダプター: 172.25.33.10 (既定のゲートウェイは割り当てされていません)

  注意

  エッジ内部インターフェイスを含むネットワークから、Skype for Business Serverまたは Lync Server 2013 クライアントを実行しているサーバー (たとえば、172.25.33.0 から 192.168.10.0) を含むネットワークへのルートがあることを確認します。

• 外部ネットワーク アダプター:

  • パブリック IP:

  • Access Edge: 131.107.155.10 (これはプライマリであり、既定のゲートウェイはパブリック ルーターに設定されています(例: 131.107.155.1)

  • Web 会議エッジ: 131.107.155.20 (セカンダリ)

  • A/V Edge: 131.107.155.30 (セカンダリ)

  Web 会議と A/V Edge パブリック IP アドレスは、Windows Server のローカル エリア接続プロパティのインターネット プロトコル バージョン 4 (TCP/IPv4) およびインターネット プロトコル バージョン 6 (TCP/IPv6) のプロパティの詳細セクションにある追加の (セカンダリ) IP アドレスです。

  • プライベート IP:

  • Access Edge: 10.45.16.10 (これはプライマリであり、既定のゲートウェイはルーターに設定されています(例: 10.45.16.1)

  • Web 会議エッジ: 10.45.16.20 (セカンダリ)

  • A/V Edge: 10.45.16.30 (セカンダリ)

Web 会議と A/V Edge パブリック IP アドレスは、Windows Server のローカル エリア接続プロパティのインターネット プロトコル バージョン 4 (TCP/IPv4) およびインターネット プロトコル バージョン 6 (TCP/IPv6) のプロパティの詳細セクションにある追加の (セカンダリ) IP アドレスです。

• 外部ネットワーク アダプターで 1 つの IP アドレスを使用することもできますが、この方法はお勧めしません。 異なるポート (Skype for Business Serverで実行できる) を使用して、サービスを区別する必要があるため、これはお勧めしませんが、代替ポートをブロックする可能性のあるファイアウォールがいくつかあります。 この点の詳細については、「Port and firewall planning」を参照してください。

• 1 つではなく 3 つの外部ネットワーク アダプターを使用し、サービス IP の 1 つをそれぞれに割り当てることができます。 なぜこれを行うのですか? サービスが分離され、問題が発生した場合はトラブルシューティングが容易になり、問題の解決中に他のサービスが引き続き機能する可能性があります。

スケーリングされた DNS とハードウェア エッジ サーバーのシナリオの DNS レコード

これらは、パブリック IP または NAT を使用したプライベート IP を使用して、エッジ サーバーを歌うために必要な DNS レコードになります。 これはサンプル データであるため、独自のエントリをより簡単に解決できるように、IP の例を示します。

• 内部ネットワーク アダプター:

  • ノード 1: 172.25.33.10 (デフォルト ゲートウェイの割り当てなし)

  • ノード 2: 172.25.33.11 (デフォルト ゲートウェイの割り当てなし)

    注意

    エッジ内部インターフェイスを含むネットワークから、Skype for Business Serverまたは Lync Server 2013 クライアントを実行しているサーバー (たとえば、172.25.33.0 から 192.168.10.0) を含むネットワークへのルートがあることを確認します。

• 外部ネットワーク アダプター:

  • ノード 1

    • パブリック IP:

      • Access Edge: 131.107.155.10 (これはプライマリであり、既定のゲートウェイはパブリック ルーターに設定されています(例: 131.107.155.1)

      • Web 会議エッジ: 131.107.155.20 (セカンダリ)

      • A/V Edge: 131.107.155.30 (セカンダリ)

        Web 会議と A/V Edge パブリック IP アドレスは、Windows Server のローカル エリア接続プロパティのインターネット プロトコル バージョン 4 (TCP/IPv4) およびインターネット プロトコル バージョン 6 (TCP/IPv6) のプロパティの詳細セクションにある追加の (セカンダリ) IP アドレスです。

    • プライベート IP:

      • Access Edge: 10.45.16.10 (これはプライマリであり、既定のゲートウェイはルーターに設定されています(例: 10.45.16.1)

      • Web 会議エッジ: 10.45.16.20 (セカンダリ)

      • A/V Edge: 10.45.16.30 (セカンダリ)

      Web 会議と A/V Edge パブリック IP アドレスは、Windows Server のローカル エリア接続プロパティのインターネット プロトコル バージョン 4 (TCP/IPv4) およびインターネット プロトコル バージョン 6 (TCP/IPv6) のプロパティの詳細セクションにある追加の (セカンダリ) IP アドレスです。

  • ノード 2

    • パブリック IP:

      • Access Edge: 131.107.155.11 (これはプライマリであり、既定のゲートウェイはパブリック ルーターに設定されています(例: 131.107.155.1)

      • Web 会議エッジ: 131.107.155.21 (セカンダリ)

      • A/V Edge: 131.107.155.31 (セカンダリ)

      Web 会議と A/V Edge パブリック IP アドレスは、Windows Server のローカル エリア接続プロパティのインターネット プロトコル バージョン 4 (TCP/IPv4) およびインターネット プロトコル バージョン 6 (TCP/IPv6) のプロパティの詳細セクションにある追加の (セカンダリ) IP アドレスです。

  • プライベート IP:

    • Access Edge: 10.45.16.11 (これはプライマリであり、既定のゲートウェイはルーターに設定されています(例: 10.45.16.1)

    • Web 会議エッジ: 10.45.16.21 (セカンダリ)

    • A/V Edge: 10.45.16.31 (セカンダリ)

      Web 会議と A/V Edge パブリック IP アドレスは、Windows Server のローカル エリア接続プロパティのインターネット プロトコル バージョン 4 (TCP/IPv4) およびインターネット プロトコル バージョン 6 (TCP/IPv6) のプロパティの詳細セクションにある追加の (セカンダリ) IP アドレスです。

ここでは、他の構成も利用できます。

• 外部ネットワーク アダプターで 1 つの IP アドレスを使用することもできますが、この方法はお勧めしません。 異なるポート (Skype for Business Serverで実行できる) を使用して、サービスを区別する必要があるため、これはお勧めしませんが、代替ポートをブロックする可能性のあるファイアウォールがいくつかあります。 この点の詳細については、「Port and firewall planning」を参照してください。

• 1 つではなく 3 つの外部ネットワーク アダプターを使用し、サービス IP の 1 つをそれぞれに割り当てることができます。 なぜこれを行うのですか? サービスが分離され、問題が発生した場合はトラブルシューティングが容易になり、問題の解決中に他のサービスが引き続き機能する可能性があります。

フェデレーション用の DNS レコード (すべてのシナリオ)

XMPP (Extensible Messaging and Presence Protocol) 用の DNS レコード

証明書の計画

Skype for Business Serverは、サーバー間とサーバー間のセキュリティで保護された暗号化された通信に証明書を使用します。 予期できるように、証明書に格納されているすべてのサブジェクト名 (SN) とサブジェクトの別名 (SAN) に一致するサーバーの DNS レコードが、証明書に記録されている必要があります。 現在はこの方法で機能しますが、計画段階で、証明書に格納されている SN と SAN の各エントリに対応する適切な FQDN を確実に DNS に登録してください。

外部証明書と内部証明書の要件を個別に説明します。その後、両者の要件を示す表を掲載します。

外部証明書

少なくとも、外部エッジ サーバー インターフェイスに割り当てられた証明書は、パブリック証明機関 (CA) によって提供される必要があります。 特定の CA をお勧めすることはできませんが、CA、 ユニファイド コミュニケーション証明書パートナー の一覧があり、お好みの CA が一覧表示されているかどうかを確認できます。

この公開証明書を取得するために CA に要求を送信する必要が生じるのはいつで、またどのような方法を使用すればよいでしょうか。 この作業を実行するいくつかの方法があります。

• Skype for Business Serverのインストールとエッジ サーバーの展開を実行できます。 Skype for Business Server展開ウィザードには、証明書要求を生成する手順があり、選択した CA に送信できます。

• また、Windows PowerShell コマンドを使用して、ビジネス ニーズやデプロイ戦略に合わせてこの要求を生成することもできます。

• 最後に、CA には独自の申請プロセスがあり、Windows PowerShellまたは別の方法も含まれる場合があります。 この場合は、参考としてここに掲載する情報に加えて、CA から提供されたドキュメントを参照する必要があります。

証明書を取得したら、次のSkype for Business Serverでこれらのサービスに割り当てる必要があります。

• Edge サービス インターフェイスにアクセスする

• Web 会議エッジ サービス インターフェイス

• オーディオ/ビデオ認証サービス (音声およびビデオ ストリームの暗号化に証明書を使用しないため、A/V Edge サービスと混同しないでください)

内部証明書

内部エッジ サーバー インターフェイスでは、パブリック CA のパブリック証明書、またはorganizationの内部 CA から発行された証明書を使用できます。 内部証明書について覚えておく必要があるのは、SN エントリを使用し、SAN エントリを使用しないため、内部証明書の SAN について心配する必要がまったくないということです。

必須の証明書に関する表

要求について理解できるように、表を用意しました。 ここに示す FQDN エントリは、サンプルのドメインのみを対象にしています。 独自のプライベート ドメインとパブリック ドメインに基づいて要求する必要がありますが、この例で方針を説明します。

• contoso.com: パブリック FQDN

• fabrikam.com: 2 番目のパブリック FQDN (複数の SIP ドメインがある場合に要求する内容のデモとして追加)

• Contoso.net: 内部ドメイン

エッジ証明書に関する表

単一のエッジ サーバーとエッジ プールのどちらを実行しているかに関係なく、証明書に必要なのは次のとおりです。

XMPP (Extensible Messaging and Presence Protocol) 用の証明書が必要な場合は、該当する表は前述の外部エッジに関する表とほぼ同じになりますが、以下の 2 つの SAN エントリを追加する必要があります。

• Xmpp。contoso.com

• *.contoso.com

現在、XMPP は Google Talk のSkype for Business Serverでのみサポートされていることに注意してください。他の何かのために使用する必要がある場合は、サードパーティベンダーが関与する機能を確認する必要があります。

ポートとファイアウォールの計画

Skype for Business Server Edge Server 展開のポートとファイアウォールの計画を適切に行うと、数日または数週間のトラブルシューティングとストレスを節約できます。 そのために、プロトコルの使用法、NAT を受信、送信、両方のどれで使用するのか、またパブリック IP に関してどのようなシナリオを想定するかに基づいて、どのポートを開く必要があるかを示すいくつかの表を掲載します。 さらに、ハードウェア負荷分散 (HLB) のシナリオに関する個別の表と、その点に関する詳細なガイダンスも示します。 そこからさらに詳しく読むには、特定の展開に関する問題にチェックSkype for Business Server、いくつかのエッジ サーバー シナリオもあります。

プロトコルの一般的な使用法

外部ファイアウォールと内部ファイアウォールの要約表に進む前に、次の表について考えてみましょう。

外部ポートに対するファイアウォールの要約表

送信元 IP アドレスと宛先 IP アドレスには、プライベート IP アドレスと NAT の組み合わせを使用しているユーザーに関する情報、およびパブリック IP アドレスを使用しているユーザーに関する情報を含めます。 ここでは、Skype for Business Server セクションの Edge Server シナリオのすべての順列について説明します。

内部ポートに対するファイアウォールの要約表

エッジ ポートを対象にしたハードウェア ロード バランサーに関する表

ハードウェア ロード バランサー (HLB) と Edge ポートに独自のセクションを提供しています。これは、追加のハードウェアと少し複雑になります。 この特定のシナリオのガイダンスについては、次の表を参照してください。

外部ポートに対するファイアウォールの要約表

送信元 IP アドレスと宛先 IP アドレスには、プライベート IP アドレスと NAT の組み合わせを使用しているユーザーに関する情報、およびパブリック IP アドレスを使用しているユーザーに関する情報を含めます。 ここでは、Skype for Business Server セクションの Edge Server シナリオのすべての順列について説明します。

内部ポートに対するファイアウォールの要約表

外部インターフェイスの仮想 IP

内部インターフェイスの仮想 IP

ここに示すガイダンスは多少変化する予定です。 事実、現時点で HLB を使用する状況では、以下の場合のみ、内部 VIP を経由するルーティングを使用することをお勧めします。

• Exchange 2007 または Exchange 2010 ユニファイド メッセージング (UM) を使用している場合。

• エッジを使用するレガシ クライアントが存在している場合

次の表では、これらのシナリオのガイダンスを示しますが、それ以外の場合は、中央管理ストア (CMS) に依存して、認識されている個々のエッジ サーバーにトラフィックをルーティングできます (もちろん、CMS はエッジ サーバー情報で最新の状態に保たれる必要があります)。