Lync Server 2013 の DNS の要件を確認する

Lync クライアントがサービスを検索する方法

Microsoft Lync 2010、Lync 2013、および Lync Mobile は、クライアントが Lync Server 2013 のサービスを検索してアクセスする方法と似ています。 注目すべき例外は、別のサービスの場所プロセスを使用する Lync Windows ストア アプリです。 このセクションでは、クライアントがサービスを検索する方法の 2 つのシナリオについて詳しく説明します。最初に、一連の SRV と A ホスト レコードを使用する従来の方法、2 つ目は自動検出サービス レコードのみを使用します。 デスクトップ クライアントに対する累積的な更新により、LYNC Server 2010 から DNS の場所プロセスが変更されます。すべてのクライアントの場合、DNS クエリ プロセスは、クエリが正常に返されるか、DNS レコードの一覧が使い果たされ、最終的なエラーがクライアントに返されるまで続行されます。

Lync Windows ストア アプリを 除く すべてのクライアントについて、DNS 参照中に SRV レコードがクエリされ、次の順序でクライアントに返されます。

1. lyncdiscoverinternal。<内部 Web サービス上の自動検出サービスのドメイン> A (ホスト) レコード

2. lyncdiscover。<外部 Web サービス上の自動検出サービスのドメイン> A (ホスト) レコード

3. _sipinternaltls._tcp.<内部 TLS 接続のドメイン> SRV (サービス ロケーター) レコード

4. _sipinternal._tcp。<内部 TCP 接続のドメイン> SRV (サービス ロケーター) レコード (TCP が許可されている場合にのみ実行)

5. _sip._tls。<外部 TLS 接続のドメイン> SRV (サービス ロケーター) レコード

6. sipinternal.<フロントエンド プールまたはディレクターのドメイン> A (ホスト) レコード。内部ネットワークでのみ解決可能

7. Sip。<内部ネットワーク上のフロントエンド プールまたはディレクターのドメイン> A (ホスト) レコード、またはクライアントが外部である場合は Access Edge サービス

8. sipexternal。<クライアントが外部である場合の Access Edge サービスのドメイン> A (ホスト) レコード

Lync Windows ストア アプリは、次の 2 つのレコードを使用するため、プロセスを完全に変更します。

1. lyncdiscoverinternal。<内部 Web サービス上の自動検出サービスのドメイン> A (ホスト) レコード

2. lyncdiscover。<外部 Web サービス上の自動検出サービスのドメイン> A (ホスト) レコード

他のレコードの種類へのフォールバックはありません。

古いクライアントと比較して、新しいクライアントに使用される方法の違いは、自動検出サービスがすべてのサービスを検索するための推奨される方法になっている点です。

接続が成功すると、自動検出サービスは、モビリティ サービス (IIS でサービス用に作成された仮想ディレクトリによって Mcx と呼ばれます)、Microsoft Lync Web アプリ、Web スケジューラ URL など、ユーザーのホーム プールのすべての Web サービス URL を返します。 ただし、内部モビリティ サービス URL と外部モビリティ サービス URL の両方が外部 Web サービス FQDN に関連付けられます。 そのため、モバイル デバイスがネットワークの内部か外部かに関係なく、デバイスは常にリバース プロキシを介してモビリティ サービスに外部に接続します。

Lync Server 2013 の累積更新: 2013 年 2 月がインストールされている場合、自動検出サービスは内部/UCWA、External/UCWA、UCWA への参照も返します。 これらのエントリは、ユニファイド コミュニケーション Web API (UCWA) Web コンポーネントを参照します。 現在、エントリ UCWA のみが使用され、Web コンポーネントの URL への参照が提供されます。 UCWA は、Lync 2010 Mobile クライアントで使用される Mcx Mobility Service の代わりに、Lync 2013 Mobile クライアントによって使用されます。

モバイル デバイスでは、サービスの手動検出がサポートされます。 この場合、各ユーザーは、次のように、プロトコルとパスを含む完全な内部および外部の自動検出サービス URI を使用してモバイル デバイス設定を構成する必要があります。

• <https:// ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root for external access

• <https:// 内部アクセス用のIntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root

手動検出ではなく、自動検出を使用することをお勧めします。 ただし、手動設定は、モバイル デバイス接続の問題のトラブルシューティングに役立ちます。

