Skype for Business Serverのエッジ サーバーのシステム要件

概要:Skype for Business Serverの Edge Server のシステム要件について説明します。

Skype for Business Server Edge Server のデプロイに関しては、環境自体にあるサーバーまたはサーバーに対して行う必要がある作業と、環境構造の計画を行う必要があります。 トポロジ、DNS、証明書、およびその他のインフラストラクチャに関する考慮事項の詳細については、環境の要件のドキュメントを参照してください。

Components

エッジ サーバー環境について説明するときは、境界ネットワークに展開されているコンポーネント (つまり、ワークグループまたは Skype for Business Serverドメイン構造の外部にあるドメイン) を参照しています。

以下に示すコンポーネントは、エッジの展開を成功させるために留意する必要があるコンポーネントです。

上記の各コンポーネントに関する詳細を以下に示します。

エッジ サーバー

これらは、境界環境にデプロイされたSkype for Business サーバーです。 その役割は、内部Skype for Business Server展開によって提供されるサービスのネットワーク トラフィックを外部ユーザーに送受信することです。 これを正常に行うには、各エッジ サーバーが実行されます。

  • Access Edge サービス: 送信と受信の両方のセッション開始プロトコル (SIP) トラフィックに対して、信頼できる 1 つの接続ポイントを提供します。

  • Web 会議エッジ サービス: 外部ユーザーが内部Skype for Business Server環境でホストされている会議に参加できるようにします。

  • A/V Edge サービス: オーディオ、ビデオ、アプリケーション共有、ファイル転送を外部ユーザーが使用できるようにします。

  • XMPP プロキシ サービス: 構成された XMPP フェデレーション パートナーとの間で拡張可能なメッセージングおよびプレゼンス プロトコル (XMPP) メッセージを受け入れて送信します。

承認された外部ユーザーは、エッジ サーバーを使用して内部Skype for Business Server展開に接続できますが、それ以外の場合は、内部ネットワークへの他のアクセスは提供されません。

注意

エッジ サーバーは、有効なSkype for Business クライアントとその他のエッジ サーバー (フェデレーション シナリオ) の接続を提供するために展開されます。 他のエンド ポイント クライアントやサーバーの種類からは接続できません。 XMPP ゲートウェイ サーバーにより、構成済みの XMPP パートナーとの接続を実現できます。 ただしこの場合も、フェデレーション シナリオで有効なものだけが、実際に機能するクライアントとフェデレーションの種類です。

注意

XMPP ゲートウェイとプロキシは、Skype for Business Server 2015 で使用できますが、Skype for Business Server 2019 ではサポートされなくなりました。 詳細については、「 XMPP フェデレーションの移行 」を参照してください。

リバース プロキシ

リバース プロキシ (RP) サーバーにはSkype for Business Serverロールはありませんが、エッジ サーバーの展開に不可欠なコンポーネントです。 リバース プロキシを使用すると、外部ユーザーは次のことができます。

  • 簡易 URL を使用して会議またはダイヤルイン会議に接続する。

  • 会議コンテンツをダウンロードする。

  • 配布グループを拡張する。

  • クライアント証明書ベースの認証用のユーザーベースの証明書を取得する。

  • アドレス帳サーバーからファイルをダウンロードするか、アドレス帳 Web クエリ サービスにクエリを送信します。

  • クライアントおよびデバイス ソフトウェアの更新プログラムを取得する。

また、モバイル デバイスに関しては以下の操作が可能になります。

  • これにより、モビリティ サービスを提供するフロント エンド サーバーを自動的に検出できます。

  • Microsoft 365 または Office 365 からモバイル デバイスへのプッシュ通知を有効にします。

現在のリバース プロキシの推奨事項については、「テレフォニー インフラストラクチャ for Skype for Business」ページを参照してください。 そのため、リバース プロキシ:

  • 以下から構成される公開済みの外部 Web サービスに接続するために、公開証明書を介して、環境に導入されているトランスポート層セキュリティ (TLS) を使用できる必要があります。

    • ディレクター プールまたはディレクター プール

    • フロント エンド サーバーまたはフロント エンド プール

  • 暗号化用の証明書を使用するか、必要に応じて暗号化されない方法で内部 Web サイトを公開できる必要があります。

  • 完全修飾ドメイン名 (FQDN) を使用して、内部的にホストされている Web サイトを外部に公開できる必要があります。

  • は、ホストされている Web サイトのすべてのコンテンツを公開できる必要があります。 既定では、 * ディレクティブを /\使用できます。これは、ほとんどの Web サーバーで認識され、"Web サーバー上のすべてのコンテンツを発行する" を意味します。ディレクティブ (/ Uwca/\* など) を変更することもできます。これは、"仮想ディレクトリ Ucwa のすべてのコンテンツを発行する" を意味します。

  • 公開された Web サイトのコンテンツを要求するクライアントで TLS 接続を要求する必要があります。

  • サブジェクトの別名 (SAN) エントリを持つ証明書を受け入れる必要があります。

  • 外部 Web サービスの FQDN が解決されるリスナーまたはインターフェイスに対して証明書をバインドできる必要があります。 インターフェイスの構成よりリスナーの構成をお勧めします。 多くのリスナーは、単一のインターフェイスで構成できます。

  • ホスト ヘッダー処理の構成を許可する必要があります。 多くの場合、要求元のクライアントから送信された元のホスト ヘッダーは、リバース プロキシによって変更されるのではなく、透過的に渡す必要があります。

  • 外部で定義された 1 つのポート (例: TCP 443) から別の定義されたポート (例: TCP 4443) への TLS トラフィックのブリッジを許可する必要があります。 リバース プロキシは、受信時にパケットを復号化し、送信時にパケットを再暗号化できます。

  • 1 つのポート (例: TCP 80) から別のポート (例: TCP 8080) への暗号化されていない TCP トラフィックのブリッジを許可する必要があります。

  • NTLM 認証、認証なし、およびパススルー認証の構成を許可または受け入れる必要があります。

