モビリティの技術要件

 

トピックの最終更新日: 2013-03-05

モバイル ユーザーは、特別な計画を必要とするさまざまなモバイル アプリケーション シナリオに直面します。たとえば、ユーザーが職場から離れている間に 3G ネットワーク経由の接続によってモバイル アプリケーションの使用を開始し、職場に到着したときに社内の Wi-Fi ネットワークに切り替え、職場のビルから離れるときに再度 3G に切り替えることが考えられます。このようなネットワークの移行をサポートし、一貫したユーザー エクスペリエンスを確保するように、環境を計画する必要があります。このセクションでは、モバイル アプリケーションおよびモビリティ リソースの自動検出をサポートするために満たす必要のあるインフラストラクチャ要件について説明します。

自動検出を使用する場合、モバイル デバイスは、ドメイン ネーム システム (DNS) を使用してリソースを見つけます。DNS の参照時に、内部 DNS レコード (lyncdiscoverinternal.<sipdomain>) に関連付けられた完全修飾ドメイン名 (FQDN) への接続が最初に試みられます。内部 DNS レコードを使用して接続できない場合は、外部 DNS レコード (lyncdiscover.<sipdomain>) を使用して接続が試みられます。ネットワークの内部にあるモバイル デバイスは内部自動検出サービス URL に接続し、ネットワークの外部にあるモバイル デバイスは自動検出サービスの外部 URL に接続します。外部要求はリバース プロキシを経由します。Microsoft Lync Server 2010 自動検出サービスは、Mobility Service の URL を含め、ユーザーのホーム プール用のすべての Web サービス URL を返します。ただし、Mobility Service の内部 URL と Mobility Service の外部 URL は共に Web サービスの外部 FQDN に関連付けられます。したがって、モバイル デバイスがネットワークの内部または外部のどちらにあるかどうかに関係なく、デバイスは、常に、リバース プロキシ経由で Microsoft Lync Server 2010 Mobility Service に外部から接続します。

注:
モバイル アプリケーションは、他の Lync Server サービス (アドレス帳サービスなど) にも接続できますが、モバイル アプリケーションのすべての Web 要求を同じ外部 Web FQDN に送信するというこの要件は Mobility Service にのみ適用されます。他のサービスでは、この構成は必要ありません。

次の図に、Mobility Service および自動検出サービスのモバイル アプリケーション Web 要求のフローを示します。

Mobility Service および自動検出サービスに対するモバイル アプリケーションの要求のフロー

社内ネットワークの内側と外側からのモバイル ユーザーをサポートするには、内部と外部の Web FQDN について、いくつかの前提条件が満たされる必要があります。また、実装するように選択した機能に応じて、他の要件を満たすことが必要になる場合もあります。

• 新しい DNS CNAME または A レコード - 自動検出用

• DNS SRV レコード - プッシュ通知クリアリング ハウスとのフェデレーション用

• 新しいポート - 内部サーバー用

• 新しいファイアウォール ルール - Wi-Fi ネットワーク経由でプッシュ通知をサポートする場合

• 内部サーバー証明書およびリバース プロキシ証明書のサブジェクトの別名 - 自動検出用

• フロントエンド サーバーのハードウェア ロード バランサー構成の変更 - Cookie ベースの永続性を確保するため

• リバース プロキシの新しい Web 公開ルール - 自動検出用

Web サイトの要件

Mobility Service と自動検出サービスをサポートするには、トポロジで以下の要件を満たす必要があります。

• フロントエンド プールの内部 Web FQDN は、フロントエンド プールの外部 Web FQDN と区別する必要があります。

• 内部 Web FQDN は、社内ネットワークにのみ解決し、社内ネットワークの内側からのみアクセスできる必要があります。

• 外部 Web FQDN (内部および外部の両方のユーザー要求によって処理される Mobility Service URL を除く) は、インターネットにのみ解決し、インターネットからのみアクセスできる必要があります。

• 社内ネットワークの内側にいるユーザーの場合、Mobility Service の URL は、外部 Web FQDN にアドレス指定される必要があります。この要件は Mobility Service 向けであり、この URL にのみ適用されます。