Lync Server を使用したSplit-Brain DNS の構成

スプリットブレイン DNS は、複数の名前 (たとえば、分割 DNS やスプリットホライズン DNS) によって認識されます。 単に、同じ名前空間を持つ 2 つの DNS ゾーンが存在する DNS 構成について説明します。ただし、1 つの DNS ゾーンは内部のみの要求にサービスを提供し、他の DNS ゾーンは外部専用の要求にサービスを提供します。 ただし、内部 DNS に含まれる DNS SRV および A レコードの多くは外部 DNS に含まれず、逆も同様です。 内部 DNS と外部 DNS (www.contoso.com など) の両方に同じ DNS レコードが存在する場合、返される IP アドレスは、クエリが開始された場所 (内部または外部) によって異なります。

これらのトピックでは、スプリットブレイン DNS という用語が使用されます。

分割頭脳 DNS を構成する場合は、次の内部ゾーンと外部ゾーンに、各ゾーンに必要な DNS レコードの種類の概要が含まれます。 詳細については、「 Lync Server 2013 での外部ユーザー アクセスのシナリオ」を参照してください。

内部 DNS:

• 信頼できる contoso.com と呼ばれる DNS ゾーンが含まれています。

• 内部 contoso.com ゾーンには次のものが含まれます。

  • 内部 Lync Server 2013 クライアントの自動構成 (省略可能) の DNS A と AAAA (IPv6 アドレス指定を使用している場合) と SRV レコード

  • LYNC Server 2013 Web Services の自動検出に DNS A と AAAA (IPv6 アドレス指定を使用している場合) または CNAME レコード (省略可能)

  • フロントエンド プール名、ディレクターまたはディレクター プール名、および企業ネットワークで Lync Server 2013 を実行しているすべての内部サーバーの DNS A と AAAA (IPv6 アドレス指定を使用している場合) レコード

  • 境界ネットワーク内の各 Lync Server 2013 Edge 内部インターフェイスの DNS A と AAAA (IPv6 アドレス指定を使用している場合) レコード

  • 境界ネットワーク内の各リバース プロキシ サーバーの内部インターフェイスに対する DNS A と AAAA (IPv6 アドレス指定を使用している場合) レコード (リバース プロキシの管理の場合は省略可能)

  • 境界ネットワーク内のすべての Lync Server 2013 Edge Server 内部エッジ インターフェイスは、クエリを解決するために内部 DNS ゾーンを使用して contoso.com

  • Lync Server 2013 を実行しているすべてのサーバーと、企業ネットワークで Lync 2013 を実行しているクライアントは、内部 DNS サーバーを指し示し、クエリを contoso.com に解決したり、各エッジ サーバーで HOSTS ファイルを使用したり、次ホップ サーバー (特にディレクターまたはディレクター VIP) の A と AAAA (IPv6 アドレス指定を使用している場合) レコードを一覧表示します。 フロントエンド プール VIP または Standard Edition サーバー

外部 DNS:

• 信頼できる contoso.com と呼ばれる DNS ゾーンが含まれています。

• 外部 contoso.com ゾーンには次のものが含まれます。

  • Lync Server 2013 クライアントの自動構成 (省略可能) の DNS A と AAAA (IPv6 アドレス指定を使用している場合) と SRV レコード

  • モビリティで使用する Lync Server 2013 Web サービスの自動検出用の DNS A と AAAA (IPv6 アドレス指定を使用している場合) または CNAME レコード

  • 境界ネットワーク内の各 Lync Server 2013、Edge Server、またはハードウェア ロード バランサー仮想 IP (VIP) の Edge 外部インターフェイスの DNS A と AAAA (IPv6 アドレス指定を使用している場合) と SRV レコード

  • リバース プロキシ サーバーの外部インターフェイス用の DNS A と AAAA (IPv6 アドレス指定を使用している場合) レコード、または境界ネットワーク内のリバース プロキシ サーバーのプールの VIP

Split-Brain DNS を使用しない自動構成

スプリットブレイン DNS を使用すると、内部でサインインする Lync Server 2013 ユーザーは、内部 DNS ゾーンに使用中の各 SIP ドメインの_sipinternaltls._tcp SRV レコードが含まれている場合、自動構成を利用できます。 ただし、分割頭脳 DNS を使用しない場合、このセクションで後述する回避策の 1 つが実装されていない限り、Lync を実行しているクライアントの内部自動構成は機能しません。 これは、Lync Server 2013 では、自動構成用に指定されたフロントエンド プールのドメインと一致するようにユーザーの SIP URI が必要であるためです。 これは、以前のバージョンの Communicator でも同様でした。