リバース プロキシがこの一覧のすべてのニーズに対応できる場合は、先に進んでくださいが、上記のリンクにある推奨事項に留意してください。

ファイアウォール

外部ファイアウォールの内側にエッジ展開を配置する必要がありますが、1 つの外部ファイアウォールと、エッジ環境と内部環境の間に配置する 1 つの内部ファイアウォールの、2 つのファイアウォールを使用することをお勧めします。 シナリオのすべてのドキュメントには 2 つのファイアウォールが含まれます。 2 つのファイアウォールをお勧めするのは、ネットワーク エッジ間の厳密なルーティングが実現され、内部ネットワーク用にファイアウォール保護が二重になるからです。

ディレクター

これは省略可能なロールです。 単一サーバーまたはディレクター ロールを実行するサーバーのプールを指定できます。 これは、内部Skype for Business Server環境で見つかったロールです。

ディレクターは、Skype for Business Server内部サーバー宛てのエッジ サーバーから受信 SIP トラフィックを受信する内部ネクスト ホップ サーバーです。 着信した要求を事前認証し、これをユーザーのホーム プールまたはサーバーにリダイレクトします。 この事前認証により、識別されていないユーザー アカウントの要求を破棄できます。

このことが問題になる理由について説明します。 ディレクターにとって重要な機能は、Standard Edition サーバーとフロント エンド サーバーまたはフロント エンド プールを、サービス拒否 (DoS) 攻撃などの悪意のあるトラフィックから保護することです。 ネットワークが無効な外部トラフィックであふれた場合、トラフィックはディレクターで停止します。

ロード バランサー

Skype for Business Serverスケーリングされた統合エッジ トポロジは、新しいデプロイの DNS 負荷分散用に最適化されており、これをお勧めします。 高可用性が必要な場合は、特定の状況でハードウェア ロード バランサーを使用することをお勧めします。

  • Exchange 2013 より前 の Exchange UM を使用するリモート ユーザー向けの Exchange UM。

重要

ロード バランサーを混在させることができない点に注意することが非常に重要です。 Skype for Business Server環境では、すべてのインターフェイスで DNS または HLB を使用する必要があります。

注意

ダイレクト サーバー リターン (DSR) NAT は、Skype for Business Serverではサポートされていません。

A/V Edge サービスを実行するエッジ サーバー エッジ サーバーのハードウェア ロード バランサー要件

A/V Edge サービスを実行しているエッジ サーバーの要件は次のとおりです。

  • 内部と外部の両方のポート 443 に対して TCP のネーグル処理がオフになっていること。ネーグル処理はいくつかの小さなパケットを 1 つの大きなパケットにまとめて転送効率を向上させるプロセスです。

  • 外部ポート範囲 50000 ~ 59999 の TCP のネーグル処理がオフになっていること。

  • 内部または外部のファイアウォールで NAT が使用されていないこと。

  • Edge 内部インターフェイスは、エッジ サーバーの外部インターフェイスとは異なるネットワーク上にあり、それらの間のルーティングを無効にする必要があります。

  • A/V Edge サービスを実行するエッジ サーバーの外部インターフェイスでは、パブリックにルーティング可能な IP アドレスを使用し、エッジ外部 IP アドレスに NAT またはポート変換を行う必要はありません。

HLB の要件

Skype for Business Serverには、Cookie ベースのアフィニティ要件はあまりありません。 そのため、Skype for Business Server環境で Lync Server 2010 フロントエンド サーバーまたはフロントエンド プールを使用する (これは 2015 固有Skype for Business Server) 場合を除き、Cookie ベースの永続化を使用する必要はありません。 Lync Server 2010 に推奨される構成方法で Cookie ベースのアフィニティが必要になります。

注意

HLB 用に Cookie ベースのアフィニティを有効にすることを決定した場合、環境で不要であっても、そのような操作に問題はありません。