• 社内ネットワークの外側にいるユーザーの場合、要求は、フロントエンド プールまたはディレクターの外部 Web FQDN に送信される必要があります。

• スプリットブレイン DNS 環境があり、モバイル デバイスのクライアントがワイヤレスで接続する場合、パブリック IP アドレスを使用して内部 DNS に外部 Web FQDN を構成する必要があります。

DNS の要件

Mobility Service と自動検出サービスをサポートするには、トポロジで以下に示す DNS の要件を満たす必要があります。

Mobility Service の URL の要件

既定の構成では、Wi-Fi 経由で内部ネットワークに接続するユーザーには、常に、ホーム プールとして外部の Mobility Service の URL が返されます。ユーザーのデバイスは内部 DNS ゾーンに対してクエリを実行し、外部の Lync Web サービスの FQDN をリバース プロキシの外部インターフェイスの IP アドレスに解決できる必要があります。その後、ユーザーはリバース プロキシを経由して Mobility Service への発信のヘアピン接続を確立します。

自動検出とプッシュ通知の要件

自動検出をサポートする場合、SIP ドメインごとに以下の DNS レコードを作成する必要があります。

• 組織のネットワーク内から接続するモバイル ユーザーをサポートするための内部 DNS レコード

• インターネットから接続するモバイル ユーザーをサポートするための外部 (パブリック) DNS レコード

• プッシュ通知をサポートするための外部 (パブリック) DNS レコード

内部の自動検出 URL にネットワークの外側からアドレス指定できないようにする必要があります。外部の自動検出 URL にネットワーク内からアドレス指定できないようにする必要があります。ただし、外部 URL に対するこの要件を満たすことができなくても、モバイル クライアントは機能的に影響を受けません。内部 URL が常に最初に試みられるためです。

DNS レコードは、CNAME レコードまたは A (ホスト) レコードとすることができます。

次の内部 DNS レコードを作成する必要があります。

内部 DNS レコード

レコードの種類	ホスト名	解決先
A (ホスト)	lyncweb.contoso.com (外部 Web サービス URL の例)	外部 Web サービスの URL の外部 IP アドレスに解決される、内部 DNS にあるレコード。例: https://lyncweb.contoso.com

さらに、次の内部 DNS レコードの 1 つを作成する必要があります。

レコードの種類	ホスト名	解決先
CNAME	lyncdiscoverinternal.<sipdomain>	ディレクター プール (ディレクター プールがある場合) またはフロントエンド プール (ディレクターがない場合) の内部 Web サービス FQDN
A (ホスト)	lyncdiscoverinternal.<sipdomain>	ディレクター プール (ディレクター プールがある場合) またはフロントエンド プール (ディレクターがない場合) の内部 Web サービス IP アドレス (ロード バランサーを使用する場合は仮想 IP (VIP) アドレス)

次の外部 DNS レコードの 1 つを作成する必要があります。

外部 DNS レコード

レコードの種類	ホスト名	解決先
CNAME	lyncdiscover.<sipdomain>	ディレクター プール (ディレクター プールがある場合) またはフロントエンド プール (ディレクターがない場合) の外部 Web サービス FQDN
A (ホスト)	lyncdiscover.<sipdomain>	リバース プロキシの外部またはパブリック IP アドレス

注:
外部トラフィックはリバース プロキシを経由します。

注:

モバイル デバイスのクライアントでは、異なるドメインからの複数の SSL (Secure Sockets Layer) 証明書がサポートされません。つまり、HTTPS では、異なるドメインへの CNAME のリダイレクトがサポートされません。たとえば、director.contoso.net のアドレスにリダイレクトされる lyncdiscover.contoso.com の DNS CNAME レコードは、HTTPS ではサポートされません。このようなトポロジでは、CNAME のリダイレクトが HTTP で解決されるように、モバイル デバイスのクライアントは、最初の要求に対して HTTP を使用する必要があります。その後、以降の要求については HTTPS を使用します。このシナリオをサポートするには、ポート 80 (HTTP) の Web 公開ルールを使用して、リバース プロキシを構成する必要があります。詳しくは、「モビリティに合わせたリバース プロキシの構成」の「ポート 80 の Web 公開ルールを作成するには」をご覧ください。 HTTPS では、同じドメインへの CNAME のリダイレクトはサポートされます。この場合、リダイレクト先のドメインの証明書で元のドメインがカバーされます。