たとえば、2 つの SIP ドメインが使用されている場合は、次の DNS サービス (SRV) レコードが必要になります。

• ユーザーの SIP ドメイン (contoso.com) が自動構成フロントエンド プールのドメインと一致するため、ユーザーが次の SRV レコードとして bob@contoso.com サインインすると、自動構成が機能します。

   _sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061 pool01.contoso.com

• ユーザーが次の DNS SRV レコードとして alice@fabrikam.com サインインすると、2 番目の SIP ドメインの自動構成が機能します。

   _sipinternaltls._tcp.fabrikam.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com

比較のために、ユーザーが次の DNS SRV レコードとして tim@litwareinc.com サインインした場合、クライアントの SIP ドメイン (litwareinc.com) がプール内のドメイン (fabrikam.com) と一致しないため、自動構成では機能しません。

 _sipinternaltls._tcp.litwareinc.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com

Lync を実行しているクライアントに自動構成が必要な場合は、次のいずれかのオプションを選択します。

• グループ ポリシー オブジェクト グループ ポリシー オブジェクト (GPO) を使用して、正しいサーバー値を設定します。

  注意

  このオプションは自動構成を有効にしませんが、手動構成のプロセスを自動化するため、この方法を使用する場合、自動構成に関連付けられている SRV レコードは必要ありません。

• 一致する内部ゾーン 外部 DNS ゾーン (contoso.com など) に一致する内部 DNS にゾーンを作成し、自動構成に使用される Lync Server 2013 プールに対応する DNS A と AAAA (IPv6 アドレス指定を使用している場合) レコードを作成します。 たとえば、ユーザーが pool01.contoso.net に所属していて Lync に bob@contoso.comサインインしている場合は、contoso.com と呼ばれる内部 DNS ゾーンを作成し、その内部に DNS A と AAAA (IPv6 アドレス指定が使用されている場合) レコードを作成 pool01.contoso.com。

• ピンポイント内部ゾーン 内部 DNS でゾーン全体を作成する場合は、自動構成に必要な SRV レコードに対応するピンポイント (つまり専用) ゾーンを作成し、dnscmd.exeを使用してこれらのゾーンにデータを設定できます。 DNS ユーザー インターフェイスがピンポイント ゾーンの作成をサポートしていないため、Dnscmd.exeが必要です。 たとえば、SIP ドメインが contoso.com で、2 つのフロントエンド サーバーを含む pool01 というフロントエンド プールがある場合は、内部 DNS に次のピンポイント ゾーンと A レコードが必要です。

  dnscmd . /zoneadd _sipinternaltls._tcp.contoso.com. /dsprimary
  dnscmd . /recordadd _sipinternaltls._tcp.contoso.com. @ SRV 0 0 5061 pool01.contoso.com.
  dnscmd . /zoneadd pool01.contoso.com. /dsprimary
  dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.90
  dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
  dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.91 
  dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
  

  環境に 2 つ目の SIP ドメイン (fabrikam.com など) が含まれている場合は、内部 DNS で次のピンポイント ゾーンと A レコードが必要です。

  dnscmd . /zoneadd _sipinternaltls._tcp.fabrikam.com. /dsprimary
  dnscmd . /recordadd _sipinternaltls._tcp.fabrikam.com. @ SRV 0 0 5061 pool01.fabrikam.com.
  dnscmd . /zoneadd pool01.fabrikam.com. /dsprimary
  dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.90
  dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
  dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.91
  dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
  

詳細については、DMTF ブログの記事「Communicator Automatic Configuration and Split-Brain DNS」 https://go.microsoft.com/fwlink/p/?linkId=200707を参照してください。

ディザスター リカバリー用のドメイン ネーム システム (DNS) の構成

Lync Server 2013 Web トラフィックをディザスター リカバリー サイトとフェールオーバー サイトにリダイレクトするように DNS を構成するには、GeoDNS をサポートする DNS プロバイダーを使用している必要があります。 Web 用の DNS レコードを設定してディザスター リカバリーをサポートし、1 つのフロントエンド プール全体がダウンした場合でも Web サービスを使用する機能を続行できます。 このディザスター リカバリー機能は、自動検出 (Lyncdiscover URL)、Meet、Dial-In の単純な URL をサポートします。