環境で Cookie ベースのアフィニティが不要である場合は、次のようになります。

  • ポート 443 のリバース プロキシ発行規則で、[ Forward host header]\(ホスト ヘッダーの転送\ ) を True に設定 します。 これにより、元の URL が確実に転送されます。

Cookie ベースのアフィニティが必要である展開の場合:

  • ポート 443 のリバース プロキシ発行規則で、[ Forward host header]\(ホスト ヘッダーの転送\ ) を True に設定 します。 これにより、元の URL が確実に転送されます。

  • ハードウェア ロード バランサー Cookie は httpOnly とマーク しないでください

  • ハードウェア ロード バランサー Cookie には有効期限 を設定しないでください

  • ハードウェア ロード バランサー Cookie には MS-WSMAN という名前を付ける必要があります (これは Web サービスが予期する値であり、変更できません)。

  • 同じ TCP 接続の以前の HTTP 応答が Cookie を取得したかどうかに関係なく、受信 HTTP 要求に Cookie が含まれていないすべての HTTP 応答で、ハードウェア ロード バランサー Cookie を設定する 必要があります 。 ハードウェア ロード バランサーで、TCP 接続ごとに 1 回だけ Cookie の挿入が行われるよう最適化する場合、その最適化を使用 しないでください

注意

HLB 構成では、ソース アフィニティと 20 分の TCP セッション有効期間を使用するのが一般的です。これは、クライアントの使用状況やアプリケーションの相互作用によってセッションの状態が維持されるため、Skype for Business Serverとそのクライアントに適しています。

モバイル デバイスを展開する場合、HLB で、TCP セッション内の個々の要求を負荷分散できるようにする必要があります (実際には、ターゲット IP アドレスに基づいて個々の要求を負荷分散できる必要があります)。

重要

F5 HLB には、OneConnect と呼ばれる機能があります。 この機能を使用すると、TCP 接続内の各要求が個々に負荷分散されます。 モバイル デバイスを展開する場合、HLB のベンダーが同じ機能をサポートしていることを確認してください。 最新の iOS モバイル アプリでは、TLS バージョン 1.2 が必要です。 より詳細な情報が必要な場合は、F5 が、その固有の設定を提供します。

(省略可能) ディレクターと (必須) フロント エンド プール Web サービスの HLB 要件を次に示します。

  • 内部 Web サービス VIP の場合は、HLB Source_addr永続化 (内部ポート 80、443) を設定します。 Skype for Business Serverの場合、Source_addr永続化とは、セッション状態を維持するために、1 つの IP アドレスから送信される複数の接続が常に 1 つのサーバーに送信されることを意味します。

  • TCP アイドル タイムアウト 1800 秒を使用すること。

  • リバース プロキシとネクスト ホップ プールの HLB の間のファイアウォールで、リバース プロキシから HLB への https: ポート 4443 上のトラフィックを許可する規則を作成します。 ポート 80、443、および 4443 をリッスンするように HLB を構成する必要があります。

HLB のアフィニティ要件の概要

クライアント/ユーザーの場所 外部 Web サービスの FQDN のアフィニティ要件 内部 Web サービスの FQDN のアフィニティ要件
Skype for Business Web アプリ (内部ユーザーと外部ユーザー)
モバイル デバイス (内部および外部ユーザー)
アフィニティなし
送信元アドレスのアフィニティ
Skype for Business Web アプリ (外部ユーザーのみ)
モバイル デバイス (内部および外部ユーザー)
アフィニティなし
送信元アドレスのアフィニティ
Skype for Business Web アプリ (内部ユーザーのみ)
モバイル デバイス (展開しない)
アフィニティなし
送信元アドレスのアフィニティ

HLB のポート監視

ハードウェアまたは通信の障害が原因で、特定のサービスが使用できなくなった場合を判断するには、ハードウェア ロード バランサーでポート監視を定義します。 たとえば、フロント エンド サーバーまたはフロント エンド プールが失敗したためにフロントエンド サーバー サービス (RTCSRV) が停止した場合、HLB 監視は Web サービスでのトラフィックの受信も停止する必要があります。 HLB の外部インターフェイスに関する以下の部分を監視する目的で、HLB にポート監視を実装する必要があります。

仮想 IP/ポート ノード ポート ノード コンピューター/モニター 保存プロファイル メモ
<プール>web_mco_443_vs
443
4443
フロントエンド
5061
なし
HTTPS
<プール>web_mco_80_vs
80
8080
フロントエンド
5061
なし
HTTP

ハードウェアおよびソフトウェア要件

Skype for Business Server 2015 のサーバーの全体的な要件と、Skype for Business Server 2019 ドキュメントのシステム要件のエッジ サーバーのハードウェアとソフトウェアの要件について説明しました。

併置

Skype for Business Serverドキュメントのトポロジの基本に関するページで、Edge Server の併置について説明しました。