レコードの種類	定義	解決先
SRV	_sipfederationtls._tcp.<SIP ドメイン名> からアクセス エッジ サービスのホスト A レコード	例: _sipfedrationtls._tcp.contoso.com と定義済みポート TCP 5061 から sip.contoso.com 重要: SRV レコードは、同じ SIP ドメインの A を指す必要があります。

ポートとファイアウォールの要件

Mobility Service では、フロントエンド サーバーまたは Standard Edition サーバーに以下の 2 つの Web サービス リッスン ポートが必要です。展開プロセス中に、Set-CsWebServer コマンドレットを使用して、これらのポートを手動で設定します。詳しくは、「モビリティ用の内部サーバー ポートの設定」をご覧ください。

プッシュ通知のオンライン プロバイダーとのフェデレーションのために、TCP 5061 用の許可ルールを作成する必要もあります。詳しくは、「関連アーキテクチャ」をご覧ください。

• ポート 5086。社内ネットワークの内側からのモバイル要求をリッスンするために使用します。これは、Mobility Service の内部プロセスで使用される SIP ポートです。

• ポート 5087。インターネットからのモバイル要求をリッスンするために使用します。これは、Mobility Service の外部プロセスで使用される SIP ポートです。

また、プッシュ通知をサポートし、Apple モバイル デバイスで Wi-Fi ネットワーク経由のプッシュ通知を受信する場合、社内の Wi-Fi ネットワークのポート 5223 も開く必要があります。ポート 5223 は、送信 TCP ポートであり、Apple Push Notification Service (APNS) で使用されます。モバイル デバイスや通知サービスは接続を開始できますが、社内の Wi-Fi ネットワークで発信ポートを使用できる必要があります。詳しくは、http://support.apple.com/kb/TS1629?viewlocale=ja_JP および http://developer.apple.com/library/ios/#technotes/tn2265/_index.html をご覧ください。

証明書の要件

Lync モバイル クライアントに対して自動検出をサポートする場合、証明書のサブジェクトの別名リストを変更し、モバイル クライアントからのセキュリティで保護された接続をサポートする必要があります。新しい証明書の要求と割り当てを行って、自動検出サービスを実行するフロントエンド サーバーおよびディレクターごとに、このセクションで説明されているサブジェクトの別名エントリを追加する必要があります。この方法として、リバース プロキシ用の証明書のサブジェクトの別名リストも変更することをお勧めします。組織内のすべての SIP ドメインに対してサブジェクトの別名エントリを追加する必要があります。

通常、内部の証明書機関を使用した証明書の再発行は簡単なプロセスですが、サブジェクトの複数の別名エントリを、リバース プロキシで使用されるパブリック証明書に追加するには、高い費用がかかる可能性があります。多くの SIP ドメインがある場合 (サブジェクトの別名を追加する処理が非常に高価になります)、初期の自動検出サービス要求を、HTTPS を使用してポート 443 (既定の構成) で送信する代わりに、HTTP を使用してポート 80 で送信するようにリバース プロキシを構成できます。その後、要求は、ディレクターまたはフロントエンド プールのポート 8080 にリダイレクトされます。初期の自動検出サービス要求をポート 80 で発行すると、要求で HTTPS ではなく HTTP が使用されるため、リバース プロキシの証明書を変更する必要はありません。ただし、この方法はサポートされますが、お勧めできません。

注:
初期要求に対してポート 80 を使用する方法について詳しくは、外部ユーザーの計画に関するドキュメントの「自動検出サービスの要件」の「ポート 80 を使用する初期の自動検出プロセス」をご覧ください。