GeoDNS プロバイダーで Web サービスの内部および外部解決のために、追加の DNS ホスト (IPv6 を使用する場合は A と AAAA) レコードを定義して構成します。 次の詳細は、ラウンドロビン DNS を使用してプロバイダーによってサポートされているペア プール、地理的に分散された GeoDNS、またはプライマリとして Pool1 を使用するように構成されており、通信の損失またはハードウェア障害が発生した場合に Pool2 にフェールオーバーすることを前提としています。

DNS Load Balancing

DNS 負荷分散は通常、アプリケーション レベルで実装されます。 アプリケーション (Lync を実行しているクライアントなど) は、プールの完全修飾ドメイン名 (FQDN) の DNS A と AAAA (IPv6 アドレス指定が使用されている場合) レコード クエリから返された IP アドレスのいずれかに接続することで、プール内のサーバーへの接続を試みます。

たとえば、pool01.contoso.com という名前のプールに 3 つのフロントエンド サーバーがある場合、次のことが発生します。

• pool01.contoso.com の Lync クエリ DNS を実行しているクライアント。 クエリは 3 つの IP アドレスを返し、次のようにキャッシュします (必ずしもこの順序ではありません)。

  pool01.contoso.com 192.168.10.90

  pool01.contoso.com 192.168.10.91

  pool01.contoso.com 192.168.10.92

• クライアントは、いずれかの IP アドレスへの伝送制御プロトコル (TCP) 接続を確立しようとします。 失敗した場合、クライアントはキャッシュ内の次の IP アドレスを試行します。

• TCP 接続が成功した場合、クライアントは TLS のネゴシエーションを行い、pool01.contoso.com のプライマリ レジストラーに接続します。

• クライアントが接続に成功せずにキャッシュされたすべてのエントリを試行すると、Lync Server 2013 を実行しているサーバーが現時点で使用できないことがユーザーに通知されます。

DNS 負荷分散は、次の目的で使用されます。

• サーバー間 SIP をエッジ サーバーに負荷分散する

• 会議の自動応答、応答グループ、コール パークなどのユニファイド コミュニケーション アプリケーション サービス (UCAS) アプリケーションの負荷分散

• UCAS アプリケーションへの新しい接続の防止 ("ドレイン" とも呼ばれます)

• クライアントとエッジ サーバー間のすべてのクライアント間トラフィックの負荷分散

DNS 負荷分散は、次の目的では使用できません。

• ディレクターまたはフロント エンド サーバーへのクライアントからサーバーへの Web トラフィック

DNS 負荷分散とフェデレーション トラフィック:

DNS SRV クエリによって複数の DNS レコードが返される場合、Access Edge サービスは常に、優先順位が最も低く、数値の重みが最も高い DNS SRV レコードを選択します。 インターネット エンジニアリングタスクフォースのドキュメント 「サービスの場所を指定するための DNS RR (DNS SRV)」では http://www.ietf.org/rfc/rfc2782.txt 、複数の DNS SRV レコードが定義されている場合は、優先順位が最初に使用され、重み付けされます。 たとえば、DNS SRV レコード A の重みは 20、優先度は 40、DNS SRV レコード B の重みは 10、優先度は 50 です。 優先度 40 の DNS SRV レコード A が選択されます。 DNS SRV レコードの選択には、次の規則が適用されます。

• 優先度が最初と見なされます。 クライアントは、到達できる優先順位が最も低い DNS SRV レコードによって定義されたターゲット ホストへの接続を試みる必要があります。 同じ優先度のターゲットは、重みフィールドで定義された順序で試行する必要があります。

• 重みフィールドは、同じ優先度を持つエントリの相対重みを指定します。 重みを大きくすると、選択される確率が比例して高くなります。 DNS 管理者は、実行するサーバーの選択がない場合は、重み 0 を使用する必要があります。 重みが 0 より大きいレコードがある場合、重み 0 のレコードが選択される可能性は非常に小さいはずです。

優先度と重みが等しい複数の DNS SRV レコードが返される場合、Access Edge サービスは DNS サーバーから最初に受信した SRV レコードを選択します。