注:
内部証明機関 (CA) から発行された内部証明書を Lync Server 2010 インフラストラクチャで使用しており、ワイヤレスによるモバイル デバイスの接続をサポートする計画がある場合、内部 CA からのルート証明書チェーンをモバイル デバイスにインストールするか、Lync Server インフラストラクチャのパブリック証明書に変更する必要があります。

このセクションでは、以下の証明書で必要とされるサブジェクトの別名について説明します。

• エッジ サーバーまたはエッジ サーバー プール

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

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

• リバース プロキシ

説明	サブジェクト名の別名エントリ
アクセス エッジ サービス	SAN=sip.<sipdomain>

ディレクター プールの証明書の要件

説明	サブジェクト名の別名エントリ
内部自動検出サービス URL	SAN=lyncdiscoverinternal.<sipdomain>
外部自動検出サービス URL	SAN=lyncdiscover.<sipdomain>

注:
自動検出 (lyncdiscover および lyncdicoverinternal) レコードについてのみ、SAN=*.<sipdomain> を使用することもできます。

フロントエンド プールの証明書の要件

説明	サブジェクト名の別名エントリ
内部自動検出サービス URL	SAN=lyncdiscoverinternal.<sipdomain>
外部自動検出サービス URL	SAN=lyncdiscover.<sipdomain>

注:
自動検出 (lyncdiscover および lyncdicoverinternal) レコードについてのみ、SAN=*.<sipdomain> を使用することもできます。

リバース プロキシ (パブリック CA) の証明書の要件

説明	サブジェクト名の別名エントリ
外部自動検出サービス URL	SAN=lyncdiscover.<sipdomain>

注:
この証明書は、リバース プロキシ上の SSL リスナーに割り当てます。

インターネット インフォメーション サービス (IIS) の要件

モビリティでは IIS 7.5 を使用することをお勧めします。Mobility Service インストーラーは、パフォーマンスを向上するようにいくつかの ASP.NET フラグを設定します。既定では、IIS 7.5 が Windows Server 2008 R2 にインストールされ、Mobility Service インストーラーによって ASP.NET 設定が自動的に変更されます。Windows Server 2008 で IIS 7.0 を使用する場合は、この設定を手動で変更する必要があります。詳しくは、「Mobility Service と自動検出サービスのインストール」をご覧ください。

ハードウェア ロード バランサーの要件

環境にフロントエンド プールが含まれる場合、Web サービスのトラフィックに対して使用されるハードウェア ロード バランサーの外部 Web サービス仮想 IP (VIP) を、Cookie ベースの永続性を確保するように構成する必要があります。Cookie ベースの永続性によって、1 つのクライアントから複数の接続があっても、接続は 1 つのサーバーに送信されてセッション状態が維持されます。Cookie は特定の要件を満たす必要があります。Cookie の要件について詳しくは、「負荷分散の要件」をご覧ください。

Lync モバイル クライアントを内部の Wi-Fi ネットワークのみでサポートすることを計画している場合、外部 Web サービスの VIP に関する説明のとおりに内部 Web サービスの VIP を構成し、Cookie ベースの永続性を確保する必要があります。この場合、ハードウェア ロード バランサーで内部 Web サービスの VIP に対する発信元アドレスの永続性を使用しないでください。詳しくは、「負荷分散の要件」をご覧ください。

リバース プロキシの要件

Lync モバイル クライアントに対して自動検出をサポートする場合、以下のように新しい Web 公開ルールを作成する必要があります。

• リバース プロキシ証明書のサブジェクトの別名リストを更新し、初期の自動検出サービス要求に対して HTTPS を使用するように決定した場合、lyncdiscover.<sipdomain> 用の新しい Web 公開ルールを作成する必要があります。また、Web サービスの外部 URL に対する Web 公開ルールがフロントエンド プールに存在することを確認する必要があります。

• リバース プロキシ証明書のサブジェクトの別名リストを更新しなくてもよいように初期の自動検出サービス要求に対して HTTP を使用するように決定した場合、ポート 80 (HTTP) 用の新しい Web 公開ルールを作成する必要があります。